Quand tu crées un site WordPress avec WP STAGING, il arrive souvent un moment où tu veux migrer WordPress vers ton site de production.
Ce guide étape par étape couvre la méthode manuelle avec la version gratuite — chaque étape, dans l’ordre, sans rien laisser de côté.
Assure-toi d’être à l’aise techniquement et de savoir manipuler les bases de données et les fichiers. Même si ce tutoriel est facile à suivre, il est beaucoup plus simple de pousser le site de staging avec la version PRO, car elle propose la fonction « push changes » en un clic.
Donc, si tu veux copier automatiquement ton site WordPress de staging en un clic avec WP STAGING | PRO, lis plutôt cet article.TL;DR : Ce guide déroule la méthode manuelle avec le plugin gratuit WP STAGING. Il nécessite un accès FTP, un outil d’administration de base de données (phpMyAdmin ou Adminer) et la modification directe de wp-config.php. Si tu préfères une migration en un clic qui change automatiquement le préfixe de la base de données et laisse ton site de staging intact, utilise WP STAGING | PRO et son Push Wizard.
Quand utiliser ce guide
Avant de te lancer, vérifie quelle méthode correspond à ta situation :
| Manuelle avec la version gratuite (ce guide) | WP STAGING | PRO Push Wizard | |
|---|---|---|
| Effort | Élevé — transfert FTP, recherche et remplacement en base, édition de wp-config | Faible — un seul clic |
| Risque d’erreur humaine | Élevé — une étape oubliée peut casser le site | Faible — automatisé |
| Tailles de sites supportées | Toutes, mais les gros sites peuvent dépasser les délais lors des transferts FTP | Toutes |
| Changement de préfixe DB | Manuel — tu modifies wp-config.php toi-même | Automatique |
| Après la migration | Site de staging indisponible ; il faut en créer un nouveau | Site de staging conservé intact |
Si tu veux d’abord voir le Push Wizard Pro à l’œuvre, regarde la vidéo :
Lis les instructions ci-dessous attentivement, et ne saute aucune des étapes mentionnées, sinon ton site pourrait devenir indisponible !
Avant de commencer
Prérequis pour ce tutoriel :
- Un site en ligne en production, par exemple https://host.com
- Un site de staging créé au préalable avec WP STAGING ou WP STAGING | PRO dans un sous-dossier comme https://host.com/staging
- Plugin WP STAGING activé sur le site en production
- Plugin Search And Replace activé sur le site en production
(Pas nécessaire avec WP STAGING | PRO) - Un plugin de sauvegarde installé sur le site en production. WP STAGING intègre déjà l’une des solutions de sauvegarde les plus efficaces et modernes — plus rapide et avec moins de charge CPU que beaucoup d’autres plugins de sauvegarde.
Étape 1 – Sauvegarde les deux sites
Sauvegarde le site en production et le site de staging avant toute modification.
Dans la sélection de fichiers de ton plugin de sauvegarde, inclus le sous-dossier du site de staging. Sélectionne aussi toutes les tables de la base de données dont le préfixe commence par wpstg_.
Si tu as un très gros site avec des millions de lignes en base ou que tu veux éviter des pics de temps de chargement pendant la sauvegarde, regarde WP STAGING | PRO. Il inclut déjà l’une des solutions de sauvegarde les plus avancées.
Étape 2 – Copie les fichiers de staging vers la production
Utilise un programme FTP comme FileZilla pour te connecter à ton serveur. Copie les dossiers suivants depuis le sous-dossier de staging vers la racine de production :
wp-content/uploadswp-content/pluginswp-content/themes

Étape 3 – Migre la base de données
Tu as trois options pour migrer la base de staging vers la production :
- Option 1 — Très facile : Utilise WP STAGING | PRO et clone automatiquement tout le site de staging vers la production en un clic.
- Option 2 — Facile : Effectue une recherche et un remplacement manuels sur les tables de la base de staging, puis indique à WordPress d’utiliser ces tables pour la production. Les tables d’origine de la base du site en production ne sont pas écrasées et peuvent être restaurées à tout moment. Suis les étapes ci-dessous.
- Option 3 — Avancée : Utilise un plugin dédié de migration de base de données comme WP Migrate DB ou tout autre outil capable de migrer la base de staging vers la production.
Rechercher et remplacer les URLs de staging
Cette étape met à jour toutes les URLs internes dans la base de staging, en remplaçant le chemin du sous-dossier de staging par le domaine de production.
Si ce n’est pas déjà fait, installe le plugin Search And Replace. Va dans Outils > Search & Replace.

Supposons que ton site de staging se trouve à http://yoursite.com/staging.
Saisis le chemin du staging dans le champ Search for :
//mysite.com/staging
Saisis le chemin de production dans le champ Replace with :
//mysite.com
Veille à travailler précisément. Saisis les chaînes exactes !
– N’ajoute pas de slash final après l’URL !
– N’ajoute pas HTTP:// ou https:// à la chaîne de recherche
Toute faute de frappe entraînera un site de staging ou même un site en production cassé.
Sélectionne uniquement les tables de la base qui commencent par le préfixe de tables de staging — habituellement wpstg[0]_. Vérifie le bon préfixe dans la liste des sites de staging de WP STAGING :

Pour les anciennes versions de WP STAGING, trouve le préfixe en ouvrant le wp-config.php du site de staging via FTP :
path_to_wordpress/staging_name/wp-config.php
Toutes les autres tables appartiennent au site en production ou à d’autres sites de staging, qui ne doivent en aucun cas être modifiés !
Effectue d’abord un dry run pour vérifier les réglages sans modifier de vraies données. Si le dry run réussit, décoche l’option dry run et lance le remplacement pour de vrai.
Supprimer le flag wpstg_is_staging_site
WP STAGING enregistre une option wpstg_is_staging_site en base pour identifier les environnements de staging et afficher l’écran d’authentification. La laisser après la migration entraîne un tableau de bord d’administration vide.
Utilise un outil d’administration de base comme phpMyAdmin ou Adminer et cherche dans les tables de la base de staging la valeur :
wpstg_is_staging_site
Supprime la ligne ou mets sa valeur à false.

Mettre à jour le préfixe de tables dans wp-config.php
Cette dernière étape dit à WordPress d’utiliser les tables de la base de staging au lieu des tables d’origine de production.
Connecte-toi à ton site en production en FTP. Le fichier de configuration se trouve dans /path/to/wordpress/wp-config.php. Utilise FileZilla ou le client FTP que tu préfères.

Fais un clic droit sur le fichier et sélectionne Edit. Mets à jour $table_prefix pour qu’il corresponde au préfixe de tables de staging, par exemple :
$table_prefix = 'wpstg1_';

Enregistre le fichier. Ouvre le site en production — il affiche maintenant le contenu du site de staging.
Pour réactiver les permaliens jolis, va dans Réglages > Permaliens dans l’administration WordPress et clique sur Enregistrer les modifications.

Supprime l’ancien sous-dossier de staging via FTP :
path/to/wordpress/staging-name
Important : Le site en production utilise désormais les tables de la base de staging. Crée un nouveau site de staging quand tu en auras besoin — l’ancien ne peut plus être utilisé.
D’expérience, en aidant les utilisateurs de WP STAGING, le changement de préfixe de la base de données dans wp-config.php est l’étape la plus souvent oubliée. Vérifie-la deux fois avant de fermer ton client FTP.
Félicitations — tu as migré avec succès ton site de staging vers la production.
La version pro couvre nos frais de développement et inclut un support de premier ordre !😊
Résoudre les problèmes courants
D’après les demandes de support reçues, trois types de pannes représentent la majorité des problèmes après une migration.
Le préfixe de la base de staging n’a pas été mis à jour dans wp-config.php
Après la migration, wp-config.php doit référencer le préfixe de tables de staging (par exemple wpstg1_), pas le wp_ d’origine. Si $table_prefix pointe toujours sur wp_, WordPress charge la base de production d’origine au lieu des données de staging migrées, et la migration semble n’avoir eu aucun effet.
Solution : Rouvre wp-config.php via FTP et vérifie que $table_prefix correspond au préfixe que tu as sélectionné à l’étape de recherche et remplacement.
wpstg_is_staging_site non supprimé — tableau de bord vide
Si la ligne wpstg_is_staging_site n’a pas été supprimée, WordPress détecte le site comme un environnement de staging et affiche un écran d’authentification vide au lieu du tableau de bord d’administration.
Solution : Ouvre phpMyAdmin ou Adminer, cherche dans la table des options avec le préfixe de staging (par exemple wpstg1_options) la valeur wpstg_is_staging_site et supprime la ligne.
siteurl et home non mis à jour — boucles de redirection ou mauvais domaine
Si les valeurs siteurl et home dans la table des options pointent encore vers le sous-dossier de staging après l’étape de recherche et remplacement, WordPress redirige toutes les requêtes vers l’URL de staging.
Solution : Dans phpMyAdmin ou Adminer, ouvre la table wpstg1_options (avec ton vrai préfixe), trouve les lignes siteurl et home, et vérifie que les deux valeurs pointent vers le domaine de production (par ex. https://yoursite.com), sans slash final et sans chemin de sous-dossier.