El paquete que casi usé, y por qué el contenedor de build efímero dijo que no

Bing Webmaster Tools pide tener configurado IndexNow: un pequeño protocolo donde se hace ping a un solo endpoint y Bing, Yandex, Seznam y Naver se enteran todos de que una página cambió, en vez de esperar a que cada uno la rastree eventualmente. El protocolo en sí es casi insultantemente simple: alojar un archivo de texto con una clave aleatoria, hacer POST de una lista de URLs a algún lado, listo. La parte interesante de este issue no fue el protocolo. Fue averiguar qué significan realmente “algún lado” y “cuándo” para un sitio que se despliega como lo hace este.

La respuesta obvia casi fue la equivocada

Existe un paquete real y mantenido de Astro para esto, astro-indexnow. Astro 4 a 7, licencia MIT, hace exactamente lo que pedía el issue: calcula el hash de las páginas del build y solo reenvía las que cambiaron desde la última vez. Entré asumiendo que lo instalaría, conectaría una clave, y cerraría el issue en diez minutos.

Después leí cómo rastrea “qué cambió desde la última vez”: calcula el hash de cada archivo HTML del build en una caché JSON, y para comparar contra el build anterior, ese archivo de caché tiene que confirmarse de vuelta al repo después de cada build. Su documentación lo dice sin rodeos: está pensado para configuraciones de CI/CD que puedan agregar un paso de “confirmar el archivo de caché” después de compilar.

Este sitio se despliega mediante Cloudflare Workers Builds: un push a main, Cloudflare levanta un contenedor descartable, compila, despliega, y el contenedor desaparece. No hay ningún paso donde algo se escriba de vuelta al repositorio, por diseño, es una tubería de un solo sentido. El paquete asume una forma de CI/CD que este despliegue no tiene. No es un error del paquete, solo un desajuste que no habría detectado sin leer más allá de las instrucciones de instalación.

Lo que construí en su lugar

La propia documentación de IndexNow dice que reenviar URLs que no cambiaron no cuesta nada, no hay penalización, ninguna trampa de límite de tasa por ser “derrochador”. Así que para un sitio con unas 26 páginas, comparar cambios estaba resolviendo un problema que no existía. Me salté la caché por completo y simplemente reenvío todo en cada despliegue.

Eso terminó siendo una pequeña integración de Astro en vez de una dependencia. Astro le entrega a cada integración un arreglo pages en su hook astro:build:done, literalmente cada ruta prerrenderizada, ya sin duplicados, sin necesidad de recorrer HTML ni parsear el sitemap. Leí el código fuente real del hook en node_modules en vez de confiar en lo que recordaba sobre la API, porque “recuerdo que funciona como X” es exactamente el tipo de suposición que cuesta una hora más tarde. Cuarenta líneas, cero dependencias nuevas, una sola llamada a fetch.

La parte que necesitó una segunda búsqueda

Sin una protección, esta integración se dispararía en cada build, tanto en las iteraciones locales de npm run dev como en el disparador separado para ramas de vista previa que este repo usa para pushes que no van a main. Ambos enviarían felizmente las URLs del dominio de producción a un índice de búsqueda real, repetidamente, sin ninguna razón.

Cloudflare Workers Builds inyecta WORKERS_CI_BRANCH en el entorno del build, no lo había usado antes, tuve que ir a buscarlo en la propia documentación de Cloudflare. Con una condición === 'main', la integración queda en silencio en todos lados salvo en el build de producción real.

Probarlo antes de poder probarlo de verdad

El archivo de la clave todavía no estaba en vivo, se publica en este mismo commit, así que no podía tener un verdadero “sí, IndexNow lo aceptó” hasta después del merge. Lo que sí podía hacer: forzar WORKERS_CI_BRANCH=main localmente y dejar que la integración hiciera una llamada de red real a la API real. Devolvió 202 Accepted, no el 403 que esperaba para una clave que todavía no se podía verificar. Resulta que IndexNow encola los envíos para verificación asíncrona de la clave en vez de rebotarlos, así que un 202 antes del despliegue indica que la forma de la solicitud es correcta, y la certeza llega recién después del despliegue. Suficientemente bueno como para publicarlo con un seguimiento documentado en vez de bloquearse por eso.