Votre site WordPress contient du spam SEO. Le nettoyer ne suffira pas.

Le spam SEO WordPress revient sans cesse parce que le nettoyage supprime le symptôme et laisse la voie d'accès intacte. Sucuri a trouvé une porte dérobée sur 49,21 % des sites compromis au moment de l'infection, et au moins un compte administrateur malveillant sur 55 % des sites porteurs d'un logiciel malveillant en base de données.

Vous scannez les pages, supprimez les liens injectés, mettez à jour chaque extension, et les liens de pharmacie sont de retour en moins d'un mois. Le compte qui les réinstalle a été créé lors de la première intrusion et a survécu au nettoyage.

Quiconque a déjà nettoyé une installation WordPress piratée le sait : la deuxième infection arrive plus vite que la première. Suivent les dégâts causés à votre référencement, un audit de 20 minutes sans acheter le moindre scanner, les raisons de l'échec du nettoyage et la manière de fermer la brèche pour de bon.

• Le spam SEO fait partie des infections les plus courantes que Sucuri corrige. Il est apparu sur 20,30 % des sites infectés lors du nettoyage et sur 42,22 % via des analyses à distance.
• Le nettoyage retire la charge utile et laisse l'accès. 49,21 % des sites compromis avaient une porte dérobée, et 55 % des sites infectés en base de données un compte administrateur malveillant.
• Corriger est souvent impossible. Patchstack a recensé 11 334 nouvelles vulnérabilités WordPress en 2025, dont 91 % dans des extensions, et 46 % n'avaient aucun correctif le jour de leur publication.
• L'essentiel du spam vit dans la base de données. 38,3 % des bases compromises contenaient du spam SEO, ce qui explique qu'un scanner de fichiers déclare le site propre pendant que Google affiche des titres de pharmacie.
• Une reconstruction statique met fin au cycle. Sans base de données à l'exécution et sans couche d'extensions, il n'y a rien sur le serveur où injecter quoi que ce soit.

Ce qu'une injection de spam SEO fait à un site WordPress

L'attaquant convoite la réputation de votre domaine. Un site auquel Google fait déjà confiance transmet cette confiance à des pages qui vendent des médicaments contrefaits, des inscriptions à des casinos ou de fausses baskets. Les liens vous restent invisibles et sont servis à Googlebot. Dans le navigateur le site paraît irréprochable, dans l'index il se lit comme une pharmacie.

• Blocs de liens masqués. Des centaines de balises d'ancrage repoussées hors de l'écran en CSS, injectées dans le pied de page, une zone de widget ou un vieil article que personne n'ouvre.
• Pages masquées (cloaking). Le serveur vérifie l'user-agent et le référent avant de décider quoi envoyer. Les visiteurs humains reçoivent votre page d'accueil, Googlebot reçoit du spam, et le propriétaire est le dernier informé.
• Le Japanese keyword hack. Google Search Central le documente sous ce nom : des milliers de pages générées automatiquement avec du texte japonais et des liens d'affiliation, plus un propriétaire indésirable ajouté à la Search Console pour que l'attaquant garde l'accès après votre nettoyage des fichiers.
• Redirections conditionnelles. Les visiteurs arrivant d'un résultat de recherche sont renvoyés vers la destination spam. Celui qui tape le domaine directement voit un site normal, d'où la difficulté à croire le premier signalement.

38,3 % des bases de données compromises dans le jeu de données de Sucuri contenaient du spam SEO, essentiellement des liens dissimulés vers des médicaments contrefaits et des jeux d'argent. Ce chiffre explique la partie la plus frustrante. Un scanner de logiciels malveillants parcourt le système de fichiers, déclare tout propre, et le contenu injecté se trouve dans une table de base de données qu'il n'a jamais ouverte.

Si des pages de spam apparaissent déjà dans vos résultats de recherche, la voie de la reconstruction compte davantage que la prochaine analyse. Le service de migration WordPress de webvise couvre le passage à un frontend Next.js statique, avec la table de redirections qui préserve votre positionnement actuel.

Confirmer l'infection en 20 minutes

Effectuez ces quatre vérifications avant de payer qui que ce soit pour un nettoyage. Chacune prend quelques minutes, n'exige aucune extension et repère ce que le scanner de votre tableau de bord laisse passer.

1. Demandez à Google ce qu'il a indexé

Interrogez votre propre domaine avec l'opérateur site et lisez le nombre de résultats avant de lire les résultats eux-mêmes.

• site:votredomaine.fr viagra et site:votredomaine.fr casino renvoient des pages que vous n'avez jamais écrites. Un seul résultat suffit.
• site:votredomaine.fr seul renvoie bien plus de pages que n'en compte votre site. Un site vitrine de 40 pages annonçant 6 000 URL indexées constitue à lui seul le diagnostic complet.
• Des titres de résultats s'affichent en caractères japonais, cyrilliques ou chinois sur un site qui publie en français ou en anglais.

2. Récupérez votre propre site en vous faisant passer pour Googlebot

Le spam masqué n'apparaît que lorsque le serveur croit que Googlebot fait la demande. Comparez dans un terminal ce que reçoivent les deux visiteurs.

Des chiffres identiques n'innocentent pas le site. Beaucoup d'injections visent des URL précises plutôt que la page d'accueil. Répétez donc la comparaison sur deux ou trois pages profondes avant de vous fier au résultat.

3. Lisez la Search Console, puis vérifiez qui d'autre peut la lire

Ouvrez d'abord les sections Actions manuelles et Problèmes de sécurité. Une action manuelle pour spam lié au piratage, une flambée soudaine d'impressions sur des requêtes sans rapport avec votre activité, ou un propriétaire validé inconnu dans les Paramètres pointent tous dans la même direction. Ce dernier point échappe presque toujours à l'attention, et c'est lui qui permet à un attaquant de revalider la propriété longtemps après la reconstruction du site.

4. Fouillez la base de données, pas les fichiers

C'est là que le scanner de fichiers a cessé de chercher. Trois requêtes font remonter l'essentiel de ce qu'il a ignoré.

• SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%display:none%' OR post_content LIKE '%position:absolute;left:-%'; repère les blocs de liens masqués stockés dans vos contenus.
• SELECT user_login, user_registered FROM wp_users ORDER BY user_registered DESC LIMIT 10; liste les comptes les plus récents. Remettez en question chacun de ceux auxquels vous ne pouvez associer un visage.
• SELECT option_name FROM wp_options WHERE autoload='yes' AND LENGTH(option_value) > 100000; attrape les charges utiles injectées surdimensionnées, configurées pour se charger à chaque requête.

Pourquoi le nettoyage échoue systématiquement

Un nettoyage vise la charge utile visible. La voie d'accès est tout autre chose, et elle survit à l'analyse, à la mise à jour des extensions et à la restauration de sauvegarde que la plupart des agences appliquent en première étape.

Les données de remédiation de Sucuri relèvent une porte dérobée sur 49,21 % des sites compromis au moment de l'infection. Sur les sites porteurs d'un logiciel malveillant en base de données, 55 % comptaient en plus au moins un compte administrateur malveillant. L'attaquant se connecte donc par la porte d'entrée et fait l'économie de l'exploit la seconde fois. Supprimer des liens de spam sur un site qui conserve les deux relève du ménage, et la réinfection tient de l'échéance plutôt que de la surprise.

WP Automatic rend le schéma concret. Patchstack a publié CVE-2024-27956 le 13 mars 2024, une injection SQL non authentifiée notée 9,8, et les attaques qui ont suivi s'en sont servies pour créer de nouveaux comptes administrateurs. Les chercheurs ont enregistré plus de 5,5 millions de tentatives d'exploitation. Chaque site touché puis nettoyé sans que personne n'audite la table des utilisateurs a laissé à l'attaquant un identifiant qui fonctionne.

La dernière ligne décide de toute la stratégie. Patchstack a recensé 11 334 nouvelles vulnérabilités WordPress en 2025, soit 42 % de plus que l'année précédente, dont 91 % dans des extensions et 46 % sans correctif le jour de leur publication. Pour près de la moitié de tout ce qui a été divulgué l'an dernier, appliquer le correctif ne faisait pas partie des options qui s'offraient à vous.

C'est précisément ce qui transforme une question de maintenance en question de plateforme. Le même raisonnement traverse les risques de sécurité d'une installation laissée obsolète, et le calcul empire chaque année où le nombre de vulnérabilités grimpe.

Ce que le spam vous coûte réellement dans Google

Les dégâts de positionnement précèdent largement la découverte. Quand une page de spam apparaît dans une recherche site, Google l'explore et l'indexe depuis des semaines, et le schéma qu'il a appris sur votre domaine est déjà en place.

La récupération suit un ordre fixe et rien n'y est rapide. Nettoyer le site, supprimer les comptes et propriétaires indésirables, déposer une demande de réexamen, puis attendre la levée de l'action manuelle. Google n'annonce aucun délai de traitement pour cet examen. Les pages désindexées comme spam ne reviennent pas avec leurs anciennes positions.

Un site qui a servi des pages de pharmacie masquées pendant deux mois emporte cet historique dans tout ce qui sera construit ensuite, ce qui augmente l'enjeu de la reconstruction elle-même. Les mécanismes qui préservent le positionnement lors d'une refonte méritent une lecture avant que quiconque touche au DNS.

Supprimer la surface d'attaque au lieu de la corriger

WordPress exécute du PHP sur votre serveur, lit et écrit dans une base de données à chaque requête, et fait tourner du code d'extension tiers avec un accès quasi total aux deux. Ce sont exactement les trois propriétés dont une injection de spam SEO a besoin. Un site Next.js généré statiquement n'en offre aucune à l'exécution.

• Aucune base de données à l'exécution. Les pages sont construites au déploiement et servies comme des fichiers depuis un CDN. Il n'existe aucune table wp_posts où écrire des divs masqués.
• Aucune couche d'extensions. 91 % des vulnérabilités WordPress de 2025 se logeaient dans des extensions. Un site sans couche d'extensions n'hérite d'aucune d'entre elles.
• Rien d'inscriptible sur le serveur. Seul un déploiement modifie ce que voient les visiteurs, et il part du contrôle de version. Un fichier injecté apparaît comme une différence avant même d'être livré.
• Aucun panneau d'administration exposé sur Internet. Le problème du compte administrateur malveillant cesse d'exister dès qu'il n'y a plus de formulaire de connexion à atteindre.

La migration elle-même est une grandeur connue : audit complet du site existant, reconstruction en Next.js avec génération statique, une redirection 301 pour chaque URL existante, puis suivi du positionnement après la bascule. webvise procède exactement dans cet ordre, avec un prototype fonctionnel assez tôt pour que vous voyiez vos contenus en place avant de vous engager. Savoir si ce changement convient à votre site dépend de la part qui a réellement besoin d'un serveur.

Commencez par les quatre vérifications. Si une recherche site renvoie des pages que vous n'avez jamais écrites, la voie d'accès doit être fermée avant toute autre chose, et le devis de nettoyage qui attend dans votre boîte mail achète quelques semaines de calme plutôt qu'une solution. webvise audite l'installation existante, rend compte de ses conclusions et reconstruit sur une base où rien ne peut être injecté : réservez l'audit ici.