El sitio de staging redirige al sitio en producción: causas y soluciones

Si tu sitio de staging de WordPress redirige al sitio en producción (live), la causa casi siempre es una de estas tres cosas: enlaces permanentes desactivados en el sitio de staging, una regla de reescritura en .htaccess o en el servidor que apunta al dominio de producción, o un plugin (de SSL, redirección, seguridad o idioma) que fuerza la redirección. La solución más rápida es regenerar los enlaces permanentes del sitio de staging: configúralos como "Post name" y guarda.

Diagnóstico rápido: prueba estas opciones en orden:

¿Por qué tu sitio de staging redirige al sitio en producción?

WordPress almacena dos URLs en la tabla wp_options: siteurl y home. Cuando clonas o migras un sitio, esos valores más las reglas de enlaces permanentes determinan cómo WordPress construye y resuelve los enlaces. Un sitio de staging redirige a producción cuando uno de estos elementos aún apunta al dominio en producción o reescribe hacia él:

• Los enlaces permanentes están desactivados en el sitio de staging, por lo que WordPress recurre a enlaces planos que no se resuelven en la carpeta de staging.
• Una regla de reescritura en .htaccess (Apache) o nginx.conf (Nginx) todavía apunta a la raíz del documento de producción.
• Un plugin (de SSL, redirección, membresía, seguridad o idioma) emite su propia redirección a la URL de producción.

Las secciones siguientes recorren cada causa, empezando por la que resuelve la mayoría de los casos.

Solución rápida: activa los enlaces permanentes en el sitio de staging

De forma predeterminada, WP Staging establece la estructura de enlaces permanentes en el tipo plano, así que cambiarla a "Post name" y guardar a menudo resuelve por sí solo los problemas de redirección de enlaces. Según nuestra experiencia, este es el primer paso más eficaz: pruébalo antes que cualquier otra cosa.

Más información: Cómo activar los enlaces permanentes de WordPress.

Soluciona las redirecciones causadas por URLs y .htaccess

Usa URLs absolutas en lugar de relativas

Comprueba la estructura de enlaces que redirige de vuelta al sitio en producción. WP Staging no puede buscar y reemplazar enlaces relativos, por lo que necesita enlaces absolutos para ejecutar una búsqueda y reemplazo automáticos.

Por ejemplo:

Enlace que funciona: https://domain.com/path-to-page Enlace que no funciona: /path-to-page

Para resolverlo, tienes tres opciones:

• A. Crea un nuevo sitio de staging y usa un subdominio para él. Así los enlaces relativos no tienen efectos secundarios y funcionan como se espera.
• B. Usa URLs absolutas en lugar de enlaces relativos. Convierte todos los enlaces relativos en absolutos: hazlo primero en el sitio en producción y luego vuelve a clonar, o cambia los enlaces del sitio de staging después de crearlo.
• C. Ignora los enlaces relativos que no funcionan y abre directamente las páginas del panel de administración si quieres editarlas.

La forma recomendada es la opción A o B, ya que hace que trabajar en el sitio de staging sea mucho más sencillo que abrir cada página desde el panel de administración.

Elimina o edita el .htaccess (solo Apache)

Esto solo aplica si tu sitio usa el servidor web Apache.

Cuando clonas tu sitio web en una subcarpeta, WP Staging elimina el .htaccess del sitio clonado, porque WordPress usa el .htaccess de la carpeta raíz de tu sitio en producción. Si un plugin vuelve a crear el .htaccess en el sitio de staging, ese archivo puede sobrescribir las reglas de reescritura y romper los enlaces permanentes en staging.

Si eso ocurre, renombra el .htaccess del sitio de staging a otro nombre como .htaccess-disabled e intenta recargar el sitio de staging. Puedes renombrarlo con tu cliente FTP, el administrador de archivos de cPanel o un plugin de administración de archivos.

Soluciones a nivel de servidor para Bitnami y Nginx

Configuración del .htaccess en Bitnami

Si ejecutas WordPress en una instancia de Bitnami, necesitas pasos adicionales. Los enlaces permanentes de tipo "Post name" no se admiten de forma predeterminada en Bitnami porque no utiliza un archivo .htaccess en la carpeta raíz del sitio web: ignora cualquier .htaccess que haya allí.

En su lugar, Bitnami guarda toda la configuración del .htaccess en un archivo llamado /opt/bitnami/apps/APPNAME/conf/htaccess.conf. Para que los enlaces permanentes funcionen, edita htaccess.conf y añade lo siguiente:

<Directory /opt/bitnami/apps/wordpress/htdocs/STAGING>
 <IfModule mod_rewrite.c>
 RewriteEngine On
 RewriteBase /STAGING/
 RewriteRule ^index.php$ - [L]
 RewriteCond %{REQUEST_FILENAME} !-f
 RewriteCond %{REQUEST_FILENAME} !-d
 RewriteRule . /STAGING/index.php [L]
 </IfModule>
 </Directory>

Otra opción es mantener los enlaces permanentes en la configuración plana: entonces no necesitas cambiar htaccess.conf en absoluto.

Ajusta nginx.conf para el servidor web Nginx

Si obtienes un error 404 "página no encontrada" y tu servidor web es Nginx, tendrás que ajustar el nginx.conf de tu servidor web. En ese caso, sigue este artículo para hacerlo.

Soluciona las redirecciones por opciones de clonación y conflictos de plugins

Clona a un subdominio

Si no puedes resolver el problema de la redirección, clona tu sitio web de WordPress en un subdominio y una carpeta separada usando la opción de ruta de destino y nombre de host personalizados de WP STAGING | PRO:

Hemos escrito una guía detallada sobre cómo clonar tu sitio de WordPress en un subdominio: https://wp-staging.com/docs/create-a-staging-site-clone-wordpress/#Clone_to_a_Subdomain

Plugins de idioma como WPML o Polylang

Si usas un plugin de idioma como Polylang o WPML que añade un slug de idioma a la URL —por ejemplo https://example.com/en/page1— tendrás que activar los enlaces permanentes de tipo "Post name" en tu sitio de staging. De lo contrario, esta puede ser otra causa de una redirección al sitio en producción.

Desactiva los plugins de seguridad e inicio de sesión en el sitio de staging

Crea un nuevo sitio web de staging y desactiva estos plugins excluyendo las carpetas de plugins del proceso de clonación:

• Plugins de seguridad como Wordfence, iThemes Security, Cerber, WP Spamshield, etc.
• Plugins de caché como W3 Total Cache, WP Rocket, etc.
• Plugins de idioma como WPML, Polylang (o activa los enlaces permanentes en el sitio de staging)
• Plugins de redirección o de tipo "Hide my Login"

Si ya creaste un sitio web de staging y necesitas desactivar estos plugins, puedes desactivar un plugin concreto renombrando su carpeta vía FTP o con un plugin de administración de archivos. Por ejemplo, desactiva WP Spamshield renombrando stagingsite/wp-content/plugins/wp-spamshield a otro nombre.

Desactiva los plugins de redirección en el sitio de staging

Algunos plugins provocan redirecciones: plugins de redirección específicos, plugins de membresía o plugins de SSL que fuerzan HTTPS cuando abres el sitio por HTTP. Algunos ejemplos:

• Really Simple SSL
• Redirection
• Ultimate Member

Si usas alguno de estos en tu sitio de staging, crea un nuevo sitio de staging pero excluye ese plugin del proceso de clonación. Como alternativa, desactiva el plugin problemático renombrando su carpeta vía FTP a algo como /wp-content/plugins/plugin-name-disabled.

¿Sigue redirigiendo al sitio en producción?

Recorre este breve árbol de decisión si los pasos anteriores no lo resolvieron:

1. ¿Regeneraste los enlaces permanentes? Configúralos como "Post name" y guarda de nuevo: esto limpia las reglas de reescritura obsoletas.
2. ¿El servidor web es Apache o Nginx? Apache → revisa .htaccess; Nginx → revisa nginx.conf; Bitnami → revisa htaccess.conf.
3. ¿siteurl y home en wp_options apuntan a la URL de staging? Si todavía contienen el dominio de producción, el sitio de staging seguirá redirigiendo. (Como contexto, consulta la guía de WordPress para cambiar la URL del sitio).
4. ¿Descartaste los plugins? Desactiva los plugins de SSL, redirección, seguridad e idioma de uno en uno.

Si sigue redirigiendo después de todo esto, por favor abre un ticket de soporte y te ayudaremos a resolver el problema de la redirección.

Preguntas frecuentes

¿Por qué mi sitio de staging va al dominio en producción en lugar de al de staging?

Porque algo todavía se resuelve al dominio en producción: normalmente los enlaces permanentes desactivados, una regla de reescritura en .htaccess/nginx.conf o un plugin de redirección. Regenera primero los enlaces permanentes; si eso no lo soluciona, revisa las reglas de reescritura del servidor y los plugins.

¿Qué es lo primero que debería probar?

Configura los enlaces permanentes del sitio de staging como "Post name" y guarda. Esta regeneración resuelve la redirección en la mayoría de los casos y tarda segundos.

Mi sitio de staging muestra un error 404 en todas las páginas excepto en la de inicio. ¿Qué pasa?

Ese patrón apunta a las reglas de reescritura. En Apache, renombra o corrige el .htaccess de staging; en Nginx, ajusta nginx.conf; en Bitnami, edita htaccess.conf. Después, regenera los enlaces permanentes.

¿Puede un plugin de seguridad o de SSL causar la redirección?

Sí. Los plugins de SSL que fuerzan HTTPS y los plugins de redirección/seguridad pueden enviar las solicitudes de staging a la URL en producción. Exclúyelos o desactívalos en el sitio de staging.