Preproducción WordPress de cliente: montarla y probar antes

Por qué una preproducción y no probar en el sitio en línea

Lo que le aporta la preproducción

• Actualizaciones sin sorpresas — cada cambio de núcleo, tema o plugin se ve en pantalla antes de llegar a los visitantes.
• Un diagnóstico legible — los errores van a un registro, no delante del cliente, y la causa se encuentra antes de que llame.
• Una revisión compartida — el cliente o su jefe de proyecto valida en una dirección aparte, sin tocar el sitio público.
• Un diario de cambios — anota la versión anterior y la nueva de cada plugin, y repite exactamente lo mismo en producción.
• Un ensayo de novedades — tema nuevo, constructor de páginas nuevo, módulo de pago nuevo: todo se juzga sobre una copia.
• Una vuelta atrás preparada — la copia de seguridad se hace y se comprueba antes de la prueba, no después del incidente.

Requisitos con cifras antes de copiar

Montar la preproducción, paso a paso

1. 01

   Hacer copia de seguridad de producción antes de escribir nada

   Desde la carpeta del sitio en línea:
   mkdir -p ~/preprod-backups
wp db export ~/preprod-backups/before-staging.sql --single-transaction
tar -czf ~/preprod-backups/files-before-staging.tar.gz -C ~/public_html .
   Compruebe que ambos archivos existen y no están vacíos con ls -lh ~/preprod-backups. Las copias de seguridad del plan no eximen de este gesto: su frecuencia depende del plan, así que pueden tener varios días.

2. 02

   Crear el subdominio y su carpeta

   Cree staging.your-domain.com en cPanel (la guía «Crear un subdominio en cPanel» detalla la pantalla) con una carpeta raíz propia, preferiblemente fuera de public_html, por ejemplo ~/staging.your-domain.com. Una carpeta dentro de public_html también sería accesible desde una dirección del sitio en línea. Espere a que se emita el certificado TLS del subdominio antes de probar.

3. 03

   Copiar los archivos

   rsync -a --exclude='wp-content/cache/' ~/public_html/ ~/staging.your-domain.com/
   Adapte la ruta de origen a la carpeta raíz del sitio del cliente. Sin terminal, el administrador de archivos de cPanel permite comprimir la carpeta, moverla y extraerla en la carpeta del subdominio.

4. 04

   Crear una base y un usuario dedicados

   En la sección de bases de datos MySQL de cPanel, cree una base nueva y un usuario, y concédale todos los privilegios solo sobre esa base. Luego abra el wp-config.php de la copia y cambie DB_NAME, DB_USER y DB_PASSWORD. Es el error más caro de esta guía: copiar wp-config.php sin modificar esas tres líneas hace que la preproducción escriba en la base de producción.

5. 05

   Importar la base

   Desde la carpeta de la copia:
   cd ~/staging.your-domain.com
wp db import ~/preprod-backups/before-staging.sql
wp option get siteurl
   La última orden debe mostrar todavía la dirección de producción: es normal, las URL aún no se han reemplazado. Si falla, wp-config.php sigue apuntando a la base equivocada.

6. 06

   Reemplazar las URL, primero en seco

   wp search-replace 'https://your-domain.com' 'https://staging.your-domain.com' --all-tables --skip-columns=guid --dry-run
   Lea el informe: enumera las tablas y el número de reemplazos. Después repita la misma orden sin --dry-run. WordPress guarda muchos ajustes como datos serializados, donde cada cadena lleva su longitud: un sed sobre la exportación cambia la longitud de la URL sin corregir esa cuenta, y los ajustes quedan ilegibles. wp search-replace entiende esos datos y los reescribe correctamente.

7. 07

   Fijar los ajustes de preproducción en wp-config.php

   Añada, encima de la línea «That's all, stop editing»:
   define('WP_ENVIRONMENT_TYPE', 'staging');
define('DISABLE_WP_CRON', true);
define('DISALLOW_FILE_EDIT', true);
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
   Los errores van a wp-content/debug.log sin mostrarse a los visitantes. WP_ENVIRONMENT_TYPE existe desde WordPress 5.5 y admite local, development, staging y production: permite que temas y plugins se adapten, pero no oculta el sitio a los buscadores, de ahí el paso siguiente.

8. 08

   Cerrar el acceso y pedir el noindex

   En Ajustes › Lectura, marque «Disuadir a los motores de búsqueda de indexar este sitio», o desde la línea de comandos: wp option update blog_public 0. Añada después autenticación HTTP a la carpeta de la copia: un archivo .htpasswd creado con htpasswd -c ~/.htpasswd-staging client, y en el .htaccess de la carpeta las directivas AuthType Basic, AuthName "Preproduction", AuthUserFile apuntando a ese archivo y Require valid-user. En su defecto, limite el acceso a una lista de IP.

9. 09

   Comprobar la copia como lo haría un robot

   curl -sI https://staging.your-domain.com/
   La respuesta debe ser un 401. Después, con las credenciales:
   curl -s -u client https://staging.your-domain.com/ | grep -i robots
   Debe verse una etiqueta meta name='robots' que contenga noindex. Si un plugin de caché o de SEO la sustituye, es ese el que hay que configurar. Por último, compruebe que el tema no contiene ninguna dirección de producción escrita a mano: grep -r "https://your-domain.com" wp-content/themes.

10. 10

    Integrar la preproducción en su rutina de agencia

    Convierta este montaje en una plantilla: un subdominio por cliente, en la cuenta cPanel del cliente, con la misma lista de comprobación. El orden de las operaciones para trasladar un sitio a otro alojamiento lo cubre la guía «Migrar un sitio WordPress de cliente sin cortes»; la preproducción descrita aquí es una herramienta duradera, no un paso de la migración.

Aislar de verdad: el noindex no basta

Neutralizar correos, pagos y tareas programadas

Lista de comprobación antes de tocar un solo plugin

• Correos — plugin de envío en modo de prueba o redirigido a un buzón de revisión, notificaciones de la tienda desactivadas.
• Pagos — pasarela en modo de prueba, claves de producción retiradas de la copia, direcciones de retorno (webhooks) no declaradas para la preproducción.
• Tareas programadas — DISABLE_WP_CRON definido, eventos pendientes listados con wp cron event list.
• Edición de archivos — DISALLOW_FILE_EDIT activo para no editar el código desde la administración.
• Registro de errores — WP_DEBUG_LOG activo y WP_DEBUG_DISPLAY en false.
• Integraciones de terceros — CRM, directorios, herramientas de estadísticas y claves de API de producción sustituidos o retirados.
• Buscadores — noindex fijado y autenticación en su sitio, comprobados con curl como arriba.

Probar las actualizaciones, una a una

Cuando la actualización rompe: leer debug.log

Solución de problemas: los otros síntomas que sí aparecen

• El sitio redirige a producción — wp option get siteurl y wp option get home muestran aún la dirección antigua, o un constructor de páginas conserva URL escritas a mano; repita el reemplazo, con --precise si hace falta.
• «Error al establecer una conexión con la base de datos» — DB_NAME, DB_USER, DB_PASSWORD o DB_HOST de la copia son incorrectos, o el usuario no tiene derechos sobre la base nueva.
• Imágenes o estilos cargados desde producción — las URL escapadas, como https:\/\/ en los datos JSON de los constructores, escaparon al reemplazo; repítalo con esa forma.
• Bucle de inicio de sesión o cierre inmediato — las cookies pertenecen al dominio antiguo; bórrelas y compruebe siteurl y home.
• La preproducción aparece en un buscador — el noindex se fijó demasiado tarde o un plugin lo sustituye; pase a la autenticación HTTP y solicite la retirada de la dirección.

Archivos o base: qué se traslada y cómo

Desplace la tabla

Pasar a producción y poder volver atrás

Una rutina que aguanta a escala de cartera