AI for Website Localization: The SEO Layer

Machine translation has become so cheap it has stopped being the interesting part of localization. Translating a 400-page site into German costs about forty dollars. What it costs you is everything after that: the review you did not do, the product name the model helpfully translated, the placeholder it broke, and the German title tag that is a flawless rendering of a phrase no German has ever searched for.

This guide covers both halves — the production pipeline from source to publishable copy, and the search layer that decides whether any of it earns the traffic you localized for. The second half is where most projects quietly fail, and it is the half almost nobody writes about.

The Challenge

Localizing a website is not one job. It is four, and they fail differently.

The volume is real and the value is uneven. A mid-size site has 300–800 indexable pages. Perhaps thirty carry most of the traffic. Perhaps ten carry legal or financial risk. The rest are a long tail worth something and not worth a professional translator's day rate.

Machine translation is excellent, and wrong in specific, predictable places. It nails a product description. It fumbles the idiom in your hero headline, flips formality register between paragraphs, guesses at grammatical gender it cannot know, and — the one that actually breaks things — rewrites the variable inside {count} unread messages.

Your terminology is not the model's terminology. Your product is called Anchor; the model translates it to Ancla. Your plan tier is Enterprise; it becomes Unternehmen. Nobody notices until a customer emails support about a product that does not exist.

And then there is search. A perfectly translated page can be invisible: served to the wrong market because your hreflang is one-sided and Google therefore ignores it, mis-served because you never declared an x-default, or ranking for nothing because you translated the keyword instead of researching it.

Translation is the cheap, solved part. The expensive parts are deciding where a human looks and getting the search layer right.

How AI Solves It

The mental model that makes this tractable: you are not buying translation, you are allocating review.

source → machine translation → LLM post-edit → termbase enforcement → human review, targeted only where it pays → publish

Machine translation produces a fluent, grammatical draft in seconds. A neural engine like DeepL or the Google Translation API is very good at sentence-level meaning and blind to everything beyond the sentence.

LLM post-edit is the stage that did not exist five years ago and is the reason this pipeline now works. A large language model sees the whole page at once, so it can fix what MT structurally cannot: hold formality register consistent across paragraphs, apply brand voice, restore an idiom MT rendered literally, and obey explicit rules about what must not change. It reads source and draft side by side and returns a corrected target. This is where your termbase and placeholder rules get enforced.

Termbase enforcement is a hard constraint, not a suggestion. Product names, feature names, plan tiers and technical terms go to the model as a do-not-translate list — then get checked programmatically. A model follows the list most of the time; across 400 pages, "most of the time" is not a standard you can ship against.

Human review is the budget. Spend it top-down on pages ranked by traffic and risk, and spend none of it on the 2021 changelog.

What AI does not do is tell you which pages matter, hold legal liability, or know that your German customers are B2B and expect Sie. Those are inputs you supply.

Recommended Tools & Models

Two purchases, and they are not the same purchase. You need something that translates and something that edits.

Layer one — machine translation. Verified July 2026.

You can skip dedicated MT and translate straight with an LLM, and for a handful of brand-critical pages that is often the better result. For 400 pages of documentation, MT followed by an LLM post-edit is cheaper and more consistent — MT does a narrow job well, and the LLM then does the job it is genuinely good at: editing.

Layer two — the post-edit model. Any current frontier model is competent; what varies is context window and cost at volume. Claude Sonnet 5 handles long pages in one pass and is reliable about literal instructions like do not translate anything inside curly braces — that reliability is the whole game. Claude Haiku 4.5 is cheap enough to run across an entire back catalogue. GPT-5.5 and Gemini 3.5 are strong generalists, and Gemini's large context window helps when feeding a whole docs section through at once. Benchmark DeepSeek, Qwen and GLM on Chinese pairs before assuming a Western model wins; Mistral Medium is strong on French.

If content cannot leave your infrastructure — common the moment legal copy is involved — run the post-edit locally with Ollama or LM Studio. Quality drops below the frontier models; the content never leaves the building. Once the prompts are stable, n8n chains the whole thing together: watch a content directory, push new source through MT, post-edit, run the termbase check, drop the result in a review queue.

Step-by-Step Implementation

1. Build the termbase before you translate anything

A one-hour job that prevents a hundred hours of cleanup, and almost nobody does it first. List every string that must never be translated, and every string that must be translated exactly one way:

• Never translate: product names, feature names, plan tiers, trademarked terms, UI labels that appear in screenshots, code identifiers, {placeholders}, HTML tags and attributes, URLs.
• Translate exactly one way: your domain vocabulary. If workspace becomes Arbeitsbereich on one page and Arbeitsumgebung on another, your product has two names in German, and your support team finds out before you do.

Store it as a two-column table per language. It goes into the MT engine's glossary and into the post-edit prompt — belt and braces, because neither is reliable alone.

2. Rank every page by traffic and by risk

This decides your budget. Do it in a spreadsheet, before you write a line of code.

Risk tier — always human, regardless of traffic: terms of service, privacy and cookie copy, pricing, billing, refunds, anything medical, financial, legal or safety-related, regulated claims, checkout and account flows.

Traffic tier — human review top-down until the budget runs out. Sort by sessions or revenue. A small fraction of pages carries most of the value, so a budget covering the top decile covers most of what a reader will ever actually see.

Never, or last: archived posts, old changelogs, deprecated docs. Publish them post-edited and move on. Re-review a page the day it enters the top tier — not before.

Write the ranking down. It is the artifact that turns "we need human review" from an unbounded cost into a number.

3. Run the MT pass

Feed the source through DeepL or the Translation API with the glossary loaded. Keep source and output side by side — the next stage needs both. Publish nothing from here.

4. Post-edit with an LLM

This is the load-bearing prompt in the pipeline.

The [VERIFY] list is the highest-value part of the output. A model asked to mark its own uncertainty reliably flags the exact sentences a reviewer should look at — which is how a two-hour review becomes a twenty-minute one.

5. Verify the termbase programmatically

Never trust the model on this. After post-editing, run a script that checks, per page:

• Every do-not-translate term still appears verbatim.
• Every placeholder in the source appears, unchanged, in the target — same count, same spelling, same syntax.
• Every HTML tag in the source appears in the target.

Twenty lines of code, and it catches the class of error that costs the most to find in production — because a broken placeholder does not look broken. It looks like a sentence with a word missing.

6. Localize the metadata separately — and re-research it

Do not let the title tag and meta description ride along with the body. They are a different job.

7. Get the search layer right

This is the half that decides whether any of the above earns anything.

Give every language version its own URL. Google's guidance is explicit: "Google recommends using different URLs for each language version of a page rather than using cookies or browser settings to adjust the content language on the page." If one URL serves German to a German browser and English to everyone else, Googlebot sees one version and the other does not exist.

Choose a URL structure. Google publishes the trade-offs:

For most sites the subdirectory wins, for a reason Google's table does not state: it keeps every language on one domain, so the authority you have already built is shared rather than split across three domains you would now have to earn links for separately. Reach for a ccTLD when the country, not the language, is the product — separate legal entities, separate pricing, separate inventory.

Implement hreflang, and get reciprocity right. This is the rule that silently voids everything. From Google's documentation: "If two pages don't both point to each other, the tags will be ignored."

A one-sided hreflang is not a partial win. It is nothing. If /de/pricing points to /pricing but /pricing does not point back, Google discards the annotation. Every page in a language set must reference every other page in the set — including itself.

Three ways to declare it, and you pick one: <link rel="alternate" hreflang="..."> in the <head>, a Link: HTTP header (the option for PDFs), or <xhtml:link> elements in the XML sitemap. The sitemap is easiest to keep reciprocal, because the whole set lives in one file you can actually look at.

Declare x-default. In Google's words: "The reserved x-default value is used when no other language/region matches the user's browser setting." It is where a Brazilian visitor lands when you have en, de and fr and nothing else. Without it, that visitor's fate is a coin toss.

Split by region where the market, not the language, differs. A Spaniard searches ordenador; a Mexican searches computadora. One language, two markets, two keyword sets — which is exactly what hreflang="es-ES" versus hreflang="es-MX" exists to express. Do this when pricing, inventory or vocabulary genuinely differ; do not mint region variants of an identical page just to have more URLs.

And know that Search Console will not check this for you. The International Targeting report — the one that used to list hreflang errors — was deprecated in August 2022 and removed the following month. Google Search Central's own note at the time: "The International Targeting report has been deprecated... We continue to support hreflang and our recommendations for managing multilingual and multiregional sites still stand." The support is intact; the reporting is gone. Validate hreflang with a crawler, or by reading the rendered <head> of each language and confirming the set is closed.

8. Understand where the spam-policy line actually is

People get this wrong in both directions — paralyzed by a policy that does not say what they think, or blithely publishing 4,000 auto-translated pages into a real penalty. Here is the precise state of it.

Before March 2024, Google's spam policies listed, as an example of spammy automatically-generated content: "Text translated by an automated tool without human review or curation before publishing." That line is where the widely-repeated "machine translation is spam" belief comes from.

In March 2024, Google replaced that section with scaled content abuse: "when many pages are generated for the primary purpose of manipulating search rankings and not helping users. This abusive practice is typically focused on creating large amounts of unoriginal content that provides little to no value to users, no matter how it's created." Translation is named in the examples: "Scraping feeds, search results, or other content to generate many pages (including through automated transformations like synonymizing, translating, or other obfuscation techniques), where little value is provided to users."

In June 2025, with Reddit's machine-translated pages having been expanding across languages for over a year, Google told Search Engine Land: "our policies do not strictly define content that has been translated by AI as spam. Our scaled content abuse policy mentions automated transformations, including translations, as part of the overall warning against creating large amounts of unoriginal content that provides little to no value to users."

So the line is this. Machine translation is not spam because it is machine translation. It becomes scaled content abuse when it is many pages, unoriginal, generated primarily to rank, and providing little value to users — all four together. Google's own guidance under the earlier policy, from Lizzi Sassman in an October 2022 office-hours session, was that machine translation is "totally fine for Google as long as there's a human involved in the review process. That's the key."

The pipeline in this guide is built around exactly that: not a bulk auto-translation, but a reviewed, terminology-controlled, market-adapted localization of pages that were worth reading in the first place. What would put you on the wrong side of the line is generating fifty language versions of a thin page, with localized metadata bolted on, for a reader who does not exist.

Real-World Examples

Example 1: The keyword that was translated instead of researched

Before. A phone-accessories retailer localizes into German. The English title tag is "Cases for Every Mobile Phone." The MT pass returns "Hüllen für jedes Mobiltelefon" — correct, natural, grammatical German.

The page ranks for nothing.

What was actually true. Germans do not call it a Mobiltelefon in a search box. They call it a Handy — a word that looks English, is not used this way in English, and is what real people type. The translation was perfect and pointed at a phrase almost nobody searches.

After. Keyword research is run in German first. The title becomes "Handyhüllen für jedes Modell", built around the term that has volume, and the body copy uses the word too — a title promising one thing over a page that says another satisfies nobody.

What changed: nothing about translation quality. The German was correct both times. The second one was aimed at a query that exists.

Example 2: The placeholder that broke in production

Before. A SaaS app localizes its notification strings into French. The source string:

You have {count} unread messages in {workspace_name}.

The model returns something that reads beautifully:

Vous avez {compte} messages non lus dans {nom_espace}.

It translated the placeholder names. The application looks up count and workspace_name and finds neither. Depending on the framework, French users now see raw braces, an empty gap, or a crash.

Nothing about the translation looks wrong. It is correct French. A linguistic reviewer who does not read code will approve it.

After. The post-edit prompt carries the absolute rule — anything inside curly braces is copied character-for-character — and a script verifies that every placeholder in the source appears unchanged in the target:

Vous avez {count} messages non lus dans {workspace_name}.

What changed: one paragraph in the prompt, and twenty lines of verification. The verification is the part that matters, because the model gets this right most of the time.

Example 3: The register that flipped mid-page

Before. A German landing page comes back from MT. The hero says "Entdecken Sie Ihre Daten" — formal. Three paragraphs down, a CTA says "Probier es aus" — informal. MT has no page-level view; it makes a fresh, locally-plausible choice sentence by sentence. To a German reader this is not a subtle wobble — it reads as though two different companies wrote the page.

After. The post-edit model, which does see the whole page, is told: "Formality: use Sie, consistently across the entire page. Never switch register mid-page." One instruction, one pass, fixed.

What changed: this is the clearest illustration of why the post-edit stage exists at all. It is not a polish step on top of MT — it is the only stage in the pipeline that can see more than one sentence at a time.

Industry-Specific Applications

SaaS and developer tools. The placeholder problem is your problem — UI strings, ICU plurals and interpolated variables break in ways invisible to linguistic review. Ship the verification script before the first language.

E-commerce. Metadata is where the money is; pricing and shipping copy sit in the always-human tier.

Publishing and media. A huge long tail with concentrated value — the best fit for traffic-ranked review. Post-edit the archive, put a human on the pages still being read.

Regulated industries — health, finance, legal. The machine pass is a drafting aid and nothing more. The pipeline saves you time; it does not save you the reviewer.

Best Practices

• Write the termbase before you translate. The cheapest hour in the project.
• Rank pages by traffic and risk, in writing. Review is a budget with a number on it, not a virtue you either have or lack.
• Legal, pricing, medical and safety copy always get a human. No traffic threshold.
• Post-edit with the whole page in context. It is the only stage that can hold register, voice and terminology consistent, because it is the only one that sees more than a sentence.
• Copy placeholders character-for-character, and verify with a script. The model is right most of the time; a script is right every time.
• State the formality register explicitly. Sie or du, vous or tu. Otherwise the model picks one per sentence.
• Localize metadata separately, against real search data. Translate the meaning, then rewrite the title around the phrase people type.
• Make hreflang reciprocal, and include a self-reference. One-sided annotations are ignored entirely.
• Declare x-default, and validate hreflang with a crawler — Search Console stopped reporting these errors in 2022.
• Never machine-translate at scale into pages nobody would want. That is the behaviour the scaled content abuse policy is actually about.

Common Pitfalls

One-sided hreflang. The most common technical failure, with the harshest failure mode: not degraded — ignored.

Translating the keyword instead of researching the market. The most common strategic failure. Your German page is a flawless answer to a question no German asked, which costs you the entire reason you localized.

Broken placeholders. Correct-looking target text, broken application. Invisible to a linguistic reviewer, invisible in a prose diff, obvious to a user.

Terminology drift. Workspace → Arbeitsbereich on Monday, Arbeitsumgebung on Tuesday. Two words, one product, and a support queue that cannot search for either.

Gendered guessing. "Are you sure?" in French needs to know whether the reader is sûr or sûre. You do not know. The model will guess, or emit the ugly sûr(e). The correct move is a gender-neutral rewrite, and you have to ask for it.

Auditing what you cannot read. The deepest pitfall. MT and LLMs produce assured, natural output when they are wrong exactly as readily as when they are right (see hallucinations), and in a language you do not read, fluency is all you can see. If nobody at the company reads the target language, human review is not optional at any traffic level — it is the only signal you have.

Publishing at scale and calling it localization. Fifty language versions of a thin page, generated for search and read by nobody, is the definition Google actually wrote down. The defense is not a disclaimer. It is that the pages were worth reading, and that a human looked at the ones that matter.

Measuring Success

Indexation of the localized URLs. The bluntest test: are the /de/ pages in the index at all? A section that was never indexed did not fail at translation — it failed at robots, canonicals, noindex or URL structure. (Not at hreflang: hreflang decides which version gets served to whom, not whether a page is indexed at all. Chasing hreflang for a page Google never crawled is a wasted afternoon.)

hreflang set integrity. Crawl each language, confirm every set is closed and reciprocal and that x-default is declared. This should be 100%, and checked on every deploy, because one template change breaks all of it at once.

Organic traffic to localized pages, per language. Never in aggregate — one strong language will hide four dead ones.

Rankings for the researched term, not the translated one. Measure the position of a literal keyword translation and the number will look bad no matter how good the page is.

Termbase violations per hundred pages. Should trend to zero and stay there. A climb means someone shipped a product name and did not add it to the list.

Placeholder integrity. Pass/fail, not a percentage. One broken string in a checkout flow outweighs a hundred clumsy sentences in a blog post.

Review coverage against the ranking. What share of your top-decile-by-traffic pages, and all of your risk-tier pages, have been read by a human who speaks the language? That number — not word count — is the honest measure of whether you localized a site or merely translated one.

Cost Analysis

The arithmetic is the argument, so here it is with the assumptions shown. A 400-page site at 800 words per page: 320,000 words per language.

The machine pass. Take 1,000 words ≈ 6,000 characters.

• MT: Google Cloud Translation at $20 per million characters → 6,000 characters = $0.12 per 1,000 words.
• LLM post-edit: the model reads source, MT draft and termbase, and writes the corrected target — call it ~3,700 input tokens and ~1,700 output tokens per 1,000 source words. On Claude Haiku 4.5 at $1 per million input tokens and $5 per million output: (3,700 × $1 + 1,700 × $5) ÷ 1,000,000 ≈ $0.01 per 1,000 words.
• Machine pass total: about $0.13 per 1,000 words — roughly $42 per language across 320,000 words.

That number should reframe the project. The translation is free. It rounds to nothing against a single day of anyone's salary.

The human pass — the actual budget. Translation vendors publish rates around $0.15–$0.30 per word for full human translation and $0.05–$0.15 per word for machine-translation post-editing, where a human edits machine output rather than starting from scratch. These are vendor-published ranges, not an independent study — treat them as an order of magnitude and get a real quote for your pair. At a mid-range $0.20/word human rate and $0.08/word post-editing rate:

The middle row is the one that gets you into the scaled content abuse conversation. The bottom row is the one that ships.

What the money buys. Not translation — you already had that for $42. It buys a native speaker's judgment on the forty pages where being wrong is expensive, and it buys the thing Google's own guidance names as the key: a human involved in the review process. What it does not buy is knowing which pages matter. That ranking is yours, it takes an afternoon, and it is the highest-leverage artifact in this guide.

Related Tools

• DeepL — the machine-translation layer, with glossary support
• Claude — post-editing long pages; reliable about literal do-not-translate rules
• ChatGPT — post-editing and metadata rewriting
• Google Gemini — large context for whole documentation sections in one pass
• Microsoft Copilot — drafting and reviewing inside Office documents
• Mistral Le Chat — strong European-language handling
• DeepSeek — benchmark for Chinese pairs
• Ollama and LM Studio — local post-editing when content cannot leave your infrastructure
• n8n — wiring MT, post-edit, termbase check and review queue into one pipeline
• Qwen Code — writing the placeholder-verification script

Related Models

• Claude Sonnet 5 — long pages, literal instruction-following, consistent register
• Claude Haiku 4.5 — cheap enough to post-edit an entire back catalogue
• Claude Opus — the highest-stakes pages, where brand voice carries the weight
• GPT-5.5 — strong generalist for post-editing and metadata
• Gemini 3.5 — large context window for whole-section consistency
• Qwen, DeepSeek, GLM — benchmark before assuming a Western model wins on Chinese
• Mistral Medium — European languages; Command — enterprise generation workflows

New to writing prompts? Start with prompt engineering — the difference between a post-edit that preserves your placeholders and one that quietly breaks them is a single paragraph of instruction. For the underlying technology, see natural language processing, text generation, semantic understanding and inference — and for how localized pages surface in AI-generated answers as well as the ten blue links, generative engine optimization.