Multilingual SEO: How to Rank in More Than One Language

Multilingual SEO — making one website rank in more than one language — fails for structural reasons far more often than for content reasons. The translation is usually fine. What breaks is everything around it: the URL architecture, the hreflang annotations, keyword research that never happened in the target language, and analytics that can't tell you which locale actually makes money.

This guide covers those decisions in the order you'll face them, using France as the running example. French is a useful stress test: a large, mature search market where Google dominates, users expect to search and buy in their own language, and literal translations of English keywords routinely miss the terms people actually type. If you're planning a full market entry rather than a language rollout, our international SEO guide covers the bigger picture. This article goes deep on the multilingual mechanics.

Multilingual SEO starts with site architecture

You have three realistic options for structuring language versions. The choice is expensive to reverse, so make it deliberately.

• Country-code domains (example.fr). The strongest geographic signal, and often a trust signal for French users. But every domain starts from zero authority, so ten markets means ten backlink profiles to build. Choose this only if brand or legal considerations force your hand, or if you genuinely have the budget to build authority several times over.

• Subdomains (fr.example.com). Technically easy to set up, but you get the weakest version of both worlds: authority consolidation is unreliable, and the geographic signal is weaker than a ccTLD's. It's rarely the right answer.

• Subfolders (example.com/fr/). One domain, one backlink profile, every language version benefiting from the authority the others earn. For most companies expanding into new languages, this is the correct default.

Then decide whether your folders represent languages or language-market pairs. If France is your only French-speaking target, /fr/ is enough. If you plan to serve France, Belgium and Switzerland with different prices, currencies or offers, you'll need /fr-fr/, /fr-be/ and /fr-ch/ — and you need to accept what that implies. Every locale folder is a standing commitment: content to maintain, hreflang entries to manage, performance to monitor. Launch fewer locales than you think you want, and launch them properly.

The consolidation argument isn't theoretical. When we ran SEO and link building for BMW Europe Moto, the official distributor of BMW motorcycle parts, the single-platform, market-by-market approach opened six new markets in organic search, generated more than 55,000 organic visitors, and consolidated the site's Domain Rating at 70. Every new market launched on top of authority the previous ones had already earned.

Getting hreflang right (and the four ways it usually breaks)

Hreflang is the annotation that tells Google which language and regional versions of a page belong together, so it can serve French users the French URL and British users the English one. Google documents it in its Search Central guidelines on localized versions, and you can implement it in three places: link elements in the HTML head, HTTP headers (useful for PDFs and other non-HTML files), or your XML sitemap. Pick one method and stay consistent. Debugging hreflang is painful enough without annotations scattered across three layers.

Keep in mind that hreflang is a hint, not a directive, and Google ignores hints that don't validate. Four mistakes account for most broken implementations.

Missing return links

Hreflang only counts when it's reciprocal. If your English page points to the French version, the French page must point back — and every version in the cluster should reference every other version, including itself. The moment page A references page B but B doesn't reference A, that relationship can be dropped. This is why hand-maintained hreflang falls apart at any real scale: annotations should be generated from a single source of truth, typically your CMS's translation relationships, never edited page by page.

Wrong language and country codes

Language codes come from ISO 639-1 and country codes from ISO 3166-1 Alpha 2, and mixing them up produces annotations that fail silently. The classic errors: writing en-UK instead of en-GB (the United Kingdom's country code is GB), and trying to target a country without a language. Note that fr on its own means the French language everywhere, not France; France specifically is fr-fr. If you run a single French version for all francophone users, plain fr is correct and usefully broad. Just make sure that's a decision, not an accident.

Misusing x-default

The x-default value tells Google which version to serve users who match none of your declared languages. Point it at your language selector or your primary international version. The common failures are omitting it entirely, or pointing it at a URL that redirects or is blocked from indexing. Every URL in an hreflang cluster, x-default included, needs to resolve with a 200 status and be indexable.

Redirecting visitors by IP address

Forcing users onto "their" version based on IP feels helpful and quietly sabotages the whole setup. Googlebot crawls mostly from US IP addresses, so an aggressive geo-redirect can prevent it from ever seeing your French pages. It also infuriates real people: the French expat in London, the anglophone in Paris. Suggest the local version with a dismissible banner. Never force it.

One more interaction worth checking: canonicals. Each language version should declare itself as canonical. Teams sometimes canonicalize French pages to their English originals "to consolidate signals" — which tells Google the French pages shouldn't be indexed at all. Hreflang cannot rescue a page you've canonicalized away.

Keyword research for multilingual SEO: translate the intent, not the words

French buyers don't search for translations of English keywords. They search in French, with the vocabulary of the French market, and the gap between a correct translation and the actual search term is where most multilingual SEO quietly dies.

Two examples we see constantly. An English retailer ranking for "sneakers" will get a technically perfect translation like "chaussures de sport" — while French shoppers overwhelmingly type "baskets". A refurbishment marketplace translating "refurbished phone" literally might land on "téléphone rénové", when the entire French market has standardized on "reconditionné". Both translations are correct. Both would target pages at terms far smaller than the real demand.

The working process looks like this:

1. Treat your source-language keyword set as a list of intents, not strings.

2. For each intent, have a native French speaker with SEO training identify the terms people actually use.

3. Validate against French search data. Volumes don't map one-to-one: an English head term may split into three distinct French queries, or several English variants may collapse into one.

4. Check the French SERPs for each priority term. The "same" query can be transactional in one market and informational in another, and your competitors in France will not be the ones you know from home.

This is the core argument of our guide to SEO translation: the deliverable is not translated pages, it's pages built on local keyword research. And keywords are only one layer of adaptation — currencies, trust signals, proof points and France's legal requirements around French-language consumer information all shape whether a page converts once it ranks. We cover that side in our guide to website localization for the French market.

The duplicate-content traps that quietly sink multilingual sites

First, the misconception: translated content is not duplicate content. A French translation of an English page is a different page in Google's eyes, and you will not be penalized for publishing it. The real traps are elsewhere.

• Same language, multiple regions. If /fr-fr/ and /fr-be/ pages are near-identical, Google may treat them as duplicates and pick one to index. Hreflang helps serve the right version, but don't spin up regional variants without regional substance — different prices, availability, contact details, delivery terms.

• CMS locale fallback. Many systems render the source-language content at the localized URL when a translation is missing. The result is dozens or hundreds of English pages living under /fr/, competing with your real English pages. Untranslated pages should not exist as live URLs. Keep them unpublished, noindexed or redirected until the translation ships.

• One URL, many languages. Serving language via a ?lang=fr parameter, a cookie, or the browser's Accept-Language header on a single URL is a dead end. Google indexes URL by URL, and one URL can only rank as one thing. Every language needs its own stable, crawlable URL.

• Unreviewed machine translation. Machine output at scale, published without human review, risks being treated as low-value auto-generated content — and reads that way to users. MT as a first draft is fine. MT as a publishing strategy is not.

Sitemaps and the CMS: the plumbing that decides whether this scales

For sites with more than a handful of locales, put hreflang in the XML sitemap rather than the HTML head. Head-based annotations add one link element per locale to every page — at ten locales, that's ten-plus tags on every URL — and they're miserable to audit. A sitemap centralizes the entire annotation set in files you can validate programmatically. Structure it as a sitemap index with one sitemap per locale, and per-locale indexation debugging in Search Console becomes almost pleasant.

Your CMS decides whether any of this is sustainable. Five questions filter platforms quickly:

• Can slugs be translated? You want /fr/chaussures-de-securite, not /fr/safety-shoes.

• Are titles and meta descriptions separate fields per language, or inherited from the source?

• Is hreflang generated automatically from translation relationships — and only for versions that are actually published?

• Is fallback behavior explicit, so untranslated pages never render source-language content at a localized URL?

• Can editors see translation status, so marketing knows what's live and what's pending?

Retrofitting any of these later usually means a migration. It is far cheaper to ask the questions before the build.

Measuring multilingual SEO by locale

The subfolder architecture pays off a second time here: register each locale folder as its own URL-prefix property in Google Search Console (example.com/fr/), and you get per-locale clicks, impressions and indexation coverage without any spreadsheet gymnastics. Four things deserve regular attention:

• Per-locale query reports. Are French pages earning French queries, or accidentally ranking for English ones?

• Country and language mismatches. French pages collecting most of their impressions outside francophone countries usually point to an hreflang or targeting problem.

• Wrong-version rankings. Search your priority French keywords from a French context. If /en/ pages outrank your /fr/ pages in France, something is off in hreflang, internal linking or content depth.

• Conversions per locale, not just traffic. A locale that earns visits but no revenue has a keyword-intent problem or a trust problem — payment methods, language quality, local proof.

France adds one wrinkle worth planning for: the CNIL, France's data protection authority, is among Europe's stricter regulators on analytics consent, so your measurement stack needs the same care as your content. Getting consent-compliant, per-locale tracking right is exactly the kind of foundation our web analytics team builds before any optimization work starts, because you cannot improve locales you cannot measure.

Frequently asked questions

Should I use subfolders or subdomains for a multilingual website?

Subfolders, in almost every case. They consolidate authority on one domain, simplify maintenance, and make per-locale measurement trivial. Subdomains fragment your link equity for no meaningful benefit. Country-code domains are defensible when brand or legal constraints demand them, but they multiply the authority-building work by the number of markets.

Do I need to translate every page of my site?

No. Translate the pages that have search demand and a conversion role in the target market. A blog post about a US-specific topic may have no French audience at all, and forcing it into French adds cost without traffic. A partial rollout done well beats a complete rollout done thin. Whatever you choose not to translate should simply not exist as a live URL in that locale.

Is machine translation good enough for multilingual SEO?

As a first draft, yes — provided a native speaker reviews it and, critically, adapts it to real French search terms. Published raw, it carries both a quality risk and a commercial one: machine output translates your words, not the keywords French users actually type, so even flawless pages can target the wrong terms.

How long does it take for a new language version to rank?

There's no honest universal number. New locale sections need to be crawled, indexed and evaluated, and competitive French head terms take considerably longer than long-tail queries. Think in months, not weeks. The early signals worth watching are indexation coverage and long-tail impressions in the new locale — if those appear within the first weeks, your foundations are sound and rankings tend to follow.

Ready to rank in French?

Multilingual SEO rewards teams that get the unglamorous parts right: architecture chosen once and correctly, hreflang generated rather than hand-edited, keywords researched in the target language, and measurement that isolates each locale. If France or another French-speaking market is on your roadmap, talk to our team — we're a French agency with over 200 published case studies, and we're happy to pressure-test an architecture plan or an hreflang setup before you commit engineering time to it.