Maintenance WordPress après migration ou refonte : les 30 jours à surveiller

La maintenance WordPress après migration ou après refonte est une étape souvent sous-estimée. Une fois le nouveau site en ligne, on peut avoir l’impression que le projet est terminé. Pourtant, les 30 premiers jours sont souvent les plus sensibles.

C’est pendant cette période qu’il faut vérifier si les redirections fonctionnent, si les formulaires envoient bien les messages, si Google peut explorer les nouvelles pages, si les courriels transactionnels partent correctement, si les performances restent stables et si les journaux d’erreurs ne révèlent pas de problème invisible.

Une migration ou une refonte ne se limite pas au moment de la mise en ligne. Il y a toujours une phase de stabilisation. L’objectif de cet article n’est pas d’expliquer comment faire une migration WordPress, mais plutôt quoi surveiller après la mise en ligne pour éviter que de petits problèmes deviennent coûteux.

Pourquoi les 30 jours après une migration ou une refonte sont critiques

Après une migration ou une refonte WordPress, plusieurs éléments peuvent changer en même temps : structure des URL, thème, hébergement, extensions, formulaires, menus, contenus, balises SEO, performances, suivi Analytics, configuration courriel ou tunnel d’achat.

Même si le site semble fonctionner au moment de la livraison, certains problèmes n’apparaissent qu’après quelques jours :

• une ancienne URL n’est pas redirigée ;
• un formulaire n’envoie plus les messages ;
• Google découvre des pages en erreur ;
• une page importante n’est plus indexable ;
• un courriel transactionnel ne part pas ;
• un script Analytics est absent ;
• une page stratégique est plus lente qu’avant ;
• une erreur PHP revient dans les logs ;
• une extension réagit mal au nouvel environnement.

Google recommande, lors d’un déplacement de site avec changement d’URL, de préparer les nouvelles URL, de configurer des redirections et de surveiller les deux sites dans Search Console après le lancement. Cette logique confirme l’importance d’un suivi post-mise en ligne, surtout lorsque les URL changent.  

Les 30 premiers jours servent donc à valider que le site n’est pas seulement “en ligne”, mais qu’il fonctionne réellement pour les visiteurs, les moteurs de recherche et l’entreprise.

Maintenance après migration ou refonte : ce que cet article couvre

Cet article se concentre sur la période post-lancement.

Il couvre :

• les redirections ;
• les formulaires ;
• l’indexation ;
• Search Console ;
• les performances ;
• les logs ;
• les courriels ;
• les sauvegardes ;
• les conversions ;
• WooCommerce, si applicable ;
• les points à surveiller semaine par semaine.

Il ne remplace pas un service de migration WordPress complet. La migration est un projet à part, avec sa préparation, ses sauvegardes, ses transferts, ses tests et sa mise en ligne. Ici, on parle de la maintenance qui suit ce projet.

Si le site vient d’être livré ou migré, cette période doit être traitée comme une phase de surveillance active.

Jour 0 à jour 2 : vérifier que le site fonctionne vraiment

Les premières 48 heures après une migration ou une refonte doivent être consacrées aux contrôles essentiels.

L’objectif est de repérer rapidement les problèmes visibles ou bloquants.

Vérifier les pages principales

Il faut tester les pages les plus importantes :

• page d’accueil ;
• pages de services ;
• page contact ;
• pages de conversion ;
• articles qui génèrent du trafic ;
• pages locales importantes ;
• pages légales ;
• pages WooCommerce, si applicable ;
• pages de connexion ou espace membre, si applicable.

Il ne suffit pas d’ouvrir la page d’accueil. Certaines erreurs ne touchent que certains modèles de pages ou certaines fonctionnalités.

À vérifier :

• affichage desktop ;
• affichage mobile ;
• menus ;
• boutons ;
• images ;
• vidéos ;
• liens internes ;
• appels à l’action ;
• sections dynamiques ;
• pied de page ;
• traduction, si site multilingue.

Cette vérification permet de confirmer que la mise en ligne n’a pas cassé une partie importante du site.

Tester les formulaires

Les formulaires doivent être testés immédiatement après la mise en ligne.

À tester :

• formulaire de contact ;
• demande de soumission ;
• demande de rendez-vous ;
• inscription à une infolettre ;
• formulaire de téléchargement ;
• formulaire de candidature ;
• formulaire de réservation ;
• formulaire WooCommerce, si applicable.

Le test doit aller jusqu’à la réception du courriel.

Il faut vérifier :

• message de confirmation ;
• réception du courriel ;
• adresse destinataire ;
• objet du message ;
• champs transmis ;
• intégration CRM ;
• inscription infolettre ;
• stockage de l’entrée dans WordPress, si activé.

Un formulaire qui affiche “message envoyé” peut quand même ne pas livrer le courriel correctement. C’est pourquoi le test réel est indispensable.

Vérifier les courriels du site

Après une migration ou une refonte, la configuration courriel peut changer. Le SMTP, les DNS, les expéditeurs et les notifications doivent être vérifiés.

À surveiller :

• courriels de formulaires ;
• notifications administrateur ;
• réinitialisation de mot de passe ;
• création de compte ;
• courriels WooCommerce ;
• courriels de réservation ;
• courriels d’inscription ;
• alertes de sécurité ou maintenance.

Si le site utilise un service SMTP, il faut confirmer qu’il est toujours connecté et qu’aucune erreur d’envoi n’apparaît.

Semaine 1 : surveiller les redirections et les erreurs 404

La première semaine doit accorder une attention particulière aux URL.

Après une refonte, certaines pages changent souvent de slug, de structure ou d’emplacement. Après une migration, les URL peuvent aussi changer si le domaine, le protocole ou l’arborescence a été modifié.

Vérifier les redirections 301

Les anciennes URL importantes doivent rediriger vers les nouvelles pages correspondantes.

À vérifier :

• anciennes pages de services ;
• articles générateurs de trafic ;
• pages avec backlinks ;
• anciennes landing pages ;
• anciennes pages locales ;
• anciennes catégories ;
• pages indexées dans Google ;
• URLs partagées dans des campagnes ;
• URLs présentes dans des annuaires ou médias.

Google explique que les redirections peuvent indiquer à Google Search quelle URL doit être considérée comme canonique, et que le choix du type de redirection dépend notamment de la durée prévue du changement. Pour une migration ou une refonte durable, les redirections permanentes sont généralement centrales.  

Un bon suivi post-migration consiste donc à tester les redirections, mais aussi à corriger rapidement les oublis.

Surveiller les erreurs 404

Les erreurs 404 ne sont pas toujours graves. Mais après une refonte ou une migration, un volume inhabituel de 404 peut indiquer un problème de redirection.

À surveiller :

• anciennes URL sans redirection ;
• images manquantes ;
• fichiers supprimés ;
• liens internes cassés ;
• URLs indexées qui n’existent plus ;
• URLs venant de backlinks externes ;
• erreurs dans Search Console.

Une erreur 404 sur une page sans importance n’a pas le même impact qu’une erreur 404 sur une page qui recevait du trafic ou des liens.

Il faut donc prioriser les pages selon leur valeur.

Vérifier les liens internes

Une refonte peut casser des liens internes, surtout si les slugs ont changé.

À vérifier :

• menus ;
• boutons ;
• liens dans les pages services ;
• liens dans les articles ;
• liens de footer ;
• liens vers les formulaires ;
• liens vers les pages de conversion ;
• liens dans les blocs réutilisables ;
• liens traduits, si site multilingue.

Les liens internes doivent pointer directement vers les bonnes pages, pas passer inutilement par des redirections.

Semaine 1 : surveiller Search Console et l’indexation

Après une migration ou une refonte, Search Console devient un outil important de suivi.

Il faut vérifier :

• couverture/indexation ;
• pages exclues ;
• erreurs 404 ;
• redirections ;
• pages explorées mais non indexées ;
• sitemap soumis ;
• baisse inhabituelle d’impressions ;
• erreurs mobiles ;
• problèmes de balises canoniques ;
• pages importantes toujours indexables.

Si le site change de domaine, l’outil de changement d’adresse de Google Search Console peut être utilisé dans certains cas. Google précise que cet outil sert à informer Google d’un déplacement de site d’un domaine ou sous-domaine vers un autre, mais il ne remplace pas les redirections : les redirections doivent être en place.  

Pour une simple refonte sans changement de domaine, l’enjeu est surtout de surveiller les URL, le sitemap, les pages indexables et les erreurs.

Vérifier le sitemap XML

Après la mise en ligne, le sitemap doit être vérifié.

À contrôler :

• sitemap accessible ;
• sitemap soumis dans Search Console ;
• URLs importantes présentes ;
• anciennes URLs absentes ;
• pages noindex exclues ;
• pages inutiles non incluses ;
• cohérence avec la nouvelle structure.

Un sitemap qui contient encore des anciennes URL peut ralentir la compréhension du nouveau site par les moteurs.

Vérifier les balises noindex

Une erreur fréquente après migration ou refonte est de laisser certaines pages en noindex, surtout si le site a été travaillé en staging.

À vérifier :

• page d’accueil indexable ;
• pages de services indexables ;
• articles importants indexables ;
• catégories importantes indexables ;
• absence de blocage global ;
• réglages SEO ;
• fichier robots.txt ;
• balises canoniques.

Cette vérification est essentielle dans les premiers jours.

Semaine 2 : surveiller les performances sans en faire un audit complet

Après une refonte ou une migration, les performances peuvent changer.

Un nouveau thème, de nouvelles images, un constructeur de page, un hébergement différent ou une configuration cache différente peuvent affecter l’expérience utilisateur.

À surveiller :

• vitesse perçue ;
• pages lentes ;
• poids des images ;
• cache actif ;
• cache serveur ;
• pages mobiles ;
• scripts tiers ;
• erreurs liées au cache ;
• pages stratégiques ;
• tunnel WooCommerce, si applicable.

L’objectif n’est pas de transformer cette maintenance en audit complet de performance. Il s’agit de repérer les régressions évidentes après mise en ligne.

Par exemple :

• une page service devient nettement plus lente ;
• une image hero est trop lourde ;
• le cache n’est pas actif ;
• le mobile charge mal ;
• le checkout WooCommerce ralentit ;
• un script de tracking bloque l’affichage.

Si les problèmes sont importants, une intervention d’optimisation WordPress peut ensuite être planifiée séparément.

Semaine 2 : surveiller les logs et les erreurs invisibles

Un site peut sembler fonctionner, mais générer des erreurs en arrière-plan.

Après une migration ou une refonte, il faut regarder les logs.

À surveiller :

• erreurs PHP ;
• erreurs serveur ;
• erreurs liées aux extensions ;
• erreurs liées au thème ;
• erreurs WooCommerce ;
• erreurs SMTP ;
• erreurs de tâches planifiées ;
• erreurs 500 ;
• erreurs récurrentes après changement d’environnement.

Les logs permettent de repérer des problèmes que le visiteur ne voit pas toujours. Un warning isolé n’a pas forcément la même importance qu’une erreur critique répétée.

Le but est de distinguer :

• ce qui est mineur ;
• ce qui doit être surveillé ;
• ce qui doit être corrigé rapidement ;
• ce qui nécessite du débogage.

Si les erreurs sont nombreuses, récurrentes ou bloquantes, il faut passer par une intervention de débogage WordPress plutôt que de corriger au hasard.

Semaine 2 : vérifier les tâches planifiées et cron

Après une migration, certaines tâches planifiées peuvent ne plus fonctionner correctement.

À vérifier :

• sauvegardes programmées ;
• envois automatiques ;
• publications programmées ;
• synchronisations ;
• tâches WooCommerce ;
• actions planifiées ;
• tâches liées aux extensions ;
• traitements de formulaires ;
• automatisations marketing.

WordPress utilise des événements planifiés pour certaines actions internes et extensions. Des événements qui ne s’exécutent pas correctement peuvent indiquer un problème avec WP-Cron ou des événements orphelins.  

Ce point est particulièrement important si le site a changé d’hébergement, car le comportement des tâches planifiées peut dépendre de l’environnement serveur.

Semaine 3 : surveiller les conversions

La troisième semaine doit être consacrée à la réalité commerciale du site.

Un site refondu peut être plus beau, plus moderne et mieux structuré, mais perdre des demandes si certains éléments de conversion ne fonctionnent pas.

À surveiller :

• formulaires soumis ;
• appels téléphoniques ;
• clics sur les boutons ;
• demandes de devis ;
• inscriptions ;
• téléchargements ;
• réservations ;
• commandes ;
• taux de conversion ;
• événements GA4 ;
• objectifs ou conversions publicitaires.

Il faut comparer les données avec la période avant refonte, si possible.

Attention : une baisse temporaire peut être normale selon le contexte. Mais une chute nette des formulaires, des commandes ou des clics importants mérite une vérification rapide.

Vérifier les événements Analytics et Tag Manager

Après une refonte, les balises de suivi peuvent être absentes ou mal déclenchées.

À vérifier :

• Google Analytics 4 ;
• Google Tag Manager ;
• Search Console ;
• pixels publicitaires ;
• événements de formulaire ;
• clics téléphone ;
• clics courriel ;
• événements WooCommerce ;
• conversions publicitaires ;
• Microsoft Clarity, si utilisé.

L’objectif est de confirmer que les données sont encore fiables. Une refonte peut casser le suivi sans que le site soit visuellement cassé.

Semaine 3 : tester à nouveau les formulaires et emails

Même si les formulaires ont été testés au jour 1, il faut les tester à nouveau après quelques semaines.

Pourquoi ? Parce que certains problèmes apparaissent avec l’usage réel :

• messages qui tombent en spam ;
• erreurs SMTP intermittentes ;
• mauvaise adresse destinataire ;
• intégration CRM instable ;
• notification manquante ;
• champ non transmis ;
• formulaire multilingue mal configuré ;
• automatisation non déclenchée.

Pour un site qui génère des prospects, cette vérification est prioritaire.

Elle doit être intégrée au monitoring WordPress post-mise en ligne.

Semaine 4 : faire le bilan des 30 jours

À la fin des 30 jours, il faut produire un bilan.

Ce bilan permet de décider si le site peut entrer dans une maintenance régulière ou si des corrections post-lancement sont encore nécessaires.

À inclure :

• incidents détectés ;
• corrections réalisées ;
• redirections ajoutées ;
• erreurs 404 restantes ;
• état Search Console ;
• formulaires testés ;
• emails testés ;
• performances observées ;
• logs importants ;
• recommandations ;
• priorités du mois suivant.

Ce bilan peut prendre la forme d’un rapport de maintenance WordPress adapté à la phase post-refonte ou post-migration.

Checklist des 30 jours après migration ou refonte WordPress

Période	Vérifications prioritaires
Jour 0 à 2	Pages clés, formulaires, emails, affichage mobile, menus, CTA
Semaine 1	Redirections, erreurs 404, liens internes, sitemap, Search Console
Semaine 2	Performances, logs, erreurs PHP, cron, sauvegardes, cache
Semaine 3	Conversions, Analytics, Tag Manager, formulaires, emails
Semaine 4	Bilan, recommandations, corrections restantes, passage en maintenance régulière

Cette checklist permet de sortir de la logique “le site est lancé, donc c’est terminé”.

Une mise en ligne réussie doit toujours être suivie d’une période de contrôle.

Points spécifiques à surveiller pour WooCommerce

Si le site est une boutique WooCommerce, la période post-migration ou post-refonte doit être encore plus rigoureuse.

À vérifier :

• pages produits ;
• variantes ;
• panier ;
• checkout ;
• paiement ;
• taxes ;
• livraison ;
• coupons ;
• courriels transactionnels ;
• commandes ;
• stocks ;
• statuts de commandes ;
• actions planifiées ;
• intégrations comptables ;
• abonnements, si présents ;
• passerelles de paiement.

WooCommerce recommande de tester les commandes pour évaluer une nouvelle méthode de paiement, revoir le processus de commande et vérifier les intégrations liées aux commandes. Les tests de commande peuvent aussi déclencher des courriels et apparaître dans les analyses WooCommerce, ce qui confirme l’importance de tester le parcours complet.  

Si WooPayments est utilisé, WooCommerce précise qu’une migration de site peut activer le Safe Mode ou empêcher le compte WooPayments de se transférer correctement vers le nouveau site. C’est donc un point à surveiller spécifiquement après migration.  

Pour approfondir, consultez notre guide sur la maintenance WooCommerce.

Les erreurs fréquentes après une migration ou refonte

Voici les erreurs que l’on voit souvent après une mise en ligne :

• anciennes URL non redirigées ;
• formulaire testé visuellement, mais pas réellement envoyé ;
• noindex oublié ;
• sitemap non soumis ;
• Search Console non vérifiée ;
• Analytics absent ;
• événements de conversion cassés ;
• images trop lourdes ;
• cache mal configuré ;
• courriels SMTP non testés ;
• pages WooCommerce non testées ;
• logs ignorés ;
• sauvegarde post-lancement oubliée ;
• rapport de suivi non envoyé.

La plupart de ces problèmes ne nécessitent pas forcément une grosse intervention. Mais s’ils ne sont pas détectés rapidement, ils peuvent affecter le SEO, les conversions ou la confiance des visiteurs.

Ce qu’il ne faut pas confondre avec la migration WordPress

Cet article ne vise pas le mot-clé “migration WordPress”.

La migration concerne le transfert du site, le changement d’hébergement, le changement de domaine, le déplacement des fichiers, de la base de données et la mise en ligne.

La maintenance WordPress après migration concerne ce qui se passe ensuite :

• est-ce que les pages fonctionnent ?
• est-ce que Google comprend le changement ?
• est-ce que les formulaires envoient ?
• est-ce que les emails partent ?
• est-ce que les conversions sont suivies ?
• est-ce que les erreurs remontent ?
• est-ce que WooCommerce vend encore correctement ?

C’est une phase de surveillance, pas un tutoriel de migration.

Si vous préparez un transfert de site, il faut plutôt consulter le service de migration WordPress de Capsuleweb.

Quand passer de la surveillance post-lancement à la maintenance régulière ?

Après 30 jours, le site peut généralement entrer dans une routine de maintenance régulière si :

• les redirections critiques sont en place ;
• les formulaires fonctionnent ;
• Search Console ne montre pas de problème majeur ;
• les emails sont envoyés correctement ;
• les conversions sont suivies ;
• les sauvegardes sont actives ;
• les logs ne montrent pas d’erreur critique ;
• les performances sont acceptables ;
• WooCommerce fonctionne, si applicable.

La suite peut alors être structurée autour d’une checklist de maintenance WordPress : vérifications hebdomadaires, mensuelles et trimestrielles.

Si des problèmes restent ouverts, il faut les traiter avant de considérer la période post-lancement comme terminée.

Comment Capsuleweb accompagne les 30 jours après migration ou refonte

Chez Capsuleweb, la période après migration ou refonte est considérée comme une phase de stabilisation.

L’objectif est de vérifier :

• les redirections ;
• l’indexation ;
• les formulaires ;
• les courriels ;
• les performances ;
• les erreurs ;
• les sauvegardes ;
• les outils de suivi ;
• les conversions ;
• les parcours WooCommerce, si nécessaire.

Cette approche permet de ne pas laisser le client seul après la mise en ligne.

Un site peut être techniquement livré, mais il doit encore être observé dans son usage réel. C’est souvent pendant ces 30 jours que les derniers ajustements importants apparaissent.

Vous pouvez nous contacter si votre site vient d’être migré, refondu ou mis en ligne et que vous souhaitez sécuriser la période post-lancement.

Conclusion

La maintenance WordPress après migration ou après refonte est essentielle pendant les 30 premiers jours. Cette période permet de vérifier les redirections, les formulaires, l’indexation, les performances, les logs, les courriels, les conversions et les parcours critiques.

Le lancement n’est pas la fin du projet. C’est le début d’une phase de surveillance.

Un site peut sembler en ligne tout en ayant des problèmes invisibles : formulaire qui n’envoie pas, redirection manquante, page noindex, erreur dans Search Console, courriel transactionnel absent ou tunnel WooCommerce bloqué.

En structurant les 30 jours post-mise en ligne, on réduit les risques, on protège le SEO et on s’assure que le site fonctionne réellement pour les visiteurs comme pour l’entreprise.

---

FAQ