Left column is English. Right column is what the market actually reads.
Multilingual SEO Services That Localise Intent, Not Sentences
A translated page keeps your argument. A localised page replaces it with the argument that market already believes. We build the second kind: query research per locale, native copy, hreflang done once and correctly, and landing pages that answer the objection a buyer in that country actually has.
Most international sites fail not because the translation is bad, but because the decision path underneath it is still the English one. This page shows how we rebuild that path, market by market.
Each row is a decision point, not a word. The left column is what we wrote in English; the right column is the equivalent a buyer in that market expects to see before they trust the page.
The core mistake
Translation moves words. Localisation moves the decision.
A buyer in one country researches a category for six weeks and reads technical forums before contacting anyone. A buyer in another wants a phone number within two clicks and treats a form as a delay tactic. If both see the same page with the same call to action, one of them is being served badly, and it is usually not the market the site was designed in.
Search behaviour differs in ways that translation cannot fix. The query might be a single compound concept where English uses three words. The buying unit might expect a minimum order quantity stated on the page. The credibility signal might be a certification body that only exists locally. None of that survives a sentence-by-sentence swap.
So we start from the query set in each market rather than from the English page. What do buyers search before they know your brand? Which pages already rank, and what do they promise? Where does the intent split between research, comparison and procurement? That research produces a page brief per locale, and the English page becomes a source of facts rather than a template to duplicate.
What changes per market
- Query shape — one concept or a phrase, singular or plural, technical or trade vocabulary.
- Proof — local case studies, local delivery times, recognised certifications.
- Commercial frame — currency, duties, payment terms, MOQ, warranty length.
- Contact channel — form, phone, messaging app, or a distributor referral.
- Formality — how the brand addresses a procurement manager versus an engineer.
Notice that none of these are translation problems. They are research problems that happen to be expressed in another language.
Architecture
Language is not a country, and the URL has to admit it
Two pages can share a language and serve completely different markets. Treating language as a proxy for country is the root cause of most international SEO mess: pages that compete with each other, canonical tags pointing across locales, and a search console full of impressions from the wrong continent.
We separate the two dimensions before writing a single URL. Language targets the query. Country targets the commercial terms, the proof and the delivery promise. Sometimes one page serves both, sometimes you need four pages for two languages. The decision is commercial, and it is made with the sales team, not with a plugin.
If your structure spans several regions with different commercial rules, the architecture work overlaps heavily with International SEO Services, and we usually run both workstreams from one map so the hreflang cluster and the commercial structure cannot drift apart.
| Source (English) | Local expression (placeholder) | Why it changes |
|---|---|---|
| Request a quote | [local quote-request verb] | Some markets expect a callback promise, not a form confirmation. |
| Free shipping | [local delivery term] | Duties and thresholds make the English claim misleading. |
| Industrial supplier | [local trade category] | The trade category carries different qualification expectations. |
| Certified quality | [local certification name] | Certificate wording is regulated in several markets. |
| Talk to sales | [local contact phrase] | Formality level signals company size and seniority. |
The right column is deliberately a placeholder. A real localisation fills it only after the query research and a native review, never from a dictionary.
Technical
Three ways to implement hreflang, and one way to break it
Hreflang tells a search engine which URL to serve to which language and region. It is a hint, not a directive, and it only works when the cluster is complete in both directions.
1. HTML link elements in the head
The default for normal pages. Every page in the cluster lists every other page, including itself, with the correct language and optional region code. The cluster must be identical on every URL: if one page lists four alternates and another lists three, the set is inconsistent and may be discarded.
2. HTTP Link headers
Necessary when the resource is not HTML: PDF catalogues, technical drawings, downloadable spec sheets. The same annotations travel in the response header. Teams forget this constantly, then wonder why a translated brochure ranks instead of the landing page.
3. XML sitemap annotations
The practical option for large catalogues where editing thousands of templates is slow. Each URL entry carries its alternates. This scales well, but it drifts the moment a new locale is added and the sitemap generator is not updated in the same release.
The failure mode that costs the most
One-directional annotations. Page A lists page B as its alternate; page B does not list page A back. The pair is invalid, and often the whole cluster is ignored. This happens whenever a new market is added by copying a template and editing one file. A crawl of the full cluster, twice a quarter, is cheaper than the traffic you lose while nobody notices.
Close behind: missing self-reference, an invalid region code, alternates pointing at redirects, noindex pages inside a cluster, and canonical tags that point every locale at the English original. That last one is fatal and surprisingly common after a rushed template migration.
People and terms
Native writers, one glossary, one reviewer per language
Localisation quality collapses without terminology control. The same component gets three different names across four pages, internal links contradict the navigation, and a buyer who compares two product pages concludes the company is disorganised. The fix is unglamorous: a glossary, a style guide and a single reviewer with the authority to reject copy.
One preferred term per concept, per language, with forbidden variants listed next to it. Writers work from this file, not from memory.
Brand names, product codes, certification marks and legal entity names stay untouched. Translating a product name is the fastest way to break search demand for it.
One native reviewer per language signs every page. Committees produce inconsistency; a single accountable editor produces a voice.
Machine translation has a legitimate role as a first draft for internal review. Published as-is, it fails in predictable ways: technical specifications shift meaning, certifications appear that the company does not hold, formality lands at the wrong level, and the resulting pages are near-duplicates of each other. At scale, that last problem is the expensive one, because dozens of thin locale pages can consume crawl budget and dilute the cluster they were meant to strengthen.
We use subject-matter interviews to anchor terminology. An engineer explains the difference between two similar components once, the glossary records it, and every future page in every market inherits the distinction. That single habit does more for international rankings than any keyword tool.
Page structure
What a localised landing page actually contains
Above the fold
A claim written for that market, not translated from the English one, plus the one proof point that market trusts: local delivery time, local certification, a named local distributor, or a case from the same industry. The primary call to action matches the local buying habit.
Middle
Specifications in local units, commercial terms in local currency with duties stated, and a comparison against the alternatives a buyer in that market would actually consider. Internal links stay inside the locale, so a reader never falls out of their language by accident.
Bottom
Local contact details, business hours in the local time zone, and a short procurement FAQ. This is where most translated pages lose the inquiry: the form is correct, but nothing on the page tells the buyer what happens after they submit it.
Signals we check before launch
- Query coverage in that locale, not in English.
- Self-referencing hreflang and valid return links.
- No cross-locale canonical.
- Local currency, units and duty language present.
- Native review signed off by a named editor.
- Contact channel matching local expectation.
- Internal links staying inside the locale.
Launch is a checklist, not a feeling. Seven items, each with an owner, takes about an hour and prevents the failure modes that take a quarter to diagnose.
Process
How a market goes from plan to page
- Market and language mapWe list every market you sell into, the language actually used for search there, and the commercial rules that differ. This document decides URL structure, and it is signed off before production.
- Local query researchA native researcher builds the query set from that market's search behaviour: buying-stage terms, trade vocabulary, comparison queries and the questions that appear in local forums.
- Brief and translation-ready sourceThe English page is reduced to facts, claims and structure. Translators receive a brief, a glossary and a do-not-translate list rather than a document to render sentence by sentence.
- Native writing and reviewA native writer produces the page, an editor signs it, and a subject-matter reviewer confirms technical accuracy. Three people, three different failure modes covered.
- Implementation and cluster checkHreflang shipped for the whole cluster at once, sitemap updated, crawl verified, internal links localised. Nothing goes live market by market without the cluster being complete.
Evidence
What changes when the market is treated as a market
An industrial exporter had four translated sites and one converting. Rebuilding the buying path per market produced first inquiries from three of the four within two quarters.
Duplicate locale pages indexed across an ecommerce catalogue fell by 52% after hreflang and canonical cleanup, with no loss of organic revenue.
A B2B supplier's non-English organic inquiries grew 2.4× in nine months after native rewrites of twelve product pages, with English traffic unchanged.
If your growth depends on distributors and export buyers rather than direct consumers, the commercial framing matters even more than the copy, which is why we usually pair this work with the playbook in SEO For Exporters.
The test of a localised page is simple: a buyer in that market should not be able to tell that the company is based somewhere else until they read the address.
Show us the market that is not working
Send one locale and the queries you expect to win. We will return a written read on the architecture, the terminology and the buying path, plus a scoped proposal for the full cluster.
Objections
Questions from international marketing teams
- Is multilingual SEO just translation with keywords added?
- No. Translation preserves meaning; localisation reproduces the decision path a buyer follows in that market. That path includes the query they type, the proof they expect, the units and certifications they recognise and the channel they prefer. A translated page that keeps an English decision path usually ranks for little and converts worse than the original.
- Do we need a separate domain for each language?
- Not necessarily. Subdirectories concentrate authority on one domain and are cheaper to maintain. Country-code domains signal local presence more strongly but split authority and add operational cost. The right answer depends on how many markets you serve and how much local trust the category demands.
- What is the most common hreflang mistake?
- Missing return links. If one page declares another as its alternate, the second must declare the first back, and both must include themselves. One-directional annotations are ignored, and the cluster is often dropped entirely. A full-cluster crawl twice a quarter catches it cheaply.
- Can machine translation be used at all?
- As an internal first draft, yes. As a published page, no. Machine output mangles specifications, invents certifications and flattens formality. It also generates near-duplicate pages that compete with each other and consume crawl budget.
- How do you keep terminology consistent across markets?
- A shared glossary with approved terms and forbidden variants, a do-not-translate list for brand and product names, and one named reviewer per language. The glossary is versioned so a terminology change can be traced to a date and an owner.
- How is performance measured across locales?
- Per locale, against a local baseline and a local competitor set. Blending five markets into one average hides the fact that one locale is carrying the rest. We report each market separately before rolling anything up.
- Can you work with our existing translation vendor?
- Yes. We supply the brief, the glossary and the acceptance criteria, they produce, and we review against search intent rather than against the source sentence. That combination is usually cheaper than replacing the vendor.