SEO no Astro passo a passo: renderização estática ou no servidor, tags head, sitemap, hreflang, imagens, JSON-LD e redirecionamentos, checados na documentação.

Nesta página
Em resumo
o Astro é um dos frameworks web mais favoráveis ao SEO porque pré-renderiza as páginas em HTML puro e não envia JavaScript ao navegador, a menos que você peça. O Google e os rastreadores das IA recebem o conteúdo completo já na primeira requisição. Mesmo assim, o Astro não faz o SEO por você: títulos, meta descriptions, canônicas, hreflang, dados estruturados e redirecionamentos ficam por sua conta, principalmente num componente head compartilhado e com a integração oficial de sitemap.
Quer ir mais longe? Pergunte ao
Quiz rápido
O SEO é para você, e como começar?
O Sorank combina com suas respostas
Teste por 3 dias no seu próprio site e veja onde você está no Google, no ChatGPT e nas outras IAs.
Teste grátis de 3 dias3 dias grátis, depois você para quando quiser. Garantia de resultados ou reembolso de 90 dias.
SEO no Astro é o trabalho de transformar esse HTML limpo em páginas que se posicionam. O guia do Google sobre os princípios básicos de SEO para JavaScript explica que sites JavaScript são processados em três fases (rastreamento, renderização, indexação) e afirma que a renderização no servidor ou a pré-renderização continua sendo uma ótima ideia, porque nem todos os bots executam JavaScript. O Astro já parte dessa posição. Este guia cobre o resto, configuração por configuração, com cada comportamento conferido na documentação oficial do Astro. A propósito, o site sorank.com que você está lendo roda em Astro.
Sim, no aspecto técnico. O Astro renderiza os componentes em HTML durante o build e remove o JavaScript que frameworks como React ou Vue normalmente enviariam ao navegador. Assim evita os problemas clássicos descritos no nosso guia de SEO para JavaScript: cascas HTML vazias, conteúdo que só aparece depois da renderização, links que não são tags de âncora reais. Também evita as armadilhas de roteamento de uma aplicação de página única, já que cada rota do Astro é uma URL real com seu próprio arquivo HTML.
O que o Astro não faz importa tanto quanto. Não há plugin de SEO integrado, nem meta description automática, nem tag canônica automática, nem dados estruturados. A tabela separa o que você ganha de graça do que precisa construir.
| Elemento de SEO | O que o Astro oferece | O que você adiciona |
|---|---|---|
| HTML rastreável | HTML pré-renderizado por padrão | Nada, a menos que renderize conteúdo só no cliente |
| Título e meta description | Um head que você controla em cada layout | Um componente de SEO compartilhado alimentado por cada página |
| Tag canônica | Astro.site e Astro.url para montar URLs absolutas | A própria tag link, com barra final consistente |
| Sitemap XML | A integração oficial @astrojs/sitemap | Instalar, definir a opção site, filtrar páginas privadas |
| hreflang | Roteamento i18n e uma opção i18n do sitemap | Links alternativos no head de cada página |
| Imagens | Componentes Image e Picture que otimizam os arquivos | Textos alternativos descritivos, tamanhos adequados |
| Dados estruturados | Nada específico | Scripts JSON-LD por tipo de página |
| Redirecionamentos | Uma opção redirects na configuração | 301 reais na hospedagem para sites estáticos |
A documentação do Astro sobre renderização sob demanda é clara: por padrão, páginas, rotas e endpoints de API são pré-renderizados no build como páginas estáticas. Para SEO, a saída estática é a escolha mais segura: cada URL é um arquivo HTML pronto, servido por uma CDN, rápido e idêntico para cada visitante e cada bot.
A renderização sob demanda (no servidor) exige um adaptador para a sua hospedagem (Node, Netlify, Vercel ou Cloudflare, por exemplo). Depois você tira uma rota específica da pré-renderização com export const prerender = false, ou muda o projeto inteiro com output: 'server' e reativa as páginas estáticas uma a uma. Os dois modos produzem HTML completo, então o Google vê a mesma coisa. As diferenças estão em outro lugar:
A regra prática: mantenha estáticas as páginas comerciais, os artigos do blog e a documentação, e renderize sob demanda só as rotas que precisam de dados ao vivo. A documentação do Astro recomenda o mesmo: manter o modo estático padrão até que a maioria das páginas precise de renderização sob demanda.
Crie um único componente de SEO (muitas vezes chamado BaseHead ou Seo) e inclua-o no head de cada layout. Ele recebe um título, uma descrição, uma imagem opcional e um indicador noindex opcional, e gera:
Defina primeiro a opção site em astro.config.mjs: a canônica, o sitemap e as tags sociais dependem dela. Depois escolha uma regra trailingSlash ('always' ou 'never') e siga-a, para que /blog/artigo e /blog/artigo/ nunca concorram como duas versões da mesma página. Tire os parâmetros de consulta da canônica para que parâmetros de rastreamento de campanhas não criem duplicatas.
Dica
Se os seus artigos ficam em content collections, torne título e descrição campos obrigatórios no schema da coleção. O build falha quando um autor esquece a meta description, em vez de mandar um snippet vazio para o Google.
Use a integração oficial documentada na página do @astrojs/sitemap. O comando npx astro add sitemap instala a integração e a adiciona à configuração. Ela exige a opção site e, no build, grava um arquivo sitemap-index.xml que aponta para arquivos numerados (sitemap-0.xml e outros em sites grandes). Cada arquivo comporta até 45.000 entradas por padrão, valor definido pela opção entryLimit. Se o formato for novo para você, nosso verbete do glossário sobre o sitemap XML explica o que o Google faz com ele.
Três configurações importam para o SEO:
Atenção
A documentação informa que a integração não consegue gerar entradas de sitemap para rotas dinâmicas no modo SSR. Se as suas páginas de produto ou de artigo forem renderizadas sob demanda, vão faltar no sitemap, a menos que você as pré-renderize ou as adicione manualmente.
Para o robots.txt, um arquivo estático na pasta public basta na maioria dos sites. Se o conteúdo muda entre homologação e produção, gere-o a partir de um endpoint (src/pages/robots.txt.ts). Nos dois casos, inclua uma linha Sitemap apontando para sitemap-index.xml e teste o resultado com um verificador de robots.txt antes do lançamento. A mesma técnica gera um arquivo llms.txt; nosso guia para instalar um arquivo llms.txt detalha o conteúdo.
O roteamento i18n integrado do Astro cuida da parte das URLs. Na configuração você declara uma defaultLocale e uma lista de locales, e escolhe se o idioma padrão também recebe prefixo (prefixDefaultLocale). Funções como getRelativeLocaleUrl montam links localizados, e Astro.currentLocale informa a cada página em que idioma ela está.
O guia de roteamento não trata das tags hreflang no head, então planeje escrevê-las você mesmo no componente de SEO: para cada página, um link alternativo por versão de idioma mais um x-default, tudo em URLs absolutas, e cada versão deve listar todas as outras (links de retorno). Gerá-las a partir da mesma lista de idiomas do roteamento evita o erro mais comum, uma alternativa apontando para uma página que não existe. Para conferir a lógica em algumas URLs, nosso gerador de hreflang produz o conjunto completo de tags de uma página. Depois ative a opção i18n do sitemap como segundo sinal.
A velocidade é onde o Astro mais ganha terreno, e isso aparece nas Core Web Vitals. O guia de imagens do Astro descreve o componente Image do astro:assets: ele otimiza imagens locais, converte o formato, adiciona carregamento lento e decodificação assíncrona e deduz as dimensões da imagem para evitar o Cumulative Layout Shift. O atributo alt é obrigatório nele, o que impõe uma regra básica de SEO de imagens. O componente Picture vai além e serve AVIF ou WebP com um fallback.
Dois hábitos completam o quadro. Guarde em src as imagens que precisam de otimização (os arquivos de public são servidos como estão, sem processamento). E não adie o carregamento da imagem principal no topo da página: carregue-a de imediato para não atrasar o Largest Contentful Paint.
A arquitetura de ilhas mantém o JavaScript sob controle. Um componente é HTML estático até você adicionar uma diretiva de cliente: client:load o hidrata na hora, client:idle quando o navegador fica livre, client:visible só quando ele entra na área visível. Reservar client:load ao que precisa reagir de imediato (um menu, um carrinho) é o jeito mais simples de proteger o Interaction to Next Paint. As ilhas de servidor (server:defer) carregam um bloco personalizado depois da página em cache, sem atrasar o conteúdo principal.
Nota
Uma ilha só atrasa a sua interatividade, não o seu texto, desde que o componente seja renderizado primeiro no servidor. Conteúdo carregado depois no navegador é outro caso: rastreadores que não executam JavaScript, entre eles muitos rastreadores de IA, não vão vê-lo.
O Astro não tem um recurso de schema, o que deixa você com controle total. Monte um objeto JavaScript por tipo de página (Article, Product, Organization, BreadcrumbList, FAQPage) e coloque-o numa tag script do tipo application/ld+json, com a diretiva set:html e JSON.stringify para que o JSON não seja escapado. Alimente-o com os mesmos dados de frontmatter ou de coleção da página visível: assim a marcação sempre corresponde ao que os usuários veem, uma exigência das diretrizes do Google sobre marcação schema.
Para redigir o JSON de um novo tipo de página, nosso gerador de schema gratuito oferece um bloco inicial válido, que você transforma em modelo. Valide uma amostra de páginas geradas com o teste de pesquisa aprimorada do Google após cada mudança no modelo.
Migrações a partir de WordPress ou Next.js são o momento mais arriscado para um site Astro. Mantenha cada URL com tráfego ou backlinks e associe as demais, uma a uma, ao equivalente mais próximo com redirecionamentos permanentes, como explica nosso guia de redirecionamentos para SEO.
A configuração do Astro aceita um objeto redirects que associa caminhos antigos a novos. Com um adaptador, eles viram redirecionamentos HTTP de verdade. Num build puramente estático, o Astro grava no lugar uma página HTML com meta refresh, que o Google segue mas trata como sinal mais fraco que um 301 no servidor. Para um site estático, declare os redirecionamentos no formato da sua hospedagem (um arquivo _redirects na Netlify ou no Cloudflare Pages, um arquivo vercel.json na Vercel) para que os rastreadores recebam um 301 real.
Ser citado pelo ChatGPT, Perplexity ou Gemini começa por ser legível. Muitos rastreadores de IA baixam o HTML bruto sem executar JavaScript, então um site que entrega todo o texto na primeira resposta, como o Astro faz por padrão, remove uma barreira que os sites renderizados no cliente ainda têm. Intertítulos claros, parágrafos que respondem logo de cara, dados estruturados e um arquivo llms.txt tornam cada página mais fácil de citar.
Depois do lançamento, meça em vez de adivinhar. O painel GEO e SEO da Sorank reúne seus dados do Search Console e suas visitas vindas de assistentes de IA, para você ver se o novo site mantém as posições.

A qualidade técnica só rende com conteúdo para posicionar. O gerador de artigos de blog com IA da Sorank escreve e publica artigos otimizados para o Google e para as IA, e se conecta por webhook a um site sob medida, como um projeto Astro.
O Astro entrega por padrão um HTML rápido e rastreável; o posicionamento continua dependendo das tags head, do sitemap, do hreflang, dos dados estruturados e dos redirecionamentos que você adiciona. Configure primeiro o componente de SEO compartilhado e o sitemap, e depois percorra a tabela acima antes do lançamento.
Não. O Astro não tem um plugin de SEO oficial tudo em um: título, meta description, canônica e tags sociais são escritos num componente head compartilhado. A integração oficial @astrojs/sitemap cuida do sitemap. Existem pacotes da comunidade, mas um pequeno componente próprio é fácil de manter e fica totalmente sob o seu controle.
Os dois podem gerar HTML totalmente renderizado, então o Google indexa bem qualquer um deles. O Astro envia bem menos JavaScript por padrão, o que costuma deixar sites de conteúdo mais rápidos e ajuda nas Core Web Vitals. O Next.js combina mais com aplicações muito interativas; para blogs, sites institucionais e documentação, o Astro é a escolha mais simples para SEO.
Sim. Uma página renderizada sob demanda também devolve HTML completo ao Googlebot, exatamente como uma página pré-renderizada. Os pontos de atenção são o tempo de resposta do servidor, que afeta a velocidade de carregamento, e a integração de sitemap, que não lista rotas dinâmicas no modo servidor a menos que você as adicione.
ELES EXPERIMENTARAM O SORANK ANTES DE VOCÊ
