- Google no documenta una regla de ranking a favor de subdominios o de subdirectorios. John Mueller ha dicho que, en general, los ve igual, y que él intentaría mantener el contenido junto.
- Mi criterio por defecto: subdirectorio para blog, servicios y contenidos del negocio; subdominio cuando hay una razón técnica u organizativa real (aplicación, tienda en otra plataforma, UGC, infraestructura distinta).
- Para Google, el host es una frontera técnica: cada subdominio tiene su
robots.txt, y en Search Console una propiedad de prefijo de URL no incluye los subdominios; la de dominio sí. - Los problemas reales no vienen de elegir mal entre los dos, sino de lo que se deja suelto: hosts de staging indexados, subdominios huérfanos y wildcard DNS que responde a cualquier nombre.
- Cambiar de uno a otro es una migración: redirecciones 301 uno a uno, enlazado actualizado y seguimiento durante meses. Solo por SEO rara vez compensa.
- Se audita en tres pasos: inventario de hosts,
site:por host yrobots.txtde cada host.
La pregunta «¿blog en subdominio o en subdirectorio?» suele llegar cuando ya hay un blog en blog.tudominio.com que no despega o una migración de plataforma que obliga a decidir. Casi todo lo que se publica sobre el tema se queda en una lista de ventajas y en un «depende», sin separar lo que Google ha dicho de lo que son opiniones de la industria.
Aquí separo ambas cosas. Cubro qué ha dicho Google, cuándo elijo cada opción, qué cambia en Search Console, robots.txt, cookies y migraciones, los errores que más daño hacen y cómo audito una estructura de hosts. También cuento cómo está organizada mi propia web, con lo que puedo ver y lo que no.
Subdominio y subdirectorio: dónde está la diferencia técnica
En https://blog.ejemplo.com/articulo/, el host es blog.ejemplo.com y la ruta es /articulo/. El subdominio es un nombre más a la izquierda del dominio, y puede apuntar a otro servidor, otra plataforma, otro certificado y otra configuración. Un subdirectorio, como ejemplo.com/blog/, vive en el mismo host que el resto de la web y comparte con ella robots.txt, certificado y configuración de servidor.
Esa diferencia no es de ranking, es operativa: lo que se configura «por host» se configura por duplicado cuando hay subdominios. Por eso la decisión pesa más en el mantenimiento que en el algoritmo.
Qué dice Google sobre subdominios y subdirectorios
No he encontrado en la documentación de Google Search Central una página que diga «usa subdominios» o «usa subdirectorios» para un sitio en general. Lo que existe son declaraciones de John Mueller y documentación sobre aspectos concretos (robots.txt, Search Console, sitios multirregionales).
- En una sesión de office hours recogida por Search Engine Journal en mayo de 2018, Mueller dijo: «In general, we see these the same». Añadió que personalmente intentaría «keep things together as much as possible» y que, si no tienes preferencia, lo mantendría dentro del mismo sitio.
- Ahrefs recoge una declaración de Mueller de 2017 según la cual la búsqueda web de Google funciona bien con subdominios y con subdirectorios. Semrush cita de la misma época que Google tiene que aprender a rastrearlos por separado, pero que en su mayor parte «es solo una formalidad». Estas dos citas las tomo de esos artículos y no he podido contrastarlas con el vídeo original.
La lectura honesta es esta: ambas estructuras son válidas, Google no promete un trato idéntico en todos los casos y la mayoría de afirmaciones del tipo «los subdirectorios posicionan más» salen de casos de migración donde cambiaron más cosas a la vez (enlazado interno, plataforma, contenido). Ahrefs lo desarrolla con ejemplos de cambios de estructura en los que costaba aislar el efecto de la URL.
Cuándo elijo subdirectorio
Es mi opción por defecto cuando el contenido pertenece al mismo negocio y al mismo tema que la web principal: blog, guías, servicios, fichas de producto, páginas de ubicación. Hay tres motivos prácticos.
- Una sola cosa que mantener. Un robots.txt, un certificado, una propiedad de Search Console, un sitemap XML principal, una analítica.
- Enlazado interno natural. El blog enlaza a servicios y los servicios al blog con rutas relativas y sin saltar de host.
- Coherencia con la recomendación de Mueller de mantener las cosas juntas cuando no hay razón para separarlas.
Un blog de contenidos que sostiene los servicios de la web es el caso más claro. Si ya existe en un subdominio y funciona, no lo muevo solo por SEO: lo explico en la sección de migraciones.
Cuándo tiene sentido un subdominio
Un subdominio es la herramienta correcta cuando hay algo que separar de verdad. Estos son los casos en los que lo acepto sin discutir:
| Caso | Por qué separa | Qué vigilar |
|---|---|---|
| Aplicación o área de cliente | Otro código, otro servidor, a menudo tras login | Que no se indexen pantallas sin valor |
| Tienda en otra plataforma | La plataforma obliga a su propio host | Enlazado entre tienda y web, y analítica unificada |
| Idiomas con infraestructura distinta | Otro servidor, otro equipo, otra ubicación | hreflang correcto y propiedades en Search Console |
| Contenido de usuarios (UGC) | Aísla riesgos de calidad y moderación | Moderación y control de lo que se indexa |
| Razones técnicas u organizativas | Otro hosting, otro CMS, otro equipo | Que alguien se haga responsable de cada host |
Para sitios internacionales, la documentación de Google sobre sitios multirregionales compara tres estructuras. Los subdominios con gTLD aparecen como «fáciles de configurar», con posibilidad de distintas ubicaciones de servidor y fácil separación de sitios. Los subdirectorios aparecen con bajo mantenimiento por compartir host, pero con una sola ubicación de servidor y con la separación de sitios más difícil. En ambos casos Google señala que los usuarios pueden no reconocer el geotargeting solo por la URL. Si cada idioma va en su host, las versiones se declaran con hreflang, no se dejan al dominio. Y quien llega sin versión propia necesita un destino por defecto, el papel del valor x-default de hreflang.
Prueba de la frase: si no puedes explicar en una línea por qué esa parte necesita su propio host (otra plataforma, otro equipo, otro servidor), probablemente te vale un subdirectorio.
Search Console: propiedad de dominio frente a prefijo de URL
Según la ayuda de Search Console, una propiedad de dominio incluye todos los subdominios (m, www y los que tengas) y varios protocolos (http, https, ftp), y solo se verifica mediante registro DNS. Una propiedad de prefijo de URL incluye solo las URL con ese prefijo exacto, protocolo incluido, y la propia ayuda aclara que los subdominios, como m.example.com, no están incluidos en ese prefijo.
En la práctica, con subdominios yo creo siempre la propiedad de dominio para tener la visión global y añado prefijos solo cuando un equipo necesita acceso limitado a un host. Si tu proveedor de DNS no te deja verificar por registro, antes de elegir estructura conviene resolver quién controla el DNS: es un requisito de gobierno, no solo técnico.
robots.txt y noindex: cada host, lo suyo
La documentación de Google lo dice claro: el archivo robots.txt debe estar en la raíz del host al que se aplica, y sus reglas solo valen para el host, protocolo y puerto donde se aloja. Un robots.txt en https://example.com/ es válido para esa dirección y sus subdirectorios, pero no para https://other.example.com/, http://example.com/ ni https://example.com:8181/. Google también indica que no puede colocarse en un subdirectorio.
Las consecuencias son concretas. Si bloqueas el staging con un Disallow: /, ese bloqueo solo cubre el host de staging. Y al revés: el robots.txt de tu dominio principal no protege nada de un subdominio. Tienes más detalle de sintaxis y casos en mi guía de robots.txt.
Hay una trampa conocida: robots.txt no es un mecanismo para sacar URLs del índice. Para que noindex funcione, la página no debe estar bloqueada por robots.txt; si lo está, el rastreador nunca ve la regla. Para un staging, lo más fiable es combinar acceso restringido (autenticación) con noindex mientras exista, no un bloqueo en robots.txt solo.
Cookies, analítica y enlazado interno
Con un solo host todo esto viene resuelto. Con subdominios hay tres puntos que se estropean sin avisar.
- Cookies. Según MDN, una cookie sin atributo
Domainestá disponible en el servidor que la establece pero no en sus subdominios; si se especificaDomain, sí lo está en ese dominio y sus subdominios. Si el login o el consentimiento se guardan en cookies, hay que decidir su alcance. - Analítica. Una sesión que cruza de
wwwatiendapuede contarse como dos si la configuración de la herramienta no contempla ambos hosts. No lo he verificado contra la documentación actual de GA4, así que compruébalo con tu implementación antes de fiarte de los informes. - Enlazado interno. Los enlaces entre subdominios son enlaces entre hosts: hay que mantenerlos como enlaces normales, rastreables y con la URL canónica final. Google recomienda enlazar de forma consistente a la URL que consideras canónica, algo que explico en mi artículo sobre canonicals.
Migrar entre subdominio y subdirectorio
Pasar de blog.ejemplo.com a ejemplo.com/blog/ es una migración con cambio de URLs. La guía de Google sobre migraciones recomienda redirecciones permanentes del lado del servidor (301 u otros permanentes), indica que no causan pérdida de PageRank, avisa de evitar las cadenas de redirecciones y pide mantenerlas «generally at least 1 year», o indefinidamente por los usuarios.
- Haz el mapa de URLs antiguas a nuevas, una por una, sin mandar todo a la home.
- Actualiza canonical, sitemap y enlaces internos a las URLs nuevas.
- La herramienta de cambio de dirección de Search Console, según esa guía, se necesita al pasar de un dominio o subdominio a otro; la guía no trata de forma explícita el paso de subdominio a subdirectorio.
- Vigila el rastreo y la indexación durante semanas con ambas propiedades abiertas.
Ahrefs concluye, tras revisar varios casos, que cambiar solo por SEO introduce riesgos y probablemente no compense. Comparto el criterio: si el subdominio es coherente con su función, lo dejo; si es un blog corporativo aislado sin motivo, la migración se puede justificar, pero planificada y medida. Si necesitas acompañamiento en el proceso, encaja en migraciones SEO, y la decisión previa sobre cómo organizar los hosts, en arquitectura web SEO.
Errores típicos con subdominios
Blog en subdominio sin necesidad
Es el más frecuente: un blog en blog. porque el CMS o el hosting lo facilitó en su día, sin ninguna razón técnica. Quedan dos hosts que mantener y un contenido separado del resto de la web. No es un error que penalice, pero es una complejidad que se podría evitar.
Entornos de staging indexados
Un staging. o dev. accesible sin contraseña y sin noindex puede acabar rastreado e indexado si alguien lo enlaza o lo incluye en un sitemap. La solución es acceso restringido por autenticación; el robots.txt del staging solo no basta, por lo que vimos con noindex.
Subdominios huérfanos
Hosts antiguos (campañas, microsites, pruebas) que siguen resolviendo, a veces con un certificado caducado y contenido desfasado. Nadie los enlaza, nadie los mantiene y siguen a la vista. Inventariarlos es el primer paso de la auditoría.
Wildcard DNS
Un registro DNS comodín (*.ejemplo.com) hace que cualquier subdominio inventado resuelva. Si el servidor responde 200 con la home en lugar de un error, cualquier nombre puede mostrar contenido duplicado, y en un sitio grande el duplicado es de lo que más presupuesto de rastreo consume. Google, en su guía de URLs duplicadas, menciona que el certificado debe coincidir con la URL completa o ser un certificado wildcard; el wildcard es válido, pero exige que el servidor decida qué hosts existen. Qué hace Googlebot exactamente con hosts inventados no está documentado, y no lo doy por hecho.
Otros dos
Copiar el robots.txt de staging, con su bloqueo total, a producción, y retirar a los pocos meses las redirecciones de una migración.
Cómo lo tengo en mi web
He leído el código de cristofercruz.net para esta sección, así que solo cuento lo que se ve en él.
| Qué reviso | Qué hay hoy |
|---|---|
| Blog | En subdirectorio: /blog/ y un artículo por carpeta, como /blog/robots-txt/ |
| Servicios | En subdirectorio: /servicios/ (auditoría, consultoría, migraciones, entre otros) |
| Ubicaciones | Páginas como /consultor-seo-salamanca/ en la raíz del mismo host, más un índice en /ubicaciones/ |
| Herramientas y casos | /herramientas/ y /casos-de-exito/, también como carpetas |
| Dominio canónico | La constante SITE_URL es https://cristofercruz.net y el canonical de cada página se construye a partir de ella |
| robots.txt | Uno solo, en la raíz. Bloquea carpetas internas como /includes/, /tools/ y /contact-private/, y declara dos sitemaps (/sitemap.xml y /blog/sitemap.php) |
| Subdominios | No encuentro referencias a ninguno en el código, enlaces ni sitemaps |
Lo que no puedo afirmar desde el código es el estado del DNS: si existe algún registro comodín o algún subdominio que no se use es algo que se comprueba en el panel del proveedor, no en el repositorio. Tampoco puedo confirmar desde aquí cómo redirige el servidor la variante con www o con http a la versión canónica; mi documentación interna lo marca como dependiente del servidor y sin tocar. Es una de las comprobaciones de la sección siguiente que haría yo mismo con curl.
Elegí subdirectorios porque todo el contenido es del mismo negocio y lo mantengo yo, sin plataformas ni equipos separados. No tengo ninguna aplicación ni tienda que justifique un host propio. Si mañana la tuviera, un subdominio sería la opción razonable.
Cómo auditar una estructura con subdominios
- Inventario de hosts. Zona DNS del dominio, certificados emitidos, enlaces salientes de la web y las propiedades que ya existen en Search Console. Con una propiedad de dominio verificada, los informes ya agrupan los subdominios.
site:por host. Una consulta por cada host (site:blog.ejemplo.com) para ver qué hay indexado. Es una aproximación, no un recuento exacto.- robots.txt de cada host. Abre
/robots.txten cada uno y comprueba que no hay un bloqueo total heredado ni ausencia de archivo donde debería haberlo. - Host inventado. Pide una URL de un subdominio que no existe. Debe fallar o dar un error, no devolver la home con un 200.
curl -I https://blog.ejemplo.com/robots.txt
curl -I https://nombre-inventado-123.ejemplo.com/
curl -I http://ejemplo.com/ | grep -i locationLos dos primeros comandos cubren los pasos 3 y 4; el tercero comprueba a dónde redirige la variante sin cifrar. Si quieres que lo revise alguien con tu inventario real, es parte de una auditoría SEO técnica.
Para staging, no confíes en una sola capa: autenticación en el servidor, noindex mientras exista y, si lo retiras, que el host deje de resolver o devuelva un error.
Preguntas frecuentes
¿Es mejor un subdominio o un subdirectorio para SEO?
Google no documenta una preferencia. Mueller ha dicho que en general los ve igual y que intentaría mantener las cosas juntas. Mi criterio: subdirectorio por defecto, subdominio con una razón técnica u organizativa clara.
¿Los subdominios se consideran parte del mismo sitio?
Depende de qué parte de Google mires. En Search Console, la propiedad de dominio los incluye y la de prefijo no. En robots.txt, cada host es independiente. Sobre cómo se agrupan las señales de ranking, lo que hay son declaraciones de Mueller, no una especificación.
¿Dónde pongo el blog?
Si el blog apoya los servicios o productos de tu web, en un subdirectorio como /blog/. Un subdominio tiene sentido si el blog corre en otra plataforma que lo obliga o lo gestiona otro equipo.
¿Necesito un robots.txt por cada subdominio?
Si quieres reglas en ese host, sí: Google indica que un robots.txt solo es válido para el host, protocolo y puerto donde se aloja. Si un subdominio no tiene archivo, el del dominio principal no le aplica.
¿Cambiar de subdominio a subdirectorio mejora el posicionamiento?
No está garantizado. Los casos publicados de mejora suelen incluir otros cambios a la vez. Es una migración con riesgo: hacen falta redirecciones 301 una a una y seguimiento. No la haría solo por SEO si el subdominio funciona.
¿Cómo veo todos mis subdominios en Search Console?
Con una propiedad de dominio, que se verifica por DNS e incluye todos los subdominios. Con propiedades de prefijo necesitas una por cada host.
¿Es un problema tener wildcard DNS?
No en sí mismo, pero obliga a que el servidor responda con un error a los hosts que no existan. Si todos devuelven la home con 200, tienes contenido duplicado accesible bajo nombres inventados. Cómo trata Googlebot esos casos no está documentado.
Fuentes
- Add a website property to Search Console Ayuda de Search Console
- How Google interprets the robots.txt specification Google Search Central
- Create and submit a robots.txt file Google Search Central
- Block Search indexing with noindex Google Search Central
- Site moves with URL changes Google Search Central
- Managing multi-regional and multilingual sites Google Search Central
- How to specify a canonical URL Google Search Central
- Google treats subdomains and subdirectories the same, John Mueller says Search Engine Journal
- Subdominio vs. subdirectorio Ahrefs
- Using HTTP cookies MDN
