# General Translation Knowledge Base: Subdirectorio vs. subdominio vs. ccTLD para SEO multilingüe URL: https://generaltranslation.com/es/kb/multilingual-url-structure.mdx Docs index: https://generaltranslation.com/llms.txt Description: Usa subdirectorios como example.com/de/ cuando un mismo producto comparte sitio y proceso de lanzamiento. Solo un ccTLD indica un país, los subdominios permiten un alojamiento independiente, Google desaconseja los parámetros ?lang= y trata los dominios personalizados como .io y .ai como genéricos. Category: SEO multilingüe Last updated: 2026-10-20 Authors: Kevin Wu, Jackie Chen Published: 2026-10-20 Todas las estructuras que se presentan aquí asignan a cada idioma su propia URL, y la [guía de Google sobre sitios multirregionales y multilingües](https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites) las compara en cuanto a segmentación y mantenimiento sin situar ninguna por encima de las demás. Así que la decisión se reduce a dos preguntas: ¿te orientas a idiomas o a países?, y ¿cuántos sitios quieres gestionar? ## Comparación de las cuatro estructuras de URL Las ventajas y desventajas que se muestran a continuación parafrasean la tabla de la propia Google. La última opción, un parámetro de URL, es la que Google marca como no recomendada. | Estructura | Ejemplo | Ventajas según Google | Desventajas según Google | | --------------------------------------------------- | --------------------- | ---------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | | Dominio de nivel superior de código de país (ccTLD) | `example.de` | Segmentación geográfica clara; la ubicación del servidor es irrelevante; facilita separar los sitios | Costoso y a veces no disponible; más infraestructura; requisitos estrictos de ccTLD en algunos países; se dirige a un solo país | | Subdominio | `de.example.com` | Fácil de configurar; permite distintas ubicaciones de servidor; facilita separar los sitios | Los usuarios no pueden saber por la URL si `de` indica un idioma o un país | | Subdirectorio | `example.com/de/` | Fácil de configurar; mantenimiento sencillo (mismo host) | Es posible que los usuarios no identifiquen la segmentación por la URL; una sola ubicación de servidor; más difícil separar los sitios | | Parámetro de URL | `example.com?lang=de` | No se indica ninguna (no recomendado) | Difícil de segmentar por URL; es posible que los usuarios no identifiquen la segmentación | Dos detalles de las recomendaciones de Google acortan distancias entre las opciones: * **De todas las formas de URL, solo un ccTLD indica un país.** La [guía de versiones localizadas](https://developers.google.com/search/docs/specialty/international/localized-versions) de Google señala que los subdominios de idioma como `en` o `de` no se usan para determinar la audiencia de una página; esa correspondencia se define explícitamente con [hreflang](/kb/what-is-hreflang). Google no menciona expresamente las carpetas, pero nada indica que una ruta `/de/` reciba un trato distinto, así que defínelas también con hreflang. * **Algunos ccTLD se consideran genéricos.** Google trata `.io`, `.ai`, `.co`, `.me`, `.tv` y otros ccTLD «de fantasía», además de dominios regionales como `.eu`, como dominios de nivel superior genéricos. Una startup con `example.io` no se dirige al Territorio Británico del Océano Índico. Google también señala que la ubicación del servidor «no es una señal definitiva», ya que los sitios usan CDN, lo que atenúa la desventaja de «una sola ubicación de servidor» de los subdirectorios. Una quinta opción mantiene una única URL y cambia el idioma mediante una cookie o una cabecera del navegador. Google la desaconseja porque es posible que su rastreador no encuentre todas las versiones; las ventajas y desventajas se analizan en [cómo debe elegir un sitio el idioma que ofrece](/kb/locale-routing-seo). ## Lo que cuesta mantener cada estructura La tabla de Google se limita a indicar «más infraestructura». En la práctica, las estructuras se diferencian en la cantidad de elementos independientes que hay que mantener: * **Dominios de país:** un dominio que comprar y renovar por cada país, con normas de registro locales en algunos de ellos. Cada host necesita cobertura TLS, aunque un mismo certificado puede cubrir varios nombres. Planifica la titularidad, las redirecciones y la monitorización de todos esos dominios. * **Subdominios:** un solo dominio, pero un registro DNS y cobertura de certificado para cada subdominio. La [guía de canonicalización](https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls) de Google advierte que el certificado debe coincidir con el host completo o ser un comodín; de lo contrario, Google podría preferir la versión HTTP. * **Subdirectorios:** los idiomas pueden compartir host, configuración TLS, aplicación y flujo de despliegue. Son opciones operativas habituales, no requisitos: los proxies inversos pueden enrutar rutas a aplicaciones distintas, y la analítica puede organizarse con independencia de la estructura de URL. No des por hecho que los subdirectorios obtienen una ventaja de posicionamiento ni que cada subdominio nuevo parte sin señales útiles. La comparación de Google no respalda ninguna de las dos afirmaciones. Compara el trabajo de alojamiento, titularidad y lanzamiento que exige tu despliegue real. ## ¿Conviene orientarse a idiomas o a países? Google distingue entre un sitio **multilingüe** (la misma oferta en varios idiomas, como una empresa canadiense en inglés y francés) y uno **multirregional** (ofertas distintas por país, como un fabricante que envía a Canadá y a EE. UU.). La estructura de URL debe ajustarse a tu caso: * **Oriéntate a un idioma** cuando el contenido sea el mismo para todos los hablantes. Una única sección `/es/` anotada como `es` sirve a hispanohablantes de México, España y Argentina. * **Oriéntate a un país** cuando algo cambie según el país: precios y moneda, envíos, condiciones legales o el catálogo de productos. Usa `/es-mx/` y `/es-es/`, o `example.mx`, y anótalos como `es-MX` y `es-ES`. La segmentación por país tiene un coste. Según Google, la segmentación geográfica puede mejorar el posicionamiento en el país de destino «a costa de los resultados en otras configuraciones regionales o idiomas», y un ccTLD solo puede orientarse a un país. Si optas por dividir por país, Google [recomienda](https://developers.google.com/search/docs/specialty/international/localized-versions) ofrecer también una página solo de idioma (`es`) para los hablantes del resto del mundo. Para elegir entre códigos como `es` y `es-MX`, consulta [qué códigos de configuración regional usar](/docs/platform/core/guides/locale-codes). ## Slugs localizados El prefijo de configuración regional hace visible la versión en la URL, pero el resto de la ruta también se puede traducir: por ejemplo, `/de/ueber-uns` en lugar de `/de/about-us`. Según Google, se pueden usar palabras localizadas en las URL, al igual que nombres de dominio internacionalizados, siempre que las URL usen UTF-8 y se escapen correctamente al enlazarlas. Un slug con caracteres no ASCII como `/de/über-uns` se transmite como `/de/%C3%BCber-uns`, así que esa forma codificada es la que debe figurar en hreflang y en los mapas del sitio. Los slugs traducidos resultan más naturales en los resultados de búsqueda, pero obligan a mantener un mapa de slugs por configuración regional, y si cambia la traducción de un slug, hace falta una redirección desde la URL anterior. Los equipos que prescinden de los slugs localizados mantienen `/de/about-us` y, aun así, obtienen una URL distinta e indexable para cada idioma. ## ¿Qué estructura deberías usar? Usa **subdirectorios** como punto de partida cuando un mismo producto se ofrece en varios idiomas desde un sitio y un proceso de lanzamiento compartidos. Suelen permitirte reutilizar la configuración de enrutamiento y de alojamiento. Aun así, puedes tener despliegues separados, y una CDN puede servir el mismo host desde varias ubicaciones. Usa **dominios de país** cuando cada país funciona, en la práctica, como un negocio independiente (con entidades legales, catálogos o equipos de marketing propios), quieres enviar la señal de país más fuerte posible y puedes asumir el coste de mantenimiento. Usa **subdominios** cuando una configuración regional requiere un alojamiento o una infraestructura distintos; por ejemplo, cuando un mercado debe servirse desde servidores ubicados en ese país. Evita los **parámetros de URL** como estructura de idioma predeterminada, ya que Google no los recomienda. No es que no puedan indexarse por naturaleza; el comportamiento de los informes y de la caché depende de cómo traten tus sistemas esos parámetros. Elijas la opción que elijas, usa URLs estables y anota las versiones publicadas equivalentes con hreflang. (Consulta [Qué es hreflang](/kb/what-is-hreflang)). ## Cómo admite General Translation cada estructura El paquete `gt-next` de General Translation admite subdirectorios. En el App Router, [`createNextMiddleware`](/docs/react/nextjs/reference/functions/create-next-middleware) enruta cada configuración regional bajo un prefijo de ruta como `/es/about`; en [enrutamiento por configuración regional y SEO](/kb/locale-routing-seo) se explica si la configuración regional predeterminada también lleva uno. La opción `pathConfig` del mismo middleware asigna a una ruta compartida un slug localizado para cada configuración regional, como `/de/ueber-uns` para `/about`, y `customMapping` en `gt.config.json` permite que una ruta use un alias como `/cn` mientras las traducciones usan el código canónico `zh`. (Consulta la [guía de SEO para alias de configuración regional](/docs/react/nextjs/locale-alias-seo)). La documentación de `gt-next` cubre el enrutamiento basado en rutas, no por nombre de host. Para subdominios o dominios de país, asigna cada host a una configuración regional en tu propio código y pásala a la biblioteca; por ejemplo, con una función de configuración regional personalizada definida mediante [`getLocalePath`](/docs/react/nextjs/config#request-function-paths) o con [`withGT`](/docs/node/reference/functions/with-gt) en `gt-node`. Para las etiquetas de URL canónica, hreflang y el mapa del sitio, consulta [¿Cómo configuro el SEO para una aplicación de Next.js multilingüe?](/kb/multilingual-nextjs-seo). ## Puntos clave * Google compara los ccTLD, los subdominios y los subdirectorios en cuanto a segmentación y mantenimiento, no en cuanto a posicionamiento, y desaconseja usar parámetros de idioma en las URL. * Un ccTLD aporta una señal de país; los subdominios y las rutas que parecen indicar un idioma no aportan esa señal por sí solos. Usa hreflang para segmentar explícitamente por idioma o región. Google trata `.io`, `.ai` y `.co` como dominios genéricos. * Empieza con subdirectorios (`example.com/de/`) cuando tus configuraciones regionales compartan un sitio y un proceso de lanzamiento; la estructura de URL no exige un único despliegue ni una única propiedad de analítica. * Divide por país (`es-MX`) solo cuando los precios, los envíos, las condiciones legales o los catálogos difieran; de lo contrario, segmenta por idioma (`es`). * `gt-next` ofrece enrutamiento por prefijo de ruta, prefijos opcionales para la configuración regional predeterminada y slugs localizados mediante `pathConfig`. ## Related questions - [¿Qué es hreflang y cómo se configura?](https://generaltranslation.com/es/kb/what-is-hreflang.mdx): Hreflang le indica a Google qué URL son versiones de la misma página en otros idiomas o regiones, para que pueda mostrar la adecuada en los resultados de búsqueda. Agrégalo con etiquetas link de HTML, cabeceras HTTP Link o un mapa del sitio, asegúrate de que todos los enlaces sean recíprocos y usa códigos válidos como en-GB, no en-UK. - [Redirecciones de idioma y SEO: ¿URL, cookie o Accept-Language?](https://generaltranslation.com/es/kb/locale-routing-seo.mdx): Deja que la URL determine el idioma de cada página que quieras indexar, porque Googlebot no envía la cabecera Accept-Language y rastrea sobre todo desde direcciones de EE. UU. Recurre a la preferencia guardada en una cookie y, en su defecto, a Accept-Language solo para decidir adónde redirige una raíz neutral como /, mediante una redirección temporal 302 o 307. - [¿Cómo configuro el SEO de una aplicación de Next.js multilingüe?](https://generaltranslation.com/es/kb/multilingual-nextjs-seo.mdx): Asigna a cada idioma su propia URL con prefijo, como /en/about y /es/about, y luego publica html lang, una URL canónica autorreferente, versiones alternativas hreflang con x-default, un título y una descripción traducidos, y una entrada en el mapa del sitio para cada idioma publicado. Marca con noindex las versiones no publicadas. gt-next de General Translation dirige cada idioma a su propia URL y traduce los títulos con getGT. - [¿Cómo hago que un sitio web sea multilingüe?](https://generaltranslation.com/es/kb/make-website-multilingual.mdx): Elige dónde se alojarán las traducciones (en un proxy, un plugin de CMS, un creador de sitios web o tu propio código) y después asigna a cada idioma su propia URL, tal como recomienda Google. Traduce las páginas completas, además de los títulos y las metadescripciones, vincula las versiones con hreflang y ofrece un selector de idioma en lugar de redirigir automáticamente a los visitantes. ## Previous and next questions - Previous question: [Redirecciones de idioma y SEO: ¿URL, cookie o Accept-Language?](https://generaltranslation.com/es/kb/locale-routing-seo.mdx) - Next question: [¿Cómo agrego i18n a una aplicación de Next.js con App Router?](https://generaltranslation.com/es/kb/add-i18n-to-nextjs.mdx) ## Sitemap See the [Knowledge Base sitemap](https://generaltranslation.com/es/kb/sitemap.md) for every article.