Checklist de indexação no Google para sites Astro no Cloudflare Pages

A parte irritante da indexação no Google é que um deploy bem-sucedido não compra lugar no índice.

Você consegue facilitar o rastreamento. Dá para publicar sitemap, manter robots.txt aberto e entregar canonicals limpos. Depois disso, ainda precisa conferir o que o Google fez. “O sitemap existe” e “a URL está indexada” são fatos diferentes.

Passamos por isso ao revisar os sites da Sunstone Apps, feitos com Astro e publicados no Cloudflare Pages. O build local passava. Os arquivos públicos respondiam. Os metadados pareciam razoáveis no código. Nada disso respondia a pergunta que importava: quais URLs o Google aceitou?

O trabalho útil não foi adicionar mais código de SEO. Foi percorrer a cadeia entre arquivos gerados e evidência no Search Console.

Comece pela saída de produção

Em um site estático Astro, comece pelo build de produção. O código-fonte pode parecer certo enquanto o HTML gerado conta outra história.

Os artefatos mínimos para verificar são:

• robots.txt existe e não bloqueia páginas importantes.
• sitemap-index.xml ou sitemap.xml é gerado e está acessível.
• Canonical aponta para o domínio de produção.
• hreflang aponta para as variantes de idioma esperadas.
• Páginas importantes não renderizam noindex.
• OpenGraph e JSON-LD estão presentes quando o site espera esses metadados.

Neste projeto, BaseLayout e os helpers compartilhados de SEO geram canonical, hreflang, OpenGraph, Twitter cards e JSON-LD. Essa camada compartilhada vale a pena porque o site institucional e as landing pages dos apps não devem inventar regras de SEO separadas.

Mas código compartilhado não é prova. Sitemap, assets estáticos, rotas geradas e configuração de deploy acontecem fora do componente que você está olhando. O site gerado é o que o Google enxerga.

Confira a web pública, não só o build

Depois do build, confira as URLs publicadas pela internet pública:

curl -L -sS -o /dev/null -w 'status=%{http_code} content_type=%{content_type}\n' \
  https://example.com/sitemap-index.xml

Esse pedido simples encontra problemas que inspeção de código não mostra:

• DNS ausente para um subdomínio.
• Cloudflare Pages servindo um build antigo.
• robots.txt apontando para o sitemap errado.
• Sitemap existente localmente, mas ausente no deploy.

Na nossa verificação, sunstoneapps.com e daily-sudoku.sunstoneapps.com serviam seus sitemaps com HTTP 200. O subdomínio word-search.sunstoneapps.com não resolvia publicamente, então o Google não conseguiria rastreá-lo. O build local também renderizava noindex porque o produto ainda estava em pré-lançamento.

Isso estava correto para um produto que ainda não deveria receber tráfego orgânico. O mesmo estado seria bug de lançamento para um produto público. Por isso o checklist precisa entender intenção, não só devolver verde ou vermelho.

Verifique o domínio no Search Console

Para um domínio com subdomínios, use uma propriedade de domínio no Google Search Console, a menos que exista motivo para não usar. Ela é mais limpa do que manter uma propriedade de prefixo de URL para cada site.

Uma propriedade de domínio para sunstoneapps.com cobre:

• https://sunstoneapps.com/
• https://daily-sudoku.sunstoneapps.com/
• subdomínios futuros abaixo do mesmo domínio verificado

O Search Console exige verificação por DNS para propriedades de domínio. O fluxo Domain Connect do Cloudflare pode adicionar o registro TXT automaticamente:

google-site-verification=...

A regra prática é simples: mantenha esse TXT no DNS. Ele não é sobra de lançamento. Removê-lo pode quebrar a verificação de propriedade depois, geralmente no pior momento.

Envie o sitemap e leia a tabela com cuidado

Enviar o sitemap é só o recibo. A tabela do Search Console ainda precisa ser interpretada.

Com a integração de sitemap do Astro, o Search Console pode mostrar:

• sitemap-index.xml
• sitemap-0.xml

O índice pode aparecer como processado e, ainda assim, mostrar 0 páginas encontradas, porque as URLs reais ficam no sitemap filho. É o sitemap filho que deve mostrar a contagem de páginas.

No nosso caso:

• https://sunstoneapps.com/sitemap-0.xml foi processado com 20 páginas encontradas.
• https://daily-sudoku.sunstoneapps.com/sitemap-0.xml foi processado com 8 páginas encontradas.
• Os dois sitemap-index.xml foram processados, mas mostraram 0 páginas diretamente.

Isso não é falha. Significa que o arquivo de índice foi lido, enquanto a contagem de páginas pertence ao sitemap filho.

Também apareceu um estado confuso: o Search Console primeiro disse que não conseguiu buscar o sitemap do Sudoku, mesmo com a mesma URL retornando HTTP 200 publicamente. Depois de atualizar a tela, o Google processou o arquivo.

Esse é o tipo de resultado que pede calma. Se a URL pública falha, corrija o site. Se a URL pública funciona e o Search Console teve uma leitura antiga, atualize e verifique de novo antes de mexer no código.

Inspecione as URLs importantes

A prova rápida mais forte é a Inspeção de URL. Ela olha uma URL por vez, e é exatamente por isso que ajuda.

Para cada página importante, o Search Console responde:

• A URL é conhecida pelo Google?
• A página está indexada?
• Ela foi servida por HTTPS?
• O canonical é aceitável?
• Dá para solicitar indexação?

Para os sites da Sunstone, as URLs importantes eram:

• https://sunstoneapps.com/
• https://sunstoneapps.com/pt-BR/
• https://daily-sudoku.sunstoneapps.com/
• https://daily-sudoku.sunstoneapps.com/pt-BR/

As quatro já estavam no Google e marcadas como indexadas. Isso valia mais do que uma busca genérica com site:. O operador site: serve para uma checagem rápida, mas pode atrasar, omitir URLs e criar alarme falso.

Quando o Search Console diz detectada, mas não indexada

Detectada, mas não indexada no momento não significa automaticamente que a página está quebrada. Muitas vezes quer dizer que o Google conhece a URL pelo sitemap ou por outro sinal, mas ainda não fez o rastreamento. O campo Último rastreamento dá a pista. Se ele mostra N/D, talvez o problema seja fila, não renderização.

Em uma revisão posterior, sunstoneapps.com já tinha as homes indexadas, mas várias URLs de blog e páginas legais ainda estavam nesse estado. O HTML gerado estava correto: requisições públicas voltavam HTTP 200, robots.txt permitia rastreamento, canonical apontava para a URL final, os alternates hreflang existiam e não havia noindex. A peça que faltava não era outra meta tag. Era descoberta interna mais forte.

A correção prática foi criar links úteis a partir de páginas que o Google já confiava. A home institucional agora renderiza os quatro posts mais recentes em cada idioma. A landing do Daily Sudoku passou a linkar diretamente a página de exclusão de dados no menu e no rodapé. Esses links ajudam leitores e dão aos crawlers um caminho que não depende só do sitemap.

O acompanhamento no Search Console ficou seletivo:

• teste primeiro a URL publicada;
• solicite indexação só quando o teste ao vivo disser que a página pode ser indexada;
• priorize hubs e páginas legais em vez de enviar todos os posts um por um;
• não reenvie a mesma URL várias vezes, porque isso não muda a posição dela na fila.

Essa contenção importa. Se o teste ao vivo falha, corrija o site. Se o teste passa e a página só está aguardando, melhore a descoberta interna e dê tempo para o Google rastrear de novo.

O checklist que eu reutilizaria

Antes de chamar um site estático pequeno de indexável, eu verificaria esta cadeia:

• Build de produção passa.
• robots.txt está público e aponta para o sitemap correto.
• Sitemaps diretos retornam HTTP 200.
• Canonical e hreflang batem com as URLs de produção.
• Páginas importantes não têm noindex.
• Propriedade de domínio está verificada no Search Console.
• Sitemaps filhos diretos foram enviados e processados.
• Search Console encontrou a contagem de páginas nos sitemaps filhos.
• Páginas principais passam na Inspeção de URL.
• Subdomínios em pré-lançamento ficam intencionalmente sem DNS, com noindex, ou ambos.

Esse último ponto é fácil de esquecer. Um produto que não está pronto não deve vazar para a busca. Um produto que está pronto não deve sair com freios de pré-lançamento ainda ligados.

Valide o site gerado, não só o código-fonte

Astro facilita raciocinar sobre componentes. O Google não indexa componentes. Ele indexa a saída que o Cloudflare Pages serve: HTML, sitemap, robots, canonical, alternates hreflang, tags OpenGraph e JSON-LD.

Um componente pode parecer correto enquanto a página final ainda tem canonical errado, alternate localizado ausente, conteúdo draft no sitemap ou imagem OG velha. A saída de build é a fonte de verdade para buscadores.

O que checar depois de cada mudança de conteúdo

Para um site estático pequeno, o checklist depois de cada mudança pode continuar curto:

• rodar build de produção;
• confirmar que a rota existe no idioma esperado;
• inspecionar canonical e links hreflang;
• confirmar se a página entra ou não no sitemap como esperado;
• verificar og:type, título, descrição e imagem;
• checar o tipo de JSON-LD para a categoria da página.

Esses checks importam mais em sites bilíngues. Um par em português ausente ou uma rota errada no idioma padrão pode dividir sinais entre URLs sem quebrar a página de um jeito que o desenvolvedor perceba.

Cloudflare Pages é rápido, mas cache ainda existe

Cloudflare Pages publica saída estática rapidamente, mas assets antigos e previews sociais podem ficar em caches fora do repositório e fora da Cloudflare. Nomes de imagens OG, caminhos gerados e consistência de metadados importam porque busca e redes sociais podem continuar usando um preview antigo depois que a página mudou.

Trate o build como artefato publicável, não como efeito colateral do código. Se o artefato contém o HTML e os assets certos, o deploy fica muito menos misterioso.

Atualidade de conteúdo precisa de estrutura

Publicar mais páginas não é automaticamente melhor. Um site pequeno se beneficia de uma estrutura clara de conteúdo: pares bilíngues, slugs estáveis, datas consistentes e links internos entre posts relacionados. Leitores precisam dessa estrutura. Crawlers também.

Para blogs técnicos, atualidade deve vir de trabalho que aconteceu de verdade. Um post escrito depois de resolver um problema de release, indexação, billing ou React Native costuma ser mais forte que um artigo genérico de palavra-chave porque carrega os detalhes feios: a suposição errada, a checagem que falhou, o sistema externo que atrasou, a coisa que parecia quebrada mas não estava.

Uma regra simples ajuda: se uma página deve ser indexada, ela merece uma checagem de build de produção antes do trabalho ser encerrado.

Em sites bilíngues, também confira se as duas versões de idioma entraram na mesma mudança. Publicar só um idioma deixa o índice com sinais desiguais e torna a tradução posterior mais difícil de rastrear.

Conclusão

Indexação é uma cadeia, não um interruptor:

DNS resolve -> página responde -> robots permite -> metadados estão válidos -> sitemap é processado -> URL é indexada

Cada etapa precisa de uma evidência diferente. Astro prova que os arquivos podem ser gerados. Cloudflare prova que eles podem ser servidos. Search Console é onde você confirma se o Google aceitou.

O hábito útil não é “enviar sitemap e torcer”. É checar a cadeia até as URLs importantes dizerem o que você realmente precisa: a página está indexada.