How to plan a multilingual site without doubling cost
Decide which pages genuinely need a second language, how to structure them, and which hidden costs make a full translation the wrong call.
Why the second language usually gets priced wrong
You sell across two or three states. Your buyers search in Hindi or Tamil or Marathi and someone on the team suggests a multilingual site. The instinct is to duplicate everything. Every page gets a twin. Every blog post gets a twin. The quote comes back at close to double the original build and the project stalls there for a year.
The quote is honest and the plan is wrong. A second language is not a second website. It is a second set of words on the same structure. Almost all of the cost sits in deciding how much to translate and who maintains it afterwards rather than in the translation itself.
What it costs and what the translation leaves out
Exclusions first. A translation budget does not cover your offer. If the pricing or the package differs by region that is a product decision and it has to be made before anyone translates a word. It does not cover enquiry handling. A form filled in Tamil arrives with a Tamil-speaking buyer attached and somebody has to answer them. It does not cover your email templates your WhatsApp replies or your PDFs. Those sit outside the website and are usually forgotten.
The real cost lines are a translator plus a separate native reviewer who is not the translator, developer time to wire language routing and a switcher, font and rendering checks for Devanagari or Tamil script where line heights and character widths break English layouts, and ongoing editorial time. Service fees in India carry GST at 18%. Machine translation lowers the first line and raises the second because every sentence then needs reading by someone who would have written it differently.
Who should add a language and who should not
Do not do this if nobody in your organisation reads the second language. You will be unable to review the copy. You will be unable to answer the enquiries it produces. You will be publishing claims about your own business that you cannot check. That is a worse position than having no translation at all.
Do not do this if you sell to procurement and technical heads at larger companies who conduct their working life in English. The translated pages will be read by nobody who buys. Spend the money on proof and case documentation instead.
It is worth doing when you sell a consumer or small-business service in non-metro markets, when your field team already pitches in that language, and when you can name the specific searches your buyers type. Local service categories where the buyer compares three providers on a phone are the clearest case.
How to do it without doubling anything
Translate a subset and say so openly on the site. Five to eight pages usually carry the entire buying decision. The home page the service pages the pricing page the contact page and one proof page. Leave the blog in English. A partial translation that is complete where it matters beats a full translation that is thin everywhere.
Keep one design and one codebase. Only the strings change. Put the second language in a subdirectory rather than a separate domain so both versions share one technical foundation. Add hreflang markup so search engines understand the pages are alternates and not duplicates. Make the language switcher land the visitor on the matching page rather than dumping them back at the home page.
Then assign an owner per language with the authority to approve copy. Write down what happens when an English page changes. Without that rule the second language drifts out of date within two quarters and starts contradicting the first.
Judging whether the second language earns its keep
The metric that matters is enquiries that originate on the translated pages and the proportion of those your team can actually serve in that language. Track the second number honestly. A language version that generates calls nobody can take is a cost with a complaint attached.
The metric that flatters is pageviews on the translated section and the count of languages supported. Both rise the moment you publish. Neither tells you whether a buyer understood your offer.
The mistake that undoes the whole exercise
The common mistake is translating the pages and leaving everything after the click in English. The buyer reads a confident Hindi service page then meets an English form with English field labels then an English confirmation email then a sales call in English. The site made a promise about how this relationship would work and the first three interactions broke it.
It is expensive because it destroys exactly the trust the translation was bought to build. The cheaper and safer sequence is the reverse. Make the form the autoresponder and the first call work in the language. Then translate the pages that feed them.
The maintenance debt nobody prices
Every language you add multiplies editorial work for as long as the site exists. A price change becomes two edits. A new service becomes two pages and two sets of internal links. This is the cost that kills multilingual projects and it never appears in the build quote. Decide who carries it before you commission anything. If no name can be put against that work the honest answer is to stay in one language and do it well.
This guide explains how something works. It is not legal, tax or financial advice, and rules change. Confirm anything regulatory with a qualified professional before you act on it.