Arquitectura web internacional: estructuras de URL escalables

La arquitectura web internacional es la base de las decisiones de cualquier programa de SEO multilingüe y multirregional. Antes de encargar traducciones, configurar hreflang o dividir los catálogos por país, necesitas un patrón de URL que los motores de búsqueda puedan rastrear, que los usuarios puedan guardar en sus marcadores y que tu equipo pueda mantener durante años. Google documenta varias opciones de URL específicas para cada configuración regional, pero ninguna garantiza el posicionamiento. La ventaja es la claridad: cada versión de idioma y mercado tiene una dirección propia y localizable, con anotaciones coherentes.

Esta guía vincula las estructuras de URL documentadas por Google con decisiones concretas de planificación. Explica cuándo conviene usar ccTLD, subdominios y subdirectorios, por qué los parámetros no funcionan como método principal de segmentación geográfica y cómo hreflang y las URL canónicas se derivan de la arquitectura, y no al revés. Para conocer la terminología estratégica de la segmentación por idioma frente a la segmentación por país, consulta SEO internacional frente a SEO multilingüe.

Preguntas que responde esta guía

• ¿Qué estructuras de URL documenta Google para sitios internacionales y multirregionales?
• ¿Cuándo conviene elegir ccTLD, subdominios o subdirectorios?
• ¿Por qué no se recomiendan los parámetros de URL para la segmentación geográfica?
• ¿Cómo debe variar la arquitectura entre la segmentación solo por idioma y la segmentación por país?
• ¿Cómo interactúan hreflang y las URL canónicas con las decisiones sobre la arquitectura de URL?
• ¿Qué señales de configuración regional importan más allá de la ruta de la URL?
• ¿Cómo deben gestionar los equipos las migraciones entre estructuras de URL internacionales?
• ¿Qué errores de arquitectura impiden el rastreo de las versiones por idioma o región?

Respuesta rápida: la arquitectura depende de la matriz de mercados

Empieza por una matriz de países × idiomas, no por el nombre de una carpeta. En cada celda, anota qué necesitan los usuarios de ese mercado: comprender el idioma, usar la moneda local, conocer las condiciones de entrega y los términos legales, o todo lo anterior. La matriz te indica si necesitas rutas solo por idioma (/de/), solo por país (/us/), que combinen país e idioma (/en-ca/) o ccTLD independientes (example.de).

Google recomienda usar URL diferentes para cada versión de idioma en lugar de cambiar el idioma en una única URL mediante cookies o la configuración del navegador. El cambio dinámico oculta variantes porque Googlebot suele rastrear sin Accept-Language y, habitualmente, desde infraestructura ubicada en Estados Unidos. Por tanto, la arquitectura es ante todo una decisión sobre la capacidad de rastreo y, después, una decisión de marca.

Una vez definida la matriz, elige una estructura que tus equipos de ingeniería y localización puedan gestionar durante los próximos años. Los subdirectorios en un único gTLD suelen ser la opción predeterminada que menos mantenimiento requiere. Los ccTLD tienen sentido cuando las circunstancias legales, de marca o de alojamiento exigen una separación estricta entre mercados. Los subdominios ofrecen una solución intermedia. Los parámetros de URL están documentados, pero no se recomiendan para la segmentación geográfica.

Estructuras de URL documentadas por Google

La documentación de Google sobre sitios multirregionales y multilingües recoge cuatro patrones de URL específicos para cada configuración regional. Cada uno proporciona una dirección distinta por versión, el requisito básico para que las variantes por idioma y región sean rastreables.

Ninguna de estas estructuras determina por sí sola el posicionamiento. Google las considera formas de ofrecer variantes regionales o de idioma, no mejoras automáticas del posicionamiento.

Cómo elegir entre ccTLD, subdominios y subdirectorios

Utiliza criterios de decisión que tu organización pueda justificar en una revisión del diseño:

Los ccTLD envían una señal clara de orientación a un país, pero pueden resultar costosos, estar sujetos a restricciones y limitarse a un solo país. Google señala que algunos ccTLD se tratan como dominios de nivel superior genéricos, así que comprueba cómo se clasifica el TLD elegido antes de dar por hecho que permite la segmentación por país.

Los subdominios (de.example.com) ofrecen una separación flexible y pueden vincularse a distintos backends. Google advierte expresamente de que los códigos de los subdominios no se utilizan para determinar el público objetivo, a menos que este se indique explícitamente, por ejemplo, mediante hreflang y señales coherentes en las páginas.

Los subdirectorios (example.com/de/) suelen ser la opción más sencilla de configurar en un único host y requieren menos mantenimiento continuo. La contrapartida es la ambigüedad: /de/ podría indicar contenido en alemán para todo el mundo, contenido en inglés para Alemania o contenido en alemán para Alemania. Define la intención en la matriz antes de decidir los nombres de las carpetas.

Por qué los parámetros no funcionan como método principal de segmentación geográfica

Google incluye en su documentación los parámetros de URL como opción para indicar el idioma y la región, pero no los recomienda para la segmentación geográfica. A gran escala, los parámetros generan problemas previsibles:

1. Duplicación del rastreo. Una misma ruta con varios valores de ?loc= puede generar combinaciones de parámetros que diluyan las señales, a menos que la gestión de parámetros se configure meticulosamente.
2. Señales poco claras para los usuarios. Las rutas estables son más adecuadas para guardar en favoritos, compartir y usar en materiales impresos. Los parámetros dificultan identificar el idioma y la región en los datos de analítica y en las solicitudes de soporte.
3. Carencias en el descubrimiento. Los enlaces internos, los sitemaps y los grupos hreflang necesitan URL absolutas. Las arquitecturas con muchos parámetros suelen implementarse con conjuntos incompletos de versiones alternativas.
4. Deuda de migración. Pasar más adelante de ?lang=fr a /fr/ requiere mapas de redirecciones para cada variante de URL indexada.

Los parámetros pueden seguir utilizándose para el seguimiento o las vistas que requieren autenticación, pero no como método principal de segmentación.

Arquitectura solo por idioma frente a arquitectura por país

Las estrategias centradas solo en el idioma y las centradas solo en el país necesitan estructuras de URL diferentes, aunque compartan el mismo CMS.

La segmentación solo por idioma (SEO multilingüe) responde a la pregunta: ¿en qué idioma debería leer este usuario? Estructuras habituales:

• Subdirectorios /en/, /es/, /ja/
• Subdominios en.example.com, es.example.com
• Un sitio global en inglés al que se añaden progresivamente carpetas por idioma

Los valores de hreflang suelen ser únicamente códigos de idioma: hreflang="en", hreflang="es". La política de URL canónicas es sencilla cuando cada URL corresponde a una traducción real de la misma página.

La segmentación por país (SEO multirregional) responde a la pregunta: ¿qué experiencia de mercado debe ofrecerse a este usuario? Estos son algunos modelos habituales:

• ccTLD por país (example.co.uk, example.com.au)
• Subdominios o carpetas por país (uk.example.com, example.com/us/)
• Carpetas que combinan idioma y país cuando ambos varían (/en-us/, /en-gb/, /fr-ca/)

Los valores de hreflang suelen combinar idioma y región: hreflang="en-US", hreflang="en-GB". Cuando un mismo idioma aparece en varias URL de distintos países con contenido casi idéntico, Google recomienda elegir una versión preferida y usar rel="canonical" junto con hreflang.

El diseño general de un programa de SEO multilingüe va más allá de esta guía sobre la estructura de URL; este artículo se centra en las decisiones de arquitectura de las que dependen esos programas.

Hreflang y URL canónicas en la arquitectura

Hreflang y las etiquetas canónicas no sustituyen la arquitectura de URL: añaden anotaciones a las URL elegidas. Google admite hreflang mediante etiquetas de enlace HTML, cabeceras HTTP o sitemaps; los tres métodos son equivalentes. Cada URL localizada debe incluir un enlace a sí misma y a sus versiones alternativas, con enlaces recíprocos y URL completas. Si dos páginas no se enlazan mutuamente, es posible que se ignoren las etiquetas hreflang.

Reglas de hreflang basadas en la arquitectura:

• Una URL por cada variante de idioma o de idioma y región dentro del grupo
• URL absolutas que coincidan con la dirección canónica que ven los usuarios
• x-default para los idiomas sin una versión correspondiente, normalmente dirigido a un selector de idioma o a una versión global predeterminada
• Códigos solo de idioma (de) o de idioma y región (de-AT) coherentes con la matriz

Interacción con la URL canónica: Al usar hreflang, especifica una URL canónica en el mismo idioma o, si no existe, en el idioma alternativo más adecuado disponible. Para contenido similar en el mismo idioma distribuido entre URL de distintas regiones —por ejemplo, alemán tanto en example.de como en example.com/de/—, elige una URL preferida y combina la etiqueta canónica con hreflang para que el buscador pueda mostrar la URL regional correcta sin considerar cada duplicado una repetición no controlada.

Las versiones localizadas solo se consideran duplicados problemáticos cuando el contenido principal sigue sin traducirse. Las pequeñas variaciones regionales dentro de un mismo idioma son un caso legítimo de páginas alternativas.

Este artículo resume hreflang en lo que respecta a la arquitectura. Los enlaces de retorno, los códigos de región no válidos, las ventajas e inconvenientes de usar sitemaps frente a HTML y los procedimientos de control de calidad de los grupos se tratan en profundidad en «Aborda el funcionamiento de los grupos hreflang como una línea de trabajo técnico específica». Consulta ese artículo complementario cuando pases del diseño de URL a la implementación de anotaciones.

Señales de idioma y región más allá de la ruta

La estructura de URL es necesaria, pero no suficiente. Google determina el idioma y la región de destino a partir de varias señales:

Google ignora las metaetiquetas de ubicación, como geo.position, para la segmentación geográfica. Esta segmentación no es exacta, por lo que conviene ofrecer enlaces visibles que permitan elegir la región o el idioma si alguien llega a la versión equivocada. Google también señala que orientarse a un país concreto puede mejorar los resultados en ese país a costa de otras regiones: es una contrapartida, no una promesa de mayor visibilidad global.

La detección del idioma sigue una regla distinta: Google determina el idioma a partir del contenido visible, no de las URL, los atributos lang ni hreflang. Por tanto, la arquitectura debe ofrecer páginas en las que predomine un único idioma, tanto en el contenido como en la navegación.

Sitemaps y descubrimiento a gran escala

A medida que aumenta el número de versiones regionales y lingüísticas, los sitemaps se convierten en una de las principales vías de descubrimiento, junto con los enlaces internos. Los sitemaps para Google pueden declarar versiones alternativas por idioma y región, lo que ayuda a los rastreadores a encontrar URL que la navegación interna podría dejar ocultas en menús con múltiples filtros.

Incluye solo URL canónicas, mantén los sitemaps actualizados cuando cambien los mercados y haz que sus entradas hreflang coincidan con las anotaciones del HTML o de las cabeceras. Envía los sitemaps en Search Console para cada propiedad cuando los ccTLD estén repartidos entre distintas cuentas. Una vez que la estructura de URL y las anotaciones sean estables, los datos estructurados de cada versión regional o lingüística pueden ampliar el descubrimiento más allá de las simples listas de URL.

Patrones de migración entre estructuras

Los equipos rara vez aciertan por completo con la arquitectura en el primer lanzamiento. Entre las migraciones habituales están el paso de subdirectorio a ccTLD (por separación legal), de parámetro a carpeta (para recuperar la capacidad de rastreo), la consolidación de subdominios y los cambios de nombre de carpetas. Todas requieren un mapa de redirecciones para cada URL indexada de cada versión regional o lingüística, no solo para la página de inicio, además de actualizar hreflang y las etiquetas canónicas en el mismo despliegue.

Principios de migración: deja cerrada primero la matriz, prioriza las redirecciones 301 directas, haz que los selectores de idioma apunten de inmediato a las nuevas URL y comprueba la reciprocidad semanalmente durante el primer mes. Google no documenta plazos fijos de recuperación; documenta que la implementación técnica esté completa en lugar de prometer cifras de tráfico.

Errores de arquitectura que ocultan versiones regionales y lingüísticas

Estos errores impiden el rastreo o generan señales confusas sobre el idioma o la región:

El error más costoso es tratar la arquitectura como algo meramente estético: lanzar una interfaz traducida en URL cuyo contenido principal sigue siendo monolingüe, o separar países sin actualizar en la página los datos de entrega y gestión de pedidos. Tanto los usuarios como los sistemas de búsqueda leen lo que está visible.

Lista de comprobación para la implementación

• Documenta una matriz de país × idioma para los próximos 12–24 meses
• Etiqueta cada celda según su enfoque: solo idioma, solo país o ambos
• Elige un ccTLD, un subdominio o un subdirectorio; evita basar la segmentación geográfica principalmente en parámetros
• Asigna una URL rastreable a cada versión de idioma o configuración regional
• Nombra las carpetas según el propósito definido en la matriz (elige deliberadamente entre /en-us/ y /en/)
• Prepara grupos hreflang con URL absolutas y referencias recíprocas
• Define una política de canonicalización para versiones del mismo idioma dirigidas a varios países que se solapen
• Añade selectores de idioma y región para los usuarios; desactiva las redirecciones forzadas por configuración regional
• Localiza el contenido principal y la navegación, no solo los textos comunes
• Publica mapas del sitio con URL canónicas y anotaciones de versiones alternativas
• Valida la indexación y la reciprocidad de hreflang tras el lanzamiento
• Planifica la supervisión de cada propiedad en Search Console si utilizas ccTLD

Rastreo e indexación en motores de búsqueda

Googlebot y los rastreadores de Bing necesitan URL estables por idioma o país a las que se pueda enlazar, ya sea mediante un ccTLD, un subdominio o un subdirectorio. Las decisiones de arquitectura afectan al presupuesto de rastreo, a los grupos de URL canónicas y a los mapas de hreflang. Mantén las versiones regionales en HTML que los bots puedan obtener sin depender de un enrutamiento opaco que se ejecute exclusivamente en el cliente. Mide la cobertura de indexación por host o carpeta en Google Search Console y Bing Webmaster Tools.

Acceso de los motores de respuestas, selección de fuentes y comprensión multilingüe

Los motores de respuestas suelen necesitar las mismas URL accesibles que pueden abrir los usuarios. Si una versión de idioma solo está disponible tras autenticarse, mediante scripts bloqueados o con parámetros inestables, tiene pocas posibilidades de ser citada o incluida como fuente. Prioriza rutas regionales estables, un propósito claro para cada página e información coherente sobre las entidades en todos los idiomas, para que los asistentes puedan reconocer a la misma organización en francés, alemán o japonés. La arquitectura no garantiza que se cite el contenido; elimina barreras involuntarias de acceso y comprensión.

Próximos contenidos previstos: guías de optimización específicas para Google, Bing, ChatGPT, Claude, Gemini, Perplexity y Microsoft Copilot.

Optimización para Google Search

Elige estructuras de URL que Google pueda rastrear y relacionar mediante hreflang: hosts o carpetas estables, versiones de idioma en HTML y enlaces internos claros entre versiones regionales. Documenta explícitamente las limitaciones conocidas: no inventes factores de posicionamiento y separa las métricas de indexación tradicionales de las comprobaciones de citas en motores de respuestas.

Optimización para Bing

Ofrece las mismas condiciones de rastreabilidad a Bingbot y valida los hosts y las rutas regionales en Bing Webmaster Tools. Documenta explícitamente las limitaciones conocidas: no inventes factores de posicionamiento y separa las métricas de indexación tradicionales de las comprobaciones de citas en motores de respuestas.

Guía de plataforma: ChatGPT

Los asistentes necesitan URL regionales accesibles. Los selectores de idioma que funcionan solo en el cliente y ocultan el HTML de las versiones alternativas bloquean el acceso a las fuentes. Documenta explícitamente las limitaciones conocidas: no inventes factores de posicionamiento y separa las métricas de indexación tradicionales de las comprobaciones de citas en motores de respuestas.

Guía de la plataforma: Claude

La documentación local de referencia debe ser accesible desde el servidor: una arquitectura que encierra los textos en aplicaciones limita la capacidad de Claude para consultarlos como fuente. Documenta explícitamente las limitaciones conocidas: no inventes factores de posicionamiento y separa las métricas de indexación tradicionales de las comprobaciones de citas en motores de respuestas.

Guía de plataforma: Gemini

Una arquitectura regional indexable sigue siendo la base práctica de las experiencias de IA del ecosistema de Google. Documenta explícitamente las limitaciones conocidas: no inventes factores de posicionamiento y separa las métricas de indexación tradicionales de las comprobaciones de citas en motores de respuestas.

Guía de la plataforma: Perplexity

Las URL estables por idioma favorecen la permanencia de las citas frente a las soluciones improvisadas que gestionan las versiones regionales únicamente mediante parámetros. Documenta explícitamente las limitaciones conocidas: no inventes factores de posicionamiento y separa las métricas de indexación tradicionales de las comprobaciones de citas en motores de respuestas.

Guía de plataforma: Microsoft Copilot

Cuando el descubrimiento de contenido en Copilot esté vinculado a la indexación de Bing, mantén una arquitectura multilingüe que Bing pueda indexar, sin inventar factores de posicionamiento específicos de Copilot. Documenta explícitamente las limitaciones conocidas: no inventes factores de posicionamiento y separa las métricas de indexación tradicionales de las comprobaciones de citas en motores de respuestas.

Dónde encaja GlotEO

Las decisiones de arquitectura corresponden a los responsables de ingeniería y SEO, pero fracasan si no cuentan con flujos de trabajo de contenido que mantengan cada URL regional alineada con las páginas traducidas, las anotaciones y las listas de verificación de calidad. La solución de SEO multilingüe de GlotEO respalda esa capa editorial en proyectos multilingües e internacionales: ayuda a los equipos a publicar versiones de idioma rastreables con las estructuras de URL que elijas, sin sustituir el trabajo previo de matriz y migración.

Para un seguimiento continuo, planifica la división en propiedades de Search Console, los informes de hreflang y las comprobaciones de cobertura de las distintas versiones regionales. La implementación de datos estructurados a gran escala puede abordarse una vez que las bases sean estables.

Los equipos que necesiten control editorial sobre las distintas versiones regionales pueden utilizar la plataforma de SEO multilingüe de GlotEO y, después, comparar los precios y planes de GlotEO.