Astro’s i18n routing has been built into the framework since version 4, released in late 2023. For WordPress, multilingual means WPML at $99/year, or Polylang with its limitations. Neither answer is obviously better — it depends on your content workflow, your team’s technical comfort, and how dynamic your multilingual content actually is.
The WordPress Multilingual Reality
WordPress doesn’t ship with multilingual support. It’s a core gap the platform has never addressed natively, which is why a plugin fills the void.
WPML is the most capable solution. It handles content translation, string translation, menu translation, theme translation, and WooCommerce translation. It integrates with most major page builders and has been the de facto multilingual standard for WordPress for over 10 years. The price is $99/year for a Multilingual Blog license, $199/year for CMS (which includes string translation), and $299/year for Agency licenses.
WPML is good. It’s also heavy. It adds multiple database tables, hooks into the content query layer at a deep level, and has historically caused performance overhead. On a properly configured WordPress setup, the impact is manageable — 20–50ms on server response time in most setups. On a cheap shared host, it can be more significant.
Polylang is the free alternative, with a Pro version at $99/year. The free tier handles basic content translation with a solid UI. The limitations: no WooCommerce support without Polylang Pro, no string translation on the free tier, and less mature integration with complex themes. For a simple brochure site with 5–10 pages in 2–3 languages, Polylang free works well.
TranslatePress is a third option — a visual, front-end translation editor at $99–$259/year. It’s easier to use than WPML for non-technical translators, and the visual interface is genuinely useful for reviewing translations in context. Translation happens on the live page, which some find more intuitive than translating in the admin panel.
The WordPress multilingual story: capable, plugin-dependent, $99–$299/year for a serious implementation, and adding ongoing maintenance complexity to your plugin stack.
What Astro’s Built-In i18n Actually Provides
Astro’s i18n configuration was introduced as experimental in v3 and stabilized in v4. “Built-in” is accurate, but it’s important to understand what that means and what it doesn’t.
What Astro’s i18n provides:
URL routing. Astro handles locale-based URL structures automatically. example.com/en/about, example.com/fr/about, example.com/de/about — the routing is configured in astro.config.mjs with a few lines. The framework handles locale detection, redirects from the root to the default locale, and fallback behavior if a page isn’t translated.
Content organization. Astro’s Content Collections can be organized by locale. You have an en/ directory and a fr/ directory, each with Markdown or MDX files. The type-safe schema validation applies to both.
Locale utilities. Astro ships helper functions: getRelativeLocaleUrl() for generating locale-aware links, getLocaleByPath() for detecting the current locale, getPathByLocale() for building navigation. These are the utilities you’d otherwise build yourself.
What Astro’s i18n does not provide:
Translation management UI. There is 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 third-party translation service.
String/UI translation. Translating page content is straightforward. Translating interface strings — “Add to Cart,” “Search,” “Previous Post” — requires additional tooling. The common pattern is a locale-specific JSON file of UI strings referenced in components. It works, but it’s setup you do yourself.
Machine translation integration. WPML and TranslatePress have direct integrations with DeepL and Google Translate for automated first-draft translations. Astro has no such integration natively. You’d connect to translation APIs through serverless functions or use a headless CMS that handles machine translation.
The Headless CMS Factor for Multilingual Astro
For any Astro site with meaningful content volume, you’ll want a headless CMS — and that CMS handles most of the translation workflow.
Sanity has built-in translation support. Content fields can be locale-specific, and the document structure supports side-by-side translation editing. Sanity’s “Document Internationalization” plugin is stable and actively maintained. For a multilingual Astro site with a non-technical translation team, Sanity gives your translators an interface that looks like a real content editor.
Contentful supports localization natively in all paid plans (and limited on the free tier). Each content entry can have locale-specific field values. Contentful’s translation workflow is mature. The limitation: Contentful’s free tier only supports one locale, so any multilingual project needs at minimum the Basic plan at $300/month. That’s a significant cost jump.
Prismic supports multiple locales on all plans, including free. Content variants per locale, document-level translation status tracking, and a translation-ready editing UI. For cost-conscious multilingual projects, Prismic is worth evaluating.
Storyblok’s visual editor works per-locale — translators can see the rendered page in their language while editing. It’s one of the better translation experiences in the headless CMS market.
The practical takeaway: Astro’s built-in i18n handles routing and content organization. Your headless CMS handles the translation workflow and UI. These are separate concerns, and both need to be solved for a serious multilingual implementation.
Performance for Multilingual Sites
This is where the Astro architecture delivers a concrete advantage over WPML-powered WordPress.
With WPML on WordPress, every page request goes through the WPML locale detection layer, which queries the database to determine which translated content to serve. On a well-configured server, this adds 20–50ms per request. On a high-traffic site with hundreds of thousands of pageviews, this adds up — and it means you can’t fully cache multilingual pages without a sophisticated caching strategy.
Astro’s static multilingual site is pre-built. The English version of /about and the French version of /fr/about are both static HTML files on a CDN. There’s no runtime locale detection. There’s no database query. The page load time is the same as any static Astro page — CDN latency only. Lighthouse scores for both locales are identical to the monolingual site.
For an SEO-driven multilingual site, this matters. Google crawls locale-specific pages independently. If your French pages are slow because WPML is adding overhead, that’s a real ranking signal for French-language queries.
Astro multilingual sites also handle hreflang tags more predictably. You declare locale relationships in your Astro layout, they render into the HTML <head> of every pre-built page, and they don’t depend on a plugin correctly detecting the page type and injecting the tags at request time.
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 owner with a multilingual team, the editing experience difference is significant.
WPML on WordPress: your translator logs into the WordPress admin, finds the English post, clicks “Translate,” and edits in a side-by-side editor showing the source language on the left and translation fields on the right. It’s not beautiful, but it’s functional. A non-technical translator can be trained on this in 20 minutes.
Astro with Sanity: your translator logs into Sanity, finds the English document, opens the translation sidebar, and edits locale-specific fields. The experience is roughly comparable to WPML — usable by non-technical translators after brief training.
Astro with Markdown files in Git: your translator gets a .md file in a Git repository and a Markdown editor. This is fine for developers. It is not a reasonable workflow for a marketing team or external translation agency. If this is your editing model, you need a headless CMS.
The WordPress WPML workflow is mature and tested. It’s been used by large multilingual sites for over a decade, and edge cases have been ironed out. Astro’s headless CMS integrations are newer. They work — we build them — but they require more upfront configuration.
The Cost Comparison
WordPress multilingual with WPML:
- WPML CMS license: $199/year
- Managed WordPress hosting: $35–$100/month
- Plugin maintenance overhead: included in general WordPress maintenance
- 3-year WPML license cost: $597
Astro multilingual with Sanity:
- Sanity free tier: $0/month (up to 3 users, 2 datasets)
- Sanity Growth plan: $15/month per user (for larger teams)
- CDN hosting (Vercel/Netlify/Cloudflare): $0–$20/month
- 3-year hosting cost: $0–$720
For a small team, Astro with Sanity’s free tier and Cloudflare Pages hosting is effectively free to operate. WPML costs $597 in licenses over 3 years on top of hosting. For larger teams needing multiple Sanity users, the cost difference narrows.
The build cost for a proper multilingual Astro implementation is higher than adding WPML to an existing WordPress site. WPML adds multilingual to an existing platform in hours. Setting up Astro i18n routing plus a headless CMS with multilingual content types takes days. Budget accordingly if you’re starting fresh.
When to Choose WordPress + WPML
WordPress multilingual makes sense when:
Your content team is already in WordPress and doesn’t want to learn a new CMS. Adding WPML to an existing WordPress site is the path of least disruption.
You’re running WooCommerce. Multilingual ecommerce with product translations, checkout string translations, and locale-specific pricing is a solved problem with WPML + WooCommerce. Replicating this in Astro is a significant custom build.
You need a translation agency workflow. WPML has direct integrations with professional translation services, including WPML’s own translation management system. Sending content to an external translator and receiving it back into WordPress is a supported workflow with WPML.
You’re adding a second language to an existing site with 50+ existing pages. Retrofitting Astro i18n to an existing non-multilingual Astro site is more disruptive than it sounds. Adding WPML to an existing WordPress site takes a few hours.
When to Choose Astro i18n
Astro multilingual makes sense when:
You’re starting a new site and performance is a priority for multilingual SEO. Static pages served from a CDN in every locale is architecturally better for Core Web Vitals than WPML’s runtime translation layer.
You’re running a global site with high page counts per locale. Astro’s build-time rendering means no per-request overhead regardless of content volume. At scale, this matters.
Your translation workflow is developer-managed or uses a headless CMS that already handles localization. Sanity’s i18n tooling is production-grade. If you’re already evaluating Sanity for content management, multilingual is not a reason to choose WordPress instead.
Your team is comfortable with a developer-centric workflow. Astro i18n is well-documented and not difficult to implement — but it requires a developer who knows the framework.
Frequently Asked Questions
Does Astro support right-to-left languages like Arabic and Hebrew?
Yes. Astro’s i18n routing handles any locale, including RTL languages. The HTML dir="rtl" attribute and locale-specific CSS are handled in your layout components — Astro doesn’t restrict this in any way. You’ll need to test your CSS carefully for RTL layout issues, but this is a CSS concern, not an Astro constraint.
Can I use Astro i18n without a headless CMS? Yes, with caveats. Markdown files organized by locale directory work cleanly with Astro Content Collections. For a developer-maintained site with infrequent updates, this is a viable workflow. For a marketing team that updates content regularly, you need a CMS with a proper editing interface.
Is WPML worth the cost? For most WordPress multilingual projects, yes. The alternative is either Polylang (which has limitations on the free tier) or building custom locale management from scratch. $199/year for a well-maintained, full-featured multilingual solution is a reasonable line item for a business that genuinely needs multiple languages.
How does Astro handle hreflang tags?
You implement hreflang in your site’s <head> component, using Astro’s locale utilities to generate the correct href values for each locale variant. It’s declarative and predictable — the tags are rendered into static HTML at build time, not injected at request time by a plugin.
What’s the minimum viable multilingual Astro setup? For a developer-managed site with Markdown content: Astro’s i18n config, locale-organized content directories, a locale switcher component, and hreflang tags in the head. This is a 1–2 day setup for a developer familiar with Astro.
Can I machine-translate content in Astro? Not natively. You’d connect to DeepL or Google Translate through a build-time script or a headless CMS feature. Sanity, Contentful, and Storyblok all have machine translation integrations. In WordPress, WPML and TranslatePress have this built in.
If you’re building a multilingual site and aren’t sure whether WordPress or Astro is the right foundation, our custom WordPress development work covers both — and our fixed-price packages include a clear upfront recommendation based on your actual requirements, not a default to whichever we sell more of.