Claude como traductor SEO: 4.500 páginas, 10 idiomas

Pedimos presupuesto a tres agencias para localizar skillproof.dev a 10 idiomas europeos. Las cifras iban de 14.000 a 22.000 dólares y de seis a diez semanas, sobre todo porque el sitio no es estático: más de 30 artículos de blog, 106 fichas de skills en el catálogo que cambian de veredicto cada vez que las volvemos a testear, páginas de categoría y cada cadena de texto de la interfaz. Una agencia cotiza eso como un proyecto puntual. Nosotros necesitábamos que aguantara un martes cualquiera en el que publicamos tres reseñas nuevas y editamos dos antiguas.

Así que no contratamos a ninguna agencia. Pusimos a trabajar agentes de Claude en paralelo, uno por idioma, con el mismo set de instrucciones, y localizamos unas 4.500 páginas en más o menos un día. Este artículo es ese set de instrucciones: las seis reglas que marcan la diferencia entre un texto que suena a traducción y otro que parece escrito por alguien que trabaja en ese mercado, más los costes reales y los dos fallos que tuvimos que arreglar antes de publicar.

El problema de traducir un sitio vivo

La traducción automática resolvió el problema mecánico hace años. Google Translate te da un alemán gramaticalmente correcto para cualquier frase en inglés que le pegues. El problema nunca fue la gramática. Son tres cosas que las herramientas de traducción no tocan:

Las palabras clave SEO no se traducen literalmente. «How to install Claude skills» no se convierte en una búsqueda alemana pasándola por un diccionario; los desarrolladores alemanes buscan «Claude Skills installieren», con el verbo al final y el nombre del producto intacto. Si te equivocas aquí, tu página en alemán queda fluida e invisible.

El registro es una decisión de mercado, no una regla del idioma. El alemán tiene «du» y «Sie», el francés tiene «tu» y «vous», y elegir uno u otro para una marca de herramientas de desarrollo es una cuestión de posicionamiento, no de gramática. Un traductor de agencia sin contexto de marca tiende al formal por defecto, y eso suena rígido al lado del sitio alemán de Linear o del de Stripe.

Y un sitio no es un documento. Son 4.500 páginas que cambian cada semana. Una entrega de traducción puntual queda obsoleta en un mes, y volver a explicarle todo a una agencia cada vez que actualizas algo no es un flujo de trabajo, es una suscripción que no quieres pagar.

Convertimos nuestro método de trabajo en una skill, seo-translator, que vive en nuestro repositorio de skills: las mismas instrucciones que describe este artículo, listas para que las uses gratis en tu propio sitio.

Cómo lo montamos

El mecanismo es simple: un agente de Claude por idioma de destino, cada uno con el contenido completo de origen y el mismo conjunto de reglas, trabajando en paralelo en vez de en fila. Diez idiomas significan diez agentes trabajando a la vez, en lugar de un traductor abriéndose paso por una cola durante dos meses.

Cada agente recibió un brief autosuficiente: el markdown de origen, la lista de lo que nunca se traduce, el registro por defecto de ese mercado y los límites de caracteres para el título y la meta descripción de esa página. Ningún agente necesitó preguntarnos nada a mitad de proceso, algo que resultó importar más de lo que esperábamos — lo veremos más abajo.

Las seis reglas

1. Palabras clave como las busca de verdad el mercado

Cada artículo y cada ficha de skill lleva una palabra clave objetivo. La instrucción no es «traduce la palabra clave», es «averigua cómo formulan esta búsqueda los desarrolladores de ese mercado». Para nuestra guía de «cómo instalar skills de Claude», la traducción literal al alemán es correcta y también inútil. Lo que la gente teclea es «Claude Skills installieren». Lo mismo en francés: no es una traducción de manual, es «installer les skills Claude», que es como lo dicen de verdad los blogs de desarrolladores franceses. Hicimos que los agentes contrastaran cada término con cómo aparece en foros de desarrolladores y sitios de documentación en ese idioma antes de darlo por bueno, en vez de limitarse a pasar la palabra clave en inglés por un diccionario.

2. Registro por mercado, decidido de antemano

No dejamos que cada agente adivinara un tono. Fijamos una tabla y todos los agentes la siguieron:

Mercado	Registro	Referencia
Alemán (de)	du	Linear, Vercel
Francés (fr)	vous	Stripe, Notion
Español (es)	tú	La mayoría de sitios de herramientas dev
Italiano (it)	tu	Convención informal en dev
Portugués (pt)	você	Norma habitual en herramientas dev brasileñas
Neerlandés (nl)	je	Estándar en SaaS
Polaco (pl)	formal (evitando Pan/Pani, con formulaciones neutras)	Convención en SaaS B2B
Japonés (ja)	です/ます, sin keigo	Estándar de cortesía empresarial
Coreano (ko)	해요체	Estándar en SaaS, no el formal 합쇼체
Sueco (sv)	du	Universal en sueco, incluso en B2B

El par alemán-francés es el que más hace tropezar a la traducción automática por defecto, porque ambos tienden al formal, y nuestras dos marcas de referencia demuestran que es una decisión real de mercado y no un capricho de estilo.

3. Una lista estricta de lo que nunca se traduce

Todos los agentes recibieron la misma lista de exclusión, comprobada antes de aceptar cualquier salida: bloques de código y código en línea, comandos de CLI, nombres de producto y de marca (Claude, Claude Code, SkillProof, Anthropic), rutas de archivo y cualquier token {placeholder} en cadenas de interfaz. Suena obvio hasta que ves una primera traducción convertir npm install en una frase verbal traducida o renombrar SKILL.md sin que nadie se dé cuenta. Lo tratamos como una puerta de validación, no como una sugerencia: cualquier salida con un bloque de código traducido o un placeholder alterado fallaba automáticamente y se repetía.

4. El pase anti-IA

El primer borrador de cualquier traducción hecha por un LLM arrastra señales delatoras: calcos (estructura de frase inglesa vestida con palabras del idioma de destino), frases hechas de IA traducidas tal cual («en el vertiginoso mundo actual» tiene equivalentes igual de cansados en cada idioma), y una planitud que un lector nativo detecta en un solo párrafo. Hicimos una segunda pasada dedicada, por idioma, cuyo único trabajo era cazar esto: reestructurar frases que claramente eran orden de palabras inglés disfrazado de vocabulario alemán, cambiar el relleno traducido por cómo abriría de verdad ese párrafo un redactor técnico nativo. Esta pasada es la razón por la que el resultado suena a alguien que escribe en ese mercado y no a un documento bien traducido.

5. Disciplina con los tokens

Esto es lo que hace que todo salga a cuenta, no solo que sea posible. Una sola pasada por idioma, nada de borrador-revisión-pulido. Nada de repetir el texto de origen antes de traducirlo, una costumbre que dobla el gasto de tokens sin ganar nada en calidad. Y procesamiento por lotes: las fichas del catálogo se traducen en tandas en vez de una llamada a la API por ficha, porque el coste fijo de cada llamada se nota rápido cuando son 106 fichas cortas.

6. Límites de caracteres por idioma, no dados por hechos

Los 60 caracteres para el title y los 155 para la meta descripción son una guía pensada para el inglés que no aguanta en alemán, donde los sustantivos compuestos se alargan, ni en japonés, donde contar caracteres significa algo completamente distinto que en alfabetos latinos. Le dimos a cada agente el límite como una restricción dura, comprobada sobre la cadena final ya traducida y no sobre la longitud del inglés de origen, así los títulos en alemán no se disparaban por encima de 60 solo porque el sustantivo alemán para «traductor» sea incómodamente largo.

Lo que costó de verdad

Registramos el gasto de tokens de toda la tanda. Son cifras reales de nuestro propio uso de Sonnet, no estimaciones:

Tipo de contenido	Tokens por idioma	Notas
Artículo de blog de ~2.500 palabras	120.000–160.000	Origen + traducción + pase anti-IA
106 fichas de skill del catálogo (por lotes)	150.000–170.000	Fichas cortas, pero son 106 y se nota
Cadenas de categoría e interfaz	Menos de 20.000	Pequeño, mayormente estático

En los 10 idiomas, localizar todo el sitio nos costó unos pocos dólares en API, no los más de 14.000 dólares que nos cotizaron por una entrega más lenta y que además se queda obsoleta. Toda la tanda —más de 30 artículos, 106 fichas, páginas de categoría y cadenas de interfaz, en 10 idiomas— llevó cerca de un día de agentes trabajando en paralelo, la mayor parte sin supervisión una vez listos los briefs. Ese es el número que cambia de verdad el cálculo: no es que la traducción con IA sea más barata que una agencia, es que sale tan barata que puedes repetirla cada vez que cambia el contenido de origen, algo que una entrega puntual de agencia nunca podrá ofrecer.

Lo que salió mal

Hubo dos fallos que merecía la pena pillar antes de publicar, y ninguno de los dos habría salido a la luz sin validación.

El primero fue agentes que reportaban «esperando» en vez de producir nada, normalmente porque el brief hacía referencia a algo fuera del contexto propio del agente, tipo «usa la misma formulación que la versión alemana» en un agente que no tenía acceso a esa salida. La solución fue hacer que cada brief fuera completamente autosuficiente: nada de referencias cruzadas entre agentes, nada de «comprueba con la otra tanda», todo lo que el agente necesitaba para acabar la tarea incluido desde el principio.

El segundo fue un incidente que se comió los acentos en una tanda de fichas de catálogo en polaco: un paso de formateo en algún punto del pipeline eliminó silenciosamente los diacríticos, y el resultado se veía bien en una terminal pero estaba mal en la página. Lo detectamos porque validamos contando, no leyendo los informes de los agentes: cada archivo traducido se comprueba contra el original en número de caracteres razonable, número de encabezados y un diff de los tokens que debían quedar intactos (bloques de código, placeholders, nombres de producto). Que un agente te diga «traducción completa» no es una prueba. Un archivo con el mismo número de encabezados que el original, los mismos bloques de código sin tocar y un título dentro del límite de caracteres del mercado, eso sí es una prueba.

Las etiquetas hreflang son la parte que hace que 10 versiones de idioma funcionen como un solo sitio indexable en vez de diez sitios compitiendo entre sí. Cada versión de idioma necesita enlaces hreflang recíprocos que apunten a todas las demás versiones y a sí misma, o los buscadores posicionarán tranquilamente la página en el idioma equivocado para una búsqueda. Es mecánico en cuanto tienes la estructura de URLs definida, pero también es el paso que se salta la mayoría de proyectos de traducción caseros, y merece la pena hacerlo bien antes de publicar tu primera página localizada. Nuestra guía de instalación cubre la parte de instalar la skill si quieres montar esto como un proceso repetible y no como un script de un solo uso.

Lo que le diríamos a un equipo que empieza el lunes

No traduzcas todo el sitio el primer día. Elige tus dos o tres páginas con más tráfico, pásalas por los 10 idiomas y contrasta el resultado con un hablante nativo antes de escalar al resto. Las reglas de arriba son las que aprendimos equivocándonos primero; si te saltas ese paso, las vas a reaprender en 4.500 páginas en vez de en tres.

Escribe la tabla de registro antes de traducir una sola palabra. Es una decisión de negocio, no lingüística, y sale mucho más barato discutirla al principio que arreglarla después con 106 fichas usando el pronombre equivocado.

Valida contando, no preguntando. Si tu pipeline no puede decirte, de forma mecánica, que un archivo traducido tiene el número correcto de encabezados y los bloques de código intactos, no tienes un pipeline de traducción, tienes una esperanza.

Y si haces esto para un sitio con mucho contenido en vez de un puñado de páginas estáticas, la misma disciplina que mantiene coherente una estrategia de contenidos a lo largo de decenas de artículos es la que mantiene coherente una tanda de traducción a lo largo de decenas de idiomas: un único set de instrucciones, aplicado de forma consistente, comprobado contra el original cada vez. Contamos cómo nos exigimos ese mismo nivel en cómo testeamos las skills de Claude.

Si quieres probar el paso de localización de palabras clave en una sola página antes de lanzarte a la tanda completa, nuestro conversor SEO te da el formato de salida; nuestra página de mejores skills de escritura clasifica las skills testeadas que merece la pena combinar con esto, incluyendo SEO Audit para pillar lo que un pase de traducción por sí solo no coge, como enlaces internos rotos entre versiones de idioma.

Preguntas frecuentes

¿Puede Claude traducir de verdad un sitio web entero, no solo páginas sueltas?

Sí, pero no como un único prompt gigante. Lo que nos funcionó fue partir el sitio en agentes por idioma trabajando en paralelo, cada uno con un brief autosuficiente que cubría todo el set de reglas: localización de palabras clave, registro, la lista de lo que nunca se traduce y los límites de caracteres. Un solo agente intentando sostener 10 idiomas en un mismo contexto pierde consistencia rápido; 10 agentes, cada uno con un idioma, se mantuvieron consistentes porque las reglas las llevaba el brief, no la memoria del agente.

¿La traducción con IA es suficientemente buena para SEO, o hace falta una pasada humana?

Para contenido técnico y de marketing, una tanda de Claude bien preparada se acerca lo suficiente como para que una revisión puntual de un hablante nativo sea la cantidad justa de intervención humana, no una retraducción completa. El riesgo específico de SEO no es la gramática, es la formulación de la palabra clave: un agente que traduce literalmente en vez de localizar la búsqueda produce páginas fluidas e imposibles de encontrar. Por eso la primera regla de este artículo habla de cómo se busca, no de gramática.

¿Cuánto cuesta traducir un sitio a varios idiomas con Claude?

Según nuestra propia tanda: un artículo de 2.500 palabras cuesta unos 120.000–160.000 tokens por idioma en Sonnet, y 106 fichas cortas de catálogo cuestan unos 150.000–170.000 tokens por idioma procesadas por lotes. En los 10 idiomas, localizar todo el sitio nos costó unos pocos dólares en total de gasto de API. El coste grande no son los tokens, es el tiempo de preparar el set de reglas y las puertas de validación, que pagas una vez y reutilizas en cada actualización futura.

¿Cuál es el error más grande que cometen los equipos al localizar con IA?

Saltarse la validación y fiarse del informe de «hecho» del propio agente. Solo detectamos el bug de los acentos y el problema del agente atascado porque comprobamos la salida traducida contra el original de forma mecánica —número de encabezados, bloques de código intactos, límites de caracteres— en vez de leer lo que el agente dice que hizo. Trata cada tanda de traducción con la misma puerta de aceptación que le aplicarías a un cambio de código: verifica el artefacto, no el informe.