Ce que WordPress fait bien nativement, et l'endroit exact où sa responsabilité s'arrête
Posséder un site WordPress ne dit à peu près rien de son référencement, et c'est la première chose qu'il faut accepter avant d'ouvrir le capot. Le socle, pris seul, est plutôt bon élève : il produit des adresses lisibles dès qu'on le lui demande, il respecte la hiérarchie des titres si le thème ne la sabote pas, il génère depuis plusieurs versions un plan de site XML sans qu'on installe quoi que ce soit, il pose une balise canonique correcte sur les contenus standards, et il expose une interface d'édition que n'importe quel salarié peut utiliser sans formation longue. Cette dernière qualité est d'ailleurs la plus sous-estimée sur le plan du référencement : un site que l'on peut alimenter sans appeler un prestataire est un site qui reçoit du contenu, et un site qui reçoit du contenu progresse. Beaucoup d'installations que nous reprenons ont survécu à des années de négligence technique uniquement parce que quelqu'un, dans l'entreprise, continuait de publier.
Le revers est symétrique et rarement énoncé. WordPress fabrique de lui-même des quantités de pages que personne n'a demandées : une archive par catégorie, une par étiquette, une par auteur, une par mois, une par année, une page par fichier envoyé dans la médiathèque, et autant de pages de pagination qu'il faut pour écouler les listes. Il n'arbitre pas ce qui mérite d'exister aux yeux d'un moteur, parce que ce n'est pas son travail. Il ne contrôle pas non plus ce qu'une extension injecte dans l'en-tête de chacune de vos pages, ni le poids qu'un thème acheté quarante-neuf dollars fait porter à chaque visiteur, ni la cohérence entre les trois balisages de données structurées émis simultanément par le thème, l'extension de référencement et le constructeur de pages. Le socle est neutre ; tout ce qui compte se joue dans les décisions prises autour de lui.
Le socle est neutre : il fournit des fondations correctes et laisse entièrement ouvertes les décisions qui séparent un site visible d'un site invisible.
Nous travaillons WordPress depuis la création de Facem Web, en décembre 2012, et cette continuité nous a donné une vision assez précise de la manière dont un site vieillit. Nous développons des thèmes sur mesure et des thèmes enfants, et nous reprenons régulièrement des installations qui ont accumulé sept ou huit ans de couches successives : un thème premium modifié directement dans ses fichiers, un constructeur de pages ajouté par un prestataire, un second constructeur ajouté par le suivant, trente-cinq extensions dont personne ne sait à quoi servent la moitié, deux extensions de référencement actives en même temps, et un dossier de médias qui pèse plusieurs gigaoctets pour une centaine d'images réellement affichées. Rien de tout cela n'est visible depuis la page d'accueil, et c'est précisément pourquoi le diagnostic doit être fait avec les outils du développeur plutôt qu'avec ceux du visiteur.
Cette page s'adresse à quelqu'un qui possède déjà un WordPress et qui veut savoir où porter l'effort. Elle ne traite pas de ce qu'est le référencement en général — d'autres pages du site s'en chargent — ni de la spécificité des boutiques en ligne, qui obéissent à des règles distinctes. Elle traite du CMS lui-même : de sa structure d'adresses, de ses thèmes, de ses extensions, de ses images, de ses archives, de son cache, de sa sécurité, de ses mises à jour et de ses migrations. Chaque section décrit un mécanisme concret, ce qu'il coûte quand il est mal réglé, et la manière dont nous le traitons sur les dossiers que nous ouvrons, à Arras, à Lille et partout en France.
Les permaliens : la décision structurante que l'on ne prend confortablement qu'une fois
La structure des permaliens se règle en trois clics dans les réglages, ce qui donne l'impression trompeuse d'un paramètre anodin. Elle détermine pourtant l'adresse de chaque contenu du site, et par conséquent l'identité de chaque page aux yeux des moteurs. WordPress propose par défaut une forme technique bâtie sur un identifiant numérique, et plusieurs formes lisibles : la date suivie du titre, le titre seul, la catégorie suivie du titre, ou une combinaison personnalisée. Le choix par défaut à l'installation dépend de la version et de l'hébergeur, et nous trouvons encore des sites en production dont les articles vivent derrière un point d'interrogation et un numéro. Notre recommandation, sur l'immense majorité des projets, tient en une ligne : le titre seul, en minuscules, sans accent, sans mot vide inutile, et sans date. La date dans l'adresse date le contenu de manière irréversible et transforme un article encore pertinent en archive périmée dès que l'internaute lit l'URL.
La question de la catégorie dans l'adresse mérite un examen plus nuancé. Faire apparaître le silo thématique dans le chemin donne une lecture immédiate de l'architecture, aussi bien pour le visiteur que pour le moteur, et facilite la mise en place de regroupements cohérents. Mais elle crée une dépendance : le jour où un article change de catégorie, son adresse change aussi, et il faut alors gérer une redirection. Sur un site éditorial dont la taxonomie est stabilisée depuis des années, l'inconvénient est théorique. Sur un site dont les rubriques bougent au gré des offres commerciales, il devient une source permanente de dette technique. Nous tranchons dossier par dossier, en regardant d'abord la stabilité réelle du plan de classement plutôt que l'élégance de l'adresse.
- Étape 1 Geler et inventorier l'existant Exploration complète du site, export du rapport d'indexation, journaux serveur sur plusieurs mois, plans de site : toutes les adresses connues, pas seulement celles du menu.
- Étape 2 Trancher la structure cible Le titre seul dans la quasi-totalité des cas. La date fige un contenu intemporel, la catégorie crée une dépendance dès qu'un article change de rubrique.
- Étape 3 Écrire la table de correspondance Une ligne par contenu, ancienne adresse vers nouvelle adresse. Jamais un renvoi massif vers l'accueil, jamais une règle générique qui laisse des trous.
- Étape 4 Poser des redirections permanentes directes Un seul saut par adresse. Les chaînes héritées de refontes successives se résolvent à cette occasion plutôt que de s'allonger d'un cran.
- Étape 5 Réécrire les liens internes en base Les liens posés dans le corps des articles sont stockés en dur. On les remplace avec un outil qui comprend les données sérialisées, jamais par une requête SQL brute.
- Étape 6 Resoumettre et surveiller huit semaines Nouveaux plans de site, suivi des pages indexées, des impressions et des adresses demandées qui renvoient une absence. Ce sont elles qui révèlent les oublis.
Le réglage se modifie en une seconde ; l'opération se prépare comme une migration complète. C'est la seule façon d'obtenir une perte transitoire plutôt qu'une perte définitive.
Le coût d'un changement de structure est le point sur lequel nous alertons le plus fermement, parce qu'il est systématiquement sous-évalué. Modifier le réglage prend une seconde ; ses conséquences se comptent en jours de travail et en semaines de récupération. Toutes les adresses du site changent simultanément, y compris celles qui sont indexées depuis des années, celles qui reçoivent des liens depuis d'autres sites, celles qui ont été partagées, imprimées sur une plaquette ou enregistrées en favori. Les liens internes posés dans le corps des articles sont stockés en dur dans la base de données et pointent toujours vers les anciennes adresses. Les images insérées, les fichiers joints, les éventuelles règles de cache et les configurations de suivi analytique se retrouvent décalés. Si le site tourne sur un serveur qui limite le nombre de règles de réécriture, les redirections deviennent elles-mêmes un sujet de performance.
Il existe malgré tout des situations où le changement se justifie, et nous les traitons plusieurs fois par an. Une structure bâtie sur un identifiant numérique prive le site de tout signal sémantique dans l'adresse et vaut la peine d'être corrigée tant que le site est jeune. Une structure datée sur un fonds d'articles intemporels handicape durablement la perception de fraîcheur. Une structure qui empile trois niveaux de catégories imbriquées produit des adresses interminables que les moteurs tronquent dans leurs affichages. Dans ces cas, l'opération se prépare comme une migration à part entière : cartographie exhaustive de l'existant, table de correspondance adresse par adresse, redirections permanentes écrites en une seule règle par contenu et non en chaîne, réécriture des liens internes directement en base, mise à jour des plans de site, puis surveillance de l'indexation sur six à huit semaines. Faite ainsi, la perte est transitoire et se résorbe. Faite en cochant une case un vendredi soir, elle ne se résorbe pas.
Le thème : le choix qui décide silencieusement de tout le reste
Un thème WordPress n'est pas une peinture posée sur un contenu, c'est le programme qui décide de ce que le navigateur reçoit. Il fixe le balisage HTML de chaque gabarit, la hiérarchie des titres, l'ordre de chargement des styles et des scripts, la manière dont les images sont appelées, la présence ou l'absence de données structurées, et le comportement du site sur un téléphone d'entrée de gamme. C'est donc le premier facteur technique du référencement d'un WordPress, très loin devant le réglage de n'importe quelle extension. Un thème sobre et bien écrit vous laisse un site rapide même sur un hébergement modeste ; un thème lourd vous condamne à passer votre budget en rustines de performance qui ne rattraperont jamais complètement le retard initial.
Le modèle économique des thèmes multi-usage vendus sur les places de marché explique l'essentiel du problème. Pour justifier son prix et se distinguer de mille concurrents, un thème doit annoncer le maximum de fonctions : vingt démos importables, un constructeur intégré, un second constructeur en option, un carrousel maison, une bibliothèque d'icônes complète, un système de portfolio, un module de réservation, un jeu de polices personnalisées et une centaine de codes courts. L'acheteur en utilise trois. Le visiteur, lui, télécharge l'ensemble, parce que ce type de thème charge globalement plutôt que conditionnellement. Nous mesurons couramment, sur ces installations, des feuilles de style de plusieurs centaines de kilooctets dont moins d'un dixième sert réellement, une dizaine de fichiers JavaScript chargés sur toutes les pages y compris celles qui n'en ont aucun usage, et un arbre de balises trois à cinq fois plus dense que ce que le même contenu exigerait.
Ce qu'un thème lourd coûte réellement, au-delà des kilooctets
Le poids n'est que la partie visible. Le premier coût réel est la dépendance : votre site ne fonctionne plus sans l'éditeur du thème, ses mises à jour, ses éventuelles extensions compagnes et sa licence annuelle. Le jour où cet éditeur cesse son activité — cela arrive régulièrement — vous héritez d'un site figé sur une version de PHP vieillissante, avec le choix entre reconstruire ou vivre dangereusement. Le deuxième coût est la rigidité : chaque demande d'évolution un peu spécifique se heurte à une architecture pensée pour être configurée, pas pour être modifiée, et le développeur passe plus de temps à contourner le thème qu'à écrire la fonctionnalité. Le troisième coût est l'écrasement : quand des modifications ont été faites directement dans les fichiers du thème parent, la première mise à jour les efface, et l'on découvre la perte plusieurs semaines plus tard en constatant qu'une balise a disparu ou qu'un gabarit est revenu à son état d'origine.
C'est pour cette raison que nous travaillons soit avec un thème enfant systématique lorsqu'un thème du commerce est déjà en place, soit avec un thème sur mesure lorsque le projet le justifie. Le thème enfant n'est pas une élégance de développeur : c'est la seule manière de personnaliser un thème tout en continuant de recevoir ses correctifs de sécurité. Le thème sur mesure, lui, se justifie dès que le site porte réellement l'activité commerciale de l'entreprise. Il ne contient que ce que le site utilise, il produit un balisage que l'on maîtrise entièrement, il ne dépend d'aucune licence, et il vieillit beaucoup mieux parce qu'on peut le faire évoluer sans démonter une usine. C'est l'approche que nous appliquons sur nos projets de création de site internet, et c'est aussi celle vers laquelle nous ramenons progressivement les installations reprises, gabarit par gabarit, sans jamais imposer une refonte totale à une entreprise dont le site fonctionne.
Les constructeurs de pages et le poids de balisage qu'ils ajoutent
Divi, Elementor, WPBakery et leurs équivalents répondent à un besoin réel et légitime : permettre à une personne non technique de composer une mise en page sans écrire une ligne de code. Ils ont largement contribué à démocratiser la création de sites, et il serait malhonnête de les condamner en bloc. Il faut simplement savoir ce qu'ils coûtent, parce que ce coût est payé par chaque visiteur et par chaque passage du robot d'exploration. Un constructeur fonctionne en enveloppant votre contenu dans une structure de conteneurs imbriqués : une section, une rangée, une colonne, un module, un habillage interne, parfois un second habillage pour l'animation. Un simple paragraphe de texte se retrouve ainsi enfermé dans six à huit niveaux de balises, chacune portant ses classes et parfois ses styles en ligne.
Multipliez cela par le nombre de blocs d'une page de service ordinaire et vous obtenez un arbre de plusieurs milliers de nœuds là où le même contenu, écrit proprement, en demanderait quelques centaines. Ce volume a trois conséquences mesurables. Le navigateur met plus de temps à construire et à peindre la page, ce qui pèse directement sur la vitesse perçue. Le rapport entre le texte utile et le code qui l'entoure se dégrade fortement, ce qui n'est pas un critère en soi mais complique la lecture du document par les analyseurs. Et surtout, chaque interaction devient plus coûteuse, parce que le navigateur doit recalculer un arbre plus lourd à chaque changement d'état — c'est là que se joue une bonne partie des mauvaises mesures de réactivité que nous relevons.
Le contenu prisonnier, et ce que ça change le jour où l'on veut partir
Le second sujet est plus insidieux. Un constructeur qui stocke ses mises en page sous forme de codes courts — c'est le cas historique de plusieurs d'entre eux — laisse en base de données un contenu illisible sans lui. Désactivez l'extension, et vos pages affichent des lignes de crochets et de paramètres à la place du texte. Ce que l'on appelle le verrouillage n'est pas une clause contractuelle, c'est un fait technique : votre contenu éditorial, celui qui vous a coûté des semaines de rédaction, n'existe plus indépendamment de l'outil qui l'a composé. Les constructeurs plus récents stockent leurs structures en JSON dans les métadonnées, ce qui est plus propre côté rendu mais tout aussi captif. Sortir d'un constructeur signifie donc, dans la pratique, réextraire le texte page par page et le recomposer — un travail que nous chiffrons généralement en jours plutôt qu'en heures, et qu'il vaut mieux anticiper qu'improviser.
Notre position n'est pas dogmatique. Sur un site existant qui fonctionne, dont l'équipe interne maîtrise l'outil et publie régulièrement, arracher le constructeur est rarement le meilleur usage du budget : on obtient plus de résultats en désactivant les modules inutilisés, en limitant le chargement des ressources aux pages qui en ont besoin, en supprimant les animations décoratives et en reconstruisant les deux ou trois gabarits les plus visités en HTML natif. Sur un projet neuf, en revanche, nous privilégions l'éditeur de blocs standard complété de blocs sur mesure, parce qu'il produit un balisage nettement plus léger, qu'il fait partie du cœur et qu'il ne dépend d'aucun éditeur tiers. La question à se poser avant de choisir n'est pas « lequel est le plus joli » mais « qui va publier sur ce site dans trois ans, et avec quel niveau de compétence ».
L'accumulation d'extensions et l'inventaire de ce qui sert encore
L'extension est la grande liberté de WordPress et sa principale source de dette. Chaque besoin ponctuel trouve sa réponse en trois minutes : un formulaire, un carrousel, une bannière de consentement, une galerie, un annuaire, un compteur de partages, un chat, un système de réservation, un correctif pour un problème oublié depuis. Personne ne désinstalle jamais rien, parce que personne ne se souvient de ce que chaque extension faisait ni de qui l'a activée. Sur les installations que nous reprenons, le compteur tourne fréquemment entre trente et cinquante extensions actives, et il nous est arrivé d'en trouver davantage. Le problème n'est pas le nombre en lui-même — dix extensions bien écrites pèsent moins que trois mal écrites — mais ce que chacune ajoute sans le dire.
Ce qu'elle ajoute, concrètement : des requêtes supplémentaires à la base de données sur chaque affichage de page, une ou plusieurs feuilles de style et des scripts chargés partout y compris là où ils ne servent à rien, parfois des appels à des serveurs extérieurs qui bloquent le rendu, des tâches planifiées qui s'exécutent au moment où un visiteur arrive, des tables supplémentaires en base, des options chargées automatiquement à chaque requête, et dans les cas les plus lourds une réécriture de gabarits ou une injection dans l'en-tête HTML. L'effet cumulé n'est pas linéaire : c'est la combinaison qui coûte, en particulier quand deux extensions font la même chose ou se contredisent. Nous avons vu des sites où trois systèmes de cache cohabitaient, où deux extensions de référencement émettaient chacune leur balise canonique, et où une extension de sécurité bloquait le robot d'un moteur que l'entreprise cherchait justement à séduire.
L'inventaire tient sur un tableau et demande une demi-journée sur un site de taille moyenne. La suppression se fait ensuite une par une, avec une sauvegarde restaurable et une vérification entre chaque étape.
L'inventaire que nous menons tient sur un tableau et demande une demi-journée sur un site de taille moyenne. Pour chaque extension, nous notons ce qu'elle fait réellement, où cette fonction est visible sur le site public, la date de sa dernière mise à jour et l'activité de son auteur, la présence d'alternatives natives ou déjà couvertes par une autre extension, son poids en ressources chargées, et le risque associé à sa suppression. Trois catégories se dégagent presque toujours. Les extensions indispensables et bien entretenues, que l'on garde sans discuter. Les extensions qui rendent un service réel mais dont la fonction tient en quelques dizaines de lignes dans le thème, que l'on remplace par du code maîtrisé. Et les extensions fantômes, dont plus aucune trace n'apparaît sur le site public, qui continuent pourtant de charger leurs fichiers sur chaque page.
La suppression se fait toujours une par une, avec une sauvegarde restaurable et une vérification entre chaque étape, jamais par lot. Deux précautions supplémentaires méritent d'être connues. La première est que désinstaller ne nettoie pas : la majorité des extensions laissent derrière elles leurs tables, leurs options et parfois leurs types de contenu personnalisés, si bien qu'une base peut rester chargée de résidus datant de prestataires partis depuis longtemps. La seconde est que certaines extensions créent des contenus publics — des types personnalisés, des taxonomies, des pages d'archive — qui ont pu être indexés. Les faire disparaître brutalement génère des erreurs par centaines. On les traite comme n'importe quelle suppression d'adresse : on vérifie ce qui est indexé, on redirige ce qui mérite de l'être, et on laisse le reste renvoyer un code d'absence franc plutôt qu'une redirection paresseuse vers l'accueil. Cette remise à plat est l'un des chantiers que nous incluons systématiquement dans un audit technique et sémantique, parce que son rapport entre effort et gain est l'un des meilleurs de tout le plan d'action.
Les extensions SEO : ce qu'elles font, ce qu'elles ne font pas, et l'illusion du feu vert
Yoast, Rank Math et SEOPress occupent le même créneau et rendent, pour l'essentiel, les mêmes services. Elles vous donnent la main sur le titre et la méta-description de chaque contenu, avec des modèles applicables par type de page, ce qui évite d'avoir à les écrire une par une sur un site qui en compte des centaines. Elles pilotent les directives d'indexation contenu par contenu et par famille, ce qui est indispensable pour traiter les archives dont nous parlerons plus loin. Elles gèrent la balise canonique, produisent un plan de site XML segmenté, émettent un balisage de données structurées de base, génèrent le fil d'Ariane, alimentent les métadonnées de partage social, et proposent dans leurs versions payantes un module de redirections qui capte automatiquement les changements d'adresse. C'est beaucoup, c'est utile, et un WordPress sérieux en installe une.
Ce qu'elles ne font pas est tout aussi important à énoncer, parce que la confusion coûte cher. Elles ne décident pas de votre architecture : aucune extension ne vous dira que vos six pages de service se cannibalisent parce qu'elles traitent la même intention avec des mots différents. Elles n'écrivent pas votre contenu, et le générateur de texte qu'elles intègrent parfois produit exactement la matière indifférenciée qui ne positionne rien. Elles n'acquièrent aucun lien. Elles ne corrigent pas un thème lent ni un hébergement saturé. Elles ne savent pas si la personne qui tape votre requête cible veut acheter, comparer ou apprendre. Autrement dit, elles administrent des réglages ; elles ne remplacent ni la stratégie ni l'exécution. Nous voyons régulièrement des entreprises persuadées d'avoir « fait leur SEO » parce qu'elles ont installé et configuré l'une d'elles.
Le feu vert vert, et pourquoi il ne mesure pas ce que vous croyez
L'analyse de contenu intégrée à ces extensions attribue à chaque page un indicateur coloré, et cet indicateur exerce une fascination remarquable sur les équipes. Il faut comprendre ce qu'il calcule : la présence d'une expression choisie par vous dans le titre, l'adresse, le chapeau, un sous-titre et un attribut d'image, une densité située dans une fourchette arbitraire, une longueur minimale, une proportion de phrases longues, une part de voix passive, un nombre de mots de transition. Ce sont des critères de forme, mesurés par un algorithme local qui n'a jamais vu les pages concurrentes, ne connaît pas le volume de recherche, ignore l'intention de la requête et n'a aucune idée de la qualité de l'information que vous délivrez. Un texte creux peut atteindre le vert en dix minutes ; un excellent article de fond restera orange parce qu'il emploie des synonymes plutôt que de répéter mécaniquement une expression.
Nous demandons donc à nos clients de traiter cet indicateur comme une liste de vérification de mise en forme, et rien de plus. Les seuls signaux réellement utiles qu'il fournit sont l'oubli d'un titre, l'absence de méta-description, une adresse aberrante ou un texte manifestement trop court pour le sujet traité. Pour le reste, la question qui compte est ailleurs : votre page répond-elle mieux que celles classées devant vous à ce que cherche la personne qui tape la requête, et le prouve-t-elle avec des informations que vous seul possédez ? C'est la conversation que nous ouvrons dans nos missions de conseil en référencement, et elle ne commence jamais par la couleur d'une pastille. Un dernier point pratique : n'installez jamais deux de ces extensions simultanément. Elles émettent alors des balises concurrentes, des plans de site rivaux et des directives contradictoires, et le moteur tranche comme il peut — souvent à votre désavantage.
Les images : le premier poste d'économie sur presque tous les WordPress
Sur la grande majorité des sites que nous auditons, les images représentent l'essentiel du poids transféré, et l'essentiel du gain accessible en quelques heures de travail. Le scénario est toujours le même : quelqu'un envoie dans la médiathèque une photographie sortie d'un appareil ou d'une banque d'images, quatre mille pixels de large, plusieurs mégaoctets, et l'insère dans un bloc qui l'affichera sur huit cents pixels. Le navigateur télécharge le fichier complet, le redimensionne à la volée, et l'internaute qui consulte le site sur son téléphone en zone mal couverte paie la différence. Rien dans l'interface ne l'avertit, rien ne l'empêche, et l'aperçu est parfait à l'écran. Le problème n'apparaît que dans les mesures de performance, c'est-à-dire au moment où l'on cherche à comprendre pourquoi le site est lent.
Le traitement se joue sur quatre plans. Les dimensions d'abord : une image ne doit jamais être servie beaucoup plus large que la place qu'elle occupe, ce que WordPress sait faire correctement à condition que les tailles générées correspondent aux emplacements réels du thème. Le format ensuite : le WebP est aujourd'hui reconnu partout et réduit couramment le poids de moitié par rapport à un JPEG de qualité équivalente, l'AVIF va plus loin encore sur les photographies, et le PNG doit être réservé aux visuels qui exigent de la transparence ou des aplats nets. La compression enfin, avec un réglage qui doit être testé visuellement plutôt que subi : sur une photographie ordinaire, on descend très bas avant que l'œil ne perçoive quoi que ce soit. Et pour finir la déclaration explicite des dimensions dans le balisage, qui n'a aucun effet sur le poids mais évite que la page ne saute au moment où l'image arrive.
Le chargement différé et son piège le plus fréquent
WordPress applique nativement un chargement différé aux images depuis plusieurs versions, ce qui est une bonne chose : les visuels situés en bas de page ne sont téléchargés que lorsque le visiteur s'en approche. Le piège est bien connu et pourtant très répandu : lorsque ce mécanisme s'applique aussi à la grande image de bandeau qui occupe le haut de la page, il retarde précisément l'élément qui définit la vitesse d'affichage perçue. Le navigateur doit d'abord analyser le document, exécuter le script, décider que l'image est visible, puis seulement la demander. On perd plusieurs centaines de millisecondes sur l'indicateur qui compte le plus. La correction consiste à exclure du différé le ou les premiers visuels de chaque gabarit, et à leur donner au contraire une priorité de chargement élevée. La plupart des extensions d'optimisation savent le faire ; encore faut-il le régler, car aucune ne le devine.
Reste le dossier des tailles générées, qui est probablement le désordre le mieux caché de WordPress. À chaque envoi de fichier, le CMS crée plusieurs déclinaisons — miniature, moyenne, moyenne large, grande — auxquelles s'ajoutent celles déclarées par le thème et par chaque extension qui en réclame. Sur une installation chargée, il n'est pas rare qu'un seul envoi produise entre dix et vingt fichiers, dont trois sont réellement utilisés. Multiplié par plusieurs milliers de médias accumulés sur dix ans, cela donne des dossiers de plusieurs dizaines de gigaoctets, des sauvegardes interminables et des migrations pénibles. Nous auditons donc les tailles déclarées, nous supprimons celles qui ne correspondent à aucun emplacement réel, nous régénérons proprement, et nous purgeons les orphelines. Le gain n'est pas directement un gain de position, mais il rend le site administrable — et un site administrable est un site que l'on ose faire évoluer.
Le cache, les CDN et l'hébergement : ce qu'ils règlent et ce qu'ils masquent
Le cache est le premier réflexe de toute personne confrontée à un WordPress lent, et c'est un bon réflexe. Il faut cependant distinguer plusieurs mécanismes que le vocabulaire commercial mélange volontiers. Le cache de page enregistre le HTML final d'une adresse et le ressert tel quel aux visiteurs suivants, ce qui supprime intégralement le travail de PHP et de la base de données ; c'est le levier le plus spectaculaire. Le cache d'objets conserve en mémoire les résultats de requêtes coûteuses et accélère ce qui ne peut pas être mis en cache de page, notamment l'administration et les parcours identifiés. Le cache d'opcode conserve le code PHP compilé et se règle côté serveur. Le cache navigateur, enfin, évite au visiteur de retélécharger les fichiers statiques qu'il possède déjà. Ces quatre couches ne se remplacent pas : elles se complètent.
Ce qu'un cache de page ne règle pas mérite d'être dit clairement, parce que c'est là que se cachent la plupart des mauvaises surprises. Il ne corrige rien à la génération réelle de vos pages : un site dont chaque page demande quatre secondes de calcul reste un site à quatre secondes, simplement il ne le montre qu'à certains visiteurs. Lesquels ? Le premier arrivé après une purge, c'est-à-dire après chaque publication ou chaque mise à jour d'extension sur les configurations agressives. Tout visiteur identifié, donc toute votre équipe. Et surtout le robot d'exploration, qui a la particularité de demander en priorité des adresses peu visitées — précisément celles que le cache n'a pas conservées. Nous avons vu des sites afficher des temps de réponse excellents dans les outils grand public et des temps catastrophiques dans les statistiques d'exploration du moteur, pour cette seule raison. Le cache est un pansement efficace ; il ne remplace pas un thème raisonnable et un parc d'extensions maîtrisé.
Le réseau de diffusion de contenu obéit à la même logique. Il rapproche géographiquement vos fichiers statiques du visiteur, absorbe les pics de charge, décharge votre serveur, et propose souvent une optimisation d'images à la volée qui rend de vrais services. Pour une entreprise dont la clientèle est française et l'hébergement en France, le gain de latence pure est modeste ; il devient significatif dès que l'audience s'internationalise. En revanche, aucun réseau de diffusion ne réduira un arbre de balises de cinq mille nœuds, n'accélérera l'exécution de trois cent kilooctets de JavaScript, ni ne rendra rapide une requête SQL mal écrite. Confier ces sujets au CDN revient à espérer qu'un livreur plus rapide compense un colis trois fois trop lourd.
L'hébergement mutualisé, ses vertus et ses limites réelles
Le mutualisé n'est pas déshonorant, et nous ne conseillons pas systématiquement de le quitter. Pour un site vitrine de quinze pages, quelques centaines de visiteurs par jour et une publication mensuelle, une offre mutualisée sérieuse, avec une version de PHP récente et un stockage SSD, fait parfaitement l'affaire pour un coût dérisoire. Les limites apparaissent ailleurs. La ressource processeur est partagée, ce qui signifie que la charge d'un voisin peut dégrader votre temps de réponse à des moments que vous ne contrôlez pas. Le nombre de processus PHP simultanés est plafonné, si bien qu'un léger pic de trafic ou le passage soutenu d'un robot fait apparaître des erreurs de serveur qui, elles, sont vues par le moteur. La base de données est souvent bridée en connexions et en durée de requête. Le cache d'objets en mémoire n'est généralement pas disponible. Et l'on n'obtient ni accès aux journaux du serveur, ni ligne de commande, ni environnement de préproduction — trois manques qui rendent le diagnostic et la maintenance nettement plus laborieux. Le basculement vers un serveur dédié ou une infrastructure infogérée se justifie quand le site porte le chiffre d'affaires, quand le trafic dépasse quelques milliers de visites quotidiennes, ou quand la nature du site impose des traitements non mis en cache.
Les Core Web Vitals sur un WordPress réel
Les signaux web essentiels mesurent trois choses distinctes, et sur WordPress chacune a ses coupables habituels. Le premier indicateur observe le délai au bout duquel le plus gros élément visible de l'écran d'accueil est affiché : sur un site vitrine, c'est presque toujours l'image de bandeau ou le bloc de titre. Le deuxième mesure la réactivité, c'est-à-dire le temps que met la page à répondre visuellement lorsque le visiteur clique, ouvre un menu ou déplie un accordéon. Le troisième quantifie l'instabilité visuelle, ces déplacements de contenu qui font cliquer à côté et lire deux fois la même ligne. Aucun de ces trois indicateurs ne fera monter un site médiocre, et il faut se méfier des prestations vendues sur cette seule promesse. En revanche, ils pèsent sur le comportement des visiteurs, et le comportement des visiteurs finit toujours par se voir.
Les causes, sur WordPress, se répètent d'un dossier à l'autre avec une régularité déconcertante. Pour l'affichage du contenu principal : une image de bandeau non compressée et chargée en différé, une police web appelée depuis un serveur tiers qui retarde le rendu du texte, une feuille de style de thème de plusieurs centaines de kilooctets qui bloque l'affichage, et un temps de réponse serveur déjà élevé faute de cache pertinent. Pour la réactivité : l'accumulation de scripts d'extensions exécutés au chargement, un carrousel maison, un gestionnaire de balises qui déclenche quatre outils de mesure, une bulle de conversation, et un arbre de balises alourdi par le constructeur de pages. Pour la stabilité : des images sans dimensions déclarées, une bannière de consentement injectée après coup, des polices dont la substitution provoque un ressaut, et des blocs conditionnels qui apparaissent une fois le script chargé.
Chaque étage s'ajoute au précédent : optimiser les images d'un site posé sur un mutualisé saturé revient à peindre une façade sur des fondations qui bougent. On traite dans cet ordre.
Un point de méthode évite beaucoup de temps perdu. Deux familles de mesures coexistent et ne disent pas la même chose. La mesure en laboratoire simule une visite dans des conditions fixées et fournit un diagnostic détaillé, reproductible, immédiatement exploitable pour identifier ce qui bloque. La mesure de terrain agrège les visites réelles de vos internautes sur une fenêtre glissante de plusieurs semaines, avec leurs appareils et leurs connexions ; c'est elle que le moteur regarde, et elle réagit avec un retard qui déroute systématiquement les équipes. Corriger un problème un lundi et constater le mardi que la note n'a pas bougé n'a rien d'anormal : il faut laisser passer la fenêtre d'observation complète avant de juger. Nous prévenons toujours de ce décalage avant d'engager le chantier, parce qu'il génère sinon une inquiétude et des interventions désordonnées.
Notre ordre d'attaque est presque invariable. On commence par le serveur et le cache, parce que tout le reste s'y ajoute. On traite ensuite les images du premier écran, qui offrent le meilleur rapport entre effort et gain. On s'occupe des polices, en les hébergeant localement et en les préchargeant, ce qui règle souvent d'un coup un problème de rendu et un problème de conformité au règlement européen sur les données. On attaque alors le JavaScript : suppression du superflu, chargement différé de ce qui n'est pas nécessaire à l'affichage initial, restriction des scripts aux gabarits qui les utilisent réellement. On termine par le CSS, en réservant à l'affichage immédiat le strict nécessaire. Et l'on mesure entre chaque étape, sur les mêmes pages et dans les mêmes conditions, faute de quoi on ne saura jamais laquelle des cinq interventions a produit le résultat.
Catégories, étiquettes et archives : le contenu que WordPress fabrique sans vous le demander
Voici la particularité la plus mal maîtrisée du CMS, et celle qui produit le plus de dilution. Chaque fois qu'un rédacteur publie un article, WordPress crée ou alimente automatiquement plusieurs pages annexes : l'archive de chaque catégorie cochée, l'archive de chaque étiquette saisie, l'archive de l'auteur, l'archive du mois, l'archive de l'année, et le flux correspondant. Un blog de deux cents articles répartis dans huit catégories et associés à cent quarante étiquettes différentes ne compte donc pas deux cents pages mais plusieurs centaines, dont l'écrasante majorité n'affiche que des extraits d'articles existants. Personne n'a demandé la création de ces pages, personne ne les relit, et pourtant elles concourent pour votre visibilité — c'est-à-dire qu'elles consomment du budget d'exploration et qu'elles se placent parfois devant l'article qu'elles auraient dû mettre en avant.
Le cas des étiquettes est le plus caricatural. Sur les sites que nous reprenons, nous trouvons très couramment des étiquettes créées à l'unité pour un seul article, souvent au singulier et au pluriel, avec des fautes de frappe qui les dupliquent encore. Chacune produit une page d'archive contenant un seul extrait, c'est-à-dire à peu près rien. Le cas des archives d'auteur est comparable sur les sites où une seule personne publie : la page d'auteur reproduit alors très exactement la page d'accueil du blog, avec une adresse différente. Quant aux archives de date, elles proposent un classement chronologique dont l'intérêt pour un visiteur venu d'un moteur est proche de zéro dans la quasi-totalité des secteurs.
Un blog de deux cents articles ne compte pas deux cents pages. La décision se prend famille par famille, en se demandant ce que chacune apporte à quelqu'un qui arriverait dessus depuis un moteur.
La règle que nous appliquons ne consiste pas à tout désindexer par principe, ce qui serait paresseux et parfois contre-productif. Elle consiste à demander de chaque famille de pages ce qu'elle apporte à quelqu'un qui arriverait dessus depuis un moteur. Une page de catégorie peut être excellente, à condition qu'on la travaille : un titre pensé pour une requête réelle, un texte d'introduction substantiel qui présente le sujet et oriente, un ordre d'affichage éditorial plutôt que chronologique, et des liens vers les contenus de référence de la rubrique. Ainsi conçue, elle devient une page de destination à part entière et se positionne souvent mieux que les articles qu'elle liste. Traitée par défaut, avec un titre égal au nom de la catégorie et une liste d'extraits, elle n'apporte rien et vaut mieux hors de l'index.
Les autres cas se tranchent plus vite. Les étiquettes sont désindexées sauf usage transversal réellement construit et documenté — un regroupement par marque, par matériau, par ville d'intervention, avec un contenu propre. Les archives d'auteur sont désactivées sur les sites mono-auteur et conservées, avec une vraie fiche biographique, sur les publications collectives où la signature a une valeur. Les archives de date sont désactivées presque systématiquement. Les pages de recherche interne ne doivent jamais être indexables, sous peine de voir apparaître dans l'index une adresse par requête tapée, y compris par des robots malveillants. Quant à la pagination, elle reste explorable — c'est par elle que le moteur atteint les contenus anciens — mais chaque page porte sa propre balise canonique, jamais un renvoi vers la première : renvoyer la page quatre vers la page une revient à dire au moteur d'oublier tout ce qu'elle contient. Ces réglages se posent en quelques minutes dans n'importe quelle extension de référencement ; encore faut-il avoir pris la décision, et l'avoir prise famille par famille.
Le maillage interne et les blocs de liens automatiques
WordPress ne propose presque rien nativement en matière de liens internes : un menu, des widgets de barre latérale, et c'est à peu près tout. Le reste vient d'extensions ou du thème, et prend généralement la forme de blocs générés automatiquement — « articles similaires », « à lire aussi », « les derniers articles de la même catégorie ». Ces blocs ont un mérite, celui d'exister, et deux défauts qu'il faut connaître. Le premier est que leur logique de sélection est pauvre : ils choisissent par catégorie commune et par date, ce qui produit des rapprochements sans pertinence éditoriale, et ils affichent souvent les trois mêmes contenus récents sur des dizaines de pages différentes. Le second est que l'ancre du lien est systématiquement le titre de l'article, ce qui prive le moteur du signal le plus utile que porte un lien interne : le vocabulaire employé pour le décrire.
Un maillage qui produit des effets se construit dans le corps du texte, pas dans les blocs de pied de page. Concrètement, cela signifie qu'en rédigeant une page ou un article, on cite les contenus voisins au moment où le propos les appelle, avec une ancre qui décrit la destination dans les mots d'un lecteur — « la manière dont nous construisons un plan de redirections », « notre approche des thèmes enfants » — plutôt qu'un titre recopié ou un « en savoir plus » qui n'informe personne. On varie les formulations d'une page à l'autre, parce que répéter cent fois la même ancre exacte est un motif que les moteurs identifient sans difficulté. Et l'on regarde d'où partent les liens autant que vers où ils vont : un lien depuis la page d'accueil ou depuis une page qui reçoit déjà de la visibilité transmet infiniment plus qu'un lien depuis un article que personne ne consulte.
Les pages orphelines et les grappes isolées
L'exercice le plus révélateur consiste à explorer le site avec un outil de crawl en partant uniquement de l'accueil, puis à comparer la liste obtenue à l'inventaire réel des contenus publiés. La différence, ce sont les pages orphelines : celles qu'aucun lien interne ne désigne, accessibles uniquement par le plan de site ou par une adresse connue. Sur un WordPress de quelques années, on en trouve toujours, et souvent parmi les plus importantes — une page de service créée pour une campagne publicitaire, un guide rédigé pour un salon, une page géographique ajoutée puis oubliée. Elles peuvent être indexées, elles sont rarement bien positionnées, parce que le site lui-même ne leur accorde aucune importance visible. Les relier depuis deux ou trois pages pertinentes est le genre de correction qui prend une heure et qui se lit dans les courbes quelques semaines plus tard.
Nous en profitons pour poser une architecture en regroupements thématiques, ce que l'on appelle communément le siloing, mais sans le fétichisme qui l'accompagne parfois. L'idée tient en peu de mots : les contenus qui traitent d'un même sujet se citent abondamment entre eux et convergent vers une page de référence, laquelle porte la requête principale et renvoie vers l'ensemble. WordPress s'y prête bien grâce à ses catégories et à ses pages parentes, à condition que le plan de classement corresponde vraiment à la manière dont vos clients pensent votre métier plutôt qu'à votre organigramme interne. Nous vérifions enfin la profondeur de clic : un contenu situé à plus de trois ou quatre clics de l'accueil sur un site vitrine est un contenu que vous considérez implicitement comme secondaire, et le moteur en tire la même conclusion. Si ce n'est pas ce que vous vouliez dire, il faut le corriger dans la structure, pas dans le texte.
Les données structurées : ce qui sert vraiment, ce qui encombre
WordPress n'émet quasiment aucune donnée structurée par lui-même. Tout ce que votre site déclare provient donc du thème, de l'extension de référencement, du constructeur de pages ou d'une extension dédiée — et c'est exactement là que naissent les problèmes que nous rencontrons le plus souvent. Sur une installation chargée, il n'est pas rare de trouver trois blocs de balisage concurrents dans la même page : le thème déclare une organisation avec un logo, l'extension de référencement déclare la même organisation avec un logo différent, et le constructeur ajoute son propre fil d'Ariane qui contredit celui déjà présent. Le moteur ne « choisit » pas au sens où on l'entend : il tente de réconcilier, échoue partiellement, et finit par ignorer une partie de ce que vous lui dites. Le premier travail sur ce sujet n'est donc pas d'ajouter du balisage, c'est d'en retirer.
Une fois le terrain déblayé, la question devient : quels types déclarer, et pour quel bénéfice ? Sur un site d'entreprise, le socle utile tient en quelques éléments. La déclaration de l'organisation, avec la dénomination exacte, l'adresse, les moyens de contact et les profils officiels, contribue à ce que le moteur relie entre elles toutes les mentions de votre entreprise sur le web — c'est un travail d'identité, pas un travail d'affichage. Le fil d'Ariane, unique et cohérent avec la navigation réelle, améliore la lisibilité du chemin dans les résultats. Le balisage d'article, sur les contenus éditoriaux, précise la date de publication, la date de modification et l'auteur. Le balisage d'établissement local, quand l'entreprise reçoit du public, complète la cohérence entre le site et la fiche d'établissement. Le balisage de questions-réponses reste utile quand la page contient réellement une foire aux questions visible par le visiteur, même si son affichage enrichi a été fortement restreint.
Ce qu'il ne faut pas déclarer, et pourquoi
Deux tentations reviennent régulièrement et méritent un avertissement franc. La première est le balisage d'avis et de note moyenne auto-attribué : déclarer soi-même que son entreprise obtient quatre virgule neuf sur cinq, sans support d'avis réels et vérifiables affichés sur la page, expose à une perte de tous les affichages enrichis du domaine, parfois durable. Le jeu n'en vaut pas la chandelle. La seconde est l'empilement systématique de types dans l'espoir d'un effet cumulatif : déclarer un balisage de cours, d'événement ou de produit sur des pages qui ne contiennent ni cours, ni événement, ni produit ne rapporte rien et signale au moteur que votre balisage n'est pas fiable. Le balisage de produit, en particulier, appartient aux pages de fiches marchandes et relève d'une logique que nous traitons dans nos accompagnements de sites e-commerce, avec ses exigences propres de prix, de disponibilité et de mise à jour.
La vérification, enfin, doit être faite sur les pages réelles et non sur un extrait de code collé dans un validateur. Nous contrôlons un échantillon représentatif de chaque gabarit — accueil, page de service, article, catégorie, page de contact — avec l'outil de test des résultats enrichis et l'inspection d'URL, et nous surveillons le rapport dédié de la Search Console pendant les semaines qui suivent, parce que c'est là que remontent les erreurs générées à grande échelle par un gabarit défectueux. L'intérêt de ce travail dépasse aujourd'hui les affichages enrichis : les moteurs conversationnels et les réponses génératives s'appuient largement sur la capacité à identifier une entité, ses activités et son périmètre. Un balisage propre et cohérent est l'un des rares leviers directs dont on dispose sur ce terrain.
Le multilingue et le multisite : deux réponses souvent confondues
Rendre un WordPress multilingue passe généralement par WPML ou Polylang, dont les philosophies diffèrent plus qu'on ne le croit. Polylang associe à chaque contenu ses traductions au sein de la même installation et reste léger, avec une version gratuite très utilisable pour un site vitrine. WPML propose une gestion plus industrielle, avec des flux de traduction, la connexion à des agences et une meilleure prise en charge des extensions tierces complexes, au prix d'une base de données nettement plus sollicitée. Sur les sites marchands ou dotés de nombreuses extensions, la compatibilité penche souvent en faveur du second ; sur un site institutionnel bilingue, le premier suffit largement. Ce qui compte davantage que le choix de l'outil, c'est la rigueur des réglages qui l'entourent.
Le premier réglage est la forme des adresses. Le répertoire de langue est la solution la plus simple à administrer et à sécuriser, et celle que nous recommandons dans la quasi-totalité des cas : une seule installation, un seul certificat, un seul domaine dont l'autorité profite à toutes les langues. Le sous-domaine complique la donne sans bénéfice évident. Le domaine par pays ne se justifie que pour des entités juridiquement distinctes, avec des équipes et des offres réellement différentes, et il suppose de construire l'autorité de chaque domaine séparément — c'est un choix d'entreprise, pas un choix technique. Le second réglage est la déclaration des correspondances entre versions linguistiques, qui doit être exhaustive et réciproque : chaque page doit désigner ses équivalentes dans les autres langues et être désignée par elles en retour, avec une version par défaut clairement identifiée. Une déclaration incomplète ou unilatérale est simplement ignorée.
Les pièges qui coûtent le plus cher
Trois erreurs reviennent constamment. La première est la traduction automatique publiée sans relecture : elle produit des pages qui existent, s'indexent, et donnent de votre entreprise une image approximative dans la langue concernée. Elle abîme la crédibilité bien plus qu'elle n'apporte de trafic. La deuxième est la traduction partielle : les articles sont traduits, les pages de catégorie non, les slugs restent en français, les chaînes du thème — boutons, messages de formulaire, mentions de pied de page — restent dans la langue d'origine, et le visiteur étranger tombe sur un site hybride. Traduire un site, ce n'est pas traduire ses articles ; c'est traduire ses adresses, ses taxonomies, ses menus, ses formulaires, ses messages système et ses métadonnées. La troisième est le changement d'extension en cours de route, opération lourde qui reconstruit les correspondances et provoque presque toujours une perte de traductions si elle n'est pas préparée comme une migration.
Le multisite, lui, répond à une question différente : gérer plusieurs sites distincts depuis une seule installation, avec un cœur, des thèmes et des extensions partagés. Il est parfaitement justifié quand une organisation exploite un grand nombre de sites structurellement identiques — un réseau d'agences, des filiales, des marques distinctes avec des équipes séparées — et qu'un administrateur central doit pouvoir déployer une mise à jour partout en une fois. Il ne l'est pas pour gérer deux langues, ce que les extensions dédiées font mieux. Il ne l'est pas non plus pour créer un site par ville d'intervention, stratégie qui produit surtout des sites vides se cannibalisant entre eux, alors qu'une arborescence locale bien construite sur un seul domaine concentre l'autorité. Il faut par ailleurs connaître ses contreparties : une base de données commune dont le volume explose, une extension incompatible qui bloque l'ensemble du réseau, une compromission qui touche tous les sites simultanément, et une expertise d'administration que tous les prestataires ne possèdent pas. Nous en installons quand le besoin est réel ; nous en démontons aussi, quand il ne l'était pas.
La sécurité, et son lien très direct avec le référencement
La popularité de WordPress en fait la cible la plus attaquée du web, non par faiblesse intrinsèque du cœur — qui est plutôt bien tenu — mais par la loi des grands nombres et par l'état du parc d'extensions. Les attaques automatisées ne visent personne en particulier : elles balaient des millions d'adresses à la recherche d'une version vulnérable connue, d'un identifiant faible ou d'un fichier laissé accessible. Un site d'artisan à Béthune est scanné exactement comme un site de groupe industriel, et il est souvent plus facile à compromettre. Le lien avec le référencement est immédiat et brutal, ce que beaucoup de dirigeants découvrent au pire moment : un site compromis n'est plus un problème informatique, c'est un problème de visibilité et de réputation.
Le scénario le plus répandu n'est pas la page noire avec un message de revendication. C'est l'injection discrète : des centaines de pages générées dans un répertoire ignoré, souvent dans une langue étrangère et sur des thématiques de contrefaçon, de médicaments ou de jeu en ligne, invisibles pour un visiteur qui navigue normalement. Le code injecté sert un contenu différent selon l'identité du demandeur : la vraie page pour vous, la page de spam pour le robot du moteur. Parfois s'ajoutent des liens sortants dissimulés dans le pied de page et une redirection conditionnelle qui n'envoie ailleurs que les visiteurs venus d'un moteur sur téléphone. L'entreprise ne se rend compte de rien pendant des semaines, jusqu'à ce que le nombre de pages indexées explose sans raison, qu'un message apparaisse dans la Search Console, que la mention « ce site peut être piraté » s'affiche sous le résultat, ou que le navigateur affiche un avertissement rouge en plein écran.
Ce que coûte le nettoyage, et pourquoi il ne suffit pas
Restaurer une sauvegarde saine et refermer la porte d'entrée n'est que la première moitié du travail. Il faut ensuite traiter les traces laissées dans l'index : recenser les adresses parasites indexées, les faire renvoyer un code d'absence franc, demander leur retrait, corriger les plans de site, et solliciter un examen si une action manuelle a été notifiée. Il faut aussi vérifier les comptes administrateurs créés à votre insu, les tâches planifiées ajoutées, les fichiers déposés dans le dossier des médias, les modifications faites en base dans les options, et les liens que les auteurs du spam ont eux-mêmes acquis vers vos pages parasites — un passif dont vous héritez. Le rétablissement complet de la visibilité demande, dans les dossiers que nous traitons, de quelques semaines à plusieurs mois, et il n'est jamais garanti à l'identique. C'est l'un des rares domaines où la prévention est manifestement moins chère que la réparation.
La prévention, sur WordPress, tient à des gestes peu spectaculaires mais cumulatifs : appliquer les correctifs du cœur, du thème et des extensions dans un délai court, supprimer purement et simplement ce qui n'est plus utilisé plutôt que de le désactiver, limiter les comptes administrateurs au strict nécessaire et donner à chacun le niveau de droits correspondant à son usage réel, imposer des mots de passe robustes et une double authentification sur les comptes à privilèges, restreindre les tentatives de connexion, désactiver l'édition de fichiers depuis l'interface, fermer les points d'entrée inutilisés, tenir des sauvegardes stockées hors du serveur et — le point que presque personne ne vérifie — s'assurer qu'elles se restaurent réellement. Nous ajoutons volontiers un filtrage applicatif en amont sur les sites exposés, et nous surveillons l'intégrité des fichiers, car repérer une modification anormale trois heures après vaut infiniment mieux que la découvrir trois semaines plus tard dans un message du moteur.
Mises à jour, environnements de test et retours en arrière
Toute entreprise qui exploite un WordPress se heurte tôt ou tard au même dilemme, et le tranche généralement mal. Ne pas mettre à jour laisse ouvertes des vulnérabilités publiquement documentées, ce qui revient à parier sur la chance. Mettre à jour à l'aveugle un vendredi après-midi expose à ce que quelque chose casse pendant le week-end, sans personne pour s'en apercevoir. Les mises à jour automatiques, activées par défaut sur les versions mineures et proposées pour les extensions, réduisent le risque de sécurité mais transfèrent le risque fonctionnel : elles s'appliquent sans que personne ne vérifie ensuite que le site fonctionne toujours. Notre conviction, formée sur des années de maintenance, est qu'il faut mettre à jour souvent — donc par petits lots faciles à diagnostiquer — mais jamais sans filet.
Ce qui casse est rarement spectaculaire, et c'est bien le problème. Un site qui s'effondre complètement se remarque dans l'heure. Un formulaire de contact qui n'envoie plus rien depuis une mise à jour de l'extension d'envoi de courriels ne se remarque pas du tout : les demandes de devis cessent simplement d'arriver, et l'entreprise conclut à un marché atone. Une mise à jour de thème qui écrase des modifications faites dans le parent supprime silencieusement un balisage. Une extension de référencement qui repasse un réglage à sa valeur par défaut réindexe soudain trois cents pages d'étiquettes. Un module de redirections dont la table se vide fait disparaître d'un coup l'héritage d'une ancienne migration. Aucune de ces situations n'émet d'alerte ; toutes se paient en visibilité, avec un décalage de plusieurs semaines qui rend le diagnostic difficile.
La préproduction, et la recette de dix minutes qui évite la plupart des accidents
Un environnement de test n'est plus un luxe réservé aux grandes structures : la plupart des hébergeurs sérieux proposent aujourd'hui la création d'une copie du site en un clic, et les outils de synchronisation ont beaucoup progressé. La règle que nous appliquons est simple : toute opération susceptible de modifier le comportement du site — montée de version majeure, changement de thème, ajout ou retrait d'extension structurante, modification de la structure d'adresses — passe d'abord par cette copie. Deux précautions vont avec. La préproduction doit être fermée aux moteurs, sans quoi elle finit indexée et concurrence le site réel, ce que nous constatons plus souvent qu'il ne serait raisonnable. Et elle doit être fermée par authentification serveur plutôt que par une simple directive, car une directive oubliée dans l'autre sens le jour du basculement fait disparaître le site de l'index en quelques jours.
La recette qui suit chaque mise à jour tient sur une feuille et prend dix minutes bien employées. On charge la page d'accueil, deux pages de service et un article, en vérifiant l'affichage sur téléphone autant que sur ordinateur. On envoie un vrai message par le formulaire de contact et l'on vérifie qu'il arrive dans une boîte réelle. On regarde le code source d'une page pour confirmer la présence du titre, de la méta-description, de la balise canonique et du balisage structuré. On appelle le plan de site et le fichier robots. On teste deux redirections connues. On ouvre l'interface d'administration avec un compte non administrateur pour s'assurer que les rédacteurs peuvent toujours travailler. Enfin, avant même de commencer, on sait où se trouve la sauvegarde, combien de temps prend sa restauration et qui détient les accès nécessaires. Cette procédure de retour en arrière ne servira probablement pas, et c'est précisément parce qu'elle existe que l'opération se déroule sans stress. Nous documentons régulièrement ces gestes dans notre blog consacré à WordPress, pour les équipes qui préfèrent les exécuter elles-mêmes.
Migrer un WordPress sans perdre ses positions
Le mot « migration » recouvre des opérations dont la difficulté n'a rien de comparable, et la première chose à faire est de savoir laquelle on entreprend. Changer d'hébergeur en conservant le domaine, les adresses et le thème est l'opération la plus sûre : bien menée, elle est totalement transparente pour les moteurs. Passer d'une adresse non sécurisée à une adresse sécurisée relève d'un changement de domaine complet du point de vue technique, même si l'utilisateur n'y voit rien. Changer de nom de domaine transfère l'autorité d'une entité vers une autre et demande une période de consolidation. Refondre le thème en conservant les adresses modifie le contenu perçu de chaque page sans toucher à leur identité. Modifier la structure des permaliens ou fusionner deux sites constitue l'opération la plus délicate, parce qu'elle cumule changement d'adresses et changement de contenu. Le risque et le calendrier découlent directement de ce classement.
- Étape 1 Qualifier l'opération réelle Simple changement de serveur, passage en HTTPS, changement de domaine, refonte de thème à adresses constantes ou fusion de sites : le calendrier découle de ce classement.
- Étape 2 Relever la situation de départ Pages indexées, positions et impressions sur les expressions stratégiques, temps de réponse, liste des redirections déjà en place. Sans relevé avant, aucune comparaison après.
- Étape 3 Monter une préproduction fermée Copie complète, fermée par authentification serveur et non par une simple directive, pour éviter qu'elle ne s'indexe et ne concurrence le site réel.
- Étape 4 Remplacer les adresses proprement Un outil qui comprend les données sérialisées, jamais un rechercher-remplacer SQL qui vide silencieusement les réglages de widgets, de thème et d'extensions.
- Étape 5 Recetter avant de basculer Gabarits, formulaire testé en réel, titres et canoniques dans le code source, plan de site, fichier robots, échantillon de redirections, et procédure de retour arrière écrite.
- Étape 6 Basculer hors des créneaux à risque Jamais un vendredi soir ni une veille de jour férié. Durée de vie des DNS abaissée à l'avance, équipe disponible dans les heures qui suivent, vérifications enchaînées dans l'heure.
- Étape 7 Surveiller six à huit semaines Pages indexées par type, impressions comparées à l'année précédente, erreurs serveur et adresses absentes. Un tassement de trois semaines est normal, un mois ne l'est plus.
Changer d'hébergeur, de domaine, de thème ou de structure d'adresses ne présente pas du tout le même risque. La première décision consiste à savoir laquelle de ces opérations on entreprend.
Les incidents que nous réparons le plus souvent après une migration ratée forment une liste courte et remarquablement stable. Le remplacement des adresses en base de données effectué avec un simple rechercher-remplacer SQL, qui corrompt les données sérialisées et fait disparaître silencieusement les réglages de widgets, de thème et d'extensions : il faut un outil qui comprenne la sérialisation, jamais une requête brute. La directive d'interdiction d'indexation héritée de la préproduction, laissée active sur le site de production, qui vide l'index en une à deux semaines. Le fichier de configuration du serveur oublié lors de la copie, emportant avec lui toutes les règles de redirection existantes. Les redirections écrites en chaîne, l'ancienne adresse renvoyant vers une deuxième qui renvoie vers une troisième, chaque saut diluant un peu plus le signal. Les contenus mixtes après passage en HTTPS, avec des images et des scripts encore appelés en clair. Et le classique absolu : la redirection globale de toutes les anciennes adresses vers la page d'accueil, qui revient à jeter l'historique de chaque page pour épargner une journée de travail.
La surveillance après bascule est aussi importante que la préparation, et elle se mène sur six à huit semaines. Nous suivons quatre indicateurs et rien d'autre : le nombre de pages indexées par type de contenu, la courbe d'impressions et de clics comparée à la même période de l'année précédente, le volume d'erreurs serveur relevé dans les journaux, et la liste des adresses demandées qui renvoient une absence — car ce sont elles, et elles seules, qui révèlent les oublis du plan de redirections. Une migration réussie présente un profil reconnaissable : un léger tassement pendant deux à trois semaines, le temps que le moteur réexplore et réévalue l'ensemble du site, puis un retour au niveau antérieur. Une chute qui se prolonge au-delà d'un mois n'est pas un phénomène naturel dont il faudrait attendre la fin : c'est un symptôme, et il a une cause identifiable. Plus le diagnostic est précoce, plus le rattrapage est simple, parce qu'au bout de quelques mois le moteur a eu le temps d'oublier des milliers d'adresses qu'il faudra lui réapprendre une par une.
Le fichier robots, le sitemap et les réglages d'indexation
Commençons par l'accident le plus fréquent et le plus coûteux de tout l'univers WordPress : la case « Demander aux moteurs de recherche de ne pas indexer ce site », logée dans les réglages de lecture. Elle est cochée par défaut pendant le développement chez la plupart des prestataires, et le jour de la mise en ligne, entre les vérifications de contenu, les tests de formulaire et l'enthousiasme général, personne ne pense à la décocher. Le site s'affiche parfaitement, tout fonctionne, et il reste invisible. Nous avons diagnostiqué cette situation sur des sites en ligne depuis plus d'un an, dont les propriétaires s'interrogeaient sur l'inefficacité de leur référencement. C'est la première chose que nous regardons en ouvrant un dossier, avant même le premier café, et cela prend quinze secondes.
Le fichier robots que WordPress génère virtuellement est volontairement minimal, et c'est très bien ainsi. Les erreurs viennent de ce que l'on y ajoute. Bloquer l'accès aux répertoires du cœur ou du thème empêche le moteur de charger les feuilles de style et les scripts nécessaires au rendu de la page, et il évalue alors un site cassé. Bloquer le dossier des médias empêche l'indexation des images, ce qui prive de tout un canal de visibilité. Surtout, il faut comprendre une distinction que presque personne ne maîtrise : interdire l'exploration d'une adresse n'est pas demander sa désindexation. Une page bloquée dans le fichier robots ne peut pas être lue, donc la directive de non-indexation qu'elle contient ne sera jamais vue, et l'adresse peut rester dans l'index sans description. Pour retirer une page, il faut la laisser accessible et lui poser une directive de non-indexation ; on ne bloque l'exploration que pour économiser du budget sur des zones sans valeur, comme les paramètres de filtre ou la recherche interne.
Un seul plan de site, et seulement des adresses qui méritent d'y être
WordPress produit nativement un plan de site XML, et toutes les extensions de référencement en produisent un également. En laisser deux actifs simultanément crée deux inventaires potentiellement contradictoires : il faut en désactiver un, et à peu près toujours le natif, car celui de l'extension respecte les directives d'indexation que vous avez posées. Un bon plan de site ne contient que des adresses qui répondent correctement, qui sont canoniques d'elles-mêmes et que vous souhaitez voir indexées. Il ne contient donc ni les pages de remerciement, ni les mentions légales si vous les excluez, ni les archives que vous avez décidé de sortir de l'index, ni les adresses redirigées. Les dates de dernière modification qu'il déclare doivent être exactes : un plan qui prétend que trois cents pages ont été modifiées hier alors que rien n'a bougé perd toute valeur d'indication.
Restent deux réglages spécifiquement WordPress que nous vérifions systématiquement. Les pages de pièce jointe, d'abord : le CMS crée par défaut une page publique pour chaque fichier envoyé dans la médiathèque, contenant l'image et à peu près rien d'autre. Sur un site de trois mille médias, cela fait trois mille pages sans contenu, indexables, qui diluent tout. Les versions récentes redirigent ces pages vers le fichier lui-même et les extensions de référencement proposent toutes le réglage, mais il faut s'assurer qu'il est actif — et vérifier, sur un site ancien, ce qui a déjà été indexé. La recherche interne ensuite : chaque requête tapée produit une adresse unique, et laisser ces adresses indexables revient à autoriser n'importe qui à créer des pages sur votre domaine. Ces deux réglages prennent une minute et évitent des mois de nettoyage. Le reste du travail d'indexation se pilote dans la Search Console, dont le rapport de couverture indique adresse par adresse ce que le moteur a retenu, écarté, et pour quel motif — un rapport que nous exploitons ligne à ligne au démarrage de chaque accompagnement.
Questions fréquentes
Faut-il quitter WordPress pour être mieux référencé ?
Dans l'immense majorité des cas, non. Le CMS n'est presque jamais la cause d'un mauvais référencement : les vraies causes sont un thème surchargé, un parc d'extensions jamais élagué, des images envoyées sans traitement, des archives indexées qui diluent, et surtout un contenu qui ne répond pas aux questions que se posent vos clients. Changer de plateforme déplace le problème en ajoutant une migration à risque, un coût de reconstruction et une perte de compétence interne. Nous conseillons de quitter WordPress dans deux situations seulement : un besoin fonctionnel que le CMS ne couvre réellement pas, ou une installation tellement compromise et bricolée que la remise en état coûterait plus cher qu'une reconstruction propre.
Yoast, Rank Math ou SEOPress : laquelle choisir ?
Les trois couvrent le même socle : titres et méta-descriptions avec modèles, directives d'indexation, balise canonique, plan de site XML, fil d'Ariane, données structurées de base et redirections dans les versions payantes. L'écart de performance entre elles est marginal comparé à ce que produit une bonne configuration. Prenez celle que votre équipe utilisera réellement, en tenant compte du prix des fonctions payantes qui vous intéressent et de la compatibilité avec vos autres extensions. La seule règle absolue est de n'en installer qu'une : deux extensions actives simultanément émettent des balises canoniques concurrentes, deux plans de site rivaux et des directives contradictoires, et le moteur tranche rarement en votre faveur.
Mon indicateur SEO est vert sur toutes mes pages, pourquoi je ne remonte pas ?
Parce que cet indicateur mesure la forme, pas la pertinence. Il vérifie la présence d'une expression que vous avez choisie vous-même dans le titre, l'adresse, un sous-titre et un attribut d'image, une densité située dans une fourchette arbitraire, une longueur minimale, une part de phrases longues et de voix passive. Il n'a jamais consulté les pages classées devant vous, il ignore le volume de recherche et il ne sait rien de l'intention derrière la requête. Un texte creux atteint le vert en dix minutes ; un excellent article reste orange parce qu'il emploie des synonymes. Traitez-le comme une liste de vérification de mise en forme, et jugez vos pages sur ce qu'elles apportent de plus que les concurrentes.
Puis-je changer la structure de mes permaliens maintenant ?
Vous le pouvez techniquement en trois clics, et c'est précisément le danger. Modifier ce réglage change simultanément l'adresse de tous vos contenus, y compris ceux qui sont indexés depuis des années et ceux qui reçoivent des liens depuis d'autres sites. Sans préparation, vous perdez l'historique de chaque page. L'opération se mène comme une migration : inventaire exhaustif des adresses existantes, table de correspondance ligne à ligne, redirections permanentes en un seul saut, réécriture des liens internes stockés en base, resoumission des plans de site et surveillance sur six à huit semaines. Faite ainsi, la perte est transitoire. Si votre structure actuelle est simplement perfectible mais lisible, l'opération ne vaut souvent pas son coût.
Combien d'extensions est-ce trop ?
La question du nombre est un mauvais indicateur : dix extensions bien écrites et entretenues pèsent moins que trois extensions mal conçues. Ce qui compte est ce que chacune ajoute réellement à chaque affichage de page — requêtes en base, feuilles de style et scripts chargés partout, appels à des serveurs extérieurs, tâches planifiées déclenchées par la visite d'un internaute. Nous menons donc un inventaire plutôt qu'un comptage : pour chaque extension, ce qu'elle fait, où cela se voit sur le site public, la date de sa dernière mise à jour et l'activité de son auteur. Les extensions dont plus aucune trace n'apparaît côté visiteur partent en premier, une par une, avec une sauvegarde restaurable.
Faut-il désindexer les catégories et les étiquettes de mon blog ?
La décision se prend famille par famille, pas en bloc. Une page de catégorie peut être excellente si vous la travaillez : un titre pensé pour une requête réelle, un texte d'introduction substantiel, un ordre d'affichage éditorial et des liens vers les contenus de référence de la rubrique. Ainsi construite, elle se positionne souvent mieux que les articles qu'elle liste. Laissée par défaut, avec pour tout contenu le nom de la rubrique et une liste d'extraits, elle n'apporte rien et vaut mieux hors de l'index. Les étiquettes, elles, sont désindexées dans la quasi-totalité des cas, sauf regroupement transversal réellement construit et alimenté d'un contenu propre. Les archives d'auteur et de date se désactivent presque toujours.
Mon site a été piraté. Vais-je perdre mon référencement ?
Cela dépend surtout du délai de détection. Une compromission repérée en quelques heures et nettoyée proprement laisse peu de traces. Une injection restée en place plusieurs semaines, avec des centaines de pages de spam générées et servies au robot mais invisibles pour vous, produit un avertissement dans la Search Console, parfois la mention indiquant que le site peut être piraté, et une chute nette. Le nettoyage n'est que la première moitié du travail : il faut ensuite faire renvoyer une absence franche aux adresses parasites, demander leur retrait, corriger les plans de site, vérifier les comptes administrateurs créés à votre insu, et solliciter un examen si une action manuelle a été notifiée. Le rétablissement complet demande de quelques semaines à plusieurs mois.
Un hébergement mutualisé suffit-il pour être bien référencé ?
Pour un site vitrine d'une quinzaine de pages, quelques centaines de visiteurs par jour et une publication mensuelle, une offre mutualisée sérieuse avec une version récente de PHP fait parfaitement l'affaire. Les limites apparaissent ailleurs : la ressource processeur est partagée, donc la charge d'un voisin dégrade votre temps de réponse à des moments que vous ne contrôlez pas ; le nombre de processus PHP simultanés est plafonné, si bien qu'un pic de trafic ou le passage soutenu d'un robot fait apparaître des erreurs que le moteur enregistre ; le cache d'objets en mémoire est rarement disponible ; et vous n'avez ni journaux serveur, ni ligne de commande, ni environnement de test. Le changement se justifie quand le site porte réellement votre chiffre d'affaires.
Reprendre la main sur votre WordPress, avec un seul interlocuteur
Facem Web est une agence web et SEO indépendante née à Arras en décembre 2012, avec une seconde implantation à Lille et des clients partout en France, de Dunkerque à Marseille. Nous travaillons WordPress depuis le premier jour, ce qui représente aujourd'hui une somme d'expérience assez précise sur la manière dont ces sites vieillissent, se dégradent et se remettent d'aplomb. Nous développons des thèmes sur mesure et des thèmes enfants, nous reprenons des installations surchargées par des années d'interventions successives, et nous accompagnons dans la durée des artisans, des industriels, des cabinets libéraux et des PME qui ont besoin que leur site produise des demandes plutôt que des compliments. La particularité de notre organisation tient en une phrase : les compétences sont réunies chez le même interlocuteur, du développement à la rédaction, du référencement à l'acquisition payante, si bien que vous n'avez jamais à arbitrer entre trois prestataires qui se renvoient la responsabilité d'un problème.
Une reprise d'installation commence toujours par un état des lieux complet, parce qu'on ne répare pas ce qu'on n'a pas mesuré : version du cœur et de PHP, inventaire du thème et des extensions avec leur activité réelle, état de l'indexation et des directives, structure des adresses et héritage des redirections, poids et format des médias, chaîne de cache, journaux du serveur, données structurées, maillage, et confrontation entre les requêtes que vous visez et celles qui vous apportent effectivement des impressions. À la sortie, vous obtenez une liste ordonnée : ce qui doit être corrigé cette semaine parce que cela vous coûte du trafic tous les jours, ce qui relève d'un chantier planifié, et ce qui n'a aucune importance malgré ce qu'affichent les outils automatiques. Cette hiérarchie est l'essentiel de la valeur — un export de crawl remonte quatre cents anomalies, et une petite dizaine seulement explique vos résultats.
Nous menons ensuite l'exécution ou nous la confions à votre équipe, selon vos moyens et vos préférences, avec la même exigence dans les deux cas. Le référencement d'un WordPress ne se limite d'ailleurs jamais à la technique : il suppose de produire des pages qui répondent réellement aux questions de vos clients, de structurer l'ensemble en regroupements cohérents, et de construire de l'autorité vers ce site. Sur ce dernier point, nous sommes directs : le netlinking occupe une place centrale dans notre travail, nous construisons ces liens activement en pilotant la qualité des domaines, la cohérence thématique et le rythme d'acquisition, et nous vous exposons le risque associé avant de vous y engager. Si votre besoin porte d'abord sur la visibilité et non sur le CMS, un consultant en référencement peut prendre le sujet directement.
La manière la plus efficace d'avancer consiste à nous donner un accès en lecture à votre WordPress et à votre Search Console, puis à nous dire ce que vous vendez, à qui, et ce que vous attendez du site dans les douze prochains mois. Nous vous dirons ce qui bloque, dans quel ordre le traiter, ce que cela représente en budget et en délai, et ce qui peut attendre. Et s'il apparaît qu'un nettoyage ciblé de trois jours suffit à débloquer votre situation, nous vous le dirons aussi, même si cela nous conduit à vous facturer beaucoup moins que ce que vous étiez venu chercher.