SEO for multi-language websites: the best practices

SEO for multi-language websites: what breaks and how to fix it before it costs you

Most multi-language websites are not multilingual SEO problems waiting to happen — they are multilingual SEO problems that already happened, quietly, while everyone was busy translating the homepage.

A translated website and an SEO-ready multilingual website are two different things, and the gap between them is usually measured in rankings you never knew you lost.

Why multi-language SEO breaks before you even write a word

The structural decisions come first, and most teams make them last.

Before a single translated paragraph goes live, three things need to be decided: how the URLs will be organized, how Google will know which version to show to which user, and whether the content will be genuinely localized or just linguistically swapped. Get any of these wrong and the rest of the work — the writing, the keyword research, the link building — lands on a broken foundation.

This is usually the point where marketing wants to launch fast, development wants to keep the CMS (Content Management System) setup simple, and nobody has actually read the Google Search Central documentation on international targeting. The result is a site that ranks in the wrong country, serves the wrong language to the right user, or splits its authority across URLs that Google treats as duplicates.

The irony is that the fixes are not complicated. The decisions are. And the cost of making them after launch is significantly higher than making them before.

Choosing your url structure: the decision that outlasts everything else

There are three main options, and none of them is universally correct.

A subdirectory (example.com/nl/) keeps all language versions under one domain, which means they share domain authority. A subdomain (nl.example.com) separates them at the host level, which Google treats more like independent sites. A country-code top-level domain, or ccTLD (example.nl), sends the strongest geographic signal but requires building authority separately for each domain.

For most businesses, subdirectories are the practical default. They are easier to manage, consolidate link equity, and do not require separate Google Search Console properties for each language — though you will still want separate properties for monitoring. Subdomains make sense when the language versions are genuinely different products or brands. ccTLDs make sense when the geographic signal is critical and the budget for separate domain authority exists.

What changes when you scale from two languages to five is that the maintenance overhead of subdomains and ccTLDs compounds fast. A subdirectory structure does not get harder to manage as you add languages; a ccTLD setup absolutely does.

Decision box

– **Best if:** You are targeting multiple language markets and want to consolidate authority under one domain — use subdirectories.
– **Not ideal if:** Your language versions are genuinely separate brands or products with distinct audiences — subdirectories will feel forced.
– **Likely overkill when:** You are adding one secondary language to a primarily single-market site — a subdirectory with careful hreflang is enough.

hreflang: what it actually does and where it reliably fails

hreflang is an HTML attribute — a signal you add to each page that tells Google which language and region that page is intended for, and which other pages are its equivalents in other languages.

The logic sounds simple. The implementation is where things go wrong. According to an Ahrefs study from 2022, hreflang errors were found on 75% of sites that use it. The most common failures are: the return tag is missing (every page in the hreflang cluster must reference every other page, including itself), the language codes are wrong (use BCP 47 format, as specified by the W3C, e.g., “nl-NL” not “nl_NL”), or the tags point to pages that redirect or return errors.

Google’s own hreflang documentation is the most reliable reference for tag syntax and supported language codes.

A canonical tag — an HTML signal that tells Google which version of a page is the “original” to index — interacts with hreflang in ways that trip up even experienced developers. If your canonical points to the English version from every language page, you have effectively told Google to ignore your hreflang setup. Each language page should self-canonicalize: its canonical tag should point to itself.

The x-default tag is worth mentioning here too. It tells Google which page to show when no other language version matches the user’s settings. It is not a fallback homepage; it is a targeting signal for unmatched locales. Treating it as a catch-all is a common and quietly damaging mistake.

Content localization vs translation: the SEO difference

Translation swaps words. Localization adapts meaning, context, and search intent.

A Dutch user searching for a product does not search the way an English user does. The keywords are different, the phrasing is different, and sometimes the intent is different. Running keyword research in English and then translating the results into Dutch is not multilingual SEO — it is wishful thinking with a dictionary.

According to CSA Research’s 2020 “Can’t Read, Won’t Buy” report, 76% of online shoppers prefer to buy in their native language. That preference extends to how they search. If your Dutch pages are optimized for translated English keywords rather than natural Dutch search phrasing, you are competing in a race you entered in the wrong shoes.

Machine-translated content adds another layer of risk. Google’s quality guidelines treat thin or auto-generated content as a negative signal. A page that reads like it was processed through a translation engine — even a good one — tends to have lower engagement, higher bounce rates, and weaker topical depth. None of those help rankings.

The practical rule: do separate keyword research per language, write or adapt content for each market, and treat each language version as its own editorial product, not a derivative of the original.

Language targeting vs country targeting: not the same problem

Language targeting tells Google what language a page is in. Country targeting tells Google which geographic market a page is for. They overlap, but they are not the same, and conflating them creates real problems.

A page in Dutch could target the Netherlands, Belgium, or Suriname. A page in English could target the UK, Australia, or South Africa. hreflang handles both dimensions: the language code (nl) and the optional region code (NL, BE). If you only specify the language and not the region, Google will make its best guess about which market to serve — and its best guess is not always yours.

Google Search Console has an international targeting report that shows which country Google associates with each section of your site. If you are using subdirectories, you cannot set a country target at the folder level through Search Console — that setting only works for the whole domain or for subdomains and ccTLDs. This is one of the few genuine advantages of ccTLDs: the geographic signal is unambiguous.

For most sites, the right answer is to use hreflang with both language and region codes, and to let the content and link signals do the rest. Trying to force country targeting through technical settings alone, without matching content and local signals, rarely works as intended.

Keeping multi-language SEO healthy over time

A multilingual site is not a one-time setup. It is a system that drifts.

New pages get added in one language and not the others. hreflang clusters break when URLs change and the tags are not updated. A language version that was ranking well six months ago starts slipping because the content has not been refreshed while the original language version has. These are not edge cases; they are the normal lifecycle of a multilingual site that does not have a maintenance process.

The most common failure mode is asymmetry: the primary language version gets all the editorial attention, and the secondary versions get updated only when someone notices they are wrong. By then, the damage to rankings is already done.

If the audit reveals structural problems that go beyond a settings fix, Studio Ubique’s SEO services cover the full technical and content layer.

What to monitor monthly

– hreflang errors in Google Search Console (International Targeting report)
– Indexing status per language version (Coverage report, filtered by URL prefix)
– Organic traffic by language segment in Google Analytics or equivalent
– Ranking positions per language market for core target keywords
– Crawl errors on language-specific URLs after any site update

Managing SEO for a multi-language website requires structural decisions before content decisions: URL format, hreflang implementation, and genuine content localization per market. According to Ahrefs (2022), 75% of sites using hreflang have errors in their implementation. Studio Ubique works with businesses navigating these decisions at the architecture and content level, not just the tag level.

Faqs

What is the best url structure for a multi-language website?

Subdirectories (example.com/nl/) are the most practical choice for most sites because they consolidate domain authority, are easier to manage at scale, and do not require separate Google Search Console properties per language; subdomains and ccTLDs are better suited to situations where language versions are genuinely separate brands or where a strong geographic signal is the priority.

Does hreflang affect rankings directly?

hreflang does not boost rankings; it tells Google which language version to show to which user, so the right page appears in the right market’s SERP (Search Engine Results Page) — without it, Google may rank your English page for Dutch queries or vice versa, which looks like a ranking problem but is actually a targeting problem.

Is machine translation safe for SEO?

Machine-translated content carries real risk: Google’s quality guidelines treat thin or auto-generated content as a negative signal, and pages that read like they were processed by a translation engine tend to have lower engagement and weaker topical depth, both of which hurt rankings over time.

Do i need separate keyword research for each language?

Yes, always — search phrasing, intent, and competition vary significantly between languages and markets, so translating English keywords into Dutch and optimizing for those translated terms is not the same as researching how Dutch users actually search, and the difference shows up in traffic.

How do i know if my multilingual SEO setup is working?

Check the International Targeting report in Google Search Console for hreflang errors, monitor organic traffic and rankings segmented by language market, verify that the correct language version is indexed for each target market, and run a crawl after any site update to catch broken hreflang clusters before Google does.