WordPress en varios idiomas: cómo ayudar a Google y a la IA a encontrar la versión correcta

Tienes tu WordPress en varios idiomas. Has traducido el contenido, has puesto las banderitas y todo parece en orden. Pero un día buscas tu tienda en Google y aparece la versión en inglés. O peor: le preguntas a ChatGPT por tu producto y te cita una página que no es la tuya, o una traducción automática que ni controlas.

Es frustrante, y le pasa a muchísima gente. La buena noticia es que casi siempre se arregla con cuatro ajustes bien hechos. En esta guía vas a ver, paso a paso y sin tecnicismos raros, cómo montar y auditar tu WordPress multilingüe para que Google y los modelos de IA encuentren y citen la versión de idioma correcta.

TL;DR Una URL distinta por idioma, sin parámetros ni cookies. hreflang recíproco, con autorreferencia y x-default bien puestos. Canonical del mismo idioma, nunca apuntando al idioma principal. Sitemap con xhtml:link para cada versión. Y verifica con prompts por idioma qué versión cita la IA.

WordPress en varios idiomas: qué problema resuelve este poradín

Cuando tu web existe en varios idiomas, tienes varias páginas que dicen casi lo mismo. Google y los modelos de IA necesitan saber cuál enseñar a cada persona. Si no lo tienen claro, eligen por su cuenta. Y ahí empiezan los problemas.

Tres conceptos te van a acompañar todo el artículo, así que vamos con ellos en lenguaje llano:

• hreflang: una etiqueta que le dice a Google "esta página es la versión en español de esta otra en inglés". Es como poner una señal de tráfico entre versiones.
• canonical: la URL "oficial" de una página. Sirve para decir cuál es la buena cuando hay varias parecidas.
• x-default: la versión que quieres mostrar cuando el idioma del visitante no coincide con ninguno de los que tienes.

El problema típico es este: tu versión en español y la inglesa se parecen tanto que Google decide que son duplicados y muestra solo una. O tu plugin genera etiquetas a medias y Google las ignora. Resultado: el usuario acaba en el idioma equivocado.

Con la IA pasa algo parecido, pero con un matiz importante. En los modelos de lenguaje, el idioma de la consulta manda. Si alguien pregunta en español, la IA busca y cita fuentes en español. Si tu versión en español no está bien identificada, o no existe, la IA tirará de otra cosa. A veces incluso del proxy de Google Translate, que no te da tráfico ni te representa bien.

Al terminar este poradín vas a saber configurar tu WordPress para que cada versión de idioma sea clara, y también cómo comprobar que la IA está citando la que toca.

Antes de empezar: qué necesitas y cuándo este método no encaja

Antes de tocar nada, prepara estas cosas:

• Acceso de administrador a tu WordPress.
• Un plugin de traducción instalado y activo.
• Acceso a Google Search Console.
• Tu sitemap a mano.
• Capacidad de editar los ajustes SEO (normalmente desde Yoast, Rank Math o similar).

Con eso ya puedes trabajar. No necesitas ser desarrollador.

Ahora, seamos honestos: este enfoque no siempre tiene sentido. Si tu web está en un solo idioma, no apliques nada de esto. Si tienes un presupuesto muy justo y no vas a poder mantener las traducciones, tampoco. Y si el contenido no se va a localizar de verdad, mejor no crear versiones vacías que solo confunden.

Una aclaración que evita muchos dolores de cabeza: elegir entre multisite, subdominios o dominios separados es una decisión de gobernanza, no de SEO. Tiene que ver con cómo quieres organizar tu negocio y tu equipo, no con trucos para posicionar mejor.

Paso 1: elige la estructura de URL y el plugin

Esta es la decisión más importante, y conviene tomarla antes de instalar nada.

Para la mayoría de pymes, el subdirectorio es la opción más práctica. Todo suma en un mismo dominio, tienes un solo robots.txt y un solo sitemap index. Menos piezas que se pueden romper.

Sobre el plugin, tienes varias opciones conocidas: WPML, Polylang, TranslatePress o Weglot. Todas generan hreflang, canónicas y sitemaps por idioma. Elige según tu presupuesto, si usas WooCommerce y lo cómodo que te resulte el panel. Si vendes con WooCommerce, comprueba que el plugin cubra tu tienda antes de decidir.

Aquí entra Semly. Se integra con WordPress y WooCommerce mediante una clave API, así que puedes conectar tu web y medir cómo aparece tu marca en las respuestas de IA, además de generar contenido y datos estructurados pensados para que los modelos te puedan citar.

Punto de control: cada idioma debe tener su propia URL. Sin parámetros tipo ?lang=es y sin depender de cookies.

Paso 2: configura hreflang, canonical y x-default

Esta es la parte técnica central. Vamos por partes.

El hreflang tiene que ser recíproco: si la versión en español apunta a la inglesa, la inglesa tiene que apuntar a la española. Y cada versión debe incluirse a sí misma. Si falta esa reciprocidad, Google ignora las etiquetas.

Usa siempre URLs absolutas y códigos ISO válidos. Por ejemplo, es-MX o en-GB. Ojo con un error clásico: en-UK no existe, lo correcto es en-GB.

Un ejemplo de cómo se ve en el HTML:

<link rel="alternate" hreflang="es" href="https://tusitio.com/es/" />
<link rel="alternate" hreflang="en-GB" href="https://tusitio.com/en-gb/" />
<link rel="alternate" hreflang="x-default" href="https://tusitio.com/" />

Puedes poner estas etiquetas de tres formas equivalentes: en el HTML, en una cabecera HTTP o en el sitemap XML. Usar las tres a la vez no te da ninguna ventaja extra, así que elige una y hazla bien.

Sobre la canonical: cada versión de idioma debe apuntar a sí misma. Nunca pongas la canonical de la página en español apuntando a la versión principal en inglés. Si lo haces, anulas el hreflang y le dices a Google que solo existe una página. Eso confunde también a los modelos de IA.

Y una advertencia importante: no uses redirecciones automáticas según el idioma del navegador. Google puede no rastrear todas tus versiones si lo haces. Mejor un selector de idioma manual y URLs claras.

Punto de control: cada versión se lista a sí misma y a todas las demás.

Paso 3: sitemap multilingüe y datos estructurados

El sitemap es tu fuente única de verdad. Aquí le dices a Google, de una vez y ordenadamente, qué versiones existen.

En un sitemap multilingüe, cada URL incluye etiquetas xhtml:link que apuntan a sus versiones en otros idiomas. A escala, esto es mucho más fácil de mantener que ir tocando etiquetas HTML página por página.

Además, añade datos estructurados JSON-LD por cada idioma. Así marcas el idioma de cada versión de forma explícita y ayudas a que la IA entienda qué contenido corresponde a cada locale.

Y aquí entra un archivo del que se habla mucho: llms.txt. Es un índice curado de tus recursos clave pensado para los modelos de lenguaje. Es útil, sí, pero no sustituye ni a robots.txt ni al sitemap. Son cosas distintas con funciones distintas. Y conviene decirlo claro: tener llms.txt no garantiza que la IA te cite.

Semly genera llms.txt, JSON-LD y una base de conocimiento en un subdominio propio, con actualización automática de contenido. Es una forma práctica de tener esa capa lista sin montarla a mano.

Paso 4: comprueba que la IA cita la versión correcta

Aquí está el gran hueco que casi nadie cubre. Has configurado todo bien, pero ¿cómo sabes que funciona?

La respuesta es sencilla: preguntando. Lanza prompts de prueba en cada idioma en ChatGPT, Gemini, Claude, Grok y en los AI Overviews de Google. Pregunta por tu marca, tus productos o tus servicios, tal como lo haría un cliente real.

Después, mira qué URL cita la IA. ¿Es tu versión localizada o el proxy de Google Translate? ¿Cita tu web o la de otro? Anota los resultados para poder comparar con el tiempo.

Mini-checklist de auditoría:

• ¿La IA cita tu URL del idioma correcto?
• ¿Cita el proxy de Google Translate en lugar de tu web?
• ¿Aparece tu marca en las respuestas de ese idioma?
• ¿Qué fuentes usa la IA para responder?
• ¿Cambian los resultados según la plataforma?

Semly monitoriza prompts, fuentes y citas por plataforma, con informes cada 24 horas. Así puedes ver si tu versión en español se cita cuando alguien pregunta en español, y detectar si la IA está tirando de otra fuente.

Errores frecuentes y cómo arreglarlos

La mayoría de webs multilingües comete algún error de hreflang. No estás solo en esto. Aquí van los más comunes, con su causa y su solución.

hreflang duplicado por plugin y tema. Causa: el plugin genera las etiquetas y tu tema también. Solución: deja que solo uno lo haga y revisa el código fuente de la página.

Canonical cruzada entre idiomas. Causa: configuración mal puesta en el plugin o en el SEO. Solución: cada versión debe apuntar a sí misma.

Slugs sin traducir. Causa: se tradujo el contenido pero no las URLs. Solución: traduce también los slugs para que sean claros en cada idioma.

Sitemap sin xhtml:link. Causa: el plugin no lo genera o está desactivado. Solución: revisa los ajustes y comprueba el sitemap en el navegador.

Redirección automática por navegador. Causa: se activó por comodidad. Solución: desactívala y usa un selector manual.

Códigos de idioma inválidos. Causa: se escribió en-UK en lugar de en-GB. Solución: revisa que todos los códigos sean ISO válidos.

Si Google indexa la versión equivocada, casi siempre hay una de estas causas detrás. Revisa el informe de targeting internacional en Search Console y verás qué está fallando.

Co dalej: mide, localiza y escala

Ya tienes la base técnica. Ahora toca medir y mejorar.

En Search Console, mira las impresiones y el CTR por idioma. Si una versión recibe visitas pero no convierte, quizá el problema no es técnico, sino de localización. Y aquí va una idea clave: localizar no es solo traducir. Es adaptar moneda, ejemplos, prueba social y terminología a cada mercado.

Mantén el contenido fresco. Las páginas actualizadas con regularidad tienen más probabilidades de recibir citas, tanto en Google como en IA.

¿Y cuándo cambiar de arquitectura? Si tu proyecto crece mucho, si necesitas aislar mercados o si los equipos trabajan de forma totalmente independiente, puede tener sentido pasar a multisite o a dominios separados. Pero eso es una decisión de negocio, no una urgencia SEO.

Checklist final de verificación:

• hreflang recíproco y con autorreferencia en cada versión.
• Canonical propia por idioma.
• Sitemap con xhtml:link para todas las versiones.
• Prompts de prueba por idioma en cada plataforma de IA.

Y una acción concreta para hoy: conecta tu WordPress o WooCommerce a Semly con la clave API y empieza a medir tu visibilidad en IA por idioma. Sabrás qué versión citan los modelos y podrás mejorarla con datos, no con suposiciones.

Preguntas rápidas

¿Qué es x-default y cuándo lo necesito? Es la versión que muestras cuando el idioma del visitante no coincide con ninguno de los tuyos. Útil si tienes un idioma principal claro o una página de selección.

¿llms.txt sustituye al sitemap? No. Son complementarios. El sitemap es para los buscadores, llms.txt es un índice curado para modelos de lenguaje.

¿Qué hago si la IA cita el proxy de Google Translate? Revisa que tu versión localizada esté bien identificada con hreflang y canonical, y que el contenido sea realmente localizado. Después, vuelve a comprobar con prompts en ese idioma.