Claude as an SEO Translator: 4,500 Pages, 10 Languages

Three agencies quoted us for localizing skillproof.dev into 10 European languages. The numbers ranged from 14,000 to 22,000 dollars and six to ten weeks, mostly because the site isn’t static: 30-plus blog articles, 106 catalog skill cards that change verdicts as we retest them, category pages, and every UI string in the shell. An agency prices that as a one-time project. We needed it to survive a Tuesday where we ship three new skill reviews and edit two old ones.

So we didn’t hire an agency. We ran parallel Claude agents, one per language, against a shared instruction set, and localized roughly 4,500 pages in about a day. This article is that instruction set: the six rules that made the difference between output that reads like a translation and output that reads like it was written by someone who works in that market, plus the honest costs and the two ways it went wrong before we fixed it.

The problem with translating a living site

Machine translation solved the mechanical problem years ago. Google Translate will hand you grammatically correct German for any English sentence you paste in. The problem was never grammar. It’s three things translation tools don’t touch:

SEO keywords don’t translate word for word. “How to install Claude skills” doesn’t become a German search query by running through a dictionary; German developers search “Claude Skills installieren,” verb at the end, product name untouched. Get this wrong and your German page is fluent and invisible.

Register is a market decision, not a language rule. German has “du” and “Sie,” French has “tu” and “vous,” and which one a dev-tools brand uses is a positioning choice, not a grammar choice. An agency translator without brand context defaults to formal, which reads stiff next to Linear’s German site or Stripe’s.

And a site isn’t a document. It’s 4,500 pages that change weekly. A one-time translation delivery is stale within a month, and re-briefing an agency for every update isn’t a workflow, it’s a subscription you don’t want.

We turned our working method into a skill, seo-translator, and it lives in our skills repo — the same instructions this article describes, free to run against your own site.

How we set it up

The mechanism is simple: one Claude agent per target language, each with the full source content and the same rule set, running in parallel rather than in sequence. Ten languages means ten agents working at once instead of one translator working through a queue for two months.

Each agent got a self-contained brief: the source markdown, the never-translate list, the per-market register default, and the character limits for that page’s title and meta description. No agent needed to ask us anything mid-run, which turned out to matter more than we expected — more on that below.

The six rules

1. Keywords as the market actually searches them

Every article and skill card carries a target keyword. The instruction isn’t “translate the keyword,” it’s “find how this market’s developers phrase this search.” For our “how to install Claude skills” guide, the literal German translation is grammatically fine and useless. The query that gets typed is “Claude Skills installieren.” Same for French: not a textbook translation but “installer les skills Claude,” matching how French developer blogs actually phrase it. We had agents check phrasing against how the term appears in that language’s developer forums and docs sites before committing to it, not just render the English keyword through a dictionary.

2. Per-market register, decided in advance

We didn’t let each agent guess a tone. We set a table and every agent followed it:

Market	Register	Reference
German (de)	du	Linear, Vercel
French (fr)	vous	Stripe, Notion
Spanish (es)	tú	Most dev-tool sites
Italian (it)	tu	Informal dev convention
Portuguese (pt)	você	Brazilian dev-tool norm
Dutch (nl)	je	Standard for SaaS
Polish (pl)	formal (Pan/Pani avoided, neutral phrasing)	B2B SaaS convention
Japanese (ja)	です/ます, no keigo	Standard business-polite
Korean (ko)	해요체	SaaS-standard, not formal 합쇼체
Swedish (sv)	du	Universal in Swedish, even B2B

The German and French pairing is the one that trips up default MT the hardest, since both defaults to formal, and both of our reference brands prove it’s a real market choice rather than a stylistic afterthought.

3. A hard never-translate list

Every agent got the same exclusion list, checked before output was accepted: code blocks and inline code, CLI commands, product and brand names (Claude, Claude Code, SkillProof, Anthropic), file paths, and any {placeholder} token in UI strings. This sounds obvious until you watch a first-pass translation render npm install as a translated verb phrase or quietly rename SKILL.md. We treated this as a validation gate, not a suggestion: any output containing a translated code fence or an altered placeholder failed automatically and reran.

4. The anti-AI pass

The first draft from any LLM translation carries tells: calques (English sentence structure wearing target-language words), stock AI phrasing translated intact (“in today’s fast-paced world” has equivalents in every language, and they’re just as tired), and a flatness that a native reader clocks in one paragraph. We ran a dedicated second pass per language whose only job was hunting these down — restructuring sentences that were obviously English word order wearing German vocabulary, replacing translated filler with how a native tech writer would actually open that paragraph. This pass is why the output reads like a market-native writer instead of a well-translated document.

5. Token discipline

This is what makes the whole thing affordable instead of merely possible. One pass per language, not draft-then-revise-then-polish. No restating the source text back before translating it — a habit that quietly doubles token spend for zero quality gain. And batch processing: catalog cards translate in batches rather than one API call per card, since per-call overhead on 106 short cards adds up fast.

6. Character limits enforced per language, not assumed

Title tags at 60 characters and meta descriptions at 155 are an English-language guideline that doesn’t hold once you’re in German, where compound nouns run long, or Japanese, where character count means something entirely different than in Latin scripts. We gave each agent the limit as a hard constraint checked against the actual rendered string, not the English source length, so German titles didn’t blow past 60 just because the German noun for “translator” is inconveniently long.

What it actually cost

We logged token spend across the full run. These are real numbers from our own Sonnet usage, not estimates:

Content type	Tokens per language	Notes
~2,500-word blog article	120,000–160,000	Source + translation + anti-AI pass
106 catalog skill cards (batched)	150,000–170,000	Short cards, but 106 of them adds up
Category and UI strings	Under 20,000	Small, mostly static

Across 10 languages, the full site localization came to a few dollars in API spend, not the 14,000-plus dollars we were quoted for a slower, staler deliverable. The whole run — 30-plus articles, 106 cards, category pages, and UI strings, across 10 languages — took about a day of parallel agents running, most of it unattended once the briefs were set. That’s the number that actually changes the calculus: it’s not that AI translation is cheaper than an agency, it’s that it’s cheap enough to re-run every time the source content changes, which a one-time agency deliverable can never be.

What went wrong

Two failure modes were worth catching before they shipped, and neither would have surfaced without validation.

The first was agents that reported “waiting” instead of producing output — usually because a brief referenced something outside the agent’s own context, like “use the same phrasing as the German version” from an agent that had no access to the German output. The fix was making every brief fully self-contained: no cross-agent references, no “check with the other run,” everything the agent needed to finish the task included up front.

The second was an accent-stripping incident on one batch of Polish catalog cards, where a formatting step somewhere in the pipeline quietly dropped diacritics on output that looked fine in a terminal but was wrong on the page. We caught it because we validate by counting, not by reading agent reports: every translated file gets checked against the source for character-count sanity, heading count, and a diff of untranslated tokens (code blocks, placeholders, product names) that should have survived intact. An agent telling you “translation complete” is not evidence. A file that has the same number of headings as the source, the same untouched code blocks, and a title under the market’s character limit is evidence.

hreflang tags are the part that makes 10 language versions function as one indexable site instead of ten competing ones. Each language version needs reciprocal hreflang links pointing to every other version plus itself, or search engines will happily rank the wrong-language page for a query. It’s mechanical once the URL structure is set, but it’s also the step most DIY translation projects skip, and it’s worth getting right before you ship your first localized page. Our install guide covers the skill installation side if you’re setting this up as a repeatable skill rather than a one-off script.

What we’d tell a team starting Monday

Don’t translate the whole site on day one. Pick your two or three highest-traffic pages, run them through all 10 languages, and check the output against a native speaker before scaling to the rest. The rules above are the ones we learned by getting them wrong first; skip that step and you’ll relearn them on 4,500 pages instead of three.

Write the register table before you write a single translated word. It’s a business decision, not a linguistic one, and it’s much cheaper to argue about at the start than to retrofit after 106 cards use the wrong pronoun.

Validate by counting, not by asking. If your pipeline can’t tell you, mechanically, that a translated file has the right number of headings and untouched code blocks, you don’t have a translation pipeline, you have a hope.

And if you’re doing this for a content-heavy site rather than a handful of static pages, the same discipline that keeps a content strategy coherent across dozens of articles is what keeps a translation run coherent across dozens of languages: one instruction set, applied consistently, checked against the source every time. We wrote up how we hold ourselves to that same bar in how we test Claude skills.

If you want to try the keyword-localization step on a single page before committing to a full run, our SEO converter will format the output; our best writing skills page ranks the tested skills worth pairing it with, including SEO Audit for catching what a translation pass alone won’t, like broken internal links across language versions.

FAQ

Can Claude actually translate a whole website, not just single pages?

Yes, but not as one giant prompt. What worked for us was splitting the site into per-language agents running in parallel, each with a self-contained brief covering the full rule set: keyword localization, register, the never-translate list, and character limits. A single agent trying to hold 10 languages in one context loses consistency fast; 10 agents each holding one language stayed consistent because the brief, not the agent’s memory, carried the rules.

Is AI translation good enough for SEO, or does it need a human pass?

For technical and marketing content, a well-briefed Claude run gets close enough that a native-speaker spot-check is the right amount of human involvement, not a full re-translation. The SEO-specific risk isn’t grammar, it’s keyword phrasing: an agent that translates literally instead of localizing the search query will produce fluent, unfindable pages. That’s why rule one in this piece is about search phrasing, not grammar.

How much does it cost to translate a site into multiple languages with Claude?

Based on our own run: a 2,500-word article costs roughly 120,000–160,000 tokens per language on Sonnet, and 106 short catalog cards cost about 150,000–170,000 tokens per language batched. Across 10 languages our full-site localization came to a few dollars total in API spend. The bigger cost isn’t tokens, it’s the setup time for the rule set and validation gates, which you pay once and reuse on every future update.

What’s the biggest mistake teams make when localizing with AI?

Skipping validation and trusting the agent’s own “done” report. We caught an accent-stripping bug and a stalled-agent problem only because we check translated output against the source mechanically — heading counts, untouched code blocks, character limits — rather than reading what the agent claims it did. Treat every translation run as needing the same acceptance gate you’d apply to a code change: verify the artifact, not the report.