You serve customers who speak more than one language. The real question is whether your website does, and whether doing it the wrong way could quietly cost you.
A second language on your site can win trust with customers who would rather read in their own words, and it can help you show up when someone searches in that language. But it only works when it is built correctly. A translate-everything widget added onto an English site can confuse both your visitors and search engines, and sometimes it does more harm than the single-language site you started with.
So before you translate a single page, run what we call the Four-Point Language Check. Four questions. If a language version passes all four, it is doing real work for you. If it fails one, you have found exactly what to fix.
Point one: Do your customers actually want a second language?
This is the question to answer before any of the technical ones, because a second language you do not need is just more site to maintain. The signal is not whether a second language would be nice to have. It is whether real customers would rather read and contact you in it.
Imagine a physiotherapist in a neighbourhood where much of the daily business, local signage, and everyday conversation happens in Spanish. A Spanish version of the key pages may genuinely help those customers trust the practice and reach it. Now imagine a specialist supplier whose customers all do business in one language regardless of background: a second version mostly adds upkeep for little return. Same decision, opposite answers.
Ways to check your own demand honestly:
- Listen to who already contacts you. Which language do enquiries, calls, and in-person questions actually come in?
- Look at who you serve. Your neighbourhood, your suppliers, the communities and visitors around you.
- Ask whether the second language changes the decision. Would someone choose you over a competitor because they could finally read the details in their own language?
Point two: Does each language get its own page, not a translate widget?
There are two ways to put a second language on a website, and they are not equal. One gives each language its own page with its own web address. The other is a widget or browser setting that swaps the words without creating a real page underneath.
The difference matters because search engines find and list pages by their web address. A German version that lives at its own address, say yoursite.com/de/, is something a search engine can crawl, read, and potentially show to someone searching in German. A widget that rewrites the English page inside the visitor's browser often leaves nothing permanent for a search engine to index, so the translated version may be much less likely to appear in results. Machine widgets can also produce wording you never see or approve, on a page that still carries your name.
If a visitor can land directly on your second-language page from a search result and read it as its own page, you are on the right side of this one.
Point three: Are your language versions connected with hreflang?
Once you have separate pages, you have a new problem: a search engine needs to understand that your English page and your German page are the same page in two languages, not two competing pages. That is what an hreflang tag does. It is a small piece of code in the background of each page that names the language the page is written for and points to its counterparts.
Done well, hreflang can help a search engine serve the German version to German readers and the English version to English readers, instead of guessing. Left out or done wrong, the versions can end up competing with each other. You will not see hreflang on the page, it lives in the code, which is exactly why it tends to get forgotten. A correct setup usually includes:
- Every language version listing every other one, including itself, so the whole set agrees.
- Correct language codes, for example en for English and de for German, with a region added only when you really serve different regions differently.
- Links that point at live pages, not at addresses that have moved or no longer exist.
This is where a maintained site helps, because hreflang is easy to break and nobody notices until the wrong version starts turning up for the wrong reader.
Point four: Is the translation written by a human?
Automatic translation has improved, but it can still miss things that matter to a local business: the name of a service as locals actually say it, the tone you use with your customers, the difference between a phrase that is polite and one that is almost right but slightly off. A page that reads like a machine wrote it can undercut the very trust you added the language to build.
You do not need literary translation. You need:
- A fluent human to write, or at least review, every page a customer will read.
- Your real terms kept consistent, so the same service is called the same thing on every page.
- Your contact details and buttons translated too, not just the body text, so a visitor is never stopped at the step that matters most.
A fluent reader going through the page and never stumbling is the test here. If you cannot judge it yourself, have someone who speaks the language read it as a customer would.
A second language earns its place when the structure carries it
Not every local business needs a multilingual site. If your customers all speak one language comfortably, a second version is work and upkeep for little return, and you are often better off putting that effort into the pages you already have. But if you genuinely serve people in more than one language, a properly built second-language section can make them feel spoken to, and can help them find you in the first place.
The Four-Point Language Check is there so you can tell the difference between a second language that helps and one that just adds clutter: real demand, separate pages, connected with hreflang, written by a human. Pass all four and the language is doing real work. Fail one and you now know which part to fix before you translate anything else.