Claude som SEO-översättare: 4 500 sidor, 10 språk

Tre byråer gav oss offerter på att lokalisera skillproof.dev till 10 europeiska språk. Siffrorna låg mellan 14 000 och 22 000 dollar och sex till tio veckor, mest för att sajten inte är statisk: 30-plus blogginlägg, 106 kataloginlägg med skill-omdömen som ändras när vi testar om dem, kategorisidor och varenda UI-sträng i gränssnittet. En byrå prissätter det som ett engångsprojekt. Vi behövde något som klarar en tisdag där vi publicerar tre nya skill-recensioner och redigerar två gamla.

Så vi anlitade ingen byrå. Vi körde parallella Claude-agenter, en per språk, mot samma instruktionsuppsättning, och lokaliserade ungefär 4 500 sidor på ungefär ett dygn. Den här artikeln är den instruktionsuppsättningen: de sex reglerna som avgjorde skillnaden mellan text som läses som en översättning och text som läses som om den skrevs av någon som jobbar på den marknaden, plus de faktiska kostnaderna och de två sätt det gick fel innan vi rättade till det.

Problemet med att översätta en sajt som lever

Maskinöversättning löste det mekaniska problemet för länge sedan. Google Translate ger dig grammatiskt korrekt tyska för vilken engelsk mening du än klistrar in. Problemet har aldrig varit grammatik. Det handlar om tre saker som översättningsverktyg inte rör vid:

SEO-nyckelord går inte att översätta ord för ord. "How to install Claude skills" blir inte en tysk sökfras genom att köras igenom ett lexikon; tyska utvecklare söker på "Claude Skills installieren", verbet sist, produktnamnet orört. Gör man fel här blir den tyska sidan flytande och osynlig.

Tilltalsform är ett marknadsbeslut, inte en språkregel. Tyska har "du" och "Sie", franska har "tu" och "vous", och vilken form ett utvecklarverktyg använder är ett positioneringsval, inte ett grammatikval. En byråöversättare utan varumärkeskontext hamnar per default i formell form, vilket känns stelt bredvid Linears tyska sajt eller Stripes.

Och en sajt är inget dokument. Det är 4 500 sidor som ändras varje vecka. En engångsleverans av översättning är föråldrad inom en månad, och att briefa om en byrå för varje uppdatering är inget arbetsflöde – det är ett abonnemang man inte vill ha.

Vi gjorde vår arbetsmetod till en skill, seo-translator, och den ligger i vårt skills-repo – samma instruktioner som den här artikeln beskriver, fri att köra mot din egen sajt.

Så satte vi upp det

Mekaniken är enkel: en Claude-agent per målspråk, var och en med hela källinnehållet och samma regeluppsättning, och de körs parallellt i stället för i sekvens. Tio språk betyder tio agenter som jobbar samtidigt i stället för en översättare som arbetar sig igenom en kö i två månader.

Varje agent fick en självständig brief: käll-markdown, listan över det som aldrig ska översättas, standardtilltalsformen för respektive marknad och teckengränserna för sidans titel och metabeskrivning. Ingen agent behövde fråga oss om något mitt i körningen, vilket visade sig spela större roll än vi trodde – mer om det längre ner.

De sex reglerna

1. Nyckelord som marknaden faktiskt söker på

Varje artikel och skill-kort har ett målnyckelord. Instruktionen är inte "översätt nyckelordet", den är "ta reda på hur den här marknadens utvecklare formulerar sökningen". För vår guide om hur man installerar Claude skills är den bokstavliga tyska översättningen grammatiskt korrekt och helt oanvändbar. Det som faktiskt skrivs in är "Claude Skills installieren". Samma sak på franska: ingen läroboksöversättning utan "installer les skills Claude", vilket matchar hur franska utvecklarbloggar faktiskt uttrycker det. Vi lät agenterna kontrollera formuleringen mot hur termen förekommer på det språkets utvecklarforum och dokumentationssajter innan de bestämde sig, i stället för att bara köra det engelska nyckelordet genom ett lexikon.

2. Tilltalsform per marknad, bestämd i förväg

Vi lät inte varje agent gissa sig till en ton. Vi satte upp en tabell och alla agenter följde den:

Marknad	Tilltalsform	Referens
Tyska (de)	du	Linear, Vercel
Franska (fr)	vous	Stripe, Notion
Spanska (es)	tú	De flesta utvecklarverktygssajter
Italienska (it)	tu	Informell utvecklarkonvention
Portugisiska (pt)	você	Brasiliansk norm för utvecklarverktyg
Nederländska (nl)	je	Standard för SaaS
Polska (pl)	formell (undviker Pan/Pani, neutral formulering)	B2B-SaaS-konvention
Japanska (ja)	です/ます, ingen keigo	Standard affärsartig
Koreanska (ko)	해요체	SaaS-standard, inte formell 합쇼체
Svenska (sv)	du	Universellt på svenska, även B2B

Kombinationen tyska och franska är den som ställer till det mest för vanlig maskinöversättning, eftersom båda som default hamnar i formell form, och båda våra referensvarumärken visar att det är ett verkligt marknadsval snarare än en stilistisk eftertanke.

3. En strikt lista över det som aldrig ska översättas

Varje agent fick samma undantagslista, kontrollerad innan resultatet godkändes: kodblock och inline-kod, CLI-kommandon, produkt- och varumärkesnamn (Claude, Claude Code, SkillProof, Anthropic), filsökvägar och alla {placeholder}-token i UI-strängar. Det låter självklart tills man ser en första översättning göra om npm install till en översatt verbfras eller i tysthet döpa om SKILL.md. Vi behandlade det här som en valideringsgrind, inte ett förslag: alla resultat som innehöll ett översatt kodblock eller en ändrad placeholder underkändes automatiskt och kördes om.

4. Anti-AI-genomgången

Det första utkastet från en LLM-översättning bär alltid spår: kalkeringar (engelsk meningsbyggnad klädd i måltexordval), schablon-AI-fraser översatta rakt av ("in today's fast-paced world" har motsvarigheter på varje språk, och de är precis lika slitna där också) och en platthet som en infödd läsare märker inom ett stycke. Vi körde en separat andra genomgång per språk vars enda uppgift var att jaga upp det här – bygga om meningar som uppenbart var engelsk ordföljd klädd i tyskt ordförråd, byta ut översatt utfyllnad mot hur en infödd techskribent faktiskt skulle inleda stycket. Den här genomgången är anledningen till att texten läses som skriven av en marknadsinföding i stället för ett välöversatt dokument.

5. Tokendisciplin

Det här är vad som gör hela upplägget överkomligt i stället för bara möjligt. En genomgång per språk, inte utkast-sedan-revidera-sedan-putsa. Ingen omformulering av källtexten innan översättningen börjar – en vana som i tysthet dubblar tokenförbrukningen utan någon kvalitetsvinst. Och batchbearbetning: kataloginläggen översätts i grupper i stället för ett API-anrop per kort, eftersom overheaden per anrop snabbt drar iväg på 106 korta kort.

6. Teckengränser som gäller per språk, inte antas

Titeltaggar på 60 tecken och metabeskrivningar på 155 är en engelskspråkig tumregel som inte håller så fort man är i tyskan, där sammansatta substantiv blir långa, eller i japanskan, där teckenantal betyder något helt annat än i latinska skriftsystem. Vi gav varje agent gränsen som ett hårt krav kontrollerat mot den faktiska renderade strängen, inte den engelska källängden, så att tyska titlar inte sprängde 60 tecken bara för att det tyska ordet för "översättare" råkar vara opraktiskt långt.

Vad det faktiskt kostade

Vi loggade tokenförbrukningen genom hela körningen. Det här är verkliga siffror från vår egen Sonnet-användning, inte uppskattningar:

Innehållstyp	Tokens per språk	Anteckningar
Blogginlägg på ~2 500 ord	120 000–160 000	Källa + översättning + anti-AI-genomgång
106 kataloginlägg (batchat)	150 000–170 000	Korta kort, men 106 stycken summerar snabbt
Kategori- och UI-strängar	Under 20 000	Litet, mestadels statiskt

Över 10 språk landade hela sajtlokaliseringen på några enstaka dollar i API-kostnad, inte de 14 000-plus dollar vi blivit offererade för en långsammare, mer föråldrad leverans. Hela körningen – 30-plus artiklar, 106 kort, kategorisidor och UI-strängar, över 10 språk – tog ungefär ett dygn med parallella agenter igång, och det mesta skötte sig själv sedan briefarna var på plats. Det är den siffran som faktiskt ändrar kalkylen: det handlar inte om att AI-översättning är billigare än en byrå, det handlar om att den är billig nog att köra om varje gång källinnehållet ändras, vilket en engångsleverans från en byrå aldrig kan bli.

Vad som gick fel

Två felmönster var värda att fånga innan de nådde publicering, och inget av dem hade synts utan validering.

Det första var agenter som rapporterade "väntar" i stället för att leverera resultat – oftast för att en brief hänvisade till något utanför agentens egen kontext, som "använd samma formulering som den tyska versionen" till en agent som inte hade tillgång till den tyska texten. Lösningen var att göra varje brief helt självständig: inga hänvisningar mellan agenter, inget "kolla med den andra körningen", allt agenten behövde för att slutföra uppgiften fanns med från början.

Det andra var en incident där diakritiska tecken försvann i en batch polska kataloginlägg, där ett formateringssteg någonstans i pipelinen i tysthet tappade diakriter på resultat som såg bra ut i en terminal men blev fel på sidan. Vi upptäckte det för att vi validerar genom att räkna, inte genom att läsa agenternas egna rapporter: varje översatt fil kontrolleras mot källan för rimligt teckenantal, antal rubriker och en diff av oöversatta token (kodblock, placeholders, produktnamn) som skulle ha överlevt orörda. En agent som säger "översättning klar" är inte ett bevis. En fil med lika många rubriker som källan, samma orörda kodblock och en titel under marknadens teckengräns – det är ett bevis.

Hreflang-taggar är det som gör att 10 språkversioner fungerar som en indexerbar sajt i stället för tio konkurrerande sajter. Varje språkversion behöver ömsesidiga hreflang-länkar som pekar till varje annan version plus sig själv, annars rankar sökmotorerna gärna fel-språkiga sidan för en sökning. Det är mekaniskt så fort URL-strukturen är på plats, men det är också steget de flesta gör-det-själv-översättningsprojekt hoppar över, och det är värt att få rätt innan man publicerar sin första lokaliserade sida. Vår installationsguide tar upp skill-installationsdelen om du sätter upp det här som en repeterbar skill snarare än ett engångsskript.

Vad vi skulle säga till ett team som börjar på måndag

Översätt inte hela sajten dag ett. Välj ut de två eller tre sidorna med mest trafik, kör dem genom alla 10 språken och stäm av resultatet mot en infödd talare innan ni skalar upp till resten. Reglerna ovan är sådana vi lärde oss genom att först göra fel; hoppar man över det steget får man lära om det på 4 500 sidor i stället för tre.

Skriv tilltalstabellen innan du översätter ett enda ord. Det är ett affärsbeslut, inte ett språkligt, och det är mycket billigare att bråka om i början än att rätta till i efterhand när 106 kort redan använder fel tilltalsform.

Validera genom att räkna, inte genom att fråga. Om pipelinen inte mekaniskt kan tala om för dig att en översatt fil har rätt antal rubriker och orörda kodblock, har du ingen översättningspipeline – du har en förhoppning.

Och gör man det här för en innehållstung sajt snarare än en handfull statiska sidor, är det samma disciplin som håller en innehållsstrategi sammanhållen genom dussintals artiklar som håller en översättningskörning sammanhållen genom dussintals språk: en instruktionsuppsättning, tillämpad konsekvent, kontrollerad mot källan varje gång. Vi har skrivit om hur vi håller oss till samma måttstock i hur vi testar Claude skills.

Vill du testa nyckelordslokaliseringssteget på en enda sida innan du kör igång på allvar formaterar vår SEO-konverterare resultatet; vår sida med bästa skrivskills rankar de testade skills som är värda att kombinera med den, däribland SEO Audit för att fånga sådant en översättningsgenomgång ensam inte gör, som trasiga interna länkar mellan språkversioner.

Vanliga frågor

Kan Claude verkligen översätta en hel webbplats, inte bara enskilda sidor?

Ja, men inte som en enda jätteprompt. Det som fungerade för oss var att dela upp sajten på agenter per språk som körs parallellt, var och en med en självständig brief som täcker hela regeluppsättningen: nyckelordslokalisering, tilltalsform, listan över det som aldrig ska översättas och teckengränser. En enda agent som försöker hålla 10 språk i samma kontext tappar konsekvens snabbt; 10 agenter som var och en håller ett språk förblev konsekventa eftersom det var briefen, inte agentens minne, som bar reglerna.

Räcker AI-översättning för SEO, eller behövs en mänsklig genomgång?

För teknisk text och marknadsföringstext kommer en välbriefad Claude-körning så pass nära att en stickprovskontroll av en infödd talare är rätt mängd mänsklig inblandning, inte en fullständig omöversättning. Den SEO-specifika risken är inte grammatik, det är nyckelordsformulering: en agent som översätter bokstavligt i stället för att lokalisera sökfrasen producerar flytande men osökbara sidor. Det är därför regel ett i den här artikeln handlar om sökformulering, inte grammatik.

Vad kostar det att översätta en sajt till flera språk med Claude?

Baserat på vår egen körning: en artikel på 2 500 ord kostar ungefär 120 000–160 000 tokens per språk på Sonnet, och 106 korta kataloginlägg kostar ungefär 150 000–170 000 tokens per språk när de batchas. Över 10 språk landade vår sajtlokalisering totalt på några enstaka dollar i API-kostnad. Den större kostnaden är inte tokens, det är tiden för att sätta upp regeluppsättningen och valideringsgrindarna, vilket du betalar en gång och återanvänder vid varje framtida uppdatering.

Vad är det vanligaste misstaget team gör vid lokalisering med AI?

Att hoppa över validering och lita på agentens egen "klar"-rapport. Vi hittade både buggen med försvunna diakritiska tecken och problemet med en agent som fastnade bara för att vi kontrollerar det översatta resultatet mot källan mekaniskt – antal rubriker, orörda kodblock, teckengränser – i stället för att läsa vad agenten påstår sig ha gjort. Behandla varje översättningskörning som om den behöver samma godkännandegrind som en kodändring: verifiera artefakten, inte rapporten.