By Mehdi HassanMost multilingual website guides start with hreflang tags. That's the last step, not the first. The expensive mistakes happen earlier: translating into languages you can't sell in, translating copy that was written for a different buyer, or picking a URL structure that splits your search authority across domains. This guide starts with the business decision and ends with the technical setup, and links to deeper guides on each part.
We build multilingual marketing sites in Framer, Webflow and Next.js, and the same principles hold on every platform. Where platform choices matter, we say so.
What is a multilingual website, and do you need one?
A multilingual website offers its content in more than one language, with each language version on its own URL, written for that audience and connected so search engines show the right version to the right person. It's different from a site with a translate button, where a browser or widget rewrites the page on the fly. Those versions aren't indexed, can't be optimized and often read badly.
You need one when a meaningful share of your buyers prefer to evaluate and buy in another language, and when you can actually serve them: sales calls, support, contracts and onboarding in that language, or at least a plan for them. If a German prospect reads a perfect German homepage and then gets an English-only demo and English-only docs, the translation has raised expectations you can't meet.
You probably don't need one yet if your buyers are technical teams who work in English, if you have no customers in the target market, or if your English site still isn't converting. Fix the core message first. Translating a weak page gives you several weak pages.
When should a startup localize its website?
A startup should localize its website when there's evidence of demand in a market and the business is ready to sell there. The evidence is usually already in your data. Look for it before you commission a single translation.
- Traffic and signups by country: a market sending steady traffic and trials despite an English-only site is the strongest signal.
- Sales conversations: prospects asking for materials, contracts or demos in their language.
- Search demand: people searching for your category in their own language, which you can check with keyword tools.
- Competitive gaps: competitors with no localized presence in a market you can serve.
- Strategic plans: a hire, partner or office in a new market that needs a local site to support it.
The readiness side matters as much as demand. Ask who will answer a support email in that language, who will review the copy when the product changes, and whether pricing, payment methods and legal terms work for that market. If those answers are 'nobody yet', localize one landing page for a campaign before committing a whole site.
Which markets and languages should you start with?
Start with the one or two markets where demand, ability to serve and revenue potential overlap. Choosing by population or by which languages are easiest to translate leads to sites in languages nobody on the team can sell in. Use a simple scoring table and be honest about each column.
Factor | What to check | Why it matters |
|---|---|---|
Existing demand | Traffic, trials and inquiries from the market | Proof that people already want the product |
Search demand | Category searches in the local language | Shows organic potential for the localized site |
Ability to sell | Sales and support in the language or a plan for it | A translated site with no local follow-up wastes leads |
Commercial fit | Pricing, currency, payment and legal requirements | Some markets need product or contract changes first |
Competition | How well local and global rivals serve the market | Gaps are cheaper to win |
Language vs country | One language across countries, or one country with several languages | Decides your URL and hreflang structure |
The last row is easy to miss. Spanish for Spain and Spanish for Mexico are one language with different terms, prices and examples. Switzerland is one country with several languages. Decide whether you're targeting languages, countries or both before you choose URLs, because it changes the structure.
How does copy change between languages?
Copy for a new market should be adapted, not just translated: the message, proof, examples, pricing and tone may all need to change. Translation converts words. Localization asks whether the argument still works for a buyer in that market. A headline built on an American idiom, testimonials only from US companies, and prices in dollars can all weaken a translated page.
Element | Translation only | Localized |
|---|---|---|
Headline | Literal translation of the English line | Rewritten around the same benefit in natural local phrasing |
Proof | Same logos and testimonials | Local or regional proof where you have it |
Pricing | Dollar amounts | Local currency, tax display and payment methods |
Examples | US-centric use cases | Examples, regulations and tools familiar locally |
Tone | Same formality as English | Adjusted, such as formal or informal address |
Calls to action | Translated button text | The action buyers expect in that market |
Machine translation is a reasonable first draft for long-tail pages and a poor final draft for the pages that sell. The homepage, pricing, key landing pages and anything legal deserve a native speaker who understands the product. We go deeper on where machine translation falls short in localization vs translation.
For example, suppose a US SaaS company localizes for Germany
For example, suppose a US analytics startup localizes for German buyers. A literal translation keeps the punchy English headline, the US customer logos and monthly prices in dollars.
A localized version rewrites the headline in natural German around the same benefit, uses the formal form of address that fits B2B buyers, shows prices in euros with tax handling explained, adds a section on data residency and privacy because that's a top buying question, and swaps in examples from European tools the buyer already uses. The page structure stays the same, which keeps design and build costs down, but the argument fits the market.
How should you structure URLs for a multilingual website?
For most startups, put each language in a subdirectory on your main domain, like example.com/de/ and example.com/fr/. Sources on international SEO broadly agree on this for most cases. Subdirectories keep all versions on one domain, so they share its authority, are cheap to run and are easy to manage in a single CMS.
Structure | Example | Strengths | Weaknesses | Best for |
|---|---|---|---|---|
Subdirectory | example.com/de/ | Shares domain authority, one site to manage | Weaker local signal than a country domain | Most startups |
Subdomain | de.example.com | Separate hosting or platform per market | Can be treated more like separate sites | Teams with separate regional stacks |
Country domain (ccTLD) | example.de | Strongest local signal and trust | Separate authority, more domains and cost | Large companies with local teams |
URL parameters | example.com?lang=de | Easy to bolt on | Harder to target and often poorly indexed | Avoid |
Whatever you choose, keep one language per URL, don't redirect visitors automatically based on location or browser language without a way back, and make sure every version is crawlable. The full trade-offs are in subdirectory vs subdomain vs ccTLD.
How does multilingual website SEO work?
Multilingual website SEO works by giving each language its own indexable URL, connecting the versions with hreflang annotations, and doing keyword research in each language rather than translating English keywords. Hreflang tells search engines which page is for which language or region, so they can show a French speaker the French page. Google's documentation on localized versions of pages is the reference.
Hreflang is where most multilingual sites quietly break. The recurring errors reported across international SEO sources are consistent:
- Missing self-reference: each page must list itself as well as its alternates.
- Missing return tags: if the English page points to the German one, the German page must point back.
- Wrong codes: language codes must be valid, and region codes are optional add-ons, not replacements.
- No x-default: a fallback for visitors whose language you don't support.
- Duplicate tags from plugins: two systems writing hreflang at once, often with conflicting values.
Our guide to hreflang setup and the mistakes that break it walks through each one. Beyond hreflang, localized pages need their own titles, meta descriptions and internal links, and a technical SEO launch checklist for each language. If a localized blog is part of the plan, set up its templates and categories per language from the start; our blog setup guide covers the structure.
Do AI answer engines cite translated pages?
AI answer engines can cite localized pages when they're real, crawlable pages with clear answers in that language, but they're less predictable than classic search. The same build basics apply: server-rendered or static HTML, crawler access in robots.txt and answer-first structure. Pages translated on the fly by a widget don't exist for these systems at all.
Answer engines also sometimes answer in one language while citing sources in another, so strong English pages can still surface for non-English questions. Localized pages give you a better chance in that market's language, especially for local questions about pricing, compliance and availability. We look at what's known in localizing for AI search.
How do you design a website for multiple languages?
Design for multiple languages by planning for longer text, right-to-left scripts where needed, local formats and a clear language switcher from the first wireframe. A layout that only fits short English headlines will break in German or Finnish. Navigation that fits five English labels might not fit five French ones.
- Text expansion: leave room in buttons, navigation and headings for longer translations, and avoid fixed-width text containers.
- Right-to-left languages: Arabic and Hebrew need mirrored layouts, which is much easier with logical CSS properties from the start.
- Formats: dates, numbers, currencies and addresses differ by locale.
- Fonts: check that your typeface covers every script and accented character you need.
- Images with text: avoid them, or plan to produce a version per language.
The language switcher deserves its own design attention. Use language names written in their own language, keep it in a predictable place, and never use flags for languages. Our guides to designing for multiple languages and language switcher UX cover the details.
Which platform is best for a multilingual website?
Framer, Webflow and Next.js can all run a good multilingual website; the difference is cost structure, editing workflow and control. Framer and Webflow offer built-in localization features, priced as add-ons or per locale depending on the plan, so check each platform's current pricing page. Next.js gives full control over routing and content with internationalized routing and a headless CMS, at the cost of developer setup.
Platform | How localization works | Good fit | Watch out for |
|---|---|---|---|
Framer | Built-in localization as a paid add-on | Small sites with a few languages | Add-on costs as you add locales; check current pricing |
Webflow | Localization add-on with per-locale content | Marketing teams editing visually | Plan limits and add-on pricing |
Next.js with a headless CMS | i18n routing plus localized CMS fields | Many languages, custom workflows, product integration | Needs developer setup and upkeep |
For Next.js specifically, routing, content modeling and translation workflows are covered in multilingual Next.js sites. If you already have a multilingual site on another platform and want to move, the URL and hreflang work is the risky part; read migrating a multilingual website and our guide to redesigning without losing SEO before you start.
What does a multilingual website cost?
A multilingual website costs the base site plus translation and localization, extra design and QA per language, platform fees per locale, and ongoing upkeep as content changes. The ongoing part is the one teams underestimate: every product update, new page and pricing change now has to happen in every language. Cost ranges vary widely by number of languages and pages, which we break down in how much a multilingual website costs.
Confirm the market
Check demand and readiness for one pilot market, using the factors above.
Fix the source site
Make sure the English message and structure work before you multiply them. Picking the right kind of website audit helps decide what to fix first.
Choose structure and platform
Subdirectories by default, on a platform whose localization pricing and editing workflow you can live with.
Localize the selling pages
Homepage, pricing and key landing pages, written or reviewed by native speakers who know the product.
Set up multilingual SEO
Native keyword research, localized metadata, correct hreflang with self-references, return tags and x-default.
Plan the update workflow
Decide who updates each language when the product, pricing or content changes, and how fast.
What should you read next?
Read the guide that matches your next decision. Each one goes deeper on a single part of the plan above.
- Strategy and copy: localization vs translation and what a multilingual site costs.
- Structure and SEO: subdirectory vs subdomain vs ccTLD and hreflang explained.
- Design: designing for multiple languages and language switcher UX.
- Build: multilingual Next.js sites, and if you're moving platforms, Framer to Next.js migration cost.
- AI search: do answer engines cite translated pages?
