Claude come traduttore SEO: 4.500 pagine, 10 lingue

Tre agenzie ci hanno fatto un preventivo per localizzare skillproof.dev in 10 lingue europee. Le cifre andavano da 14.000 a 22.000 dollari, con tempi da sei a dieci settimane, soprattutto perché il sito non è statico: oltre 30 articoli del blog, 106 schede skill nel catalogo che cambiano verdetto ogni volta che le ritestiamo, pagine di categoria e ogni stringa UI della shell. Un'agenzia lo valuta come un progetto una tantum. A noi serviva che sopravvivesse a un martedì in cui pubblichiamo tre nuove recensioni di skill e ne aggiorniamo altre due.

Quindi non abbiamo assunto un'agenzia. Abbiamo fatto girare agenti Claude in parallelo, uno per lingua, con lo stesso set di istruzioni, e abbiamo localizzato circa 4.500 pagine in un giorno. Questo articolo è quel set di istruzioni: le sei regole che fanno la differenza tra un testo che si legge come una traduzione e uno che sembra scritto da chi lavora davvero in quel mercato, più i costi reali e i due modi in cui il sistema si è rotto prima che lo sistemassimo.

Il problema di tradurre un sito vivo

La traduzione automatica ha risolto il problema meccanico anni fa. Google Translate ti restituisce un tedesco grammaticalmente corretto per qualsiasi frase inglese tu ci incolli. Il problema non è mai stato la grammatica. Sono tre cose che gli strumenti di traduzione non toccano:

Le keyword SEO non si traducono parola per parola. "How to install Claude skills" non diventa una query di ricerca tedesca passando per un dizionario; gli sviluppatori tedeschi cercano "Claude Skills installieren", verbo in fondo, nome del prodotto intatto. Sbagliare questo passaggio significa avere una pagina tedesca fluente e invisibile.

Il registro è una decisione di mercato, non una regola linguistica. Il tedesco ha "du" e "Sie", il francese ha "tu" e "vous", e quale dei due usa un brand di strumenti per sviluppatori è una scelta di posizionamento, non di grammatica. Un traduttore d'agenzia senza contesto di brand punta di default sul formale, che risulta rigido accanto al sito tedesco di Linear o a quello di Stripe.

E un sito non è un documento. Sono 4.500 pagine che cambiano ogni settimana. Una consegna di traduzione una tantum è già superata dopo un mese, e ribriefare un'agenzia a ogni aggiornamento non è un flusso di lavoro, è un abbonamento che non vuoi pagare.

Abbiamo trasformato il nostro metodo di lavoro in una skill, seo-translator, e vive nel nostro repository di skill — le stesse istruzioni descritte in questo articolo, libere da usare sul tuo sito.

Come l'abbiamo impostato

Il meccanismo è semplice: un agente Claude per ogni lingua di destinazione, ciascuno con il contenuto sorgente completo e lo stesso set di regole, in esecuzione in parallelo invece che in sequenza. Dieci lingue significano dieci agenti al lavoro contemporaneamente, invece di un traduttore che smaltisce una coda per due mesi.

Ogni agente ha ricevuto un brief autosufficiente: il markdown sorgente, la lista degli elementi da non tradurre, il registro predefinito per quel mercato e i limiti di caratteri per titolo e meta description di quella pagina. Nessun agente ha dovuto chiederci nulla a metà lavoro, un dettaglio che si è rivelato più importante del previsto — ne parliamo più avanti.

Le sei regole

1. Le keyword come le cerca davvero il mercato

Ogni articolo e ogni scheda skill porta una keyword target. L'istruzione non è "traduci la keyword", è "trova come gli sviluppatori di questo mercato formulano questa ricerca". Per la nostra guida "how to install Claude skills", la traduzione tedesca letterale è grammaticalmente corretta e inutile. La query digitata davvero è "Claude Skills installieren". Lo stesso vale per il francese: non una traduzione da manuale ma "installer les skills Claude", che rispecchia come i blog di sviluppatori francesi la formulano davvero. Abbiamo fatto verificare agli agenti la formulazione confrontandola con come il termine compare nei forum per sviluppatori e nei siti di documentazione di quella lingua, prima di darla per buona, invece di limitarsi a far passare la keyword inglese per un dizionario.

2. Registro per mercato, deciso in anticipo

Non abbiamo lasciato che ogni agente indovinasse il tono. Abbiamo fissato una tabella e ogni agente l'ha seguita:

Mercato	Registro	Riferimento
Tedesco (de)	du	Linear, Vercel
Francese (fr)	vous	Stripe, Notion
Spagnolo (es)	tú	La maggior parte dei siti dev-tool
Italiano (it)	tu	Convenzione informale per dev tool
Portoghese (pt)	você	Norma dev-tool brasiliana
Olandese (nl)	je	Standard per il SaaS
Polacco (pl)	formale (si evita Pan/Pani, fraseggio neutro)	Convenzione B2B SaaS
Giapponese (ja)	です/ます, senza keigo	Standard business-cortese
Coreano (ko)	해요체	Standard SaaS, non il formale 합쇼체
Svedese (sv)	du	Universale in svedese, anche nel B2B

La coppia tedesco-francese è quella che manda più in crisi la traduzione automatica di default, perché entrambe le lingue di default virano sul formale, e i nostri brand di riferimento dimostrano che è una scelta di mercato reale, non un vezzo stilistico.

3. Una lista rigida di elementi da non tradurre

Ogni agente ha ricevuto la stessa lista di esclusione, verificata prima di accettare l'output: blocchi di codice e codice inline, comandi CLI, nomi di prodotto e di brand (Claude, Claude Code, SkillProof, Anthropic), percorsi file e qualsiasi token {placeholder} nelle stringhe UI. Sembra ovvio finché non vedi una prima bozza tradurre npm install come una locuzione verbale tradotta o rinominare silenziosamente SKILL.md. L'abbiamo trattata come un gate di validazione, non un suggerimento: qualsiasi output con un blocco di codice tradotto o un placeholder alterato falliva automaticamente e veniva rieseguito.

4. Il passaggio anti-AI

La prima bozza di qualsiasi traduzione fatta da un LLM porta con sé dei segnali: calchi (struttura della frase inglese vestita di parole della lingua di arrivo), frasi fatte da AI tradotte pari pari (l'equivalente di "in today's fast-paced world" esiste in ogni lingua, ed è altrettanto stanco), e una piattezza che un lettore madrelingua nota entro un paragrafo. Abbiamo fatto girare un secondo passaggio dedicato per ogni lingua, con l'unico compito di scovare questi difetti — ristrutturare frasi che erano chiaramente ordine delle parole inglese vestito di vocabolario tedesco, sostituire il riempitivo tradotto con come un copywriter tecnico madrelingua aprirebbe davvero quel paragrafo. È questo passaggio a far leggere il risultato come scritto da chi lavora in quel mercato, non come un documento ben tradotto.

5. Disciplina sui token

È questo che rende l'intera operazione economica, non solo possibile. Un solo passaggio per lingua, non bozza-poi-revisione-poi-rifinitura. Niente ripetizione del testo sorgente prima di tradurlo — un'abitudine che raddoppia silenziosamente la spesa in token senza alcun guadagno di qualità. E lavorazione a batch: le schede del catalogo si traducono in blocchi invece che con una chiamata API per scheda, perché l'overhead per chiamata su 106 schede brevi si accumula in fretta.

6. Limiti di caratteri imposti per lingua, non dati per scontati

Title tag a 60 caratteri e meta description a 155 sono una linea guida pensata per l'inglese, che non regge più in tedesco, dove i sostantivi composti si allungano, o in giapponese, dove il conteggio dei caratteri significa qualcosa di completamente diverso rispetto agli alfabeti latini. Abbiamo dato a ogni agente il limite come vincolo rigido verificato sulla stringa effettivamente resa, non sulla lunghezza del testo sorgente inglese, così i titoli tedeschi non sforavano i 60 caratteri solo perché il sostantivo tedesco per "traduttore" è scomodamente lungo.

Quanto è costato davvero

Abbiamo tracciato la spesa in token durante l'intera esecuzione. Sono numeri reali del nostro utilizzo di Sonnet, non stime:

Tipo di contenuto	Token per lingua	Note
Articolo del blog di ~2.500 parole	120.000–160.000	Sorgente + traduzione + passaggio anti-AI
106 schede skill del catalogo (a batch)	150.000–170.000	Schede brevi, ma sono 106 e la somma si sente
Stringhe di categoria e UI	Sotto i 20.000	Piccole, per lo più statiche

Su 10 lingue, la localizzazione dell'intero sito è costata pochi dollari di spesa API, non i 14.000 e passa dollari che ci erano stati preventivati per una consegna più lenta e già superata al momento della consegna. L'intera esecuzione — oltre 30 articoli, 106 schede, pagine di categoria e stringhe UI, su 10 lingue — ha richiesto circa un giorno di agenti in parallelo, per lo più senza supervisione una volta impostati i brief. È questo il numero che cambia davvero i calcoli: non è che la traduzione AI costi meno di un'agenzia, è che costa abbastanza poco da poterla rieseguire ogni volta che il contenuto sorgente cambia, cosa che una consegna d'agenzia una tantum non potrà mai fare.

Cosa è andato storto

Due modalità di fallimento valeva la pena intercettare prima della pubblicazione, e nessuna delle due sarebbe emersa senza validazione.

La prima erano agenti che segnalavano "in attesa" invece di produrre output — di solito perché un brief faceva riferimento a qualcosa fuori dal contesto dell'agente stesso, tipo "usa la stessa formulazione della versione tedesca" dato a un agente che non aveva accesso all'output tedesco. La soluzione è stata rendere ogni brief completamente autosufficiente: nessun riferimento incrociato tra agenti, nessun "controlla con l'altra esecuzione", tutto ciò che serviva all'agente per finire il compito incluso fin dall'inizio.

La seconda è stata un incidente di perdita degli accenti su un batch di schede del catalogo in polacco, dove uno step di formattazione da qualche parte nella pipeline eliminava silenziosamente i segni diacritici su un output che sembrava a posto nel terminale ma era sbagliato sulla pagina. L'abbiamo scoperto perché validiamo contando, non leggendo i report degli agenti: ogni file tradotto viene controllato contro il sorgente per la coerenza del conteggio caratteri, il numero di titoli e un diff dei token non tradotti (blocchi di codice, placeholder, nomi di prodotto) che dovevano restare intatti. Un agente che ti dice "traduzione completata" non è una prova. Un file che ha lo stesso numero di titoli del sorgente, gli stessi blocchi di codice intatti e un titolo sotto il limite di caratteri del mercato è una prova.

I tag hreflang sono la parte che fa funzionare 10 versioni linguistiche come un unico sito indicizzabile, invece che come dieci siti in competizione tra loro. Ogni versione linguistica ha bisogno di link hreflang reciproci che puntano a ogni altra versione più a se stessa, altrimenti i motori di ricerca posizioneranno volentieri la pagina nella lingua sbagliata per una query. È un lavoro meccanico una volta impostata la struttura degli URL, ma è anche il passaggio che la maggior parte dei progetti di traduzione fai-da-te salta, ed è meglio farlo bene prima di pubblicare la tua prima pagina localizzata. La nostra guida all'installazione copre il lato installazione della skill se stai impostando tutto questo come una skill ripetibile invece che come uno script usa e getta.

Cosa diremmo a un team che parte lunedì

Non tradurre tutto il sito il primo giorno. Scegli le tue due o tre pagine con più traffico, falle passare in tutte e 10 le lingue e controlla l'output con un madrelingua prima di scalare al resto. Le regole qui sopra sono quelle che abbiamo imparato sbagliandole per prime; salta questo passaggio e le reimparerai su 4.500 pagine invece che su tre.

Scrivi la tabella dei registri prima di tradurre anche solo una parola. È una decisione di business, non linguistica, ed è molto più economico discuterne all'inizio che sistemarla dopo che 106 schede hanno usato il pronome sbagliato.

Valida contando, non chiedendo. Se la tua pipeline non riesce a dirti, meccanicamente, che un file tradotto ha il numero giusto di titoli e i blocchi di codice intatti, non hai una pipeline di traduzione, hai una speranza.

E se lo stai facendo per un sito ricco di contenuti invece che per una manciata di pagine statiche, la stessa disciplina che tiene coerente una content strategy su decine di articoli è ciò che tiene coerente un'esecuzione di traduzione su decine di lingue: un solo set di istruzioni, applicato con costanza, verificato contro il sorgente ogni volta. Abbiamo raccontato come manteniamo noi stessi allo stesso standard in come testiamo le skill di Claude.

Se vuoi provare il passaggio di localizzazione delle keyword su una singola pagina prima di impegnarti in un'esecuzione completa, il nostro convertitore SEO formatterà l'output; la nostra pagina delle migliori skill di scrittura classifica le skill testate da abbinarci, inclusa SEO Audit per intercettare quello che un solo passaggio di traduzione non coglie, come i link interni rotti tra le versioni linguistiche.

FAQ

Claude può davvero tradurre un intero sito web, non solo singole pagine?

Sì, ma non come un unico prompt gigante. Quello che ha funzionato per noi è stato dividere il sito in agenti per lingua in esecuzione parallela, ciascuno con un brief autosufficiente che copre l'intero set di regole: localizzazione delle keyword, registro, lista degli elementi da non tradurre e limiti di caratteri. Un singolo agente che prova a tenere 10 lingue in un solo contesto perde coerenza in fretta; 10 agenti, ciascuno con una sola lingua, sono rimasti coerenti perché a portare le regole era il brief, non la memoria dell'agente.

La traduzione AI è abbastanza buona per la SEO, o serve comunque un passaggio umano?

Per contenuti tecnici e di marketing, un'esecuzione Claude ben briefata si avvicina abbastanza da rendere sufficiente un controllo a campione di un madrelingua, non una ritraduzione completa. Il rischio specifico della SEO non è la grammatica, è la formulazione delle keyword: un agente che traduce alla lettera invece di localizzare la query di ricerca produce pagine fluenti e introvabili. Per questo la prima regola di questo articolo riguarda la formulazione delle ricerche, non la grammatica.

Quanto costa tradurre un sito in più lingue con Claude?

In base alla nostra esecuzione: un articolo di 2.500 parole costa circa 120.000–160.000 token per lingua su Sonnet, e 106 schede brevi del catalogo costano circa 150.000–170.000 token per lingua in batch. Su 10 lingue, la localizzazione dell'intero sito ci è costata pochi dollari in totale di spesa API. Il costo più grande non sono i token, è il tempo di impostazione del set di regole e dei gate di validazione, che paghi una volta e riusi a ogni aggiornamento futuro.

Qual è l'errore più grande che i team commettono localizzando con l'AI?

Saltare la validazione e fidarsi del report "fatto" dell'agente stesso. Abbiamo scoperto un bug di perdita degli accenti e un problema di agente bloccato solo perché controlliamo l'output tradotto contro il sorgente in modo meccanico — conteggio dei titoli, blocchi di codice intatti, limiti di caratteri — invece di leggere cosa l'agente dichiara di aver fatto. Tratta ogni esecuzione di traduzione come se avesse bisogno dello stesso gate di accettazione che applicheresti a una modifica di codice: verifica l'artefatto, non il report.