Créer un site de staging WordPress pour tester avant de publier

C’est quoi un site de staging WordPress ?

Un site de staging WordPress est une copie privée de ton site en ligne.

Il reprend généralement les mêmes fichiers, la même base de données, les mêmes extensions, le même thème et les mêmes réglages. La différence, c’est qu’il n’est pas destiné aux visiteurs. Il sert à tester.

Tu peux l’utiliser pour vérifier :

• une mise à jour WordPress ;
• une nouvelle version PHP ;
• un changement de thème ;
• une extension sensible ;
• une refonte de page ;
• une modification de code ;
• un réglage de cache ;
• une optimisation technique ;
• une migration d’hébergement.

Le staging est donc une zone de sécurité. Ton vrai site continue de fonctionner pendant que tu testes ailleurs. Si quelque chose casse en staging, ce n’est pas agréable, mais ce n’est pas visible par tes visiteurs. Et ça change tout.

Pourquoi créer un staging au lieu de tester en direct ?

Quand ton site WordPress est en ligne, il peut se passer quelque chose à tout moment : une visite, un formulaire, une commande, une demande de contact. Tester une mise à jour directement dessus, c’est donc prendre le risque de casser quelque chose pendant qu’un visiteur est là.

Le staging WordPress permet de séparer le test de la production.

Tu peux tester une mise à jour, repérer une erreur, ajuster une page, tester une extension sans exposer les visiteurs à une mauvaise surprise.

C’est particulièrement utile avant une migration technique. Quand tu prépares un changement d’hébergement, un environnement de test aide à vérifier les points sensibles comme la version PHP, les emails, le cache, les redirections et les limites serveur. Par exemple, les questions à se poser avant de migrer d’hébergeur permettent justement de cadrer ces vérifications avant de bouger un site qui fonctionne déjà.

Tester en direct peut sembler plus rapide. Jusqu’au moment où le site affiche une erreur, qu’un formulaire ne part plus ou qu’une mise en page explose sur mobile.

Quand faut-il créer un site de staging ?

Un site de staging n’est pas nécessaire pour modifier une virgule dans un article. Il devient utile dès qu’une action peut toucher au fonctionnement du site.

Je te conseil de créer un site de staging avant :

• une mise à jour majeure de WordPress ;
• une migration vers une nouvelle version PHP ;
• une refonte de page importante ;
• un changement de thème ;
• l’installation d’un plugin sensible ;
• une modification dans le code ;
• une optimisation de performance ;
• un changement de cache ;
• une migration d’hébergement ;
• une intervention sur WooCommerce.

Pour une simple correction de texte, le staging serait excessif. Pour une mise à jour PHP, un changement de thème ou un nouveau plugin de paiement, il devient beaucoup plus raisonnable.

WordPress 7.1 fournit un bon exemple. Les nouveaux styles responsifs et l’éditeur entièrement isolé dans une iframe peuvent révéler une incompatibilité dans une extension. Avant de mettre le site public à jour, découvre ce que WordPress 7.1 change vraiment et les éléments à contrôler en priorité.

Un bon repère consiste à se demander si le changement peut bloquer une page, casser un formulaire, perturber le panier ou modifier l’affichage. Si oui, le staging mérite clairement sa place.

Avant de commencer, fais une sauvegarde complète

Avant de créer un site de staging WordPress, il faut disposer d’une sauvegarde fiable.

Même si le staging est censé protéger le site en ligne, tu vas manipuler des fichiers, une base de données, des URLs et parfois des outils d’hébergement. Une sauvegarde reste donc indispensable.

Ta sauvegarde doit inclure :

• les fichiers WordPress ;
• le dossier wp-content ;
• les médias ;
• le thème ;
• les plugins ;
• la base de données ;
• le fichier wp-config.php.

Une sauvegarde et restauration complète WordPress  doit permettre de revenir en arrière si une manipulation ne se passe pas comme prévu. Le staging réduit le risque, mais il ne remplace pas un vrai filet de sécurité.

C’est moins spectaculaire qu’un bouton “réparer mon site”, mais beaucoup plus fiable.

Choisir où installer le staging

Le plus simple est d’installer le staging sur un sous-domaine.

Par exemple : staging.tonsite.fr

Tu peux aussi utiliser un sous-dossier : tonsite.fr/staging/

Le sous-domaine est souvent plus propre. Il sépare mieux l’environnement de test du site principal et limite les confusions entre les deux installations.

Tu dois éviter un nom trop évident si le staging doit rester privé. Un sous-domaine comme test, dev ou staging est pratique, mais il peut être facile à deviner. Le plus important est surtout de protéger l’accès, d’empêcher l’indexation et de ne pas laisser le site de test ouvert à tout le monde.

Un staging n’est pas une deuxième vitrine publique. C’est un atelier. Et un atelier, normalement, on ne laisse pas la porte grande ouverte sur la rue.

Protéger le staging avant tout le reste

Un site de test WordPress doit être protégé.

Il ne doit pas être indexé par Google, ni accessible librement à n’importe qui, parce qu’il contient une copie complète du site de production.

Les protections nécessaires sont simples :

• bloquer l’indexation dans WordPress ;
• ajouter une protection par mot de passe ;
• désactiver les emails automatiques si nécessaire ;
• empêcher les paiements réels en test ;
• vérifier les clés API ;
• éviter les formulaires qui envoient vers les vrais outils ;
• distinguer visuellement le staging du site public.

Sur o2switch, la protection d’un dossier peut se faire depuis les outils de fichiers, notamment avec la confidentialité du répertoire. Les outils de gestion des fichiers o2switch donnent le contexte sur les options disponibles dans cPanel, comme le gestionnaire de fichiers, les comptes FTP ou la protection d’un répertoire.

Cette étape est souvent oubliée. Pourtant, elle évite de découvrir trois semaines plus tard qu’un vieux staging a été indexé avec des pages de test. 

Méthode 1 : Créer un staging WordPress à la main

Créer un staging à la main demande un peu plus de manipulation, mais c’est une méthode fiable quand on veut garder le contrôle.

Le principe est simple. Tu crées un emplacement de test, tu copies les fichiers, tu dupliques la base de données, tu relies le tout, puis tu remplaces les anciennes URLs par l’adresse du staging.

Il faut avancer étape par étape, sans se presser. Le staging est justement là pour éviter les décisions prises avec le cœur qui bat trop vite.

Créer le sous-domaine

Commence par créer un sous-domaine dans ton hébergement.

Par exemple : staging.tonsite.fr

L’hébergement va généralement te demander le dossier racine associé. Tu peux utiliser un dossier du type :

/public_html/staging/

ou un autre dossier dédié, selon la structure de ton hébergement.

L’idée est de séparer les fichiers du staging de ceux du site public. Il ne faut pas copier les fichiers n’importe où, ni mélanger production et test dans le même dossier.

Quand le sous-domaine est créé, vérifie qu’il pointe bien vers le bon dossier avant d’aller plus loin.

Copier les fichiers WordPress

Ensuite, il faut copier les fichiers du site de production vers le dossier du site de staging.

Tu peux le faire via FTP/SFTP, SSH si tu es à l’aise, ou depuis le gestionnaire de fichiers de l’hébergement.

Les éléments à copier sont généralement :

• wp-admin ;
• wp-content ;
• wp-includes ;
• les fichiers à la racine ;
• le fichier .htaccess s’il existe ;
• le fichier wp-config.php, qui sera ensuite adapté.

Le dossier wp-content/uploads peut être lourd. Si le site contient beaucoup d’images, la copie peut prendre du temps. Mieux vaut éviter de lancer ça entre deux rendez-vous avec l’idée que “ça ira vite”. WordPress adore prouver le contraire.

Une fois la copie terminée, le staging contient les fichiers, mais pas encore la base de données.

Créer une nouvelle base de données

Le staging doit utiliser sa propre base de données.

Il ne faut surtout pas le connecter à la base du site en production. Sinon, une modification faite en staging peut toucher le vrai site. Et là, le staging perd tout son intérêt.

Depuis l’hébergement, tu crées :

• une nouvelle base de données ;
• un nouvel utilisateur ;
• un mot de passe solide ;
• les droits nécessaires pour cet utilisateur sur cette base.

Sur o2switch, les outils de bases de données permettent de créer et gérer les bases MySQL, les utilisateurs et phpMyAdmin. Les outils de bases de données o2switch donnent un repère utile pour retrouver ces options dans l’interface.

Note bien le nom de la base, l’utilisateur, le mot de passe et le serveur MySQL. Ces informations seront nécessaires dans wp-config.php.

Exporter puis importer la base de production

Le site WordPress stocke les contenus, réglages, utilisateurs, menus, widgets et options dans la base de données.

Il faut donc exporter la base du site public, puis l’importer dans la base créée pour le staging.

La méthode classique passe par phpMyAdmin :

• ouvrir phpMyAdmin ;
• sélectionner la base du site en production ;
• exporter la base au format SQL ;
• ouvrir la base du staging ;
• importer le fichier SQL.

Une fois l’import terminé, le staging possède une copie des données. Il faut maintenant lui dire qu’il doit utiliser sa propre base.

Modifier le fichier wp-config.php

Dans le dossier du staging, repère et ouvre le fichier wp-config.php.

Il faut modifier les informations de connexion à la base de données pour utiliser la nouvelle base créée pour le staging.

Les lignes concernées ressemblent à ceci :

define( 'DB_NAME', 'nom_de_la_base_staging' );
define( 'DB_USER', 'utilisateur_staging' );
define( 'DB_PASSWORD', 'mot_de_passe_staging' );
define( 'DB_HOST', 'localhost' );

Selon l’hébergement, DB_HOST peut être localhost ou une autre valeur. Il faut reprendre l’information fournie par l’hébergeur.

Cette étape est importante. Si le staging pointe encore vers la base de production, les deux sites partagent les mêmes données. C’est exactement ce qu’on veut éviter.

Remplacer les URLs dans la base

Après la copie, la base contient encore les URLs du site en production.

Il faut remplacer : https://tonsite.fr

par : https://staging.tonsite.fr

Il ne faut pas le faire avec un simple rechercher/remplacer dans un fichier SQL ouvert à la main, surtout sur WordPress. Certaines données sont sérialisées, et une modification brutale peut casser des réglages.

Le plus propre consiste à utiliser un outil prévu pour WordPress, comme WP-CLI si tu maîtrises la ligne de commande, ou un plugin comme better search & replace fiable sur le site de staging.

L’objectif est de remplacer les URLs sans casser les données sérialisées.

Avant cette opération, vérifie encore une fois que tu travailles bien sur la base du staging. Deux minutes de vérification ici peuvent éviter une très longue soirée.

Bloquer l’indexation du staging

Une fois connecté au tableau de bord du staging, va dans :

Réglages > Lecture

Puis coche : Demander aux moteurs de recherche de ne pas indexer ce site

Cette option ne suffit pas toujours à elle seule, car elle repose sur le respect des moteurs de recherche. Elle reste utile, mais une protection par mot de passe est plus sûre.

Le staging doit rester discret. Ce n’est pas un site public. C’est la pièce où tu poses les câbles, les cartons et les idées pas encore prêtes.

Désactiver les actions sensibles

Sur un site de staging, certaines fonctionnalités doivent être neutralisées.

Selon le site, pense à vérifier :

• les formulaires de contact ;
• les emails automatiques ;
• les paiements WooCommerce ;
• les webhooks ;
• les clés API ;
• les outils CRM ;
• les newsletters ;
• les pixels publicitaires ;
• les tâches cron ;
• les intégrations de réservation.

Un site de staging doit permettre de tester sans envoyer de vrais emails, sans déclencher de vrais paiements et sans envoyer de données dans les outils de production.

C’est souvent là que les petites surprises arrivent. Un test qui envoie une vraie facture ou une vraie notification à un client, ça réveille plus vite qu’un double espresso.

UpdraftPlus – Sauvegarder en quelques clics !

UpdraftPlus, c’est l’extension de sauvegarde la plus populaire au monde, avec plus de 3 millions d’installations

Le partenaire ultime pour sauvegarder dans le Clous et restaurer en un seul clic !

→ Passer à UpdraftPlus

Méthode 2 : Créer un staging WordPress avec o2switch

Chez o2switch, la méthode la plus logique consiste à passer par WP Tiger, l’outil WordPress intégré à l’espace d’hébergement.

L’intérêt est simple : tu peux gérer ton installation WordPress depuis une interface pensée pour ça, sans forcément tout refaire à la main avec FTP, phpMyAdmin et modification du fichier wp-config.php.

Avant de lancer la création, vérifie bien :

• le domaine ou sous-domaine de destination ;
• le dossier où sera installé le staging ;
• la base de données utilisée ;
• l’accès au tableau de bord ;
• la protection contre l’indexation ;
• la différence entre le site public et le site de test.

Le point le plus important est de ne jamais confondre la production et le staging. Si tu travailles sur la mauvaise version, le filet de sécurité se transforme vite en tapis glissant.

WP Tiger permet de gérer plus facilement une installation WordPress et de préparer un environnement de test sans repartir sur une manipulation entièrement manuelle.

Avantages de WP Tiger chez o2switch

WP Tiger peut faire gagner du temps si ton site WordPress est bien reconnu par l’outil.

Tu évites une partie des manipulations techniques, notamment la copie manuelle des fichiers, la création de base, l’import SQL et les remplacements d’URLs. Pour un site vitrine ou un site WordPress classique, c’est souvent plus confortable.

Cette méthode est particulièrement pratique pour tester :

• une mise à jour WordPress ;
• une extension sensible ;
• un changement de thème ;
• une nouvelle version PHP ;
• une optimisation de cache ;
• une modification importante avant publication.

L’outil simplifie le travail, mais il ne remplace pas la vérification. Une copie automatique doit toujours être contrôlée avant d’être utilisée sérieusement.

Les limites à garder en tête

Même avec WP Tiger, un staging ne doit pas être lancé les yeux fermés.

Il faut vérifier que le site de test utilise bien son propre environnement, que les URLs sont cohérentes, que l’indexation est bloquée et que les formulaires, emails, paiements ou intégrations externes ne déclenchent pas de vraies actions.

Un outil peut préparer une copie. Il ne peut pas deviner que ton formulaire envoie des leads dans un CRM, qu’un webhook déclenche une facture ou qu’un paiement WooCommerce doit rester en mode test.

Après la création du staging, prends donc quelques minutes pour contrôler :

• l’accès au site de test ;
• l’accès à l’administration ;
• les URLs internes ;
• les formulaires ;
• les emails automatiques ;
• les moyens de paiement ;
• le cache ;
• les erreurs PHP ;
• l’affichage mobile ;
• les pages importantes.

C’est ce contrôle qui rend le staging vraiment utile. 

Que faut-il tester sur le staging ?

Créer un site de staging WordPress ne sert pas seulement à regarder si la page d’accueil s’affiche.

Il faut tester les éléments qui comptent vraiment.

Commence par les parcours essentiels :

• page d’accueil ;
• pages services ;
• page contact ;
• formulaires ;
• menu ;
• pied de page ;
• moteur de recherche ;
• pages principales du blog ;
• version mobile ;
• vitesse de chargement ;
• espace client si le site en a un ;
• panier et paiement si WooCommerce est installé.

Teste aussi ce qui a motivé la création du staging. Si tu voulais vérifier une mise à jour de plugin, teste la fonctionnalité du plugin. Si tu voulais changer PHP, regarde les erreurs, les logs et les comportements inhabituels.

Quand le staging sert à préparer une migration vers une version PHP récente, la migration WordPress vers PHP 8.3, par exemple, demande justement de tester en environnement de préproduction avant de basculer le site public.

Un staging non testé est juste une copie qui prend de la place. Le vrai intérêt commence quand tu vérifies ce qui pourrait casser.

Attention au cache sur le staging

Le cache peut brouiller les tests.

Si tu testes une modification, mais que le staging affiche encore une ancienne version de la page, tu peux croire que rien ne fonctionne. À l’inverse, un cache trop agressif peut masquer une erreur.

Sur un staging, il vaut mieux partir avec un cache simple et bien maîtrisé. Évite d’empiler plusieurs systèmes de cache, surtout si tu testes des modifications CSS, JavaScript, thème ou constructeur.

Quand tu travailles sur la performance, la distinction entre cache serveur et plugin de cache WordPress aide à comprendre ce qui se passe côté hébergement et côté WordPress. C’est particulièrement utile quand le site en production et le staging ne réagissent pas de la même façon.

Avant de valider une modification, vide le cache du staging et teste en navigation privée. Ça évite de se débattre avec une page qui date d’il y a vingt minutes.

Ne copie pas tout du staging vers la production sans réfléchir

Une fois les tests terminés, il faut remettre les changements sur le site en production.

Et là, attention. On ne pousse pas toujours tout le staging vers la production.

Si le site en ligne a reçu de nouveaux formulaires, commandes, commentaires ou contenus pendant que tu travaillais, une copie complète du staging vers la production peut écraser des données récentes.

Sur un site vitrine peu actif, une recopie complète peut parfois convenir. Sur un site WooCommerce, un espace membre ou un site avec beaucoup de formulaires, il faut être beaucoup plus précis.

Tu peux choisir de transférer seulement :

• des fichiers de thème ;
• un plugin mis à jour ;
• une page reconstruite ;
• des réglages précis ;
• un extrait de code ;
• une version PHP validée ;
• une configuration de cache.

La bonne question est simple : qu’est-ce qui a changé en staging, et qu’est-ce qui a changé en production pendant ce temps ?

Si tu ne sais pas répondre, évite de remplacer la production en bloc. C’est souvent là que les ennuis commencent.

Checklist avant de valider le staging

Avant de considérer le staging comme prêt, vérifie :

• l’accès au tableau de bord ;
• l’absence d’indexation ;
• la protection par mot de passe ;
• les formulaires ;
• les menus ;
• les pages importantes ;
• le responsive mobile ;
• les emails désactivés ou isolés ;
• les paiements en mode test si besoin ;
• les URLs internes ;
• les erreurs PHP ;
• le cache ;
• les performances ;
• les sauvegardes.

Cette checklist n’a rien d’exotique. Elle évite simplement de valider un site de test qui n’a été regardé qu’en surface.

Un staging sert à voir les problèmes avant les visiteurs. Autant lui faire faire son travail.

Les erreurs à éviter

Créer un staging peut sembler simple, mais quelques erreurs reviennent souvent.

La plus dangereuse consiste à connecter le staging à la base de production. Dans ce cas, tu crois tester sur une copie, alors que tu modifies les vraies données.

D’autres erreurs fréquentes :

• oublier de bloquer l’indexation ;
• laisser le staging accessible publiquement ;
• garder les vrais emails actifs ;
• envoyer des paiements tests sur les vrais moyens de paiement ;
• copier tout le staging vers la production sans comparer ;
• ne pas vider le cache ;
• tester uniquement la page d’accueil ;
• oublier les formulaires ;
• ne pas faire de sauvegarde avant la manipulation.

Le staging est un outil de prudence. Mal utilisé, il peut quand même faire des dégâts. Comme une ceinture de sécurité attachée au mauvais siège.

Faut-il garder le staging en permanence ?

Tout dépend du site.

Pour un site vitrine simple, le staging peut être créé quand un vrai besoin apparaît, puis supprimé ou archivé après validation.

Pour un site professionnel qui évolue souvent, il peut être utile de garder un staging permanent. Cela permet de tester les mises à jour, les nouvelles pages, les changements PHP et les réglages techniques sans toucher au site public.

Dans tous les cas, il faut penser à l’entretien du staging.

Un vieux staging oublié peut devenir :

• obsolète ;
• vulnérable ;
• indexable ;
• lourd pour l’hébergement ;
• source de confusion ;
• rempli de données anciennes.

Si tu gardes un staging, mets-le à jour, protège-le et identifie-le clairement. Sinon, supprime-le quand il ne sert plus.

Un staging oublié pendant deux ans, ce n’est plus un atelier. C’est un débarras numérique avec une porte ouverte.

En conclusion

Créer un site de staging WordPress est l’une des meilleures habitudes à prendre avant de toucher à un site important.

Tu peux le créer à la main, en copiant les fichiers, la base de données et les URLs vers un sous-domaine dédié. Tu peux aussi utiliser les outils de ton hébergement, notamment ceux de o2switch, quand l’installation WordPress est bien reconnue.

Dans les deux cas, le principe reste le même. Un site de staging doit être séparé, protégé, non indexé et testé avec sérieux.

Il ne sert pas seulement à éviter une panne. Il permet de travailler plus sereinement, de valider les changements et de publier uniquement quand tout est prêt.

Le site public reste tranquille. Toi aussi. Et franchement, c’est déjà une belle victoire.