Subdominio o subcarpeta: dónde poner tu blog o tu tienda

Si tu web sirve un único mercado y un único idioma, la duda de si un blog, una tienda o un centro de ayuda deben vivir en un subdominio (blog.tudominio.com) o en una subcarpeta (tudominio.com/blog) no tiene nada que ver con geolocalizar contenido para distintos países. Es una decisión de arquitectura: qué autoridad compartes entre secciones, qué aíslas por si algo sale mal y qué complejidad técnica estás dispuesto a mantener a largo plazo.

La respuesta correcta cambia según qué estés montando. Un blog corporativo, una tienda online y un centro de ayuda tienen necesidades distintas, y la plataforma que uses para cada uno —tu propio CMS, un SaaS de ecommerce o una herramienta de soporte— a menudo decide por ti antes de que llegues a pensar en SEO. Esta guía repasa qué se juega realmente en cada caso y da un criterio claro para decidir cuando sí tienes margen de elección.

Qué diferencia técnicamente a un subdominio de una subcarpeta

Un subdominio es un nombre de host distinto bajo el mismo dominio registrado: blog.tudominio.com tiene su propio registro DNS y puede apuntar a un servidor completamente diferente al de tudominio.com, con su propio stack tecnológico, su propio certificado y, salvo que lo configures explícitamente, sus propias cookies de sesión. Una subcarpeta, en cambio, es una ruta dentro del mismo host: tudominio.com/blog vive en el mismo servidor, bajo el mismo certificado, y comparte automáticamente el espacio de cookies con el resto del sitio.

Esa diferencia técnica es la raíz de todo lo demás. Para un rastreador, un subdominio es, a efectos prácticos, un host aparte: puede tener su propio patrón de rastreo, su propia frecuencia de visita y sus propias señales de calidad agregadas. Una subcarpeta hereda directamente el patrón de rastreo del dominio completo, porque para el rastreador no hay ninguna frontera que cruzar entre tu página de inicio y una entrada de blog en /blog/lo-que-sea.

• Subdominio: host propio en el DNS, puede alojarse en un servidor distinto, cookies no compartidas por defecto.
• Subcarpeta: misma dirección de host, mismo certificado SSL, mismas cookies de sesión sin configuración adicional.

Por qué la autoridad no se reparte igual en los dos casos

Los enlaces internos y externos que apuntan a un subdominio refuerzan primero la reputación de ese host. Para que ese refuerzo llegue también al dominio raíz depende de cuántos enlaces cruzan de un lado a otro —del subdominio hacia las páginas principales, y viceversa— y de cuánta coherencia de marca y de calidad hay entre ambos. En una subcarpeta no existe ese cruce que resolver: cualquier enlace que llega a una entrada de blog, a una ficha de producto o a un artículo de ayuda refuerza directamente el mismo host donde vive tu página de inicio y el resto de tu contenido comercial.

Google ha dado indicaciones contradictorias sobre esto a lo largo de los años, y en distintos momentos ha dicho tanto que trata los subdominios como parte del mismo sitio como que los evalúa de forma independiente. Lo más honesto es asumir que sus sistemas actuales valoran señales de calidad a varios niveles —página, sección y host— y que el efecto real depende de cuánto contenido propio, bien enlazado y de calidad consistente tengas en cada lado. No es una regla fija que puedas aplicar sin mirar tu caso concreto.

El blog: el caso más habitual en una web de un solo mercado

Para la mayoría de sitios de un único mercado, el blog es el ejemplo más simple: si el objetivo del blog es atraer tráfico y convertirlo en la página de producto o de contacto, quieres que la autoridad que genere ese contenido fluya sin fricción hacia esas páginas. Mantenerlo en una subcarpeta hace que ese flujo sea directo, sin depender de cuántos enlaces cruzados coloques entre un host y otro.

Hay casos legítimos para elegir subdominio incluso en un blog de un solo mercado. Si la herramienta de publicación que necesitas solo se integra bien sirviendo desde su propio host, o si quieres lanzar un formato editorial experimental —un tono, una frecuencia o un tipo de contenido muy distinto del resto del sitio— y prefieres no arriesgar la reputación del dominio principal mientras compruebas si funciona, un subdominio te da ese aislamiento. El coste es que, si el experimento funciona, tendrás que decidir más adelante si lo migras a subcarpeta para que empiece a sumar directamente.

• Mismo host que las páginas que quieres posicionar y convertir, sin depender de enlaces cruzados para transferir autoridad.
• Atribución de conversión más simple: la sesión del visitante no cambia de dominio entre leer un artículo y visitar una página de producto.
• Sin necesidad de mantener reglas de canonical ni redirecciones entre dos hosts distintos.

La tienda: cuando la plataforma decide antes que el SEO

En ecommerce, la elección suele venir impuesta por la plataforma antes de que llegues a valorarla como decisión de SEO. Muchos SaaS de tienda online sirven por defecto desde un subdominio propio (tienda.tudominio.com) porque así gestionan ellos toda la infraestructura: el checkout, la seguridad del proceso de pago y el catálogo corren en sus servidores, no en los tuyos. Algunas plataformas permiten, con configuración adicional en tu propio servidor, servir la tienda bajo una subcarpeta mediante un proxy inverso; otras simplemente no lo ofrecen.

El coste de mantenimiento no es simétrico. Un proxy inverso hacia una subcarpeta añade una pieza más en la cadena de peticiones —si esa pieza falla, la tienda entera puede caerse aunque el proveedor esté funcionando perfectamente— y normalmente exige que tu equipo de infraestructura mantenga esas reglas actualizadas cada vez que la plataforma cambia su estructura de rutas. Un subdominio evita ese riesgo compartido: si el proveedor tiene un problema, tu web principal sigue en pie, y si tu servidor tiene un problema, la tienda del proveedor sigue funcionando.

• Subcarpeta: la autoridad de tu dominio principal alcanza directamente las páginas de producto y categoría, sin cruce de host.
• Subdominio: el proveedor gestiona por completo la infraestructura y la seguridad del pago, sin que dependa de tu propio servidor.

El centro de ayuda: la excepción que suele justificarse sola

Los centros de ayuda acaban en subdominio con más frecuencia que los blogs o las tiendas, y casi siempre por el mismo motivo: la herramienta de soporte (una plataforma de tickets, una base de conocimiento) exige servir desde ayuda.tudominio.com por diseño, y solo los planes más caros —cuando existen— ofrecen un proxy inverso configurable para servir desde una subcarpeta.

Aquí la pregunta de SEO que merece la pena hacerse es otra: ¿quieres que esos artículos de ayuda («cómo cancelar una reserva», «cómo cambiar mi método de pago») posicionen para búsquedas informacionales genuinas y atraigan tráfico nuevo, o son sobre todo una herramienta interna de soporte para quien ya es cliente? Si lo primero te interesa de verdad, la subcarpeta captura más de ese valor directamente para tu dominio principal; si es sobre todo soporte operativo, el aislamiento del subdominio no te cuesta prácticamente nada en la práctica.

En la práctica, esta decisión suele estar más condicionada por el presupuesto y el plan contratado con el proveedor que por una preferencia de SEO: migrar un centro de ayuda ya construido en la plataforma de un tercero a tu propia subcarpeta no siempre es técnicamente posible, así que conviene comprobarlo antes de construir cientos de artículos en un sitio que después no podrás traer a tu dominio principal.

El coste de mantenimiento que rara vez se calcula al principio

Poner un blog o una tienda con un stack tecnológico distinto —por ejemplo, un WordPress bajo /blog conviviendo con una aplicación propia en el resto del dominio— en una subcarpeta exige una capa de proxy inverso que decida, ruta a ruta, a qué backend responde cada petición. Eso implica coordinar el cacheo y la configuración de CDN por ruta, mantener un certificado que cubra todo el dominio —lo cual ya es automático en subcarpeta— y aceptar que un despliegue mal coordinado en cualquiera de los dos sistemas puede parecer, de cara al visitante, que todo el sitio está caído.

Un subdominio simplifica ese primer despliegue: cada sistema tiene su propia infraestructura, su propio certificado —comodín o con el subdominio incluido explícitamente como nombre alternativo— y su propio proceso de publicación, sin depender de que nadie más toque una regla de proxy compartida. A cambio, ahora mantienes dos configuraciones de DNS, dos sistemas de analítica que hay que enlazar a mano si quieres una vista unificada del recorrido del usuario, y un consentimiento de cookies que, por defecto, no se comparte entre hosts.

• Subcarpeta: un único stack de despliegue, un único dominio de cookies, un único certificado que ya lo cubre todo.
• Subdominio: infraestructuras independientes, DNS y certificados propios, analítica y consentimiento que hay que enlazar explícitamente.

Cómo decidir cuando sí tienes margen

Cuando la plataforma no te obliga a nada, estas son las preguntas que de verdad deciden el resultado.

• Si puedes alojar el contenido en el mismo servidor, o detrás de un proxy sin complicar el despliegue, la subcarpeta es la opción por defecto en un sitio de un solo mercado: es la forma más directa de que ese contenido sume al resto.
• Si la plataforma que necesitas —soporte, ecommerce, comunidad— solo ofrece subdominio, acéptalo sin forzar un proxy inverso frágil: el coste de mantenerlo suele superar el beneficio de SEO que ganarías.
• Si el contenido tiene un perfil de calidad o de riesgo muy distinto al resto del sitio —contenido generado por usuarios, un foro, un formato experimental— un subdominio te protege de que sus problemas de calidad afecten a las señales del dominio principal.
• Si el contenido es tuyo, editorial y controlado, y tu dominio principal ya tiene autoridad acumulada, ponlo en subcarpeta: es la forma más directa de que ese trabajo beneficie al resto del sitio.

Migrar de subdominio a subcarpeta más adelante

Si más adelante decides mover contenido de un subdominio a una subcarpeta, el proceso técnico es el mismo que cualquier cambio de URLs a esta escala: redirecciones 301 de cada URL antigua a su equivalente nueva, actualización de todos los enlaces internos que apunten al subdominio —no basta con dejar que la redirección haga el trabajo indefinidamente— y una nueva versión del sitemap XML que refleje las URLs definitivas.

Conviene contar con una fluctuación temporal de visibilidad mientras las señales se consolidan en el host nuevo; no es una señal de que algo haya ido mal, es el tiempo que tarda el rastreo y la reevaluación de calidad en ponerse al día con la nueva estructura. Y una vez migrado, mantén la redirección del subdominio antiguo en marcha: convertirla en un error 404 desperdicia cualquier autoridad residual que esos enlaces antiguos todavía pudieran aportar.