How to Build a Multilingual SEO Strategy
On this page
The strategic decisions come before any hreflang tag. Multilingual SEO is a sequence of investment choices: which languages to build, whether to target a language or a specific country, which URL structure to use, and how far to localize rather than translate. Make those well and the implementation becomes largely mechanical. Make them on autopilot, with a domain per country and word-for-word translation, and you can end up maintaining several thin sites with content that misses how each market searches. One well-localized Spanish version can serve searchers in Spain, Mexico and Argentina; separate country versions earn their cost only where the markets differ in ways that change the content.
Multilingual versus multi-regional
Google’s guide to managing multi-regional and multilingual sites draws the line: a multilingual website is any site that offers content in more than one language, and a multi-regional website is one that explicitly targets users in different countries. They aren’t the same decision, and treating them as one is an early strategic error.
Targeting a language means one version serves everyone who reads it. Google’s guide to localized versions supports language-only codes, such as de for German content independent of region, so a single Spanish version can be annotated for Spanish speakers everywhere.
Targeting a country means a separate version per market, such as es-ES and es-MX, each tuned to local pricing, currency, regulation and search behavior, and each needing its own content, links and upkeep.
The decision is a trade-off between concentration and precision. Do you need to distinguish Mexican from Argentine Spanish, or does one well-localized Spanish version meet the demand? Start with languages, and split into country versions only where a real market difference, such as pricing, legal requirements or clearly different search patterns, justifies maintaining separate pages.
Localize, don’t just translate
Translation and localization aren’t the same, and the right amount of localization varies by content type. Word-for-word translation can miss local search patterns: people in different markets phrase the same need differently, and a literal translation of your English keywords may not match what they type. At the other extreme, rebuilding every page from scratch throws away the structure you already have.
Localization is the middle path: keep the page’s structure, do fresh keyword research in the target language, and adapt culturally where it matters while translating directly where it doesn’t.
- Translate directly: product descriptions, technical specifications and other content whose meaning is stable across markets.
- Localize fully: anything where local context changes the substance, such as case studies and social proof, pricing and currency, examples, and compliance or legal content.
Translate the main content, not just the frame around it. Google’s multi-regional guide recommends a single language for content and navigation on each page, avoiding side-by-side translations, and notes that translating only the boilerplate while keeping the bulk of a page in another language can create a bad user experience when the same content appears multiple times in results with different boilerplate languages.
The keyword research step is easy to skip. Local search behavior is its own input: find the queries people use in the target language and build the localized page around them, rather than translating the keywords you already rank for and hoping they map.
AI translation: drafts, not publishing
Machine translation can produce a usable first draft and speed up localization. Don’t publish it unreviewed on pages where trust matters. For anything that affects a purchase, a legal or compliance statement or your credibility, have a native speaker review before publication, because text can be technically correct and still read as foreign, miss idiom or shift nuance. Use AI to speed up the draft; keep a person as the final pass on pages where trust is the conversion.
Prioritize languages by evidence
Trying to build every language at once can spread the effort too thin. Search responds to queries people already make, so rank languages by evidence of those queries:
- Impressions you already earn. Search Console’s Performance report can group data by country, and its comparison feature puts two countries side by side, such as the USA versus France. Impressions your current content already earns in a country are a direct sign of demand there.
- Competitor investment. If competitors have built out a language, check what they rank for; if none have, test for demand before assuming it is there.
- Sales traction. Markets where you already make sales or get inbound interest are where search investment builds on real demand.
Prove the return on one language before scaling to the next. Build the highest-signal language fully, measure the result, and use it to justify the next. One complete language gives a clearer test than six half-built ones.
URL architecture: subdirectory by default
Google recommends different URLs for each language version, rather than cookies or browser settings that change the language on one URL. Its multi-regional guide compares the URL options:
| Structure | Example | Google's pros | Google's cons |
|---|---|---|---|
| Country-code domain | <!–INLINECODE3–> | Clear geotargeting; server location irrelevant; easy separation of sites | Expensive; more infrastructure; ccTLD requirements can be strict; targets a single country |
| Subdomain | <!–INLINECODE4–> | Easy to set up; allows different server locations; easy separation | Users might not recognize geotargeting from the URL alone |
| Subdirectory | <!–INLINECODE5–> | Easy to set up; low maintenance (same host) | Users might not recognize geotargeting from the URL alone; single server location; separation harder |
| URL parameter | <!–INLINECODE6–> | Not recommended | Segmentation difficult |
Our recommendation for a company expanding into new languages without a local presence is a subdirectory. It is the lowest-maintenance option in Google’s table, and every language version lives on the site you are already building, so content, links and technical fixes accumulate in one place instead of across several domains.
Choose a country domain when there is a real reason: an established local presence or brand, a regulatory requirement, or a need for a strong country signal, which Google says country domains provide. Weigh that against the cost: each country domain is a separate site to build, link and maintain.
Don’t plan around a Search Console setting to assign a country. The International Targeting report has been deprecated. Google determines a page’s target audience from signals it lists, including country domains, hreflang, server location and local signals such as local addresses, currency and links from other local sites. That is another reason the structure decision matters.
Frequently asked questions
Should I use a country domain for each country to rank better locally?
Not by default. A country domain gives the clearest country signal, but each one is a separate site to build and maintain. Without a local presence, brand or regulatory reason in that country, a subdirectory on your main site is the simpler path.
Do I need separate Spanish versions for Spain and Mexico?
Only if the markets differ in ways that change the content: pricing, currency, legal requirements or clearly different search behavior. If one well-localized Spanish version meets the demand, build that first. Split into country versions when a concrete difference justifies the extra pages and upkeep.