Como traduzir um site Astro: roteamento i18n e SEO

A arquitetura do Astro, que prioriza conteúdo estático, é ideal para sites de marketing multilíngues — desde que as equipes tratem o roteamento i18n, as coleções de conteúdo e as anotações de SEO como tarefas essenciais de engenharia. É comum que desenvolvedores Astro publiquem pastas de localidade bem organizadas e só depois descubram que falta hreflang, que os elementos da interface continuam em inglês ou que as ilhas híbridas renderizam textos não traduzidos no lado do cliente.

Este guia explica como traduzir um site Astro com HTML rastreável por localidade, coleções de conteúdo organizadas, layout e tags de SEO localizados, sitemaps preparados para hreflang, cuidados com a renderização híbrida e fluxos editoriais para Markdown e MDX — tudo com base nos requisitos do Google para sites multilíngues. Sem fatores de ranqueamento inventados.

Perguntas que este guia responde

• Como o roteamento i18n do Astro permite versões por localidade rastreáveis?
• Como organizar as coleções de conteúdo por idioma?
• Como localizar os elementos da interface do layout e as tags de SEO no Astro?
• Como gerar hreflang para a saída estática do Astro?
• Quando a renderização híbrida é necessária em sites Astro multilíngues?
• Como integrar o fluxo de tradução ao conteúdo em Markdown/MDX?
• Quais são os erros mais comuns em sites Astro multilíngues?
• Quando as equipes que usam Astro devem adotar uma plataforma de tradução?

Resposta rápida: o HTML estático por localidade é a vantagem do Astro em SEO

Resposta curta: use o roteamento i18n do Astro para pré-renderizar URLs distintas por localidade com HTML totalmente localizado — incluindo navegação, metadados e conteúdo principal — e depois adicione hreflang recíproco entre as versões alternativas.

O HTML pré-renderizado para cada URL de localidade está alinhado à preferência do Google por versões de idioma rastreáveis com URLs distintas. O Astro pode gerar arquivos estáticos por localidade durante o build, oferecendo aos rastreadores o mesmo documento específico de idioma que os usuários recebem, sem depender de seletores de idioma no lado do cliente.

O Google recomenda URLs rastreáveis diferentes para cada versão de idioma, em vez de depender apenas de cookies ou do idioma do navegador. O roteamento astro:i18n do Astro (ou padrões equivalentes de prefixo de localidade) dá suporte a esse modelo quando você gera um caminho de saída por localidade.

Roteamento i18n do Astro e estrutura de URLs

Configure o Astro com localidades explícitas e uma localidade padrão. Padrões comuns de URL:

• Incluir o prefixo da localidade padrão (/en/about, /fr/about) — explícito e fácil de anotar.
• Ocultar a localidade padrão (/about para inglês, /fr/about para francês) — URLs mais limpas para o mercado principal; documente o mapeamento no hreflang.

Em astro.config.mjs, defina i18n.locales, i18n.defaultLocale e i18n.routing de acordo com sua matriz de localidades. Cada arquivo de rota deve receber a localidade ativa pelas APIs do Astro para que os templates renderizem o idioma correto.

O Google determina o idioma da página principalmente pelo conteúdo visível; as versões de idioma devem manter o conteúdo e a navegação predominantemente em um único idioma. Conecte os componentes de navegação a dicionários de tradução que considerem a localidade para que cabeçalhos e rodapés estejam no mesmo idioma do corpo da página.

Evite redirecionamentos automáticos com base em suposições sobre o idioma ou a localização. O Google desaconselha esses redirecionamentos e recomenda um seletor de idioma visível para o usuário, com links para as URLs alternativas.

Para entender a estratégia de segmentação por idioma em comparação com a segmentação por país, leia SEO internacional versus SEO multilíngue.

Coleções de conteúdo por localidade

As coleções de conteúdo do Astro dão suporte ao conteúdo de blogs, documentação e landing pages. Organize o conteúdo multilíngue de forma planejada:

• Diretórios de coleção separados por localidade (src/content/blog/en/, src/content/blog/fr/) com esquemas compartilhados.
• Campo de localidade no frontmatter para filtrar uma única coleção quando o volume de conteúdo for pequeno.
• Índices gerados ou vinculados por links simbólicos que listem apenas os itens disponíveis em cada localidade — evite publicar páginas vazias como placeholders de versões localizadas.

Cada documento localizado deve referenciar recursos e links internos adequados à localidade. Uma publicação em francês com link para um documento disponível apenas em inglês compromete a confiança do usuário e a consistência do idioma.

Quando não houver conteúdo equivalente em uma localidade, não crie alternativas hreflang fictícias — traduza a versão correspondente ou omita a relação até que ela esteja pronta.

Localização de layouts, SEO e Open Graph

Centralize os elementos da interface do layout em componentes que considerem a localidade:

• BaseLayout.astro lê Astro.currentLocale (ou sua função auxiliar de i18n) e seleciona os textos de dicionários JSON ou TS.
• <title> e a meta description vêm do frontmatter ou dos campos do CMS de cada página — não de textos em inglês fixos no código.
• As tags Open Graph e Twitter refletem o título e a descrição localizados.
• O atributo html lang corresponde à localidade ativa (para acessibilidade e clareza; o Google continua usando o conteúdo visível para detectar o idioma).

Os títulos de SEO e as meta descriptions localizados devem ser exclusivos para cada URL de localidade. Uma localização superficial, restrita aos elementos comuns da interface — com navegação traduzida e corpo dos artigos em inglês —, resulta em versões de idioma pouco consistentes.

Geração de hreflang e sitemaps

Os sites Astro também devem gerar hreflang recíproco (no HTML, nos cabeçalhos ou nos sitemaps) entre as URLs de localidade quando houver versões alternativas. Durante o build, gere uma matriz de localidades a partir do seu grafo de conteúdo:

1. Para cada página lógica, liste todas as URLs de localidade publicadas.
2. Inclua <link rel="alternate" hreflang="..." href="..." /> em <head> em cada arquivo HTML estático, ou
3. Gere um sitemap XML com alternativas xhtml:link para cada entrada de URL.

Os sitemaps XML ajudam na descoberta das versões de idioma e podem conter anotações hreflang com xhtml:link quando usados como método de implementação.

Cada URL de idioma deve ter uma URL canônica bem definida no mesmo idioma. As orientações do Google sobre URLs canônicas se aplicam tanto a sites estáticos quanto a dinâmicos.

Integre a geração de sitemaps à CI — @astrojs/sitemap com hooks de serialização personalizados funciona bem — para manter o hreflang sincronizado quando o conteúdo mudar.

Consulte fundamentos de SEO multilíngue para entender como as equipes editoriais gerenciam as anotações em conjunto com as entregas de engenharia.

Cuidados com ilhas híbridas e conteúdo dinâmico

A arquitetura de ilhas do Astro permite hidratar componentes React, Vue ou Svelte de forma seletiva. Cuidados em sites multilíngues:

• Widgets executados apenas no cliente podem exibir conteúdo em inglês até o JavaScript carregar — o que prejudica a detecção do idioma e a experiência do usuário.
• Renderize no servidor o HTML inicial da ilha na localidade correta sempre que possível.
• Rotas dinâmicas (output: 'server' ou hybrid) precisam receber a localidade via middleware para que o HTML gerado por SSR corresponda ao prefixo da URL.

Quando a renderização híbrida é necessária? Use renderização híbrida ou no servidor quando o conteúdo for personalizado, exigir autenticação ou for obtido no momento da requisição — mas ainda gere estruturas estáticas localizadas e rastreáveis para páginas de marketing que precisam aparecer nos resultados de busca. As versões localizadas de marketing devem usar geração estática por padrão; reserve a renderização dinâmica para as seções autenticadas do aplicativo.

Fluxo editorial para conteúdo em MDX e CMS

Para muitas equipes, Markdown e MDX continuam sendo a camada de conteúdo do Astro mais fácil de manter:

1. Textos de origem em arquivos de tradução (src/i18n/fr.json) para os elementos da interface.
2. Frontmatter em cada arquivo de localidade para conteúdo longo.
3. Pull requests por lote de localidade com verificações de glossário.
4. Exportação para ferramentas CAT ou TMS para grandes conjuntos de documentação — com reimportação para src/content.

As orientações do Google sobre conteúdo útil priorizam páginas voltadas às pessoas; publicar traduções puramente automáticas, sem revisão, gera experiências localizadas superficiais.

Defina critérios de aprovação para publicação: não permita o merge se faltarem campos obrigatórios da localidade, se os links internos levarem a outra localidade ou se os pares de hreflang verificados por amostragem não passarem nas verificações de reciprocidade.

Lista de verificação de implementação

• Configure as localidades do i18n do Astro e a estratégia de prefixos de roteamento
• Crie arquivos de layout e dicionário com suporte a localidades
• Organize coleções de conteúdo por localidade com esquemas compartilhados
• Localize o título, os metadados, as tags OG e html lang em cada template
• Crie uma matriz de localidades × URLs durante a compilação
• Gere anotações hreflang recíprocas no HTML ou no sitemap
• Defina URLs canônicas no mesmo idioma para cada página estática gerada
• Renderize as ilhas via SSR ou estaticamente na localidade ativa
• Adicione um seletor de idioma visível, sem redirecionamentos forçados
• Execute um rastreamento no ambiente de homologação após o lançamento de cada localidade

Erros comuns

1. Estrutura do layout apenas em inglês nas rotas localizadas.
2. Ausência de hreflang porque os caminhos estáticos eram mantidos manualmente.
3. Localidade padrão oculta sem documentar as alternativas — quebra de reciprocidade.
4. Seletor de idioma renderizado no cliente sem URLs distintas.
5. MDX com mistura de idiomas devido a merges de traduções parciais.
6. Publicação de versões localizadas incompletas com lorem ipsum ou textos provisórios em inglês.
7. Ausência de sitemap em grandes sites estáticos — descoberta mais lenta.
8. URL canônica apontando para outro idioma sem o devido cuidado.

As diretrizes do Bing para webmasters também enfatizam conteúdo útil e rastreável, além de uma estrutura de site clara para a indexação em diferentes mercados.

Fundamentos da busca tradicional e dos mecanismos de respostas

Os fundamentos comuns ao HTML estático localizado e às coleções de conteúdo do Astro continuam importantes para o Google, o Bing e os mecanismos de resposta: versões de idioma rastreáveis, entidades claras, afirmações sustentadas por evidências, dados estruturados que reflitam a realidade e localização de verdade — não apenas estruturas em inglês. Considere os guias abaixo como perspectivas específicas de cada plataforma sobre o mesmo padrão de qualidade na entrega multilíngue.

Guia da plataforma: Pesquisa Google

Na Pesquisa Google, a descoberta depende de URLs de idioma e região rastreáveis, com HTML adequado ao idioma, títulos e cabeçalhos precisos e hreflang recíproco quando houver versões alternativas. Os fundamentos técnicos incluem conteúdo indexável (não apenas seletores baseados em cookies), metadados localizados, sitemaps e rigor na canonicalização. Qualidade de conteúdo significa oferecer conteúdo principal feito para pessoas em cada idioma; a autoridade vem da identidade clara da organização e de fontes que confirmem as informações — não do marketing de ferramentas de tradução. Implicação multilíngue: cada URL de mercado ou idioma deve funcionar de forma independente. Meça os resultados com a cobertura do Search Console e a Inspeção de URL por idioma e região. O que se sabe e o que é incerto: o Google documenta o comportamento multilíngue e do hreflang; não garante posicionamentos com base em nenhum CMS ou fluxo de trabalho de MTPE.

Guia da plataforma: Bing

O Bing descobre e indexa páginas multilíngues rastreáveis com estrutura clara, de forma semelhante às expectativas do Google quanto à clareza de URLs e conteúdo. Os fundamentos técnicos incluem URLs de idioma e região que possam ser acessadas pelos rastreadores, conteúdo útil e monitoramento no Bing Webmaster Tools. Priorize a localização de cabeçalhos, afirmações e perguntas frequentes, em vez de traduzir apenas os elementos da interface. Os sinais de autoridade continuam dependendo de fontes confiáveis e entidades consistentes. Implicação para sites multilíngues: não esconda idiomas atrás de seletores que funcionam apenas no lado do cliente. Meça a indexação e as estatísticas de rastreamento no Bing Webmaster Tools. O que se sabe e o que é incerto: as diretrizes do Bing enfatizam conteúdo útil e rastreável; não invente fatores de classificação exclusivos do Bing para ferramentas de tradução.

Guia da plataforma: ChatGPT

O ChatGPT pode citar ou resumir páginas acessíveis publicamente quando as versões de idioma são claras e estão prontas para fornecer respostas. A descoberta não segue uma classificação convencional de busca por rastreamento; a visibilidade se manifesta na seleção como fonte ou na menção nas respostas. Os fundamentos técnicos ainda começam com URLs HTML acessíveis — não com sobreposições de widgets que ocultam o texto. Entre as qualidades de conteúdo que ajudam estão respostas diretas, perguntas frequentes e terminologia estável baseada em glossários. A autoridade vem de evidências e de entidades consistentes entre versões de idioma e região. Implicação multilíngue: cada página localizada deve ser compreensível por si só. A medição é imperfeita — trate as verificações de citações como hipóteses. O que se sabe e o que é incerto: não há garantia documentada de que a MTPE ou qualquer integração com um CMS gere citações no ChatGPT.

Guia da plataforma: Gemini

O Gemini e as experiências relacionadas de IA do Google se beneficiam de entidades coerentes, dados estruturados precisos e páginas localizadas indexáveis. A visibilidade está ligada a receber referências ou ser reconhecido — não a inventar fatores de classificação do Gemini. Os fundamentos técnicos coincidem com os da Pesquisa Google em relação à rastreabilidade e à qualidade dos metadados. O conteúdo deve apresentar afirmações e definições claras em cada idioma. A autoridade depende da consistência da organização e da confirmação das informações por outras fontes. Implicação para sites multilíngues: nomes de produtos padronizados por um glossário reduzem a confusão entre versões de idioma e região. Faça a medição tradicional pelo Search Console e avalie qualitativamente amostras de respostas da IA. O que se sabe e o que é incerto: o comportamento do Gemini não substitui as orientações documentadas da Pesquisa Google sobre hreflang e versões de idioma.

Guia da plataforma: Google AI Overviews

O Google AI Overviews pode incluir links para páginas de apoio; os critérios de elegibilidade continuam baseados em conteúdo indexável e voltado para as pessoas. Esse recurso não funciona como um seletor de idiomas nem substitui o hreflang. As bases técnicas continuam sendo HTML rastreável para cada localidade e dados estruturados fiéis ao conteúdo. Entre as qualidades do conteúdo estão respostas concisas e títulos claros em cada idioma. Os sinais de autoridade seguem as expectativas para conteúdo útil. Implicação para sites multilíngues: a inclusão no AI Overviews não é garantida para nenhuma página traduzida. Acompanhe os relatórios de recursos generativos no Search Console, quando disponíveis, e mantenha as métricas tradicionais de indexação separadas. O que se sabe e o que permanece incerto: nenhum fluxo de trabalho de tradução pode prometer presença no AI Overviews.

Onde a GlotEO se encaixa

Quando as equipes que usam Astro devem adotar uma plataforma de tradução? Quando a aplicação de glossários, as filas de revisão por localidade e as matrizes de hreflang ultrapassarem o que é possível gerenciar com pull requests manuais de JSON e MDX.

A engenharia pode entregar um roteamento i18n perfeito no Astro; ainda assim, a localização precisa de glossários, filas de revisão e rigor na publicação. Conheça a localização de sites da GlotEO para conectar briefings, fluxos de tradução e critérios de aprovação de qualidade aos pipelines de conteúdo de sites estáticos — mantendo as atualizações de MDX e dos dicionários alinhadas ao hreflang e aos metadados de SEO gerados pela compilação do Astro.

Compare os preços e planos da GlotEO quando o volume de tradução ultrapassar a capacidade de edição manual de JSON e use ferramentas para fluxos de trabalho de SEO multilíngue para manter as matrizes de localidades e os requisitos editoriais visíveis tanto para desenvolvedores quanto para equipes de conteúdo.

Complemente este tutorial de Astro com SEO internacional versus SEO multilíngue quando a estratégia de idiomas e países vier antes da implementação.