A translated website is not the same as a website that ranks in several languages. Multilingual SEO closes the gap: a separate address for every language version, clear signals about how those versions relate, and pages written for the words people actually type in each language. Miss one and the translations sit unseen, or searchers land on a version they can’t read.
This guide takes the search decisions in the order they need to be made. Which languages to launch, the translation workflow and the language switcher’s design are covered in how to plan a multilingual website.
The short answer
To rank in every language you serve:
- Give every language its own URL, usually a subfolder such as
/de/, never a cookie or script on one address. - Let people and crawlers reach every version. Offer a choice instead of redirecting by location or browser language.
- Connect equivalent pages with hreflang, each page listing itself and every alternate, plus an
x-default. - Research keywords in each language rather than translating your keyword list.
- Localise everything search engines read, from titles and slugs to structured data.
Choose a multilingual URL structure
This is the hardest decision to change later, because every internal link, redirect and hreflang tag depends on it.
Are you targeting languages or countries?
Most businesses target languages: the same offer for anyone who reads that language, wherever they live. Some target countries, the other half of international SEO: prices, products, delivery or legal terms differ by market, even where the language is shared.
A language version needs a language code in its URL (/es/). A country version needs a country signal: a country-code domain or a language-and-region folder such as /en-gb/. Don’t put a language version on a country-code domain; it tells Google the content is for one country.
The options compared
| Structure | Example | Strengths | Trade-offs |
|---|---|---|---|
| Country-code domains | example.de |
Clearest country signal | Each domain builds reputation alone; targets one country only; some countries restrict who can register |
| Subdomains | de.example.com |
Can run on separate hosting or platforms | Managed almost like separate sites |
| Subfolders | example.com/de/ |
One install, one set of updates | Harder to split off later |
| URL parameters | example.com/?lang=de |
Quick to build | Not recommended by Google; hard to segment in reports |
Subfolders vs subdomains vs country domains
Subfolders suit most businesses. For one organisation with broadly the same offer in each language, they keep everything in one WordPress install, hosting account and analytics property.
Country-code domains make sense when each country really is a separate business, with the budget to build each domain’s reputation from scratch. Subdomains make sense when a version must live apart, on another platform or server. Whichever you choose, apply the same pattern to every language.
What never works: one address for every language
Cookies, browser settings and JavaScript translate widgets leave one URL, so only one version can be crawled, indexed and ranked; that is why Google recommends a separate URL per language. A translate button helps visitors who have already found you, but gives searchers nothing to find.
Don’t redirect visitors automatically
Sending visitors to “their” version by location or browser language feels helpful. Google advises against it.
Crawlers can get stuck on one version. Google’s documentation notes that Googlebot’s default IP addresses appear to be in the United States and that it usually crawls without an Accept-Language header. Redirect by either, and Googlebot may only ever see one version.
People aren’t always where their language is. Travellers, people living abroad and buyers on a VPN land on the wrong version, and some can’t get back.
Instead:
- Load every version at its own URL, for everyone.
- Suggest, don’t force: a dismissible banner when the browser language doesn’t match the page.
- Use a crawlable switcher: plain links to the equivalent page in each language, not to each homepage.
- Remember an explicit choice on the visitor’s next visit.
Google’s guidance allows one exception: a homepage at the root that sends visitors on to a language version, or asks them to choose one. Mark it as the x-default in hreflang, and make sure every language URL still loads directly.
Get hreflang right
hreflang tells Google which pages are equivalents in other languages or regions, so it can show each searcher the right one rather than, say, your English page in a Spanish-language search. It doesn’t make a page rank, and Google treats it as a hint, not an instruction it must follow.
A correct hreflang set
For a services page in three languages, every version carries the same block in its <head>:
<link rel="alternate" hreflang="en" href="https://www.example.com/services/" />
<link rel="alternate" hreflang="de" href="https://www.example.com/de/leistungen/" />
<link rel="alternate" hreflang="es" href="https://www.example.com/es/servicios/" />
<link rel="alternate" hreflang="x-default" href="https://www.example.com/services/" />Four rules make it work:
- Every page lists itself and all its alternates.
- Every link is returned. If the English page names the German one, the German page must name the English one, or Google ignores the pair.
- Codes follow the standards: an ISO 639-1 language code, optionally followed by an ISO 3166-1 Alpha 2 region code. A region can’t stand alone.
- URLs are absolute and canonical: full
https://addresses of live pages that aren’t redirected or set to noindex.
x-default names the fallback page for searchers whose language matches none of your versions: usually your main-language page, or a homepage where visitors choose a language. It’s optional, and Google recommends it.
Google reads hreflang from <head> tags, HTTP headers (for non-HTML files such as PDFs) or the XML sitemap. It treats the three as equivalent, so pick one; sitemaps suit large sites because the mapping lives in one place. Established WordPress multilingual plugins generate the tags for you, but check what they output.
Regional versions of one language
For one language in several regions, use language-region codes (en-gb, en-us) plus a plain en version as a catch-all for everyone else. Near-identical same-language pages may be treated as duplicates and folded into one canonical; Google advises using canonical tags and hreflang together so each region still sees its own URL. Give each version real local differences: prices, currency, contact details, delivery terms. Google lists local addresses, phone numbers and currency among the signals it can use to work out which country a page serves.
Common hreflang errors
| Error | What happens | Fix |
|---|---|---|
| Missing return link or self-reference | Google ignores the pair | Every page lists the whole set, itself included |
| Invalid codes | uk means Ukrainian; en-uk and jp aren’t valid codes |
Use en-gb for British English and ja for Japanese |
| Canonical points to another language | Google may index only one language | Each version canonicalises to itself |
| Mapped to a non-equivalent page, such as another language’s homepage | The pair is ignored, or searchers land on the wrong page | Link true equivalents only |
How to check it
- View the source of one page per language: the hreflang block should be identical on each.
- Crawl the site with a tool that reports hreflang errors.
- Inspect a translated URL in Search Console and confirm the Google-selected canonical is the page itself.
Google deprecated Search Console’s International Targeting report, which listed hreflang errors, in 2022. At the time of writing (June 2026) there is no dedicated replacement, so a crawler is the practical way to catch errors at scale. The wider crawl and index checks are in our technical SEO checklist.
Translation is not localisation
A faithful translation can still miss every search. Each language needs its own keyword research, and each page should read as if it was written in that language.
Research keywords in every language
The phrase a translator chooses and the phrase people type often differ. In some languages searchers use a borrowed English term; in others, a local word no translator would pick. Run the same keyword research and search intent process for each language, read that language’s results page, and map one primary keyword to each page.
Localise the whole page
Google works out a page’s language from its visible content, so pages that switch language halfway down, or show side-by-side translations, send a mixed message. Keep one language per page, and translate what surrounds the main content:
Machine and AI translation make good first drafts, but unreviewed they bring stilted headings, wrong terminology and keywords nobody searches for. Have a fluent reviewer who knows your field check at least the pages that earn enquiries.
Titles, slugs and schema in every language
Titles and meta descriptions. Write them for each language’s primary keyword rather than translating the originals, and check they still fit: search results shorten long titles to fit the screen, and some languages run much longer than others.
URL slugs. Google’s URL guidance is to use your audience’s language, transliterating where needed, so /de/leistungen/ beats /de/services/. For non-Latin scripts, choose deliberately: native characters display well in browsers but can become long percent-encoded strings when copied into email or analytics, while transliteration avoids that. Settle slugs before launch, because renaming one later means redirects and updated hreflang across the set.
Structured data. Markup describes its own page, in that page’s language. Translate text fields such as service names, descriptions and FAQ answers, and point url properties to the same-language page. Many schema.org types, including articles and web pages, also accept inLanguage with a code such as es. Google’s guidelines say markup must describe content visible on the page, so the Spanish page marks up its own Spanish questions.
Keep multilingual SEO working after launch
Most problems start when one language changes and the others don’t:
- Remove or rename a page in one language, and update the whole set, or the others keep pointing at a redirect or a 404.
- Publish new pages with hreflang in place, or leave them out of the set until the translation exists.
- Give each language an owner who approves its changes. Website governance for large sites covers roles, workflows and translation rules.
- Review each language in Search Console monthly: filter the Performance report by page (URLs containing
/de/) and by country to see which version appears where.
Online stores add currencies, delivery, payments and returns, covered in selling internationally online.
Frequently asked questions
Do I need hreflang if each version is in a different language?
Google can often find and tell apart language versions on its own, but it recommends marking them explicitly. hreflang earns its keep when more than one version could match a search, and matters most when one language has versions for different regions.
Can I translate only part of my website?
Yes, and many sites start with the pages that bring in enquiries. Translate each of those pages in full, not just its menus, and add hreflang only between pages with a true equivalent.
Does the lang attribute affect rankings?
Google says it uses visible content, not the lang attribute, to determine a page’s language. Set it correctly anyway: screen readers use it to choose pronunciation, and WCAG 2.2 requires the page language to be identified (3.1.1 Language of Page, Level A) and passages in another language to be marked (3.1.2 Language of Parts, Level AA).
Should each language have its own XML sitemap?
It isn’t required. Separate sitemaps per language are often convenient, though, because Search Console’s Page indexing report can be filtered by sitemap, showing at a glance how much of each language is indexed.
What to do next
Take these decisions in order, ideally before designs are signed off; the first two are the most expensive to reverse. For how they fit into search as a whole, see our guide to SEO-friendly websites.
These are build-stage decisions, so our multilingual website design and development projects settle the URL structure and hreflang at the planning stage, with separate SEO for each language. If your current site switches languages on a single address, fixing it usually means rebuilding the structure in a website redesign, with every changed URL redirected. Not sure which applies? Talk to us about what your website needs.