A client came to me in 2021 with a SaaS product that had been live in five languages for two years. Traffic from Germany: 38 sessions a month. From France: 22. Their English pages were ranking fine, but every localised version was basically invisible. They'd paid an agency to translate the copy, someone had installed WPML, and then everyone had assumed the work was done.
It wasn't even close to done.
Localisation SEO is one of those areas where doing 60% of the job correctly is nearly identical to doing 0%. Miss hreflang. Pick the wrong URL structure. Skip local signals. Result: Google ignores your translated pages entirely or, worse, treats them as duplicate content and filters them out. I've fixed this problem on hundreds of sites over the past nine years at Seahawk, and the failure pattern is almost always the same.
So let's go through what actually works.
---
Translation Is Not Localisation
This is the first thing I tell every client. Translation is converting words from one language to another. Localisation is rebuilding the intent of a page for a specific market.
Take a UK e-commerce client we had in late 2022. They were selling premium kitchen knives. Their German pages were a word-for-word translation of the English copy, including phrases like "perfect for Sunday roasts." Germans don't do Sunday roasts. The copy was grammatically correct and completely wrong.
But beyond culture, the SEO implications are real. Keyword volumes don't translate. The English query "best chef knife" gets roughly 8,100 searches a month in the UK. The German equivalent "bestes Kochmesser" gets far fewer, but "Kochmesser Test" (roughly "chef knife test/review") is enormous. If your translated page targets the literal translation of your English keyword, you're optimising for the wrong thing.
Before you write a single word of localised content, run keyword research in the target language, in the target locale using Google Keyword Planner with the country set correctly, or Ahrefs with the country filter applied. These are not the same as running English research. Treat each market as a new site from a keyword perspective.
What "Localised" Actually Means in Practice
- Pricing in local currency, with local payment method references
- Dates, addresses, and units formatted for that country (DD/MM vs MM/DD matters)
- Examples, idioms, and references that resonate locally
- Country-specific trust signals (German Käufer trust local certifications; French buyers respond to different social proof than Brazilians)
---
URL Structure: Get This Wrong and Nothing Else Matters
I've seen this argument derail so many projects. ccTLD vs subdomain vs subdirectory. People get religious about it.
Here's my honest take after building and migrating hundreds of international sites: subdirectories are usually the right call for most businesses. Something like yoursite.com/de/ rather than de.yoursite.com or yoursite.de. The reasons are practical: all your domain authority consolidates, it's easier to manage in one place, and Google handles it well when hreflang is set up correctly.
ccTLDs (yoursite.de , yoursite.fr) do send a strong local signal. If you're a serious player in a specific market and you can commit to running essentially separate sites, they're worth it. Seahawk had a fintech client that insisted on separate ccTLDs for six countries in 2020, and yes, it performed well in those markets. But their dev overhead tripled. For most agencies building for clients, that's not realistic.
Subdomains (de.yoursite.com) are the worst of both worlds in most cases. Harder to maintain than subdirectories, weaker authority signal than ccTLDs. I'd avoid them unless your CMS architecture genuinely forces the issue.
Whatever you pick: be consistent. Don't mix structures. I've inherited sites with /fr/ pages and a fr. subdomain running simultaneously, both indexed. It's a nightmare.
---
Hreflang: The Most Commonly Broken Part of International SEO
If you take one thing from this post, make it this.
Hreflang tells Google which version of a page to show to which user in which language and country. Get it wrong and you'll have your US English pages showing up in Germany, your German pages not ranking at all, or, my personal favourite disaster, your x-default pointing to a page that redirects somewhere else entirely.
The tag format looks like this in your <head>:
`` <link rel="alternate" hreflang="de" href="https://yoursite.com/de/page/" /> <link rel="alternate" hreflang="en-GB" href="https://yoursite.com/en-gb/page/" /> <link rel="alternate" hreflang="x-default" href="https://yoursite.com/page/" /> ``
A few things that trip people up constantly:
- Every page must reference every alternate, including itself. If your German page doesn't link back to the English page, and the English page doesn't link back to German, the implementation is broken.
- Language vs language-region codes.
hreflang="en"means "English, any region."hreflang="en-GB"means "English, United Kingdom specifically." If you're trying to target UK vs US separately, you need the region code. - Return tags. The German page must contain a tag pointing to the English page. The English page must contain a tag pointing back to German. Both. Always.
- Consistency with canonical tags. Your hreflang alternate URL and your canonical URL for that page must match. Exactly. Including trailing slashes.
I use Aleyda Solis's hreflang tag generator when I'm setting these up manually. And I always audit with Screaming Frog after. Always.
---
Local Signals: The Bit Everyone Forgets After Launch
Correct hreflang and a well-localised page gets you maybe 50% of the way there. The other 50% is signal: does Google have any reason to believe you're a genuine entity in that market?
For most sites, this means:
- Local backlinks. A link from a German .de domain to your
/de/pages carries meaningful weight. Links from French media to your French pages, same thing. Getting a link from a US blog to your German content doesn't help nearly as much as people assume. - Google Business Profile. If there's any physical presence, even a registered address, set up a GBP for that location. Fill it out properly. This is table stakes for local pack visibility.
- Local schema. Add
LocalBusinessschema with the correct country, address format, and phone number format. Don't just copy your English schema and translate the description. The structured data needs to match the locale specifics. - Hosting location. Less important than it used to be given CDNs, but if you're using a CDN (and you should be), confirm your edge nodes are serving European users from European servers. Cloudflare's free plan handles this. It's not a huge ranking factor but it contributes to TTFB in that region, which matters.
Back in 2019 I had a client in the health supplement space trying to rank in Spain. Their localisation was good. Their hreflang was correct. But they had zero Spanish backlinks, their GBP for their Madrid address was unclaimed, and their schema still listed a UK phone number. Fixing those three things over about four months took them from page 4 to page 1 for three of their target terms.
---
Content Depth Varies by Market
This is something keyword research won't fully tell you. Some markets are informationally hungry; others convert on thin product pages.
Germany is notoriously thorough. German searchers tend to want detailed comparison content, spec tables, and clear return policies before they buy anything. A 300-word product page that converts in the UK might need to be 900 words with a FAQ section to perform in Germany.
Japan is another one. Japanese search results for commercial queries often feature extremely detailed, long-form content. The SERP looks different, user behaviour is different, and content expectations reflect that.
I'm not saying write 2,000 words for every market just because you can. I'm saying: look at what's actually ranking in that country, in that language, for your target query. Open an incognito window, set your Google country manually, and look at the top three results. What length are they? Do they have video? Do they have tables? Do they have user reviews embedded? That's your benchmark, not what works in English.
---
The Technical Audit Checklist Before You Go Live
Before any international site goes live from Seahawk, we run through this in order:
- Confirm URL structure is consistent across all locales
- Validate hreflang tags on every page type (home, category, product, blog) using Screaming Frog
- Check canonical tags align with hreflang alternate URLs exactly
- Verify x-default is set and points to a live, non-redirecting page
- Test geo-targeting settings in Google Search Console (International Targeting report, under Legacy Tools)
- Confirm XML sitemap includes all localised URLs and is submitted per locale if using separate properties
- Check page speed from target regions using WebPageTest with a European or Asian node
- Validate LocalBusiness schema with Google's Rich Results Test for at least one representative page per locale
That's not every check we do. But if those eight are clean, the foundation is solid enough to start building on.
---
The Patient Game: Timelines and Expectations
Here's something I wish I could put on a billboard for every client who comes to us for international SEO: this takes longer than English SEO. A lot longer, sometimes.
When you launch a new localised section, you're essentially launching a new site from Google's perspective in that market. You have no local backlink history. You have no local engagement signals. You have no query history. Google is cautious.
Realistic timeline: 3 months to see any movement, 6 months to start forming conclusions, 12 months to actually evaluate whether the localisation strategy is working. I know that's not what anyone wants to hear. But clients who go in with that expectation are far less likely to pull the plug at month 4 when they haven't hit page 1 yet.
The SaaS client I mentioned at the start? We rebuilt their whole international setup in Q1 of 2022. By Q4 of 2022, their German traffic had gone from 38 sessions a month to around 1,400. France was at 800. It took nine months of consistent work. No shortcuts. Just correct architecture, real localised content, and patient link building in each market.
---
FAQ
Do I need a separate Google Search Console property for each language?
Not if you're using subdirectories. One GSC property covers the whole domain, and you can filter by URL prefix to see per-locale data. If you're using ccTLDs, then yes, each domain needs its own property. Subdomains can be set up as separate or covered under a domain property. I prefer separate for cleaner data.
Can I use machine translation for localised content?
Short answer: no, not as your final output. Google can detect machine-translated content and it's covered under their Spam Policies as auto-generated content. Use DeepL or similar to get a first draft, then have a native speaker edit it properly. The editing pass is where localisation actually happens anyway.
How do I handle a language spoken across multiple countries? Like Spanish for Spain vs Mexico?
You use separate hreflang codes: es-ES for Spain and es-MX for Mexico. And ideally you have genuinely different content for each, or at minimum different metadata targeting local queries. Don't just point both hreflang codes to the same page. Google will figure out what you're doing.
What if my CMS doesn't support hreflang natively?
Most do with plugins. WPML and Polylang both handle hreflang well on WordPress. For custom builds, you can output the tags via your XML sitemap rather than the <head>, which Google accepts. The sitemap method is actually easier to maintain at scale. Just make sure it's validating cleanly.
---
Localisation SEO is slow, fiddly, and often under-resourced. Most of the sites I've audited have the translated content but the technical layer is either missing or broken. Fix the architecture first. Then build the local signals. The content is the easy bit, honestly. The boring stuff is what makes the difference.