Quand on parle de “désinfection” WordPress, on imagine souvent des fichiers piratés, des pages créées de nulle part, des redirections mystérieuses. C’est parfois vrai. Mais dans beaucoup de cas, le problème le plus discret et le plus pénible, ce sont les liens cachés injectés dans le contenu. Ils peuvent être minuscules, invisibles à l’œil nu, et surtout difficiles à attribuer à une cause unique.
Je l’ai vu sur des sites qui avaient l’air “propres” en surface, avec des thèmes et extensions à jour, aucune nouvelle page publique, et pourtant un motif récurrent: du SEO qui dégringole, des alertes dans des outils web, et un comportement bizarre sur certains navigateurs. Le diagnostic finissait toujours par tomber sur des liens noyés dans le HTML, parfois en couleur identique au fond, parfois via des caractères invisibles, parfois via des blocs qui ne s’affichent pas en conditions normales.
Ce guide explique comment repérer ces liens cachés, comment s’assurer qu’on les enlève vraiment, et surtout comment éviter de refaire le même nettoyage deux fois.
À quoi ressemblent ces liens “cachés” ?
Le terme “liens cachés” recouvre plusieurs techniques. L’objectif reste le même: insérer un lien sortant vers un domaine tiers, souvent dans un article ou une page déjà existante, sans déclencher immédiatement l’alarme côté visiteur. L’attaquant veut du trafic ou un bénéfice SEO, et il ne veut pas que l’éditeur du site voit ce qui s’est passé.
Sur WordPress, ces liens se trouvent fréquemment dans le contenu posté, mais ils peuvent aussi apparaître dans des fragments injectés via:
- du HTML inséré dans la zone de contenu (éditeur classique, blocs, shortcodes), des champs inattendus (champs personnalisés, métadonnées affichées via hooks), des shortcodes malveillants qui affichent ensuite le lien, des attributs modifiés dans le rendu (styles CSS, balises spans, classes).
Ce que j’ai constaté le plus souvent, ce sont des liens qui restent dans le code source, mais qui ne s’affichent pas dans le rendu final. Par exemple, un lien peut être “caché” en utilisant une règle CSS comme une couleur identique au fond, une taille de police minuscule, ou un texte rendu transparent. Dans d’autres cas, le lien est déclenché par un script discret ou par des iframes, mais on retombe alors sur une injection plus “visible”.
Le piège, c’est que l’éditeur WordPress peut afficher le contenu “normal” alors que le front-end expose un HTML différent. Autrement dit, le contenu affiché en back-office n’est pas une preuve suffisante.
Pourquoi WordPress laisse passer ça ?
WordPress est fait pour être flexible. Cette flexibilité devient un point d’entrée. Quelques raisons reviennent tout le temps:
1) Les filtres de WordPress ne couvrent pas tous les cas. Certains champs, shortcodes, blocs et zones peuvent laisser passer des portions de HTML si la configuration ou des plugins modifient le rendu.
2) Des rôles trop permissifs. Un compte compromis, même “éditeur” ou “auteur”, peut insérer du contenu qui passe, surtout si des plugins de page builder sont présents.
3) Des plugins ou thèmes qui contournent l’édition sécurisée. Certains affichent du contenu avec des fonctions qui neutralisent mal le HTML, ou qui injectent des “templates” côté front.
4) Une cache mal maîtrisée. Après un premier nettoyage, un ancien rendu peut persister dans le cache du serveur, un CDN ou même dans un cache de plugin. Résultat: vous cherchez un lien dans la base, vous le retirez, mais il réapparaît sur le front. Ça fait perdre un temps énorme.
Quand vous attaquez le nettoyage, vous devez donc raisonner en “chaîne”, pas en “point unique”: compte compromis, insertion dans le contenu, rendu front, cache.
Les étapes de diagnostic avant de supprimer quoi que ce soit
Avant de “désactiver et supprimer”, prenez cinq à dix minutes pour cadrer le problème. Ça évite d’effacer une information utile et ça réduit le risque de casser le site.
La première étape, c’est de comparer ce que vous voyez dans le back-office et ce que le navigateur reçoit. Ouvrez une page touchée, puis inspectez le code source et le DOM. Cherchez:
- des URL externes inhabituelles, des balises qui semblent “hors contexte” dans l’article, des classes ou styles qui ne correspondent pas au thème, des textes invisibles, par exemple une structure “spacer” minuscule ou des caractères Unicode bizarres.
Ensuite, vérifiez dans la base et dans le rendu s’il y a un motif récurrent. Sur beaucoup de sites, le lien malveillant pointe vers le même domaine, avec la même forme d’URL et parfois des paramètres cohérents. Cette cohérence vous aide à identifier l’origine dans WordPress.
Enfin, inspectez les logs d’accès et les événements de sécurité si vous en avez. Vous cherchez des indices comme un compte récemment utilisé, des pics d’édition, ou des requêtes vers des endpoints “non habituels”. Même si ça ne donne pas la preuve finale, ça réduit le nombre d’hypothèses.
Repérer les liens cachés dans l’éditeur et le contenu
Selon la configuration, les liens cachés peuvent être stockés dans différents endroits. Le symptôme le plus courant est simple: l’éditeur ne “voit” rien, mais le front montre un lien.
Pour vérifier, cherchez dans:
- les pages et articles concernés (contenu stocké), les extraits “renderisés” par des blocs, les champs personnalisés si votre thème les affiche, les shortcodes si un plugin les gère.
Là où je recommande d’être méthodique, c’est de ne pas vous limiter à la page sur laquelle le problème est visible. Si vous retirez un lien dans une seule page, vous risquez de rater la même injection dans d’autres contenus ou dans des templates.
Voici une approche courte et pragmatique pour gagner du temps sans faire une chirurgie risquée.
Mini check list de vérification (à faire sur une page touchée)
- Ouvrir la page publique et repérer l’élément suspect dans le DOM (bouton droit puis inspecter). Rechercher l’URL cible ou un mot unique dans le HTML rendu (Ctrl+F dans la page). Comparer avec le contenu de l’article dans WordPress (mode texte ou aperçu des blocs). Vérifier si le lien apparaît dans plusieurs pages qui utilisent le même gabarit ou la même source de contenu. Désactiver temporairement le cache (plugin et serveur) si vous en avez un, pour confirmer l’effet réel du nettoyage.
Cette étape n’a l’air “que” technique, mais elle évite une erreur classique: nettoyer la mauvaise couche.
Nettoyage: enlever les liens cachés sans abîmer la publication
Le nettoyage se joue à deux niveaux: supprimer le lien dans le contenu, et empêcher son retour via la cause racine. Les liens cachés sont parfois la conséquence d’un plugin compromis, parfois celle d’un compte compromis, parfois celle d’une modification sur un modèle d’affichage.
1) Mettre le site en mode “calme” le temps d’agir
Avant d’éditer ou de remplacer du contenu, je coupe court aux modifications concurrentes. Si vous avez une équipe, annoncez une fenêtre d’intervention. Sinon, gardez au minimum le site en maintenance ou restreignez l’accès à l’admin si c’est possible.
Pourquoi? Parce que si la cause est active, un nouveau lien peut être réinjecté pendant que vous nettoyez. Et vous perdez alors l’historique de ce que vous avez déjà supprimé.
2) Retirer le lien dans le contenu là où il est réellement stocké
Une fois que vous avez identifié le contenu exact, retirez la portion HTML ou le bloc qui porte le lien. Sur WordPress, ça peut être:
- un bloc Gutenberg contenant du HTML, un paragraphe avec une balise ajoutée, un champ de type “texte” injecté via un builder, ou un shortcode qui génère ensuite un rendu.
Le choix de suppression dépend du format. Si vous supprimez uniquement la partie visible mais que le shortcode malveillant reste, le lien revient au prochain affichage.
Dans les cas “classiques”, l’attaquant insère une balise a ou une URL dans un bloc. Une suppression simple peut suffire. Dans les cas plus vicieux, il insère un conteneur avec un style pour masquer le texte, mais la structure contient quand même l’URL. Le nettoyage doit enlever l’URL et la structure qui la porte.
3) Nettoyer aussi les zones “cachées” qui ne sont pas l’article
Je me suis déjà fait piéger par des thèmes qui affichent certains champs personnalisés. Le lien n’était pas dans le contenu, il était stocké dans un champ, puis rendu automatiquement sur le front.
C’est pour ça que, quand vous trouvez un motif, vous devez chercher le même motif ailleurs. Par exemple, si l’URL cible apparaît une fois dans une page, elle peut aussi se retrouver:
- dans un champ d’options, dans un extrait généré automatiquement, dans un widget, dans une configuration d’un plugin d’optimisation ou d’accessibilité.
La désinfection réussie n’est pas “un article propre”. C’est “un site qui ne réinjectionne plus”.
Gérer le cas des shortcodes et des blocs compromis
Les shortcodes sont souvent des responsables indirects. Un shortcode peut être déclaré dans le thème ou un plugin. Ensuite, il peut afficher du HTML non désiré, parfois sans que le contenu “montre” tout.
Le symptôme typique, c’est quand le contenu semble “normal” mais que le rendu final contient un lien qui ne correspond pas à ce que vous avez écrit.
Dans ce cas, vous avez deux voies:
- identifier où le shortcode est défini, et révoquer sa capacité à générer le rendu.
Je recommande de vérifier d’abord dans les fichiers du thème et des plugins actifs. Si un shortcode inattendu existe, et qu’il renvoie une URL vers un domaine suspect, vous tenez une piste. Puis vous remettez le fichier dans un état sain.
Attention: ne “nettoyez” pas à moitié. Si vous commentez une ligne mais que le reste reste exploitable, l’attaquant peut s’adapter.
Désactiver la cause racine: comptes, permissions, plugins
En pratique, le nettoyage du contenu ne vaut que si vous supprimez la source. Sinon, vous serez condamné à recommencer.
Les cas les plus fréquents que j’ai rencontrés:
- compte admin ou éditeur compromis, plugin déjà vulnérable ou compromis, thème modifié en secret, mécanisme de réinjection (tâche planifiée, webshell, script discret).
Pour éviter de courir partout, je me base sur un faisceau d’indices. Une seule preuve isolée ne suffit pas, mais un pattern répété aide.
Voici les signes qui m’ont le plus souvent orienté vers une source de réinfection.
Signes fréquents d’une réinjection ou d’un compte compromis
- Des contenus “modifiés” alors que personne n’a travaillé dessus entre deux visites. Des URL externes qui reviennent, souvent avec le même domaine ou les mêmes paramètres. Des apparitions de liens surtout après des tentatives de connexion ou après une mise à jour. Des comptes inconnus, ou des rôles qui ont changé sans explication. Des tentatives de mise à jour qui arrivent même en dehors de vos heures de maintenance.
Si vous observez ce type de signaux, commencez par verrouiller: changez les mots de passe, vérifiez les sessions, auditez les comptes, et contrôlez les plugins actifs et leur état.
Vérifier les fichiers changés, sans se fier à “l’apparence”
Un lien caché dans le contenu peut venir d’une modification de fichiers, même si tout a l’air normal dans l’interface admin.
Je procède généralement par deux étapes:
- vérifier l’intégrité des thèmes et plugins (et pas seulement “qu’ils sont là”), regarder les fichiers récemment modifiés sur le serveur.
Ensuite, je compare avec la version attendue. Si vous utilisez des thèmes issus de marketplaces, vous pouvez généralement réinstaller le thème depuis l’archive officielle pour remettre les fichiers à zéro.
Pour les plugins, la logique est la même. Réinstaller une version saine est souvent plus sûr que “supprimer une ligne suspecte”.
Le compromis ici, c’est que vous pouvez perdre des personnalisations (par exemple, un thème modifié localement). Mais si vous avez été compromis, la priorité est la restauration de la base saine.
Cache, CDN et “fantôme” du lien: le piège du retour
Après avoir supprimé un lien dans un article, le lien peut rester visible pendant un moment. Ce n’est pas forcément une réinjection. Souvent, c’est une conséquence de cache.
WordPress peut être mis en cache via:
- le cache d’un plugin, un cache serveur (par exemple au niveau du reverse proxy), un CDN, ou une optimisation côté navigateur.
Donc, avant de conclure que le nettoyage a échoué, invalidez le cache sur toutes les couches possibles. Sinon, vous passez votre temps à “nettoyer un fichier” alors que la page servie vient d’un ancien rendu.
Dans les cas où le site est très lent à propager, j’ai déjà vu un lien revenir pendant 15 minutes après suppression, puis disparaître complètement après purge. La confusion est réelle. C’est pour ça que la check list “désactiver le cache temporairement” n’est pas une formalité.
Procédure de désinfection pratique, du contenu à la prévention
Je préfère une séquence qui réduit le risque de boucle de réinfection. Elle ne demande pas d’outils ésotériques, juste de la discipline.
1) Identifiez 1 à 3 pages touchées, puis repérez le domaine ou le motif exact. 2) Vérifiez si le contenu back-office contient déjà ce motif, en mode texte. 3) Supprimez le bloc ou https://gardewp.fr/ le segment qui porte le lien, et contrôlez le rendu après purge cache. 4) Auditez les plugins et le thème actif. Réinstallez à neuf si nécessaire. 5) Verrouillez la sécurité: mots de passe, rôles, sessions, et suppression des comptes inconnus. 6) Surveillez sur 24 à 72 heures, avec des recherches ciblées du motif dans la base.
Le point clé, c’est la surveillance après coup. Le nettoyage est un moment, la désinfection est un processus. Un lien caché peut revenir si un mécanisme de réinfection existe, et il peut être déclenché par un événement (publication, tâche planifiée, connexion à un moment précis).
Nettoyer aussi la base de données, sans paniquer
Dans certains cas, le lien caché est réellement dans la base à plusieurs endroits, pas seulement dans la table des contenus. Vous pouvez alors faire une recherche globale du motif, par exemple un domaine suspect.
Le risque quand on “supprime au hasard”, c’est de casser du contenu légitime ou de supprimer des données utiles. La meilleure approche consiste à:
- repérer précisément les occurrences dans les champs concernés, comprendre ce que le site rend réellement, et supprimer uniquement ce qui correspond à l’injection.
J’ai déjà vu des nettoyages trop agressifs qui ont vidé des éléments de mise en page. Le site “semblait” propre côté HTML, mais les blocs Gutenberg ne s’affichaient plus comme avant. Sur ce type d’incident, la prévention et l’identification fine valent mieux que le nettoyage brute force.
Quoi faire si vous ne retrouvez pas le lien dans l’article ?
C’est un cas fréquent. Il y a plusieurs scénarios:
- le lien est injecté au rendu via un filtre PHP, le lien est généré par un hook dans le thème ou un plugin, le lien est inséré dans un champ qui n’apparaît pas dans l’éditeur, ou le site utilise un builder qui stocke le contenu d’une manière indirecte.
Si l’URL apparaît dans le front, mais introuvable dans l’article, je fais d’abord une analyse sur le rendu: qu’est-ce qui entoure le lien? Est-ce qu’il y a une classe CSS spécifique, un bloc identifié, un conteneur ajouté automatiquement?
Ensuite, je remonte vers le code: quand vous voyez une structure répétée sur plusieurs pages, c’est souvent un point unique côté thème ou plugin.
C’est là que l’inspection du code source devient une enquête, pas juste un contrôle.
Prévenir le retour: durcissement WordPress après désinfection
Une fois le site nettoyé, vous voulez réduire la probabilité de récidive. Le durcissement ne doit pas être une course aux “options parfaites”. Il doit être adapté à votre équipe et à votre niveau de risque.
Je recommande surtout de verrouiller les points où les attaques trouvent leur porte d’entrée:
- comptes et mots de passe, permissions des rôles, hygiène plugin, suppression de ce qui est inutile, mises à jour régulières, surveillance.
Sur les environnements où je travaille, le changement le plus rentable est souvent la gestion des rôles. Beaucoup de sites donnent des droits trop larges à des comptes qui ne devraient gérer que du contenu. Limiter ce qui peut injecter du HTML ou publier sans validation réduit drastiquement le risque de “liens cachés” qui reviennent.
Et si vous utilisez un builder ou un plugin de rendu, suivez son état de sécurité de près. Un plugin “innocent” peut devenir le vecteur.
Cas concrets: ce que j’aurais fait différemment
Je termine avec quelques retours qui aident à éviter les erreurs qui coûtent cher en temps.
Un premier cas: un site e-commerce avait des liens cachés dans les descriptions produit. Le premier nettoyage avait consisté à corriger deux pages visibles. Ça a tenu trois jours, puis le problème a repris. La cause était un rôle éditeur qui pouvait modifier des blocs via un plugin de contenu. Tant que ce rôle n’avait pas été verrouillé, l’injection a continué, même si les pages les plus touchées avaient été corrigées.
Un deuxième cas: une page “propre” affichait pourtant des liens cachés. La suppression du bloc dans Gutenberg ne suffisait pas, car le lien était généré au rendu par un filtre lié au thème. Le contenu back-office ne contenait pas l’URL, et pourtant elle apparaissait dans le HTML final. La désinfection a nécessité une remise à zéro du thème modifié et la suppression d’un hook ajouté.
Ces deux scénarios montrent la même leçon: le contenu est souvent la surface, pas la cause.
Ce que vous pouvez mesurer pour être sûr
Une désinfection sérieuse doit laisser des traces de stabilisation. Sans basculer dans une obsession de reporting, je conseille de vérifier:
- que le motif (domaine ou URL) n’apparaît plus dans le HTML rendu, que les pages corrigées restent propres après purge cache, que les mêmes pages ne “réinventent” pas le problème, et que vos comptes et plugins n’ont pas de signe d’altération.
Ce contrôle simple, fait sur quelques pages et sur une courte période, permet d’éviter de repartir de zéro alors que tout n’était pas totalement réglé.
Si vous arrivez à cette étape, vous avez déjà fait l’essentiel du travail: vous avez coupé le lien entre l’injection et le contenu rendu. Ensuite, la surveillance et le durcissement font le reste.
Si vous voulez, décrivez-moi le type de lien caché que vous voyez (code HTML exact, bloc concerné, domaine visé) et votre stack (éditeur Gutenberg ou builder, plugins de cache, thème). Je peux vous aider à choisir la méthode la plus sûre pour le retirer sans risquer de casser la mise en forme.