Umbodi es un agente autónomo para la visibilidad en búsquedas y en respuestas de IA, y funciona con GitHub. Audita tu sitio, escribe la corrección y abre una pull request en tu repositorio; nunca envía cambios directamente a tu sitio. Por defecto, tú lees el diff y lo fusionas; después vuelve a rastrear la página para saber si la corrección está realmente publicada.
Una GitHub App en los repositorios que elijas. Por defecto, nada se fusiona sin ti. Fusionar por su cuenta es un ajuste aparte, desactivado hasta que lo actives.
Los dos modos abren la misma pull request. Se diferencian en quién la fusiona.
Umbodi abre una pull request en el repositorio que elegiste. Una persona revisa el diff y lo fusiona. Umbodi nunca hace push a tu rama por defecto y nada llega a producción salvo a través de tu propio despliegue.
Activas la fusión por separado, y solo surte efecto si la publicación automática y la programación también están activas. Entonces Umbodi fusiona su propia pull request cuando pasan tus comprobaciones obligatorias, espera al despliegue, vuelve a leer la página publicada y revierte el cambio si no está.
Nunca fusiona ni revierte sin pruebas: una comprobación que no puede leer significa esperar, y una página que no puede obtener significa reintentar y, al final, desistir y decirlo. Solo escribe archivos de contenido y de descubribilidad, y nunca puede editar sus propios controles, pruebas ni CI.
En el modo autónomo, una reversión llega como un único commit en tu rama por defecto que restaura los archivos exactamente como estaban antes de su fusión, sin force push y sin reescribir el historial.
La mayoría de las herramientas se detienen tras el segundo. El cuarto es el que demuestra que el trabajo fue real.
Lee tu sitemap, rastrea cada página a la que puede llegar y registra lo que te está costando visibilidad.
Títulos, descripciones, datos estructurados y páginas enteras, redactados como el cambio de archivo en sí. No una tarea pendiente.
En el repositorio que elegiste, como una rama y un diff. Por defecto, tú lo revisas, lo fusionas y lo despliegas.
Aplicado significa que un rastreador vio el cambio en la página en vivo. Un pull request fusionado que nunca se desplegó sigue sin estar aplicado.
Cada plugin de SEO que edita tu sitio directamente pide un permiso que ningún otro proveedor obtiene.
Por defecto, la misma revisión por la que pasa cualquier otro cambio en tu sitio. En el modo autónomo, tus comprobaciones obligatorias son la barrera: nada se fusiona si no pasan.
Una fusión de la que te arrepientes es un revert. Una escritura directa de la que te arrepientes es un incidente, y te enteras por tu tráfico.
Tu historial de git dice qué cambió, cuándo y por qué — en el lugar donde tu equipo ya mira, no dentro del panel de un proveedor.
Si un revisor no puede decir para qué sirve un cambio, el cambio no está terminado.
Una página por pull request, o un lote de archivos de descubribilidad —sitemap, robots.txt, llms.txt—. Nunca un barrido de cuarenta archivos que hay que tomar o dejar entero.
Cada pull request nombra los hallazgos de auditoría que aborda, por código, para que quien revisa compare el cambio con lo que se midió, no con una mejora prometida.
Si no pudo abrir el pull request, nombra el motivo — la app no instalada en ese repositorio, por ejemplo — en lugar de informar de una ejecución limpia que no publicó nada.
Umbodi. Audita tus páginas, escribe la corrección y abre una pull request en el repositorio desde el que se construye tu sitio. Por defecto, el cambio es un diff que revisas y fusionas como cualquier otro; fusionar por su cuenta es una opción aparte. Umbodi nunca escribe directamente en tu sitio en producción.
Umbodi se instala como una GitHub App en los repositorios que elijas. Solo abre pull requests en esos repositorios, y si la instalación deja de cubrir un repositorio lo dice por su nombre en lugar de informar de una ejecución limpia que no publicó nada.
No. Cada cambio que propone a un repositorio llega como una pull request y, por defecto, nada se fusiona sin ti. Si activas por separado la fusión autónoma, solo fusiona su propia pull request cuando pasan tus comprobaciones obligatorias; después vuelve a leer la página publicada y revierte el cambio si no llegó. Para los sitios que no están en un repositorio, Umbodi prepara en su lugar el bloque exacto para que lo pegues.
Tras el despliegue, Umbodi vuelve a rastrear la página en vivo y comprueba que la corrección está presente en lo que recibe un rastreador. Aplicado significa que un nuevo rastreo la vio, no que una tarea devolviera un código de éxito — un pull request fusionado que nunca se desplegó sigue sin estar aplicado.
Solo si lo activas. La fusión autónoma está desactivada por defecto y necesita su propio ajuste, con la publicación automática y la programación activas. Con ella activa, Umbodi fusiona cuando pasan tus comprobaciones obligatorias; después verifica la página publicada y revierte si el cambio no llegó. Nunca fusiona sobre una comprobación que no pudo leer.
Ejecuta primero la auditoría y lee lo que encuentra. El pull request viene después, cuando estés de acuerdo con ella.