International SEO without tears: hreflang, ccTLDs and content reuse

Every international expansion we've watched go sideways made the same mistake: it treated "we're launching in Germany" as a translation project. It is not a translation project. It is a second website that happens to share a design system with your first one — with its own search demand, its own competitors, its own idioms, and a cranky little XML-ish mechanism called hreflang stitching the siblings together. Get the architecture and the stitching right and international is a compounding second engine. Get them wrong and you've built a very expensive duplicate-content farm that confuses Google in two languages.

This is the playbook we run: the architecture decision, hreflang done properly (including the three ways it reliably breaks), translation as an editorial workflow rather than an export, and the staged validation that catches disasters before Google does.

The architecture decision: ccTLD, subfolder, subdomain

You will have this meeting, so have it with eyes open. Three options, honest trade-offs:

ccTLDs (example.de, example.fr). The strongest local signal that exists — users genuinely trust a local domain, country targeting is unambiguous, and each market can eventually be operated semi-autonomously. The costs are real and never fully reversible: each ccTLD starts with zero domain authority, so you're effectively launching n new sites and splitting your link equity across all of them; every ccTLD is another property to register, renew, secure and monitor; and consolidated reporting gets harder. Choose ccTLDs when international markets are core to the business for a decade, when you'll fund local marketing efforts that earn links locally, and when you have the operational stomach. This is the enterprise answer.

Subfolders (example.com/de/). The default we recommend for most companies. One domain, all authority pooled — a strong .com lifting your German pages from day one is worth more than most local signals. Country targeting is declared in Search Console, hosting and ops stay simple, analytics stays consolidated. The weakness: the local trust signal is softer (a /de/ folder reads as "also available in German" to a Munich buyer comparing you against a .de incumbent), and if the parent domain ever takes a hit, everything takes the hit together. For a B2B SaaS or services company entering two to five markets, subfolders win almost every time.

Subdomains (de.example.com). The compromise that inherits the drawbacks of both. Search engines have historically treated subdomains as semi-separate properties, so you neither pool authority fully nor get true local signal. We recommend them only when the architecture is forced — a market running on genuinely separate infrastructure — never as a strategy.

One non-negotiable whichever you pick: one language-country pair per URL, always a dedicated URL, never a client-side language switcher. Geo-IP redirects that serve German content on the .com URL are the silent killer of international SEO: Googlebot crawls from the US, sees only English, and your German pages effectively don't exist. Redirect suggestions (a dismissible banner: "Sieht nach Deutschland aus — zur deutschen Seite?") are fine; forced redirects are an own goal.

Hreflang done properly (and the three ways it breaks)

Hreflang is not complicated; it is merely unforgiving. The mechanism: every page in a language cluster declares, for itself and all its siblings, the language (en-AU) and x-default fallback. These declarations must be reciprocal and complete — if your Australian page points at the German page, the German page must point back, with exactly the same cluster membership. Implement it in the HTML head or the sitemap (we prefer sitemaps for scale — one generated artefact, no template logic scattered across codebases).

The three ways it reliably breaks, in descending order of frequency across the audits we've run:

  1. Partial reciprocity. Someone ships a new /de/about/ but the English /about/ never gets the return annotation — because the hreflang logic lives in per-template code and the German template was added by a different squad six months later. Google treats broken reciprocity as a hint, not a directive, which means it ignores your entire cluster and serves whatever it likes. This is the failure mode behind "we launched German pages and our English rankings got weird".
  2. Annotations pointing at non-canonical or redirected URLs. Your hreflang cluster lists /de/preise/, but that page 301s to /de/pricing/ or declares a canonical to the English page. Every edge of the cluster must terminate on a self-canonical, indexable, 200-status URL. One redirected edge poisons the cluster's credibility.
  3. x-default forgotten or misused. The x-default entry tells Google where to send everyone else (usually your global English page or a language selector). Omitting it produces the classic symptom: a user in Spain searching in English gets served your German page because Germany "felt closest". Marking a random page as x-default produces weirder symptoms. It's one line. Put it in.

And the meta-rule: hreflang is a hint system, not a routing system. It resolves ambiguity between near-duplicate pages. It does not create demand, fix thin translations, or rescue pages that never should have existed. Speaking of which.

Translation is an editorial workflow, not an export

The spreadsheet-export-to-translation-vendor pipeline produces content that is grammatically correct and commercially dead, because it translates what you wrote instead of what the market searches for and needs to hear. The pipeline that works:

Localise by intent, not by page. Before translating anything, run keyword research in the market, in the language — not translated English keywords, which miss the ways Germans actually search (compound nouns, different category vocabulary, English loanwords used differently). The outcome is not a page map, it's a priority list with gaps: pages to translate straight, pages to rewrite for local intent, pages the market doesn't need yet, and — the part everyone skips — pages the local market needs that don't exist in English at all. Local regulatory questions, local comparison competitors, local buying customs. A German "Brassfern alternative" searcher has a different competitive set than an Australian one; the comparison page strategy has to be rebuilt per market, not translated.

Transcreate the money pages, translate the long tail. Homepage, services, pricing, top case studies: these get a native-speaker marketing writer, not a translation vendor. The difference shows up in conversion, not word counts — idioms, humour, the register of the CTA. Blog archives and documentation can go through faster workflows, with a native review pass on anything that ranks.

Keep voice, change references. The brand's voice chart travels; the examples don't. Local currency, local business hours, local proof points, local legal framing on privacy pages and cookie handling. A translated page with A$ pricing and Melbourne school-holiday references is a telling detail that undoes the trust the translation was bought to create.

Hreflang-annotated, not cross-translated. Pages don't need to exist in every language. A German-only article and an English-only article simply aren't a cluster. Resist the urge to machine-fill the matrix; thin auto-translated content at scale is how programmatic SEO goes wrong.

Technical checklist before launch

Beyond hreflang, the launch-critical items, condensed from our technical SEO checklist:

  • Language-detection banner, not redirect, with the preference remembered (cookie or account setting) and crawlable links to every language version in the switcher — the switcher is the internal linking between clusters.
  • Translated metadata, slugs and structured data. Title tags and descriptions in the local language (written for local CTR, not transliterated), URL slugs localised where cheap (/de/preise/ beats /de/pricing/ marginally, but stability beats both — never churn slugs later), and JSON-LD inLanguage correct per page.
  • Sitemaps per locale, submitted separately, each carrying the full hreflang cluster — this is the validation-friendly format.
  • Local currency, address and phone in structured data and footers; areaServed on your Organization markup per market.
  • Translated image alt text — the step literally everyone forgets, including us once, memorably.
  • Search Console properties for each subfolder or ccTLD, with country targeting set explicitly, not assumed.
  • Performance per region. If your German pages are served from a Sydney origin with no CDN, your localisation includes a 300ms handicap. The performance budget discipline applies per-market, and field data (CrUX) is reported per-country — check the German numbers, not the global average.

Staged validation: the crawl before the crawl

The failure pattern we refuse to repeat: launch all locales at once, discover six weeks later from a traffic chart that hreflang never worked. The staging protocol instead:

  1. Crawl yourself first. Full crawl of every locale with rendering on. Verify: hreflang reciprocity across the entire cluster graph (script this — a reciprocal-graph checker is an afternoon of work and has saved every launch), self-canonicals, 200 statuses, translated metadata, no noindex survivors from staging.
  2. Soft-launch one mid-traffic locale to production with monitoring: indexation rate, which URLs Google actually serves per market (Search Console's International Targeting report), cannibalisation between clusters in shared SERPs.
  3. Run a log-file check after two weeks. Is Googlebot crawling the new locale proportionally? If not, the internal linking from the switcher is weak or the pages are orphaned.
  4. Only then roll the remaining locales, because the bug classes are identical and you just proved them out on one.

This is the same instinct as a site migration: the launch is the least important moment; the validation discipline around it is the project.

The long game

International SEO's dirty secret is that the technical part is front-loaded and the editorial part never ends. Markets rank on the strength of local relevance earned over years — local links, local coverage, local case studies, content that answers questions nobody asked in Sydney. Launch the architecture correctly, be honest about which markets will get real editorial investment (two done properly beat five running on machine translation and hope), and give each locale an owner the way every metric deserves an owner. Expansion is a portfolio decision wearing a technical costume.

We run this as a fixed-scope engagement inside our growth practice: architecture decision memo, hreflang spec and reciprocal-graph validator, transcreation brief for the money pages, staged validation plan. Two weeks of decision-making that saves a year of unravelling. The brief form is here.

Key takeaways

  • International launch = a second website sharing a design system, not a translation task. Decide ccTLD vs subfolder on decade-scale strategy; subfolders win for most companies entering two to five markets.
  • Dedicated URL per language-country pair, always. Never geo-redirect; suggest, remember, and make language links crawlable.
  • Hreflang fails three ways: broken reciprocity, edges pointing at redirected or non-canonical URLs, missing or misused x-default. Validate the cluster graph with a script, not hope.
  • Translate by intent: local keyword research first, transcreate money pages with native marketing writers, keep the voice chart and change the references.
  • Crawl every locale pre-launch, soft-launch one with close monitoring, then roll the rest. The validation discipline is the project.

FAQ

We only sell in English-speaking markets for now. Do we need any of this? Partially. Even single-language businesses hit the architecture question — Australia's .com.au vs .com, UK and AU content cannibalising each other. The minimum viable version: one dedicated URL per country only where the content genuinely differs (pricing, legal, shipping), hreflang between those (en-AU / en-GB / x-default), and local signals (address, currency, phone) in structured data. Skip anything beyond that until an actual market with an actual language arrives.

Should we translate our blog? Rarely at first. Blogs rank on topical authority built through links and freshness, and a translated archive with no local links is a ghost town. Start with the ten posts closest to money in each market (the ones your sales team actually sends), transcreate them, and earn a few local links before scaling. Measure indexation and impressions per locale monthly; expand only where the first cohort earns its keep.

Machine translation has gotten really good. Can we just... use it? For comprehension-grade content (documentation, help centre) with a native review pass: yes, increasingly. For persuasion-grade content (homepage, pricing, case studies): no. MT produces fluent, plausible, slightly dead copy — the marketing equivalent of stock photography. The failure isn't grammar, it's that nobody feels spoken to. And unreviewed MT at scale is exactly the pattern quality systems are trained to discount. Spend the money where the words carry revenue.

How long until a new locale ranks? Honest ranges from our launches: subfolder on a strong existing domain in a moderately competitive market shows meaningful impressions in 6–10 weeks and commercial rankings in 4–8 months. A fresh ccTLD on a thin link profile can double that. Anyone quoting you weeks for a competitive market is selling the translation, not the outcome. Set the expectation with leadership at kickoff or the programme gets defunded at month three, right before it works.


Keep reading