Segregación de entornos de desarrollo y producción en subdominios

En hosting compartido es frecuente que equipos y autónomos gestionen tanto la versión pública (producción) como una copia de pruebas (desarrollo o staging) en el mismo proveedor. Separar correctamente ambos entornos en subdominios —por ejemplo, staging.ejemplo.com y www.ejemplo.com— reduce riesgos operativos, evita filtraciones SEO y facilita despliegues seguros. Esta guía técnica explica cómo implementar esa segregación de forma práctica y segura en entornos compartidos.

Por qué segregar entornos: riesgos y beneficios

Separar entornos no es solo una buena práctica: previene errores graves. Entre los riesgos más habituales están la indexación de contenido no final, exposición de datos de prueba, sobrescritura accidental de la base de datos en producción y problemas de configuración que afectan a usuarios reales.

• Protección frente a indexación accidental y pérdida de reputación.
• Aislamiento de bases de datos y credenciales: evita contaminaciones entre entornos.
• Control de acceso para testing colaborativo sin exponer la web pública.
• Facilita rollback y pruebas A/B controladas.

Diseño recomendado: dominio principal y subdominio de staging

En hosting compartido la opción más práctica es mantener el dominio principal en producción y crear un subdominio para desarrollo o staging. Nombres habituales:

• www.ejemplo.com — Producción
• staging.ejemplo.com o dev.ejemplo.com — Desarrollo / Pruebas

Ventajas del subdominio frente a un subdirectorio: independencia de cookies, certificados SSL y posibilidad de apuntar a directorios o instancias distintas sin interferencias.

Configuración técnica paso a paso en hosting compartido

1. Crear el subdominio y directorio

Desde el panel de control (cPanel, Plesk u otro):

• Crear el subdominio (staging.ejemplo.com) y asignar un directorio raíz separado (por ejemplo public_html/staging).
• Subir la copia del sitio al directorio del subdominio o clonar desde un backup.

2. DNS: registros apropiados

Añade un registro A o CNAME según tu configuración:

• Registro A que apunte a la IP del servidor si el proveedor lo solicita.
• Registro CNAME que apunte a tu dominio principal en entornos con balanceo o CDN.

Comprueba la propagación con herramientas DNS antes de continuar.

3. Bases de datos y credenciales separadas

Siempre crear una base de datos distinta para el subdominio. Recomendaciones prácticas:

• Prefijar nombres: wp_staging, stg_db.
• Crear un usuario con permisos mínimos (SELECT, INSERT, UPDATE, DELETE) y no reutilizar credenciales de producción.
• Actualizar ficheros de configuración (por ejemplo wp-config.php) con los nuevos datos.

4. SSL: cifrado para ambos entornos

No dejes el subdominio sin HTTPS. En hosting compartido puedes solicitar certificados gratuitos con Let’s Encrypt o usar la integración del panel. Atención con certificados wildcard: requieren validación DNS, que en muchos hostings compartidos puede ser más complejo.

Control de acceso y medidas para evitar indexación

Un subdominio de staging debe estar protegido. Las medidas combinadas reducen el riesgo de accesos no autorizados y de indexación por motores de búsqueda.

Autenticación básica (HTTP Auth)

La forma más directa en hosting compartido es activar autenticación básica mediante el panel o .htpasswd. Ejemplo mínimo para .htaccess (colócalo en la raíz del subdominio):

AuthType Basic
AuthName 'Acceso privado'
AuthUserFile /ruta/a/.htpasswd
Require valid-user

Esta capa detiene a la mayoría de crawlers y evita que usuarios no autorizados vean contenido en pruebas.

Restricción por IP y VPNs

Si el equipo trabaja desde ubicaciones fijas, restringe el acceso por IP en .htaccess o con reglas del panel. Otra opción es usar una VPN o servicios de control de acceso (por ejemplo, reglas en CDN).

Noindex y cabeceras

Agrega meta robots noindex en las páginas de staging y, mejor aún, envía la cabecera HTTP X-Robots-Tag: noindex, nofollow para bloquear indexación a nivel servidor. La cabecera es más robusta y puede aplicarse desde .htaccess o mediante la configuración del servidor. Para referencia técnica sobre cabeceras consulta la documentación de HTTP en MDN.

Consideraciones específicas para WordPress en hosting compartido

WordPress es común en hosting compartido; estas pautas aplican directamente:

• Crear un wp-config.php con constantes que diferencien entornos: definir WP_ENV u otras banderas para activar/desactivar plugins o mostrar errores.
• Desactivar módulos de caché y CDN en staging o configurarlos para no cachear para evitar confusiones.
• Usar prefijos de tabla distintos si compartes una base de datos (no recomendado), por ejemplo stg_.
• Reemplazar URLs internas con herramientas de búsqueda y reemplazo (asegúrate de serializar correctamente campos PHP serializados).

Despliegue y sincronización: buenas prácticas

Evita sincronizaciones manuales riesgosas. Recomendaciones:

• Usar scripts o plugins de migración que respeten búsquedas/URLs y excluyan tablas sensibles (usuarios, pagos).
• Automatizar backups antes de cada sincronización y conservar varios puntos de restauración.
• Etiquetar claramente los entornos en el backend y registros para que el equipo no confunda staging con producción.

Seguridad complementaria y hardening

Además del control de acceso, implemente medidas adicionales:

• Escanear dependencias y plugins por vulnerabilidades y mantener versiones actualizadas.
• Limitar acceso a phpMyAdmin y paneles administrativos a IPs específicas.
• Hacer auditorías periódicas y revisar los logs de acceso.

Para buenas prácticas de seguridad y pruebas de exposición, la comunidad de seguridad pública recursos útiles en OWASP.

Uso de CDN y control externo (opcional en hosting compartido)

Si tu hosting compartido permite configuración de CDN o proxy inverso, puedes aplicar reglas restrictivas a nivel de CDN (por ejemplo autenticación por token, listas de permitidos) y reducir carga en el servidor. Para configuraciones avanzadas y control de acceso a nivel de red, la documentación de proveedores como Cloudflare ofrece ejemplos sobre cómo proteger subdominios y aplicar reglas.

Checklist final antes de publicar en producción

• Verificar que el subdominio de staging tiene autenticación y no es indexable (X-Robots-Tag y meta robots).
• Confirmar bases de datos y credenciales independientes.
• Certificados SSL instalados correctamente en ambos nombres.
• Backups automáticos y políticas de rollback documentadas.
• Reglas de caché y CDN coherentes entre entornos.

Conclusión

Segregar entornos de desarrollo y producción mediante subdominios en hosting compartido es una estrategia práctica y efectiva que reduce riesgos técnicos y SEO. La clave está en una separación clara de recursos (archivos, bases de datos, credenciales), protección del subdominio de staging mediante autenticación y cabeceras anti-indexación, y en procesos de despliegue y backup bien definidos. Aunque el hosting compartido impone algunas limitaciones, aplicando las medidas descritas se consigue un flujo de trabajo seguro y profesional sin necesidad de infraestructuras complejas.

Si trabajas con sitios dinámicos o WordPress, prioriza la separación de bases de datos y la protección de endpoints administrativos. Para implementaciones avanzadas (wildcard SSL o validación DNS automatizada) consulta la documentación de Let’s Encrypt y las guías del proveedor de CDN que utilices.