Multilingual Website: Do You Need One, and How?
7 min read
"We'd like to add an English version, roughly what does that cost?" By the time this question reaches me the decision is usually already made and the caller is comparing quotes. But the real cost of a second language is not the build. It is that every future edit becomes two edits. The rate card changes, a service gets dropped, the address moves, the first language gets updated and the second one stays where it was. Six months later you have a page you would rather nobody read. This piece covers whether to do it at all, what each of the three approaches actually costs you, how search engines work out that two URLs are one document in two languages, and the mistakes I have made myself.
1. Decide whether to do it at all
Most small companies do not need a second language. That is a poor thing for someone who builds websites to say, but it saves everyone time. A language is not a feature you add. It is an asset you maintain, and the maintenance cost has nothing to do with how many foreign customers you have. It scales with how often you change the site.
The useful question is not whether it is possible but whether it is already happening. Does English arrive in your inbox? Has anyone on your team sat in a meeting pointing at a page the other side could not read? Does the product actually ship abroad? Three noes mean a second language solves a problem you do not yet have.
There are situations where it pays off immediately. Taking remote work from overseas clients, selling through cross-border marketplaces, applying for foreign certification or exhibiting at a trade fair, dealing with the local branch of a multinational. In those cases the second language is not decoration. It is the thing the other party has to read.
There is a middle option that rarely gets mentioned: do one page. A single page of company background in the second language, saying what you do, which regions you serve and how to reach you, living at a fixed URL. It costs almost nothing to keep current, and in most of the situations above it covers nine tenths of the need. Once you see traffic to that page arriving from a particular country, revisit the question of a full site.
2. Three approaches, three costs
Once you have decided, there are only three routes in practice. What separates them is not difficulty. It is where the job of keeping both sides in agreement ends up sitting.
| Approach | What you get | What it costs you |
|---|---|---|
| Browser or plugin auto-translation | Free, and a visitor gets the second language with one click | No separate URL, so search engines never receive the translated content. It serves only people who already found you |
| A translation plugin (WPML, Polylang and similar) | Each language gets its own URL that search engines can read, and both share one layout | Every content change means going through the admin twice, and the plugin itself needs updating and usually paying for |
| Two separate sites | Content, layout and structure can differ completely and be tuned per market | The easiest to let drift. The common ending is one of the two frozen two years ago |
The first is often mistaken for having done the work. The text produced by a translate button exists only in that one visitor's browser. The URL did not change and the server still sent the original language. What search engines fetch is always the original, so in results for the second language the site effectively does not exist. It solves a reading problem for people who already arrived. It does not help anyone arrive.
The second is the sensible choice for most small companies. The thing to get right is not running two of them at once. Two translation plugins active together emit conflicting language markup, and that is a problem you cannot see on the page.
The third suits the case where the two markets genuinely buy differently, a catalogue at home and a spec sheet abroad. The cost is that nothing reminds you to change both, so it depends on process, and process is the thing that breaks first in a small company.
3. How a search engine knows the two pages are one document
Once each language has its own URL, a new question appears. To a search engine, are these two different pages or two versions of one document? Read as two different pages, they compete with each other for the same queries. Read as duplicates, one of them may not be indexed at all.
The mechanism that settles it is hreflang, which is easiest to think of as a language-pairing tag. It sits in the source of each page and says: this page is the first language, and the same content in the second language lives at this URL. Google's documentation on localized versions is explicit that the point is to serve the right language version to the right user, not to improve ranking.
Two details get missed most often. First, the pairing has to run both ways. Each page points at the other, and each also points at itself. A one-way claim is not trusted, because any site could declare itself the translation of someone else's. Second, you need to nominate a default version for visitors whose language is not on your list, so a reader arriving with a German browser lands somewhere deliberate.
- 01
Open the first page and view source
Right-click, view page source, search for hreflang. You should find at least three lines: one pointing at this page, one at the translated page, one at the default version.
- 02
Do the same on the translated page
You should find a symmetrical set, and the URL pointing back has to match the page you just looked at exactly, trailing slash included.
- 03
Check the language declaration
At the top of the same source, the html tag carries the page's language. Each version must declare its own. This one is missed constantly because it changes nothing visible.
Those three steps need no tools and take five minutes. If the site was built for you, they are also the five best-spent minutes of accepting the work.
4. The four most common mistakes
I have run into all four of these, and one of them was on my own site.
Check each one before the second language goes live
- Whole pages of machine translation published as content. Google's spam policies list unreviewed automated translation among the things it acts on. Machine translation as a draft is fine, but somebody has to read it, particularly service names, currency units and anything touching the law.
- A language switch that does not change the URL. Remembering a language preference in a cookie, with the address staying the same, means search engines only ever receive the default. Each language needs a URL that can be linked and sent to somebody else.
- Half the site translated, with the whole site claiming pairs. Translation plugins often emit language pairing across everything by default when only ten pages are actually done. Pairings that point at pages which do not exist get ignored, and worse, you lose track of which pages have a counterpart.
- A translated page declaring the original language. This one happened on my own site. The service pages in the second language inherited a hard-coded language declaration and the original company name from the template, so every one of them told search engines it was in the wrong language. Nothing looked wrong. You had to read the source to see it.
The fourth deserves another sentence. What these mistakes have in common is that nothing breaks, so nobody reports them and they appear in no performance report. They simply make your site say something untrue to a search engine, quietly, for months. There is one way to find them, which is to read your own output periodically.
5. Not every page has to be translated
People tend to think of a second language as all or nothing, then stall on "there are too many articles to translate" and never start. Partial coverage is a perfectly normal state as long as it is handled cleanly.
Clean means this: pages that have a counterpart emit the language pairing, and pages that do not, do not. For a page with no translation, the correct signal is to take part in no pairing at all, rather than pointing at a URL that does not exist. Most translation plugins can be configured this way, though it is usually not the default.
The order of what to translate is clear too. Services and contact details first, because those are what the reader needs in order to decide. Then the handful of pieces that show you can do the work. Legal documents such as a privacy policy and terms of service are often better left untranslated, because they cite the law of one jurisdiction and a translation invites the reader to assume it covers theirs.
6. The second language should not carry the first one's weight
The last item is more technical, but it affects real load time and nearly every bilingual site has it. A Chinese or Japanese font file is large, because it has to carry thousands of characters. Pages in the other language contain none of them and still download the whole file. The reason is that the font list in the stylesheet is shared site-wide, so the browser sees the large font first in the list and fetches it.
I measured this on my own site. An English article page was transferring close to 390 KB, and almost half of that was the Chinese font file. Specifying the font by language brought it to around 200 KB with no visible difference at all, because there was no Chinese on the page to render in the first place.
A speed report will not flag this as a language configuration problem. It will only show a large font file. So if your site has a second language and those pages feel inexplicably slow, this is the first place to look. The check is to open the browser's developer tools, watch the network requests, and see whether a page in one language is downloading the font for the other.
Whether a second language succeeds has little to do with translation quality and everything to do with whether it still says the same thing as the original six months later. So before committing, settle who keeps them in sync and how often it gets checked. If those two questions have no answer, one page of company background is far more practical than a full site that will go stale.
Common questions
- Can I just use Google Translate for the second language?
- As a reading aid for a visitor, yes. As the site's content, no. Browser translation happens only on that visitor's screen, the URL does not change, and what the search engine fetches is still the original, so in results for the other language you have nothing. If you save machine output as real pages, Google's spam policies list unreviewed automated translation among the things it acts on. The workable approach is machine translation as a draft with a person reading it afterwards, especially service names, currency units and anything touching the law.
- WPML or Polylang?
- For a small site in two languages, the free version of Polylang is usually enough, and treating each language as its own post keeps the model simple. If you need to translate shop products, forms or a lot of plugin interface text, WPML covers more ground, at the cost of an annual fee and heavier configuration. The thing that actually matters is not running both, because two translation plugins active together emit conflicting language markup and nothing about that is visible on the page.
- Is it a problem to translate only the home page and services, not the articles?
- No, partial coverage is normal. The one thing to get right is that only pages with a counterpart emit the language pairing, otherwise you are pointing at URLs that do not exist. Also filter the related-reading block on translated pages down to pages that have a counterpart, or readers get sent into the untranslated side of the site and leave.