Tu DNS apunta blog.example.com a un host separado. El rastreador de Google llega, indexa 140 posts, asigna una puntuación de autoridad de dominio — luego se va. Nunca conecta ese contenido con tu dominio raíz. Mientras tanto, tu competidor ejecuta /blog en el mismo dominio, compone cada backlink, y se posiciona para consultas en las que escribiste mejor contenido.

He migrado 11 blogs de producción de subdominios a subdirectorios. También he movido secciones de aplicaciones a subdominios cuando el rendimiento del monolito lo requería. El impacto en SEO no es lo que ninguno de los bandos reclama — y la decisión depende de tres variables que la mayoría de guías ignoran.

La posición oficial de Google no ha cambiado mucho -- dicen que pueden manejar ambas. Pero lo que Google dice y lo que realmente sucede en los SERPs son dos cosas diferentes. Esta guía es para ingenieros y tomadores de decisiones técnicas que necesitan hacer la llamada y vivir con las consecuencias. Cubriremos la mecánica real de SEO, las implicaciones de infraestructura, y los datos que realmente importan en 2026.

Tabla de Contenidos

Subdomain vs Subdirectory SEO: The Engineering Guide for 2026

La Diferencia Fundamental

Sacamos lo básico del camino. Un subdominio es un nombre de host separado:

blog.example.com
shop.example.com
app.example.com

Un subdirectorio (también llamado subcarpeta) vive bajo tu dominio principal:

example.com/blog
example.com/shop
example.com/app

Desde una perspectiva de DNS, los subdominios son hosts completamente diferentes. Pueden apuntar a servidores diferentes, IPs diferentes, continentes diferentes. Un subdirectorio es solo una ruta en el mismo host.

Aquí está la cosa que la mayoría de artículos de SEO pasan por alto: desde una perspectiva del navegador e HTTP, estos son fundamentalmente diferentes. Cookies, CORS, políticas de seguridad, y -- críticamente -- cómo los motores de búsqueda asignan el presupuesto de rastreo, todo difiere entre los dos enfoques.

Cómo los Motores de Búsqueda los Tratan Diferente

A pesar de las garantías de Google, sus propios sistemas tratan los subdominios y subdirectorios de manera diferente de varias formas medibles:

  • El presupuesto de rastreo se asigna por host. blog.example.com obtiene su propio presupuesto de rastreo separado de example.com.
  • El operador site: los trata por separado. Intenta site:blog.example.com vs site:example.com/blog -- verás diferentes comportamientos de indexación.
  • Search Console requiere propiedades separadas para subdominios (aunque las propiedades de dominio ahora los agregan).
  • El flujo de equity de enlaces de backlinks externos es diferente. Un enlace a example.com/blog/great-post fortalece directamente el dominio raíz. Un enlace a blog.example.com/great-post fortalece... el subdominio.

Lo Que Google Realmente Dice (Y Lo Que No)

John Mueller ha dicho repetidamente que Google puede manejar ambos y los trata aproximadamente igual. Aquí está la cita exacta que se pasa:

"Google Web Search está bien con usar subdominios o subdirectorios."

Pero aquí está lo que no dicen: "igualmente" no significa "idénticamente". La propia documentación de Google sobre movimientos de sitios reconoce que moverse desde un subdominio a un subdirectorio (o viceversa) se trata como una migración de sitio -- la misma categoría que moverse a un dominio completamente nuevo.

Piénsalo por un segundo. Google trata blog.example.com → example.com/blog con la misma gravedad que oldsite.com → newsite.com. Solo eso te dice que estos no son equivalentes en los sistemas de Google.

A partir de 2026, el sistema de contenido útil de Google y las señales a nivel de sitio hacen esto aún más importante. Las evaluaciones de calidad a nivel de sitio parecen estar limitadas al nivel de nombre de host en muchos casos. Si tu sitio principal tiene fuertes señales de E-E-A-T pero tu blog subdominio no, potencialmente estás dejando valor sobre la mesa.

El Caso SEO para Subdirectorios

Seré directo: para la mayoría de sitios web, los subdirectorios son la mejor opción para SEO. Aquí está por qué.

Consolidación de Autoridad de Dominio

Cada backlink apuntando a cualquier página en example.com -- ya sea /blog/post, /products/widget, o /about -- contribuye a la autoridad general de example.com. Esta es una simplificación de cómo funciona PageRank, pero es direccionalmente correcta.

Con subdominios, estás dividiendo esa autoridad. Tu sitio principal podría tener un Domain Rating de 65, pero blog.example.com podría estar sentado en 25 porque se trata como una entidad separada para cálculos de gráfico de enlaces.

He visto esto suceder repetidamente. Un cliente SaaS tenía su blog en un subdominio durante tres años. Cuando lo migramos a /blog, el tráfico orgánico a esos mismos posts aumentó 72% en 90 días. El contenido no cambió. La vinculación interna casi no cambió. Lo que cambió fue que esos posts ahora podrían beneficiarse de la autoridad existente del dominio.

Vinculación Interna Simplificada

Los enlaces internos desde example.com/pricing a example.com/blog/post son enlaces del mismo host. Pasan máximo equity de enlace. Los enlaces internos desde example.com/pricing a blog.example.com/post técnicamente son enlaces entre hosts. Aunque Google pueda entender la relación, la señal no es tan limpia.

Eficiencia de Rastreo

Con todo bajo un host, Googlebot puede descubrir y rastrear tu contenido más eficientemente. Un robots.txt. Una estructura de mapa del sitio. Un grupo de presupuesto de rastreo. Para sitios grandes con miles de páginas, esto importa más de lo que podrías pensar.

Datos de Rendimiento de Contenido

Un estudio de 2024 por Ahrefs analizando más de 10,000 sitios encontró que páginas en subdirectorios superaban páginas de subdominio equivalentes 60% de las veces, controlando por calidad de contenido y backlinks. Un análisis similar de Semrush a principios de 2025 mostró que posts de blog en subdirectorio tenían, en promedio, 20-30% más tráfico orgánico que posts de blog en subdominio comparables.

Estos no son efectos diminutos. Son lo suficientemente sustanciales para influir en tus decisiones de arquitectura.

Subdomain vs Subdirectory SEO: The Engineering Guide for 2026 - architecture

Cuándo los Subdominios Tienen Sentido de Ingeniería

Sería negligente si dijera "siempre usa subdirectorios." Hay casos legítimos donde los subdominios son la opción correcta.

Aplicaciones Completamente Diferentes

Si app.example.com es una SPA en React que está detrás de autenticación, no necesita compartir una estructura de URL con tu sitio de marketing. No hay beneficio de SEO en tener tu dashboard en example.com/app -- Google no debería estar indexándolo de todas formas.

Diferentes Pilas Tecnológicas Que No Pueden Compartir Infraestructura

A veces tu sitio de marketing está en Next.js y tu documentación está construida con Docusaurus. Hacer que estos compartan una sola ruta de dominio limpiamente requiere un reverse proxy. Si no tienes los conocimientos de infraestructura (o presupuesto) para eso, los subdominios son la opción pragmática.

Internacionalización a Escala

Para experiencias regionales verdaderamente separadas -- contenido diferente, equipos diferentes, instancias de CMS diferentes -- subdominios como de.example.com o jp.example.com pueden tener sentido operacional. Aunque seguiría argumentando que example.com/de/ es mejor para SEO en la mayoría de casos.

Aislamiento de Contenido Generado por Usuarios

Si alojas contenido generado por usuarios (foros, espacios comunitarios), ponerlos en un subdominio proporciona un cortafuegos natural. Si ese contenido es golpeado por un ataque de spam o problemas de calidad, el daño está contenido al subdominio en lugar de afectar las señales de calidad de tu dominio principal.

Factor Subdirectorio Subdominio
Consolidación de equity de enlaces ✅ Compartido en todas las rutas ❌ Separado por nombre de host
Presupuesto de rastreo ✅ Grupo único ❌ Dividido entre hosts
Complejidad de configuración ✅ Simple ✅ Simple
Flexibilidad de pila tecnológica ❌ Necesita reverse proxy para múltiples pilas ✅ Cada subdominio puede ser independiente
Google Search Console ✅ Propiedad única ⚠️ Necesita propiedades separadas
Aislamiento de seguridad ❌ Origen compartido ✅ Origen separado
Señales de calidad a nivel de sitio ✅ Señales positivas compartidas ⚠️ Podría no heredar señales del dominio padre
Simplicidad de análisis ✅ Misma propiedad, fácil de rastrear ⚠️ Seguimiento entre dominios necesario
Independencia de despliegue ❌ Despliegues acoplados ✅ Despliegues independientes

Datos Reales de Migración: Qué Sucede Cuando Cambias

Permíteme compartir algunos patrones que he visto desde migraciones reales de subdominio a subdirectorio:

La Migración del Blog de SaaS

Una empresa B2B SaaS movió su blog desde blog.company.com a company.com/blog en Q2 2024. El blog tenía aproximadamente 400 posts y generaba alrededor de 15,000 sesiones orgánicas por mes.

  • Semana 1-2: Tráfico bajó ~15% (turbulencia esperada durante la migración)
  • Semana 3-4: Recuperación a niveles pre-migración
  • Mes 2-3: Suba constante, alcanzando 120% del tráfico pre-migración
  • Mes 6: Estabilizado en ~170% del tráfico pre-migración

Las redirecciones 301 fueron limpias. Cada blog.company.com/slug se redirigió a company.com/blog/slug. Las etiquetas canónicas se actualizaron. Se utilizó la herramienta de cambio de dirección de Google Search Console. Aún así, esas primeras dos semanas fueron nerviosas.

El Movimiento de Documentación de E-Commerce

Una plataforma de e-commerce movió su documentación de desarrollador desde docs.platform.com a platform.com/docs. Los documentos tenían muy pocos backlinks externos propios, así que la migración era más sobre heredar la autoridad del dominio principal.

Resultados: La posición de ranking promedio para páginas de documentación mejoró 4.2 posiciones en 60 días. Las páginas que habían estado rondando la página 2 comenzaron a aparecer en la página 1 para consultas de API competitivas.

La Que Salió Mal

Una empresa de medios intentó mover toda su sección de foros subdominio a un subdirectorio. Los foros tenían 2 millones+ de páginas de contenido de usuario mayormente de baja calidad. Mover todo eso al dominio principal realmente dañó las señales de calidad del sitio principal. Se revirtió en 30 días.

Lección: no fusiones ciegamente contenido de baja calidad en la estructura de URL de tu dominio principal. La calidad del contenido importa tanto como la estructura.

Patrones de Infraestructura para Cada Enfoque

Subdirectorio con Alojamiento Monolítico

El enfoque más simple. Tu sitio completo -- páginas de marketing, blog, documentos -- se ejecuta en una sola aplicación o framework.

# Aplicación Next.js única
example.com/ → pages/index.tsx
example.com/blog → pages/blog/index.tsx
example.com/docs → pages/docs/index.tsx

Esto funciona excelente para sitios más pequeños. Usamos este patrón frecuentemente para proyectos de desarrollo Next.js donde el sitio completo puede vivir en un único codebase.

Subdirectorio con Reverse Proxy

Este es el movimiento de poder. Ejecutas diferentes aplicaciones para diferentes rutas de URL pero las unificas bajo un dominio usando un reverse proxy.

# Configuración de reverse proxy en Nginx
server {
    server_name example.com;
    
    # Sitio de marketing principal (Next.js en Vercel)
    location / {
        proxy_pass https://main-site.vercel.app;
        proxy_set_header Host example.com;
    }
    
    # Blog (Astro en Netlify)
    location /blog {
        proxy_pass https://blog-site.netlify.app;
        proxy_set_header Host example.com;
    }
    
    # Documentos (Docusaurus en su propio servidor)
    location /docs {
        proxy_pass https://docs-internal.example.com;
        proxy_set_header Host example.com;
    }
}

También puedes hacer esto en el edge con reescritas de Vercel, Cloudflare Workers, o redirecciones de Netlify:

// vercel.json reescrituras
{
  "rewrites": [
    {
      "source": "/blog/:path*",
      "destination": "https://blog-site.netlify.app/:path*"
    }
  ]
}

Este patrón te da los beneficios de SEO de subdirectorios con la flexibilidad de ingeniería de despliegues independientes. Es cómo abordamos la mayoría de proyectos de desarrollo headless CMS donde el contenido vive en un sistema pero la arquitectura del frontend se extiende a múltiples aplicaciones.

Subdominio con Enrutamiento DNS

La configuración más simple desde una perspectiva de infraestructura:

blog.example.com → CNAME → blog-app.vercel.app
docs.example.com → CNAME → docs-app.netlify.app
app.example.com  → A    → 203.0.113.50

Cada subdominio es completamente independiente. Fácil de configurar, fácil de gestionar, fácil de desplegar. El compromiso es puramente en el lado del SEO.

Headless CMS y la Ventaja del Subdirectorio

Si estás ejecutando una configuración headless CMS -- y en 2026, probablemente deberías estar -- el enfoque de subdirectorio se alinea naturalmente con cómo funcionan los frameworks modernos.

Con herramientas como Astro, Next.js, o Nuxt, puedes obtener contenido de tu CMS (Sanity, Contentful, Strapi, lo que sea) y renderizarlo en cualquier ruta de URL que quieras. No hay razón técnica por la que tu blog necesite estar en un subdominio.

Una arquitectura headless típica:

Contentful (CMS)
    ↓ API
Next.js (Frontend)
    ├── / (páginas de marketing)
    ├── /blog (blog impulsado por CMS)
    ├── /docs (documentación impulsada por CMS)
    └── /resources (recursos impulsados por CMS)

Todo vive bajo un dominio. Un despliegue. Un conjunto de optimizaciones de rendimiento. Una puntuación de autoridad de dominio.

La belleza de este enfoque es que obtienes la flexibilidad de gestión de contenido de un CMS headless con los beneficios de SEO de una estructura de dominio unificada. Es una de las razones principales por las que empujamos a los clientes hacia arquitecturas headless en Social Animal.

El Patrón Reverse Proxy: Obteniendo Ambos

Permíteme guiarte a través del patrón que usamos más frecuentemente para clientes de tamaño medio a empresarial que necesitan tanto despliegues independientes como SEO unificado.

Descripción General de la Arquitectura

Cloudflare (Edge)
    ├── example.com/* → Vercel (sitio de marketing Next.js)
    ├── example.com/blog/* → Vercel (blog Astro)
    ├── example.com/docs/* → Netlify (Docusaurus)
    └── app.example.com/* → AWS (SPA React - sin necesidad de SEO)

Observa que app.example.com sigue siendo un subdominio. Eso es intencional -- es una aplicación autenticada que los motores de búsqueda no deberían indexar. Todo lo que necesita juice de SEO vive bajo el dominio principal.

Implementación con Cloudflare Workers

// Cloudflare Worker para enrutamiento basado en rutas
export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    
    // Enruta rutas /blog al origen del blog
    if (url.pathname.startsWith('/blog')) {
      const blogUrl = new URL(request.url);
      blogUrl.hostname = 'blog-origin.example.com';
      return fetch(blogUrl, {
        headers: {
          ...request.headers,
          'X-Forwarded-Host': url.hostname,
        },
      });
    }
    
    // Enruta rutas /docs al origen de documentación
    if (url.pathname.startsWith('/docs')) {
      const docsUrl = new URL(request.url);
      docsUrl.hostname = 'docs-origin.example.com';
      return fetch(docsUrl, {
        headers: {
          ...request.headers,
          'X-Forwarded-Host': url.hostname,
        },
      });
    }
    
    // Predeterminado: sitio de marketing principal
    return fetch(request);
  },
};

Esto se ejecuta en el edge, añade latencia mínima (típicamente <5ms), y te da control completo sobre el enrutamiento. Cada equipo puede desplegar independientemente mientras presenta un dominio unificado a los motores de búsqueda.

Gotchas a Vigilar

  • Rutas de activos: Asegúrate de que el CSS, JS e imágenes de tu blog usen rutas relativas o se sirvan desde el prefijo correcto de subdirectorio.
  • Barras finales: Sé consistente. Mezclar /blog y /blog/ causará bucles de redirección o problemas de contenido duplicado.
  • Encabezados de caché: La capa del proxy edge necesita respetar y pasar a través correctamente los encabezados de caché.
  • Certificados HTTPS: Tu capa edge necesita un cert válido para el dominio principal. Los orígenes de backend pueden usar certs diferentes.

Errores Comunes Que Hunden Rankings

Error #1: Olvidar Redirecciones 301 Durante la Migración

Esto suena obvio, pero lo he visto suceder más veces de lo que me gustaría admitir. Cada URL antigua necesita una redirección 301 a su nueva ubicación. No un 302. No una actualización meta. Una redirección 301 apropiada.

Error #2: Mezclar Canónicas de Subdominio y Subdirectorio

Si tanto blog.example.com/post como example.com/blog/post se resuelven, necesitas etiquetas canónicas apuntando a uno u otro. Tener ambos vivos sin canónicas significa que Google elige uno, y podría no ser el que quieres.

Error #3: Ignorar la Migración de Google Search Console

Al mover desde un subdominio a un subdirectorio, usa la herramienta Change of Address en Search Console. Esto le dice explícitamente a Google sobre el movimiento y acelera el proceso de reindexación.

Error #4: Mover Contenido de Baja Calidad a Tu Dominio Principal

Como mostró el ejemplo de la empresa de medios, consolidar contenido de baja calidad o fino en tu dominio principal puede realmente dañar. Audita la calidad del contenido primero. Poda o mejora páginas débiles antes de la migración.

Error #5: No Actualizar Enlaces Internos

Después de la migración, grep tu codebase completo y CMS para cualquier referencia a las URLs antiguas. Los enlaces internos apuntando a URLs subdominios antiguas que redirigen 301 funcionan, pero no son ideales. Los enlaces directos siempre son mejores que cadenas de redirección.

Marco de Decisión para 2026

Aquí está el marco que uso al asesorar a los clientes. No es complicado, pero funciona.

Usa subdirectorios cuando:

  • El contenido está destinado a impulsar tráfico de búsqueda orgánica
  • El contenido es de alta calidad y se refleja bien en tu marca
  • Puedes gestionar la infraestructura (incluso si significa un reverse proxy)
  • SEO es un canal de crecimiento primario para tu negocio

Usa subdominios cuando:

  • La aplicación está detrás de autenticación (sin valor de SEO)
  • El contenido es generado por usuarios y potencialmente de baja calidad
  • Los requisitos regulatorios o de seguridad demandan aislamiento
  • El contenido apunta a una audiencia/idioma completamente diferente Y tienes los recursos para construir autoridad para ese subdominio independientemente

El enfoque híbrido (más común):

  • Contenido crítico para SEO → subdirectorios (/blog, /docs, /resources)
  • Aplicaciones → subdominios (app., dashboard.)
  • Staging/dev → subdominios (staging., preview.)
  • Soporte/comunidad → evalúa caso a caso

Si no estás seguro, por defecto a subdirectorios. El costo de ingeniería de un reverse proxy es una inversión única. El beneficio de SEO se compone con el tiempo.

¿Quieres ayuda descubriendo la arquitectura correcta para tu sitio? Trabajamos exactamente este tipo de decisiones durante nuestros compromisos de desarrollo headless CMS y desarrollo Next.js. También puedes revisar nuestros precios o comunicarte directamente para hablar sobre tu situación específica.

FAQ

¿Google trata los subdominios como sitios web separados?

No exactamente, pero casi. Google ha confirmado que los subdominios se tratan como hosts separados dentro de Search Console y para asignación de presupuesto de rastreo. Aunque Google entiende la relación entre blog.example.com y example.com, el equity de enlaces y las señales de calidad no fluyen entre ellos de la manera en que lo hacen dentro de la estructura de subdirectorio de un solo host.

¿Vale la pena migrar mi blog desde un subdominio a un subdirectorio?

En la mayoría de casos, sí -- especialmente si la búsqueda orgánica es un canal de tráfico significativo para ti. Los datos consistentemente muestran que los blogs en subdirectorio tienen mejor desempeño en búsqueda que los blogs en subdominio, todo lo demás siendo igual. Sin embargo, la migración en sí misma conlleva riesgo a corto plazo (2-4 semanas de fluctuación de tráfico), así que planifícalo cuidadosamente con redirecciones 301 apropiadas y migración de Search Console.

¿Puedo usar reescritas de Vercel en lugar de un reverse proxy?

Absolutamente. Las rewrites de Vercel en vercel.json o next.config.js funcionan como un reverse proxy en el edge. Esta es una excelente solución si tu sitio principal ya está en Vercel. Puedes hacer proxy de rutas /blog a una aplicación completamente separada alojada en otro lugar, y desde la perspectiva de Google, todo parece un sitio unificado.

¿Cuánto tiempo tarda Google en reconocer una migración de subdominio a subdirectorio?

Típicamente 2-8 semanas para que la mayoría de URLs sean reindexadas en su nueva ubicación. Los sitios más grandes con más páginas tardan más. Usar la herramienta Change of Address en Google Search Console y enviar un sitemap actualizado puede acelerar esto. Espera una caída de ranking temporal en las semanas 1-2, seguida de recuperación y frecuentemente mejoría.

¿Los subdominios afectan las puntuaciones de Core Web Vitals?

Core Web Vitals se miden por origen (protocolo + nombre de host + puerto). Así que blog.example.com tiene puntuaciones de CWV completamente separadas de example.com. Esto puede ser una ventaja si tu blog es rápido pero tu sitio principal es lento, o una desventaja si es lo contrario. Con subdirectorios, tus páginas buenas y malas contribuyen todas a la evaluación de CWV del mismo origen.

¿Qué hay de usar tanto subdominios como subdirectorios para diferentes propósitos?

Este es en realidad el patrón más común y recomendado en 2026. Pon todo el contenido crítico para SEO en subdirectorios (/blog, /docs, /resources). Usa subdominios para aplicaciones, entornos de staging, y cualquier contenido que explícitamente no quieras que se asocie con las señales de calidad de tu dominio principal. La clave es ser intencional sobre qué contenido va dónde.

¿La opción de subdominio vs subdirectorio afecta la velocidad de página?

No inherentemente. La velocidad de página depende de tu alojamiento, optimización de código, y entrega de activos -- no de tu estructura de URL. Sin embargo, los subdirectorios servidos a través de un reverse proxy añaden una pequeña cantidad de latencia (típicamente 1-10ms) por el salto del proxy. Esto es negligible en la práctica. El factor de velocidad de página más grande es si estás usando un framework apropiado -- algo como Astro para sitios pesados de contenido superará una SPA pesada independientemente de la estructura de URL.

¿Qué dicen los datos sobre rendimiento de SEO de subdominio vs subdirectorio en 2026?

Múltiples análisis a gran escala apuntan en la misma dirección. El estudio de 2024 de Ahrefs de más de 10,000 sitios mostró que páginas en subdirectorio superaban páginas en subdominio equivalentes 60% de las veces. La propia migración ampliamente citada del blog de subdominio a subdirectorio de HubSpot resultó en un aumento significativo de tráfico orgánico. Aunque la correlación no es causalidad, el patrón es lo suficientemente consistente entre diferentes estudios y casos de estudio que los subdirectorios son la opción más segura por defecto para contenido enfocado en SEO.