A client came to me in 2021 with a WooCommerce store that had been running beautifully in English for three years. Solid rankings. Decent traffic. Then their agency "internationalised" it for the French and German markets. Six weeks later, the English rankings had dropped 40%. The French and German pages were getting indexed, but Google was confused about which version to serve for which query. Nobody had touched the hreflang tags. Nobody had thought about URL structure. The "translation" was just duplicated content sitting on the same domain with a query string like ?lang=fr.
I spent two weekends untangling that mess. So let me save you the same pain.
Translating a WordPress site is genuinely not hard once you understand what Google actually needs. The problem is that most tutorials stop at "install a plugin, add your languages, done." That's where the SEO damage begins.
---
Why Translation Breaks SEO (And Why Most People Don't Notice Immediately)
Search engines are picky about duplicate content. When you add a French version of your homepage and it lives at yourdomain.com/?lang=fr instead of yourdomain.com/fr/ or fr.yourdomain.com, Google often treats both URLs as the same page with slightly different content. Neither version ranks well. Your existing English page can start losing authority because the signals are diluted.
The second problem: hreflang. This is the HTML attribute that tells Google "this page in French is the equivalent of that page in English." Get it wrong and you create what Google itself calls a "return tag" error, where the hreflang chain is broken and Google ignores the whole lot.
I've seen this on a Seahawk project for a SaaS client in 2023. They had 11 languages added via a plugin, but the plugin was generating hreflang tags only for pages it had translated. Untranslated pages had no self-referencing hreflang tag. Result: Google started deindexing the English versions of those pages because it thought they were orphaned duplicates. Not malicious, just careless configuration.
The fix isn't complicated. But you have to be deliberate about it from day one.
---
Choosing the Right URL Structure Before You Touch a Plugin
This is the decision that locks in your architecture. You have three options.
- Subdirectories:
yourdomain.com/fr/,yourdomain.com/de/, my default recommendation for most sites. - Subdomains:
fr.yourdomain.com,de.yourdomain.com, works well if you want to treat each language as a separate property in Search Console. - Separate domains (ccTLDs):
yourdomain.fr,yourdomain.de, strongest geo-targeting signal, but expensive and complex to maintain.
For 90% of sites I build, subdirectories win. They inherit domain authority, they're simpler to manage in one WordPress install, and Google handles them well. The only time I'd go subdomain or ccTLD is when a client has serious geo-targeting requirements and a dedicated team for each market.
Pick your structure before installing a single translation plugin. Changing it later means 301 redirects, updated hreflang, updated sitemaps, and at least a few weeks of ranking turbulence. I learned this the hard way on a hospitality client's site in 2020 where we switched from subdomains to subdirectories mid-project. Painful.
---
Picking a Translation Plugin That Won't Fight Your SEO
There are three plugins worth your attention. Everything else is noise.
WPML
WPML is what I use on almost every professional multilingual build at Seahawk. It's not free (starts around $39/year for the basic licence), but it generates clean hreflang tags, handles URL structure properly, integrates with WooCommerce without drama, and has a String Translation module for things like navigation labels and widget text.
The one thing you must do: go to WPML > Languages > Language URL format and choose "Different languages in directories" (i.e., the subdirectory option) unless you have a specific reason not to. The default is sometimes set to query strings. Change it.
Polylang
Polylang is the free alternative and it's genuinely solid for simpler sites. The free version handles URL structure and basic hreflang. You'll want the Pro version ($99/year) if you're running WooCommerce or need translation management features. I used it on a small NGO site last year and it behaved perfectly for three languages.
TranslatePress
TranslatePress has a different approach: you translate directly on the front end, visually. That's great for clients who want to manage their own translations. The SEO pack add-on (paid) handles hreflang and meta translation. Without that add-on, your translated pages will have duplicate meta titles and descriptions. Don't skip it.
Avoid automatic translation as your only layer. Machine translation from DeepL or Google Translate is fine as a starting draft, but it needs human review before you publish. Thin, poorly translated content ranks poorly and creates a bad user experience. I always tell clients: if your translated content reads like it was written by someone who doesn't speak the language, Google will figure that out too.
---
Setting Up Hreflang Correctly
Hreflang is the bit most developers get wrong. Here are the rules, plainly:
- Every page needs a hreflang tag for every language version of that page, including itself.
- You must include
x-defaultpointing to the version you want served when no language preference matches. - The hreflang value must match a valid BCP 47 language tag. That means
en-gbnoten-GB(lowercase, hyphenated, region code after the language). - The relationship must be reciprocal. If
/fr/points to/en/via hreflang, then/en/must point back to/fr/.
WPML handles most of this automatically. But I always validate manually with Hreflang Tags Checker by Aleyda Solis after setup. It's free and takes about three minutes to run. Worth every second.
One edge case: if you have pages that aren't translated yet. Don't leave them without hreflang. Either point x-default to the English version, or add a self-referencing hreflang for English only until the translation is ready. A gap in the hreflang chain does more damage than you'd think.
---
Sitemaps, Search Console, and Crawl Budget
Once your translated pages are live, you need three things sorted before Google sees them.
- Submit a sitemap that includes all language versions. WPML and Polylang both generate multilingual sitemaps automatically when combined with Yoast SEO or Rank Math. Check that the sitemap at
yourdomain.com/sitemap.xmlactually lists your/fr/and/de/URLs before you submit anything. - Add each language subdirectory as a separate property in Google Search Console if you want granular performance data per language. Or add them as prefixes within the same root domain property. Either works, but separate properties give you cleaner data.
- Think about crawl budget. For a site with 500 pages and 5 languages, you suddenly have up to 2,500 indexable URLs. Google doesn't have unlimited appetite for crawling. Make sure your translated pages are not behind unnecessary JavaScript rendering, don't have noindex tags left over from staging, and load reasonably fast. Under 3 seconds on mobile is my working target.
A quick note on Rank Math: its Multilingual SEO module plays nicely with WPML and Polylang and lets you set translated meta titles and descriptions per language from within the familiar Rank Math interface. I switched a client from Yoast to Rank Math specifically for this reason last March and the workflow improved significantly.
---
Handling Translated Metadata and On-Page SEO
Translated URL slugs matter. /fr/a-propos/ performs better than /fr/about/ for French-speaking searchers. It signals to both users and Google that this is a genuinely localised page, not a direct copy.
WPML lets you set translated slugs. So does Polylang. Use them. I know it's extra work. Do it anyway.
Meta titles and descriptions need to be translated and rewritten for each market, not just run through a translator word-for-word. Search intent varies by language. A French user searching for your product may use different phrasing than an English user. Keyword research per language, even basic research with Google Keyword Planner or Ahrefs, makes a real difference to how well translated pages perform.
Image alt text is often forgotten entirely. Your translated pages should have alt text in the target language. Same for any schema markup that includes text fields.
One more thing that trips people up: WordPress menus. If your navigation has "About Us" in English, you need a translated menu item in French pointing to /fr/a-propos/. WPML has a menu sync feature that prompts you to translate menu items. Use it. Otherwise you get French pages with English navigation, which looks sloppy and confuses crawlers.
---
Testing Before You Go Live
Don't skip this. I run through a quick checklist on every multilingual build before flipping to production.
- Check hreflang tags on at least the homepage, one interior page, and one product or blog page per language. View source or use a browser extension like SEO Meta in 1 Click.
- Crawl the site with Screaming Frog. Filter by
hreflangin the Hreflang tab. Any "non-200" or "missing return tag" errors need fixing before launch. - Confirm your XML sitemap lists all language URLs and submit it in Search Console.
- Test language switching in a private browser window to make sure cookies or geolocation redirects aren't sending users to the wrong version.
- Verify that translated pages return 200 status codes, not 301s or 404s.
The whole checklist takes maybe 90 minutes on a medium-sized site. That 90 minutes has saved me from at least four post-launch panics over the years.
---
FAQ
Does translating my site guarantee I'll rank in other countries?
No. Translation is a prerequisite, not a guarantee. You still need backlinks from relevant local domains, genuine local search demand, and content that actually serves the user's intent in that market. Translation opens the door. SEO work in each language walks you through it.
Can I use Google Translate or DeepL to auto-translate my whole site?
You can use them as a first draft. Both WPML and TranslatePress have integrations with DeepL for machine translation. But publishing raw machine translation without human editing is a bad idea. The content reads awkwardly, which increases bounce rates, and Google's quality assessors do evaluate translation quality on larger sites.
Should each language have its own Google Search Console property?
It depends on your URL structure. If you're using subdirectories (yourdomain.com/fr/), one root domain property in Search Console covers everything, but adding a URL prefix property for /fr/ specifically gives you cleaner per-language data. If you're using subdomains, you'll want separate properties. For ccTLDs, you have no choice, they're separate domains.
What if I only want to translate a few pages, not the whole site?
That's fine. Just make sure those translated pages have proper hreflang pointing back to their English equivalents, and that the English pages point back to the translated versions. Partial translation is a legitimate approach, especially for sites where only a product or landing page section targets a foreign market.
Is it worth hiring a professional translator or is machine translation good enough?
For anything public-facing, I'd always say get a human translator to at least review the output. For a small brochure site with 10 pages, the cost is minimal. For a large WooCommerce catalogue, you might use machine translation for bulk content and human review for high-value pages like product descriptions, checkout flows, and legal pages. That split approach works well in practice.
---
Translation done right is one of those things that compounds quietly. You set it up properly once, Google indexes everything cleanly, and over 12 to 18 months your organic footprint in a new market grows without you having to rebuild anything. Get the architecture wrong and you're fighting Google indefinitely. The plugin work is the easy part. The structural decisions, URL format, hreflang, translated metadata, that's where the real work is. Spend an extra afternoon getting those right. Your future self will be grateful.