A client says they want their site “in Spanish too.” That one sentence hides a project three times bigger than they think it is.
Multilingual is not a translation task you bolt on at the end. It touches the theme, the URLs, the database, the SEO, and, quietly, your support inbox for years. So before you put a number on it, you need to know what you are actually signing up for. Get the scope wrong here and you eat the difference later.
That is what this post is for: scoping the build honestly, before you commit to it.
Key Takeaways
- The business case for multilingual is usually sound, so your job is scoping the build, not selling the idea.
- The build is a one-time cost. The translation is forever, and it belongs in the quote as a recurring line.
- Which markets to target is the client’s call. The technical scope that decision creates is yours.
- Half-built multilingual, where the pages are translated but checkout and support are not, is worse than none, and it lands on your support queue.
Is the multilingual business case usually solid?
Usually, yes, which means your job is to scope it, not to talk the client into or out of it. The demand is well documented. A widely cited CSA Research study of 8,709 consumers across 29 countries found that 76% of online shoppers prefer to buy in their own language, and 40% will not buy from other-language sites at all. Among buyers with no English, that preference climbs to 89%.
So the client is not wrong to want this. The wider web backs them up too, with English making up under half of all website content despite being the default most agencies build in. Your role is not to validate the “why.” It is to turn the client’s ambition into a technical scope, a realistic number, and a maintenance plan they have not thought about yet. That is where you earn your fee, and where you protect your margin.
Which markets should the build target, and is that your call?
The market is the client’s decision. The technical scope that decision creates is yours, and blurring those two is where scope creep is born. When a client says “let’s do five languages,” your next move is not “sure.” It is “which five, and can you actually support customers in all of them?”
Push them toward their own analytics before anyone picks a language. Open the site’s traffic by country and language, then find the market that arrives in volume but leaves fast. That is the evidence-based first language, and it is also your cover. When you scope to one well-supported language instead of five speculative ones, you are not under-delivering. You are stopping the client from paying to maintain four languages that never convert. Frame it that way and you look like the expert, not the bottleneck.
What is the real cost you need to put in the quote?
The build is one-time. The translation is forever, and the second part is the line most quotes forget. A developer prices the setup, ships it, then gets pulled back every month to translate new content for free because nobody scoped it. Do not be that developer.
So split the quote in two. There is the build: plugin setup, theme string translation, URL structure, hreflang, the language switcher, and testing across every language. Then there is the ongoing reality, because every new page, product, or post the client publishes needs translating too. That is a retainer, not a favor. Machine and AI translation lower the per-word cost, but someone still owns the workflow, and that someone is you unless you write it into the agreement. Some tools also bill translation by word or credit, so the client’s publishing pace drives their monthly cost directly. Say that out loud before you quote, not after.
What happens if the client only half-commits?
Then you have built something worse than a monolingual site, and it lands on your support queue, not theirs. This is the failure mode to head off in the kickoff call, not discover in month three.
Picture it. A German customer buys, then emails a question. But the checkout, the order emails, the returns policy, and the support team all still operate in English. You did not build a multilingual site. You built a beautiful front door on a house nobody can live in. A translated landing page that funnels into English-only everything does not build trust. It advertises the gap, and the client blames the build, which means they blame you.
So scope the whole journey or scope none of it. That means translated checkout, emails, and legal pages, plus a client who can actually answer a support ticket in the language you sold them. If they cannot staff that yet, translate fewer languages properly rather than more languages halfway. Fewer, complete, and maintained beats broad and broken every single time.
Scope the truth.
How do you protect the project once it is scoped?
You write the boundaries down and make the client agree to them before a line of code gets written. A clear scope document is the difference between a change request and an argument. Spell out which languages are in scope, what “translated” covers (pages, yes, but also menus, forms, emails, legal, and checkout), and what counts as new work once the build ships.
Then set expectations on the two things clients always underestimate: maintenance and SEO. Tell them upfront that translations need upkeep as the site grows, and that multilingual SEO, translated URLs, hreflang, and per-language metadata, is part of the build rather than a magic setting. A client who understands that before signing is a client who renews a retainer instead of disputing an invoice.
Frequently Asked Questions
Whose decision is it which languages to add?
The client owns the market decision, and you own the technical scope it creates. Push them to base the language choice on their own country-and-language analytics rather than a hunch. Then scope the build, the plugin, URLs, hreflang, and testing, around the languages they can realistically support with both content and customer service.
How should I price a multilingual project?
Split it into a one-time build and an ongoing retainer. The build covers plugin setup, string translation, URL structure, hreflang, and cross-language testing. The retainer covers translating everything the client publishes afterward. Quoting only the build is the most common way developers lose money on these projects.
Will making a site multilingual hurt its SEO?
No, not when it is built correctly. Search engines use hreflang tags to understand which version serves which audience, so properly tagged translations avoid duplicate-content problems. The risk is translations without their own indexable URLs and correct hreflang, which is an implementation detail you control, not a reason to avoid the project.
Do I need a specific plugin to do this properly?
It depends on the build. A simple brochure site and an ACF-heavy WooCommerce store have very different needs, and the wrong plugin creates a maintenance headache across every client site you manage. Match the plugin to the project’s complexity, budget, and how hands-on the client wants to be.
Leave a Reply