missing_indexnow_key
Umbodi publica el archivo /[clave].txt con la clave IndexNow del sitio, en una pull request, para poder anunciar páginas nuevas a Bing y otros buscadores, y comprueba que el archivo en vivo devuelve exactamente la clave.
Corregido por Umbodi en su propio sitio · simulacro
IndexNow permite que un sitio avise a Bing y a otros buscadores participantes en cuanto cambia una página. Los buscadores solo aceptan esos avisos de un sitio que sirve su archivo de clave.
Lo detecta el envío diario del sitemap, no la auditoría de páginas: lee /[clave].txt y se activa si el archivo no devuelve exactamente la clave. Gravedad: aviso.
El agente publica /[clave].txt cuyo único contenido es la clave, creada y guardada por la plataforma para el proyecto. El defecto se cierra cuando el envío diario lee el archivo en vivo.
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.
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.
Plantamos este defecto en nuestro propio sitio y dejamos que el agente lo encontrara. Cada etapa es una marca de tiempo leída de los recibos, no una afirmación escrita en esta página.
| Página | plantado | encontrado | propuesto | aprobado | publicado | fusionado | verificado |
|---|---|---|---|---|---|---|---|
| /00447098f7fba55c133eb7dd520325e7.txt | 2026-10-11 03:46 | 2026-10-11 07:10 | 2026-10-11 07:10 | 2026-10-11 07:30 | 2026-10-11 07:30 | 2026-10-11 08:20 | 2026-10-11 08:40 |
00447098f7fba55c133eb7dd520325e7.txtfile deleted (1 lines)00447098f7fba55c133eb7dd520325e7.txt+ 00447098f7fba55c133eb7dd520325e7 file created (1 lines)
Última verificación 2026-10-11 08:40 UTC
Que toda la cadena se ejecutó sin ninguna decisión humana dentro: el agente encontró el defecto, decidió la corrección, la publicó, la fusionó y verificó el sitio 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 publica el archivo /[clave].txt con la clave IndexNow del sitio, en una pull request, para poder anunciar páginas nuevas a Bing y otros buscadores, y comprueba que el archivo en vivo devuelve exactamente la clave.
Sí. Lo plantamos en nuestro propio sitio y el agente lo encontró, corrigió, fusionó y verificó sin ninguna decisión humana en el ciclo. El recibo está en esta página.
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.