Ressource Agence BPC
Checklist migration WordPress 7.0 en 3 phases
27 contrôles cochables organisés en 3 phases pour migrer un site WordPress 6.x vers la 7.0 sans casser le SEO ni la production. La checklist couvre les deux grosses nouveautés de la 7.0 (Connectors API IA, collaboration temps réel) et les pièges classiques de toute migration majeure WordPress.
Imprimez la page, posez-la à côté de votre clavier, cochez au fur et à mesure. Un point survolé, c'est en général la cause d'une chute de 20 à 40% de trafic organique dans les 90 jours qui suivent la bascule, ou d'un plugin tiers qui sature votre clé API IA en silence.
Phase 1 - Audit pré-migration (semaines 1-2)
- Inventorier tous les plugins actifs : nom, version, date du dernier update sur wordpress.org, compatibilité WP 7.0 annoncée par l'éditeur. Sur un site moyen de 5 ans, comptez 12 à 20 plugins dont 3 à 5 jamais mis à jour depuis > 18 mois (à remplacer ou supprimer, pas négociable).
- Lister les surcharges du thème : child theme, hooks modifiés, templates customisés, blocks personnalisés. Cette liste donne le temps de reprise estimé (4 à 20 heures de dev front selon le niveau de customisation).
- Vérifier la compatibilité du page builder si présent : Divi, Elementor, Bricks. Historiquement, les page builders mettent 4 à 12 semaines pour publier une version stable compatible avec une majeure WordPress. Ne migrez PAS avant que votre builder soit officiellement compatible.
- Vérifier que l'hébergement supporte PHP 8.2 minimum (8.3 recommandé pour WordPress 7.0), MySQL 8.0+ ou MariaDB 10.6+, et `memory_limit` 512M minimum. Si mutualisé bas de gamme, bascule sur un hébergeur sérieux (Kinsta, WP Engine, o2switch, ou VPS).
- Extraire toutes les URLs indexées via Screaming Frog ET Google Search Console. Distinguer : articles, pages, catégories blog, pages produit WooCommerce si applicable. Cette liste sert de référence pour vérifier que rien ne casse côté SEO après bascule.
- Snapshot SEO complet : positions sur 30 à 50 mots-clés stratégiques, captures Search Console (impressions, clics, CTR des 12 derniers mois), liste des pages qui génèrent 80% du trafic organique.
- Backup complet en double : dump SQL + dossier wp-content/ + fichier wp-config.php + fichiers serveur custom (.htaccess, configuration Nginx ou Apache). Stocké sur 2 supports différents, pas sur le même serveur que la prod.
- Décider de la stratégie IA : allez-vous brancher des modèles via la Connectors API ? Si oui, quels fournisseurs (OpenAI, Anthropic, Google) et pour quels cas d'usage (SEO, modération, support, recommandations) ? Budget IA mensuel estimé.
- Document chiffré de sortie d'audit : durée totale estimée (2 à 12 jours-homme selon poids du site), budget par poste, risques identifiés (plugins critiques non maintenus, builder lent à se mettre à jour), plan de récupération SEO détaillé.
Phase 2 - Bascule en staging et tests (semaines 3-5)
- Provisionner l'environnement de staging sur un sous-domaine dédié (ex : staging.votresite.fr), avec mêmes specs serveur que la prod cible (PHP 8.2 minimum, MySQL 8.0+, RAM, CPU).
- Activer noindex strict sur le staging via robots.txt (Disallow: /) ET header X-Robots-Tag: noindex. Double protection contre l'indexation accidentelle (Google adore indexer les stagings, surtout si un dev oublie le robots.txt).
- Cloner la base et les fichiers de prod vers staging. Vérifier que les URLs internes pointent bien vers le sous-domaine staging (search-replace sur la base : wp-cli search-replace).
- Lancer la mise à jour WordPress 6.x vers 7.0 sur le staging. Si tout est propre : 30 à 60 minutes. Tests immédiats : login admin, édition d'un article, prévisualisation, formulaire de contact.
- Tester chaque plugin actif un par un : désactiver tout, réactiver plugin par plugin, vérifier que chacun fonctionne sur WP 7.0. Les plugins qui plantent à l'activation = à remplacer.
- Tester la nouvelle collaboration temps réel Gutenberg : ouvrir un article en édition sur 2 onglets différents avec 2 comptes, vérifier que les curseurs sont visibles et que les modifs se synchronisent sans conflit.
- Configurer la Connectors API IA si activée : renseigner la clé OpenAI, Anthropic ou Google côté admin, tester un appel simple (génération de texte) via un plugin compatible, vérifier la facturation et les quotas côté fournisseur.
- Audit performance complet : Lighthouse mobile + desktop, Core Web Vitals (LCP < 2,5s, INP < 200ms, CLS < 0,1). Comparer aux valeurs pré-migration. Si dégradation > 10%, identifier le block theme ou le plugin coupable.
- Vérifier le balisage SEO dans Google Rich Results Test : schema Article, BreadcrumbList, FAQPage sur 10 pages au hasard. Comparer avec un crawl pré-migration. Le passage à WP 7.0 peut modifier la structure JSON-LD générée par certains plugins SEO.
- Tester les meta titles et descriptions sur 20 pages clés (top trafic organique). Vérifier qu'elles n'ont pas été écrasées par les defaults WP 7.0 ou par un plugin SEO incompatible.
- Tester tous les formulaires de contact et les parcours de conversion : envoi formulaire, réception email, intégration CRM si applicable, popups, lead magnets. Du clic au mail de confirmation reçu.
- Si WooCommerce : tester chaque mode de paiement (Stripe, PayPal, virement, CB), processus de checkout complet en 3 langues si applicable, e-mails transactionnels, espace client.
- Vérifier les redirections existantes : 301 historiques, plugin de redirection (Redirection, Rank Math). Aucune ne doit casser sur WP 7.0. Tester 30 anciennes URLs au hasard.
Phase 3 - Bascule en production et monitoring (semaines 6-18)
- Choisir le créneau de bascule : mardi, mercredi ou jeudi matin. JAMAIS un vendredi. JAMAIS la veille d'un jour férié. Toute l'équipe disponible pendant 48 heures après.
- Bascule en suivant un plan horodaté : maintenance activée, dernier backup, déploiement code, vérif sample 20 URLs, désactivation maintenance, soumission nouveau sitemap dans Search Console.
- Surveillance temps réel pendant les 4 heures qui suivent : Search Console (erreurs), GA4 (trafic en temps réel), logs serveur (codes 4xx/5xx). Tout pic d'erreur = diagnostic immédiat.
| Heure | Action | Responsable |
|---|---|---|
| 8:30 | Activation maintenance + dernier backup complet | Dev |
| 8:45 | Mise à jour WordPress 6.x vers 7.0 (depuis wp-admin) | Dev |
| 9:15 | Vérif login admin + 5 articles + formulaires + paiement | Dev / Métier |
| 9:30 | Vérif redirections (échantillon 20 URLs) | SEO |
| 9:45 | Désactivation maintenance | Dev |
| 10:00 | Re-vérif tracking GA4 + Ads + Schema JSON-LD | Marketing |
| 10:15 | Soumission nouveau sitemap dans Search Console | SEO |
- J+1 à J+7 : Search Console quotidien. Pic de 404, « page d'erreur de redirection », « page exclue » = action immédiate. Logs Googlebot consultés tous les jours.
- J+30 : audit positions vs snapshot pré-migration. Chute > 15% sur les mots-clés stratégiques = diagnostic urgent (souvent schema cassé par un plugin SEO incompatible ou block theme mal repris).
Règle d'or
Une migration WordPress 7.0 réussie se voit à J+90 : trafic stable ou en hausse, positions intactes, Core Web Vitals améliorés. Si vous êtes encore en chute à J+90, ce n'est plus un retard d'indexation : c'est un dégât structurel (souvent un plugin SEO mal compatible ou un block theme mal configuré) à corriger en urgence.