On a repris la main sur un WordPress e-commerce dont le LCP dépassait les 5 secondes. Le responsable n’était ni un slider jQuery mal désactivé ni un bundle CSS non minifié. C’était un plugin de vérification de liens cassés, installé depuis trois ans, silencieux, qui balayait 12 000 URLs toutes les 48 heures. La base de données ramait, le TTFB explosait à chaque cycle et personne dans l’équipe n’avait fait le lien. Voilà le vrai visage des checkers de liens cassés intégrés à WordPress : des pompes à requêtes SQL dont l’utilité SEO est largement surcotée.
Ce que ces plugins font à votre base de données
La plupart des extensions de vérification de liens cassés fonctionnent sur un principe simple : elles parcourent l’intégralité du contenu de vos articles, pages et commentaires, extraient toutes les URLs, puis envoient une requête HTTP pour chaque lien. Le tout est stocké dans des tables dédiées, souvent wp_blc_links et consorts chez le plus connu d’entre eux. Sur un site de quelques centaines d’articles, ce sont des milliers de vérifications qui s’empilent à chaque passage. Le problème, c’est que cette routine ne se contente pas de tourner tranquillement dans son coin. Elle monopolise le processeur au moment du cron, génère des écritures lourdes dans la base et, pire, certaines variantes exécutent des micro-vérifications au vol lors du chargement d’une page pour rafraîchir un statut. Résultat : à chaque visite d’une page d’administration ou même du front selon la configuration, MySQL souffre et le TTFB s’allonge.
Si vous avez déjà suivi nos retours sur l’optimisation des Core Web Vitals, vous savez que le TTFB est un signal précoce que Google observe de près. Une requête qui met 800 ms au lieu de 200 ms à cause d’une table de liens qui grossit, c’est une perte sèche de réactivité perçue et un risque de déclassement pour l’ensemble du site. Et l’ironie, c’est que cette lourdeur n’apporte quasiment aucun bénéfice mesurable en termes de classement.
L’illusion SEO : pourquoi Google s’en moque
Un lien cassé n’est pas un signal négatif en soi pour le référencement. La Search Console pourra vous alerter avec un rapport « Liens internes brisés », mais il s’agit d’une note informative, pas d’une pénalité. Google comprend qu’un lien peut temporairement renvoyer une 404 ou une erreur DNS sans que cela dévalue la page source. Ce que les moteurs mesurent en priorité, c’est la qualité de l’expérience utilisateur. Un visiteur qui tombe sur un lien mort va peut-être rebondir, ce qui envoie un mauvais signal comportemental. Mais ce risque se joue lien par lien, et une vérification en continu n’y change rien si vous ne corrigez pas le lien dans la minute. L’argument qui consiste à dire « je dois scanner toutes les heures pour préserver mon SEO » est une posture de confort, pas une nécessité technique.
Ce qui compte, c’est de repérer les liens cassés avant que vos lecteurs ne les subissent, pas de maintenir une base à jour en temps réel. Un audit mensuel ou hebdomadaire suffit dans l’immense majorité des cas. L’obsession du scan permanent est un héritage des années 2010 où l’on pensait que la moindre erreur 404 ferait fuir Googlebot. Aujourd’hui, on sait que ce robot alloue son crawl budget en fonction de signaux bien plus structurants : la vitesse des pages, la cohérence du maillage et la fréquence de mise à jour du contenu.
Les faux positifs, ce bruit qui coûte cher
Un lien marqué « cassé » par un checker automatique ne l’est pas toujours. Un pare-feu applicatif, une restriction IP, un timeout réseau un peu court ou un site externe qui bloque les requêtes HEAD suffisent à générer un statut d’échec. Votre tableau de bord se remplit alors d’alertes rouges pour des liens parfaitement valides. On a vu des équipes passer des heures à vérifier manuellement des centaines de faux positifs parce que le plugin n’interprétait pas un code 403 comme temporaire. Cette charge cognitive, sans même parler de l’impact serveur, coûte plus cher que le problème qu’elle prétend résoudre.
Passer à un audit externe : la méthode qui ne ralentit rien
La solution la plus immédiate consiste à déporter la vérification hors de WordPress. Des logiciels comme Screaming Frog ou Sitebulb, exécutés depuis votre machine ou un serveur dédié, analysent l’intégralité du site en quelques minutes sans solliciter le moindre cycle CPU de votre hébergement. Vous obtenez un rapport complet des erreurs 4xx et 3xx, exportable, filtrable, et vous pouvez programmer ces audits de manière ponctuelle. Le site reste léger, le TTFB ne bouge pas et vous gardez la main sur la fréquence d’analyse sans qu’un cron interne ne s’emballe.
Cette approche présente un autre avantage : vous pouvez coupler le crawl de liens avec une analyse de performance. Un même outil vous remonte les pages lentes, les chaînes de redirections et les liens internes cassés en une seule session. L’économie de temps est réelle et vous évitez d’empiler trois plugins pour trois tâches différentes.
Scripter sa vérification avec un cron maison
Si vous préférez automatiser sans dépendre d’une application graphique, un script sur mesure est la voie la plus efficiente. Un simple fichier PHP ou Python exécuté par un cron externe peut se connecter au dump de contenu de la base WordPress, extraire les URLs, leur appliquer un curl -I équivalent et logger les erreurs. Le script ne tourne pas sur le serveur de production au moment des pics de trafic, il s’exécute à une heure creuse et dépose un rapport lisible. Quand on conçoit ce type de petit outil, la logique de gestion d’état des vérifications peut rappeler celle d’une app front avec Zustand : une boucle asynchrone, un store interne et une interface de restitution. Avec les LLM modernes, écrire ce script prend moins de temps que configurer un plugin.
D’ailleurs, en comparant les environnements de développement, vous pouvez parfaitement générer ce code avec Claude Code ou Cursor en décrivant le besoin en langage naturel. On arrive à un script opérationnel en quelques itérations, testé sur un staging avant mise en production. L’avantage, c’est la transparence totale : vous savez exactement ce que fait chaque ligne et vous n’ajoutez aucune surcouche opaque dans votre installation WordPress.
Adapter WordPress pour se passer du plugin
Si vous tenez à une vérification intégrée, limitez son périmètre de manière drastique. Désactivez le scan automatique et lancez-le manuellement une fois par mois depuis l’interface. Pensez aussi à réduire le nombre d’entrées conservées en base : certains plugins gardent un historique inutile de tous les liens jamais scannés, même ceux des articles supprimés. Un petit coup de wp db optimize et une purge des tables orphelines redonne de l’air.
Enfin, regardez votre fichier robots.txt et vos logs serveur. Parfois, un checker de liens internes va trigger des centaines de requêtes sur des URLs bloquées ou protégées, générant une boucle d’erreurs inutile. Couper le scan automatique règle aussi ce problème.
Questions fréquentes
Est-ce que désactiver mon plugin de liens cassés va dégrader mon SEO ?
Non. Ce que Google mesure, c’est la présence de liens fonctionnels au moment où il crawl. Si vous corrigez les liens cassés de manière réactive, avec un audit mensuel, le robot ne verra qu’un site propre. Le vrai risque pour votre SEO, c’est un TTFB dégradé en continu à cause du plugin, pas une erreur 404 passagère.
Puis-je utiliser un service SaaS de vérification de liens externes sans impact ?
Oui, des outils comme Ahrefs ou Semrush proposent des crawls périodiques qui n’utilisent pas vos ressources serveur. Ces services se comportent comme un visiteur supplémentaire, sans alourdir votre base de données. L’inconvénient est le coût, mais l’absence d’impact sur les Core Web Vitals rend la solution pertinente pour les sites à fort trafic.
Un lien cassé fait-il perdre du PageRank ?
Pas directement. Le PageRank circule via les liens valides. Un lien cassé rompt la chaîne de transmission et le flux s’arrête là, mais cela n’affecte pas le PageRank déjà acquis par la page source. Ce qui importe, c’est que vos pages importantes ne pointent pas vers des erreurs 404 qui dégradent l’expérience utilisateur.
