The client approved the multilingual build. Now it is on you to make sure it does not bite you in month three.
Most of the pain in these projects does not come from the translation itself. It comes from decisions nobody made on purpose: the wrong URL structure, a plugin that fights the page builder, SEO bolted on at the end. Those are the choices that turn a clean build into a maintenance headache across every client site you run.
Here are the six things to lock down before you write a line of code.
Key Takeaways
- Let the client’s analytics choose the target languages, not their gut and not yours.
- URL structure is a decision you make once and live with, so make it deliberately.
- Whether translations live in your database or on a vendor’s servers is an architecture choice with real trade-offs.
- Someone owns translation after launch. Decide who, and price it, before you ship.
- Multilingual SEO, hreflang, translated URLs, and per-language metadata, is part of the build, not a setting you flip at the end.
1. Which languages should the build actually support?
The ones the client’s own traffic already justifies, not the ones that sound impressive in a kickoff meeting. A client will ask for five languages because five feels ambitious. Your job is to turn that instinct into evidence before it turns into scope you cannot maintain.
Open the site’s analytics and segment by country and language. The demand is usually already visible in the numbers. A Weglot study of 30,000 of its own clients’ sites found that, on average, 35% of their traffic came from non-primary languages, and WPML, analyzing its own site , reported that 92% of its traffic comes from outside the US. Different tools, same lesson: the audience is already multilingual, whether or not the site is. So the market that arrives in real volume but bounces fast is your first, best candidate, because the demand is already there and the language barrier is what is costing the conversion. Start with the one or two languages the data supports, ship them properly, and add more once they prove their return.
2. What URL structure should you commit to?
Your options are subdirectories (site.com/es/), subdomains (es.site.com), or separate country domains (site.es). Pick one of three, and understand you are mostly stuck with it once the site is indexed. This is the decision developers rush and regret, because changing it later means redirects, re-indexing, and a nervous conversation about lost rankings.
Subdirectories are the usual right answer, because they inherit the main domain’s authority and are the simplest to run. Subdomains and separate domains make sense when the client genuinely operates as distinct regional businesses, with different teams, content, or legal entities, but they split your SEO authority and multiply the maintenance. Whichever you choose, make sure the plugin you pick actually supports it cleanly, because retrofitting a URL structure onto a live multilingual site is exactly the kind of afternoon you do not want to bill for.
3. Where should the translations live?
Either in the client’s own database or on a translation vendor’s servers, and the difference matters more than it looks. This is the architecture call that quietly decides how portable, how fast, and how permanent the multilingual site is.
Self-hosted plugins keep every translation inside the WordPress database, so the client owns the content outright and it survives whether or not a subscription keeps getting paid. Cloud or proxy tools host the translations for you, which means faster setup and less to run, but the translations live on the vendor’s side and stop serving if the client stops paying. Most of these tools let you export your translations before you cancel, so the content is not necessarily lost, but it stops appearing live unless someone re-implements it. Neither is wrong. A lean brochure site that wants the fastest possible launch is a different animal from a client who needs to own every asset for the long haul. Just make the choice on purpose, and make sure the client understands which one they are buying, because “why did the Spanish version disappear when we cancelled that tool” is not a fun email to answer. We go deeper on matching the plugin to the project in the next post in this series.
4. Who translates the content, and who owns it after launch?
A human, a machine, or both, and the honest answer for most sites is both. What matters more than the method is deciding, before launch, who is responsible for translation once the site is live and the client starts publishing again.
Machine and AI translation have gotten good enough to carry the bulk of the work, especially for high-volume, low-stakes content. But the pages that carry money or brand, product descriptions, legal text, the checkout, still need a human pass, because a machine-translated refund policy is a liability, not a saving. The trap is treating translation as a one-time launch task. The client will add pages, and every one of them needs translating, so decide now whether that is your retainer, their in-house job, or a translation service, and put it in writing. If you skip this, the work defaults to you, for free, forever.
5. What does “localized” actually require beyond translation?
More than swapped-out words. Localization is where a multilingual site either feels native or feels like a machine ran over it, and it is the part clients forget to budget for.
Currency and date formats need to match the market. Right-to-left languages like Arabic and Hebrew need layouts that actually flip, which can break a theme that was never tested for it. Non-Latin scripts like Chinese and Japanese carry their own font and spacing quirks, and some translation tools price them by character rather than word, which changes the cost math. Even regional variants of the same language matter, because the German a Swiss customer expects is not identical to the German a Berliner does. None of this is exotic, but all of it is real work that belongs in the scope, not in a surprised Slack message the week before launch.
6. How do you get multilingual SEO right the first time?
You build it in from the start, because retrofitting it is slow, painful, and visible in the rankings. Multilingual SEO is not a switch you flip at the end. It is a set of decisions baked into how the site is structured.
Get the fundamentals in place: hreflang tags so search engines serve the right language version and duplicate content is not a problem, translated URL slugs so the whole page reads native, and translated metadata and alt text rather than English strings sitting under a Spanish page. One thing worth knowing in 2026: translation setups that render only in the browser, via JavaScript after the page loads, are often invisible to search engines, which means the “translated” site never gets indexed and the traffic never comes. Server-side, indexable translations are what both Google and AI answer engines can actually read. If a client is paying for reach, that reach depends on getting this layer right.
The thing that ties all six together
Every one of these is a decision that is cheap to make before the build and expensive to fix after it. That is the whole point of planning a multilingual site rather than diving into it. You are not just choosing a plugin and translating some pages. You are committing a client to a structure, a cost, and a maintenance rhythm that you will be living with for as long as you manage the site.
Plan it properly and the build is boring, which is exactly what you want. If you are still weighing whether the project is worth quoting in the first place, we covered that in scoping a multilingual WordPress build .
Plan first.
Frequently Asked Questions
How do I choose which languages to translate a site into?
Use the client’s own analytics rather than a guess. Segment traffic by country and language and look for a market arriving in volume but converting poorly, which usually signals a language barrier. Start with the one or two languages the data supports, ship them properly, and add more once they prove their return.
Which URL structure is best for a multilingual site?
Subdirectories like site.com/es/ are the usual best choice, because they inherit the main domain’s authority and are simplest to maintain. Subdomains or separate country domains suit clients operating as genuinely distinct regional businesses, but they split SEO authority and add maintenance. Decide early, because changing it after indexing is costly.
Can I just machine-translate the whole site?
For low-stakes, high-volume content, machine and AI translation are usually fine. For conversion-critical and legal pages, they need a human review, because an inaccurate checkout or refund policy is a real liability. Most builds land on a hybrid, and the key is deciding who owns ongoing translation before you launch.
Will translated pages cause duplicate-content problems?
No, as long as each language version has its own indexable URL and correct hreflang tags. Hreflang tells search engines which version to serve to which audience, while self-referential canonical tags handle actual duplication; together they keep language versions from competing with each other. The real risk is a setup that renders translations only in the browser, which search engines often cannot index at all.
Leave a Reply