Multilingual Local SEO in a Diverse Catchment

If you run a business in a place like Southall, you already know that a single-language website is describing your customers imperfectly. What is much less obvious is what to do about it. The default answer — bolt a translation widget onto the site and move on — is usually worse than doing nothing.

This is a practical guide to the decision, written for businesses serving catchments where many households speak more than one language at home.

Start with what your customers actually do, not what you assume

The most common mistake is inferring language behaviour from demographics. It does not work that way.

A very large share of bilingual customers search in English. English is the language their phone keyboard is set to, the language technical and commercial vocabulary lives in, and the language that returns the most results. Someone perfectly fluent in Punjabi, Urdu, Somali, Polish or Tamil will still type “solicitor near me” rather than the equivalent in their first language, because that is what returns useful results.

But search language and trust language are different things. The same person may search in English, land on your page, and then look for a signal that you will understand them — a note that your staff speak a particular language, a name they recognise, a review written in that language, a photograph of a person rather than a stock image. That signal is often what decides between you and the identical business two doors down.

So the useful framing is: compete for English searches, convert on multilingual trust. That single sentence saves most businesses from building the wrong thing.

There are exceptions, and they are worth checking rather than guessing. Older customers, recent arrivals, and certain categories — immigration advice, money transfer, some health and legal services, community and religious services — do generate real search volume in other languages. You can check your own situation in Search Console: look at the actual queries bringing people to your site, and look at whether any non-English queries appear at all. That is evidence. Assumption is not.

Why machine-translating the whole site usually backfires

Automatic translation of an entire website is cheap, fast and tempting. Here is what tends to happen.

The commercial language goes wrong first. General prose survives machine translation reasonably well. Service names, legal terms, pricing conditions and calls to action do not. The sentence that determines whether someone trusts you is exactly the sentence most likely to come out slightly odd — and “slightly odd” is worse than English, because it signals carelessness rather than effort.

Nobody proofreads it. A translated site is a second site. If you do not have someone who can read it, errors sit there permanently, including ones that change meaning.

It creates pages nobody asked for. Automatically generating a version of every page in five languages produces a large volume of unread, unmaintained content. Search engines are increasingly unimpressed by bulk low-value pages regardless of language.

Widgets that translate on the fly are usually invisible to search. If the translation happens in the browser after the page loads, there is often nothing for a search engine to index. You have added complexity and gained no visibility.

Machine translation is a reasonable first draft for a human who speaks the language. On its own, for public-facing commercial pages, it is not.

When separate language pages are actually worth it

Build a translated page when all three of these are true:

1. There is real demand — you have evidence of searches, or a large share of your enquiries come through in that language.
2. The page does commercial work — a service page, a pricing page, a contact page. Not your blog.
3. Someone who genuinely speaks the language will write or check it, and will still be around in a year to maintain it.

If those hold, do it properly. Give the translated content its own URL — a subfolder such as /pa/ or /ur/ is the simplest approach for most small sites. Set the page’s lang attribute correctly. Translate the page title and meta description too, not just the body. Keep navigation consistent so someone can move between languages without getting stranded.

If those three conditions do not hold, a much better investment is one well-written English page that explicitly says which languages you speak, and who to ask for. That is a content decision more than a technical one.

hreflang, briefly and honestly

hreflang is the tag that tells search engines “this page has an equivalent version in another language or region, show the right one to the right person”. It goes in the page head, or in your sitemap, and it must be reciprocal — if the English page points at the Punjabi page, the Punjabi page must point back.

Two honest caveats.

First, hreflang solves a specific problem: multiple versions of the same content competing with each other. If you have one English site and one genuinely translated section, it is worth implementing correctly. If you have three translated pages, the benefit is modest.

Second, it is easy to get wrong, and wrong implementations are common — mismatched language codes, missing return tags, tags pointing at redirects. A partially correct implementation is not half-useful; it is usually ignored. This is a job for whoever handles your website development, with the output checked in Search Console’s international targeting reporting rather than assumed to work.

What hreflang is not: a ranking boost, and not a substitute for the content being good.

The trust signals that do the actual work

Assume the search happened in English and the visitor is now deciding. What moves them?

• A plain statement of which languages you speak, placed where it is visible, not buried in an about page. “We speak Punjabi, Hindi and Urdu” is more persuasive than a flag icon.
• Named people. A team member’s name often communicates more than a paragraph of copy.
• Reviews in other languages, left untranslated. These are strong signals and they are self-verifying. Do not hide them.
• Google Business Profile completeness. Profile attributes, service descriptions and posts are frequently the first thing seen. Reviews in multiple languages sitting on the profile do real work.
• Answering the question about process. Customers who have dealt with institutions in a second language often want to know how the interaction will go, not just what it costs.

Handle spelling variants sensibly

Names transliterated from other scripts have multiple accepted English spellings, and customers will type all of them. The same is true of place names, dish names, service names and surnames.

You do not solve this by creating a page for every spelling. You solve it by using the most common spelling naturally in your main copy, mentioning genuine alternatives once where it reads normally, and letting search engines handle the rest — they are reasonably good at this now. Resist the urge to stuff variants; it reads badly to humans and buys very little.

A sensible order of work

If you are starting from a single-language site, do it in this sequence.

Look at your actual query data first. Then make your English pages explicitly welcoming — languages spoken, named staff, real photographs, reviews left as they were written. Then complete your Google Business Profile properly. Only then, if the evidence supports it, translate a small number of commercial pages with a human who speaks the language.

That order costs less, fails more safely, and gets you most of the benefit before you spend anything on translation at all.

If you want help working out which of these steps your site needs, tell us about your business and we will give you a straight answer.