Every guide on this subject opens with country-code domains versus subdirectories. It's the easiest decision you'll make and roughly the fifth most important one — and leading with it means most teams get the structure right and the programme wrong.
The decisions that actually determine whether this works: whether you should be doing it at all, whether you've confused language with country, and whether anyone is checking the tags — because Google stopped checking them for you four years ago.
The question to answer before any of this
Most sites that want international SEO shouldn't do it yet.
Three things have to be true, and the third is where programmes die. You need demonstrable demand in the target market. You need the ability to actually serve customers there — shipping, support hours, language, currency, legal. And you need the ongoing capacity to maintain the content, which means every page change forever, multiplied by the number of markets.
The market to start with is usually already visible in your data: filter your existing organic traffic by country and look for places you're getting visits you never asked for. That's demand you haven't served, which is a much better first market than one chosen from a spreadsheet — and it's one of the more useful things sitting in the Search Console reports that matter.
Language is not country
The root structural error, and it's conceptual rather than technical.
Spanish is not a market. Spain, Mexico, Argentina and the US Hispanic audience are four markets sharing a language, with different vocabulary, different competitors, different price expectations and sometimes different products. English is worse: the UK, US, Australia, India, Canada and Singapore all read English and search differently.
Most site structures assume a one-to-one mapping, which forces a choice nobody should have to make — either one Spanish page for everyone, which serves none of them well, or four near-identical pages that look like duplicates.
The resolution is to decide, per market, whether you're targeting a language or a country:
- Language-only where the content genuinely works everywhere it's read and you have no local operation. One Spanish version, targeted by language alone.
- Country-specific where you have local pricing, local stock, local legal terms or a local team. This is where the extra pages earn their maintenance cost.
- Both for large programmes — a generic language version plus country variants where they're justified.
Getting this wrong at the start is expensive to undo, because it's baked into the URL structure and every tag that references it.
The structure decision, briefly
Since everyone leads with this, here it is — with the honest weighting.
| Structure | Geographic signal | Real cost |
|---|---|---|
| ccTLD (example.de) | Strongest | Separate authority per domain; highest maintenance |
| Subdomain (de.example.com) | Moderate | Authority partly separated; easier hosting flexibility |
| Subdirectory (example.com/de/) | Weakest signal, strongest consolidation | Lowest overhead; the default for most businesses |
Subdirectories are the right answer for most businesses entering new markets, because consolidated authority beats a marginally stronger geographic signal when you're starting from scratch. Country-code domains make sense when a market is genuinely a separate business with its own team, brand recognition and link acquisition.
One thing worth knowing: Google removed the ability to manually set a country target for a generic domain in Search Console, saying it was judged to have little value. Geographic relevance is now inferred from ccTLDs, hreflang, server location and on-page signals — there is no manual override, so the structural choice carries more weight than it did.
SE Ranking
Fast-growing affordable SEO platform perfect for agencies and small businesses
Best for: Budget SEO Platform
hreflang doesn't do what most people think
The single most-implemented and most-broken tag in SEO.
What hreflang actually does It swaps which version of a page a searcher sees. It does not lift where that page ranks. Implemented well it puts the right page in front of the right person; implemented badly it fragments rankings across your markets. It is not a ranking factor in either direction.
Teams implement it expecting a traffic increase, see none, and conclude international SEO doesn't work. The tag was doing its job — the job just isn't the one they wanted.
Four failure modes cause most of the damage:
- Missing return links. Annotations must be bidirectional. If the German page points to the French one but not vice versa, Google discards the relationship. This is the most common error by a distance, and it usually appears when a new market is added and existing pages aren't updated.
- Invalid codes. Language codes are ISO 639-1, region codes are ISO 3166-1 Alpha-2. There is no en-uk — it's en-gb. A single invalid code silently voids the annotation.
- Alternates that don't return 200. Pointing hreflang at a URL that redirects, 404s, or is canonicalised elsewhere breaks the cluster. This happens constantly after site changes, because nobody updates the tags when URLs move.
- Conflicting signals. A page declaring hreflang="de" while serving English content tells Google two contradictory things. Same for a hreflang set that disagrees with the canonical tag.
Also: include a self-referencing tag on every page, and an x-default pointing at whichever version handles everyone you haven't explicitly targeted. Both get skipped routinely.
Google removed the safety net in 2022
The operational consequence almost no guide has caught up with, including several published this year.
Search Console's International Targeting report was deprecated in 2022 and removed. That took away two things: the manual country-targeting setting, and — more importantly — site-wide hreflang error reporting. Google still supports and uses hreflang. It just no longer tells you when yours is broken.
So validation is now entirely your responsibility, which changes the workflow:
- Crawl your own site with a tool that follows and validates hreflang relationships, exporting every annotation so you can see missing return links, invalid codes and non-200 alternates.
- Re-run it after every significant publish or URL change, not annually. Hreflang breaks silently, and by the time you notice a ranking effect you're weeks past the cause — the same argument as in the redirects and migrations safety checklist.
- Use URL Inspection for spot checks and watch indexation patterns per market. If a language version isn't being indexed, that's the signal you now get instead of an error report.
- Give it an owner. International health has no automatic alerting any more, so it needs a named person and a scheduled check or it will drift.
For large sites where crawling is itself a question, log file analysis will show you which market versions Googlebot is actually reaching — which is frequently not all of them.
Never redirect by IP address
The classic disaster, and it's still shipped regularly.
Automatic redirection based on the visitor's location does two things. It traps users — a traveller, an expatriate, or someone who simply prefers English can't reach the version they want. And it can prevent your international versions from being indexed at all, because Googlebot crawls predominantly from one region and will be redirected away from everything else.
The correct pattern is a dismissible suggestion: a banner offering the local version, with the choice remembered, and the original page still fully accessible. Slightly more work to build, and it's the difference between having international pages and having international pages that exist in the index. If your platform makes that awkward, it's worth solving properly rather than working around — a website build question that has SEO consequences rather than the reverse.
Translation is not localisation
Where most of the content investment gets wasted.
The core problem: keyword research doesn't translate. People in different markets search using different terms, different framings and occasionally for different problems. Translating a page optimised for one market's phrasing produces a page targeting a phrase nobody in the new market types.
Proper practice is to run fresh keyword research in the target language and market, then write to what it finds — which sometimes produces a different page rather than a translated one. Your topic clusters may need a different shape in each market, because the questions people ask differ.
Beyond keywords, localisation covers currency and payment methods, date and address formats, units, local proof and case studies, legal and compliance language, and local contact options. Machine translation has improved enough to make a competent first draft cheap; it has not made local review optional, and the difference shows most in exactly the commercial pages that matter. If AI sits in that workflow, the brand-voice discipline in an AI content workflow matters more across languages, not less.
For e-commerce specifically, the same localisation gaps show up in your product feed, where untranslated attributes and wrong currency formatting quietly suppress shopping visibility in the new market.
The maintenance cost nobody budgets
This is what actually kills international programmes, and it never appears in the launch plan.
Every page change multiplies. A pricing update is now six updates. A new product page is six pages. A positioning refresh is a project in every market. Within a year, the markets nobody owns are visibly stale, and stale thin pages are a quality problem across the whole domain rather than a local one.
Two ways to survive it. Keep the localised footprint deliberately small — your highest-value commercial pages and nothing else, rather than a mirror of the entire site. And put the multiplication into your editorial calendar as real capacity, not as an afterthought attached to the English version.
Once a market is live, treat it in your regular content audits rather than reviewing only the home market. Decay in a language nobody on the team reads is invisible until it's severe.
Beyond Google
Worth knowing before you plan a market on Google assumptions.
Hreflang is essentially a Google convention. Yandex supports a comparable implementation. Baidu ignores it entirely, weighting hosting location, domain registration within China and ICP licensing instead — so targeting China is an infrastructure and legal project before it's an SEO one, and hreflang won't help.
Add to that the growing share of discovery happening outside conventional search engines, which varies by region in ways worth checking rather than assuming — the market differences in where AI search traffic actually lands are substantial, and the platform mix in a new market may not resemble your home one at all.
A sequence that works
- Find the market already sending you unserved traffic.
- Decide language-only or country-specific, per market, before choosing URLs.
- Pick subdirectories unless the market is genuinely a separate business.
- Run fresh keyword research in-market rather than translating your existing set.
- Localise a small set of high-value pages properly instead of mirroring the site.
- Implement hreflang with self-references, return links, valid codes and an x-default.
- Crawl and validate it yourself, on a schedule, with a named owner.
- Suggest the local version; never redirect by IP.
- Prove the market before adding the next one.
Note that the technical foundation has to be sound first — hreflang problems compound existing crawl and indexation issues rather than existing alongside them, so a technical audit and sensible internal linking come before any of this, not after. And if you're scaling across locations rather than countries, multi-location SEO is the closer analogue.
The short version
Answer whether you should do this at all before choosing a structure — three half-maintained language versions perform worse than one good site. Separate language from country, because Spanish isn't a market and English is four of them. Use subdirectories unless a market is genuinely a separate business. Understand that hreflang swaps which version shows rather than lifting rankings, and that four failure modes — missing return links, invalid codes, non-200 alternates and conflicting signals — cause most of the damage. Google deprecated its International Targeting report in 2022, so nobody validates your hreflang but you: crawl it on a schedule with a named owner. Never redirect by IP; suggest instead. Run fresh keyword research per market rather than translating your existing set. And budget the maintenance multiplication before launch, because that's what actually ends these programmes.
The domain structure debate is the part that feels like the decision. It's the part you're least likely to get wrong.
Language versions live but not ranking in their own markets?
We audit the hreflang nobody's validating since Google stopped, and find where the clusters are broken.
Audit my international setup →Frequently asked questions
Should you use ccTLDs, subdomains or subdirectories for international SEO?
Subdirectories suit most businesses entering new markets, because they keep all authority consolidated under one domain and cost the least to maintain. Country-code domains send the strongest geographic signal but split your link authority across separate sites and multiply the technical and operational overhead. The choice is closer to a business decision about commitment and resourcing than an SEO one, and it matters considerably less than whether the content in each market is genuinely localised.
Does hreflang improve rankings?
No, and expecting it to is the most common misunderstanding. Hreflang tells Google which language and regional version of a page to show a given searcher — it swaps the version rather than lifting the position. Implementing it correctly can improve results in a market by ensuring the right page appears, and implementing it incorrectly can fragment rankings badly, but it is not a ranking factor and it will not make a page rank where it otherwise would not.
Does Google Search Console still report hreflang errors?
No. Google deprecated the International Targeting report in 2022 and removed it, taking with it both the site-wide hreflang error reporting and the ability to set a manual country target for a generic domain. Google stated the country targeting feature was judged to have little value for the ecosystem. Hreflang itself remains fully supported, but validation is now your responsibility — it needs a third-party crawler and periodic manual checks rather than a report inside Search Console.
Should you redirect visitors automatically based on their location?
No. Automatic redirection based on IP address is one of the most damaging patterns in international SEO. Googlebot crawls predominantly from a single region, so IP-based redirects can prevent most of your international versions from ever being crawled or indexed. It also traps genuine users who want a different version — a traveller, an expatriate, or someone who simply prefers English. Suggest an alternative version with a dismissible banner instead, and let the visitor choose.
Is translating your existing content enough for international SEO?
Rarely, because keyword research does not translate. People in different markets search using different terms, different framings and sometimes for different problems entirely, so a literal translation of a page optimised for one market frequently targets a phrase nobody in the new market uses. Proper practice is to run fresh keyword research in the target language and market, then write to what that research finds — which may produce a different page rather than a translated one.
