Astro JS for Multilingual Websites: i18n Guide

Astro has had internationalization routing built in since version 3.5. “Built in” is accurate, but it covers less than people expect. Astro handles the URLs for each language. Translation itself, the interface strings and the hreflang tags Google reads are still yours to set up. WordPress takes the opposite approach: it has no multilingual feature of its own, so a plugin does all of it.

We build Astro sites through our custom web development service and WordPress sites through our WordPress development service, so weigh that. Every fact below about Astro and Google was checked against the Astro documentation and Google Search Central in October 2026.

Short answer: Astro’s i18n routing gives you a URL per language (/fr/about/), a default language, fallbacks for untranslated pages and helper functions for locale-aware links. It doesn’t translate content, manage translators or add hreflang tags. You keep translations in Markdown or a headless CMS, write hreflang into your layout (or let the sitemap integration list the alternates) and follow Google’s rules: every language version lists itself and all the others. For a new site where speed and search in each language matter, Astro fits. For an existing WordPress site or a multilingual WooCommerce store, a WordPress plugin is the shorter path.

What Astro i18n Does and Doesn’t Do

As of October 2026, from the Astro and Google documentation:

Sources: Astro i18n routing guide, Astro i18n API reference, Astro sitemap integration.

The WordPress Multilingual Reality

WordPress doesn’t ship with multilingual support. A plugin fills the gap, and the established ones cover content translation, menus, theme strings and, on the more complete tiers, WooCommerce products and checkout.

That’s the strength of the WordPress route: everything lives in one admin. A translator opens a post, clicks translate and works in a side-by-side editor. Several plugins also connect to machine translation services for a first draft.

The cost is a heavier plugin. A multilingual plugin hooks into how WordPress looks up content on every request, and it becomes another component to update, test and keep compatible with your theme, page builder and WooCommerce. Check the current plan and price on each plugin’s own site before you choose, because what’s included in each tier changes.

What Astro’s Built-In i18n Actually Provides

Astro’s i18n routing API was added in Astro 3.5.0 (source). Features have been added since, and it’s configured in astro.config.mjs.

URL routing. You list your locales and set a defaultLocale. By default, pages in your default language have no prefix, and other languages live under /[locale]/, such as example.com/fr/about/. Set prefixDefaultLocale: true and every language gets a prefix, including the default (source).

Fallback. When a page isn’t translated yet, Astro can show the page from another language instead of a 404. You set the fallback per language, and since Astro 4.15 you choose whether it redirects to that page or shows its content at the requested URL (source).

Locale utilities. The astro:i18n module includes getRelativeLocaleUrl() and getAbsoluteLocaleUrl() for links, getPathByLocale() and getLocaleByPath() for mapping paths to languages, and middleware helpers for custom redirects (source). These are the utilities you’d otherwise build yourself.

Browser language. On pages rendered on demand, Astro.preferredLocale gives the visitor’s preferred language if your site supports it (source). Use it to suggest a language, not to redirect. Google advises against automatically redirecting users from one language version to another (source).

Separate domains. The domains option, added in Astro 4.9, maps languages to their own domains, such as fr.example.com. It needs a server-rendered project with no prerendered pages, using the Node or Vercel adapter (source).

What Astro’s i18n does not provide:

Translation management UI. There’s no Astro admin panel where a translator logs in, sees untranslated strings and enters translations. Your translation workflow lives in your headless CMS, your Markdown files or a translation service.

String/UI translation. Translating page content is straightforward. Translating interface strings, such as “Search” or “Previous post”, needs its own setup. The common pattern is a JSON file of strings per language, read by your components.

Machine translation integration. Astro has no built-in connection to a machine translation service. You’d add one through a build script or use a headless CMS that offers it.

hreflang on an Astro Site

hreflang tells Google which pages are language versions of each other, so searchers get the right one. Astro’s i18n routing guide doesn’t generate these tags. You add them yourself.

Google’s rules, from its localized versions guide:

• Three methods, all equal. HTML link tags, HTTP headers or the sitemap. Google treats them the same, so pick one.
• Every version lists every version. Each language version must list itself and all the others. If two pages don’t point to each other, Google ignores the tags.
• Use x-default for everyone else. hreflang="x-default" marks the page for visitors whose language you don’t support, usually a language picker or your main version.
• Use standard codes. The language code is ISO 639-1, with an optional ISO 3166-1 Alpha 2 region, such as en-GB. Codes outside those standards, such as es-419, aren’t supported.
• hreflang isn’t language detection. Google doesn’t use hreflang or the HTML lang attribute to work out a page’s language. It reads the page itself, so keep each page in one language.

On Astro, the HTML method fits well. Your layout knows the current page’s path, so a short loop over your locales with getAbsoluteLocaleUrl() can write one link tag per language plus x-default. The tags are rendered into static HTML at build time, not injected by a plugin per request. If you’d rather use the sitemap method, the @astrojs/sitemap integration’s i18n option adds the alternate links for each URL (source).

Google also recommends a separate URL for each language version rather than switching the language with cookies or browser settings (source). Astro’s routing gives you that by default.

The Headless CMS Factor for Multilingual Astro

For an Astro site with regular content updates, a headless CMS usually handles the translation workflow. Most major headless CMSs support per-language fields or per-language documents, and some show translators a preview of the page in their language.

What to check before choosing one:

• How many languages your plan allows. Some CMSs limit the number of locales on lower tiers.
• Field-level or document-level translation. Field-level suits pages that share structure. Document-level suits content that differs by market.
• Translation status. Can an editor see which pages are out of date in which language?
• Machine translation. Is a first-draft integration built in, or an add-on?

The practical takeaway: Astro’s built-in i18n handles routing. Your CMS handles the translation workflow. Both need to be solved for a serious multilingual site.

Our guide to headless CMS with Astro covers how content editing works in practice.

Performance for Multilingual Sites

A static Astro site pre-builds every language. The English /about/ and the French /fr/about/ are both plain HTML files served from a CDN, with no database query and no language lookup when someone visits. Each language loads as fast as a single-language Astro page.

A WordPress multilingual plugin works at request time, deciding which translation to serve as each page loads. Page caching can absorb most of that, but the cache has to keep a separate copy per language and clear the right ones when content changes.

For multilingual SEO, this matters because Google crawls each language version as its own page. Every version needs to be fast, not only the main one.

For more on Astro’s SEO capabilities, the Astro JS SEO capabilities post covers the technical implementation in full.

Content Editing Workflow: Practical Comparison

For a business with a multilingual team, the editing experience is often what decides it.

WordPress with a multilingual plugin: the translator logs into the WordPress admin, opens the original post and translates in a side-by-side editor. It’s functional, and a non-technical translator picks it up quickly.

Astro with a headless CMS: the translator logs into the CMS, opens the document and edits the fields for their language. With a well-configured CMS, it’s comparable to WordPress.

Astro with Markdown files in Git: the translator edits a .md file in a repository. That’s fine for developers. It isn’t a reasonable workflow for a marketing team or an external translation agency. If that’s your team, you need a CMS.

The WordPress workflow is mature and widely used. The Astro workflows work well, but they take more setup at the start.

When to Choose WordPress + WPML

WordPress with a multilingual plugin such as WPML makes sense when:

• Your content team already works in WordPress. Adding a plugin is the path of least disruption.
• You run WooCommerce. Multilingual products, checkout and emails are a solved problem with a WooCommerce-compatible multilingual plugin. Rebuilding that on Astro is a large custom project.
• You send content to a translation agency. Several plugins have workflows for sending content out and bringing it back in.
• You’re adding a language to a large existing site. A plugin can be added to the site you have. Moving to Astro means a rebuild.

When to Choose Astro i18n

Astro makes sense when:

• You’re starting a new site and search in each language matters. Every language is a static, fast page with its own URL.
• You have many pages per language. Build-time rendering means no per-visit cost, however much content you have.
• Your translation workflow is developer-managed or runs through a headless CMS that already handles localization.
• You have a developer who knows Astro. The i18n setup is well documented, but it’s code, not a settings screen.

Related Posts

• Astro JS SEO capabilities: what Astro handles automatically and what you build
• Headless CMS with Astro explained: how content editing works
• Astro content collections explained: how content is organized, including by language
• Astro CMS options for non-developers: which CMS suits your editors

FAQ

Does Astro have built-in multilingual support?

Astro has built-in i18n routing, added in version 3.5. It handles a URL per language, the default language, fallbacks and locale-aware links. Translating content, interface strings and hreflang tags is still up to you, your files or your CMS.

Does Astro support right-to-left languages like Arabic and Hebrew?

Yes. Astro’s routing works with any locale. Set dir="rtl" and the lang attribute in your layout for those languages, and test your CSS for right-to-left layout. That’s a CSS job, not an Astro limitation.

Can I use Astro i18n without a headless CMS?

Yes. Markdown files in a folder per language work well with Astro’s content collections. That suits a developer-maintained site with occasional updates. A marketing team that edits content regularly needs a CMS.

Does Astro add hreflang tags automatically?

Not to the page head. You write them into your layout, usually with a loop over your locales. The @astrojs/sitemap integration can add hreflang alternates to your sitemap instead. Google treats both methods the same.

Should I redirect visitors to their browser language?

Google advises against automatically redirecting users between language versions. Let visitors switch with a language picker. If you detect their browser language with Astro.preferredLocale, use it to suggest a version, not to force one.

Can I machine-translate content in Astro?

Not natively. You’d connect a translation service through a build script or use a headless CMS with a machine translation feature. Many WordPress multilingual plugins include one.