Envío de URLs con IndexNow: configuración y errores

IndexNow avisa a los buscadores participantes de que una URL se ha añadido, modificado o eliminado. Bing lo recomienda para automatizar las notificaciones entre los buscadores participantes. Su guía de envío de URLs distingue este mecanismo de las opciones que solo envían a Bing.

Un equipo SEO necesita saber si un cambio publicado generó la notificación correcta y qué ocurrió después. Un indicador verde en el panel de la integración no basta para responder. El desarrollador necesita identificar el evento, el host verificado, la solicitud y su respuesta. El responsable SEO necesita pruebas sobre la página que encontró después el buscador.

Pensemos en una empresa hipotética de Barcelona con páginas de servicios en español, catalán e inglés. Su editor corrige la descripción de un servicio, retira una oferta antigua y publica una traducción. Cada cambio requiere comprobaciones distintas, aunque todos utilicen el mismo mecanismo de envío. El objetivo es registrar las URLs públicas que cambian sin obligar al editor a recordar otra tarea cada vez que publica.

Define qué vas a comprobar antes de conectar la API

Según la documentación del protocolo, HTTP 200 confirma la recepción; HTTP 202 indica recepción con la validación de la clave pendiente. Ninguno de los dos estados informa de la inclusión en el índice. La especificación de respuestas de IndexNow define qué debe reflejar el registro de envíos.

Separa los hitos del proceso: cambio visible en producción, notificación recibida, rastreo observado y estado de indexación comprobado. Asigna un responsable cuando falte alguno. Si el despliegue terminó pero no hay notificación, revisa la integración de publicación. Si el endpoint recibió la URL, investiga cómo se descubre la página y qué contiene. Repetir una solicitud correcta no aporta la prueba que falta.

Bing afirma expresamente que IndexNow no garantiza el rastreo ni la indexación. Su guía de configuración recoge ese límite. Las posiciones, el tráfico orgánico y las citas en respuestas de IA también son resultados independientes. Ninguno sirve como criterio de aceptación de una solicitud de notificación.

Los envíos se comparten entre los buscadores participantes. Google no figura en la lista de endpoints de las preguntas frecuentes oficiales de IndexNow. No presentes una confirmación de recepción de IndexNow como un envío a Google. Conserva las comprobaciones de Google Search Console en su proceso habitual y mantén por separado el inventario de sitemaps XML.

Elige quién se encarga de los envíos

Comprueba primero si el CMS, un plugin o el alojamiento ya envían notificaciones. El directorio de configuración de Bing enumera integraciones compatibles y recomienda revisar la actividad existente en Webmaster Tools. Prioriza una integración existente si puedes comprobar sus eventos y diagnosticar sus fallos. Desarrolla un emisor propio cuando necesites un control que esa integración no ofrece. La decisión afecta al mantenimiento: cuenta con quien tendrá que repararla cuando falle una publicación.

Pide a su responsable que enseñe un cambio reciente. ¿Qué URL pública envió? ¿El aviso partió de un borrador guardado, del botón Publicar o de un despliegue terminado? ¿Puedes ver las eliminaciones? ¿Quién recibe un aviso cuando fallan las solicitudes? Estas preguntas ayudan más que comparar capturas de plugins.

En una web estática, toma como punto de partida el despliegue correcto en producción. Guardar un archivo en el repositorio solo expresa un cambio previsto. Los fallos de compilación, las cancelaciones y los retrasos del despliegue ocurren antes de notificar. Envía los avisos cuando el contenido o la respuesta esperados ya estén disponibles en el host público.

Designa a una persona responsable y documenta qué sistema realiza los envíos. Antes de incorporar otro plugin o una tarea vinculada al despliegue, revisa el proceso existente. Si no puedes evitar que varios emisores coincidan, detalla qué eventos cubre cada uno y cómo contrastarás sus registros. Un aumento inexplicable de solicitudes merece una investigación.

Verifica el host y la ubicación de la clave

Para la configuración manual, las preguntas frecuentes indican una clave de entre 8 y 128 caracteres formada por letras, dígitos o guiones. Las instrucciones sobre la clave también exigen acceso público sin iniciar sesión. Genera un valor para tu sitio; las cadenas del ejemplo son valores ficticios.

El archivo de verificación de la raíz es un texto UTF-8 cuyo nombre es la clave seguida de .txt y cuyo contenido es la propia clave. Según la documentación de verificación de propiedad, ese archivo permite verificar el host. Para un host de ejemplo, la configuración sería:

Host: www.example.com
Key: 61af7490d82b4e718093a420f96cbe25
File URL: https://www.example.com/61af7490d82b4e718093a420f96cbe25.txt
File content: 61af7490d82b4e718093a420f96cbe25

Consulta directamente el archivo desplegado con un cliente HTTP. Examina tanto el cuerpo como el estado: una respuesta de reserva de la aplicación puede mostrar una página HTML de la marca donde esperabas texto plano. Prueba sin sesión de administrador y comprueba que ningún control del cortafuegos ni una pantalla de acceso sustituya la respuesta. Guarda la prueba junto a la configuración.

Una ubicación alternativa exige keyLocation. Un archivo bajo /catalog/ autoriza ese prefijo de URLs, pero no páginas ajenas bajo /services/. Las reglas de ubicación del protocolo hacen que la raíz sea la opción más sencilla para un emisor que cubra toda la web.

En sitios multilingües, presta atención a esa ubicación. Guardar la clave dentro de la carpeta inglesa porque el desarrollador trabaja allí puede provocar un error de configuración. Decide primero qué URLs debe cubrir la verificación. La condición de pertenecer al mismo host también exige tratar de forma expresa el dominio sin subdominio y su versión con www; no des por hecho que un archivo cubre ambos.

Los subdominios necesitan sus propios archivos de verificación, según las preguntas frecuentes de IndexNow. Mantén un registro de configuración por host. Anota el host de producción, el identificador de la clave, la URL del archivo, el equipo responsable y la última fecha de comprobación. Ese archivo debe servirse públicamente; las credenciales del despliegue no tienen cabida en él.

Cuando cambies la clave, coordina el archivo desplegado y la configuración del emisor en una misma publicación. Prueba el archivo nuevo antes de utilizarlo en las solicitudes de producción. Conserva información de la configuración anterior para interpretar intentos antiguos que sigan en cola y comprueba qué configuración utilizará el proceso cuando reintente.

Prueba una solicitud representativa antes de enviar un lote

La API admite una URL mediante GET y un conjunto mediante POST con JSON, con hasta 10.000 URLs por POST. La documentación de envío define ambos formatos. Empieza la prueba con una URL pública real que haya cambiado recientemente; no exportes toda la web para el primer intento.

Este cuerpo de POST ilustra los campos documentados. Sustituye el host, la clave y las URLs por valores que controles:

{
  "host": "www.example.com",
  "key": "61af7490d82b4e718093a420f96cbe25",
  "keyLocation": "https://www.example.com/61af7490d82b4e718093a420f96cbe25.txt",
  "urlList": [
    "https://www.example.com/en/services/",
    "https://www.example.com/ca/serveis/"
  ]
}

Utiliza https://api.indexnow.org/indexnow con JSON y la cabecera Content-Type application/json; charset=utf-8. El ejemplo de configuración manual de Bing muestra esta estructura. El bloque anterior representa el cuerpo de una solicitud; no es un script que haya enviado esas páginas.

Para GET, codifica la URL de la página como parámetro de consulta. El protocolo exige escapar la URL. En un cuerpo POST, utiliza el serializador JSON del cliente y conserva URLs absolutas válidas en la lista. Evita concatenar cadenas a mano, sobre todo si la ruta lleva tildes o la consulta contiene el signo &.

En la prueba inicial, registra la URL exacta enviada, el endpoint elegido, la fecha y hora, el estado y las cabeceras de respuesta. Compara la URL registrada con la dirección de la página prevista en el navegador. Conserva el prefijo de idioma, las mayúsculas de la ruta y la convención de barra final. No envíes un host de previsualización porque aparezca en el mensaje de despliegue correcto del proveedor.

Pasa a los lotes cuando puedas relacionar la URL enviada con su respuesta. Agrupa por host verificado y fija un límite explícito de tamaño. El máximo de 10.000 URLs es un límite del protocolo, no una cifra que debas alcanzar antes de enviar. Trabaja con lotes menores si facilitan inspeccionar o repetir una solicitud fallida.

Decide qué cambios merecen una notificación

Acuerda con el equipo editorial qué eventos activan los envíos. Las recomendaciones de la tabla están pensadas para una web de empresa; adapta los ejemplos al contenido que publicas. El efecto público del cambio debe decidir si el evento entra en la cola.

IndexNow admite URLs redirigidas y URLs eliminadas que devuelven 404 o 410. Las preguntas frecuentes contemplan ambos casos. No reutilices un filtro de exportación del sitemap que descarte todas las respuestas distintas de 200: la política de notificación debe conservar las eliminaciones intencionadas.

Cuando retires una oferta, guarda su dirección antes de borrar la ficha del CMS. De lo contrario, el proceso de envío podría quedarse sin la URL que debe notificar. Distingue el evento de eliminación en tu registro, aunque el cuerpo enviado sea una lista de URLs. Quien lo revise más adelante debe entender por qué se envió una página ausente.

Si una página cambia de dirección, verifica por separado la antigua y el destino. Comprueba en producción el 301 u otra respuesta de redirección prevista. Si el destino también es nuevo o ha cambiado, inclúyelo como evento propio. Comprobar una redirección no demuestra que el buscador ya haya consultado el destino.

Aplica reglas explícitas al contenido traducido. En el ejemplo hipotético de Barcelona, editar solo el texto español no demuestra que haya cambiado la respuesta catalana o inglesa. En cambio, un dato compartido del servicio puede afectar a todos los idiomas al desplegarse. Obtén las URLs afectadas a partir de la salida publicada o de las relaciones entre contenidos y comprueba una muestra. Revisa canonical y hreflang en la auditoría SEO técnica; las notificaciones no corrigen esas relaciones.

Para páginas con cambios frecuentes, las preguntas frecuentes oficiales recomiendan al menos 5 minutos entre notificaciones repetidas de cambios relevantes. Su guía de automatización prioriza las actualizaciones sustanciales frente a los cambios cosméticos. Aplica ese intervalo después de decidir si el cambio requiere un envío. Una página sin cambios no necesita un temporizador.

Conserva una cola que puedas recuperar

En una integración propia, una opción práctica es mantener una lista persistente de cambios pendientes en producción. Guarda la URL, el momento del evento, el identificador del despliegue y el resultado previsto. Encarga el envío a un proceso separado de la acción de publicar del editor. Es una recomendación de implementación: el equipo debe poder reintentar una entrega sin pedir que se vuelva a publicar el contenido.

Agrupa los cambios próximos de una misma URL antes de enviarlos. Conserva el último estado público relevante y suficiente historial para diagnosticar lo ocurrido. Si una página se publica y se retira antes de ejecutarse el proceso, quien revise el registro necesita conocer esa secuencia. Una marca de éxito no debería borrar el motivo del evento.

Si falla la validación de un lote, guarda el lote y sus URLs para revisarlos. Reconstruir la lista desde el contenido actual puede omitir las direcciones eliminadas que originaron la notificación. Vincula los reintentos a los eventos registrados y comprueba si otros cambios posteriores los han sustituido.

Documenta qué ocurre tras un reinicio. Si el proceso se interrumpe, ¿qué registros siguen pendientes? Si reviertes un despliegue, ¿qué URLs necesitan otro aviso? Incluye esas situaciones en las pruebas de aceptación cuando la cola aún sea pequeña. Comprobar que el sistema se recupera de un fallo permite evaluar su funcionamiento mejor que acumular solicitudes de prueba correctas.

Resuelve cada error según su causa

Los códigos siguientes proceden de la referencia de configuración de IndexNow de Bing. Las acciones propuestas son recomendaciones operativas; no prometen una respuesta determinada en el próximo intento.

Registra por separado 200 y 202. Un 202 justifica vigilar la verificación, no reenviar el mismo lote una y otra vez. Comprueba el acceso público al archivo y la configuración antes de atribuir al contenido una validación que sigue pendiente. Si el proceso etiqueta ambas respuestas como “indexado”, corrige esa etiqueta antes de que alguien la utilice en un informe.

Ante un 429, respeta Retry-After cuando se proporcione; cada buscador participante establece sus límites. La guía oficial sobre límites de solicitudes no publica una cuota diaria universal. No calcules un supuesto cupo diario multiplicando el tamaño máximo de lote por una frecuencia de solicitudes inventada.

Cuando un fallo transitorio de red, un tiempo de espera agotado o un error del servidor dejan la entrega sin confirmar, aplica reintentos limitados. Una opción de ingeniería razonable consiste en aumentar las esperas con cierta variación aleatoria, limitar los intentos y avisar al alcanzar ese límite. Son decisiones de diseño, no garantías adicionales de la API de IndexNow. Conserva los detalles para distinguir un problema de conexión de una solicitud rechazada.

Antes de procesar envíos acumulados, comprueba que el emisor siga apuntando al host correcto de producción y que el archivo de la clave continúe disponible. Repara primero los errores permanentes. Repetir miles de solicitudes mal formadas con más rapidez dificulta investigar el problema inicial. Si la cola crece tras un despliegue, compara el volumen de eventos nuevos con las entregas correctas y clasifica los fallos repetidos por causa.

Comprueba qué ocurrió después de la recepción

Bing Webmaster Tools muestra el origen y la hora del envío, además del estado de rastreo e indexación de una muestra de URLs. Su página de ayuda indica que las horas de envío sin zona especificada utilizan UTC. La documentación de informes de IndexNow define esos campos. Tenlo en cuenta al comparar un registro de despliegue con la hora local de un editor en España.

Elige un conjunto pequeño y estable de eventos relevantes para el seguimiento. Incluye una página nueva, una actualización y una eliminación intencionada si el despliegue las contiene. Guarda el momento de observación junto a cada estado. Un informe obtenido antes del siguiente rastreo no permite determinar qué hizo el buscador con el contenido más reciente.

El anuncio de Insights de Bing describe informes de URLs enviadas, rastreadas e indexadas, con detalle de los últimos 1.000 envíos. Según ese anuncio, la vista sirve para diagnosticar el proceso. Conserva tu propio registro de eventos para disponer de un historial duradero; una muestra reciente no equivale a una exportación histórica completa.

Utiliza la inspección de URLs de Bing para comparar la información del índice con una consulta en directo. Según su documentación, la prueba Live URL informa de las redirecciones sin seguirlas automáticamente; inspecciona el destino por separado. Anota si cada observación procede de la vista del índice o de la prueba en directo.

Si se recibe la notificación de una página nueva pero esta sigue sin indexarse, examina el acceso, robots.txt, noindex y la canonical declarada. Después revisa si el contenido es útil y distinto. Mantén visible el estado de la notificación mientras investigas la página: aportan pruebas diferentes. La guía de análisis de logs del servidor explica cómo comprobar por separado la actividad de los rastreadores a partir de los registros.

En una eliminación intencionada, cambia la pregunta de evaluación: ¿ha desaparecido el resultado obsoleto después de que el buscador procesara la nueva respuesta? No clasifiques toda URL enviada y sin indexar como un fallo. Un informe útil recoge el resultado previsto junto al observado, de modo que una oferta eliminada no se confunda con una página de servicio recién publicada.

Despliega la integración con un registro breve de aceptación

Empieza con un host de producción y un evento de publicación controlado. Verifica el archivo de la clave, captura la solicitud y clasifica su respuesta. Prueba un fallo recuperable en el entorno de pruebas de la integración o con un endpoint simulado; evita saturar deliberadamente la API pública. Demuestra que el evento permanece en la cola y que la solicitud corregida puede completar la entrega.

Después, comprueba una actualización y una eliminación reales cuando se produzcan. Registra qué modificó el editor, cuándo cambió la respuesta pública, qué URL envió el proceso y qué pruebas de seguimiento existen. Si no puedes conectar esos datos, completa el registro antes de activar todos los tipos de contenido.

Describe el alcance del despliegue con precisión: la integración envía cambios admisibles de producción, registra los resultados de entrega y permite investigar incidencias. Afirmar que acelera la indexación exige observaciones separadas y una comparación adecuada. Las preguntas sobre la selección posterior de fuentes en Copilot corresponden a la guía de Bing AI Performance.

En la próxima publicación, pide al equipo el recorrido completo de una URL. El registro debe resultar comprensible para el editor, para quien mantiene el emisor y para el especialista SEO que comprueba la página. Esa es la prueba que necesitas antes de ampliar el proceso.