This post contains affiliate links. If you buy something through one of them, Veravix may earn a commission at no extra cost to you.
A SaaS founder I worked with pulled up her analytics mid-call and pointed at the country breakdown: eighteen percent of last month’s traffic was coming from Germany, Brazil, and France, and none of it was converting anywhere near as well as her US and UK segments. Her question was simple — should we translate the site? The honest answer took longer to give than she expected, because the real decision isn’t whether to translate. It’s how much of the site’s architecture you’re willing to commit to a second language, and that commitment is a lot bigger than picking a translation plugin.
In every localization project I’ve scoped, the plugin choice is the easy twenty minutes. The part that actually determines whether the project works — whether Google treats the result as a legitimate second version of the site instead of a folder of confused duplicate content, and whether visitors in the new language get a page that reads like it was written for them — gets decided before any plugin is installed. It’s the URL structure, the hreflang setup, and which pages get machine translation versus a human pass. Skip that groundwork and even the best translation plugin just automates a mistake faster.
This is the layer before the mechanics. If you’ve already decided to add a language and just need the WordPress-specific steps — which plugin, how to configure it, what Google actually flags as risky — how to add AI translation to your WordPress website covers that directly. This post covers the three structural decisions that determine whether that setup work actually pays off: how to structure the URLs, how to implement hreflang so Google understands what you’ve built, and how to decide which pages deserve a human translator instead of a machine.
Quick Answer
For most sites adding one or two languages, a subdirectory structure (yoursite.com/fr/) is the right call — it’s the cheapest to set up, keeps all your existing domain authority in one place, and is what most translation plugins default to. Reserve a country-code domain (a separate .de or .fr) for a market big enough to justify its own hosting, legal entity, and marketing budget, and a subdomain for a case where you genuinely need separate infrastructure — different hosting region, different team, different CMS — but don’t want to buy a new domain. Whatever structure you pick, every translated page needs hreflang annotations pointing to every language version of itself, including a self-reference and an x-default fallback; Google does not infer language targeting from URL structure alone, so this step isn’t optional. On translation itself, use machine translation as the default for the long tail of content, but put a human editor on anything a visitor might buy something through — homepage, pricing, checkout, and your two or three highest-traffic pages. Skip the whole project if under roughly 5% of your traffic comes from a market where English isn’t functionally understood for your audience; the setup and ongoing maintenance cost outweighs what you’d gain.
Choosing a URL Structure: Subdirectory, Subdomain, or Country-Code Domain
Google itself lists four ways to structure a multilingual or multi-regional site, and — deliberately — doesn’t rank one above the others. Its own documentation states the tradeoffs plainly and leaves the choice to the site owner’s infrastructure and budget, not SEO potential. The fourth option, using URL parameters (yoursite.com/?lang=fr) instead of a real path, is the one case Google does flag directly: it’s harder for the site owner to manage and for Google to reliably associate with the right region, so it’s not worth considering for a new project.
| Subdirectory | Subdomain | Country-Code Domain (ccTLD) | |
|---|---|---|---|
| Example | yoursite.com/de/ | de.yoursite.com | yoursite.de |
| Setup cost | Low — same hosting, same install | Low to moderate — can share or split hosting | High — new domain, often new hosting and legal setup per market |
| Domain authority | Fully shared with the main site | Mostly shared, though search engines sometimes treat it as semi-independent | Starts from zero — a separate domain builds its own authority from scratch |
| Server location | Single location for every language | Can point at a different server per subdomain | Irrelevant to geotargeting — the domain itself signals the country |
| User trust signal | Weak — most visitors don’t parse a URL path as a targeting signal | Weak, same reason | Strong — a .de domain reads as “this is a German business” before the page even loads |
| Best fit | Adding one to a handful of languages to an existing site | A market that genuinely needs separate infrastructure without a new domain purchase | A flagship market big enough to justify running it as close to a separate business |
In practice, subdirectories win most of the time simply because most sites adding a language aren’t opening a genuinely separate regional business — they’re extending an existing one. Every backlink, every bit of accumulated trust, and every existing ranking on the main domain carries over immediately to a new subdirectory, which is the opposite of a ccTLD, which starts building authority from nothing. The one case worth taking seriously is a market where a local domain extension changes buyer behavior in a way English-language SEO metrics don’t capture — certain enterprise or government buyers in some countries will not do business with a foreign-domain vendor regardless of how well the page is translated, and no amount of hreflang fixes that.
If the deciding factor is hosting rather than trust — you need a server physically closer to a specific region for latency, or a market’s data-residency rules require it — that’s a separate infrastructure question from URL structure, and it’s worth reading multi-region hosting for WordPress before assuming a ccTLD is the only way to get it. A subdomain or even a subdirectory can sit behind region-specific hosting or a CDN edge without changing the URL structure at all.
Hreflang: What It Actually Does, and the Rules That Are Easy to Get Wrong
Hreflang is not a ranking signal and it doesn’t affect whether a page ranks well. What it does is tell Google which version of a page to show a searcher based on their language and location — so a French speaker searching in French gets pointed to yoursite.com/fr/pricing instead of the English original, even if the English page technically ranks higher on its own. Get it wrong and Google either shows the wrong language version, or — more commonly — treats your translated pages as unrelated duplicate content instead of intentional localized variants.
The syntax follows a fixed pattern: hreflang="[language]-[region]", using ISO 639-1 language codes and, optionally, ISO 3166-1 Alpha-2 region codes — de for German speakers generally, de-AT for German speakers specifically in Austria. Google accepts the annotation three ways: HTML link tags in the page header, HTTP response headers (mainly useful for non-HTML files like PDFs), or listed in an XML sitemap. All three are functionally equivalent to Google, so pick whichever your setup makes easiest — most WordPress translation plugins handle this automatically once a URL structure is chosen, and if you’re maintaining a sitemap by hand, how to create an XML sitemap in WordPress covers where hreflang entries fit into that file.
Three rules cause most of the real-world mistakes:
- Every page must reference itself, not just the others. If your French page lists hreflang tags for English and German but not for itself, Google can discard the whole set of annotations as inconsistent.
- The links have to be reciprocal. If the English page says “the French version is at /fr/pricing,” the French page has to say “the English version is at /pricing” right back. A one-directional link is treated as unreliable and often ignored entirely.
- Use x-default for the fallback. The reserved value
hreflang="x-default"marks which page to show a visitor whose language doesn’t match any version you’ve built — typically the homepage or a language-selector page, not just a duplicate of the English version.
A URL structure with no hreflang still works — visitors can navigate it, and each page can still rank on its own. What hreflang adds is control: without it, Google decides on its own which language version to show a given searcher, using signals like the page’s detected language and the searcher’s location, and it doesn’t always guess right. With it, you’re telling Google directly instead of hoping its guess matches yours.
Machine Translation, Human Translation, or Transcreation
These aren’t three tiers of the same thing with translation quality as the only variable — they’re three different jobs, and conflating them is where most localization budgets get spent in the wrong place.
Machine translation converts text directly, fast and at near-zero marginal cost once a plugin or API is in place. Modern neural engines (the same class of model behind DeepL and Google Translate) handle straightforward, literal content well — documentation, FAQ entries, product descriptions with a consistent format, blog content where the goal is comprehension rather than persuasion. Human translation adds a person who understands both languages fluently, catching idioms, ambiguity, and tone that a model still gets wrong often enough to matter, at a real per-word cost — professional human translation generally runs $0.15 to $0.30 per word for standard content, more for specialized or regulated subject matter, while machine translation with a human editing pass afterward typically lands around $0.05 to $0.15 per word. Transcreation goes further still: instead of translating the original sentence, a specialist rewrites the message for the target market’s culture and idiom, sometimes departing from the source text entirely to preserve the intent — a taglines, a marketing headline built on wordplay, or a slogan that doesn’t survive literal translation all need this, not a more careful translation of the same words.
The practical decision isn’t “which one should we use” — it’s matching the right one to each type of content on the site:
| Content type | Recommended approach | Why |
|---|---|---|
| Documentation, FAQs, support articles | Machine translation, light review | High volume, literal meaning matters more than style |
| Blog and informational content | Machine translation, periodic human review of top-traffic pages | Comprehension is the goal; perfect prose isn’t essential |
| Homepage, pricing, checkout | Human translation, reviewed before publishing | Directly affects revenue and trust; a mistranslated price or term causes real confusion |
| Taglines, ad copy, brand messaging | Transcreation | Wordplay and cultural references rarely survive literal translation |
If you don’t already have a translator relationship for a given language, a freelance marketplace is usually the fastest way to get a qualified person on a page-by-page basis rather than committing to an agency retainer before you know the project is worth it — Fiverr has a dedicated translation and localization category where you can filter by language pair and specialty, and check a seller’s review history and completed-order count before handing over your pricing page. That’s usually enough vetting for a handful of high-stakes pages, which is exactly the scope this decision framework says actually needs a human in the first place.
The SEO Case For and Against Localizing
The case for is straightforward and backed by a large, if slightly dated, piece of research: CSA Research’s 2020 survey of 8,709 consumers across 29 countries found that 76% prefer buying products with information in their own language, and a large share said they’d never buy from a site that wasn’t in a language they were comfortable with. That’s the upside — a localized page can genuinely convert a segment of traffic your English original never will, no matter how well it ranks.
The case against is a risk this site has covered in detail elsewhere, and it’s worth taking seriously before assuming translation is a free traffic multiplier: Google’s spam policies explicitly list “creating pages by automatically translating content without human review or localization” as an example of scaled content abuse, the same policy category used against AI content farms and auto-generated doorway pages. This doesn’t mean machine translation itself is against the rules — Google’s own public guidance is explicit that intent and end-user value are what get judged, not the tool used to produce the page. What it targets is publishing hundreds of raw, unreviewed machine-translated pages purely to occupy search results in another language, with no human check and no adaptation of currency, idioms, or local context. That’s precisely the failure mode a rushed localization project falls into: someone flips on auto-translate for the entire site in an afternoon and walks away, and the volume alone starts to look like the pattern the policy is written to catch.
The dividing line between the two outcomes isn’t the translation engine. It’s whether a human ever looked at the result before it went live, and whether the pages exist because a real visitor will read them or because more indexed URLs felt like progress.
When It’s Actually Worth It
Run the numbers before committing to any of the above. In your analytics, filter by country and look at two things: how much traffic is coming from non-English-dominant markets, and how that traffic’s conversion rate compares to your English-language baseline. A gap between the two — real traffic that converts noticeably worse than the rest of the site — is the actual signal, far more reliable than a general sense that “we should probably go international.”
- Worth it: a specific market already sends meaningful, sustained traffic (a rough floor of 5% of total sessions is a reasonable starting bar) and converts worse than your average, suggesting language is the friction rather than product fit.
- Worth watching, not yet acting on: traffic from a market is growing but still small and inconsistent — note it, revisit the numbers quarterly, and don’t build infrastructure for a trend that hasn’t held yet.
- Not worth it: your audience is genuinely local and effectively single-language, or the non-English traffic you do get is converting fine already — in which case localization adds real ongoing maintenance cost (every future page now needs translating, reviewing, and keeping in sync) with no corresponding upside.
Practical Tips
- Start with one language and your highest-traffic pages, not the whole site at once — a partial, well-reviewed localization beats a complete but unreviewed one on every measure that matters, including the spam-policy risk above.
- Translate image alt text, metadata, and navigation labels along with the visible body text — these get skipped by default in most setups and quietly undercut both accessibility and international search visibility.
- Test the hreflang implementation with a real tool rather than assuming the plugin got it right — Google Search Console’s International Targeting-adjacent coverage reports and a manual view-source check on both language versions will catch a missing self-reference or return tag before it costs you months of confused indexing.
- Revisit the country-level conversion data every quarter, not just once at launch — a market that didn’t justify localization six months ago can cross the threshold, and one that did justify it can stop being worth the maintenance if the traffic dries up.
Common Mistakes
- Choosing a URL structure based on which one “sounds more professional” rather than the actual authority, hosting, and budget tradeoffs Google itself lays out — a ccTLD bought for prestige with no plan to build its own authority underperforms a subdirectory that inherits the main site’s trust immediately.
- Adding translated pages with no hreflang at all, leaving Google to guess which version to serve a given searcher — the guess is not always the version you’d want it to make.
- Auto-redirecting visitors based on browser language with no visible way to switch back, which frustrates the meaningful number of people who deliberately prefer to read in a second language.
- Treating “translated” and “localized” as the same word — a page that’s grammatically correct in the new language but still quotes prices in the wrong currency, references the wrong public holidays, or uses examples that don’t map onto the local market reads as translated, not written for that audience.
Conclusion
The plugin question is the one that gets asked first, but it’s the smallest decision in the whole project. The structure you build the site on, the hreflang tags that tell Google what you’ve built, and the line you draw between what a machine translates and what a human reviews are what actually determine whether adding a language grows the site or just adds a folder of pages nobody trusts. Get the traffic data first, pick a subdirectory unless a specific reason says otherwise, wire up hreflang correctly from the first page you publish, and put a human on anything a visitor might buy something through. Once that foundation is in place, the plugin-level setup in how to add AI translation to your WordPress website is genuinely the easy part.
Etienne Basson works with website systems, SEO-driven site architecture, and technical implementation. He writes practical guides on building, structuring, and optimizing websites for long-term growth.