Alguien pide «la web en inglés». Un plugin, dos banderitas, los textos pasados por un traductor. A los tres meses Google indexa /es/servicio y /servicio como si fueran lo mismo, el inglés hereda metas en castellano y el selector te manda a la home en cada cambio de idioma. No has internacionalizado. Has duplicado.
Una web multidioma hreflang bien hecha es arquitectura: URLs estables, relación entre versiones, CMS que no rompe slugs, y contenido que de verdad existe en cada lengua —no un 80 % sin traducir con canonical cruzado. El SEO internacional se cae por esas costuras, no por «falta de keywords en inglés».
En Truman lo tratamos como parte del desarrollo web a medida, no como un extra del día anterior al launch. Lo hemos visto en sitios con audiencia internacional —Mallorca Live Festival— y en webs de grupo como Grupo Candela, donde el idioma no es un filtro decorativo. Este artículo va a URLs, hreflang y a los errores que duplican y matan posicionamiento.
Web multidioma y hreflang: primero las URLs
Tienes tres modelos limpios. Subdirectorio: example.com/es/ y /en/. Subdominio: es.example.com. ccTLD: example.es y example.com. Para casi todo proyecto a medida de un estudio, el subdirectorio gana: una sola propiedad en Search Console, autoridad concentrada, ops más simple. El ccTLD solo tiene sentido con equipos y marcas locales de verdad. El subdominio añade culebras de cookies y de tracking sin un beneficio claro.
Lo que no es un modelo limpio: parámetros (?lang=en), hashes (#en), o detectar idioma por IP y servir HTML distinto en la misma URL. Lo último es cloaking accidental: el usuario en València y el bot de Googlebot (EE. UU.) no ven lo mismo. El selector de idioma tiene que cambiar la URL, no solo el texto. Y esa URL tiene que ser enlazable, cacheable y estable.
| Modelo | SEO / ops | Cuándo usarlo |
|---|---|---|
| Subdirectorio /es/, /en/ | Habitualmente el mejor | Una marca, varios idiomas |
| ccTLD .es / .fr | Más caro de operar | Negocio y equipo realmente locales |
| Subdominio en.sitio.com | Parte autoridad | Solo si ya hay motivo técnico fuerte |
| ?lang= o cookie sola | Malo para indexar | No lo uses en un sitio público |
| Misma URL, HTML por IP | Riesgo de cloaking | Nunca como solución de idioma |
| Plugin que reescribe slugs | Frágil | Solo con reglas de slug congeladas |
El slug se decide y se congela. Si traduces «agencia-diseno-web» a «web-design-agency», esa pareja se documenta. No se regenera cada vez que un editor toca el título. Un cambio de slug en un idioma es una migración: 301, hreflang nuevo, sitemap nuevo. Trátalo como tal, no como un typo. Si alguna vez migráis de dominio o de CMS, el mapa de pares idioma a idioma es tan crítico como el de URL a URL. Lo enlazamos con migrar una web sin perder SEO.
hreflang que Google pueda usar
Cada versión se apunta a las demás y a sí misma. Códigos ISO: es, en, ca — o es-ES, en-GB si el contenido de verdad cambia por país (precios, IVA, legal). Mezclar es y es-ES para la misma página es ruido. x-default apunta a la versión que ofreces cuando no hay match: suele ser inglés o la lengua principal de la marca, no un detector mágico.
El hreflang puede ir en HTML, en cabeceras o en sitemap. En un sitio a medida preferimos HTML en las páginas y un sitemap por idioma o uno indexado que liste los pares. Lo que no haces es poner hreflang a URLs que redirigen, que noindexan o que no existen. Search Console te lo acaba enseñando; mejor no llegar a ese informe.
Contenido que no se rompe (y CMS que no miente)
Traducir no es clonar el árbol y esperar. Hay páginas que no existen en el otro mercado. Las dejas fuera: sin URL, sin hreflang, sin ítem de menú. Forzar un inglés automático en un aviso legal español es peor que no tener la página. El selector solo lista idiomas en los que esa URL tiene equivalente.
El CMS tiene que guardar el par. No «esta página en inglés es la que el editor recuerde». Un campo de relación, un ID compartido, un source_id. Cuando el editor despublica el castellano, el inglés no se queda huérfano con un hreflang a 404. Cuando cambia un CTA, no se le olvida el otro idioma durante seis meses.
Si mañana un editor cambia el título en castellano, ¿el slug en inglés y el hreflang siguen siendo los de ayer? Si la respuesta depende del plugin, el sistema no es vuestro.
En un festival como Mallorca Live el calendario, los artistas y las entradas cambian. El idioma tiene que aguantar ese ritmo: no puedes traducir a mano 80 artistas el jueves si el CMS no tiene flujo. En un grupo empresarial, el riesgo es otro: nombres de marcas, legales y sedes que no se traducen igual. El glosario forma parte del desarrollo, no de un Excel suelto.
El coste de hacerlo bien no es «el doble de textos». Es diseño de estructura, panel y QA. Si estás dimensionando el proyecto, el multiidioma mueve presupuesto de verdad; no es una línea de 300 €. Lo encajamos en cuánto cuesta una web a medida como factor, no como checkbox.
Selector, SEO on-page y lo que Google no adivina
El selector no es una bandera. El español se habla en veinte países; una bandera de España excluye. Usa el nombre de la lengua. Recuerda la elección en cookie o en la cuenta, pero la URL manda: un enlace compartido no depende de tu cookie. html lang=»es» en la versión en castellano, lang=»en» en la inglesa. Og:locale acorde. Title y description escritos en esa lengua, no traducidos a medias.
El menú, los breadcrumbs y los schema (Organization, Event, FAQ) van en el idioma de la página. Un Event en JSON-LD con name en castellano dentro de /en/ es un detalle que las IAs y Google pinchan. Si trabajas visibilidad en buscadores generativos, la versión inglesa necesita entidad y citas propias, no un calco. Más contexto en GEO e IA de búsqueda.
Tip técnico: no mezcles hreflang y canonical en direcciones opuestas
Patrón que rompe sitios: la página /en/about tiene rel=canonical a /about y a la vez hreflang en. Google recibe dos recados. El canonical dice «esta no es la principal». El hreflang dice «esta es la versión inglesa». Gana el lío: o se indexa mal el inglés, o se fusionan snippets. Canonical propio, hreflang al par, x-default a una sola URL. Tres líneas. La mayoría de plugins las cruza.
QA antes de abrir el segundo idioma
Recorre el árbol: 200, title, H1, hreflang, canonical, lang. Cambia de idioma en una ficha profunda, no solo en home: ¿caes en el equivalente o en la portada? Enlaces internos del inglés, ¿se quedan en /en/? Las imágenes con texto incrustado no se traducen solas. Los PDFs tampoco. Un «media kit» solo en castellano en la web inglesa es un agujero de marca.
Search Console: sitemap por lengua, inspección de 10 URLs pares, informe de hreflang cuando esté. No lances 200 URLs automáticas al 40 % de calidad. Es peor para SEO que lanzar 40 bien. El contenido fino en un idioma no se «rellena» con IA sin revisión: el tono de un festival y el de un grupo industrial no salen del mismo prompt.
Internacionalizar es decidir URLs y responsables, no activar banderas. Si el inglés no tiene dueño editorial ni pares reales, no es un segundo idioma. Es duplicado con acento.
Antes de publicar el segundo idioma, verifica esto
- ¿Cada idioma tiene prefijo o host estable, sin parámetros ni detección por IP?
- ¿Los slugs están congelados y el par entre lenguas vive en el CMS, no en un Excel?
- ¿El hreflang es bidireccional, con autocita y un solo x-default?
- ¿El canonical de cada versión es ella misma, no la lengua «principal»?
- ¿Las páginas sin traducción no generan URL vacía ni hreflang inventado?
- ¿El selector en una URL profunda lleva al equivalente, no a la home?
- ¿Title, description, lang y schema están en el idioma de esa página?
- ¿Hay sitemap de las URLs finales y una pasada de Search Console en pares?
Preguntas frecuentes sobre web multidioma y hreflang
¿Qué es hreflang y para qué sirve?
Es la anotación con la que le dices a Google qué URL es la versión de cada idioma o país. Sirve para que no canibalicen entre sí y para servir la lengua correcta en el resultado. No traduce. No sustituye contenido. Solo declara pares. Si los pares no existen, no lo pongas.
¿Cómo se estructura una web multidioma sin romper el SEO?
Elige un modelo de URL (casi siempre subdirectorios), congela slugs, publica solo páginas realmente traducidas, y cierra el círculo hreflang + canonical propio + sitemap. El plugin que «lo hace todo» suele fallar en uno de los tres. El SEO se pierde en esa costura.
¿Cuándo usar es-ES frente a es en hreflang?
Usa es si el contenido es el mismo para cualquier hispanohablante. Usa es-ES, es-MX, es-AR cuando precio, legal o catálogo cambian de verdad por país. No copies es-ES en todas «por precisión»: si no hay versión por país, el código regional no aporta y complica el mapa.
¿Se puede lanzar un idioma automático y traducir después?
Puedes, y Google lo tratará como contenido pobre o duplicado. Mejor un conjunto pequeño bien escrito —home, servicios, contacto— que un sitio entero a media traducción. El automático sin editor es ruido. Si no hay presupuesto de traducción, no abras el idioma.
