Multilingual Site Structure and Hreflang: More Than Translating a Chinese Website
The short version
Decide the URL structure first. Subdirectories like example.com/en/ and example.com/de/ are the right call for almost every Chinese company on its first overseas push. Skip subdomains and country-code domains until you actually have local teams to run them. Each language version declares the others through hreflang, including x-default, and each page's canonical points to itself, never to another language. Don't auto-redirect users by IP. Let them choose, then remember the choice with a cookie. And the rule most teams ignore: the English site is not a translation of the Chinese site. It's a different document. Different case studies, different FAQ questions, different CTAs, different vocabulary. On WordPress, pick Polylang or WPML and stay there. Switching later means re-importing translations and rebuilding every language relationship by hand. After launch, check Search Console's International Targeting report and run site: queries per language to confirm Google is serving the German page to German users, not the English one.
The failure pattern we see most: a manufacturer machine-translates 200+ Chinese pages into English and German, ships /en/ and /de/ as subdirectories, and three months later discovers German buyers searching the brand name only land on the legacy /cn/ tree. The hreflang was technically present and technically wrong. Every URL self-canonicalized fine, but the hreflang block on /en/ pointed back to / (default Chinese). Google decided the whole language set was variants of one page, not three independent documents.
This guide is for Chinese teams launching their first multilingual site. Not a spec sheet. A set of trade-offs: how to choose URLs, how to split content, how to verify after launch.
1. URL structure
Three options on the table:
- Subdirectories:
example.com/en/,example.com/de/,example.com/es/. One domain, one certificate, one DNS zone, one pool of authority. - Subdomains:
en.example.com,de.example.com. Google treats these as semi-independent sites; SEO authority builds separately for each. - Country-code TLDs:
example.de,example.fr,example.co.uk. The strongest local signal, but every domain needs its own content, links, certificates, and analytics.
Nine out of ten small-to-mid exporters should pick subdirectories. The reason is operational, not technical. You don't have the bandwidth to maintain three independent properties while still figuring out your first overseas market. Subdirectories consolidate everything under one domain: authority, analytics, link equity, monitoring. Google's localized versions guidance supports all three structures and tells you to pick the one your team can actually maintain.
When does a subdomain make sense? When the language version is run by a separate local team with its own marketing calendar and conversion paths. If HQ is in Hangzhou but the German subsidiary handles its own sales and content, de.example.com lets that team operate independently.
When does a country-code TLD make sense? When the target market has a strong local-domain trust signal (Germany expects .de, France expects .fr, the UK expects .co.uk) AND you have headcount to run separate sites. End-state, not starting point.
2. hreflang done right
Hreflang tells Google "these URLs are the same content in different languages or regions." Get it wrong and search engines treat them either as duplicate content or as completely unrelated pages.
Every language version needs the full set in <head>:
<link rel="alternate" hreflang="en" href="https://example.com/en/products/" />
<link rel="alternate" hreflang="de" href="https://example.com/de/produkte/" />
<link rel="alternate" hreflang="zh-CN" href="https://example.com/cn/products/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/products/" />
<link rel="canonical" href="https://example.com/en/products/" />
Four rules:
- Bidirectional: if A lists B, B must list A. One-way declarations are silently dropped.
- Self-reference:
/en/products/must includehreflang="en"pointing to itself. - Self-canonical: never canonical
/de/produkte/to/en/products/. That tells Google the German version is a duplicate, and it'll fall out of the German index. - Include
x-default: when a user's language or region isn't in your list, Google falls back tox-default. Usually it points to the English master version.
Use ISO 639-1 codes (en, de, zh). For region variants, use language-region with a hyphen: en-US, en-GB, zh-CN, zh-TW. Never en_US — underscores break the BCP 47 language tag format that Google parses against.
WordPress plugins (Polylang, WPML) generate hreflang automatically, but the output isn't always right. Common issues: plugin URLs don't match the canonical URLs (trailing slash, www vs. apex), x-default is missing, or the plugin declares languages for pages that haven't actually been translated yet. Run Screaming Frog or Ahrefs' hreflang validator across every language version before launch.
3. Don't auto-redirect
A common first instinct: detect the user's IP, redirect a German visitor straight to /de/. Feels helpful. Usually breaks more than it fixes.
Two reasons:
- Googlebot crawls primarily from US IPs. If you redirect by IP, Googlebot trying to reach
/de/gets bounced to/en/, and the German version never gets indexed properly. - A user's IP doesn't equal their language. A Chinese expat in Berlin probably wants the Chinese version. Forcing a German page feels worse than not localizing.
Better pattern: default to x-default (usually English), put a clear language switcher in the top-right nav, remember the user's choice with a cookie. Never use meta http-equiv="refresh" or window.location for IP-based redirects.
Google says the same in its multi-regional guidance: don't auto-redirect by perceived location, because it prevents Google and users from reaching all versions.
4. Translation isn't localization
Getting the technical layer right is the floor, not the ceiling. What moves overseas inquiries is whether the content reads like it was written for the buyer or translated at them. Word-for-word translation shows up immediately. Sentence rhythm, missing context, wrong industry vocabulary, off-tone CTAs.
What the English version needs to rewrite, not translate:
- Case studies: the Chinese site might list 20 mainland clients. The English site doesn't need them. Pick three to five overseas customers and write country, industry, and scale clearly.
- FAQ: Chinese customers ask about fapiao and WeChat integration. Overseas buyers ask about payment terms, Incoterms, lead times, and MOQs. The two sets don't translate into each other.
- CTAs: "立即咨询" doesn't always become "Contact us." Depending on the model, it might be "Request a quote", "Book a demo", "Get a sample", or "Download spec sheet."
- Industry vocabulary: use what the target market says. "Environmental equipment" in German is
Umwelttechnik, not whatever a translation tool produces. Native writers handle this. LLM plus DeepL doesn't.
Localized SEO vs Direct Translation goes deeper on the content side. Short version: translation swaps words; localization rewrites the document.
5. WordPress plugin choice
For WordPress, two real options:
- Polylang: free tier covers most needs, clean UI, minimal performance hit. Polylang Pro plus String Translation handles the long tail. Good when budget is tight and the technical team handles edge cases.
- WPML: paid (annual license $99–199), most complete feature set, best compatibility with WooCommerce, Yoast, and ACF. Better for content-heavy sites and teams wanting one vendor for everything.
Both generate hreflang automatically and support all three URL structures. Pick one and don't switch. Migration between them means re-importing translations, rebuilding language relationships page by page, possibly changing URLs, and rewriting every hreflang block.
Don't use Google Translate Widget or any "one-click translation" plugin. They produce JavaScript-injected on-the-fly translations that search engines can't crawl and hreflang can't reference. SEO-wise, that's a single-language site with a fancy widget.
For a deeper architecture comparison, see WordPress Overseas Website Architecture.
6. Language switcher
Looks like a frontend detail. It isn't.
- Position: top-right navigation. Chinese designers often put it bottom-right or in the footer; Western users won't find it there.
- Format: dropdown with flag icon plus language name ("English", "Deutsch"). Don't use flag-only. One flag can't represent multiple countries sharing a language. German runs in Germany, Austria, and Switzerland.
- Routing: when a user on
/en/products/page-aswitches to German, send them to/de/produkte/seite-a, not the German homepage. Polylang and WPML both support per-page linking, but content editors have to do it manually. - Mark the language code: set
<html lang="de">or<html lang="en">correctly per version. Foundation for accessibility tools, machine translation, and SEO signals.
7. Verify after launch
Hreflang in <head> doesn't mean it's working. Verify at least four things post-launch:
- GSC International Targeting report: under Legacy tools and reports. Lists hreflang errors: missing back-links, mismatched declarations, invalid codes.
site:queries per language:site:example.com/de/shows German pages indexed;site:example.com/en/shows English. Counts shouldn't differ by an order of magnitude unless you genuinely localized only part of the site.- Region-simulated search: use a VPN to search the brand name from a German IP. The top result for
/de/keywords should be the German page, not/en/or/cn/. - CTA entry points: each language version's WhatsApp, X, and email CTA should land in the right language. German users clicking WhatsApp shouldn't get a pre-filled English message.
For the broader post-launch playbook, see The First 30 Days After Launching an Overseas Website.
8. Migrating an existing site
Upgrading a single-language site to multilingual means original URLs move. example.com/products/page-a becoming example.com/en/products/page-a requires a 301 redirect for every old URL. Skip this and you lose SEO authority and external links built up over years.
Migration checklist:
- URL map: every old URL paired with its new URL in a single spreadsheet the technical team configures from.
- Canonical fixes: update old canonical references so Google doesn't see contradictory signals.
- Sitemap resubmit: new sitemap covers all language versions; submit to Search Console.
- External link outreach: for high-value backlinks (partner sites, directories, press), contact the source and update the link directly. Don't rely on 301 chains for top referrers.
Full migration sequence in Website Content Migration Checklist.
9. Common misconceptions
The bad assumptions we keep correcting:
- "Launch English first, add German when we need it": fine, but plan multilingual URL structure from day one. Adding
/de/three months later means restructuring every English URL, another round of 301s, and authority dilution. - "Just put hreflang in the sitemap": pick one. Don't do both. Conflicting declarations confuse Google. We recommend on-page because it's easier to debug.
- "AI translation is good enough": modern LLMs and DeepL handle product specs adequately. FAQ tone drifts. Case study narratives feel off. Legal and pricing language contain errors. High-decision-cost content needs native review.
- "Multilingual slows the site": Polylang and WPML add database queries, but with page caching (WP Rocket, LiteSpeed Cache) the rendered page is indistinguishable from a single-language site.
Launch table
| Area | Must-pass items | Owner |
|---|---|---|
| URL structure | Subdirectory paths confirmed; URL per language listed | Tech + SEO |
| hreflang | Bidirectional, self-referenced, correct canonical, includes x-default | Tech |
| Auto-redirect | IP-based redirect off; language switcher only | Tech |
| Switcher | Top-right, text + flag, lands on equivalent page | Tech + Content |
| Localized content | Cases, FAQ, CTAs, vocabulary all rewritten | Content |
| WordPress plugin | Polylang or WPML chosen; hreflang output validated | Tech |
| Language tagging | <html lang="..."> correct per version | Tech |
| Verification | GSC International Targeting, site: queries, region simulation | SEO |
| Migration | Old URL 301 map, sitemap submitted | Tech + SEO |
FAQ
One domain or separate domains per language?
Almost always one. A single .com with /en/, /de/, /es/ paths plus correct hreflang is the pattern Google recommends in its localized versions guidance, and the easiest structure for a small overseas team to maintain. Country-code TLDs (.de, .fr) only earn their cost when you have a fully staffed local team and the target market shows a strong local-domain trust preference.
What are the most common hreflang mistakes?
Four show up repeatedly: one-way declarations (A lists B, B doesn't list A); wrong code format (en_US instead of en-US); canonical pointing to a different language; missing x-default. Search Console's International Targeting report or a third-party crawler (Screaming Frog, Ahrefs Site Audit) catches about 90% of these before launch.
Is AI translation good enough?
Acceptable for objective content like specs and parameters with a light native pass. Not acceptable for marketing copy, FAQs, case study narratives, or legal terms. The most common Chinese-team mistake is translating "professional one-stop service" word-for-word; overseas readers see vague language like that and close the tab. For more on this, see Localized SEO vs Direct Translation.
How long does a multilingual launch take?
If the Chinese site is stable, adding English usually takes four to six weeks. One week for URL structure and plugin choice. Two weeks for content rewriting and native review. One week for technical implementation and hreflang. One to two weeks for QA and verification. Each additional language adds three to four weeks, mostly spent on content rewriting, not technical work.
Get a diagnosis
If you're preparing a multilingual website, or you've launched but Google isn't serving the right language to the right region, bring your domain, target markets, and current URL structure. We'll run hreflang, content localization, and verification checks under our overseas website build and SEO/GEO support service in a free initial review, and flag which fixes are P0 versus what can wait.