Refonte de site WordPress : conseils et retour d’expérience

Une refonte de site WordPress réussie se prépare avant le design : fixer des objectifs, auditer le contenu, inventorier toutes les URL et bâtir un plan de redirections 301, puis valider performances, accessibilité et conformité RGPD sur une préproduction avant la mise en ligne. J’ai publié cet article en 2016, à la sortie d’une nouvelle version de WP channel. J’en garde le retour d’expérience, daté, complété par la méthode que je recommande aujourd’hui.

Retour d’expérience : la refonte de WP channel en 2016

En 2016, après des mois de développement sur mon temps libre, la nouvelle version de WP channel est mise en ligne, alors que le site approche de sa septième année d’existence.

Un changement de nom

WordPress Channel est devenu WP channel. Le nom du site correspondait enfin au nom de domaine et au compte Twitter, un point essentiel pour l’identité. C’était aussi l’occasion d’aller dans le sens de la cohérence avec la politique d’utilisation de la marque WordPress, même si le site n’avait jamais eu de souci à ce sujet.

Une nouvelle identité graphique

Le web design a été confié à Marina Mourguiart, dont le travail a commencé par un logo plus moderne. J’écrivais alors que ce travail repose sur une relation de confiance avec un prestataire devenu partenaire, capable de suggérer des pistes créatives parfois insoupçonnées.

Marina a ensuite conçu les gabarits : accueil, archives (catégories, étiquettes, auteur, date), article, page standard, page des contributeurs et page À propos, soit plusieurs journées de travail. La question centrale était l’accès à l’information : nous avons retenu des cartes à hauteur fixe pour lister les contenus et deux façons de chercher, par catégorie ou par mot-clé, en Ajax pour un affichage instantané.

Trois objectifs : performances, accessibilité, maintenance

La principale difficulté de l’intégration a été d’imaginer les comportements sur chaque résolution d’écran sans dégrader l’expérience utilisateur. La partie Ajax (recherche, filtres, bouton « Charger plus d’articles ») était l’œuvre de Mickaël Gris. Je m’étais fixé trois objectifs :

1. maintenir un haut niveau de performances sans sacrifier le graphisme : hébergement sur nos propres serveurs dédiés, PHP 7, code optimisé et WP Rocket pour la mise en cache ;
2. améliorer l’accessibilité, en m’appuyant sur le référentiel Opquast, le manuel de l’équipe accessibilité de WordPress et les conférences de Gaël Poupard au WP Tech 2014 et au WPMX Day 2015 ;
3. garantir une maintenance efficace et stable : code exigeant, fonctionnalités natives de WordPress autant que possible, simplicité plutôt que technologies à la mode vite périmées.

Les choix techniques de l’époque

Le site reposait sur Bootstrap pour le responsive design, HTML5, CSS3 et PHP 7, jQuery 2.2.3 (plus récent que la version fournie alors par WordPress), des polices Adobe Typekit, les Dashicons allégées avec IcoMoon et la prise en charge des écrans haute densité grâce aux SVG et à l’attribut srcset. Au total, la refonte a nécessité environ 15 jours-homme : nous aurions pu doubler ce temps, mais il faut savoir se fixer des limites.

Ce qui a changé depuis 2016

La plupart de ces choix se feraient autrement aujourd’hui, parce que WordPress intègre ce qu’il fallait alors ajouter. WP channel utilise d’ailleurs désormais un thème en blocs, piloté depuis l’éditeur de site.

• Mise en page : depuis WordPress 5.9 (janvier 2022), les thèmes en blocs se personnalisent dans l’éditeur de site et le fichier theme.json centralise couleurs, typographie et styles ; un framework CSS n’est plus indispensable.
• Chargement dynamique : le bloc Boucle de requête pagine sans recharger toute la page si l’on désactive son réglage « Recharger la page entière », et l’API Interactivity (WordPress 6.5) standardise les interactions côté visiteur.
• Polices : Typekit est devenu Adobe Fonts en 2018 ; la bibliothèque de polices, apparue avec WordPress 6.5, dispose depuis la 7.0 de son propre écran, Apparence > Polices.
• Images : srcset est automatique depuis WordPress 4.4, le WebP accepté depuis la 5.8 et l’AVIF depuis la 6.5.
• PHP : la branche 7 n’est plus maintenue ; WordPress recommande PHP 8.3 ou supérieur.

Cadrer la refonte avant de parler design

Fixer des objectifs vérifiables

Une refonte doit répondre à des problèmes identifiés : site lent, peu lisible sur mobile, parcours de contact confus, extensions qui bloquent les mises à jour. Associez à chaque objectif un indicateur (demandes de contact, Core Web Vitals, pages en erreur) et relevez sa valeur avant de commencer : sans état initial, impossible de dire si la nouvelle version fait mieux.

Auditer et élaguer le contenu

Pour chaque contenu, décidez de le conserver, de le mettre à jour, de le fusionner ou de le supprimer, en croisant trafic issu de la recherche, liens entrants et intérêt éditorial. Chaque décision a une conséquence technique : un contenu fusionné redirige en 301 vers la page qui l’absorbe, un contenu supprimé sans équivalent renvoie une erreur 404 ou 410, deux codes que Google traite de la même façon en retirant l’URL de son index.

Inventorier toutes les URL

Le plan de redirections part d’une liste exhaustive des URL actuelles. Google conseille de croiser les sitemaps, les pages qui reçoivent des liens dans la Search Console, les journaux du serveur et la liste fournie par le CMS, sans oublier images et vidéos. Côté WordPress, WP-CLI produit la liste en deux commandes :

# Published posts and pages, with their type and URL
wp post list --post_type=post,page --post_status=publish --fields=ID,post_type,url --format=csv > content-urls.csv

# Category and tag archives
wp term list category post_tag --fields=term_id,name,url --format=csv > term-urls.csv

Ajoutez vos types de contenu personnalisés à --post_type, puis les fichiers (PDF notamment) et les URL relevées dans la Search Console.

Protéger le référencement

Construire le plan de redirections 301

Associez à chaque URL qui change la nouvelle URL la plus pertinente. La documentation de Google sur les migrations avec changement d’URL fixe les règles :

• des redirections permanentes côté serveur (301 ou 308), avec le moins d’enchaînements possible ;
• pas de redirection massive vers une page sans rapport comme l’accueil, qui risque d’être traitée comme une erreur « soft 404 » ; rediriger plusieurs contenus fusionnés vers la page qui les regroupe reste légitime ;
• des liens internes et des balises canoniques mis à jour vers les nouvelles URL ;
• des redirections conservées aussi longtemps que possible, en général au moins 1 an.

WordPress redirige déjà en 301 un article dont vous modifiez le slug, mais pas une page (les contenus hiérarchiques sont exclus). Pour le reste, l’extension gratuite Redirection comme le module Redirections / 404 de SEOPress PRO importent un plan au format CSV et enregistrent les erreurs 404. Pour un changement de domaine, des règles serveur restent la solution la plus directe, comme je l’explique dans mon tutoriel sur la redirection 301 via le .htaccess.

Contrôler après la mise en ligne

Testez toutes les redirections, pas un échantillon : Google suggère l’outil d’inspection d’URL pour des cas isolés et un script au-delà. Celui-ci lit un fichier redirections.csv (une ligne ancienne_url,nouvelle_url par redirection, sans en-tête) et n’affiche que les anomalies :

#!/usr/bin/env bash
# Checks every redirect listed in redirections.csv (old_url,new_url per line, no header).
# Only mismatches are printed.

while IFS=',' read -r old_url new_url || [[ -n "$old_url" ]]; do
	new_url="${new_url%$'\r'}"
	result=$(curl -s -o /dev/null -w '%{http_code} %{redirect_url}' "$old_url")
	code="${result%% *}"
	target="${result#* }"

	if [[ "$code" != "301" && "$code" != "308" ]] || [[ "$target" != "$new_url" ]]; then
		echo "KO  $old_url -> $code $target (expected: $new_url)"
	fi
done < redirections.csv

Surveillez ensuite les rapports Sitemaps et Indexation des pages de la Search Console et le journal des erreurs 404. Pour un site de taille moyenne, Google prévient qu’il faut compter quelques semaines ou plus avant que les nouvelles URL remplacent les anciennes. En cas de changement de nom de domaine, déclarez aussi le changement d’adresse dans la Search Console.

Design et thème : partir de l’éditeur de site

Une refonte est le moment logique pour passer à un thème en blocs. L’éditeur de site (Apparence > Éditeur) donne alors la main sur les modèles, les parties de modèle (en-tête, pied de page), les compositions, la navigation et les styles globaux. C’est le choix fait pour WP channel ; j’en détaille le fonctionnement dans mon article sur le Full Site Editing.

La liste de gabarits établie en 2016 reste un bon exercice : dans un thème en blocs, accueil, archives, article, page, recherche et erreur 404 correspondent chacun à un modèle HTML de la hiérarchie des modèles (category.html, single.html, 404.html…). Maquettez-les avec des contenus réels, pas du faux texte : c’est là que se révèlent les titres trop longs et les images mal cadrées.

Thème existant ou thème développé pour le projet ? J’expose les arguments du second dans Pourquoi développer un thème WordPress sur mesure ? Dans l’annuaire officiel, l’étiquette accessibility-ready signale des exigences minimales, pas une conformité WCAG de niveau AA.

Performances : mesurer avant et après

Le premier objectif de 2016 se mesure aujourd’hui avec les Core Web Vitals, sur des données de visiteurs réels (75^e centile) : LCP de 2,5 secondes ou moins pour l’affichage du contenu principal, INP de 200 millisecondes ou moins pour la réactivité, CLS de 0,1 ou moins pour la stabilité visuelle.

Relevez-les dans le rapport Core Web Vitals de la Search Console avant la refonte, puis comparez. Les leviers : images aux bonnes dimensions et dans un format moderne (voir mon guide sur la gestion des images sous WordPress), cache de pages, peu d’extensions et de scripts tiers, polices hébergées sur votre serveur, PHP à jour.

Accessibilité : ce que la loi impose en France

En 2016, l’accessibilité était un objectif que je m’étais fixé. Le cadre légal s’est étendu depuis, et une refonte permet de corriger la structure du site plutôt que de la rapiécer.

Qui est concerné ?

• Organismes publics et grandes entreprises : l’article 47 de la loi du 11 février 2005 vise notamment les personnes morales de droit public et les entreprises à partir de 250 millions d’euros de chiffre d’affaires annuel moyen en France. Elles publient notamment une déclaration d’accessibilité fondée sur le RGAA et affichent leur niveau de conformité sur la page d’accueil ; la déclaration doit être mise à jour lors d’une refonte.
• Services couverts par la directive européenne : depuis le 28 juin 2025, la directive (UE) 2019/882, appliquée en France notamment par le décret n° 2023-931 du 9 octobre 2023, impose l’accessibilité de services destinés aux consommateurs, dont le commerce électronique, les services bancaires, les transports et les livres numériques. Les microentreprises prestataires de services (moins de 10 salariés et chiffre d’affaires annuel ou total de bilan inférieur à 2 millions d’euros) sont exemptées, et des périodes transitoires courent jusqu’au 28 juin 2030 au plus tard.

Le site vitrine d’une TPE n’entre en général dans aucune de ces catégories ; une boutique WooCommerce qui vend à des particuliers est concernée dès que l’entreprise n’est plus une microentreprise. La fiche pratique de la DGCCRF, autorité de contrôle pour ces services, détaille le périmètre.

Quel référentiel suivre ?

Le référentiel en vigueur est le RGAA 4.1.2 : 106 critères qui couvrent les 50 critères de succès des niveaux A et AA des WCAG 2.1 retenus par la norme européenne. Le RGAA 5 est attendu fin 2026, ce qui ne justifie pas de reporter les travaux. Hors obligation, visez les WCAG 2.2 de niveau AA, le niveau que WordPress exige de son propre code.

En recette, testez la navigation au clavier (focus visible, ordre logique), les contrastes, la hiérarchie des titres, les alternatives textuelles et les étiquettes de formulaires, puis un parcours complet au lecteur d’écran. Avant de recréer un chargement dynamique comme en 2016, notez que la documentation du bloc Boucle de requête juge le rechargement complet de la page plus sûr pour l’accessibilité.

RGPD : faire le ménage dans les services tiers

Inventoriez les services tiers (polices, vidéos, cartes, mesure d’audience, partage) : chacun peut déposer des traceurs. Selon les règles de la CNIL, les cookies non strictement nécessaires exigent un consentement préalable, et refuser doit être aussi simple qu’accepter ; certains outils de mesure d’audience en sont exemptés sous conditions. Côté WordPress :

• hébergez les polices chez vous : la bibliothèque de polices télécharge les Google Fonts choisies et les sert depuis votre site ;
• mettez à jour la politique de confidentialité désignée dans Réglages > Confidentialité ;
• limitez les formulaires aux champs utiles et vérifiez que votre extension s’intègre à Outils > Exporter les données et Outils > Effacer les données ;
• mettez à jour le registre des traitements, obligatoire pour tout organisme qui traite des données personnelles, quelle que soit sa taille.

Pour le détail, consultez mon guide sur WordPress et le RGPD.

Recette et mise en ligne

Travailler sur une préproduction isolée

Construisez la nouvelle version sur une copie du site configurée comme la production, protégée par mot de passe et exclue de l’indexation. La case « Demander aux moteurs de recherche de ne pas indexer ce site » de Réglages > Lecture est stockée en base et part en production avec elle. Je recommande plutôt de déclarer l’environnement dans le wp-config.php de la préproduction avec define( 'WP_ENVIRONMENT_TYPE', 'staging' ); et de laisser une extension indispensable (mu-plugin) forcer ce réglage partout sauf en production :

<?php
/**
 * Plugin Name: WPC Noindex Outside Production
 * Description: Discourages search engines on every environment except production.
 */

defined( 'ABSPATH' ) || exit;

add_filter( 'pre_option_blog_public', 'wpc_noindex_outside_production' );

/**
 * Forces the "blog_public" option to 0 outside production.
 *
 * @param mixed $pre_option Value to return instead of the stored option, false to keep the stored one.
 * @return mixed
 */
function wpc_noindex_outside_production( mixed $pre_option ): mixed {
	if ( 'production' === wp_get_environment_type() ) {
		return $pre_option;
	}

	return '0';
}

Enregistrez ce code dans wp-content/mu-plugins/wpc-noindex-outside-production.php. En production, wp_get_environment_type() renvoie production par défaut et le filtre ne change rien. Vérifiez dans le code source d’une page de préproduction que la balise robots contient bien noindex : certaines extensions SEO génèrent leur propre balise.

La recette, point par point

• formulaires : envoi réel, réception des e-mails, messages d’erreur ;
• affichage sur mobile, tablette et ordinateur, dans plusieurs navigateurs ;
• page d’erreur 404, recherche interne, archives et pagination ;
• bandeau de consentement : aucun traceur soumis à consentement avant le choix de l’internaute ;
• sitemap XML, balises canoniques (chaque nouvelle URL pointe vers elle-même) et plan de redirections prêt à être activé.

Le jour de la mise en ligne

1. sauvegarde complète de la production (fichiers et base de données), dont la restauration a été testée ;
2. déploiement de la nouvelle version et activation des redirections ;
3. contrôle de Réglages > Lecture et du fichier robots.txt : Google range l’oubli d’un noindex ou d’un blocage hérité du développement parmi les erreurs courantes ;
4. purge des caches (extension, CDN), puis exécution du script de contrôle des redirections ;
5. envoi du nouveau sitemap dans la Search Console ;
6. mise à jour de la déclaration d’accessibilité si votre site y est soumis.

Si vous préparez la refonte d’un site WordPress et souhaitez être accompagné du cadrage à la mise en ligne, ma démarche est présentée sur la page création de sites WordPress.

Questions fréquentes

Combien de temps prend une refonte de site WordPress ?

Cela dépend du volume de contenus, des modèles et des fonctionnalités à reprendre. À titre de repère, la refonte de WP channel en 2016 avait nécessité environ 15 jours-homme au total.

Une refonte fait-elle perdre du référencement ?

Pas durablement si chaque URL modifiée est redirigée en 301 vers son équivalent et que les liens internes sont mis à jour. Des fluctuations temporaires sont normales pendant que Google explore à nouveau le site. Les causes classiques de pertes durables sont des redirections manquantes, un noindex oublié ou des contenus supprimés sans équivalent.

Combien de temps garder les redirections 301 ?

Google recommande au moins un an et suggère même de les garder indéfiniment du point de vue des visiteurs. Mettez aussi à jour vos propres liens et, si possible, les liens externes importants, car chaque redirection ralentit l’affichage.

Mon site est-il concerné par l’obligation d’accessibilité ?

Oui si vous êtes un organisme public, une entreprise d’au moins 250 millions d’euros de chiffre d’affaires en France, ou si vous proposez aux consommateurs un service couvert par la directive européenne, vente en ligne en tête, sans être une microentreprise. Sinon, l’accessibilité reste une bonne pratique qui profite à tous.