El 404 que ya estaba correcto, y el robots.txt que no lo estaba

Dos huecos pequeños de SEO llevaban en el backlog desde un spike de hace unos días: no había línea Sitemap: en robots.txt, y las URLs desconocidas devolvían un 404 sin nada en el cuerpo. Ninguno de los dos se sentía urgente, que es justo la razón por la que habían sobrevivido tanto tiempo.

El fix de robots.txt se veía trivial: copiar el archivo de vdaluz.com, cambiar la URL del sitemap, listo. Lo único que tenía que hacer bien era el destino. El sitio genera dos archivos de sitemap, un índice y un shard numerado:

dist/client/sitemap-0.xml
dist/client/sitemap-index.xml

Lo que se necesita es el índice, no el shard. Apuntar los crawlers hacia el shard deja todo a un refactor de distancia de un enlace roto en el momento en que el sitio crezca más allá de una página de URLs.

La página 404 es donde casi sobreconstruyo el fix. Mi instinto fue: renderizarla en el servidor, porque no lograba convencerme de que una página estática prerenderizada mantendría el status HTTP correcto a través de un deploy en Workers con el ruteo de assets por delante. Pero tenía evidencia justo ahí antes de escribir una sola línea de código: el 404 actual, sin ninguna página personalizada, ya estaba devolviendo status 404 con el cuerpo vacío. Eso solo pasa si las rutas sin coincidencia ya están llegando al Worker de Astro y el Worker ya está decidiendo el status. Agregar una página prerenderizada no podía cambiar esa decisión, solo podía agregarle un cuerpo.

No confié del todo en ese razonamiento, así que no lo publiqué así nomás. Corrí wrangler dev localmente, el runtime real de Workers, no solo el resultado de astro build, y le hice curl a una ruta sin sentido:

curl -sI http://localhost:4321/nonsense-xyz
# HTTP/1.1 404 Not Found

Cuerpo con la marca, título correcto, status 404. La versión simple era correcta. Había preparado un fallback SSR de una línea en el plan por si no lo era, nunca hizo falta.

Después del deploy, lo interesante volvió a ser robots.txt. La descripción del issue decía que Cloudflare antepone sus propios comentarios gestionados de content-signals a lo que sea que sirvas desde el origen. Fui a verificarlo en vez de darlo por sentado:

curl -s https://imperfectsystems.com/robots.txt

Ningún comentario antepuesto. Solo nuestro archivo, tal cual, con línea Sitemap incluida. El supuesto del ticket no se sostuvo, pero el resultado, una directiva Sitemap funcionando, sí. Vale la pena recordar la próxima vez que toque este archivo: cualquier comportamiento de “anteposición” que exista, no es visible en una solicitud que ya tiene un robots.txt de origen para servir.