Como traduzir um site Astro: roteamento i18n e SEO

Publique URLs rastreáveis por localidade no Astro com roteamento i18n, coleções de conteúdo, tags de SEO localizadas, sitemaps preparados para hreflang e fluxos editoriais em MDX.

How to Translate an Astro Website: Astro island components floating in a static page frame with locale folder chips on a

Astro’s static-first architecture is a natural fit for multilingual marketing sites—when teams treat i18n routing, content collections, and SEO annotations as first-class engineering work. Astro developers often ship beautiful locale folders, then discover hreflang is missing, layout chrome stays in English, or hybrid islands render untranslated strings client-side.

This guide explains how to translate an Astro website with crawlable locale HTML, organized content collections, localized layout and SEO tags, hreflang-ready sitemaps, hybrid rendering caveats, and editorial workflows for Markdown and MDX—all grounded in Google’s multilingual requirements. No invented ranking factors.

Perguntas que este guia responde

  • How does Astro i18n routing support crawlable locales?
  • How should content collections be organized per language?
  • How do you localize Astro layout chrome and SEO tags?
  • How should hreflang be generated for static Astro output?
  • When is hybrid rendering needed for multilingual Astro sites?
  • How should translation workflow integrate with Markdown/MDX content?
  • Which Astro multilingual mistakes are common?
  • When should Astro teams adopt a translation platform?

Quick answer: static locale HTML is Astro’s SEO advantage

Short answer: Use Astro i18n routing to pre-render distinct locale URLs with fully localized HTML—including navigation, metadata, and main content—then add reciprocal hreflang across alternates.

Pre-rendered HTML per locale URL aligns well with Google’s preference for crawlable language versions with distinct URLs. Astro can emit static files per locale at build time, which gives crawlers the same language-specific document users receive without depending on client-side language toggles.

Google recommends different crawlable URLs for each language version rather than cookies or browser language alone. Astro’s astro:i18n routing (or equivalent locale-prefix patterns) supports that model when you generate one output path per locale.

Astro i18n routing and URL design

Configure Astro with explicit locales and a default locale. Common URL patterns:

  • Prefix default locale (/en/about, /fr/about) — explicit and easy to annotate.
  • Hide default locale (/about for English, /fr/about for French) — cleaner for primary market URLs; document the mapping in hreflang.

In astro.config.mjs, set i18n.locales, i18n.defaultLocale, and i18n.routing to match your matrix. Each route file should receive the active locale via Astro’s APIs so templates render the correct language.

Google determines page language primarily from visible content; language versions should keep content and navigation predominantly in one language. Wire nav components to locale-aware translation dictionaries so headers and footers match the page body.

Avoid automatic redirects based on assumed language or location. Google advises against auto-redirects and recommends a user-visible language selector linking to alternate URLs.

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

Content collections per locale

Astro content collections power blogs, docs, and landing page copy. Organize multilingual content deliberately:

  • Separate collection directories per locale (src/content/blog/en/, src/content/blog/fr/) with shared schemas.
  • Locale field on frontmatter filtering a single collection when volumes are small.
  • Symlinked or generated indices that list only items available in each locale—avoid publishing empty locale stubs.

Each localized document should reference locale-appropriate assets and internal links. A French post linking to an English-only doc breaks user trust and language consistency.

When equivalent content does not exist in a locale, do not fake hreflang alternates—either translate the pair or omit the relationship until ready.

Localizing layouts, SEO and Open Graph

Centralize layout chrome in locale-aware components:

  • BaseLayout.astro reads Astro.currentLocale (or your i18n helper) and selects strings from JSON or TS dictionaries.
  • <title> and meta description come from frontmatter or CMS fields per page—not hard-coded English.
  • Open Graph and Twitter tags mirror the localized title and description.
  • html lang attribute matches the active locale (accessibility plus clarity; Google still uses visible content for language detection).

Localized SEO titles and meta descriptions should be unique per locale URL. Thin boilerplate-only localization—translated nav with English article bodies—creates weak language versions.

Hreflang and sitemap generation

Astro sites should still emit reciprocal hreflang (HTML, headers or sitemaps) across locale URLs when alternate versions exist. At build time, generate a locale matrix from your content graph:

  1. For each logical page, list every published locale URL.
  2. Emit <link rel="alternate" hreflang="..." href="..." /> in <head> on each static HTML file, or
  3. Generate an XML sitemap with xhtml:link alternates for each URL entry.

XML sitemaps help discovery of language versions and can carry xhtml:link hreflang annotations when used as an implementation method.

Each language URL should have a clear same-language canonical. Google canonical guidance applies to static sites the same as dynamic ones.

Integrate sitemap generation into CI—@astrojs/sitemap plus custom serialization hooks works well—so hreflang stays in sync when content changes.

See multilingual SEO foundations for how editorial teams govern annotations alongside engineering output.

Hybrid islands and dynamic content caveats

Astro’s islands architecture lets you hydrate React, Vue, or Svelte components selectively. Multilingual caveats:

  • Client-only widgets may render English until JavaScript loads—bad for language detection and UX.
  • Server-render initial island HTML in the correct locale when possible.
  • Dynamic routes (output: 'server' or hybrid) need locale passed through middleware so SSR HTML matches the URL prefix.

When is hybrid rendering needed? Use hybrid or server rendering when content is personalized, auth-gated, or fetched at request time—but still emit crawlable static locale shells for marketing pages that must rank. Marketing locales should default to static generation; reserve dynamic rendering for authenticated app sections.

Editorial workflow for MDX and CMS content

Markdown and MDX remain the most maintainable Astro content layer for many teams:

  1. Source strings in translation files (src/i18n/fr.json) for UI chrome.
  2. Frontmatter per locale file for long-form content.
  3. Pull requests per locale batch with glossary checks.
  4. CAT or TMS export for large doc sets—re-import into src/content.

Google helpful-content guidance prioritizes people-first pages; machine-only dumps without review create thin locale experiences.

Define publish gates: no merge if required locale fields missing, if internal links escape the locale, or if sample hreflang pairs fail reciprocity checks.

Checklist de implementação

Erros comuns

  1. English-only layout shell on localized routes.
  2. Missing hreflang because static paths were hand-maintained.
  3. Default locale hidden without documenting alternates — broken reciprocity.
  4. Client-rendered language toggle without distinct URLs.
  5. Mixed-language MDX from partial translation merges.
  6. Publishing stub locales with lorem or English placeholders.
  7. Sitemap omitted on large static sites—slower discovery.
  8. Canonical pointing across languages carelessly.

Bing Webmaster Guidelines also emphasize crawlable, useful content and clear site structure for indexing across markets.

Fundamentos da busca tradicional e dos mecanismos de resposta

Shared foundations for Astro static locale HTML and content collections still matter across Google, Bing, and answer engines: crawlable language versions, clear entities, evidence-backed claims, structured data where truthful, and real localization—not English-only shells. Treat the guides below as platform-specific lenses on the same multilingual delivery bar.

No Google Search, a descoberta depende de URLs por localidade que sejam 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 de idioma baseados em cookies), metadados localizados, sitemaps e uso criterioso de tags canônicas. Qualidade de conteúdo significa ter conteúdo principal voltado às pessoas em cada idioma; a autoridade vem de uma identidade organizacional clara e de fontes que corroborem as informações — não do marketing de ferramentas de tradução. Implicação para sites multilíngues: cada URL de mercado ou idioma precisa funcionar de forma independente. Avalie a cobertura e use a Inspeção de URL do Search Console para cada localidade. O que se sabe e o que é incerto: o Google documenta o comportamento de sites multilíngues e do hreflang, mas não garante posições nos resultados com base em qualquer CMS ou fluxo de pós-edição de tradução automática (MTPE).

Guia por plataforma: Bing

O Bing descobre e indexa páginas multilíngues rastreáveis e bem estruturadas, com expectativas semelhantes às do Google quanto à clareza das URLs e do conteúdo. Os fundamentos técnicos incluem URLs por localidade acessíveis aos rastreadores, conteúdo útil e monitoramento no Bing Webmaster Tools. Prefira localizar 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 da consistência das entidades. Implicação para sites multilíngues: não esconda os idiomas atrás de seletores que funcionam apenas no lado do cliente. Avalie 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 por plataforma: ChatGPT

O ChatGPT pode citar ou resumir páginas acessíveis publicamente quando as versões de idioma estão bem identificadas e o conteúdo está pronto para responder a perguntas. A descoberta não segue a lógica convencional de classificação de páginas rastreadas; a visibilidade se manifesta na seleção como fonte ou na menção em respostas. Os fundamentos técnicos continuam começando por URLs com HTML acessível — não por sobreposições de widgets que ocultam o texto. Entre as características de conteúdo que ajudam estão respostas diretas, perguntas frequentes e terminologia consistente com base em glossários. A autoridade vem de evidências e da consistência das entidades entre localidades. Implicação para sites multilíngues: cada página por localidade deve ser compreensível por si só. A mensuraçã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 CMS gere citações no ChatGPT.

Guia por plataforma: Gemini

O Gemini e outras experiências de IA do Google se beneficiam de entidades coerentes, dados estruturados que reflitam os fatos e páginas localizadas indexáveis. Visibilidade significa ser citado ou reconhecido — não inventar fatores de classificação do Gemini. Os fundamentos técnicos coincidem com os requisitos de rastreabilidade e qualidade dos metadados do Google Search. O conteúdo deve apresentar afirmações e definições claras em cada idioma. A autoridade depende da consistência das informações sobre a organização e de fontes que as corroborem. Implicação para sites multilíngues: nomes de produtos padronizados por glossários reduzem a confusão entre localidades. Faça a mensuração tradicional pelo Search Console e avalie qualitativamente uma amostra das respostas de IA. O que se sabe e o que é incerto: o comportamento do Gemini não substitui as orientações documentadas do Google Search sobre hreflang e versões de idioma.

Guia por plataforma: Google AI Overviews

O Google AI Overviews pode incluir links para páginas que fundamentem as respostas; a elegibilidade continua baseada em conteúdo indexável e voltado às pessoas. O recurso não é um seletor de idioma nem substitui o hreflang. Os fundamentos técnicos continuam sendo HTML rastreável por localidade e dados estruturados que reflitam os fatos. Entre as características de qualidade do conteúdo estão respostas concisas e cabeçalhos claros em cada idioma. Os sinais de autoridade refletem as expectativas de conteúdo útil. Implicação para sites multilíngues: a inclusão no AI Overviews não é garantida para nenhuma página traduzida. Avalie os relatórios de IA generativa do Search Console, quando disponíveis, e mantenha as métricas tradicionais de indexação separadas. O que se sabe e o que é incerto: nenhum fluxo de tradução pode prometer presença no AI Overviews.

Onde a GlotEO se encaixa

When should Astro teams adopt a translation platform? Once glossary enforcement, locale review queues, and hreflang matrices outgrow manual JSON and MDX pull requests.

Engineering can ship perfect Astro i18n routing; localization still needs glossaries, review queues, and publish discipline. Explore GlotEO website localization to connect briefs, translation workflow, and QA gates with static-site content pipelines—so MDX and dictionary updates stay aligned with hreflang and SEO metadata your Astro build emits.

Compare GlotEO pricing and plans when translation volume grows beyond manual JSON edits, and use multilingual SEO workflow tooling to keep locale matrices and editorial requirements visible to both developers and content teams.

Pair this Astro tutorial with international SEO versus multilingual SEO when language and country strategy precedes implementation.

Referências