Translating a Website Without Breaking Its Search Setup

Localising a website for search means giving each language its own stable URL, annotating which pages are equivalents of each other, translating everything a search engine reads, and keeping the set consistent as the site changes.

Key takeaways

• Decide URL structure before translating a single word. Changing it later means redirecting every page in every language.
• Language annotations must be reciprocal and complete. A one-directional set is routinely ignored.
• Titles, descriptions, alt text, structured data and navigation labels are all content. A page with translated body copy and English metadata is half-translated.
• Machine translation is a starting point for a market you are testing, not a finished asset for one you are committed to.
• Verification is mechanical: fetch each locale, confirm the annotations point both ways and the metadata is in the right language.

Step 1: choose a URL structure and commit to it

Each language needs its own crawlable URL. Whether you use subdirectories, subdomains or separate market domains, the requirement is the same: one language per URL, stable over time. Serving different languages at the same URL based on a visitor’s browser settings or IP address prevents a crawler from ever seeing the other versions.

Google’s guidance on managing localised versions of a page is explicit that each version needs its own URL. Decide this first, because it is the only item on this list that is expensive to reverse.

Step 2: annotate the equivalents

Once each language has a URL, tell search engines which URLs are versions of each other. The annotation must be reciprocal: if the English page points to the German one, the German page must point back. An incomplete or one-directional set is commonly disregarded, which leaves the pages competing with each other instead of supporting one another.

Two mistakes account for most broken sets. The first is pointing at a URL that redirects rather than the final one. The second is generating annotations from a translation table that has drifted out of sync with the pages that actually exist — so the set references translations that were never published.

Step 3: translate everything a machine reads

Body copy is the visible part and the easiest to remember. The rest is where half-translated sites are exposed:

1. Title and meta description — these are the entire search result, and Google’s SEO Starter Guide treats both as descriptive text written for the person reading the result. An English title above German body copy is the most common and most damaging version of this mistake.
2. Image alt text — it is content, and it is read.
3. Structured data values — any human-readable field inside your markup belongs in the page’s language.
4. Navigation, buttons and form labels — a translated article inside English chrome reads as an oversight.
5. The language declaration — the document’s declared language must match what is actually written on it.
6. Dates, numbers, currencies and addresses — formats differ, and getting them wrong signals the page was translated rather than written.

Step 4: adapt the meaning, not just the words

Search terms are not translations of each other. The phrase a German buyer types is frequently not the German rendering of the English phrase, and a page built on a literal translation targets a term nobody searches. Keyword work has to be redone per market, in that market’s language.

The same applies to the copy itself. Proof points, objections and units differ by market. This is the difference between translation and transcreation, and it is why the capability page on website localization treats them as separate operations rather than one.

Step 5: verify before you announce anything

Each of these is a mechanical check with a definite answer:

• Reachability: every locale URL returns 200 directly, with no redirect based on the visitor’s location.
• Reciprocity: for each page, fetch every language version and confirm each one references all the others, including itself.
• Targets resolve: every annotated URL returns 200 rather than a redirect or a 404.
• Metadata language: for each locale, read the title, description and declared language and confirm all three match the body.
• Sitemap coverage: every published locale URL appears exactly once, and no unpublished translation appears at all.
• Untranslated leftovers: search each locale for source-language strings. Buttons and error messages are the usual survivors.

Run these before submitting anything to a search engine. Announcing a broken set teaches crawlers to distrust the annotations, and that is harder to undo than fixing the pages first.

Step 6: validate the annotations mechanically

Reading annotations by eye does not scale past a handful of pages, and the failures are exactly the kind that eyes skip. Validate them as a set instead, one locale at a time, against four rules:

• Self-reference. Each page’s annotation set must include the page itself. A set listing every language except the one it sits on is incomplete.
• Reciprocity. Every URL named in the set must name the original back. Confirm that by fetching the target, not by trusting the table that generated the markup.
• Absolute, final URLs. Each entry must be a full URL, and it must be the address that answers directly rather than one that redirects to the answer.
• Canonical agreement. A page’s canonical must point at itself, never at the equivalent page in another language. A canonical aimed across languages tells a search engine the other version is the one worth keeping.

Do this per locale rather than per template. Templates are usually right; the pages that break are the ones with a hand-edited slug, a page published in one language ahead of the others, or a page retired in one market and left in place everywhere else.

Step 7: govern the set as the site changes

A localised site is correct on the day it launches and drifts afterwards, because every later change happens in one language first. That drift is the normal failure rather than a rare one, so it needs an owner and a routine instead of good intentions.

Three rules keep the set honest. First, treat a new page as unpublished in every language until its translations and annotations exist — or publish it in one language deliberately, knowing it stands alone. Second, when a page is retired or its address changes, apply that change across every locale within the same piece of work, because an annotation pointing at a dead URL is worse than no annotation. Third, re-run the Step 6 validation on a fixed schedule, since the entire point of a mechanical check is that it catches what nobody remembered to look at.

None of this makes a site compliant with anything, and no checklist can. These are search-setup mechanics: they keep each language reachable, attributable to the right market and consistent with the rest of the set. Whether the copy is right for that market is a judgement no validation pass can make for you.

What this checklist does not cover

It is a technical and editorial checklist, not a market-entry strategy. It cannot tell you which languages are worth the investment; that is a commercial decision based on where your customers actually are.

It also does not promise a result in any market. Correct annotations make a page eligible to be understood as the right version for an audience. Whether it then competes depends on the same things it always did — the content, the market and everyone else publishing in it.

And the work does not end at launch. Every page added later needs its translations and annotations, or the set decays quietly. The maintenance cadence in the post-launch SEO article applies to every language, multiplied.

Where this fits

More on how we handle URL structure, annotations and translation governance is on the website localization page, and the market-facing case for it is on for global brands.

Written by Vincent Chen, who is accountable for the claims on this page.

Sources

• Google Search Central — Localised versions of your pages
• Google Search Central — SEO Starter Guide