See the builder itself
One site, up to eight languages, with hreflang and fallback handled automatically as you add each one.
A practical multilingual website guide: URLs, fallbacks, priorities
Adding a second language is usually described as a translation problem. It's really a structure problem: where the translated pages live, what happens while not everything is translated yet, and which pages earn the work first. Get the structure right and translation is just typing. Get it wrong and search engines index duplicate or half-empty pages, no matter how good the translation itself is.
Where the translated pages actually live
There are a handful of common ways to serve the same content in multiple languages, and they're not interchangeable for search purposes:
Subdirectories — example.com/es/page — the most common recommended pattern. Every language shares one domain, so all of the site's authority and trust accumulate in one place, and search engines can crawl every language from the same root.
Subdomains — es.example.com — technically separates languages, but search engines can treat a subdomain as a semi-distinct entity, which can dilute the signal that all these pages belong to one site.
Separate domains — example.es, example.de — full separation, common for large multinational brands who want a genuinely local presence per country, but it multiplies the SEO work: each domain builds authority independently, from zero.
A query parameter — example.com?lang=es — cheap to implement, but search engines are inconsistent about treating parameterized URLs as fully distinct pages, and it's the pattern most likely to produce duplicate-content confusion.
No distinct URL at all — a client-side language switch that doesn't change the address bar. This is the pattern to avoid for any content you want indexed: if the URL doesn't change, there is nothing for a search engine to index as "the Spanish page," and nothing a hreflang tag can point to.
The default language: prefixed, or not?
A common and reasonable convention is to leave the default language unprefixed at the root (
/pricing) and prefix every other active language (/es/pricing, /de/pricing). It reads naturally, it means your existing links and any inbound SEO equity on the root URLs are untouched when you add a second language, and it gives you an unambiguous "default" URL to fall back to when nothing else matches — which matters for the x-default hreflang tag (covered in the companion guide on hreflang).What should happen when a translation is missing
Someone always switches a language on before every last page is done — what matters is what happens at the gap. A well-built fallback chain tries, in order: the exact requested locale, then its base language (an
es-MX visitor can still read an es page), then the site's default language, and only then whatever exists at all. What it must never do is render a blank section or a broken page: a visitor should always see complete content, even if some of it arrives in the fallback language rather than the one they asked for.Rolling out a second language without breaking the first
1
Translate the navigation and the highest-traffic pages first
A visitor forgives a blog post that's still in the fallback language far more readily than a homepage or pricing page that doesn't match the language they chose. Start where the traffic and the buying decisions are.
2
Do legal and policy pages next
Terms, privacy and returns pages carry real consequences if misread — they're worth translating properly before long-tail content, even though they get less traffic.
3
Keep checkout and transactional copy in step with the rest
A storefront that switches language everywhere except the final payment step undermines confidence exactly when it matters most.
4
Only then work through the long tail
Everything else — archive content, older blog posts, niche help articles — can be translated on its own schedule without hurting the experience for most visitors.
5
Don't publish a language until the core pages actually hold up
Turning a language "on" site-wide before the pages that matter are ready trades a real problem (untranslated pages) for a worse one (a language switcher that visibly leads to gaps).
How Olmira handles this
An Olmira site runs up to eight languages — two on the trial, three on Starter, all eight from Pro upwards — and the structure above is the built-in behaviour, not configuration:
URLs — the default language stays unprefixed and every other active language gets its own // path, with hreflang and x-default alternates generated for every page the moment a second language is active.
Fallbacks — content resolves exact language, then base language, then the site's default, so an unfinished translation degrades gracefully instead of rendering blank. First-time visitors get the language their browser asks for (among the ones you've switched on); an explicit choice sticks. If you sell, the storefront — catalogue names, form labels, booking confirmations, live chat — follows the visitor's language too.
The translation work itself — a Translations tab lists every page title, meta description and section of text per language with a plain coverage percentage, and drafts the missing ones with AI on request: one line, one language, or the whole site at once. Nothing an AI suggests is saved until you've read it and clicked save, and a language you've switched on but haven't finished stays off the published site until its content is actually filled in — the rollout rule above, enforced for you rather than left to discipline. Full builder: the website builder.