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.

Um exemplo concreto: descobrimos que todos os posts do blog tinham a data exibida com um dia a menos, porque o Intl.DateTimeFormat usava o fuso do servidor em vez de UTC. O article:published_time no JSON-LD também era afetado — o Google lia uma data diferente da intencionada. Detalhamos a correção completa em Datas do blog com um dia a menos: o bug de timezone que afeta todo site Astro.

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.

Depois que o app entra na loja

O AAB pode ser aprovado enquanto o site de marketing ainda está preso no pré-lançamento.

Foi isso que aconteceu com o Daily Sudoku em 2026-07-10. A ficha na Play já estava ao vivo em https://play.google.com/store/apps/details?id=com.sunstoneapps.dailysudoku, mas daily-sudoku.sunstoneapps.com ainda dizia “em breve nas lojas” e não tinha link de download. sunstoneapps.com ainda descrevia o app como “em testes”. O Search Console já rastreava a landing; o HTML estava correto no papel. O problema era mais simples: quem chegava numa página indexável ainda não ia parar na loja.

Corrigimos primeiro as superfícies que estavam mentindo: badge na landing do Sudoku, kickers na home do estúdio, e plano vivo mais docs de listing para bater com a URL pública e o versionCode=9 publicado de fato. Depois rodamos build de produção de novo e checamos sitemap e metadados, porque mudança de CTA também é artefato de deploy.

Se você tirou noindex no pré-lançamento, o trabalho pós-lançamento não é caçar outra meta tag. É fazer a URL indexada converter. Quando a página para de prometer uma data futura e passa a apontar para uma ficha ao vivo, peça uma nova inspeção de URL no Search Console.

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.

O que aconteceu duas semanas depois: o diagnóstico real

O sitemap foi processado. As páginas eram rastreáveis. Duas semanas depois, o Search Console contou uma história diferente.

O domínio sunstoneapps.com tinha 31 URLs conhecidas. Apenas 6 estavam indexadas. 22 estavam “detectadas — não indexadas no momento”. 3 tinham redirecionamento. Zero cliques em três meses. 185 impressões, todas na página 3 do Google (posição média 26,6). Sem backlinks. Sem dados de Core Web Vitals — não porque o site era lento, mas porque não havia tráfego Chrome suficiente para medir.

As queries que chegavam ao site eram sobre “google play console” e “android developer account” — o blog estava sendo encontrado por termos adjacentes, não pelo estúdio ou pelos apps. As landings do Daily Sudoku e Word Search eram invisíveis.

Essa é a parte que checklists de indexação não preparam: o site está tecnicamente correto, e o Google ainda diz não.

Por que o Google recusou 22 páginas

O sitemap tinha 50 URLs. O Google indexou só 6. Os dois motivos de recusa foram:

• Detectada, mas não indexada no momento (22 páginas): o Google encontrou as URLs mas decidiu não indexá-las. Isso geralmente significa que o domínio tem baixa autoridade, conteúdo fino ou sinais externos insuficientes. As páginas incluíam boilerplate legal (política de privacidade, termos de uso, exclusão de dados) em dois idiomas — exatamente o tipo de conteúdo duplicado e de baixo valor que o Google descarta.
• Página com redirecionamento (3 páginas): URLs que redirecionam em vez de responder um 200 limpo. Isso desperdiça crawl budget.

A cadeia técnica estava intacta. O problema era autoridade do domínio e sinais de qualidade de conteúdo, não rastreabilidade.

O que mudamos

As correções não eram sobre tornar o site rastreável — ele já era. Eram sobre enviar melhores sinais de qualidade:

1. Páginas legais marcadas como noindex e removidas do sitemap. Seis páginas boilerplate (privacidade, termos, exclusão de dados em dois idiomas) estavam consumindo crawl budget e aparecendo como “não indexadas” no Search Console. Marcar como noindex e filtrar do sitemap liberou a atenção do Google para páginas que importam.
2. Structured data adicionada. A landing agora emite SoftwareApplication JSON-LD com a URL do Google Play, para o Google entender que o site descreve um app real publicado. O índice do blog emite Blog JSON-LD com todos os posts listados como BlogPosting, mais BreadcrumbList.
3. robots meta com max-image-preview:large. Toda página indexável agora diz ao Google que pode usar previews grandes de imagem nos resultados de busca, melhorando a riqueza dos snippets.
4. Links internos entre posts do blog. Cinco posts que formam uma sequência natural (setup da conta → build do AAB → checklist de teste interno → validação de compra → fix de splash screen) agora linkam entre si no corpo do texto, não só na sidebar.
5. OG images regeradas. Dois posts recentes não tinham eyebrow no frontmatter, que o gerador de OG image exige. Campo adicionado e imagens regeradas.
6. Meta title e description melhorados. O title da home passou de “Sunstone Apps” para “Sunstone Apps — Mobile Puzzle Games” — uma mudança pequena que dá ao Google um sinal de relevância mais forte para buscas de marca e categoria.
7. Sitemap adicionado ao site do Word Search. Simplesmente não tinha. Agora tem, com páginas legais filtradas.

O que ainda precisa acontecer fora do código

Essas são as coisas que nenhuma mudança de código resolve:

• Requests de indexação manual via Inspeção de URL no Search Console para as páginas mais importantes.
• Backlinks. O domínio tem zero backlinks conhecidos. Submeter a diretórios, escrever posts guest e ser listado em sites de review de apps daria ao Google o sinal de autoridade que falta para justificar a indexação de mais páginas.
• Tráfego real para gerar dados de Core Web Vitals. Sem usuários Chrome visitando o site, o Google não tem sinal de experiência para avaliar.
• Conteúdo evergreen que mire intenção de busca além do blog de dev: “Como jogar Sudoku para iniciantes”, “Por que Sudoku offline é útil para prática diária”.

A lição é que “o site é rastreável” é necessário mas não suficiente. O Google indexa páginas quando acredita que elas merecem ser indexadas. Correção técnica leva até a linha de largada. Autoridade e qualidade de conteúdo colocam no índice.