Traducción con IA en WordPress: por qué rompe el SEO multilingüe

#Traducción con IA en WordPress: por qué rompe el SEO multilingüe

La tesis principal es correcta. Ese 1 por ciento que falta cae exactamente donde aterriza el coste. Leonardo Losoviz en WP Tavern Jukebox, preguntado por dónde está hoy la traducción por IA frente al trabajo humano, dijo:

“Es tan fácil que todos lo harán. Y cuando todos lo hacen, no estás avanzando, solo estás corriendo para quedarte en el mismo sitio.”

A nivel de frase tiene razón. También está describiendo un mercado en el que la calidad de la traducción en sí ya no separa a un sitio de otro. Lo que los separa ocurre en los campos que el traductor de IA no debería tocar y que, en producción, suele tocar.

Este es un texto polémico contra la lectura “99 por ciento precisa” como éxito. La cifra es verdadera y en gran medida irrelevante. Operar un sitio WordPress multilingüe en 2026 ha pasado de “¿está bien la prosa?” a “¿sobrevive la estructura a la traducción?”.

#Traducción con IA en WordPress multilingüe 2026: TL;DR en 4 puntos

• En WP Tavern Jukebox, Losoviz dice: la IA gestiona el 99 por ciento de la traducción de WordPress con precisión, por una fracción del coste humano. La cifra es real para la prosa.
• Ese 1 por ciento que las herramientas de traducción por IA rompen rutinariamente no está en las frases. Está en los campos que deciden en qué URL vive un artículo y cómo lo indexa Google.
• Ese 1 por ciento es exactamente lo que indexa Google. El 99 por ciento de prosa es lo que los lectores leen una vez que han llegado a una página indexada correctamente. Si la capa de indexación se fragmenta, nadie lee la prosa.
• La cura no es un traductor de frase más inteligente. Es separar los campos técnicos de los campos que el traductor de IA puede editar, más una auditoría breve de diacríticos después de cada pasada multi-archivo.

#Glosario: frontmatter, slug, hreflang y canonical en WordPress

El resto del artículo se apoya en siete conceptos. Si alguno suena raro, es exactamente el campo que el traductor de IA más suele estropear. Para quien nunca ha abierto un archivo de contenido:

• Frontmatter - el bloque de metadatos en lo alto del archivo de artículo, delimitado por ---. Allí viven el título, la descripción, las categorías, la URL canónica, los enlaces a las otras versiones lingüísticas, el slug y decenas de otros campos. El traductor de IA recibe el archivo entero, es decir, el frontmatter y el cuerpo juntos.
• Slug - la cola de la URL del artículo, por ejemplo nis2-dora-wordpress-compliance-2026. Es un identificador de enrutamiento (la dirección en la que la página realmente se abre), no un título para leer.
• force_slug: true - un indicador en el frontmatter que le dice al sistema “usa exactamente este slug como URL, aunque el nombre del archivo sea distinto”.
• URL canónica (canonicalUrl) - un campo del frontmatter que indica a Google cuál es la dirección que debe indexar como autoritativa cuando existen varias variantes.
• Hreflang - el conjunto de enlaces que conecta entre sí las versiones lingüísticas del mismo artículo, para que Google entienda “esta es la traducción alemana de la fuente inglesa”.
• Términos de taxonomía - los valores en categories y tags. Cada uno genera su propia URL, por ejemplo /de/tag/compliance/.
• Mapa de redirecciones - la lista de pares (URL antigua, URL nueva) que evita que los enlaces previamente indexados devuelvan 404 cuando un slug cambia.

Estos campos son invisibles para quien lee la página. Para Google y para la red interna de enlaces son decisivos. En el mercado español, donde la AEPD exige rutas estables a documentos de tratamiento de datos y el ENS pide trazabilidad documental para servicios prestados a la Administración, cada 404 silencioso causado por un cambio de slug entra también en la traza de cumplimiento.

#Cómo la traducción con IA rompe un slug alemán de WordPress: un caso concreto

Un patrón fácil de reproducir con cualquier herramienta de traducción por IA que reciba el archivo entero, contra un árbol típico de contenido Astro o WordPress:

• La versión alemana de un artículo de cumplimiento vive en el archivo algo-compliance-2026.de.md y trae en el frontmatter la entrada slug: nis2-dora-wordpress-Konformität-2026. El traductor escogió el préstamo alemán porque el campo parecía una raíz de frase y la lengua de destino del texto es el alemán. Cambió “compliance” por “Konformität”.
• El resto del clúster sigue enlazando a la versión ASCII, como hacen sus hermanas inglesa, polaca, noruega, española y portuguesa. Cada uno de esos enlaces devuelve 404 porque el router sirve la página en la dirección con umlaut, la que el traductor escribió y a la que force_slug: true da prioridad sobre el nombre del archivo.
• Dos páginas pilar alemanas viven ahora en una URL con ä a la que ninguna otra versión lingüística enlaza. La red interna de enlaces del clúster se fragmenta en la capa de indexación durante todo el tiempo que nadie corra una auditoría estructural, que en la mayoría de los sitios en producción es para siempre.

Si el traductor de IA hubiera metido una frase un poco torpe en el cuerpo, el precio habría sido un suspiro de lector. La misma clase de fallo en el campo slug cuesta meses de señal de enlace interna al clúster, repartidos en una docena de páginas.

Esa es la brecha entre “99 por ciento de precisión” y “0 por ciento roto en la capa que importa”.

#Qué no mide la traducción con IA “99 por ciento precisa”

Cuando Losoviz dice 99 por ciento, habla de fidelidad a nivel de frase. Si el párrafo alemán significa lo que significaba el párrafo inglés. Si la terminología se mantiene coherente a lo largo del post. Si el registro encaja con el público. Los traductores de IA modernos contra una guía de estilo publicada alcanzan, en efecto, el 95 al 99 por ciento en la revisión por hablante nativo. La cifra es real.

Lo que la cifra no mide:

1. Si el campo slug en frontmatter coincide con el nombre del archivo y la convención de enrutamiento.
2. Si el indicador force_slug se activó por una decisión editorial o por una alucinación del traductor.
3. Si la canonicalUrl sigue coincidiendo con el slug después de un cambio de slug.
4. Si los valores en categories y tags coinciden con las URLs de categoría y etiqueta que usa el resto del sitio. Un blog alemán puede derivar hacia /de/tag/Konformität/ mientras todas las demás versiones usan un término ASCII, creando una página de etiqueta a la que ninguna otra versión enlaza.
5. Si las URLs hermanas de hreflang en el layout resuelven realmente.
6. Si el mapa de redirecciones tiene una entrada 301 desde la URL anterior tras el cambio de slug.
7. Si existen 301s desde una URL publicada e indexada anteriormente cuando el traductor cambia el patrón del slug en una pasada nueva.

Ninguno de estos siete puntos es a nivel de frase. Todos son estructurales. El traductor de IA puede influir en cada uno porque cada uno está expuesto en el frontmatter, que el traductor lee y reescribe junto con el cuerpo.

#Por qué un fallo de slug por IA cuesta más que un fallo de frase

Una frase mala en un párrafo traducido la lee un usuario, posiblemente queda calificada como baja por la evaluación de calidad de una AI Overview y, en el peor de los casos, contribuye a una erosión lenta de confianza. Un campo slug malo es un cambio de enrutamiento que dura hasta que alguien corre una auditoría de enlaces. El coste se paga en Google Search Console durante meses, no en una sesión de lectura.

Para un clúster de pilares con cross-links en versiones lingüísticas no inglesas, las consecuencias escalan con la densidad de cross-link. Un único slug de pilar mal traducido significa que cualquier otro artículo del clúster que apuntaba a la URL canónica devuelve ahora 404. Google ve un grafo fragmentado: una página pilar indexada en una URL, decenas de enlaces internos entrantes apuntando a una URL hermana que nadie sirve. El PageRank se fragmenta. La autoridad temática se diluye entre la dirección real y la fantasma. La prosa visible al usuario sigue estando bien, que es justo el problema: el síntoma es invisible desde la página renderizada.

Esa es la brecha entre “99 por ciento de precisión” y “0 por ciento roto en la capa que importa”.

#Cómo funciona el pipeline de traducción con IA en WordPress y dónde falla

El mecanismo es banal y conocido para cualquiera que haya escrito un prompt de traducción que toque el frontmatter:

1. Al traductor se le muestra el archivo completo: frontmatter más cuerpo.
2. El system prompt dice “traduce todas las cadenas visibles al usuario al idioma de destino”.
3. Al traductor se le dice (correctamente) que traduzca title, description, seo.title, preguntas y respuestas del FAQ y el texto del cuerpo.
4. Al traductor se le dice (correctamente) que no traduzca wpId, pubDate, heroImage.
5. El campo slug cae en una zona gris. El traductor ve que el slug tiene forma alemana, porque el archivo usa slugs en sentence-case que parecen raíces de frase. Concluye que “compliance” en un slug alemán es un préstamo extranjero y debería ser “Konformität”, porque la lengua de destino de la prosa es el alemán. Hace lo aparentemente correcto. Nadie le dijo al traductor que el campo slug es un identificador de enrutamiento, no una cadena visible al usuario.

No hay manera de arreglar esto con un traductor a nivel de frase más inteligente. La solución es retirar el campo de la entrada del traductor. En la herramienta, el frontmatter debería dividirse en campos en los que el traductor de IA puede escribir y campos de solo lectura. Los campos slug, force_slug, canonicalUrl, redirect_from y términos de taxonomía pertenecen al conjunto de solo lectura.

En un sistema con un esquema decente esto es una inversión de ingeniería única. En una herramienta típica que pega el archivo completo en el prompt, que es lo que son la mayoría de las herramientas de traducción por IA en producción, es estructuralmente imposible.

#Cómo proteger un WordPress multilingüe de la deriva de slug por IA

Una vez aislados los campos estructurales, el riesgo residual es que los diacríticos se filtren a otros sitios: a enlaces en el cuerpo, a fuentes de structured data, a referencias hreflang. La defensa es un script de auditoría de una pantalla, ejecutado antes de publicar y por cada versión lingüística. La regla es clara: un diacrítico Latin Extended que aparece en un campo URL después de una pasada de traducción es casi siempre una regresión. Cada versión lingüística tiene su propio conjunto de reglas - la variante noruega (ø, æ, å) admite más superficie de diacrítico que la alemana, la variante española (á, é, í, ó, ú, ñ) es distinta, la clase portuguesa ç/ã/õ otra más.

Esto no es glamour de ingeniería. Es un regex por versión lingüística y una puerta de build que hace fallar el despliegue cuando el recuento de diacríticos en campos URL sube por encima de una baseline reconocida como buena. La razón por la que la mayoría de los sitios WordPress multilingües en producción no tienen esta puerta es prosaica: el síntoma es invisible desde el dashboard editorial. En contextos en los que la AEPD audita la disponibilidad de los textos de información al usuario, o donde el ENS exige rutas estables para los servicios prestados a la Administración, este síntoma silencioso pasa a ser además una observación de cumplimiento.

#WPML AI, TranslatePress AI, Weglot, Gato AI Translations: el mismo problema estructural

La página de producto de Gato AI Translations describe el valor como “traduce cualquier tipo de post, taxonomía, custom field y string con IA”. Es correcto y útil. También implica que los custom fields están dentro del alcance, lo que significa que los campos equivalentes a slug en custom post types y los campos de metadatos que contienen URLs están expuestos a la misma clase de fallo. La misma forma se aplica a WPML AI Translation, TranslatePress AI y Weglot AI: los pipelines de producción son de entrada de archivo completo por defecto. Ninguno de ellos entrega una auditoría de integridad estructural como parte del producto.

La lógica competitiva que describe Losoviz (“cuando todos lo hacen, no estás avanzando”) subestima el riesgo. Cuando todos lo hacen y nadie corre la auditoría estructural, el sitio multilingüe WordPress promedio se aleja silenciosamente de la integridad en la capa de indexación durante años. La prosa visible al usuario sigue siendo buena. El grafo se pudre.

#4 pasos para evitar que la traducción con IA destroce el SEO de WordPress multilingüe

La respuesta mínima viable para cualquier equipo que gestione más de una versión lingüística con traducción por IA:

1. Proteja los campos estructurales. Slug, indicador force-slug, URLs canónicas, URLs de origen de redirección, términos de taxonomía y referencias hermanas de hreflang deberían escribirse desde el pipeline de ingeniería, no por el traductor. Si la herramienta de traducción no soporta un conjunto de campos de solo lectura, trate el frontmatter como separado del cuerpo en su workflow: traduzca el cuerpo en la herramienta de IA y deje el frontmatter intacto.
2. Añada una auditoría de diacríticos a la puerta de build. Un único regex por versión lingüística, ejecutado en cada pull request que toque archivos multilingües, atrapa la clase entera antes del despliegue.
3. Trate cada cambio de slug como un evento de redirección. Cualquier cambio en un campo slug, deliberado o accidental, exige un 301 correspondiente en su mapa de redirecciones. Si el build no lo impone con un fallo en entrada de redirección ausente, los cambios de slug venidos de traducción por IA terminarán por mandar URLs indexadas a 404.
4. Mida los fallos estructurales, no solo la precisión de la prosa. Un pipeline que entrega un 99 por ciento de precisión de frase y un 5 por ciento de deriva de slug entre versiones es peor en la única métrica que importa que un pipeline que entrega un 95 por ciento de precisión de frase y cero deriva de slug.

#Traducción con IA en WordPress 2026: dónde vive realmente el coste

Losoviz tiene razón en que la traducción por IA ha vuelto la precisión a nivel de frase un bien común y en que “correr para quedarse en el mismo sitio” es la nueva línea base competitiva. La polémica es que la tasa del 99 por ciento se está leyendo como un techo de calidad, cuando el techo real es la integridad estructural en la capa de enrutamiento e indexación. Todo el coste vive en ese 1 por ciento. Y ese 1 por ciento es higiene operativa, no mejor IA.

Para la agencia o el equipo interno que gestiona un sitio WordPress multilingüe, este es el momento de invertir en la capa estructural, porque el coste de la traducción por IA propiamente dicha ha caído lo suficiente como para que el coste relativo del QA estructural sea ahora la mayor partida del presupuesto de operaciones multilingües. El precio de este tipo de auditoría es individual y depende del tamaño del clúster. El siguiente hueco en el deck comercial de un proveedor es “traducción por IA más auditoría de integridad estructural”, no “traducción por IA, 99 por ciento precisa”.

#Fuentes

• Leonardo Losoviz en WP Tavern Jukebox (transcripción vía WP Tavern)
• Página de producto Gato AI Translations
• WPML AI Translation, TranslatePress AI, Weglot AI: páginas de herramientas en producción
• Orientaciones del W3C sobre diseño de URL entre versiones lingüísticas

#Relacionados

• Servicios GEO y LLMO
• WordPress headless en Astro
• Cloudflare edge para WordPress y WooCommerce