O 404 que já estava certo, e o robots.txt que não estava

Duas pequenas lacunas de SEO estavam paradas no backlog desde um spike de alguns dias atrás: nenhuma linha Sitemap: no robots.txt, e URLs desconhecidas retornando 404 sem nada no corpo. Nenhuma das duas parecia urgente, e é exatamente por isso que sobreviveram tanto tempo.

O fix do robots.txt parecia trivial: copiar o arquivo do vdaluz.com, trocar a URL do sitemap, pronto. A única coisa que eu precisava acertar era o alvo. O site gera dois arquivos de sitemap, um índice e um shard numerado:

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

Você quer o índice, não o shard. Aponte os crawlers para o shard e você fica a um refactor de distância de um link quebrado assim que o site crescer além de uma página de URLs.

A página de 404 foi onde eu quase construí a mais. Meu instinto foi: renderizar no servidor, porque eu não conseguia me convencer de que uma página estática pré-renderizada carregaria o status HTTP certo através de um deploy no Workers com roteamento de assets na frente. Mas eu tinha evidência bem ali antes de escrever uma linha de código: o 404 atual, sem nenhuma página customizada, já estava retornando status 404 com corpo vazio. Isso só acontece se rotas não encontradas já estão chegando ao Worker do Astro e o Worker já está decidindo o status. Adicionar uma página pré-renderizada não podia mudar essa decisão, só podia adicionar um corpo a ela.

Eu não confiei totalmente no raciocínio, então não publiquei em cima dele. Rodei o wrangler dev localmente, o runtime real do Workers, não só a saída do astro build, e testei uma rota qualquer com curl:

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

Corpo com a identidade visual certa, título certo, status 404. A versão simples estava correta. Eu tinha montado um fallback SSR de uma linha no plano, caso não estivesse, nunca precisei dele.

Depois do deploy, a parte interessante de novo foi o robots.txt. A descrição do próprio issue dizia que a Cloudflare prefixa comentários próprios de content-signals em qualquer coisa que você sirva pela origem. Fui conferir em vez de aceitar isso como dado:

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

Nenhum comentário prefixado. Só o nosso arquivo, palavra por palavra, com a linha Sitemap e tudo. A suposição no ticket não se confirmou, mas o resultado, uma diretiva Sitemap funcionando, sim. Vale lembrar da próxima vez que eu mexer nesse arquivo: qualquer que seja o comportamento de “prefixar” que existe, ele não aparece numa requisição que já tem um robots.txt de origem para servir.