Refondre un site WordPress, ce n'est pas seulement changer de thème. L'opération touche l'hébergement, la base de données, les extensions, les adresses des pages et, par ricochet, la visibilité acquise dans Google. Bien préparée, elle se déroule sans interruption ni perte de trafic. Mal préparée, elle produit des pages en erreur, des formulaires muets et des positions qui reculent.
Ce guide reprend la méthode que j'ai suivie lors de la refonte d'une boutique WooCommerce dont l'hébergement tournait encore sur une version PHP obsolète, ce qui a fait échouer la première tentative de migration. Il suit l'ordre réel des opérations : préparation, environnement de test, choix du thème et des extensions, migration, redirections, tests, mise en ligne et surveillance.
Pourquoi refondre, et à quel moment
WordPress reste le socle de la majorité des sites d'entreprise : selon W3Techs (relevé du 10 septembre 2026, ensemble des sites web analysés), il équipe 40,3 % de tous les sites et 58,8 % de ceux qui utilisent un CMS identifié. Côté TPE-PME françaises, le Baromètre France Num 2025 (DGE, enquête Crédoc auprès de 11 021 TPE-PME du 26 mars au 18 avril 2025, réponses déclaratives) indique que 65 % d'entre elles possèdent un site présentant leur activité. Les signaux qui justifient une refonte plutôt qu'une simple mise à jour sont assez constants :
- le thème n'est plus maintenu, ou dépend d'un constructeur de pages que vous ne voulez plus utiliser ;
- l'hébergement tourne sur une version de PHP sans correctifs de sécurité ;
- le site est mal utilisable sur mobile ou échoue aux seuils des Core Web Vitals ;
- l'arborescence ne correspond plus à ce que cherchent vos clients ;
- la moindre modification exige un développeur.
Un seul de ces points appelle une intervention ciblée ; trois ou quatre cumulés, la refonte coûte généralement moins cher que la somme des rustines. Pour arbitrer budget et périmètre, voyez la page refonte de site web : choix, budget, préparation.
Préparer la refonte : inventaire, sauvegarde, prérequis
Inventorier ce qui existe
On ne peut ni conserver ni rediriger ce qu'on n'a pas listé. Exportez la liste complète des URL (un crawler suffit pour quelques centaines de pages), les pages qui reçoivent des clics dans la Search Console, les pages d'entrée de votre outil de mesure d'audience et les pages qui reçoivent des liens externes. Ce tableau devient le plan de migration : une ligne par URL, une décision par ligne. Inventoriez aussi l'invisible : extensions actives, formulaires et destinataires des e-mails, scripts de mesure et de consentement, comptes tiers, redirections déjà en place.
Faire une sauvegarde complète et la tester
Une sauvegarde WordPress comprend les fichiers (dossier wp-content, wp-config.php) et la base de données. UpdraftPlus, Duplicator ou All-in-One WP Migration produisent les deux en une opération. Ce qui compte n'est pas l'outil mais le test : une sauvegarde jamais restaurée ailleurs n'est qu'une hypothèse. Le Baromètre France Num 2025 relève que 36 % des TPE-PME interrogées déclarent avoir déjà subi un incident de cybersécurité ; autant vérifier maintenant que la sauvegarde externe existe vraiment.
Vérifier la version de PHP
C'est le point qui a bloqué la boutique évoquée en introduction : l'extension de migration refusait de s'installer sur un hébergement resté en PHP 5. Le changement de version se fait en quelques clics dans l'espace client de l'hébergeur, mais se teste d'abord sur une copie du site, car une extension ancienne peut cesser de fonctionner.
Les prérequis officiels de WordPress recommandent PHP 8.3 ou supérieur et MariaDB 10.11 ou MySQL 8.0 ; WordPress fonctionne encore sur PHP 7.4, mais la page précise que ces versions ont atteint leur fin de vie et exposent le site à des failles. Les statistiques de WordPress.org (sites qui remontent leurs données, relevé du 10 septembre 2026) montrent que 17,0 % des sites WordPress tournent encore sur PHP 7.4 et 11,4 % sur PHP 8.1 ; toutes branches antérieures à 8.2 confondues, environ 38 % des sites utilisent une version de PHP sans correctifs.
| Branche PHP | Fin du support actif | Fin des correctifs de sécurité | Statut au 10 septembre 2026 |
|---|---|---|---|
| 8.1 et antérieures | Passée | Passée | Fin de vie |
| 8.2 | 31 décembre 2024 | 31 décembre 2026 | Sécurité uniquement |
| 8.3 | 31 décembre 2025 | 31 décembre 2027 | Sécurité uniquement |
| 8.4 | 31 décembre 2026 | 31 décembre 2028 | Support actif |
| 8.5 | 31 décembre 2027 | 31 décembre 2029 | Support actif |
Pour une refonte menée aujourd'hui, PHP 8.3 ou 8.4 est le choix raisonnable : compatible avec les extensions maintenues et couvert par des correctifs pendant au moins deux ans (calendrier officiel de PHP).
Travailler sur un site de préproduction
La refonte ne se fait jamais sur le site en ligne. Vous travaillez sur une copie, dite de préproduction (sous-domaine, domaine temporaire ou environnement local), importée depuis la sauvegarde testée. Deux précautions dès sa création : empêcher l'indexation (Réglages, Lecture, « Demander aux moteurs de recherche de ne pas indexer ce site », complété par un mot de passe côté serveur, car la case WordPress n'est qu'une demande adressée aux robots) et couper les e-mails automatiques ainsi que les connexions aux services de paiement ou de livraison, pour ne pas facturer un client depuis un site de test.
Choisir le thème et les extensions
Critères de choix du thème
Le thème détermine la vitesse, l'accessibilité et la maintenance pour plusieurs années. Les critères qui comptent :
- Maintenance : date de la dernière mise à jour, compatibilité déclarée avec la version actuelle de WordPress (7.1 au moment où j'écris) et avec PHP 8.3 ou 8.4.
- Performance : testez la démo du thème dans PageSpeed Insights avant d'acheter ; un thème lent en démo le restera avec vos contenus.
- Éditeur : blocs natifs de WordPress, ou thème classique avec constructeur de pages. Le premier limite la dépendance à un éditeur tiers ; le second reste pertinent si votre équipe le maîtrise déjà.
- Accessibilité et mobile : navigation au clavier, contrastes, affichage sans mise en page cassée.
Deux règles pratiques : un thème enfant si vous modifiez le code du thème, sinon vos modifications disparaîtront à la prochaine mise à jour ; et pas d'import du contenu de démonstration complet, qui installe des extensions et des médias inutiles.
Faire le tri dans les extensions
Chaque extension est une surface d'attaque et un facteur de lenteur potentiels. Le rapport State of WordPress Security in 2025 de Patchstack (données 2024, publié en mars 2025) recense 7 966 vulnérabilités découvertes dans l'écosystème WordPress sur l'année, dont 96 % dans des extensions et 4 % dans des thèmes, contre sept dans le cœur de WordPress ; 33 % n'avaient pas de correctif au moment de leur publication. Reprenez donc la liste extension par extension : doublons avec une fonction du thème, extensions sans mise à jour depuis plus d'un an, extensions dont personne ne connaît l'usage. Conservez les extensions structurantes (SEO, formulaires, cache, consentement, sauvegarde, WooCommerce) après avoir vérifié leur compatibilité avec le nouveau thème.
Migrer les contenus et préparer les redirections
Si l'arborescence change, chaque ancienne URL doit avoir un sort défini dans le tableau d'inventaire : conservée, redirigée vers la page qui la remplace, ou supprimée avec un code 410 quand aucun équivalent n'existe. Google recommande des redirections permanentes (301 ou 308) et de les conserver au moins un an ; il prévient aussi que des fluctuations de positions sont attendues pendant plusieurs semaines. Sur WordPress, les règles globales se posent dans le fichier .htaccess ou la configuration Nginx, les règles page par page dans une extension dédiée (Redirection, ou le module de Yoast SEO ou Rank Math).
J'ai détaillé cette partie, avec la règle à appliquer selon chaque cas (doublon, suppression, fusion, changement d'URL), dans l'article sur la refonte d'un site de tourisme sans perdre son référencement, et elle vaut pour tout secteur. Côté contenus, profitez de la migration pour reprendre titres, métadonnées, textes alternatifs et maillage interne, et contrôlez que les URL des médias n'ont pas changé.
Tester avant la mise en ligne
Les tests se font sur la préproduction, avec une liste écrite. Les points qui reviennent le plus souvent dans les incidents après refonte :
- chaque formulaire envoie un message, au bon destinataire, avec les bons champs ;
- sur une boutique : parcours de commande complet en mode test pour chaque moyen de paiement, e-mails, frais de port, stocks ;
- redirections vérifiées, idéalement en faisant relire le fichier d'inventaire par un crawler ;
- affichage sur un mobile réel, pas seulement dans le simulateur du navigateur ;
- vitesse : les seuils des Core Web Vitals définis par Google sont un LCP de 2,5 secondes au plus, un INP de 200 millisecondes au plus et un CLS de 0,1 au plus, mesurés au 75e centile des chargements ;
- scripts de mesure et bandeau de consentement fonctionnels, certificat HTTPS, plan de site XML régénéré, robots.txt sans directive héritée de la préproduction.
Si les performances ne passent pas, corrigez avant la mise en ligne : la page optimisation de la vitesse d'un site décrit ce qui relève de l'hébergement, du cache, des images et du thème.
Mettre en ligne et surveiller
Le jour du basculement, choisissez un créneau de faible trafic et refaites une sauvegarde de l'ancien site. Vous remplacez fichiers et base de données sur l'hébergement existant, ou vous faites pointer le domaine vers un nouvel hébergement (la propagation DNS peut prendre plusieurs heures). Ensuite, retirez immédiatement le blocage de l'indexation, vérifiez que les redirections répondent sur le domaine définitif et refaites un tour des formulaires et du tunnel de commande en conditions réelles.
La surveillance dure ensuite plusieurs semaines : rapport Pages de la Search Console pour les erreurs 404 et les pages exclues, rapport Performances pour les clics page par page, journal des erreurs PHP côté hébergeur, mesure d'audience pour comparer les pages d'entrée avant et après. Une baisse temporaire pendant que Google réexplore le site est normale ; une chute brutale sur des pages précises signale presque toujours une redirection manquante ou un noindex oublié.
Questions fréquentes
Combien de temps dure une refonte de site WordPress ?
Pour un site vitrine de quelques dizaines de pages, comptez généralement de quatre à huit semaines entre l'inventaire et la mise en ligne, tests compris. Une boutique WooCommerce ou un site de plusieurs centaines de pages demande davantage, surtout si l'arborescence et les URL changent. La durée dépend surtout de la disponibilité des contenus et des validations côté entreprise.
Faut-il changer d'hébergeur pour refondre un site WordPress ?
Pas nécessairement. Si l'hébergement actuel propose PHP 8.3 ou plus récent, une base MariaDB 10.11 ou MySQL 8.0, le HTTPS et un environnement de préproduction, il convient. Changer d'hébergeur se justifie quand ces prérequis manquent ou quand les temps de réponse du serveur restent élevés malgré le cache.
Une refonte fait-elle perdre le référencement ?
Une refonte bien préparée conserve l'essentiel des positions. Les pertes viennent presque toujours d'URL modifiées sans redirection, de pages supprimées qui recevaient du trafic ou d'un blocage de l'indexation oublié après la mise en ligne. Google indique lui-même que des fluctuations temporaires sont normales pendant qu'il réexplore le site.
Quelle version de PHP choisir pour un site WordPress refondu ?
WordPress recommande PHP 8.3 ou supérieur. PHP 8.3 reçoit des correctifs de sécurité jusqu'à fin 2027 et PHP 8.4 jusqu'à fin 2028, ce qui laisse une marge confortable. Testez la version choisie sur une copie du site avant de l'appliquer en production, car une extension ancienne peut ne pas être compatible.
Peut-on garder le même thème et refondre seulement le contenu ?
Oui, si le thème est encore maintenu, compatible avec la version actuelle de WordPress et de PHP, et suffisamment rapide. Dans ce cas, la refonte porte sur l'arborescence, les contenus, les extensions et l'hébergement, ce qui réduit le budget et les risques. Le changement de thème n'est utile que si l'existant bloque réellement.
Faut-il prévenir Google d'une refonte ?
Si le domaine ne change pas, aucune déclaration n'est nécessaire : les redirections et un plan de site XML à jour suffisent. L'outil de changement d'adresse de la Search Console ne sert que lorsque le site passe d'un nom de domaine à un autre. Dans tous les cas, surveillez les rapports Pages et Performances pendant les semaines qui suivent.