Multilingual website with Astro: one language, one URL

Adding a language to a website looks like a translation job. For the text, it is. But whether the new version gets found by search engines, read in the right language and shared without surprises depends on structure: where each version lives, how it points to its translations, and whether links keep readers in their language. That structure fits in one rule, one language, one URL, and it is set before the first translated page. If your site first needs a change of technology, our guide to migrating to a static site with Astro sets the frame.

Why one URL per language

A site can serve several languages in two ways: the same URL shows different text depending on the visitor (a cookie, the browser language), or each language lives at its own URL. Google settles it in its documentation on multilingual sites: it recommends different URLs for each language version rather than cookies or browser settings.

The reason is practical. A URL that changes language with the visitor is a single page to a search engine, which indexes one version. A link shared by a French salesperson opens in English for a prospect whose browser is set that way. And the same documentation goes further:

Suggesting the browser’s language in a banner is still fine: the visitor chooses, and the URL they asked for is still served.

Which URL structure

Google lists four structures: a country domain (example.de), a subdomain (de.example.com), a subdirectory (example.com/de/) and a parameter (example.com?loc=de). Only the parameter is not recommended. For a company opening one more language, the subdirectory is often the simplest: one domain, one certificate, one hosting account, and Search Console filters results by folder. A country domain makes sense when each country has its own entity, offer and team.

The path of a translated page

Step 3 is the one that breaks most often, because rereading a page does not reveal it: the text is right, the page displays, and the link still leads to the other language.

Slugs get translated too

The slug is the end of the URL: cout-site-entreprise in French, business-website-cost in English. An English reader who sees a French URL understands they are reading a translation, and a search engine reads a language signal that contradicts the page.

So the rule is to decide before publishing: on this site, every article has a slug in its own language, and what you are reading exists in French at another URL, linked to this one by a shared key. If your current site already mixes languages in its URLs, a redesign is the right moment to sort them out, as our method to decide which pages to keep, merge or delete shows, provided the 301 redirect list is in place before the switch.

Hreflang: each page points to its translations

Hreflang tags tell the search engine: “this page also exists in French, at this URL”. They must be reciprocal, point to pages that respond, and only list languages where the page really exists. The classic mistakes are covered in our article on hreflang and multilingual SEO.

What happens when the rule slips is rarely dramatic and always costly: on Palmora Property, an audit found 24 groups of articles whose declared translations led to 404 error pages. On this site, the template only emits hreflang for languages where the page exists, and the default version (x-default) points to English.

Links that keep the language

A menu, a footer, a call-to-action button, a link in an article: each must lead to the page in the same language. The trap is the hard-coded link, a full URL without a language prefix, which sends the reader back to the default language.

The fix takes two moves: generate links from the page’s language instead of typing them, and check before publishing. On this site, a script rejects a French article whose internal link leaves /fr/.

What Astro does to keep the rule

Astro translates nothing: it provides the structure so that each translation is served in the right place. Its internationalization guide describes what it brings:

• Routes per language. You choose whether the default language lives at the root or in its own folder; this site serves English at the root and French under /fr/.
• Generated links. Functions build a page’s URL in a given language instead of writing it by hand.
• A fallback language. For a page not yet translated, Astro can redirect to another language or show its content. We prefer not to publish a page that does not exist: hreflang does not list it, and readers do not hit a redirect.
• The visitor’s preferred language. Astro can read the browser’s language; it serves to suggest a language, not to redirect by default.

Content follows the same logic: each article lives in its language’s folder, and a shared key links its translations. Because the site is static, each language is just one more folder of files to serve, with no database to duplicate and no translation plugin to update. Hosting costs do not change with the number of languages, as our comparison of static site hosting explains.

Adding a language, and knowing when to remove one

A language costs money at launch (translation, review, structure) and every month afterwards: every new page and every update is done twice. Translation itself has become much cheaper: on Palmora Property, its cost was divided by 60 after moving to an AI model, and 95% of segments come from the cache after the first run. The rest of the budget is in our article on business website cost and the one on website translation cost.

Opening German on Palmora Property gives the order of magnitude of a full language:

The method we kept: open the blog alone first, a low-cost test of interest, before translating everything else. And when a language does not pay off, it is removed cleanly: this site archived Spanish and Chinese on 9 September 2026, every old URL redirecting with a 301 to the equivalent English page.

The other parts of the project

One more language touches the whole site. Forms must answer in the visitor’s language (forms and search on a static site), each version must stay fast (Core Web Vitals for business leaders) and accessible (the EU accessibility obligation). If several people publish in several languages, an editor helps (headless Astro and Sanity), and the choice between Markdown in the repository or a CMS for the blog comes up. A translation produced with AI gets reviewed, and whether to disclose it is a question too. Finally, each language’s home page must do what the first one does, generate enquiries, and hosting can stay in Europe whatever the audience. A WordPress site adds its own risks with each translation plugin: why WordPress sites get hacked.

Both our website offers include this structure: the business website to start from scratch, the static site migration to take over an existing site and its URLs, languages included.

Frequently asked questions

Sources

1. Google Search Central, managing multi-regional and multilingual sites (new tab)developers.google.com
2. Astro, internationalization guide (new tab)docs.astro.build