Ce guide est écrit pour un responsable marketing ou un webmaster solo qui gère un site WordPress de 30 à 300 pages sans équipe technique. Vous y trouverez les contrôles, leurs seuils et un ordre de correction basé sur l'impact attendu, pas sur l'ordre d'un rapport.
Le parcours
Les étapes de cette page, dans l’ordre.
-
01 Accès des robots Vérifier que rien ne bloque Google avant de chercher plus loin.
-
02 Indexation Confronter ce que Google a réellement indexé à ce que vous attendez.
-
03 Performance Mesurer les Core Web Vitals sur mobile, page par page.
-
04 Balises et contenu Contrôler titres, méta descriptions, H1 et corps des pages clés.
-
05 Maillage et dette technique Traiter les liens internes cassés, plugins inactifs et tables résiduelles.
-
06 Prioriser Classer les corrections par impact et effort, puis exécuter par lots.
01 / 12
À quoi sert un audit SEO WordPress et quand le lancer ?
Un audit SEO WordPress sert à identifier ce qui empêche réellement Google de comprendre, d'indexer et de bien classer vos pages, et à décider quoi corriger en premier.
Un audit SEO WordPress ne se lance pas par curiosité : il se déclenche quand quelque chose bouge. Une refonte ou un changement de thème, une chute de trafic organique, la reprise d'un site que vous n'avez pas construit, ou une baisse nette des positions sur des pages qui convertissaient. Dans ces quatre cas, vous avez besoin de savoir ce qui casse, pas de contempler un tableau de bord.
Car un audit n'est pas un inventaire. Il se termine par une liste courte de corrections classées, pas par un rapport interminable que personne n'appliquera. Sur WordPress, retenez ceci : la moitié des problèmes viennent des réglages natifs et des plugins, pas du contenu. L'audit doit donc regarder les deux, et vous dire par quoi commencer.
02 / 12
Comment vérifier que Google peut accéder à votre site ?
Le premier contrôle d'un audit SEO WordPress est le réglage de visibilité pour les moteurs, suivi du robots.txt et du sitemap, car un seul blocage rend tous les autres contrôles inutiles.
Le piège classique tient à une seule case dans Réglages > Lecture : « Demander aux moteurs de recherche de ne pas indexer ce site ». Cochée par le développeur au moment de la mise en ligne, elle survit à la mise en production, et votre site reste absent de Google. Donc commencez par là.
Ensuite, ouvrez votre-site.fr/robots.txt : une directive Disallow: / bloque tout le site, cherchez-la ; le fichier doit par ailleurs indiquer votre sitemap. Quant au sitemap généré par le plugin SEO, vérifiez qu'il déclare vos pages et articles utiles, car les archives de dates, d'auteurs et les pièces jointes y ajoutent du bruit que Google explore pour rien.
Réglage de visibilité
Vérifiez Réglages > Lecture : la case d'indexation doit être décochée. Contrôlez aussi qu'aucune balise noindex n'a été posée par un plugin sur l'ensemble du site.
Robots.txt
Ouvrez votre-site.fr/robots.txt : aucune règle Disallow: / globale ne doit bloquer l'ensemble du site, et la ligne Sitemap doit être présente.
Sitemap
Ouvrez le sitemap déclaré et vérifiez qu'il contient vos pages et articles, sans archives de dates, d'auteurs ni pages de pièces jointes.
HTTPS et redirections
Vérifiez qu'une seule version du domaine répond (avec ou sans www) et que tout le trafic HTTP redirige vers HTTPS en une seule redirection.
Pages en noindex volontaire
Listez les pages que vous avez volontairement mises en noindex (mentions légales, pages de remerciement) pour ne pas les confondre avec des erreurs.
Pour approfondir
Si Search Console vous annonce plus d'URLs que vous n'avez de pages, ce n'est pas une erreur : c'est WordPress qui travaille pour vous, mais pas dans le bon sens.
URLs WordPress indésirables
Concept
Les URLs WordPress qui polluent l'index
Un blocage robots.txt sur ces URLs ne les retire pas de l'index : il empêche seulement Google de les relire, donc de constater le noindex. La page reste indexée, parfois pendant des mois.
Prenons une PME avec 40 pages de contenu réel. Dans le rapport Pages de Search Console, elle découvre 310 URLs indexées. L'explication tient rarement à un piratage : WordPress, dès l'installation, expose des familles d'URL que personne n'a demandées. Les archives d'auteurs (/author/nom) existent pour chaque compte, même si un seul rédacteur publie. Les archives de dates (/2024/03/) s'empilent mois après mois. Et chaque image importée crée sa propre page de pièce jointe (/nom-image/), indexable comme n'importe quel article. Neutralisez ces réglages, et l'index retombe à 52 URLs, toutes utiles.
Le mécanisme est simple : ces pages ne sont pas des erreurs, ce sont des vues générées automatiquement par le CMS. Une archive d'auteur qui liste trois titres n'apporte aucune information que la page d'accueil ou la catégorie n'apporte déjà. Multipliée par quatre comptes et six ans d'historique, elle consomme du budget de crawl, cette quantité de pages que Google accepte d'explorer sur votre site à chaque passage. Moins de pages inutiles, c'est plus de temps passé sur vos pages qui comptent.
Le cas des catégories et des étiquettes est différent, et c'est là que l'audit demande du jugement. Une archive de catégorie travaillée, avec un texte d'introduction, un maillage interne cohérent et des extraits choisis, peut devenir une page d'atterrissage utile. La même archive qui affiche une simple liste d'extraits n'apporte rien. La règle tient donc à l'état réel de la page, pas à son type : on neutralise ce qui est vide, on garde et on enrichit ce qui est travaillé.
Une fois corrigé, rien n'est immédiat. Google doit repasser, constater le noindex, puis retirer l'URL de son index. Cela se compte en semaines, pas en jours. Le rapport de couverture de Search Console est le tableau de bord à suivre : le nombre d'URLs indexées doit baisser progressivement. Si rien ne bouge après plusieurs passages, vérifiez qu'un blocage robots.txt ne s'est pas glissé entre-temps : c'est l'erreur qui annule tout le travail.
- Compter les URLs indexéesDans Search Console, rapport Pages : comparez le nombre d'URLs indexées au nombre de pages que vous voulez réellement voir dans Google. Un écart de plusieurs centaines signale des familles générées par WordPress.
- Repérer les motifs d'URLTriez la liste des URLs indexées par motif : présence de /author/, /tag/, /20 suivi d'une année, ou extension .jpg. Chaque motif identifié correspond à un réglage à neutraliser.
- Choisir noindex, pas DisallowPour retirer une page de l'index, posez un noindex. Un Disallow dans robots.txt empêche l'exploration mais laisse l'URL dans l'index, parfois durablement.
Pour la suiteUne fois l'accès ouvert, reste à comprendre ce que Google a réellement vu : lisez la Search Console comme un diagnostic.
03 / 12
Comment lire Search Console comme un diagnostic ?
Search Console est le seul outil qui montre ce que Google a réellement indexé et sur quelles requêtes votre site apparaît, ce qu'aucun plugin SEO ne peut deviner.
Votre site est un vaste ensemble d'URLs. Le rapport Pages de Search Console sépare celles que Google a indexées de celles qu'il a exclues. Un motif comme « explorée non indexée » ou « doublon sans URL canonique choisie par l'utilisateur » vous dit la nature du problème : pas une pénalité, un signal technique à corriger.
Le rapport Performances, lui, ne se juge pas sur une semaine. Lisez-le sur trois mois minimum et filtrez par type de recherche Web : sans ce filtre, vous mélangez Discover et recherche classique, et les courbes racontent une histoire fausse.
Les quatre rapports Search Console à ouvrir pendant un audit WordPress
| Rapport | Ce qu'on y cherche | Signal d'alerte |
|---|---|---|
| Pages | URLs indexées vs exclues, motifs d'exclusion | Des pages importantes classées « Explorée, non indexée » |
| Performances | Requêtes, pages, pays, appareils sur 3 mois | Des impressions sur des requêtes hors sujet (archives, auteurs) |
| Sitemaps | Sitemap lu, date de lecture, URLs découvertes | Sitemap non lu depuis plusieurs semaines |
| Expérience sur la page (mobile) | URLs jugées « médiocres » ou « mauvaises » | Des pages clés en dessous du seuil « bon » |
Les quatre rapports Search Console qu'un audit SEO WordPress doit ouvrir, et le signal qu'on y cherche.
Pour approfondir
Le rapport d'exclusion fait peur par son volume, pas par son contenu : apprenez à trier les motifs avant de toucher à quoi que ce soit.
Motifs d'exclusion
Méthode
Lire les motifs d'exclusion sans se tromper
Sur un rapport d'exclusion, la majorité des URLs signalées n'appellent aucune correction : seul un petit sous-ensemble de motifs mérite votre temps.
Prenez un site de 120 articles dont le rapport Pages affiche 340 URLs exclues. En regroupant par motif, la répartition éclaire tout : 210 relèvent de « Autre page avec balise canonique », 90 de « Explorée, actuellement non indexée » et 40 de « Page avec redirection ». La tentation est de tout traiter. En réalité, seules les 90 du deuxième groupe demandent un travail de contenu : les 210 signalent simplement qu'une autre URL a été déclarée comme version de référence, ce qui est souvent le comportement attendu.
Chaque motif a sa logique. « Explorée, actuellement non indexée » signifie que Google a vu la page et a choisi de ne pas l'indexer, fréquemment par manque de contenu unique ou parce qu'elle ressemble à une autre. « Détectée, actuellement non indexée » est différent : Google connaît l'URL mais n'a pas encore mobilisé le budget de crawl nécessaire, cas courant sur un gros site récent. Confondre les deux fait perdre des heures sur des pages qui n'ont besoin que de patience.
D'autres motifs sont volontaires. « Exclue par la balise noindex » correspond le plus souvent à un choix : pages de remerciement, résultats de recherche interne. On ne corrige que si la page devait réellement être indexée. « Page avec redirection » et « Introuvable (404) » se traitent uniquement quand l'URL reçoit encore des liens internes ou des clics ; sinon, on les ignore. La règle de tri tient en une phrase : ne travaillez que les motifs touchant des pages à potentiel de trafic, jamais le rapport entier.
Cette méthode a une limite : elle suppose que vous savez quelles pages ont un potentiel. Sur un site sans suivi de trafic ni objectif clair, le tri par motif devient arbitraire et vous risquez de corriger des pages décoratives en laissant de côté des pages utiles. Le rapport d'exclusion est un outil de diagnostic, pas une liste de tâches : il ne dit pas où se trouve la valeur de votre site.
- Filtrer par motifRegroupez les URLs exclues par motif d'exclusion pour traiter des familles entières d'un coup, au lieu de page par page.
- Comparer avec le sitemapUne page présente dans le sitemap et exclue de l'index est un signal plus fort qu'une page absente des deux.
- Vérifier les datesUn rapport d'exclusion peut dater d'avant une correction : comparez la date de dernière exploration à la date de votre correctif.
04 / 12
Combien coûte un audit SEO WordPress ?
Un audit SEO WordPress se situe le plus souvent entre 800 et 3 500 euros selon la taille du site et la profondeur du travail, avec une part de ce coût qui peut être absorbée si vous réalisez vous-même la phase de collecte.
Le prix d'un audit dépend d'abord de ce qu'il y a à regarder : le nombre d'URLs et le nombre de modèles de pages, article, page, fiche produit, car chacun demande une lecture distincte. Ajoutez la présence ou non d'une phase de mise en œuvre, et l'écart de tarif s'explique sans mystère.
Méfiez-vous donc d'un audit facturé très bas : c'est presque toujours un rapport d'outil automatique, utile pour la collecte mais insuffisant pour décider. Le tarif reste un ordre de grandeur de marché : demandez un devis écrit qui précise le périmètre, le livrable et le délai.
Pour approfondir
Un rapport épais n'est pas forcément un rapport utile. Voici comment lire celui qu'on vous livre, ligne par ligne, avant de payer la suite.
Cadrer un prestataire
Méthode
Grille de lecture d'un rapport d'audit fourni par un prestataire
Un rapport d'audit se juge au nombre de recommandations qui citent une URL précise : c'est le seul indicateur difficile à fabriquer sans avoir ouvert vos pages.
Une PME reçoit un rapport de soixante pages : quarante-cinq de captures d'outils, dix de recommandations générales, cinq de plan d'action. Elle demande une version condensée, en exigeant pour chaque anomalie l'URL concernée, l'impact estimé et l'effort de correction. Le prestataire revient en trois jours avec quatorze lignes exploitables. Le volume n'avait pas disparu : il avait été remplacé par ce qui se décide réellement.
Un rapport excellent sur un périmètre flou ne vous dit pas ce qui reste dehors. Puis vient l'estimation d'impact : le trafic potentiellement concerné ou le nombre de pages touchées a plus de valeur qu'une étiquette « critique » posée sans mesure.
L'effort de correction doit être écrit noir sur blanc : qui peut le faire, vous, un développeur ou un rédacteur, et combien de temps cela prend. Sans cette colonne, le plan d'action reste une liste qui suit l'ordre du crawl, pas un ordre de traitement. Un rapport honnête précise aussi ce qu'il ne couvre pas, rédaction, netlinking ou refonte graphique, pour éviter les malentendus au moment de la facture.
Dernier point, souvent oublié : les accès. Search Console et les exports qui ont servi à l'audit doivent rester les vôtres, y compris après la fin de la mission. Un rapport dont vous ne pouvez pas rejouer les mesures vous rend dépendant de celui qui l'a produit.
- Anomalies ou généralitésRelisez chaque recommandation en vous demandant si elle pourrait s'appliquer à n'importe quel site. Si oui, le rapport n'a pas été fait sur le vôtre.
- URLs citéesComptez les recommandations qui nomment une URL précise. C'est le meilleur indicateur d'un travail réel plutôt que d'un export d'outil.
- Mesure avant / aprèsCherchez la valeur de départ de chaque critère. Sans elle, vous ne pourrez pas vérifier plus tard si la correction a produit un effet.
- Propriété des donnéesVérifiez que les accès Search Console et les exports utilisés restent à votre nom et vous suivent à la fin de la mission.
05 / 12
Combien de pages de votre site posent vraiment problème ?
Sur un site WordPress de 30 à 300 pages, le nombre de pages réellement problématiques reste presque toujours sous 20 % du total : c'est ce sous-ensemble qu'il faut chiffrer et corriger en premier.
Le bon réflexe n'est pas de compter vos pages, mais de repérer celles qui reçoivent des impressions sans se placer en tête des résultats. Une page qui apparaît dans les recherches et reste loin derrière est une page à corriger, pas à créer : le contenu et la structure existent déjà, il faut les retravailler. Ce repérage sert surtout à décider du volume de travail à prévoir. Retravailler quelques pages et en reprendre des dizaines ne se planifient pas de la même façon, car le temps passé par page et la charge pour votre équipe n'ont rien de comparable. Corriger d'abord les pages qui pèsent vraiment vous évite d'ouvrir un chantier que vous ne pourrez pas suivre.
Le tri se fait selon ce que chaque correction rapporte au regard de l'effort qu'elle demande, et non dans l'ordre où votre outil d'audit vous présente les problèmes.
Exemple chiffré
Chiffrer le volume de pages à corriger
- Pages publiées sur le site
- 180 pages
- Pages avec au moins une impression sur 3 mois
- 96 pages
- Part de ces pages sous le seuil de position 20
- 35 %
-
Pages qui reçoivent des impressions95,40 pages
180 × 0,53
Sur un site de 180 pages, environ 96 reçoivent au moins une impression sur trois mois dans Search Console.
-
Pages à retravailler en priorité33,60 pages
96 × 0,35
Parmi ces pages visibles, 35 % se situent au-delà de la position 20 : elles sont indexées et connues, mais mal classées.
-
Charge de travail estimée1 530 minutes
34 × 45
À 45 minutes par page (titre, méta, structure, maillage), le lot prioritaire représente environ 25 heures de travail.
Pour approfondir
Quand on n'a que quelques heures par semaine, l'ordre du rapport d'audit ne dit pas quoi faire en premier. Voici comment trancher.
Ordre des corrections
Méthode
Prioriser par impact et effort, pas par ordre du rapport
Corrigez les redirections cassées avant de retravailler les pages. Ce travail porte sur le même volume, mais son effet se voit plus vite sur des URLs qui reçoivent encore des liens.
Prenons une TPE avec quatre heures par semaine et un audit qui remonte tout en vrac. Trois chantiers attendent : trente-quatre pages à retravailler, soixante redirections cassées héritées d'une ancienne refonte, et un thème trop lourd. Le réflexe naturel est d'attaquer la liste par le haut. Le bon réflexe est de croiser ce que chaque chantier rapporte avec ce qu'il coûte. Ici, les redirections passent devant. Deux semaines de travail suffisent à produire un effet immédiat sur des adresses qui reçoivent encore des liens. Les pages à fort potentiel suivent, par lot de huit. Le thème est reporté à un budget dédié.
Une case concentre presque tout le bénéfice immédiat, puisque l'impact est fort pour un effort faible. On y trouve les redirections cassées, les titres dupliqués, un robots.txt mal écrit, des balises canoniques mal posées. À l'inverse, impact fort et effort fort désigne la refonte de thème, le changement de plugin SEO ou la migration d'hébergement. C'est un projet, avec sauvegarde et environnement de test. Entre les deux, la reprise du contenu de dix à vingt pages qui ont déjà des impressions et des liens internes demande un effort moyen et se planifie par lots.
Deux disciplines évitent que le plan s'effondre. D'abord la règle de trois. Jamais plus de trois chantiers en parallèle sur un site de moins de trois cents pages, sinon vous ne pouvez plus relier un résultat à une action. Ensuite la case à écarter, celle où l'impact est faible et l'effort fort. Le piège est de la garder ouverte au cas où, et d'y revenir à chaque réunion. Écrivez noir sur blanc qu'elle sort du plan. Reste la case impact faible et effort faible, à traiter par lots, en fond de tâche, sans jamais lui consacrer une semaine pleine.
Ce classement a une limite, puisqu'il repose sur des mesures prises avant toute intervention. Si vous corrigez d'abord et regardez ensuite, vous ne pourrez jamais démontrer l'effet du chantier, et la discussion sur le prochain budget se fera sans preuve. Notez donc les impressions et la position moyenne des pages visées avant d'y toucher, puis laissez passer trois à quatre semaines après le déploiement d'un lot avant de juger : le temps que Google recrawle et réévalue.
- Mesure avant correctionNotez impressions et position moyenne des pages visées avant toute modification, sinon aucun effet ne sera prouvable ensuite.
- Sauvegarde et environnement de testToute correction de thème ou de plugin se teste hors production ; une sauvegarde complète avant intervention est le minimum sur WordPress.
- Un lot, une mesureAttendez trois à quatre semaines entre le déploiement d'un lot et son évaluation, le temps que Google recrawle et réévalue.
Pour la suiteQuels contrôles passer en revue avant de toucher au contenu ?
06 / 12
Quels contrôles faire avant de corriger ?
Avant de toucher au moindre réglage, quatre vérifications évitent de casser un site WordPress en production ou de perdre la trace de ce qui a été modifié.
Sans sauvegarde préalable, chaque correction devient un pari, puisque vous modifiez un réglage sans savoir à quoi ressemblait le site avant. Prenez donc le temps de figer un état de départ avant de toucher à quoi que ce soit, car c'est ce point de comparaison qui vous dira si une anomalie vient de vous ou existait déjà.
Deux vérifications suffisent à couvrir la quasi-totalité des incidents. D'abord une sauvegarde complète et récente, fichiers et base de données, avec une copie conservée hors du serveur. Une sauvegarde qui n'a jamais été restaurée ne prouve rien, donc testez la restauration avant d'en dépendre. Ensuite un environnement de test, copie du site avec sa propre base, où vous essayez un thème ou un plugin sans exposer la version en ligne. Ces contrôles vous prennent une heure, et vous évitent de casser un site en production.
07 / 12
Quels contrôles faire page par page ?
Le contrôle page par page porte sur quatre éléments vérifiables dans le code de la page : la balise title, la méta description, la présence d'un seul H1 et la structure des sous-titres.
Le contrôle page par page commence par la balise title : elle doit être unique sur tout le site, contenir la requête visée et tenir dans environ 580 pixels, car au-delà Google la tronque dans les résultats. La méta description, elle, n'est pas un facteur de classement mais joue sur le taux de clic : si vous la laissez vide, Google en génère une à votre place, souvent maladroite.
Sur un article WordPress, vous pouvez avoir un H1 de titre d'article et un H1 dans le contenu : deux H1 sur une même page n'est pas une faute grave, à condition que la hiérarchie des H2 et H3 reste lisible. Le maillage interne se contrôle dans le corps du texte : des liens contextuels vers des pages profondes valent mieux qu'un menu surchargé, car ils orientent le lecteur et les robots au fil de la lecture.
08 / 12
Quels sont les risques de la dette technique sur WordPress ?
La dette technique d'un site WordPress, plugins inactifs, thème orphelin, tables résiduelles en base, pèse sur la sécurité et la vitesse avant de peser directement sur le classement.
Installer un plugin ne se limite pas à l’activer : le code reste sur le serveur, et un plugin abandonné, faute de mises à jour, devient la porte d’entrée la plus fréquente d’une compromission WordPress. Un thème premium délaissé par son auteur ne reçoit plus de correctifs de sécurité ni de compatibilité avec les versions récentes de PHP, il vieillit au même rythme que le site.
Les extensions désactivées, elles, laissent des tables et des lignes dans la base, si bien que vos sauvegardes et vos exports s’alourdissent sans que rien ne serve. Un site compromis est ensuite déclassé ou signalé dans les résultats de recherche ; le risque SEO est réel, mais il est la conséquence d’un problème de sécurité, pas sa cause. Camille Marceau le résume en une formule, puisque la dette technique, ça se paie d’abord en sécurité.
Pour approfondir
La section explique pourquoi la dette technique coûte cher. Voici comment repérer un plugin abandonné avant la panne, avec les indicateurs publics à regarder.
Plugins abandonnés
Règle à connaître
Repérer un plugin abandonné avant qu'il ne pose problème
Un plugin qui fonctionne peut déjà être incompatible avec la version de PHP de votre hébergeur : la panne arrive au moment du passage de version, pas à l'installation.
Un site de 90 pages tourne avec une extension de formulaire fermée depuis 2019. Le formulaire fonctionne, personne ne s'en plaint. Mais l'extension s'appuie sur une fonction PHP supprimée en PHP 8.2. Le jour où l'hébergeur monte de version, toutes les pages contenant le formulaire tombent en erreur 500. Le remplacement par une extension maintenue prend une heure. La dette n'a pas coûté cher ici, mais elle aurait pu coûter un week-end de site inaccessible si le passage avait eu lieu un jour de forte activité.
Trois indicateurs publics suffisent pour anticiper. Le premier est la date de dernière mise à jour sur la fiche du plugin dans le répertoire officiel WordPress.org. Le deuxième est la compatibilité déclarée avec les trois dernières versions majeures de WordPress. Dès qu'un écart dépasse trois versions, le signal d'abandon est là. Le troisième est le nombre de versions récentes de PHP déclarées compatibles, car les hébergeurs montent régulièrement de version.
Pour les extensions premium, ces indicateurs ne sont pas dans le répertoire. La date de mise à jour et la réactivité du support sur la page officielle de l'éditeur restent les seuls éléments publics fiables. Un éditeur qui répond en quelques jours et publie des correctifs suit son produit. À l'inverse, une page de tarifs inchangée depuis longtemps et un forum muet annoncent souvent un produit délaissé.
Le rangement utile tient en une tripartition : un plugin actif sur plusieurs sites, un plugin utilisé sur un seul site, un plugin à retirer. Cette distinction évite de tout désinstaller en urgence le jour de la panne. Pour les extensions abandonnées, le plan de sortie se prépare avant l'incident : solution de remplacement identifiée, procédure d'export des données, fenêtre de test. La limite de cette méthode est qu'elle demande du temps de veille régulier, difficile à tenir seul sur un parc de sites.
- Dernière mise à jourSur la fiche WordPress.org du plugin, une mise à jour de plus de douze mois est un signal d'abandon à surveiller.
- Compatibilité PHPVérifiez la version de PHP de votre hébergement, dans la section Santé du site de l'outil d'administration, et la compatibilité déclarée des extensions actives. Un écart important annonce une panne au prochain passage de version.
- Plugins désactivésListez aussi les extensions désactivées : elles restent sur le disque et peuvent être réactivées par erreur.
- Tables résiduellesUn plugin de nettoyage de base ou une requête SQL permet de lister les tables sans préfixe correspondant à un plugin actif.
Pour la suiteLes plugins SEO détectent une partie de ces problèmes, pas tous.
09 / 12
Que détectent vraiment les plugins SEO comme Yoast, Rank Math ou SEOPress ?
Un plugin SEO comme Yoast, Rank Math ou SEOPress analyse correctement vos balises, votre lisibilité et votre sitemap, mais il ne peut pas voir la performance serveur, l'indexation réelle dans Google ni l'effet d'un thème lourd.
Un plugin SEO comme Yoast, Rank Math ou SEOPress lit votre base WordPress : il voit les balises que vous rédigez, la structure de vos titres, la longueur de vos textes et votre sitemap. Ce qu'il ne voit pas, c'est ce qui se passe après : la façon dont Google explore et indexe réellement votre site, le temps de réponse de votre serveur, le poids des scripts chargés par les autres extensions, ou les appels vers des services tiers ajoutés par votre bandeau de cookies. Il travaille sur le contenu, pas sur la performance vécue par le visiteur.
Quant à sa note de lisibilité, elle reste une heuristique interne, pas un critère de classement. Gardez-la comme garde-fou pour repérer une phrase trop longue ou un paragraphe mal construit, jamais comme preuve que la page va se positionner. L'usage juste est donc simple. Confiez au plugin la gestion des balises et du sitemap, et complétez systématiquement avec Search Console et une mesure de performance externe pour voir ce que le plugin ne peut pas voir.
10 / 12
Faut-il tout corriger soi-même ou faire appel à quelqu'un ?
La ligne de partage est simple : ce qui se règle dans l'interface WordPress se fait en interne, ce qui touche au serveur, au thème ou à la base de données se délègue ou se planifie.
Ce qui se règle dans l'interface de WordPress ne demande aucune compétence de développement : balises, descriptions, maillage interne, réglages d'indexation, nettoyage des extensions obsolètes. Vous pouvez le faire vous-même, sans dépendre de personne. En revanche, la migration, la refonte du thème, l'optimisation du serveur ou de la base de données et un plan de redirections complexe touchent à des couches que vous ne voyez pas : déléguez-les.
Ce qui suppose une refonte ou un changement d'hébergement ne se traite pas en correction quotidienne : traitez-le comme un projet, avec un budget et une fenêtre de test. Et le rapport que vous rédigez vous-même devient votre cahier des charges si vous externalisez un jour.
-
Séparer les anomalies par nature
Classez chaque point relevé en trois familles : contenu et réglages, développement et serveur, projet lourd.
-
Marquer l'impact
Pour chaque anomalie, notez le nombre de pages touchées et, si possible, les impressions Search Console concernées.
-
Décider : je corrige, je délègue, je reporte
Appliquez la règle : interface WordPress = vous ; code, serveur, base = délégation ; refonte = report planifié avec budget.
-
Regrouper en lots de trois chantiers
Assemblez les corrections en lots cohérents, sans dépasser trois chantiers en parallèle, et fixez une date de mesure pour chacun.
-
Mesurer après chaque lot
Trois à quatre semaines après déploiement, comparez les relevés initiaux : impressions, positions, résultats de performance.
11 / 12
Faut-il faire son audit SEO WordPress soi-même ou déléguer ?
Un audit SEO WordPress utile commence par vérifier ce que Google voit réellement, se concentre sur la minorité de pages qui posent problème, et se partage entre ce que vous pouvez corriger dans l'interface et ce qui doit être délégué.
La priorité n'est pas de tout contrôler, mais de contrôler dans le bon ordre. Un site dont l'accès à Google est bloqué rend inutiles tous les autres diagnostics. La visibilité pour les moteurs, le robots.txt et le sitemap passent donc avant l'analyse du contenu. Vient ensuite Search Console, seul outil capable de montrer ce que Google a vraiment indexé, là où un plugin SEO ne fait qu'analyser la base WordPress et ne peut ni mesurer la performance serveur ni voir les effets d'un thème lourd. Enfin, votre travail porte sur une fraction limitée des pages, celles qui concentrent l'essentiel des problèmes.
Côté budget et organisation, la question n'est pas de tout faire seul ni de tout confier. Ce qui se règle dans l'interface WordPress reste en interne ; ce qui touche au serveur, au thème ou à la base de données se délègue ou se planifie. Un audit professionnel a un coût, mais la phase de collecte réalisée en amont peut réduire la facture. Surtout, ne corrigez rien avant d'avoir sécurisé votre environnement. Une sauvegarde, un site en production à ne pas casser et une trace écrite des modifications évitent de transformer un problème de SEO en incident.
12 / 12
Questions fréquentes
