Varios dominios en cPanel: raíces, DNS y separación de sitios

Para alojar varios dominios en cPanel, decide primero qué contenido debe mostrar cada nombre. Dos dominios con la misma raíz documental pueden servir el mismo sitio; raíces distintas permiten organizar contenidos diferentes. Pero dos carpetas dentro de una cuenta no equivalen a dos cuentas aisladas.

Esta guía sirve para planear esa relación sin mover archivos, DNS ni correo a ciegas. La interfaz actual se llama Domains / Dominios; sus opciones dependen de la versión y de las funciones habilitadas por tu proveedor. No es una captura de tu cuenta ni una instrucción para cambiarla sin respaldo.

Probar un mapa ficticio · Preparar el alta · Separar responsabilidades

Comprueba la diferencia antes de tocar tu alojamiento

En el ejemplo, a.example.test y b.example.test son nombres ficticios. Si ambos apuntan a la misma raíz, editar su página de inicio afecta al contenido que reciben ambos nombres. Si la tienda usa otra raíz, su contenido puede ser diferente, aunque siga bajo la misma cuenta. El resultado real también depende del DNS, de la aplicación y de posibles redirecciones.

Abrir la herramienta interactiva de esta guía. Se abre como recurso separado en este sitio, no dentro del artículo. Solo usa escenarios ficticios: no consulta tu alojamiento ni envía datos. Puedes comparar opciones, reiniciar y guardar un resumen local.

Lectura del esquema: el nombre solicitado selecciona una configuración del servidor y su raíz documental. Esa ruta indica dónde busca los archivos web; no demuestra quién puede leerlos ni qué límites de CPU, memoria o procesos se aplican.

Cuatro decisiones que no debes mezclar

Dar de alta un nombre existente en el alojamiento no es registrarlo ni renovarlo. Algunas versiones y proveedores ofrecen una integración opcional para comprar dominios desde la interfaz; sigue siendo una operación distinta con condiciones del registrador. Consulta el alcance en la documentación actual de Domains.

Cómo preparar y comprobar un dominio adicional

1. Define el resultado. Anota nombre, propietario, propósito y contenido esperado. Decide si será otro nombre para el mismo sitio, un proyecto distinto o un subdominio como blog.example.com. Un subdominio no exige comprar otro dominio, pero sí control de su configuración.
2. Confirma alcance y respaldo. Revisa cuántos dominios admite el plan, acceso disponible, aplicaciones existentes y copia recuperable. No elijas una carpeta que ya contenga otro sitio sin entender la consecuencia.
3. Abre Domains / Dominios y la creación de dominio. En instalaciones modernas de Jupiter, las pantallas separadas Addon Domains, Subdomains y Aliases fueron sustituidas por Domains. Las funciones no desaparecieron; la ruta visual cambió. En versiones antiguas consulta la documentación correspondiente.
4. Revisa la opción de compartir raíz. Si quieres contenido distinto, no compartas la raíz del dominio principal y revisa la ruta que permite tu proveedor. La documentación de la interfaz138+ sitúa las raíces nuevas dentro de public_html/; no asumas que tu cuenta permite otra ubicación por una guía antigua. La elección de compartir raíz se describe como permanente: el modelo educativo no es un botón para cambiar una cuenta existente. La guía oficial de creación explica las opciones disponibles.
5. Comprueba el registro guardado. Verifica nombre exacto, raíz documental y redirecciones en la lista de dominios. Todavía no concluyas que la resolución pública está lista.
6. Coordina DNS, certificado y correo por separado. Confirma dónde están los servidores autoritativos antes de editar registros. Si el correo está en otro servicio, conserva sus MX y registros relacionados; no crees buzones locales como sustituto automático. Comprueba cobertura TLS para cada nombre que vaya a usarse.
7. Verifica desde fuera. Abre cada nombre por HTTPS, identifica contenido esperado, enlaces y redirecciones. Una página equivocada puede deberse a raíz compartida, DNS, caché o configuración de la aplicación; no borres carpetas para probar hipótesis. Si existe correo, acuerda una prueba autorizada de recepción y envío, aparte de la prueba web.

La planificación de retirada de interfaces permite reconocer instrucciones antiguas. Para una ruta personalizada, contrasta también la explicación oficial de Document Root; no sustituye las restricciones de tu plan.

¿Una cuenta con carpetas o cuentas separadas?

Una cuenta puede ser suficiente cuando una misma persona administra proyectos relacionados, acepta el alcance compartido y tiene respaldos y capacidad adecuados. Mantener nombres de carpetas claros y una ficha dominio–ruta–responsable evita errores operativos; no convierte esa organización en una barrera de seguridad.

Considera cuentas separadas si hay propietarios distintos, entregas a clientes, credenciales independientes, necesidades de restauración diferenciadas o límites de recursos que deban asignarse por proyecto. Pide al proveedor que explique qué aislamiento de archivos, procesos, usuarios y recursos aplica realmente. Dos cuentas tampoco eliminan toda dependencia compartida del servidor.

Antes de pagar más, identifica la necesidad: quizá basta corregir una raíz o un registro. Un VPS no arregla por sí solo un mapa equivocado. Si el problema aparece después de cambiar un plugin, sigue un diagnóstico que preserve los datos nuevos, no una migración de alojamiento por reflejo. Y disponer de cPanel no significa tener administración del sistema operativo o acceso al cortafuegos: esas responsabilidades deben quedar explícitas.

Una ficha breve para operar sin confusiones

• Dominio y responsable de renovación; contacto autorizado.
• DNS autoritativo y responsable de cambios.
• Cuenta, raíz documental y aplicación que debe responder.
• Correo local o externo; certificado y nombres cubiertos.
• Respaldo: archivos y base de datos necesarios, fecha y procedimiento de recuperación comprobado.
• Cuotas y consumo observados; tareas programadas y responsable, sin añadir cron jobs por defecto.

Cuando amplíes el alojamiento, compara estos requisitos con límites y soporte contratado. El número de dominios no expresa por sí solo la capacidad para tráfico o aplicaciones; no hay una promesa universal de crecimiento sin restricciones.

Qué puede aportar la IA y qué no debe decidir

Puede ayudar a ordenar una ficha ficticia o detectar contradicciones entre nombres y rutas que tú le proporciones. No conoce por sí sola tu DNS autoritativo, permisos o configuración vigente, y puede inventar opciones de menú. No compartas credenciales, zonas completas con datos ajenos ni información privada de clientes. Contrasta cada propuesta con la documentación y con una lectura autorizada del panel; la decisión y la comprobación siguen siendo humanas.

Cuándo conviene pedir ayuda

Si no está claro quién controla DNS o correo, si mezclas clientes en una cuenta o si mover una raíz puede afectar una tienda, solicita una revisión del mapa antes del cambio. Un socio experimentado aporta valor al delimitar responsabilidades, planear reversión y comprobar el resultado; no por prometer que una interfaz evita todos los errores. Confirma alcance, horarios y exclusiones del soporte por escrito.

Puedes resolver una organización sencilla con tu proveedor actual. Si necesitas comparar una propuesta, cuéntanos cuántos proyectos tienes y qué debe quedar separado, sin enviar contraseñas. Lleva la ficha anterior: ayuda a evaluar una solución concreta, no solo una cuota.