SEO Técnico

Subdominio vs subdirectorio SEO: guía de decisión 2026

Subdominio vs subdirectorio SEO en 2026: por qué gana el subdirectorio, el mecanismo real que hay detrás y cuándo un subdominio sí es correcto.

SB
Consultor SEO Senior
Publicado el 25 de agosto de 2026 · 12 min de lectura
X in
Diagrama geométrico abstracto de dos rutas que divergen desde un nodo blanco, una desprendiéndose en un grupo flotante con conectores rotos y otra anidada dentro de un marco continuo, con un nodo carmesí en la bifurcación

Subdominio vs subdirectorio SEO es la decisión de si una sección de tu web vive en blog.ejemplo.com o en ejemplo.com/blog. A diferencia de la mayoría de decisiones de SEO técnico, esta es arquitectónica: es barata antes de lanzar, cara después, y casi nadie la revisa una vez que el CMS está montado.

La posición de Google no ha cambiado desde 2012, cuando Matt Cutts dijo que subdominios y subdirectorios son prácticamente equivalentes y recomendó elegir el que fuera más fácil de configurar. John Mueller lo repitió en un office-hours de Google en 2017: “Desde nuestro punto de vista, cuando hablamos con el equipo de search quality, dicen que subdominios y subdirectorios son esencialmente equivalentes.” La postura contraria de Moz, sostenida durante años, es que el subdirectorio es la opción por defecto más segura y que el subdominio se reserva sobre todo para variantes de idioma.

Así que las dos afirmaciones son ciertas a la vez: los sistemas de ranking de Google no penalizan los subdominios, y los equipos sí ven subir el tráfico cuando mueven un blog de subdominio a subdirectorio. Esa contradicción es la razón de que se lleve una década discutiendo el tema, y explica por qué todos los artículos escritos sobre él van con pies de plomo.

La contradicción se resuelve en cuanto dejas de mirar la URL y empiezas a mirar qué más cambió.

Qué diferencia realmente a un subdominio de un subdirectorio

Un subdirectorio es una ruta dentro del mismo host. ejemplo.com/blog se sirve desde el mismo registro DNS, normalmente desde el mismo servidor y —esto es lo importante— normalmente desde el mismo CMS y la misma plantilla que el resto de la web.

Un subdominio es un host distinto. blog.ejemplo.com tiene su propia entrada DNS. Puede apuntar a otra IP, a otro servidor, a una plataforma completamente distinta. Esa flexibilidad es exactamente por lo que los equipos lo eligen, y exactamente por lo que da problemas.

Google tiene que determinar, sitio por sitio, si un subdominio forma parte de la misma propiedad o es algo ajeno. Para blog.ejemplo.com en un dominio que Google ya entiende, esa determinación es trivial e inmediata. Para clientes.ejemplo.com alojando contenido de usuarios en una plataforma de terceros, no lo es — y Google puede decidir razonablemente tratarlos de forma distinta.

Ese es el resumen técnico honesto. Todo lo demás en este debate es un argumento sustituto de algo operativo.

Por qué gana el subdirectorio, y por qué la explicación habitual está mal

La explicación estándar es que el link equity se “escapa” o se “reparte” al cruzar la frontera del subdominio y se consolida en el subdirectorio. Se repite en casi todos los artículos que ocupan la primera página. Es también la parte más débil del argumento, porque Google lleva más de una década diciendo lo contrario y nadie ha descrito nunca el mecanismo de esa fuga.

Esto es lo que veo de verdad cuando audito estos montajes. Por mi experiencia auditando sitios con el blog en un subdominio, las mismas cuatro cosas se cumplen casi siempre:

  1. El subdominio corre sobre otro CMS. La web corporativa está en Webflow o en un stack a medida; el blog está en WordPress. Dos sistemas, dos plantillas, dos ciclos de despliegue.
  2. No está en el menú principal. O está, pero el enlace es de ida — la web principal enlaza al blog y la cabecera del blog es una versión recortada que no devuelve enlaces a las páginas comerciales.
  3. El enlazado interno se detiene en la frontera. Los posts enlazan a otros posts. Casi nunca enlazan a la página de precios, a las páginas de servicio o a las de categoría, porque quien los escribe trabaja en otra herramienta y no tiene esas URLs a mano.
  4. Analytics y Search Console están separados. Dos propiedades, dos paneles, y nadie mirando la foto conjunta.

Ninguna de esas cosas la causa el punto en lugar de la barra. Todas las causa la separación que el subdominio permite. El subdominio no te perjudica: elimina la fricción que si no te obligaría a integrar.

Cuando un equipo migra a subdirectorio, arregla las cuatro de golpe, porque el subdirectorio hace difícil no hacerlo. Y después atribuye la subida de tráfico al cambio de URL. Esa mala atribución es el error más común de todo este tema.

Esto importa porque te dice qué hacer si estás atrapado en un subdominio por razones que no puedes cambiar: arregla los cuatro puntos anteriores y recuperas la mayor parte de la diferencia. Y también te dice que migrar a subdirectorio manteniendo el blog en una plantilla aparte y sin enlazado interno va a servir de poco. He visto exactamente ese resultado, y el post-mortem siempre es incómodo.

Los cuatro casos en los que el subdominio es la decisión correcta

Poner el subdirectorio por defecto es un buen consejo. Pero “por defecto” no es “siempre”, y las excepciones son reales:

Un producto o una audiencia genuinamente distintos. Si el contenido sirve a otra gente con otra intención y nunca ibas a enlazarlo desde tus páginas comerciales, el beneficio de integrar no existe. La documentación técnica de una API es el ejemplo clásico.

Una plataforma alojada por un tercero. Centros de ayuda en Zendesk o Intercom, comunidades en Discourse, páginas de estado en Statuspage: esos proveedores sirven desde su propia infraestructura. Normalmente puedes apuntarles un subdominio por CNAME. Llevarlos a una ruta de subdirectorio exige un proxy inverso, que puede compensar o no.

Aislamiento técnico que necesitas de verdad. Una SPA con otra postura de seguridad, otra cadencia de despliegue u otra configuración de CDN. Forzarla al host principal para satisfacer una preferencia de SEO es mal negocio cuando la ganancia es modesta y el riesgo de ingeniería no lo es.

Separación regulatoria o de infraestructura. Requisitos de residencia de datos, una entidad jurídica distinta o una marca filial que acabará vendiéndose. Decisiones estructurales que sobreviven al argumento SEO.

Fíjate en lo que no está en la lista: “nuestro blog está en WordPress y la web principal no”. Es la razón que más se da, y es un argumento de comodidad, no de arquitectura. Es justo el caso que resuelve un proxy inverso.

El marco de decisión: subdominio o subdirectorio

Cuatro preguntas, en orden. Párate en el primer “sí”.

  1. ¿Hay un requisito legal, regulatorio o de residencia de datos que obligue a separar? Si sí, subdominio. La conversación SEO se acabó.
  2. ¿El contenido lo aloja un tercero al que no puedes servir por proxy? Si sí, subdominio — y trátalo como una propiedad aparte a la que enlazas deliberadamente y desde la que enlazas de vuelta.
  3. ¿Enlazarías este contenido desde y hacia tus páginas comerciales alguna vez? Si no, el subdominio va bien. No gana nada integrándose porque nunca ibas a integrarlo.
  4. ¿Hay una restricción de ingeniería real que un proxy inverso no pueda resolver? Si no, subdirectorio.

La mayoría de equipos llega a la pregunta cuatro y descubre que la respuesta es no. Ese es el sentido de ir en orden: separa las restricciones genuinas de las preferencias de comodidad disfrazadas de restricción.

Si estás tomando esta decisión dentro de un proyecto más amplio, va en la misma conversación que tu arquitectura web y jerarquía de URLs, no en un ticket técnico aparte.

Cómo migrar de subdominio a subdirectorio

Si ya has decidido moverlo, el orden importa más que la velocidad. Esto es una migración web con todos los riesgos habituales, y que ocurra dentro de un mismo dominio no la vuelve segura.

  1. Rastrea y exporta el subdominio entero. Todas las URLs indexables, su tráfico actual y sus enlaces entrantes. Esta es tu línea base y tu lista de origen para las redirecciones.
  2. Construye un mapa de redirecciones uno a uno. Cada URL antigua con un destino específico. No redirijas todo a la home de la nueva sección: Google lo trata como soft 404 y tiras a la basura la señal de posicionamiento que intentas conservar.
  3. Reconstruye las plantillas en el destino. Mismo menú, mismo footer, mismas migas de pan que el resto del sitio. Si te saltas esto, has movido la URL y te has quedado el problema.
  4. Monta el enlazado interno antes del corte. Enlaces contextuales desde la nueva sección hacia tus páginas comerciales, y desde las páginas comerciales relevantes hacia la nueva sección. Aquí es donde vive la ganancia real — la guía de enlazado interno explica cómo priorizar esos enlaces.
  5. Publica los 301 y mantenlos para siempre. No un año. Para siempre.
  6. Añade el destino a Search Console y conserva la propiedad antigua. Necesitas la propiedad antigua para ver cómo las URLs del subdominio salen del índice y para cazar errores de redirección. No la borres.
  7. Monitoriza entre seis y ocho semanas. Espera una caída en las semanas uno a tres. Juzga el resultado en la semana ocho, no en la dos.

Los sitios que siguen esta secuencia normalmente se recuperan y superan la línea base anterior. Los que se saltan los pasos tres y cuatro normalmente acaban donde estaban, después de gastarse un trimestre en ello.

La opción del proxy inverso que nadie menciona

Hay una tercera vía, y apenas aparece en los resultados para esta keyword. Un proxy inverso te permite servir una aplicación alojada aparte en una ruta de subdirectorio de tu dominio principal. La petición llega a ejemplo.com/blog, tu capa de edge la reenvía a la instancia de WordPress, y la respuesta vuelve desde tu host principal.

Cloudflare documenta este patrón de forma explícita para Workers, y la mayoría de CDNs y plataformas de edge soportan algo equivalente. Te da el beneficio arquitectónico del subdirectorio sin fusionar los stacks tecnológicos — que es la restricción que de verdad tienen la mayoría de equipos.

No es gratis. Asumes latencia en la capa de proxy, una configuración de caché que hay que afinar y un nuevo modo de fallo cuando la plataforma de origen cambie su enrutado. Pero si la única razón por la que estás en un subdominio es “el blog corre sobre otro CMS”, esta es la respuesta, y merece la pena valorarla antes de casarte con cualquiera de los dos bandos. Una revisión de SEO técnico previa te dirá si el coste del proxy se justifica con tu volumen de tráfico.

¿Cambia algo en webs internacionales?

En parte. Las variantes de idioma y de país son el único caso donde el subdominio tiene defensores con argumentos, y Google admite subdominios, subdirectorios y ccTLDs por igual para segmentación geográfica.

El argumento práctico sigue favoreciendo al subdirectorio para la mayoría de negocios: una propiedad que consolidar, un juego de plantillas, una superficie de rastreo. El subdominio tiene más sentido cuando las webs de cada país son operativamente independientes: equipos distintos, catálogos distintos, calendarios de publicación distintos. La implementación de hreflang es idéntica en ambos casos, y acertar ahí importa más que el contenedor que elijas. Si estás valorándolo, la guía de SEO internacional cubre la comparación completa incluyendo ccTLDs.

Qué cambia con la búsqueda por IA

Menos de lo que te gustaría. Perplexity, ChatGPT y las superficies de IA de Google citan a nivel de URL, no de dominio, así que una página de un subdominio bien enlazado se puede citar igual de bien que una de un subdirectorio.

El efecto indirecto sí importa. Los sistemas de IA favorecen contenido que pueden alcanzar, parsear y contextualizar. Un subdominio huérfano, fuera de tu menú principal, es más difícil de descubrir y le da al modelo menos contexto sobre quién lo publica y por qué es creíble. Es el mismo problema del caso de búsqueda, entrando por otra puerta — y la solución es la misma.

La respuesta corta

Usa subdirectorio salvo que se cumpla una de las cuatro excepciones. Pero no esperes que el cambio de URL por sí solo haga nada por ti. La decisión de subdominio vs subdirectorio SEO merece acertarse en el momento de construir y rara vez justifica un proyecto de migración por sí sola — lo que sí justifica el proyecto es el trabajo de menú, plantillas y enlazado interno que una migración a subdirectorio suele colar de rebote. Haz ese trabajo primero, mídelo, y luego decide si la URL todavía tiene que moverse. Si quieres una segunda opinión sobre tu montaje concreto antes de gastar horas de ingeniería, esa es justo la pregunta que debería responder una auditoría SEO.

Preguntas frecuentes

¿Es mejor un subdominio o un subdirectorio para SEO?

El subdirectorio es la mejor opción por defecto para la mayoría de webs, pero no porque Google lo posicione mejor. Google dice desde 2012 que los trata como esencialmente equivalentes. El subdirectorio gana en la práctica porque obliga a integrar: plantillas compartidas, menú compartido y un enlazado interno que conecta tu contenido con tus páginas comerciales. Si consigues esa integración en un subdominio, la diferencia se cierra casi del todo.

¿Google trata los subdominios como sitios separados?

Google lo determina sitio por sitio, no con una regla general. Para un subdominio dentro de un dominio que ya entiende, con la misma marca y enlaces internos recíprocos, Google normalmente lo reconoce como parte de la misma propiedad. Para un subdominio con contenido no relacionado alojado en infraestructura de terceros, puede tratarlo aparte — que suele ser la interpretación correcta de lo que has construido.

¿Mover mi blog de subdominio a subdirectorio subirá el tráfico?

A menudo sí, pero rara vez por el cambio de URL en sí. La ganancia suele venir del trabajo que se publica a la vez: plantillas reconstruidas, la sección apareciendo en el menú principal y enlaces internos hacia tus páginas comerciales. Si migras las URLs y dejas el blog aislado en su plantilla, espera muy poco. Planifica la migración alrededor de la integración, no de la ruta.

¿Cuándo hay que usar un subdominio en lugar de un subdirectorio?

Cuatro casos lo justifican: un requisito regulatorio o de residencia de datos, contenido alojado por un tercero al que no puedes servir por proxy, un producto o audiencia genuinamente distintos que nunca enlazarías desde tus páginas comerciales, y una restricción de ingeniería real que un proxy inverso no resuelva. “Nuestro blog corre sobre otro CMS” no está en esa lista: ese es justo el caso para el que existe el proxy inverso.

No hay ningún mecanismo documentado de reparto de link equity en la frontera de un subdominio, y Google ha dicho consistentemente lo contrario. Lo que sí se reparte es el grafo de enlazado interno, porque el contenido del subdominio se construye normalmente en otro sistema y casi nunca enlaza de vuelta a las páginas clave del sitio principal. El efecto que la gente atribuye a link equity perdido son casi siempre enlaces internos que faltan, que es un problema de contenido solucionable y no una penalización algorítmica.

Ben — Consultor SEO Senior
Escrito por
Ben

Consultor SEO freelance senior con 15 años y más de 200 proyectos en 12 países. Trabajo directamente con empresas que quieren crecimiento orgánico real — sin agencias, sin juniors, sin relleno.

Deja un comentario

Tu email no se publicará. Sin spam, nunca.

Aplica esto
en tu sitio. Gratis.

Una auditoría técnica real. Sin compromiso, respuesta en 24 horas.