--- title: Por qué un WordPress multilingüe decide si la IA te cita canonical_url: https://lolacore.com/es/wordpress-multilingue-geo/ last_updated: 2026-07-26T11:48:16+00:00 plugin_version: 1.2.3 --- # Por qué un WordPress multilingüe decide si la IA te cita URL: https://lolacore.com/es/wordpress-multilingue-geo/ ## El idioma de la pregunta decide quién puede ser citado Un modelo generativo que responde una pregunta en italiano no traduce la web entera y luego elige la mejor fuente. Recupera pasajes, y esa recuperación filtra por idioma antes de que la calidad entre en juego. Tu página en inglés puede ser la más exacta, la mejor estructurada y la más autorizada que existe sobre el tema. Si el lector preguntó en italiano y no hay versión italiana de esa página, tu página nunca estuvo en el conjunto entre el que el modelo eligió. Esta es la parte que se pierde cuando el trabajo multilingüe se archiva bajo la etiqueta de "traducción". Estamos ante un problema de elegibilidad, no de ranking, y por eso no se gana con mejor contenido en inglés. O tienes una página en el idioma de la pregunta o no la tienes, y ninguna cantidad de calidad al otro lado compensa esa ausencia. Eso cambia el marco entero de la decisión. Traducir tu web va de existir dentro del conjunto de recuperación del modelo que le responde a alguien cuando decide preguntar en su idioma, que es lo que la gente hace por defecto cuando la respuesta va a ser sobre su propio negocio. Muchos de esos lectores leen inglés perfectamente. Preguntan en el suyo igualmente. ## Qué sostiene la evidencia y qué no Sobre este asunto circulan muchas cifras. Casi todas vienen de empresas que venden traducción, y varias están construidas de una forma que no aguanta una lectura atenta. Aquí no las vamos a repetir, porque un dato que no puedes verificar vale menos que un mecanismo sobre el que puedes razonar directamente. El mecanismo se sostiene sin las cifras. La recuperación es sensible al idioma. La propia documentación de Google sobre sitios internacionales lleva años diciendo que las URLs por idioma y una anotación hreflang correcta son la forma en que un buscador decide qué versión de una página le corresponde a qué audiencia. Los motores generativos se construyen encima de la misma recuperación y de las mismas señales. Nada de esto necesita un whitepaper para creérselo. De lo que no hay evidencia buena es de que activar traducción automática en toda la web produzca beneficio GEO. Los modelos no cuentan tus versiones de idioma. Citan pasajes que se leen como si los hubiera escrito una persona competente para esa audiencia. Traducir literalmente copy comercial es la vía más rápida para producir texto que está técnicamente en español y semánticamente en ningún sitio. ## El problema de entidad que hay debajo del problema de idioma Hay un segundo efecto, y para un producto pesa más que para un blog. A través de los idiomas, el modelo está montando una imagen de qué es tu producto. Mismo nombre, mismo precio, mismas capacidades, mismas afirmaciones. Cuando la página en español dice una cosa sobre el precio y la inglesa dice otra, cuando el nombre del producto se suaviza en portugués porque sonaba mejor así, cuando el schema de una versión omite lo que las demás declaran, no has creado cuatro descripciones de un producto. Has creado cuatro medias descripciones de algo sobre lo que el modelo ahora tiene menos certeza. La coherencia entre versiones es lo que permite a un modelo tratarlas todas como la misma entidad y sumar la autoridad. La incoherencia la parte. Por eso traducir la web de un producto es un ejercicio de posicionamiento antes que uno lingüístico: cada término que posees tiene que cruzar intacto, y cada término que no posees tiene que salir en el vocabulario que el lector local usa de verdad. ## Lo que tiene que estar bien montado Los requisitos técnicos son poco lucidos y no son negociables. Cada idioma vive en su propia URL. En un WordPress lo habitual son subdirectorios: /es/, /pt-br/, /it/. Un idioma por página, nunca mezclados. Las anotaciones hreflang conectan las versiones entre sí y declaran cuál le corresponde a cada audiencia, con etiqueta autorreferencial en todas. El canonical apunta a la propia página en su idioma, no de vuelta al original en inglés, que es la forma más común en la que una instalación multilingüe de WordPress se borra a sí misma del índice sin que nadie se entere. El marcado de schema.org declara inLanguage en cada versión y mantiene la misma identidad de entidad en todas. El sitemap incluye todas las versiones. Cualquier plugin de traducción decente para WordPress hace casi todo esto por ti. Lo importante no es cuál. Lo importante es que, si estas señales están mal, el contenido de debajo no se lee como pretendías, y has pagado el coste de traducir sin cobrar el beneficio. ## Qué traducir, y en qué orden No todo, y la home no va primero. Los modelos citan pasajes que responden preguntas. Eso significa documentación, guías, comparativas, páginas de casos de uso, lo que la gente formula como pregunta cuando lo escribe en una ventana de chat. Una home traducida es un folleto en otro idioma. Una sección de documentación traducida es un conjunto de respuestas recuperables en otro idioma, que es lo que acaba apareciendo dentro de una respuesta generada. En una tienda WooCommerce, la prioridad equivalente son las fichas de producto, las categorías y las FAQ que cuelgan de ellas, porque lo que la gente le pregunta a un modelo sobre una tienda es justo lo que responde una ficha de producto. La home importa para el humano que llega después de que el modelo ya lo haya mandado. Lo que lo mandó fue otra cosa. ## El coste que nadie presupuesta Aquí está la parte que decide si una web multilingüe sobrevive a su primer año. Publicas una página en inglés. Luego la publicas en tres idiomas más. Luego cambias un precio. Luego renombras una función. Luego reescribes la sección que no convertía. Cada una de esas ediciones son ahora cuatro ediciones, en cuatro sitios, en cuatro idiomas que quizá no hables todos, con cuatro juegos de anotaciones hreflang que se rompen en silencio si una versión se descuelga. Nadie abandona una web multilingüe porque traducir sea duro. La abandonan porque el mantenimiento es constante e invisible. La versión inglesa se mantiene al día porque es la que miras cada día. Las otras tres se van descolgando, calladas, hasta que la página italiana describe un producto que ya no existe y el modelo le está citando con toda confianza a un lector italiano una afirmación tuya que caducó hace medio año. Esa deriva es un síntoma de fatiga administrativa: la distancia entre la frase simple que tienes en la cabeza, "cambia el precio de esta página", y la cantidad de pantallas e idiomas que esa frase toca de verdad. [Aquí explicamos qué queremos decir con eso.](https://lolacore.com/es/fatiga-administrativa-wordpress-woocommerce/) La consecuencia práctica es una regla que suena conservadora y no lo es: elige menos idiomas de los que crees que puedes llevar, y mantenlos sincronizados. Cuatro idiomas mantenidos ganan a ocho idiomas publicados. Una página caducada en un idioma que no lees es peor que no tener página, porque sigue siendo elegible para que la citen. ## Escrito desde una web que hace esto Nada de lo anterior es una proyección. Esta web existe en inglés y en español, y la versión inglesa de la página que estás leyendo está a un clic en el selector de idioma. No se pasó por un traductor automático en bloque. Cada página se rehízo en español desde la intención, que significa que la terminología que nos pertenece cruzó tal cual y la que no nos pertenece salió como la dice un lector español de verdad. El problema de sincronización de la sección anterior es al que le dedicamos tiempo real. Y es la razón de que los dos idiomas siguientes estén planificados en vez de publicados.