A business that expands from a single UK site into French, German, or Spanish markets usually starts by translating the existing pages and assumes that's the job done. It isn't. Without the right technical structure underneath it, a translated site can actively confuse Google about which version to show which searcher — sometimes ranking the wrong language in the wrong country, or worse, treating the translated pages as duplicate content and suppressing most of them from search results entirely.
International SEO is the layer that makes sure each language version reaches the audience it was built for. Here's how it actually works.
hreflang: What It Actually Does
The hreflang tag tells Google (and Bing) which language and, optionally, which country a specific page is intended for, and which other URLs on your site are alternate versions of the same content in other languages. Done correctly, a French searcher gets served your /fr/ page in search results even if your /en/ homepage technically ranks higher in raw authority — because hreflang tells Google that's the more relevant version for that searcher.
The three mistakes that break it most often:
Missing reciprocity — Every page in a hreflang set must reference every other page in the set, including itself. If your English page links to the French version but the French page doesn't link back to the English one, Google will often ignore the whole cluster.
Wrong or missing x-default — The x-default value tells Google which version to show a searcher whose language doesn't match any of your alternates. Without it, that traffic gets routed unpredictably.
hreflang without matching canonical tags — Each language version needs its own self-referencing canonical, not one canonical pointing back to a single "main" version. Pointing every translated page's canonical at the English original tells Google the translations are duplicates rather than distinct pages — undermining the very thing hreflang is meant to fix.
Subdirectories, Subdomains, or ccTLDs
There are three common ways to structure a multilingual site, and the choice affects both SEO and long-term maintenance cost.
Subdirectories (example.com/fr/) — The most common choice for small-to-mid businesses. All language versions share the same domain authority, which means a new language launch benefits from the trust the main domain has already built, rather than starting from zero.
Subdomains (fr.example.com) — Technically simpler to host separately, but Google has historically treated subdomains as at least partially distinct properties for authority purposes, meaning a new subdomain often takes longer to rank than a subdirectory would.
Country-code top-level domains — ccTLDs (example.fr) — The strongest local-market trust signal to users and to Google, but the most expensive to maintain long-term: separate domain registrations, separate technical SEO work, and no shared authority between markets at all.
For most businesses expanding into two to five markets, subdirectories are the pragmatic choice — which is also the structure we use on our own site, described further down.
Localised Content, Not Just Translated Content
Direct translation and localisation are not the same job, and treating them as identical is one of the most common reasons a multilingual expansion underperforms.
Prices need converting to the local currency at sensible round numbers, not a literal exchange-rate calculation that produces an odd figure like "£1,500 → €1,738.42." Idioms, industry terminology, and even keyword targeting need adapting to how that market actually searches — a literal translation of an English keyword phrase is frequently not the phrase a native speaker would type into Google at all. And UK-specific framing (dates, "in the UK" in titles, references to UK-only regulations) needs generalising or replacing with market-appropriate equivalents, not carried over unchanged into every translation.
Technical Checklist for International Sites
Sitemap entries per language — Your XML sitemap should list every language version of every URL, ideally with hreflang alternate annotations included directly in the sitemap as well as on the page itself.
Locale-aware structured data — JSON-LD schema should include an inLanguage property matching the page's actual language, not a single schema copy reused unchanged across every locale.
Consistent internal linking — Links inside translated content should point to the equivalent translated page when one exists, not fall back to the English version by default. A French page linking internally to an English page for no reason quietly leaks that visitor out of the French experience.
Locale detection that respects manual choice — Auto-detecting a visitor's language from browser settings is good practice, but it should never override a URL a user has explicitly navigated to or a language they've explicitly selected — nothing frustrates an international visitor faster than being redirected back to a language they didn't choose.
Common Mistakes That Tank International Rankings
Machine-translated content with no review — Google's systems and human searchers both recognise unreviewed machine translation, and it converts poorly even when it technically ranks.
One title tag and meta description strategy for every language — Keyword research needs to be redone per market, not translated word-for-word from the English version, because search volume and phrasing genuinely differ between languages even for the same underlying intent.
Duplicate content across near-identical locales — Two English-language sites for different English-speaking markets (say, UK and US) with identical content and no locale differentiation can trigger duplicate content issues just as easily as literal translation failures would.
How Dricomm Approaches This
Our own site runs in five languages — English, Spanish, French, German, and Russian — using the subdirectory structure and hreflang setup described above, with every page carrying a locale-aware canonical, alternate tags, and structured data. It's built on Next.js with next-intl, which is the same stack and approach we bring to client projects that need to serve more than one market. We don't machine-translate and publish; every language version is adapted for how that market actually phrases a search, not just converted word-for-word.
If you're planning an expansion into new markets and want a technical read on what your current site would need before launch, get a free audit or see our full range of services, including pricing for multilingual builds.
Ready to grow your business online? Get your free audit →