Translating your site does not automatically get you traffic. Learn how to pick a URL structure, implement hreflang correctly, avoid duplicate-content traps, and make search engines serve the right language to the right user.
A team spends three months translating their marketing site into eight languages. They launch. Six months later, organic traffic from Germany, Japan, and Brazil is roughly unchanged, and the English pages still outrank the translated ones for translated queries.
The translations were fine. The plumbing was not. Search engines never learned that those pages existed, or they learned about them and decided they were duplicates of each other.
Localization SEO is mostly three decisions: what your URLs look like, how you tell crawlers which page belongs to which audience, and how you avoid competing with yourself. Get those right and the translations do their job.
Search engines need a distinct, crawlable URL per language. There are three viable patterns.
| Pattern | Example | Best for |
|---|---|---|
| Subdirectory | example.com/de/pricing | Almost everyone. Inherits domain authority. |
| Subdomain | de.example.com/pricing | Separate infra or teams per region |
| ccTLD | example.de/pricing | Strong local brand, legal or trust requirements |
Default to subdirectories. Every localized page benefits from the authority your main domain has already accumulated, there is one SSL certificate, one analytics property, and one deployment. ccTLDs give the strongest geo-signal but mean starting each country's domain authority from zero, plus buying and defending a dozen domains.
What is not viable: a query parameter (?lang=de) or, worse, switching language purely in client-side state with no URL change at all. If the German version of a page has no unique URL, it cannot be indexed, linked to, or shared.
Use /de/ when the content is the same for all German speakers. Use /de-at/ and /de-ch/ only when the content genuinely differs -- different pricing, currency, legal terms, or shipping. Splitting a locale you do not actually differentiate just divides your own ranking signals across near-identical pages for no benefit. If you are unsure which codes to use, our guide to locale codes and BCP 47 covers the common traps, such as en-UK instead of en-GB.
hreflang is how you tell Google "these pages are the same content in different languages -- show each user the right one." Without it, your German and Austrian pages look like duplicates and Google picks one, often the wrong one.
A correct annotation set on the English pricing page looks like this:
<link rel="alternate" hreflang="en" href="https://example.com/pricing" />
<link rel="alternate" hreflang="de" href="https://example.com/de/pricing" />
<link rel="alternate" hreflang="ja" href="https://example.com/ja/pricing" />
<link rel="alternate" hreflang="pt-br" href="https://example.com/pt-br/pricing" />
<link rel="alternate" hreflang="x-default" href="https://example.com/pricing" />Four rules decide whether this works or is silently ignored:
/de/pricing does not point back at /pricing, Google discards the whole annotation as unconfirmed.pt-br is valid. pt-BR is accepted case-insensitively. br alone means Breton, not Brazil -- a genuinely common bug.In the App Router, generate the set from your locale list rather than hand-writing it (this assumes locale-prefixed routing like the one in our next-intl setup guide):
export async function generateMetadata({ params }) {
const { locale, slug } = await params;
const path = `/${slug}`;
return {
alternates: {
canonical: `https://example.com/${locale}${path}`,
languages: Object.fromEntries([
...locales.map((l) => [l, `https://example.com/${l}${path}`]),
["x-default", `https://example.com/en${path}`],
]),
},
};
}Generating from a single source list is what keeps the set reciprocal. Hand-maintained hreflang blocks drift within about two sprints.
This is the single most common way teams destroy their own multilingual SEO:
<!-- On /de/pricing -- WRONG -->
<link rel="canonical" href="https://example.com/pricing" />That tag tells Google the German page is a duplicate of the English one and should not be indexed at all. Your translation is now invisible. Every localized page needs a self-referencing canonical:
<!-- On /de/pricing -- correct -->
<link rel="canonical" href="https://example.com/de/pricing" />Canonical and hreflang answer different questions. Canonical says "this is the definitive URL for this content." hreflang says "here are the other language versions." They coexist; they do not substitute for each other.
Detecting a visitor's country and forcibly redirecting them is intuitive and wrong for three reasons:
The safer pattern: detect once, suggest rather than force, and remember the choice. Use the Accept-Language header for a first-visit default on the root path only, show a dismissible banner ("Read this in Deutsch?"), and persist the user's explicit choice in a cookie. Never redirect a crawler, and never redirect a user who arrived on a specific localized URL.
<html lang="de">Trivially small, and it drives screen-reader pronunciation, browser translation prompts, and correct hyphenation. Set it from the active locale, not statically.
List every locale URL in your sitemap, and include the xhtml:link alternate annotations there too. A sitemap is often how a new locale gets discovered at all:
<url>
<loc>https://example.com/pricing</loc>
<xhtml:link rel="alternate" hreflang="de" href="https://example.com/de/pricing"/>
<xhtml:link rel="alternate" hreflang="ja" href="https://example.com/ja/pricing"/>
</url>
Titles, meta descriptions, Open Graph tags, image alt text, and JSON-LD all need localizing. A German page with an English <title> ranks for nothing in German -- the title tag is still one of the strongest on-page signals you control.
This is where literal translation costs you the most. Germans search "Handy" for a mobile phone, not "Mobiltelefon." A direct translation of your best-performing English keyword is frequently a phrase nobody in that market types. Run keyword research per locale (and use it to decide which languages to launch first) and let your translators adjust headings accordingly -- a page that reads naturally and uses the phrases locals actually search will outperform a technically accurate translation every time.
/de/preise beats /de/pricing for both relevance and click-through. It costs you a slug mapping in your routing config. Decide early -- changing slugs later means redirects.
<html lang> matches the page's actual language.<title> translated? The meta description? The OG image alt?curl from a US IP. Do you get a 200, or a redirect to English?SEO is only one part of a launch. Our localization checklist for developers covers the rest of what to verify before a new locale goes live.
hreflang is an HTML annotation that tells search engines which language and region a page targets and where its alternate language versions live. Without it, translated pages look like near-duplicates and search engines may index only one of them.
Subdirectories such as example.com/de/ are the safest default because every locale inherits the authority of your main domain and you maintain one deployment. Use ccTLDs only when you have a strong local brand or legal requirement, since each country domain starts its authority from zero.
Every localized page needs a self-referencing canonical pointing at its own URL. Pointing the German page's canonical at the English version tells search engines the translation is a duplicate and it will not be indexed.
No. Search crawlers mostly request pages from US IP addresses, so IP-based redirects can prevent localized pages from being indexed at all. Suggest a language with a dismissible banner, remember the user's explicit choice, and never redirect a user who landed on a specific localized URL.
Yes. Titles, meta descriptions, Open Graph tags, image alt text, and structured data all need localizing. Keywords also should not be translated literally, since the phrase people actually search in a market is often different from a direct translation.
Translation is the content problem. hreflang, canonicals, and URL structure are the discovery problem, and solving only the first one means paying for translations that nobody finds. Give every locale a real URL, wire the hreflang set reciprocally from a single source of truth, keep canonicals self-referencing, and suggest a language instead of forcing one.
If keeping translated titles, descriptions, and metadata in sync across a growing set of locales is the part that keeps slipping, Babelize handles it as part of your normal Git workflow so a new page ships localized metadata on day one rather than three sprints later.
--- - [All articles](https://www.babelize.co/blogs)