> ## Content Index > Fetch the complete content index at: https://www.scopecreep.co.uk/llms.txt > Use this file to discover other available public pages before exploring further. # The localisation checklist for multilingual website launches - URL: https://www.scopecreep.co.uk/the-localisation-checklist-for-multilingual-website-launches/ - Published: 2026-10-05T00:01:15.000Z - Updated: 2026-10-08T22:01:55.000Z - Description: The thing I couldn't find when I started was a straight, practical list of what actually needs deciding, in what order, written by someone who had done it rather than someone selling translation services. - Author: Jamie Wright - Tags: Project Management, Web Development A while back I wrote about [launching the same website](https://www.scopecreep.co.uk/i-launched-the-same-website-not-once-but-five-times/) five times, in five languages, and what that does to a delivery plan. That piece was the story. This one is the checklist, because the thing I couldn't find when I started was a straight, practical list of what actually needs deciding, in what order, written by someone who had done it rather than someone selling translation services. The central lesson first, because everything below depends on it: a multilingual website is not one website translated. It is one system with several locales, and the decisions that hurt are made in weeks one and two, not in the translation phase. By the time words are being translated, most of your expensive mistakes are already set. Here's the order I'd work in now. ## 1\. URL structure, decided before anything else Three options, and you're picking one for the lifetime of the site. Subdirectories (`example.com/de/`) keep all your authority on one domain, are cheapest to run, and are the right default for most builds. Subdomains (`de.example.com`) are easier for separate teams or infrastructure, but search engines treat them as more distinct, which means your ranking strength is split. Country-code domains (`example.de`) are the strongest local signal and the most expensive thing on this list: separate domains, separate authority to build, separate everything. Pick subdirectories unless you have a specific reason not to. Write the reason down if you don't, because someone will ask in eighteen months. One related decision worth making early: is the language folder in every URL, including the default? A site with `/en/` and `/de/` is more consistent than one with `/` and `/de/`, and consistency saves you redirect work later. ## 2\. hreflang, done properly or not at all This is where most multilingual launches quietly fail, because half-implemented hreflang is worse than none. The rules that matter: - Every page needs hreflang tags pointing to every language version of that same page, including itself. Self-referencing is not optional. - The relationship must be reciprocal. If the English page points at the German one, the German one must point back, or the pair gets ignored. - Use correct codes. Language is ISO 639-1, region is ISO 3166-1 alpha-2, so `en-GB`, not `en-UK`, which does not exist and which I have seen in production more than once. - Add an `x-default` for your fallback, usually the language selector or the international English version. - Point at canonical, indexable URLs only. hreflang tags pointing at redirected or noindexed pages achieve nothing. You can implement in the ``, in HTTP headers for non-HTML files, or in the XML sitemap. Sitemaps are usually the sanest option at scale, because you can generate them rather than maintaining tags across thousands of templates. ## 3\. Never auto-redirect by IP address Tempting, common, and wrong. Automatic redirection based on someone's location breaks in two directions: search engine crawlers largely crawl from the US and will simply never see your other locales, and real users travelling or using a VPN get trapped in a language they can't read, on a site that keeps sending them back. Instead: let people land where they asked to land, detect the likely locale, and offer a dismissible banner suggesting the alternative. Remember the choice in a cookie. Put a clear language selector in the header or footer, using the language's own name (Deutsch, not German) and never a flag, because flags represent countries and languages are not countries. Ask anyone in Switzerland. ## 4\. Design and content that survives translation German runs roughly a third longer than English. Finnish and Russian expand too. Chinese and Japanese contract, but bring their own line-breaking behaviour. Any layout that fits its text exactly is a layout that breaks in at least one locale. Practical guardrails: no fixed-width buttons or nav items, test with the longest language rather than English, avoid text baked into images because it's invisible to translators and to search, and if any right-to-left language is on the roadmap, use CSS logical properties (`margin-inline-start` rather than `margin-left`) from day one. Retrofitting RTL is a rebuild, not a task. Then the locale details that aren't language at all: date formats, number separators, currency and its position, address and phone formats, units, name order, and legal pages that genuinely differ by market. Cookie consent, privacy wording and required company information vary by jurisdiction, and a translated version of your UK legal page is not compliance, it's a translated UK legal page. ## 5\. The translation workflow itself Set up a glossary of your key terms and get it signed off by someone in each market before translation starts. Product names, feature names, tone. Doing this after translation means paying twice. Translate in the CMS or a connected translation tool, not in spreadsheets emailed around at the end, which is how context gets lost and how someone ends up translating a button label as if it were a sentence. Give translators screenshots or staging access so they can see where the words land. Machine translation is fine as a first pass on high-volume, low-stakes content, provided a native speaker reviews it in context. It is not fine unreviewed on anything that carries your brand or your legal position. And "native speaker" should mean someone in that market, not a colleague who studied it at university. ## 6\. Performance, per locale [The performance trap in multilingual builds](https://www.scopecreep.co.uk/score-100-on-google-pagespeed-insights/) is shipping everything to everyone. Each locale should load its own content only: separate bundles or static builds, not one giant payload containing five languages of copy. [Fonts are where this bites hardest](https://www.scopecreep.co.uk/how-many-fonts-is-too-many/). Extended Latin, Cyrillic and Greek need broader character coverage, and CJK fonts are enormous by comparison with Latin ones. Use `unicode-range` subsetting so browsers only download the ranges they need, subset per locale, and keep `font-display: swap` so text renders while fonts load. Two more: make sure your CDN caches per locale correctly rather than serving a German page from a cached English response, and localise any images that contain text, which is one more reason not to put text in images. ## 7\. SEO that isn't just translated SEO The biggest and most commonly skipped point on this list: [do keyword research per market](https://www.scopecreep.co.uk/the-free-courses-worth-finishing-seo/), in-market, rather than translating your English keywords. People search differently, not just in different words. The term with the highest volume in one country is frequently not the literal translation of the winner in another, and occasionally the English term outranks the local one in that country's own language. Then, per locale: localised title tags and meta descriptions, localised URL slugs, internal links that stay within their own locale, structured data with the right language attributes, and a separate sitemap per locale. Keep an eye on which locale's pages get crawled most, and remember that a new locale has no authority of its own on day one, so it needs internal linking and patience rather than a panic. ## 8\. Launch sequence and afterwards Don't launch five locales simultaneously. Pilot one market first, ideally not your biggest, learn what breaks, then roll the rest. You get to make your mistakes at the smallest possible scale, which is the whole reason the sequence exists. [Before each launch](https://www.scopecreep.co.uk/the-most-important-delivery-tool-i-built-was-a-spreadsheet/): per-locale redirect maps from the old URLs, analytics segmented by locale, and QA done by someone who actually reads that language, in context, on the staging site. After launch, [name an owner per market for content updates](https://www.scopecreep.co.uk/nobody-has-ever-read-your-raci/). Without that, locales drift: the English site gains three pages, the others quietly fall out of date, and within a year you have five sites of differing quality pretending to be one. Translation debt accrues exactly like technical debt, just more politely. The checklist looks long because it is, and because almost none of it can be retrofitted cheaply. But the compressed version fits in a sentence: decide your structure and hreflang before anyone writes a word, treat each locale as a market rather than a translation, and launch them one at a time. Do that and the fifth launch is genuinely easier than the first. Skip it and you get to do the first one five times.