Nombre de host bajo un dominio principal, como docs.example.com, que puede tener una función técnica o de contenido distinta y debe planificarse como parte de la arquitectura general del sitio.
La decisión y sus límites
Un subdominio es un nombre de host por debajo de otro nombre de dominio; por ejemplo, docs.example.com bajo example.com. Técnicamente puede tener su propia aplicación, enrutado, cookies, configuración DNS y presencia en buscadores. Esa flexibilidad no resuelve la cuestión de la arquitectura de información. La elección entre subdominio y subdirectorio debe responder a la propiedad operativa, a los límites del producto, a las necesidades de localización o de plataforma y al recorrido del usuario, no a una supuesta ventaja de SEO.
Qué revisar
Haz un inventario de cada nombre de host: función, responsable, host canónico público, estado de TLS, reglas de robots, sitemap, identidad en analítica y rutas de enlazado interno. Rastrea páginas representativas a través del límite y comprueba que los enlaces apunten directamente a las rutas canónicas previstas. Durante una migración, conserva un mapa a nivel de URL y prueba cada destino, en lugar de suponer que basta con el enrutado a nivel de host.
Una ruta de implementación práctica
Usa un subdominio cuando cree un límite estable y fácil de entender, como documentación, una aplicación o una plataforma separada por región. Dale su propia navegación clara y su propia política de indexación, manteniendo los enlaces contextuales hacia la experiencia principal. Si trasladas contenido entre nombres de host, configura redirecciones permanentes directas cuando proceda, actualiza las referencias al canonical y al sitemap, y valida el renderizado y el seguimiento en ambos lados.
Errores y límites de la medición
El atajo arriesgado es crear un subdominio solo para aislar el trabajo de SEO o el contenido duplicado. Puede fragmentar la propiedad y dificultar las correcciones de todo el sitio. No afirmes que un subdominio hereda o pierde autoridad automáticamente; evalúa los enlaces reales, el contenido, la accesibilidad y la implementación de la migración.
Ejemplo de arquitectura. Una empresa puede publicar la documentación de producto en docs.example.com porque un equipo y una plataforma de documentación separados la gestionan, mientras la aplicación para clientes vive en app.example.com. Puede ser un límite coherente si la navegación, las expectativas de la cuenta, la política de búsqueda y la propiedad están claras. Mover una carpeta de marketing a un subdominio solo porque tiene una plantilla distinta es un motivo mucho más débil. Documenta el recorrido del usuario entre hosts antes de elegir el nombre de host.
Criterios de comprobación. Mantén un inventario de hosts con función, responsable principal, host público canónico, sitemap, política de robots, cobertura de TLS, alcance de la analítica y rutas de entrada clave. Rastrea páginas representativas del dominio principal al subdominio y de vuelta, y comprueba los enlaces internos directos, el comportamiento de las redirecciones y las rutas del pie de página o de la navegación. En una migración, prueba los pares de URL antiguas y nuevas, no solo la raíz del nombre de host. Revisa los recorridos en navegador y en móvil si intervienen cookies, inicio de sesión o el paso a una aplicación.
Errores habituales. No dupliques el mismo contenido entre el host raíz y un subdominio sin una decisión explícita de canonical o de migración. No des por hecho que los buscadores tratan todos los nombres de host como un solo sitio, ni que los tratan como totalmente no relacionados; verifica la estructura real de enlaces y URL. Un cambio de nombre de host afecta a las operaciones, a la analítica y a la confianza del usuario, además del SEO, así que necesita un plan de reversión a nivel de ruta.