O pacote que eu quase usei, e por que o container de build efêmero disse não

O Bing Webmaster Tools quer que o IndexNow esteja configurado: um protocolo pequeno em que você faz um ping para um endpoint e Bing, Yandex, Seznam e Naver descobrem todos que uma página mudou, em vez de esperar cada um deles rastrear o site até chegar lá eventualmente. O protocolo em si é quase ridiculamente simples: hospedar um arquivo de texto com uma chave aleatória, fazer um POST de uma lista de URLs para algum lugar, pronto. A parte interessante dessa issue não foi o protocolo. Foi descobrir o que “algum lugar” e “quando” realmente significam para um site que faz deploy do jeito que esse aqui faz.

A resposta óbvia quase foi a errada

Existe um pacote Astro real e mantido para isso, o astro-indexnow. Astro 4 a 7, licença MIT, faz exatamente o que a issue pedia: gera hash das páginas geradas no build, e só reenvia as que mudaram desde a última vez. Entrei nisso já assumindo que ia instalar, configurar uma chave, e fechar a issue em dez minutos.

Aí li como ele rastreia “mudou desde a última vez”: ele gera hash de cada arquivo HTML do build num cache em JSON, e para comparar com o build anterior, esse arquivo de cache precisa ser commitado de volta no repositório depois de cada build. A documentação deles diz isso sem rodeios, é feito para setups de CI/CD que conseguem adicionar um passo de “commitar o arquivo de cache” depois do build.

Este site faz deploy através do Cloudflare Workers Builds: push para main, o Cloudflare sobe um container descartável, builda, faz o deploy, e o container desaparece. Não existe nenhum passo em que algo é escrito de volta no repositório, por design, é um cano de mão única. O pacote assume um formato de CI/CD que esse deploy não tem. Não é um bug do pacote, só uma incompatibilidade que eu não teria percebido sem realmente ler além das instruções de instalação.

O que eu construí em vez disso

A própria documentação do IndexNow diz que reenviar URLs que não mudaram não custa nada, não existe penalidade, nenhuma armadilha de rate limit por ser “desperdiçado”. Então, para um site com cerca de 26 páginas, comparar diferenças estava resolvendo um problema que eu não tinha. Deixei o cache de lado por completo e simplesmente reenvio tudo, a cada deploy.

Isso virou uma pequena integração Astro em vez de uma dependência. O Astro entrega para toda integração um array pages no hook astro:build:done, literalmente toda rota pré-renderizada, já sem duplicatas, sem precisar varrer HTML nem parsear sitemap. Li o código-fonte real do hook em node_modules em vez de confiar no que eu lembrava sobre a API, já que “eu lembro que funciona tipo X” é exatamente o tipo de suposição que custa uma hora depois. Quarenta linhas, zero dependências novas, uma chamada fetch.

A parte que precisou de uma segunda consulta

Sem uma proteção, essa integração dispararia em todo build: nas minhas iterações locais de npm run dev, e no gatilho separado de preview-branch que este repositório usa para pushes que não são para main. Os dois felizmente enviariam as URLs do domínio de produção para um índice de busca real, repetidamente, sem motivo nenhum.

O Cloudflare Workers Builds injeta WORKERS_CI_BRANCH no ambiente de build, eu nunca tinha usado isso antes, tive que ir buscar na própria documentação do Cloudflare. Com uma checagem === 'main', a integração fica silenciosa em todo lugar, exceto no build de produção de verdade.

Provando antes que desse para provar de verdade

O arquivo de chave ainda não estava no ar, ele vai junto nesse mesmo commit, então eu não conseguia obter um verdadeiro “sim, o IndexNow aceitou isso” antes do merge. O que eu conseguia fazer: forçar WORKERS_CI_BRANCH=main localmente e deixar a integração fazer uma chamada de rede real para a API real. Voltou 202 Accepted, não o 403 que eu esperava para uma chave não verificável. Acontece que o IndexNow enfileira os envios para verificação assíncrona da chave em vez de rejeitá-los na hora, então um 202 antes do deploy diz que o formato da requisição está correto, e você descobre com certeza depois do deploy. Bom o suficiente para lançar com um follow-up documentado em vez de travar por causa disso.