Subdominios o subdirectorios: qué dice Google y cómo decidir tu estructura
Tabla de contenidos
El mismo contenido puede vivir en ejemplo.com/blog o en blog.ejemplo.com. Elegir entre subdominios o subdirectorios parece una decisión de algoritmo, pero Google documenta que es una decisión de negocio: cambia cómo mides, qué funciones te tratan como sitio aparte y cuánto cuesta moverte.
Subdominios o subdirectorios: qué es cada uno
Un subdirectorio es una ruta dentro del mismo host: ejemplo.com/blog/. Un subdominio es otro hostname, blog.ejemplo.com, con su propia entrada DNS, su propio certificado y, si quieres, otro servidor.
La regla mental del tema: el subdirectorio divide contenido; el subdominio divide infraestructura. Esa diferencia es la que después aparece en la medición, en los rastreadores y en el coste de moverte.
Por qué la máquina los distingue
Google define "sitio" por hostname en dos funciones. En los favicons: "one favicon per site, where a site is defined by the hostname"; por eso https://news.example.com puede tener el suyo y https://example.com/news no, porque es un subdirectorio. En los nombres de sitio: "one site name per site, where a site is defined by the domain or subdomain", y no se admiten a nivel de subdirectorio. Hay piezas del buscador que solo existen por hostname: una carpeta no las puede tener propias; un subdominio sí.
Cookies, certificados y despliegue
Las cookies se emiten por host: blog.ejemplo.com no ve las de ejemplo.com salvo que se declaren para el dominio padre con Domain=ejemplo.com. Un certificado wildcard cubre los subdominios; el subdirectorio vive dentro del certificado del dominio. Y el subdominio permite otro servidor, otra región u otro CDN: la propia documentación de Google lo lista como ventaja.
Lo que dice Google (y lo que nadie te puede decir)
La respuesta oficial está en la guía de iniciación al SEO: "From a business point of view, do whatever makes sense for your business". Decide por conveniencia de gestión, no por una supuesta ventaja de posicionamiento.
No existe en la documentación oficial ningún factor de posicionamiento por usar uno u otro, ninguna penalización a los subdominios ni ninguna regla que los trate como sitios ajenos: el informe de enlaces agrupa por dominio raíz, que suma la raíz, los subdominios y las carpetas.
Por qué se repite que "los subdominios posicionan peor"? Porque lo observado en la práctica suele ser el efecto de repartir infraestructura y enlaces internos, no una decisión de Google sobre el hostname. Si alguien te da un porcentaje, pide la fuente oficial: no existe.
El caso multi-idioma: la única tabla oficial
La documentación de sitios multi-región es la única que compara las opciones con pros y contras:
| Opción | Ejemplo | Ventajas (doc) | Inconvenientes (doc) |
|---|---|---|---|
| Dominio por país (ccTLD) | ejemplo.de | Geolocalización clara; la ubicación del servidor es irrelevante; separación de sitios fácil | Caro; más infraestructura; un solo país |
| Subdominio con gTLD | de.ejemplo.com | Fácil de montar; permite ubicaciones de servidor distintas; separación de sitios fácil | El usuario puede no reconocer el geotargeting en la URL |
| Subdirectorio con gTLD | ejemplo.com/de/ | Fácil de montar; mantenimiento bajo (mismo host) | Una sola ubicación de servidor; separar sitios es más difícil |
| Parámetros de URL | ejemplo.com?loc=de | - | No recomendado por Google |
Y el detalle que todos se saltan: el subdominio de idioma no comunica el idioma. La documentación de hreflang avisa de que en o de en un subdominio no determinan el público objetivo; para eso está hreflang, no el nombre del host. Lo desarrollamos en la guía de web multilingüe.
Dónde sí se nota la diferencia
Search Console: propiedades y verificación
Una propiedad con prefijo de URL "includes only URLs with the specified prefix, including the protocol": no incluye subdominios, y la ayuda pide una propiedad por cada subdominio. La propiedad de dominio agrega todos los subdominios y protocolos y se verifica solo por DNS.
Traducción práctica: si mueves el blog a un subdominio y usas una propiedad con prefijo, tu panel deja de verlo el primer día. Ver Search Console y propiedades de plataforma.
El informe de enlaces y los falsos "externos"
El informe de enlaces agrupa por dominio raíz: quita protocolo, subdominio y subdirectorios. Pero "externo" significa fuera de tu propiedad: con una propiedad con prefijo, un enlace de tu propio subdominio puede aparecer como sitio externo. No es un enlace malo, es cómo agrupa el informe. Ver enlazado interno.
robots.txt: uno por host
La documentación de robots.txt es tajante: las reglas aplican solo al host, protocolo y puerto, y un robots.txt de subdominio solo vale para ese subdominio. Si trasladas /blog/ a blog.ejemplo.com, hay que crear el del nuevo host. Ver robots.txt.
Favicon, nombre del sitio y sitelinks
El subdominio gana en lo que solo existe por hostname: favicon y nombre de sitio propios, que el subdirectorio no puede tener. Si el subdominio no declara datos estructurados en su home, Google puede usar el nombre del dominio padre como respaldo. Los sitelinks, en cambio, se generan a nivel de dominio.
Cuándo conviene un subdominio
- Otro stack o software: centro de ayuda, documentación, foro o tienda en otra plataforma.
- Otra infraestructura: otro servidor, región o CDN.
- Otro equipo y despliegue: ciclos de publicación independientes.
- Identidad propia: un producto con su propio nombre y favicon.
- Entornos de prueba:
staging.ytest..
El coste: verificación y medición por separado, robots.txt propio, favicon y nombre propios, y una migración futura más cara.
Cuándo conviene un subdirectorio
- Blog, noticias y guías del mismo tema que el dominio principal.
- Categorías y secciones de un mismo negocio.
- Versionado por idioma o país con gTLD (
/es/,/en/), que Google marca como "low maintenance (same host)". - Piezas compartidas: un robots.txt, un sitemap, un certificado, un despliegue y una propiedad de Search Console.
- Migración futura barata: mover rutas dentro del dominio no requiere Change of Address; cambiar de host, sí.
Con el mismo contenido, enlaces y velocidad de servidor, Google no documenta ninguna ventaja de ranking por usar una carpeta. Si te venden lo contrario, que enseñen la fuente oficial: no existe.
Cuatro errores caros (y uno que no funciona)
Mudarse de host no te saca de una penalización
Las políticas de spam incluyen la elusión: crear subdominios o subdirectorios nuevos para seguir violando las reglas es uno de los patrones que describe la documentación. Y la política de reputación del sitio cubre publicar contenido de terceros en un host por su autoridad previa. Mover contenido problemático a blog. o a /blog/ no es una estrategia.
Staging indexado y contenido duplicado
Dos clásicos: un staging.ejemplo.com rastreable que se indexa y confunde los datos, y un blog.ejemplo.com y un ejemplo.com/blog/ sirviendo lo mismo a la vez. El primero se bloquea o se protege; el segundo se decide y se redirige con 301 al elegido.
Y dos errores de medición que cuestan caro: verificar solo una propiedad y creer que cubre todo el dominio, y olvidar el Change of Address cuando cambia el host.
Cómo migrar de un subdominio a un subdirectorio (o al revés)
- Inventario de URLs: las que tienen enlaces, tráfico o son de paginación.
- Mapa de redirecciones 301 uno a uno hacia la URL equivalente, no todo a la home.
- Comprobar con la Inspección de URL que cada 301 resuelve a una sola URL final.
- Change of Address solo si cambia el host: la documentación de movimientos de sitio aclara que no hace falta para HTTP a HTTPS, www o non-www, ni para mover rutas dentro del mismo dominio.
- Mantener las redirecciones al menos un año.
- Actualizar enlaces internos, sitemaps y plantillas.
- Vigilar las 4 a 6 semanas siguientes y no concluir con 48 horas de datos.
Nota honesta: una mudanza siempre tiene coste de reordenación; el objetivo es no perder URLs ni señales por errores propios. Si el tráfico cae, el diagnóstico está en caída de tráfico.
Checklist: cómo decidir en 10 minutos
- Mismo tema y negocio que el dominio: subdirectorio.
- Otro stack, servidor o despliegue: subdominio.
- Multi-idioma o multi-región: subdirectorio por país; si la infraestructura exige servidores separados, subdominio más hreflang.
- Medir todo junto: propiedad de dominio, con filtro por host si quieres detalle.
- Favicon o nombre de sitio propios: solo con hostname propio.
- Reglas de rastreo distintas: robots.txt propio por host.
- Contenido de terceros: revisa la política de reputación antes de alojarlo.
- Coste de volver atrás: escribe el plan de redirecciones antes de empezar.
- Verifica la propiedad en Search Console el día 1.
- Documenta la decisión, la fecha y la métrica que la justificó.
No hay un formato de URL que Google premie: hay una decisión de negocio con consecuencias técnicas medibles. Un subdirectorio da simplicidad, medición conjunta y migraciones baratas; un subdominio da infraestructura independiente y funciones propias por hostname, a cambio de configuración y de datos que dejan de ser automáticos.
Elige con la checklist, escribe el plan de migración y no le pidas al hostname lo que solo consigue un contenido mejor. Si te interesa el formato de la URL, el detalle está en URLs amigables.