International SEO discussions tend to start with hreflang, because hreflang generates errors that show up in tools and errors demand attention. That ordering is backwards. The domain structure decision determines what is possible, and hreflang is implementation detail on top of it.
Get the structure wrong and you will spend years working around it. Get it right and hreflang becomes a maintenance task rather than a strategy.
Three Structures and What Each Actually Costs
Country code top level domains. Separate domains per market, so example.de and example.fr. The strongest geographic signal available and the most expensive option by a wide margin, because each domain builds authority independently from zero. Links earned by one do not help another.
Worth it where local trust genuinely matters commercially, which is more common in some markets than others, and where the business has resources to run genuinely separate operations. Not worth it for a company entering three markets with one content team.
Subdomains. A market per subdomain, so de.example.com. A moderate geographic signal with the entity splitting problem covered in the subdomain guide. Authority consolidation across subdomains is weaker than within one host and stronger than across separate domains.
Subdirectories. A market per path, so example.com/de/. Weakest explicit geographic signal and strongest authority consolidation, since everything accrues to one domain.
My position: subdirectories for most businesses, ccTLDs only where there is a genuine commercial reason tied to local trust or legal requirement. The authority consolidation advantage compounds and most companies underestimate how long a fresh domain takes to become competitive.
Language and Country Are Different Variables
The most common conceptual error is conflating them. Spanish is spoken across many markets with different currencies, shipping, regulations, and vocabulary. A single Spanish version serving Spain, Mexico, and Argentina will be wrong about something for two of them.
Decide whether you are segmenting by language, by country, or by both. Segmenting by language alone is simpler and works where the commercial offer is identical across markets sharing that language. Segmenting by country is necessary where price, availability, or legal terms differ.
Hreflang supports both, with language only codes like es and language plus region codes like es-MX. Mixing them inconsistently across a site is where implementations break.
Hreflang Rules That Actually Cause Failures
Three requirements account for the large majority of broken implementations.
Return links must be bidirectional. If page A declares page B as its Spanish alternate, page B must declare page A as its English alternate. Missing return links are the single most common error and hreflang without them is ignored entirely rather than partially applied.
Every set must include a self referencing entry. A page listing its alternates must also list itself. Omitting this breaks the set.
Codes must be valid. Language codes follow ISO 639-1 and region codes follow ISO 3166-1 Alpha 2. The frequent error is using en-UK, which is not valid. The correct code is en-GB.
<link rel="alternate" hreflang="en-gb" href="https://example.com/en-gb/page" />
<link rel="alternate" hreflang="en-us" href="https://example.com/en-us/page" />
<link rel="alternate" hreflang="de-de" href="https://example.com/de-de/page" />
<link rel="alternate" hreflang="x-default" href="https://example.com/page" />The x-default entry specifies what to serve when no alternate matches the user, and it is worth including rather than leaving the choice unmade.
Where to Put Hreflang
Three valid locations: HTML head, HTTP headers, or XML sitemap. Pick one and use it consistently, because implementing in two places creates conflicts when they diverge, which they will.
For sites with many language versions, the sitemap approach keeps page weight down and centralises maintenance, which matters when a set of twelve alternates would otherwise add twelve tags to every page. For smaller implementations the head is simpler to debug.
Non HTML files like PDFs can only use HTTP headers, which is worth knowing if translated documents are part of your international content, per the PDF guide.
Translation Quality Is a Ranking Factor in Practice
Machine translated content published without review reads as machine translated to native speakers, and it competes against locally written content in that market.
The failure is not that translation is bad in the abstract. It is that direct translation preserves the source market's keyword choices, which frequently do not match how people search in the target market. A term translated literally may be technically correct and commercially wrong.
Keyword research should be done natively per market rather than by translating an existing keyword list, following the intent based process in the keyword research guide. This is the step most international programmes skip and it is where the value is.
Duplicate Content Across Markets
Two English versions for the US and UK are near duplicates by construction. Correct hreflang handles this, and Google's documentation is explicit that alternate language versions are not treated as duplicate content when properly declared.
Where it breaks is when hreflang is incomplete and the two versions compete. The symptom is the wrong regional version ranking in a market, which is the ambiguity problem covered in the canonicalization guide.
Canonical tags should point within a language version, never across them. A German page canonicalising to its English equivalent tells Google the German page should not be indexed, which is the opposite of the intent.
Automatic Redirects Based on IP Are a Mistake
Redirecting visitors to a market version based on detected location is common and it causes real problems.
Crawlers accessing your site from one location get redirected to one market version and never see the others, which means alternates may go undiscovered. Users travelling or using a VPN get served the wrong market with no way out.
The better pattern is serving the requested URL and offering a dismissible suggestion to switch. That preserves crawlability and respects the user's actual request.
Local Signals Beyond Hreflang
Currency, address formats, phone number formats, date conventions, and payment methods all signal that a page belongs to a market. So does a local address and phone number where one genuinely exists.
Local hosting and ccTLDs matter less than they once did for ranking and can still matter for latency, which affects Core Web Vitals, which affects rankings indirectly. That is a real but secondary consideration.
Local link acquisition is the underrated one. Links from domains in a target market carry geographic relevance that links from your home market do not, following the same logic covered in the local SEO guide at national scale.
What This Costs to Maintain
Every market added multiplies content maintenance. A page updated in the source language is now out of date in every other version until each is updated.
Most international programmes underestimate this and end up with a well maintained home market and several stale translations that no longer describe the current product, which is the decay problem covered in the refresh workflow guide multiplied by market count.
Deciding how many markets to support should account for ongoing maintenance rather than launch cost. Three markets maintained properly outperform eight left to drift.
URL Structure Within a Market Version
Whether to translate URL slugs is a genuine decision rather than a settled question. Translated slugs match how users in that market search and they signal the page belongs to that language. Untranslated slugs are simpler to maintain and easier to map across versions when auditing.
My position: translate slugs for markets where the language uses a different script or where the untranslated version would be meaningless to a reader, and keep them consistent elsewhere. The maintenance cost of translated slugs is real and it is worth paying where readability genuinely differs.
What matters more is consistency of the market identifier itself. Mixing /de/ in some places and /de-de/ in others creates the ambiguity the whole structure exists to prevent, and it is a common artefact of markets added at different times by different people.
Checking It Works
Search Console's international targeting report surfaces hreflang errors, and third party crawlers can validate return links at scale, which is the check most worth automating.
The NotionCue Prompt Tracker covers the adjacent question of whether AI engines serve accurate market specific information, since running the same prompt in different languages frequently produces inconsistent brand descriptions that classic tools do not surface.
Start your free NotionCue trial and test a few prompts in each of your target languages. Inconsistent answers across markets are common and rarely noticed.
Before adding a market, ask who will update its content when the product changes. If the answer is nobody specific, the market will be stale within two quarters and a stale market version is worse than no version.
Common Questions
Does hreflang affect rankings directly?
No. It tells Google which version to serve to which audience. It does not make any version rank better, and a poorly translated page with perfect hreflang still ranks poorly.
Can I use subdirectories and still target countries?
Yes. Hreflang provides the targeting signal and Search Console previously offered explicit geographic targeting for subdirectories. The structure is a weaker inherent signal, not an absent one.
Should machine translation be used at all?
As a first draft reviewed by someone fluent, reasonably. Published unreviewed, it produces content that reads as foreign to the market it targets, and the keyword mismatch problem remains regardless of fluency.