A client came to me in 2021 with a WordPress e-commerce site targeting seven countries. They'd hired a translation agency, plugged everything into WPML, and called it done. Organic traffic in five of those seven markets was essentially zero. Not low. Zero. The German pages were cannibalising the English ones. The Arabic pages had no dir="rtl" attribute anywhere. And the hreflang tags? Pointing at URLs that 301-redirected to completely different pages.
That was a three-month recovery job. I billed fairly, but I've thought about it ever since, because every single problem on that site was preventable with a decent checklist run before launch.
So here's mine. The exact order I work through it, the tools I actually open, and the things that still catch out experienced developers.
---
Start With URL Structure (Before You Touch Anything Else)
This decision is permanent. Or close enough to permanent that you should treat it that way. I've seen agencies change URL structures on live multilingual sites and watch six months of link equity evaporate.
Your three options are subdirectories (/fr/), subdomains ( fr.), or ccTLDs ( site.fr). Google's own documentation on international targeting is pretty clear that all three work, but the trade-offs are real.
For most of my clients, I go subdirectories. One domain, one pool of authority, one crawl budget to manage. Subdomains make sense when you've got genuinely separate teams running separate operations (Seahawk had a SaaS client once where the US and EU products were actually different regulatory products, subdomains were right there). ccTLDs are for enterprises with serious local brand presence and the budget to build domain authority separately for each.
Pick one. Document it. Get sign-off before anyone writes a single line of template code.
The One Subfolder Mistake I Keep Seeing
People nest the default language under /en/ without setting up a proper redirect from the root. So site.com/ returns a 200 with no hreflang, site.com/en/ has all the content, and Google indexes both as separate thin pages. Set your root to redirect to the appropriate locale based on Accept-Language, or just make the root serve the default locale directly. Don't leave it dangling.
---
Hreflang: Get It Right or Don't Bother
Hreflang is the bit that makes most developers nervous. Rightly so. It's finicky.
The hreflang spec from Google tells you to use language-region codes (en-GB , fr-FR ), make the tags self-referential (every page references itself), and make the relationship bidirectional (if /fr/ points to /en/, then /en/ must point back to /fr/). Miss any of those and the whole thing breaks silently. Google won't throw a manual action. It just ignores your tags and guesses.
Here's my actual workflow:
- Build the full URL matrix in a spreadsheet first. Every locale, every equivalent page URL.
- Implement via the
<head>rather than sitemaps wherever possible. Sitemaps work, but<head>implementation is easier to audit by just viewing source. - Run Screaming Frog over the staging site with hreflang auditing enabled. Export the issues report.
- Cross-check with Ahrefs' site audit for any orphaned locale pages (pages in one language with no hreflang pointing to equivalents in other languages).
- Spot-check 10-15 pages manually. Just view source. Look for the pattern.
One thing people get wrong constantly: x-default . It's not "the English version". It's the fallback for users whose language doesn't match any of your locale tags. If you're targeting en-GB and en-US specifically, a Canadian English speaker needs somewhere to land. That's x-default. Point it at your most relevant catch-all page, usually the root or a language-selector page.
---
Crawl Budget and Indexation
On small sites this doesn't matter much. On a site with 50,000 pages across 8 languages, it absolutely does.
The maths is simple: if your English site has 6,000 pages and you add 7 languages, you've potentially got 48,000 pages that all need crawling and indexing. Most sites don't have the authority or the internal link structure to support that efficiently.
What I do:
- Audit which pages actually warrant translation. Not everything does. Blog posts from 2017 that get 3 visits a month in English don't need a French version.
- Use separate locale-specific sitemaps (
sitemap-fr.xml,sitemap-de.xml) and reference them all fromsitemap-index.xml. Google Search Console lets you submit and monitor each separately, which is far easier to debug. - Check crawl stats in Search Console per property if you're on subdomains or ccTLDs. For subdirectories on one domain, use the coverage report filtered by URL path.
- Noindex thin or machine-translated pages you haven't reviewed yet. Seriously. A page Google indexes as spam-quality content hurts the whole domain.
Back in 2019 a client in the travel sector pushed live with 12 language versions, all machine-translated by DeepL without any human review. Solid traffic in English, destroyed within 8 weeks in every other language. DeepL is a great tool (I still use it as a first draft) but unreviewed output at scale is a trust signal nightmare.
---
Translation vs Transcreation
This distinction matters more than most technical SEOs admit.
Translation is converting words. Transcreation is converting intent, tone, and cultural context. For landing pages, product descriptions, and anything you're spending money to rank, you want transcreation.
The practical checklist item here: for each target market, have a native speaker review at least the top 20 pages by traffic potential. Not just for grammar. For whether the copy sounds like a real human in that language or like a machine that learned the language from instruction manuals.
Keyword research is separate per locale. I use Ahrefs for this. The German keyword for a concept is not just the German word for the English keyword. Search behaviour differs. In some markets, users search more formally. In others, they use abbreviations or slang that would never appear in a direct translation. Build locale-specific keyword maps. It takes longer. It's worth it.
What to Do With Markets You Can't Afford to Transcreate Properly
Be honest with yourself. If you can't do German properly right now, don't launch German. A mediocre multilingual presence is worse than no multilingual presence. Googlebot doesn't give you credit for trying.
---
Technical On-Page Checks Per Locale
This is the unglamorous part. But it's where the wins are.
- `lang ` attribute on the `<html>` element. Should match the locale of the page.
<html lang="fr-FR">. Check every template, not just the homepage. - `dir ` attribute for RTL languages. Arabic, Hebrew, Urdu, Persian:
<html dir="rtl">. And check that your CSS actually supports it, not just the HTML attribute. - Canonical tags. Each localised page should self-canonicalise. The French page canonicalises to itself, not to the English equivalent. I've seen this wrong more times than I can count.
- Meta titles and descriptions. Translated and adapted per locale. Not left in English. Not auto-generated from a template with
[Page Name] | [Site Name]and a machine-translated tagline. - Structured data. If you're using Schema.org markup, the
inLanguageproperty should reflect the page's language. For e-commerce, check thatpriceCurrencymatches the locale's expected currency. - Image alt text. Translated. Often overlooked because it's not visible. Always checked.
I use a simple Google Sheet with all these as column headers. One row per locale. Tick when verified. Share it with the client so they understand what was checked.
---
Local Search and Google Business Profile
For clients with physical locations across markets, multilingual SEO doesn't stop at the website.
Google Business Profile supports multiple languages for the business description and service listings. Set the primary language per location correctly. If you've got a Paris office, the GBP for that location should be in French, with a French-language description, not copied verbatim from the English HQ profile.
NAP consistency (name, address, phone) across local citation directories matters per market too. In Germany that means making sure the listing is correct on Das Örtliche and Gelbe Seiten, not just Google. In France, PagesJaunes. Each market has its own citation ecosystem. Spending an afternoon mapping the top 10 citation sources per target country is time well spent.
---
Post-Launch Monitoring
Launch is not the end. It's the beginning of finding out what you missed.
My post-launch monitoring setup for multilingual sites:
- Set up Google Search Console separately per locale (subdomain or ccTLD) or use the URL prefix property per subdirectory path.
- Check the International Targeting report in Search Console under "Legacy tools". It'll surface hreflang errors within a few weeks of launch.
- Set up rank tracking in Ahrefs per locale, using the correct country/language targeting. A keyword tracked in "English, US" will give you different positions than the same keyword tracked in "German, Germany".
- Monitor crawl coverage monthly for the first 6 months. New locale pages sometimes get stuck in "Discovered, not indexed" for weeks. Usually a crawl budget or internal linking issue.
- Check for cannibalisation quarterly. Two locale pages competing for the same query in the same country is a sign something went wrong in the URL or hreflang setup.
One thing I added to my checklist after a painful experience with a fintech client: check that IP-based redirects aren't overriding hreflang. If your CDN or server is redirecting users based on IP geolocation, Googlebot (which usually crawls from US IPs) might never see your non-English pages. That fintech client had CloudFront rules aggressively redirecting non-US IPs. Took us two weeks to diagnose why the European pages had zero indexation.
---
FAQ
Do I need a separate Google Search Console property for each language?
Not necessarily. If you're using subdirectories on one domain (like site.com/fr/), you can use a URL-prefix property per subdirectory, or just use the root domain property and filter by URL path. If you're on subdomains or separate ccTLDs, separate properties are worth the admin overhead because you get cleaner data per market.
Is machine translation good enough for SEO in 2024?
For a first draft, yes. For publishing without human review, no. DeepL and Google Translate have got genuinely good, but they produce content that's grammatically correct and tonally flat. Search engines are increasingly good at distinguishing content that reads naturally in a language from content that's been translated. Use machine translation to move fast, then get a native speaker to review the high-value pages before indexing.
How do I handle a market where I only have partial translation coverage?
Noindex the untranslated or partially translated pages until they're ready. Don't publish half-finished locale pages just to have them live. The damage to trust signals from thin content in a language is harder to reverse than the delay in launching.
What's the single most common hreflang mistake?
Missing the self-referential tag. Every page needs a hreflang tag pointing to itself in addition to pointing to all its equivalents. Developers often implement the cross-references correctly and forget the self-reference. Screaming Frog will catch this in about 30 seconds, run it before every launch.
Should I translate URLs or keep them in English?
Translate them. /fr/chaussures/ outperforms /fr/shoes/ in French search because the slug contributes to relevance signals. It also looks more trustworthy to French-speaking users. The extra implementation effort (you need locale-specific routing and slug translation in your CMS) is worth it for any market you're seriously targeting.
---
Multilingual SEO isn't a checkbox you tick once. It's a discipline. The checklist above has saved me from expensive post-launch firefighting more times than I'd like to admit, and it's still evolving. Every new build teaches me something. Most recently: always check what the CDN is doing to non-default-locale requests before you declare a site ready. Always.