International technical SEO: locales, URLs and the hreflang graph
A multilingual site is a set of decisions about identity: what a locale is, where it lives, and which version should be served to whom. hreflang is the last of those and the only one that is a tag.
hreflang is where the problem becomes visible, not where it starts
A site adds a second language and the implementation starts at the markup: hreflang tags added to the templates. That is the end of the process being treated as the beginning. The tags describe a relationship between URLs, and whether that relationship is correct depends on decisions made earlier — what the locales are, how they are addressed, and whether each version is genuinely distinct. A hreflang graph built over an inconsistent URL structure is a set of statements about pages that should not all exist.
- hreflang tags are present and the wrong version is still being served
- One language version is indexed and the others are not
- The language selector changes content without changing the URL
- A locale's URLs are a subdirectory, a subdomain and a parameter in different places
- Translated pages are competing with each other rather than with the correct market's competitors
- Currency, availability or legal content is the same across markets
- Some locales are machine-translated and nobody has decided how they should be treated
- The site serves a language based on the visitor's IP rather than their choice
The people who usually bring us this problem
A site adding languages
You want the architecture decided before the URLs exist rather than corrected afterwards.
A site whose locales are not indexed correctly
hreflang is in place and the results do not reflect it.
A site whose international structure grew rather than was designed
Different markets were added at different times by different people and the estate is inconsistent.
What this costs while it goes unfixed
Engineering faults are rarely confined to the engineering layer. These are the commercial consequences we see most often.
A locale is an identity, not a translation
Language, country and market are three different things, and a site has to decide which one its URLs represent. A language spoken in several countries may need several versions; a country with several languages may need several. Deciding this once determines the URL structure, the hreflang graph and what the content has to vary on.
hreflang is reciprocal and incomplete annotations do nothing
Every version must reference every other version including itself, and a graph with a missing edge is unreliable for the pages involved in the gap. This is why hreflang fails quietly: a partial implementation produces no error, just an ambiguous signal, and the page that is missing from the graph is the one that suffers.
Automatic language selection is a decision with a cost
Serving a language based on IP or browser preference is convenient and it interferes with a crawler's ability to see every version and with a visitor's ability to choose differently. Where it is used, it has to be overridable and the URLs have to remain stable — otherwise the crawler sees a different site depending on where it requests from.
Translated pages that are identical in substance are not distinct pages
If the currency, the availability, the legal content and the offers are the same, the locale version adds a translation and not a market. That is a legitimate thing to have and it should be treated as one — which determines whether it is a separate indexable URL at all, or a variant of the same page.
Capabilities
Each of these is work we carry out, not an area we advise on.
Locale model design
What the locales are — language, country, or market — and what each URL represents. The decision that determines everything downstream, made against how the business is organised rather than against how the translations happened to be produced.
URL architecture
Subdirectory, subdomain, country-code domain or parameter, chosen with its trade-offs stated. There is no universally correct answer and there is a correct answer for a given site, which depends on how independent the markets are and how much infrastructure each needs.
hreflang implementation
Complete and reciprocal annotation across every version, including self-reference, generated from the content model rather than authored per template. On a site with several locales and several page types the graph is generated or it is wrong.
Language selection and redirection
Whether a visitor is auto-directed, how it can be overridden, and whether the URLs stay stable for a crawler. Where redirection is used, it is designed so that every version remains reachable and no version becomes invisible to search.
Market-specific content requirements
What genuinely differs per locale — currency, availability, legal text, contact details, delivery — and what does not. Where nothing differs, that is a fact about the locale and it changes how the version should be treated.
Canonical and duplication handling
Canonicals within a locale, and the relationship between a translated page and its source. A translated page pointing its canonical at the original removes itself from its own market's results, which is a common and expensive mistake.
Geo-targeting
Where country targeting is expressed and where it is not needed, given that the URL structure and hreflang may already say it. Signals that duplicate each other are not stronger, and a geo-targeting setting that disagrees with the URL structure is a contradiction.
Verification across locales
Every version fetched and checked: its hreflang annotations, its canonicals, its status codes and its language selector, per locale and per page type. A graph is only as correct as its least correct member, and on a multi-locale site the check is per pair.
Engineering methodology
The sequence is deliberate. The order is usually what determines whether the work holds or has to be repeated.
Decide what a locale is before anything else
Language, country or market. It determines the URL structure, the hreflang graph and what the content has to vary on — and starting from the markup means starting after the decisions that matter.
Choose the URL architecture with its trade-offs stated
Each option has costs: a subdirectory shares the domain's authority and couples the markets' infrastructure; a country-code domain is unambiguous and expensive to operate; a parameter is easy and weak. The recommendation names what is being traded.
Generate the hreflang graph from the content model
Authored per template it is incomplete the moment a page type is added, and incompleteness is the failure mode that produces no error. Generated from the model, the set of annotated page types is the set that exists.
Keep every version reachable
Where a visitor is auto-directed, the redirection is overridable and the URLs remain stable. A version that is only reachable by choosing a language, or that is redirected away from depending on the requester, is a version a crawler may never see.
Check reciprocity per pair
Every version referencing every other, including itself. This is verified as a graph rather than per page, because a missing edge affects the pages on both sides of it and neither page reveals the gap on its own.
Distinguish a translated page from a market page
Where content differs only by language, treat it as a variant; where currency, availability and legal content differ, it is a market page. The distinction decides whether it should be a separate indexable URL, and getting it wrong produces either duplication or a missing market.
What an engagement produces
Documentation is a deliverable, not an afterthought. On most of these engagements a large part of the value is a defect report precise enough for another team to act on.
Architecture
- What a locale represents, and how many there are
- URL structure, with the trade-offs of the choice stated
- What differs per locale: currency, availability, legal content, contact
- Language selection behaviour, and how it is overridden
- Which versions are distinct pages and which are variants
- Where geo-targeting is expressed, and where it would duplicate what exists
Implementation
- URL structure implemented
- hreflang generated from the content model, complete and reciprocal
- Canonicals correct within each locale and across translations
- Language selection implemented with stable URLs
- Market-specific content differences reflected where they exist
Verification
- Every version fetched: hreflang, canonical, status and language selector
- The hreflang graph checked for reciprocity as a graph, not per page
- Indexation per locale, and what is missing from each
- What is machine-translated, and how it is treated
- What remains inconsistent and why
Architecture and technology
The decisions, in the order they have to be made
- What a locale is — language, country or market
- How many there are, and whether any market needs more than one
- How they are addressed — subdirectory, subdomain, ccTLD or parameter
- What genuinely differs per locale
- Whether a visitor is auto-directed, and how that is overridden
- Which versions are indexable in their own right
- Then, and only then, the hreflang graph
How international implementations fail
- A hreflang graph with a missing edge, which produces no error and an ambiguous signal
- A translated page canonicalised at its source, removing it from its own market
- IP-based redirection that hides versions from a crawler
- An inconsistent URL structure where markets were added at different times
- Geo-targeting that contradicts the URL structure
- A locale with translated text and identical offers, treated as a distinct market
If this is not quite your problem
These overlap at the edges. Sending you to the right page is more useful than having you work it out.
The site is being migrated or restructured
URL inventory, redirect mapping and indexation recovery.
Website migrationsThe locale structure is a platform question
WordPress multilingual structures and their search consequences.
WordPress technical SEOPages exist and are not indexed in their market
Coverage and crawl diagnosis when discovery is not the constraint.
Crawl and indexationThe whole technical position needs establishing
An audit delivered as a prioritised engineering backlog.
Technical SEO auditFrequently asked
Do you have an international SEO project?
No, and the page says so rather than implying one. International work is largely implementation — the locale model, the URL structure and a hreflang graph generated from the content model — so the useful question is not whether we have a reference but whether a team can carry the implementation, which the page describes in enough detail to judge. If a reference in your specific market is a requirement, that is reasonable and this is not the page that has one.
Should we use subdirectories or country-code domains?
It depends on how independent the markets are, and each option has a cost worth naming. A subdirectory shares the domain's authority and couples the markets to one infrastructure, which suits markets that are variations of one business. A country-code domain is unambiguous for users and search engines and means operating a site per market, which suits genuinely separate operations. The recommendation names what is being traded rather than presenting one as correct, because for a given site there is a right answer and it follows from the business rather than from the industry.
Why is our hreflang not working?
The usual cause is that the graph is incomplete. hreflang is reciprocal: every version has to reference every other version, including itself, and a graph with a missing edge gives an ambiguous signal for the pages on both sides of the gap — with no error raised anywhere. A partial implementation is therefore not a partial benefit, it is an unreliable one. The check is per pair across the whole graph rather than per page, because no single page reveals the gap on its own.
Can we redirect visitors to their language automatically?
You can, and the design has to keep every version reachable. An automatic redirect that cannot be overridden, or that depends on where the request comes from, means a crawler sees a different site depending on its location and may never see some versions at all — which is the opposite of what a multi-locale structure is for. Where it is used, the URLs stay stable, the visitor can choose differently, and every version remains directly addressable.
Is machine translation a problem?
Not inherently, and it is a decision about what the page is for. A machine-translated version that serves a real market's queries is worth having; one that duplicates content in a language nobody in that market searches in is a page that adds nothing and can divide signals. The question is whether the version differs in substance — currency, availability, legal content — or only in language, because that determines whether it should be a distinct indexable page or a variant of one that already exists.
Related capabilities and work
Bring us the problem you have not been able to fix
Describe what is happening rather than what you think the cause is. If we are not the right people for it, we will say so.