Refonte d’un site WordPress => Tutoriel Complet

Comment faire la refonte d’un site WordPress ? C’est la question que je reçois le plus souvent en formation — et la réponse a beaucoup changé depuis 2022. Les outils se sont affinés, les méthodes pro ont évolué, et certaines solutions que je recommandais avant ont tout simplement été abandonnées par leurs créateurs.

Ce tutoriel couvre les trois approches principales : travailler en local sur votre machine, utiliser l’environnement de staging de votre hébergeur, ou passer par un plugin dédié. Avec pour chaque méthode, les pièges à éviter et la façon dont j’aurais fait moi-même.

Préambule obligatoire avant toute refonte

Sauvegardez. D’abord. Avant tout. Fichiers + base de données, les deux ensemble. Pas juste un export XML WordPress, ça ne sert à rien dans ce contexte. Une vraie sauvegarde complète.

Ensuite, posez-vous la question du temps disponible. Une refonte sérieuse prend plusieurs jours minimum pour un site moyen. Si vous avez une semaine et 15 plugins à tester, prévoyez large. J’ai vu des refontes "rapides" qui trainent depuis 6 mois.

Choisissez une seule méthode parmi celles qui suivent, celle qui correspond à votre niveau et votre situation. Pas besoin de les combiner.

1. Refonte d’un site WordPress en local

Travailler "en local" signifie installer un serveur WordPress directement sur votre ordinateur, sans connexion internet requise. Le logiciel simule un hébergement complet : serveur PHP, base de données MySQL, tout le toutim. Votre site tourne sur localhost au lieu d’un vrai serveur.

C’est la méthode la plus indépendante : pas besoin de payer un hébergeur supplémentaire, pas de limite de bande passante, vous pouvez travailler dans le train. En contrepartie, elle demande le plus de manipulation technique, notamment au moment de remettre le site en ligne.

Quels logiciels choisir en 2025 ?

MAMP et XAMPP restent fonctionnels, mais franchement, ils ont vieilli. Depuis 2022, de nouveaux outils ont émergé qui sont spécifiquement conçus pour WordPress. Ce sont ceux que je recommande maintenant en formation.

Local by Flywheel (maintenant simplement "Local") — C’est mon premier choix. L’interface est propre, l’installation d’un site WordPress prend 2 minutes, et le déploiement vers un hébergeur est intégré pour certains hébergeurs. Gratuit pour un usage local. Disponible sur Mac, Windows et Linux.

Studio by WordPress.com — Sorti en 2024, c’est le concurrent direct de Local. Fait par Automattic, donc parfaitement intégré à l’écosystème WordPress. Interface encore plus simple. Gratuit, disponible Mac et Windows. Bonne alternative si Local vous pose des problèmes.

DevKinsta — L’outil de Kinsta, disponible gratuitement même sans hébergement chez eux. Bonne option si vous aimez les interfaces propres. Moins de fonctionnalités que Local mais très stable.

MAMP et XAMPP restent des alternatives valables si vous les connaissez déjà ou si vous gérez plusieurs types de projets (pas uniquement WordPress). Mais pour une refonte WordPress, commencez par Local.

En revanche, évitez Desktop Server (abandonné depuis 2020) et Instant WP (plus maintenu). Ces deux outils sont morts. Ne perdez pas de temps avec eux.

Étapes d’une refonte en local — vue d’ensemble

• Sauvegarder fichiers + base de données du site en ligne
• Installer Local (ou Studio) sur votre ordinateur
• Créer un nouveau site WordPress dans Local
• Importer votre site existant (fichiers via FTP + BDD via plugin de migration)
• Effectuer toutes les modifications souhaitées sur le site local
• Remettre en ligne avec réécriture d’URLs

Pour le guide complet d’installation, lisez : Comment installer WordPress.

Le point critique : la réécriture des URLs

C’est l’étape qui fait peur, et à juste titre. Quand vous travaillez en local, vos URLs ressemblent à http://mon-site.local/ma-page/. Quand vous remettez en ligne, elles doivent devenir https://mon-site.com/ma-page/.

Le problème : WordPress stocke l’URL du site dans la base de données à des dizaines d’endroits différents. Pas juste dans les réglages. Dans les contenus, les métadonnées, les options de thème, les configurations de plugins… Si vous remplacez à la main, vous ratez forcément des occurrences.

Trois options pour gérer ça :

• Utiliser un plugin de duplication qui gère la réécriture automatiquement
• Utiliser le plugin Better Search Replace après migration
• Utiliser WP-CLI — la méthode pro, rapide et fiable (détaillée plus bas)

Créer une copie locale de votre site

Deux parties à récupérer : les fichiers du dossier WordPress (thèmes, plugins, uploads) et la base de données. Les deux ensemble. L’un sans l’autre ne sert à rien.

Via un plugin de migration — Duplicator ou All-in-One WP Migration sont les plus connus. Les versions gratuites limitent la taille à 500-520 Mo environ. Si votre site est léger, ça passe. Sinon, il faudra soit payer, soit faire autrement.

La méthode mixte que je préfère : téléchargez les fichiers manuellement via FTP (lent mais sans limite de taille), et utilisez le plugin uniquement pour exporter/importer la base de données. Résultat : réécriture d’URLs automatique pour la BDD, et vous gérez les fichiers vous-même.

• Télécharger tout le contenu du dossier WordPress depuis le FTP en ligne
• Uploader le contenu dans votre environnement local
• Exporter la BDD du site en ligne avec le plugin de migration
• Importer la BDD sur l’environnement local
• Vérifier que les identifiants BDD dans wp-config.php correspondent

La fonction export native de WordPress (Outils > Exporter) ? Ne l’utilisez pas pour une refonte. Elle exporte uniquement le contenu (articles, pages, commentaires), pas les thèmes, pas les plugins, pas la configuration. C’est utile pour transférer des articles d’un site à l’autre, pas pour une refonte complète.

Remettre le site local en ligne

La refonte est terminée en local. Il faut maintenant inverser le processus : envoyer les fichiers modifiés vers votre hébergeur et remplacer la base de données.

Si votre site pèse moins de 500 Mo, un plugin de migration fait tout. Sinon, même méthode mixte qu’à l’aller :

• Mettre votre site en maintenance (un plugin ou un fichier .htaccess)
• Remplacer les fichiers WordPress sur le FTP en ligne par les nouveaux
• Exporter la BDD locale avec le plugin de migration
• Importer la nouvelle BDD sur le serveur en ligne
• Vérifier wp-config.php (identifiants BDD)
• Aller dans Réglages > Permaliens et cliquer "Enregistrer" (sans rien changer) pour vider le cache des règles de réécriture
• Vérifier les URLs, notamment celles des images

Pour un guide complet de cette étape : Comment migrer WordPress local vers un hébergeur.

Méthode pro : WP-CLI pour remplacer les URLs

Si vous avez accès à SSH sur votre hébergeur (c’est le cas sur la majorité des hébergements sérieux), WP-CLI est de loin la méthode la plus rapide et la plus fiable pour remplacer les URLs après une migration.

Une seule commande fait ce que Better Search Replace fait en 5 clics, en gérant les données sérialisées correctement (ce qu’un simple search/replace SQL rate à tous les coups) :

wp search-replace 'http://mon-site.local' 'https://mon-site.com' --all-tables

Cette commande parcourt toutes les tables de votre base de données et remplace chaque occurrence de l’ancienne URL par la nouvelle. Le flag --all-tables inclut les tables de plugins qui ne seraient pas couvertes par défaut.

Quelques variantes utiles :

# Simuler sans modifier (dry-run) — faites toujours ça en premier
wp search-replace 'http://mon-site.local' 'https://mon-site.com' --all-tables --dry-run

# Remplacer aussi les URLs avec www
wp search-replace 'http://www.ancien-domaine.com' 'https://nouveau-domaine.com' --all-tables

# Préciser les tables si besoin
wp search-replace 'http://mon-site.local' 'https://mon-site.com' wp_posts wp_postmeta wp_options

Après le remplacement, videz le cache (LiteSpeed, WP Rocket, ou autre) et rechargez le site. C’est fait. Ça prend 30 secondes contre 10 minutes avec une interface graphique.

Si votre hébergeur ne propose pas SSH, Better Search Replace reste l’alternative correcte. L’approche directe SQL (UPDATE dans phpMyAdmin) est déconseillée car elle casse les données sérialisées.

2. Refonte via le staging de votre hébergeur

C’est la méthode que je recommande en priorité à 90% des gens. Pourquoi ? Parce qu’elle évite la quasi-totalité des problèmes de migration. Pas de transfert de fichiers, pas de réécriture d’URLs manuelle. Votre site reste en ligne pendant toute la refonte. Et quand vous êtes prêts, un bouton "pousser en production" fait le reste.

La plupart des hébergeurs WordPress sérieux proposent cette fonctionnalité aujourd’hui. Vérifiez dans votre interface d’administration (cPanel, Plesk, ou l’interface propriétaire de votre hébergeur). Les termes utilisés varient : "staging", "environnement de test", "clone", "site de développement".

Comment savoir si votre hébergeur propose le staging

Cherchez dans votre interface ces gestionnaires d’applications :

• Softaculous — Le plus répandu sur les hébergements mutualisés cPanel
• WP Toolkit — Présent sur Plesk, propose le staging de façon native
• Installatron — Alternative à Softaculous avec fonctionnalité de clonage

Votre hébergeur peut aussi proposer le staging directement dans son interface personnalisée, sans passer par ces gestionnaires. Si vous ne trouvez pas, contactez leur support et demandez explicitement : "Puis-je créer un site de staging pour mon WordPress ?"

Si votre hébergeur actuel ne propose pas cette fonctionnalité et que vous êtes bloqué là-dessus, consultez ce guide pour faire le bon choix : Choisir son hébergement WordPress.

Exemple : créer un site de staging avec Softaculous

Softaculous est présent sur une grande partie des hébergements mutualisés. Voici comment créer un site de staging avec cet outil.

Connectez-vous à votre cPanel et ouvrez Softaculous. Cliquez sur l’icône WordPress, puis sur "Balayage" pour détecter votre installation.

Une fois votre site détecté, ouvrez sa fiche et cliquez sur "Staging".

Choisissez l’emplacement du site de staging. Deux options : un sous-dossier de votre domaine actuel (mondomaine.com/staging/) ou un sous-domaine dédié (staging.mondomaine.com). Je préfère le sous-domaine, c’est plus propre et plus facile à partager avec un client pour validation.

Pensez à cocher la case pour désactiver l’indexation dans les moteurs de recherche sur le site de staging. C’est primordial : vous ne voulez pas que Google indexe votre site en cours de modification.

Cliquez sur le bouton de création. Softaculous va cloner votre site complet — fichiers + base de données — dans le nouvel emplacement. Selon la taille du site, ça prend 1 à 5 minutes. Vous pouvez ensuite vous connecter à ce site de staging avec vos identifiants WordPress habituels et travailler dessus tranquillement.

Pousser le staging en production

Refonte terminée. Retournez dans Softaculous, ouvrez la fiche du site de staging, cliquez sur "Envoyer en production".

Cliquez sur "Push to Live" et c’est terminé. Softaculous remplace le site en ligne par le contenu du staging, réécriture des URLs incluse. Supprimez ensuite le site de staging si vous n’en avez plus besoin — il prend de la place sur votre serveur.

3. Refonte avec un plugin de staging

Votre hébergeur ne propose pas le staging. Ça arrive, notamment sur les offres mutualisées bas de gamme. Dans ce cas, un plugin peut vous dépanner — mais il faudra passer à une version payante pour avoir les fonctionnalités qui comptent vraiment.

WP Staging : le plus complet

WP Staging est le plugin de référence pour créer un environnement de développement directement depuis WordPress. La version gratuite crée bien un clone, mais elle a deux limitations rédhibitoires pour une vraie refonte :

Premièrement, pas de "push to live". Vous ne pouvez pas envoyer le site cloné en production en un clic. Vous devrez faire la migration à la main.

Deuxièmement, le clone est créé dans votre base de données actuelle (pas une BDD séparée). Votre base de données double de taille. Sur un hébergement avec des limites strictes, ça peut créer des problèmes. Et supprimer le clone demande de nettoyer à la fois les fichiers FTP et les tables en base de données manuellement.

La version Pro résout ces deux problèmes. Elle crée le staging dans une base de données séparée, gère la réécriture des URLs automatiquement, et le bouton "push to live" est disponible.

Tarifs WP Staging — Le plugin est vendu en licence annuelle avec renouvellement. Les prix évoluent régulièrement, comptez à partir de 8-10 $/mois selon le plan choisi. Vérifiez les tarifs actuels directement sur wp-staging.com.

WP Staging	Gratuit	Pro
Cloner un site WordPress	Oui	Oui
Cloner vers une base de données séparée	Non	Oui
Cloner vers un sous-domaine ou domaine personnalisé	Non	Oui
Pousser le staging en production en un clic	Non	Oui
Sauvegarde et restauration	Non	Oui
Migration vers un autre serveur ou domaine	Non	Oui
WordPress multisite	Non	Oui

Mon avis : si vous avez le budget, la version Pro de WP Staging vaut le coup pour quelqu’un qui fait des refontes régulièrement. Pour une refonte ponctuelle sur votre propre site, commencez par vérifier si votre hébergeur propose le staging — vous éviterez de payer un plugin.

Checklist post-refonte

La refonte est en ligne. C’est maintenant que beaucoup de gens font une erreur : ils passent à autre chose sans vérifier que tout s’est bien passé. Voici les points à valider systématiquement.

Vérifications techniques immédiates

• URLs — Naviguez sur 10-15 pages, vérifiez que toutes les URLs fonctionnent. Testez particulièrement les images (les URLs d’upload sont les premières à poser problème)
• Permaliens — Allez dans Réglages > Permaliens et cliquez "Enregistrer" sans rien modifier. Ça vide le cache des règles de réécriture Apache/Nginx
• Formulaires — Testez chaque formulaire de contact : remplissez et soumettez pour vérifier que les emails arrivent bien
• Cache — Videz le cache de votre plugin (LiteSpeed, WP Rocket, W3 Total Cache…) et le cache CDN si vous en utilisez un
• SSL — Vérifiez que toutes les pages chargent bien en HTTPS sans avertissement de contenu mixte (HTTP/HTTPS mélangés)

SEO et redirections

• Redirections 301 — Si des URLs ont changé pendant la refonte (changement de thème, de structure), mettez en place les redirections 301. Sans ça, vous perdez le jus SEO accumulé. Utilisez Redirection (plugin gratuit) ou les règles .htaccess
• Sitemap XML — Vérifiez que votre sitemap est à jour (Yoast, Rank Math ou autre). Soumettez-le dans Google Search Console
• Balises meta — Vérifiez que le titre et la description de vos pages principales sont intacts. Un changement de thème peut parfois écraser les réglages SEO
• Robots.txt — Vérifiez que le site n’est pas en mode "décourager les moteurs de recherche" (Réglages > Lecture). C’est une case cochée par défaut sur les nouvelles installations ou les clones

Performance et monitoring

• PageSpeed — Testez votre page d’accueil et une page article sur PageSpeed Insights. Un nouveau thème peut avoir un impact significatif sur les Core Web Vitals
• Search Console — Allez dans Google Search Console et surveillez les erreurs 404 dans les prochains jours. Si des URLs ont changé et que vous avez oublié des redirections, elles apparaîtront là
• Couverture d’index — Dans Search Console, vérifiez que vos pages importantes sont bien indexées et que le nombre de pages indexées reste stable

Pour approfondir la migration d’URLs : Déplacer WordPress vers un nouveau nom de domaine.

Conclusion

Pour résumer mon point de vue après des années à accompagner des refontes en formation :

Hébergeur avec staging natif — C’est de loin la meilleure situation. Utilisez-le. Softaculous, WP Toolkit, peu importe. En 3 clics vous avez un environnement de développement, en 1 clic vous remettez en production. Ni transfert de fichiers, ni réécriture d’URLs à gérer manuellement.

Pas de staging chez votre hébergeur — Deux options honnêtes. Local by Flywheel pour travailler offline (méthode la plus indépendante), ou WP Staging Pro si vous préférez tout gérer depuis WordPress. Les deux fonctionnent. Aucune n’est gratuite sans compromis.

La réécriture d’URLs — Quelle que soit la méthode, si vous la faites manuellement, utilisez WP-CLI wp search-replace. C’est 30 secondes de travail pour un résultat propre, sans risque de données sérialisées cassées.

Et quoi qu’il arrive, faites la checklist post-refonte. C’est là que la plupart des problèmes SEO post-refonte auraient pu être évités.

Pour aller plus loin dans la gestion de votre WordPress : Formation WordPress complète.

Questions fréquentes sur la refonte d’un site WordPress

Quelle est la différence entre un site de staging et un site en local ?

Un site en local tourne uniquement sur votre ordinateur : personne d’autre ne peut y accéder, et vous n’avez pas besoin d’internet pour travailler. Un site de staging est hébergé sur votre serveur, accessible via une URL (comme staging.mondomaine.com). L’avantage du staging : vous pouvez le partager avec un client pour validation, et la remise en production est automatisée par l’hébergeur.

Combien de temps prend une refonte WordPress ?

Ça dépend de l’ampleur des modifications. Un changement de thème sur un site de 20 pages prend 2 à 3 jours pour quelqu’un qui maîtrise WordPress. Une refonte complète (thème, structure, contenu, SEO) peut prendre plusieurs semaines. Prévoyez toujours 30 à 50% de plus que votre estimation initiale — les imprévus sont la règle, pas l’exception.

Mon site doit-il être en maintenance pendant la refonte ?

Non, c’est précisément l’intérêt d’utiliser un environnement de staging ou un site local. Votre site en ligne reste intact et accessible à vos visiteurs pendant toute la durée de la refonte. Le mode maintenance n’est nécessaire que pendant les quelques minutes de la bascule finale (staging vers production), et encore, ce n’est pas toujours requis.

Que faire si des URLs ont changé après la refonte ?

Mettez en place des redirections 301 pour chaque ancienne URL qui a changé. Une redirection 301 indique à Google que la page a définitivement déménagé à une nouvelle adresse, ce qui transfère la valeur SEO. Sans ces redirections, les visiteurs qui cliquent depuis Google ou depuis d’autres sites obtiennent une erreur 404, et vous perdez le référencement accumulé. Le plugin Redirection (gratuit) gère ça simplement.

Comment vérifier que toutes les URLs ont été correctement remplacées ?

Après avoir utilisé WP-CLI wp search-replace ou Better Search Replace, cherchez des occurrences de l’ancienne URL dans votre contenu. Vous pouvez faire une requête SQL : SELECT * FROM wp_posts WHERE post_content LIKE '%ancienne-url%'. Vérifiez aussi les options : SELECT * FROM wp_options WHERE option_value LIKE '%ancienne-url%'. Si vous trouvez des résultats, relancez le search-replace sur ces tables spécifiques.

WP-CLI est-il disponible sur mon hébergement ?

La plupart des hébergements WordPress sérieux proposent l’accès SSH et WP-CLI préinstallé. Pour vérifier, connectez-vous en SSH et tapez wp --version. Si la commande n’est pas reconnue, WP-CLI n’est pas installé mais peut être ajouté manuellement (c’est un fichier PHP à télécharger). Sur les hébergements mutualisés bas de gamme sans SSH, vous devrez passer par une interface graphique comme Better Search Replace.

Dois-je prévenir Google Search Console après une refonte ?

Pas d’action spéciale requise si votre domaine ne change pas. En revanche, soumettez votre sitemap XML mis à jour dans Search Console (Sitemaps > Soumettre un sitemap) pour que Google recrawle rapidement vos pages. Si des URLs ont changé avec des redirections 301, Google va naturellement mettre à jour son index dans les semaines qui suivent. Surveillez le rapport "Couverture" dans Search Console pour détecter des erreurs 404 résiduelles.

Local by Flywheel est-il vraiment gratuit ?

Oui, Local est gratuit pour un usage en développement local. Il propose aussi une version payante "Local Pro" avec des fonctionnalités supplémentaires (collaboration, partage de liens temporaires, déploiement automatisé), mais pour une refonte WordPress classique, la version gratuite fait largement le travail.