Le site de staging redirige vers le site live : causes & solutions

Si votre site de staging WordPress redirige vers le site live (de production), la cause est presque toujours l’une de ces trois choses : des permaliens désactivés sur le site de staging, une règle de réécriture .htaccess ou serveur pointant vers le domaine de production, ou un plugin (SSL, redirection, sécurité ou langue) qui force la redirection. La solution la plus rapide est de vider les permaliens du site de staging — réglez-les sur « Nom de l’article » et enregistrez.

Diagnostic rapide — essayez ceci dans l’ordre :

Pourquoi votre site de staging redirige-t-il vers le site live ?

WordPress stocke deux URL dans la table wp_options — siteurl et home. Lorsque vous clonez ou migrez un site, ces valeurs ainsi que les règles de permaliens déterminent comment WordPress construit et résout les liens. Un site de staging redirige vers la production lorsque l’un de ces éléments pointe encore vers le domaine live, ou réécrit vers celui-ci :

• Les permaliens sont désactivés sur le site de staging, donc WordPress retombe sur des liens simples qui ne se résolvent pas dans le dossier de staging.
• Une règle de réécriture dans .htaccess (Apache) ou nginx.conf (Nginx) cible encore la racine du document de production.
• Un plugin (SSL, redirection, adhésion, sécurité ou langue) émet sa propre redirection vers l’URL live.

Les sections ci-dessous parcourent chaque cause, en commençant par celle qui résout la plupart des cas.

Solution rapide : activer les permaliens sur le site de staging

Par défaut, WP Staging définit la structure des permaliens sur le type simple, donc le passage à « Nom de l’article » et l’enregistrement résolvent souvent à eux seuls les problèmes de redirection de liens. D’après notre expérience, c’est de loin la première étape la plus efficace — essayez-la avant toute autre chose.

En savoir plus : Comment activer les permaliens WordPress.

Corriger les redirections causées par les URL et .htaccess

Utilisez des URL absolues plutôt que relatives

Vérifiez la structure des liens qui redirige vers le site web de production. WP Staging ne peut pas effectuer de recherche & remplacement sur les liens relatifs, il a donc besoin de liens absolus pour exécuter une recherche & remplacement automatique.

Par exemple :

Lien fonctionnel : https://domain.com/path-to-page Lien non fonctionnel : /path-to-page

Pour résoudre cela, vous avez trois options :

• A. Créez un nouveau site de staging et utilisez un sous-domaine pour celui-ci. Ainsi, les liens relatifs n’ont aucun effet secondaire et fonctionnent comme prévu.
• B. Utilisez des URL absolues plutôt que des liens relatifs. Convertissez tous les liens relatifs en liens absolus — faites-le d’abord sur le site live puis clonez à nouveau, ou modifiez les liens du site de staging après l’avoir créé.
• C. Ignorez les liens relatifs non fonctionnels et ouvrez directement les pages du tableau de bord d’administration si vous souhaitez les modifier.

La méthode recommandée est l’option A ou B, car elle rend le travail sur le site de staging bien plus simple que d’ouvrir chaque page depuis le tableau de bord d’administration.

Supprimer ou modifier le .htaccess (Apache uniquement)

Ceci s’applique uniquement si votre site utilise le serveur web Apache.

Lorsque vous clonez votre site web dans un sous-dossier, WP Staging supprime le .htaccess sur le site cloné, car WordPress utilise le .htaccess du dossier racine de votre site de production. Si un plugin recrée le .htaccess sur le site de staging, ce fichier peut écraser les règles de réécriture et casser les permaliens sur le staging.

Si cela se produit, renommez le .htaccess du site de staging en quelque chose d’autre comme .htaccess-disabled et essayez de recharger le site de staging. Vous pouvez le renommer avec votre client FTP, le gestionnaire de fichiers cPanel ou un plugin de gestion de fichiers.

Corrections au niveau du serveur pour Bitnami et Nginx

Paramètres .htaccess de Bitnami

Si vous exécutez WordPress dans une instance Bitnami, des étapes supplémentaires sont nécessaires. Les permaliens de type « Nom de l’article » ne sont pas pris en charge nativement sur Bitnami, car il n’utilise pas de fichier .htaccess dans le dossier racine du site web — il ignore tout .htaccess qui s’y trouve.

À la place, Bitnami conserve toute la configuration .htaccess dans un fichier appelé /opt/bitnami/apps/APPNAME/conf/htaccess.conf. Pour faire fonctionner les permaliens, modifiez htaccess.conf et ajoutez ce qui suit :

<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>

Une autre option est de conserver les permaliens sur le réglage simple — vous n’avez alors pas besoin de modifier htaccess.conf du tout.

Ajuster nginx.conf pour le serveur web Nginx

Si vous obtenez une erreur 404 « page introuvable » et que votre serveur web est Nginx, vous devrez ajuster le nginx.conf de votre serveur web. Dans ce cas, suivez cet article pour le faire.

Corriger les redirections dues aux options de clonage et aux conflits de plugins

Cloner vers un sous-domaine

Si vous ne parvenez pas à résoudre le problème de redirection, clonez votre site web WordPress vers un sous-domaine et un dossier distinct à l’aide de l’option de chemin cible et de nom d’hôte personnalisés de WP STAGING | PRO :

Nous avons rédigé un guide complet sur le clonage de votre site WordPress vers un sous-domaine : https://wp-staging.com/docs/create-a-staging-site-clone-wordpress/#Clone_to_a_Subdomain

Plugins de langue comme WPML ou Polylang

Si vous utilisez un plugin de langue comme Polylang ou WPML qui ajoute un slug de langue à l’URL — par exemple https://example.com/en/page1 —, vous devrez activer les permaliens « Nom de l’article » sur votre site de staging. Sinon, cela peut être une autre cause de redirection vers le site live.

Désactiver les plugins de sécurité & de connexion sur le site de staging

Créez un nouveau site web de staging et désactivez ces plugins en excluant les dossiers de plugins du processus de clonage :

• Plugins de sécurité comme Wordfence, iThemes Security, Cerber, WP Spamshield, etc.
• Plugins de cache comme W3 Total Cache, WP Rocket, etc.
• Plugins de langue comme WPML, Polylang (ou activez les permaliens sur le site de staging)
• Plugins de redirection ou « Hide my Login »

Si vous avez déjà créé un site web de staging et devez désactiver ces plugins, vous pouvez désactiver un plugin spécifique en renommant son dossier via FTP ou un plugin de gestion de fichiers. Par exemple, désactivez WP Spamshield en renommant stagingsite/wp-content/plugins/wp-spamshield en quelque chose d’autre.

Désactiver les plugins de redirection sur le site de staging

Certains plugins provoquent des redirections — des plugins de redirection dédiés, des plugins d’adhésion ou des plugins SSL qui forcent le HTTPS lorsque vous ouvrez le site en HTTP. Quelques exemples :

• Really Simple SSL
• Redirection
• Ultimate Member

Si vous utilisez l’un d’eux sur votre site de staging, créez un nouveau site de staging mais excluez ce plugin du processus de clonage. Vous pouvez aussi désactiver le plugin fautif en renommant son dossier via FTP en quelque chose comme /wp-content/plugins/plugin-name-disabled.

Toujours une redirection vers le site de production ?

Parcourez ce court arbre de décision si les étapes ci-dessus n’ont pas résolu le problème :

1. Avez-vous vidé les permaliens ? Réglez-les sur « Nom de l’article » et enregistrez à nouveau — cela efface les règles de réécriture obsolètes.
2. Le serveur web est-il Apache ou Nginx ? Apache → vérifiez .htaccess ; Nginx → vérifiez nginx.conf ; Bitnami → vérifiez htaccess.conf.
3. siteurl et home dans wp_options pointent-ils vers l’URL de staging ? S’ils contiennent encore le domaine live, le site de staging continuera de rediriger. (Pour le contexte, consultez le guide de WordPress sur la modification de l’URL du site.)
4. Avez-vous écarté les plugins ? Désactivez les plugins SSL, de redirection, de sécurité et de langue un par un.

S’il redirige toujours après tout cela, veuillez ouvrir un ticket de support et nous vous aiderons à résoudre le problème de redirection.

Foire aux questions

Pourquoi mon site de staging va-t-il vers le domaine live au lieu du staging ?

Parce que quelque chose se résout encore vers le domaine de production — généralement des permaliens désactivés, une règle de réécriture .htaccess/nginx.conf ou un plugin de redirection. Videz d’abord les permaliens ; si cela ne résout pas le problème, vérifiez les règles de réécriture du serveur et les plugins.

Quelle est la toute première chose à essayer ?

Réglez les permaliens du site de staging sur « Nom de l’article » et enregistrez. Ce vidage résout la redirection dans la plupart des cas et prend quelques secondes.

Mon site de staging affiche une erreur 404 sur toutes les pages sauf la page d’accueil. Quel est le problème ?

Ce schéma pointe vers les règles de réécriture. Sur Apache, renommez ou corrigez le .htaccess du staging ; sur Nginx, ajustez nginx.conf ; sur Bitnami, modifiez htaccess.conf. Puis videz les permaliens.

Un plugin de sécurité ou SSL peut-il provoquer la redirection ?

Oui. Les plugins SSL qui forcent le HTTPS ainsi que les plugins de redirection/sécurité peuvent envoyer les requêtes de staging vers l’URL live. Excluez-les ou désactivez-les sur le site de staging.