Website localisation for multilingual sites: more than translation
Adding an English version to your website does not automatically add international customers. In most cases the problem is not the quality of the sentences. It is that the content was never localised and the language versions were never declared correctly.
Quick summary: Localisation adapts the whole experience for readers in the target market, not just the meaning of the sentences. Technically, every language version needs reciprocal hreflang declarations written with absolute URLs, ISO 639-1 language codes plus optional ISO 3166-1 alpha-2 region codes, and one x-default line. Editorially, you need a locked brand glossary before anyone starts writing. Machine translation belongs in the first draft, not in an unreviewed site wide publish.
How is website localisation different from translation?
Translation carries meaning from one language into another. Localisation goes further: it adapts the entire experience for readers in the target market, including tone of address, worked examples, currency, date format, payment methods, and most importantly the keywords those readers actually type into a search box. A grammatically perfect translation can still fail if your service is named in a way nobody in that market uses.
An easy example: the Vietnamese page says "from 5 million VND, pay with VietQR". A literal English version leaves the reader converting currency in their head and guessing whether they can pay at all. Date formats are another familiar trap: the string 07/08/2026 reads as 7 August to a Vietnamese reader and as 8 July to an American one. On a promotion page or an event calendar, that gap is enough to lose an order.
How do you implement hreflang correctly?
Hreflang is how you tell search engines that two URLs are the same content in two languages or two regions, so the right version is served to the right person. The founding rule: every page must list all versions, including itself (the self-reference), using absolute URLs. And the declarations must be reciprocal. If the Vietnamese page points to the English page but the English page does not point back, that pair is ignored and the whole effort is wasted.
The value in the attribute is a language code from ISO 639-1 (two letters, for example vi, en, ja), optionally followed by a region code from ISO 3166-1 alpha-2 (for example en-GB, en-US, vi-VN). Only add a region code when you genuinely have different content per region. There is also one special value, x-default, for the fallback page shown when no version matches the user's language or region.
Diagram: both pages declare each other and both declare the same x-default. This is the pattern running between the Vietnamese pages and the English version of the Chạm AI site.
There are three valid places to put the declarations. Pick one and stay consistent:
- In the
<head>withlink rel="alternate"tags. The most common choice for small and mid sized sites. - In an HTTP header using the
Linkfield. Required for non HTML files such as PDFs. - In the XML sitemap using
xhtml:linkelements. Sensible when the site has many languages and you do not want to bloat every page head.
Example of the block placed in the head of the Vietnamese page:
<link rel="alternate" hreflang="vi" href="https://example.com/trang" /> <link rel="alternate" hreflang="en" href="https://example.com/en/page" /> <link rel="alternate" hreflang="x-default" href="https://example.com/trang" />
The English page must carry the same three lines, pointing at the same set of URLs. On this website, every bilingual article declares all 3 lines on both sides.
The most common hreflang mistakes
| Mistake | Why it breaks |
|---|---|
| Missing self-reference | The page never declares itself, so the language cluster is incomplete and easy to discard. |
| One way declarations | Page A points at B but B never points back, so the pair is treated as unconfirmed and ignored. |
| Relative URLs | The href value must be an absolute URL with protocol and domain. Relative paths are not accepted. |
| Pointing at a redirect or a 404 | The target URL has to return 200 and declare back. If it redirects or is dead, the cluster breaks. |
| Wrong language or region code | Writing en-UK instead of en-GB is extremely common. UK is not a valid ISO 3166-1 alpha-2 code. |
| Codes in the wrong order | Language first, region second. vi-VN is correct, VN-vi is not. |
| Conflicting canonical tags | An English page whose canonical points at the Vietnamese version cancels hreflang out. Each version must canonicalise to itself. |
See Google's official documentation on localised versions of a page. All of the errors above are ignored silently, with no warning, so you have to test for them on a schedule.
A brand glossary: the step before anyone translates
Before anyone touches a sentence, lock a terminology table: brand name, product names, package names, domain specific terms, and the words that must stay untranslated. The table should have 4 columns: source term, approved translation, context note, and banned variants.
Without it, the same concept shows up under three or four different names depending on who translated it or which run of the tool produced it. For AI systems now reading and summarising the web, inconsistent naming dilutes the brand recognition signal, which the article on what GEO is and how to get cited by ChatGPT treats as a core identity asset. Keeping the brand name unchanged in every language is the safest rule of all.
- Lock the brand glossary and mark which terms stay untranslated.
- Run separate keyword research for the target market instead of translating Vietnamese keywords.
- Declare hreflang reciprocally, with a self-reference, an x-default line, and absolute URLs.
- Make every version canonicalise to itself, never across languages.
- Adapt currency, date format, phone numbers, examples and images to the market.
- Verify that every target URL returns 200 rather than a redirect.
- Have a native speaker review at least the sales, pricing and legal pages.
The trap of letting machine translation run site wide
Machine translation is now good enough to build a fast first draft, but letting it publish in bulk with nobody reading the output carries more risk than benefit. The 4 problems that show up most often:
- Terminology drift. Without a glossary attached, each run can produce a different name for the same product.
- Wrong nuance in the most expensive places. Pricing, terms, warranties and legal commitments are where one skewed word creates a real dispute.
- Thin content at scale. Bulk machine output creates hundreds of low quality pages at once, exactly the kind of low value automated content that gets devalued.
- Keywords that miss reality. A faithful translation does not guarantee you match the phrases local readers actually type, so each market needs its own keyword research.
The balanced approach: use machines for the draft, wire the glossary into the workflow, then triage pages by importance. Sales pages, pricing pages and legal pages require a native editor; secondary pages can accept a lightly reviewed machine version. If you need a bilingual workflow that runs consistently, see the content and website services from Chạm AI.
FAQ - Frequently asked questions
How is website localisation different from translation?
Translation carries the meaning of the words. Localisation adapts the whole experience for the target market: tone of address, examples, currency, date format, payment methods and the keywords local readers actually type. A grammatically perfect translation still fails when the examples and product names feel foreign.
How do you implement hreflang correctly?
Every page lists all versions, including itself, using absolute URLs. The declarations must be reciprocal, because a missing return direction means the pair is ignored. Use ISO 639-1 language codes and ISO 3166-1 alpha-2 region codes, and add one x-default line for the fallback page.
Should machine translation run across the whole website?
Do not publish automatically with nobody reviewing. The risks are brand terminology drifting page by page, wrong nuance in pricing and legal copy, and thin content produced at scale. Use machines for drafts, lock a glossary into the workflow, then have a native speaker edit the pages that matter most.