Multilingual SEO: a complete guide for 2026
How multilingual SEO works: URL structure, hreflang, translation, keyword research and redirects, with what each decision costs and how to check it is working.
Multilingual SEO is the work of making each language version of your site findable by people searching in that language. It rests on four decisions: one URL per language, hreflang tags that link the versions together, translation that uses the words locals actually search, and no forced redirects that hide versions from search engines.
Getting those four right is mostly engineering and editing, not magic, and it is the kind of work our technical SEO service exists to do. This guide explains each decision, what it costs, and how to tell whether it is working.
On this page
What is multilingual SEO, and how is it different from international SEO?
Multilingual SEO is about languages. International SEO is about countries. They overlap, but they are not the same job, and mixing them up is where most expensive mistakes start.
A multilingual site offers the same business in several languages: a software company with English, French and German versions, for example. A multi-regional site targets different countries, which may share a language: separate pages for the United States, the United Kingdom and Australia, all in English. Many sites are both at once. Google describes these as two separate cases and handles them with the same tools, mainly clear URLs and hreflang annotations [1].
The difference matters because the signals differ. For a language, the content itself is the main signal: a page written in Spanish is plainly for Spanish readers. For a country, the signals are weaker and more technical, such as a country-code domain, local currency, local addresses and hreflang with a region code. If you sell the same English page in five countries, you need those technical signals, or search engines will pick one version and ignore the rest.
Before you build anything, write down which of the two you are doing. If the answer is "different languages for a global audience", you need language targeting only. If it is "different prices, stock or legal terms per country", you need country targeting as well, and that pushes you toward the heavier options in the next section. The trade-offs between one global site and separate country sites are laid out in single global site vs country sites, and it is worth deciding that before anyone touches a template.
Which URL structure should a multilingual site use?
Use a structure that gives each language its own address and that you can maintain. For most businesses that is a subfolder per language on your main domain, such as /fr/ and /de/. Country-code domains and subdomains are valid too; they just cost more to run.
Google lists the main options and is neutral about which you pick, as long as each version has its own URL [1]. What it advises against is using URL parameters like ?lang=fr as your main signal, and changing the language on a single URL based on cookies or browser settings. Both make it hard for a crawler to find and index each version separately.
Here is how the three common structures compare in practice.
| Structure | Example | Strongest for | Main cost |
|---|---|---|---|
| Subfolder | example.com/fr/ | Most businesses; shares the main domain's authority | Weaker country signal on its own |
| Subdomain | fr.example.com | Teams that need separate hosting or platforms per market | Can behave like a separate site for authority |
| Country-code domain | example.fr | Strong country targeting and local trust | Separate domains to buy, host and build links to |
| URL parameter | example.com/?lang=fr | Not recommended as the main signal | Hard for crawlers to treat as separate versions |
Subfolders win for most sites because every link you earn helps every language at once. A new French section inherits the reputation the English site has already built, instead of starting from nothing. Country-code domains are worth their cost when local trust really depends on them, or when legal and payment rules force a separate entity per country.
Subdomains sit in between, and they usually exist because of how a platform works rather than because of a strategy. If your shop platform or translation tool forces subdomains, that is fine, but budget for the extra effort to make them rank. The full comparison, with costs and migration risks, is in ccTLD vs subfolder vs subdomain.
Whichever you pick, do not change it lightly later. Moving languages from subdomains to subfolders is a site migration, with redirects, re-crawling and a dip in traffic while search engines catch up.
How does hreflang work, and why does it break so often?
Hreflang is an annotation that tells search engines, "this page has versions in these other languages or regions, and here are their URLs". It helps the right version appear for the right searcher. It does not make pages rank higher; it swaps the version shown.
You can add hreflang in three places: link elements in the page head, HTTP headers for files like PDFs, or your XML sitemap [2]. All three do the same job. Pick the one your platform handles best, and use only one method so the signals never contradict each other.
The rules are strict, and that is why hreflang breaks so often. Every version must list every other version and itself. If the French page points to the German page, the German page must point back, or search engines may ignore the pair [2]. Codes must be valid: a language code, optionally followed by a region code, such as fr or fr-CA. A region on its own is not valid. Each URL in the set must be the canonical, indexable version of that page, not a redirect or a blocked URL.
The usual failures are boring. A developer adds a new language and forgets to update the old pages. A plugin writes en-UK instead of en-GB. Canonical tags on the translated pages point at the English original, which tells Google to ignore the translation entirely. Each of these is easy to fix once found, and easy to miss for months.
For the step-by-step setup, with code examples for head tags and sitemaps, read how to implement hreflang tags. For the fallback value that catches everyone who does not match a listed version, read how x-default hreflang works, which covers when to point it at a language selector and when at your main site.
How do you do keyword research in another language?
Research each market from scratch in its own language. Translating your English keyword list gives you words that are grammatically correct and that nobody searches.
People describe the same need differently in each language and country. A term that is one word in English may be three words in German, or a loanword from English that locals prefer over the "correct" translation. Some markets search for a product by its brand name; others by what it does. Search volume and competition change too, so a keyword you cannot win in English may be wide open in another language.
The practical process is simple. Start from your English topics, not your English keywords. Have a fluent speaker brainstorm how they would search for each topic. Check those phrases in a keyword tool set to the target country and language. Look at what currently ranks, because it shows you the intent search engines reward there. Then map the winning phrases to pages before translation starts, so the translator writes toward them.
This research often changes the site itself, not just the words. You may find that one market needs a page you never built in English, or that a page you rely on at home has no demand abroad. That is normal, and it is a good reason to plan the research before you commit to translating everything. The full method, with tools and a worked example, is in international keyword research.
Should you use machine translation for SEO?
Use it as a first draft, never as the final page. Machine translation has become good enough to save real time, but unreviewed output published across a whole site is risky for rankings and for trust.
Google's spam policies name scaled content abuse: producing many pages mainly to manipulate rankings, with little value for users, whether made by people, automation or both [4]. A site that auto-translates thousands of pages without anyone checking them fits that pattern closely. Even when it does not trigger a policy, raw machine output tends to miss the local phrases your keyword research found, get product terms wrong and read as awkward to native speakers.
A workable pipeline looks like this: machine-translate, then have a fluent editor fix meaning, terminology and tone, then swap in the target keywords for titles, headings and descriptions, then publish. Keep a glossary of your product terms and brand phrases so the tool and the editors stay consistent. For high-value pages, such as your homepage, pricing and top product pages, consider a full human translation instead.
There are good reasons to be cautious with translation tools that serve translated text only through scripts on page load, too. If the translated text never appears in the HTML a crawler receives, it may not be indexed at all. The trade-offs, including when full human translation pays for itself, are covered in machine translation and SEO.
Should you redirect visitors by IP address or browser language?
No, not automatically. Suggest a better version, but let the visitor stay where they landed. Forced redirects are the fastest way to make whole language versions invisible to search engines.
The reason is how crawlers work. Google says Googlebot's crawls mostly come from IP addresses in the United States, and that it may not send an Accept-Language header with its requests [3]. If your site sends every US visitor to the English version, Googlebot may never see your French or German pages. Google's own advice is to use separate URLs with hreflang instead of changing content based on where a visitor appears to be [3].
Forced redirects also annoy people. A traveller in Paris who reads English gets pushed to French. A French speaker in Canada gets pushed to a page built for France, with the wrong currency. Both leave.
The better pattern is a banner or small dialog: "It looks like you are in France. View the French site?" with a clear choice and a remembered preference. Every version stays reachable by a normal link, and hreflang does the job of showing the right version in search results. For the exact rules on when a redirect is acceptable and how to build the banner, read geo IP redirects and SEO.
How should a language switcher be built?
Build it as plain links, one per language, pointing to the equivalent page in that language, not to each language's homepage. That one detail makes the switcher useful to people and to crawlers at the same time.
Crawlers follow links. A switcher built from real anchor tags gives search engines another path to every language version, and it keeps readers on the page they were reading when they switch. A switcher that runs on a script, a form or a dropdown that changes a cookie gives crawlers nothing to follow and often dumps readers on the homepage.
A few design details matter more than they seem. Show each language name in its own language, "Deutsch" rather than "German", so a reader who does not know your default language can still find theirs. Avoid flags for languages, because flags are countries: Spanish is spoken in many countries and one flag excludes the rest. Put the switcher in the same place on every page, usually the header or footer. And if a page has no translation, either hide that language for that page or link to the nearest useful page, never to a 404.
These are small decisions, but they compound across thousands of pages. The full guidance, including how to pair the switcher with the redirect banner, is in language switcher SEO.
Which translation plugin or platform should you use?
Pick the tool that puts translated text in the HTML, gives each language its own URL, and writes hreflang for you. After that, the choice is about workflow and budget, not SEO.
Most platforms offer two families of tools. Proxy or cloud tools translate your site through a service and serve the result, which is quick to set up and usually priced by words and languages. Plugin-based tools store translations inside your own database, which gives more control and fewer outside dependencies but more work to manage. Both can be done well or badly for SEO.
| Check | Why it matters for SEO | What good looks like |
|---|---|---|
| Translated text in the HTML | Crawlers must see the translation without running scripts | View source shows the translated words |
| Own URL per language | Each version needs an address to be indexed | Subfolder or subdomain per language |
| Hreflang generated | Manual hreflang across thousands of pages breaks | Complete, reciprocal tags on every page |
| Translated slugs and metadata | Titles, descriptions and URLs carry keywords | Editable per language, not copied from English |
| Editor workflow | Machine drafts need human review | Easy review queue and glossary support |
Run these checks on a trial before signing a yearly plan. The most common trap is a tool that looks translated in the browser but serves the original language in the page source, which means search engines index your English text on your French URLs.
For WordPress, the two names most people compare are covered in Weglot vs WPML, including how each handles URLs, hreflang and price as the number of words grows.
How is multilingual SEO different for an online store?
A store multiplies every multilingual problem by the size of its catalogue, and adds country problems on top: currency, tax, shipping and stock. The fundamentals are the same, but the scale forces automation, and automation needs rules.
Start with what changes per market. If prices, stock or delivery differ by country, you probably need country versions, not just language versions, and hreflang with region codes. If only the language changes, language versions are enough. Many stores need a mix, for example one French version for several countries plus country-specific pricing handled on the page.
Then decide what gets translated by a human and what does not. Category pages and top-selling products deserve careful translation, because they carry most of the search demand. The long tail of the catalogue can often start from a reviewed machine draft. Product attributes, sizes and units need a mapping, not a translation: a size chart in centimetres and one in inches are different data, not different words.
Watch structured data too. Price, currency and availability in your product markup must match the page each market sees, or you will send confusing signals and lose rich results. The full playbook for cross-border stores is in international ecommerce SEO, and the page-level details, from titles to reviews, are in translating product pages.
Do Baidu, Naver and Yandex need different work?
Yes, if those markets matter to you. The basics carry over, but each engine has its own habits, its own webmaster tools and different signals.
Most multilingual work in this guide targets Google and Bing, which follow similar rules. Some markets, though, have a strong local engine. Naver is a major engine in South Korea, Baidu leads in mainland China, and Yandex has a large share in Russian-speaking markets. Each has its own tools for submitting sitemaps and checking indexing, and each treats hreflang, hosting and content differently.
China is the most different case. Hosting, access speed and local registration requirements can matter as much as content, and a site that loads slowly from inside the country struggles no matter how well it is written. That is a business and legal decision before it is an SEO one.
If these markets are not in your plan, skip them for now; doing Google well in five languages beats doing four engines badly in one. If they are in your plan, read SEO for Baidu, Naver and Yandex before you build, because some of their requirements shape the architecture.
How do you launch a new language version step by step?
Treat a new language like a small site launch: plan, build, check, release, then measure. Skipping the check step is how most hreflang and indexing problems ship.
Pick the market and the goal
Choose one language or country you can already sell to and support, and write down what success means: leads, sales or sign-ups from that market.
Research keywords in that language
Have a fluent speaker find how locals search for your topics, and map those phrases to the pages you will translate.
Decide the URL structure
Use a subfolder unless there is a clear reason for a country domain or subdomain, and keep it consistent with any future languages.
Translate and edit
Draft with machine translation or a translator, then have a fluent editor fix meaning and add the target keywords to titles, headings and descriptions.
Add hreflang and self-canonicals
Every page lists all its versions and itself, and each translated page's canonical points to itself, not to the original.
Build the switcher and banner
Plain links to the equivalent page in each language, plus a suggestion banner instead of forced redirects.
Check before release
Crawl the new section, confirm the translated text is in the HTML, validate hreflang return links and submit the updated sitemap.
Measure per language
Filter search performance by the new subfolder or domain and track impressions, clicks and conversions for that market separately.
Most of these steps take days, not months. The slow part is translation and editing, which scales with the number of pages. For a full pre-launch list you can hand to a developer, use the international SEO checklist.
How much does multilingual SEO cost?
The cost splits into setup and ongoing work, and translation usually dominates both. Engineering is a one-time cost; words are paid for every time you publish or update a page.
Setup covers the URL structure, hreflang, the switcher, templates and a pre-launch audit. On a modern platform with a good plugin, that is a small project. On a custom site with years of quirks, it can take a developer several weeks. Translation is priced per word or per page by agencies and freelancers, and per word or plan tier by translation tools. Reviewed machine translation costs less per word than full human translation, which is why most sites use a mix.
Ongoing costs are the part people forget. Every English update needs a matching update in each language, or versions drift apart. Every new language adds pages to monitor for hreflang errors and indexing problems. Budget for maintenance per language, not just for launch.
If you are deciding whether to hire help, best international SEO agencies explains what to look for and what a fair scope includes. Our own plans and what they cover are on the pricing page. We are biased here, so compare us against that list.
How do you know multilingual SEO is working?
Measure each language version on its own. A single site-wide traffic number hides whether the French section is growing or the English section is carrying everything.
Filter your search console data by subfolder, subdomain or domain, one per language. Look at three things in order. First, indexing: are the translated pages indexed, or listed as duplicates or excluded? Second, impressions: are they appearing for searches in their language and country? Third, clicks and conversions: are people from that market arriving and doing what you want?
Then check for the classic warning signs. English pages ranking in a French market usually mean hreflang or canonical problems. Translated pages marked as duplicates usually mean canonicals point to the original. Impressions without clicks usually mean titles and descriptions were translated literally and do not match local searches.
A new language on an established domain often shows impressions within weeks of indexing. Steady traffic and sales usually take three to six months, longer for a new country domain with no links. If nothing is indexed after a month, stop translating and fix the technical setup first.
What this guide covers next
Each topic above has a deeper guide. For setup, start with how to implement hreflang tags and x-default hreflang, then choose your structure with ccTLD vs subfolder vs subdomain and single global site vs country sites. For content, read international keyword research, machine translation and SEO and translating product pages. For user experience, see geo IP redirects and the language switcher. Stores should read international ecommerce SEO, WordPress sites Weglot vs WPML, and anyone targeting local engines SEO for Baidu, Naver and Yandex. When you are ready to launch, work through the international SEO checklist, and if you want outside help, compare the best international SEO agencies.
Questions people also ask
Does Google treat translated pages as duplicate content?
No. A page and its real translation are different content in Google's eyes, because they serve different readers. Duplication becomes a problem when you publish near-identical pages in the same language for several countries without hreflang to tell Google how they relate.
Can I just use Google Translate on my whole site?
You can, but unreviewed machine output published at scale can fall under Google's scaled content abuse policy, and it rarely matches how people in that market actually search. Use machine translation as a first draft, then have a fluent editor fix terms, tone and keywords before publishing.
Should I redirect visitors to their language automatically?
Not with a forced redirect. Googlebot mostly crawls from US addresses, so forced IP or browser-language redirects can hide your other versions from it. Suggest the right version with a banner and let people choose, and keep every version reachable by a plain link.
How long does multilingual SEO take to show results?
A new language version on an established domain often starts getting impressions within weeks of being indexed, and steady traffic in three to six months. A new country domain with no links starts from zero and usually takes longer.
How many languages should I launch with?
Start with the one or two markets where you can already sell, support and ship, and do them properly. Adding languages you cannot maintain creates stale pages that hurt trust with readers and search engines alike.
Sources
- Managing multi-regional and multilingual sites — Google Search Central (checked 23 September 2026)
- Tell Google about localized versions of your page — Google Search Central (checked 23 September 2026)
- How Google crawls locale-adaptive pages — Google Search Central (checked 23 September 2026)
- Spam policies for Google web search — Google Search Central (checked 23 September 2026)
Find out what is holding back your other languages
Book a free 30-minute consultation with Ibrahem and Jeremy. We look at your site while we talk, and you leave with a prioritised plan.
Who wrote this
Ibrahem HelalCo-founder
Leads strategy and delivery.
Works on: SEO, GEO
Reviewed before publishing by Jeremy Zava, Co-founder.
- How to Implement Hreflang Tags CorrectlyHreflang tells search engines which language or country version of a page to show; how to add it, in the head or a sitemap, with a worked example.
- ccTLD vs Subfolder vs Subdomain for SEOThree ways to structure a site across countries, what each one costs to run, and how Google actually treats them — with a decision process, not just a table.
- International Ecommerce SEO: A Practical GuideHow to structure, translate and rank a store across multiple countries without splitting your authority or shipping the wrong currency to the wrong market.
- The international SEO checklistEverything to check before, during and after an international launch: URL structure, hreflang, translation review and market-by-market monitoring.