Cara Menerjemahkan Situs Web Astro: Perutean i18n dan SEO

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.

Pertanyaan yang dijawab dalam panduan ini

• 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.

For strategy context on language versus country targeting, read international SEO versus multilingual SEO.

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.

Daftar periksa implementasi

• Configure Astro i18n locales and routing prefix strategy
• Create locale-aware layout and dictionary files
• Organize content collections per locale with shared schemas
• Localize title, meta, OG, and html lang on every template
• Build locale × URL matrix at compile time
• Generate reciprocal hreflang in HTML or sitemap
• Set same-language canonicals on each static output
• SSR or statically render islands in the active locale
• Add visible language switcher without forced redirects
• Run staging crawl after each locale launch

Kesalahan umum

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.

Dasar-dasar mesin pencari tradisional dan mesin jawaban

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.

Panduan platform: Google Search

Di Google Search, penemuan halaman bergantung pada URL versi lokal yang dapat dirayapi, dengan HTML yang sesuai bahasa, judul dan tajuk yang akurat, serta hreflang timbal balik jika tersedia versi alternatif. Landasan teknisnya mencakup konten yang dapat diindeks (bukan pergantian bahasa yang hanya mengandalkan cookie), metadata yang dilokalkan, peta situs, dan penerapan URL kanonis yang konsisten. Konten berkualitas berarti konten utama yang mengutamakan pengguna dalam setiap bahasa; otoritas berasal dari identitas organisasi yang jelas dan sumber pendukung—bukan pemasaran alat penerjemahan. Implikasi multibahasa: setiap URL untuk pasar atau bahasa tertentu harus dapat berdiri sendiri. Ukur melalui cakupan pengindeksan di Search Console dan Inspeksi URL untuk setiap versi lokal. Yang diketahui dan yang belum pasti: Google mendokumentasikan cara kerja multibahasa dan hreflang, tetapi tidak menjamin peringkat dari CMS atau alur kerja MTPE apa pun.

Panduan platform: Bing

Bing menemukan dan mengindeks halaman multibahasa yang dapat dirayapi dengan struktur yang jelas, serupa dengan persyaratan Google mengenai kejelasan URL dan konten. Landasan teknisnya mencakup URL versi lokal yang dapat diakses, konten bermanfaat, dan pemantauan melalui Bing Webmaster Tools. Utamakan pelokalan tajuk, klaim, dan FAQ daripada hanya menerjemahkan elemen antarmuka. Sinyal otoritas tetap bergantung pada sumber tepercaya dan entitas yang konsisten. Implikasi multibahasa: jangan sembunyikan versi bahasa di balik pengalih yang hanya bekerja di sisi klien. Ukur pengindeksan dan statistik perayapan di Bing Webmaster Tools. Yang diketahui dan yang belum pasti: pedoman Bing menekankan konten bermanfaat yang dapat dirayapi; jangan mengada-adakan faktor pemeringkatan khusus Bing untuk alat penerjemahan.

Panduan platform: ChatGPT

ChatGPT dapat mengutip atau merangkum halaman yang dapat diakses publik jika versi bahasanya jelas dan kontennya siap digunakan sebagai jawaban. Penemuan konten tidak mengikuti pemeringkatan perayapan konvensional; visibilitas berarti terpilih sebagai sumber atau dirujuk dalam jawaban. Landasan teknis tetap dimulai dari URL HTML yang dapat diakses—bukan overlay widget yang menyembunyikan teks. Karakteristik konten yang membantu meliputi jawaban langsung, FAQ, dan terminologi konsisten berdasarkan glosarium. Otoritas berasal dari bukti dan entitas yang konsisten di seluruh versi lokal. Implikasi multibahasa: setiap halaman versi lokal harus dapat dibaca secara mandiri. Pengukurannya belum sempurna—perlakukan pemeriksaan kutipan sebagai hipotesis. Yang diketahui dan yang belum pasti: tidak ada jaminan terdokumentasi bahwa MTPE atau integrasi CMS apa pun akan menghasilkan kutipan di ChatGPT.

Panduan platform: Gemini

Gemini dan pengalaman AI Google terkait terbantu oleh entitas yang konsisten, data terstruktur yang akurat, serta halaman lokal yang dapat diindeks. Visibilitas berarti dirujuk atau dikenali—bukan mengada-adakan faktor pemeringkatan Gemini. Landasan teknisnya beririsan dengan keterayapan dan kualitas metadata di Google Search. Konten harus menyajikan klaim dan definisi yang jelas dalam setiap bahasa. Otoritas bergantung pada konsistensi organisasi dan bukti pendukung. Implikasi multibahasa: nama produk yang distandardisasi melalui glosarium mengurangi kebingungan antarversi lokal. Lakukan pengukuran konvensional melalui Search Console dan ambil sampel jawaban AI untuk penilaian kualitatif. Yang diketahui dan yang belum pasti: perilaku Gemini tidak menggantikan panduan Google Search yang terdokumentasi mengenai hreflang dan versi bahasa.

Panduan platform: Google AI Overviews

Google AI Overviews dapat menautkan halaman pendukung; dasar kelayakannya tetap bertumpu pada konten yang mengutamakan pengguna dan dapat diindeks. Fitur ini bukan pengalih bahasa dan tidak menggantikan hreflang. Landasan teknisnya tetap berupa HTML versi lokal yang dapat dirayapi dan data terstruktur yang sesuai fakta. Karakteristik kontennya meliputi jawaban ringkas dan tajuk yang jelas dalam setiap bahasa. Sinyal otoritasnya sejalan dengan standar konten bermanfaat. Implikasi multibahasa: tidak ada jaminan halaman terjemahan mana pun akan disertakan dalam AI Overviews. Ukur melalui laporan generatif Search Console jika tersedia, dan pisahkan dari metrik indeks tradisional. Yang diketahui dan yang belum pasti: tidak ada alur kerja penerjemahan yang dapat menjanjikan penempatan di AI Overviews.

Peran GlotEO

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.