sitemap_url_not_indexable
Umbodi elimina las entradas del sitemap cuyas páginas no sirven nada legible para un rastreador, solo si el propietario aceptó los cambios de política de rastreadores, lo publica en una pull request y comprueba que las entradas han desaparecido.
No corregido por Umbodi en su propio sitio — no se puede plantar allí
Una entrada de sitemap que devuelve un error o una página vacía lleva a los rastreadores a un callejón sin salida y gasta su atención en una página que no se puede indexar.
Se activa por cada URL del sitemap que no sirve nada legible: una página vacía o solo de scripts, un error HTTP o ningún sitio. Hoy solo la detecta una auditoría de sitio iniciada desde la app; la ejecución nocturna aún no. Gravedad: aviso o error.
El agente elimina esas URL del sitemap y se niega si lo dejara vacío. Es uno de dos remedios opuestos —el otro es arreglar la página—, así que solo actúa con permiso del propietario sobre la política de rastreadores.
El cambio llega al sitio como una pull request que añade o edita un archivo en la raíz web del repositorio, abierta por la app de GitHub de Umbodi. Los bloques generados van entre delimitadores que gestiona el agente, así que las líneas escritas a mano nunca se reescriben.
El valor se deriva de los datos del propio sitio, así que el cambio se marca como mecánico y no se aplica umbral de puntuación. Aun así, solo se aplica si el propietario activó la acción sin supervisión y puso el dial de autonomía de esta categoría en automático; fusionar requiere un permiso aparte.
Como cambia lo que pueden leer los rastreadores, hay un control más: el propietario debe haber aceptado para el proyecto los cambios de política de rastreadores. Sin eso, el agente propone y espera.
Una propuesta de cada diez se reserva como grupo de control —elegida por un hash fijo por proyecto, no a mano— y nunca se aplica sin supervisión, para medir el efecto de las correcciones frente a las no hechas.
Tras fusionar la pull request y aparecer el despliegue en producción, el agente lee el archivo en vivo y lo compara con el propio diff de la fusión: cada línea añadida debe estar, y un cambio que solo quitaba líneas debe haberlas eliminado. Si no, el archivo se relee hasta cinco veces, unas dos horas y media, y después el agente revierte su propia fusión.
Se detiene, y dice por qué, cuando el archivo en vivo lo genera el código del sitio en lugar de servirse desde el repositorio —una pull request no cambiaría nada—, cuando el archivo del repositorio ya dice lo mismo, cuando un cambio de robots.txt requiere una política que el propietario no ha elegido, o según las mismas reglas de fusión y despliegue que las páginas. Nunca revierte sobre un archivo que no puede obtener.
Nuestro sitio no tiene dónde plantar este defecto sin romper algo real, así que no hay recibo en vivo. La corrección solo está demostrada en la batería de pruebas. El motivo, tal como lo dice el código:
plantable in principle and not built: it needs a new sitemap edit that ADDS a url serving nothing (the existing sitemap_lastmod target only ages an entry), and the drill then advertises a dead page to crawlers for up to 52 hours. Measured 2026-10-07: the remedy and the plant are inverses — the agent dropping the url restores exactly what scripts/build-sitemap.mjs produces — so this is the one of the three that a later session could reasonably add. It is listed rather than attempted because a drill that lies to a crawler about a page should be a deliberate decision, not a side effect of finishing a list.
Última verificación 2026-10-11 08:43 UTC
Solo lo que demuestra la batería de pruebas: el camino del hallazgo a la corrección verificada funciona con casos de prueba. Nada en esta página afirma que haya ocurrido en vivo.
No demuestra ningún cambio de posición ni de citas. Umbodi nunca lo deduce de una corrección: la posición se mide aparte, en Google, y se informa tal como se mide. Un recibo también muestra que el camino funciona en este sitio, no en todos.
Umbodi elimina las entradas del sitemap cuyas páginas no sirven nada legible para un rastreador, solo si el propietario aceptó los cambios de política de rastreadores, lo publica en una pull request y comprueba que las entradas han desaparecido.
No en vivo. Nuestro sitio no tiene dónde plantarlo sin romper algo real, así que la corrección solo está demostrada en la batería de pruebas, y esta página explica por qué.
La página de recibos lista cada tipo de defecto que el agente corrige por sí solo y cuáles ya ha corregido en vivo en este sitio.