Un dimanche soir, un client m’envoie une capture d’écran Search Console accompagnée de trois points d’interrogation. Son concurrent direct, un domaine apparu de nulle part trois mois plus tôt, venait de lui passer devant sur ses vingt requêtes stratégiques. Le site en question n’avait aucun backlink visible, un design qui semblait sorti d’un générateur bas de gamme, et un catalogue de pages qui grossissait de plusieurs centaines d’URL chaque jour. J’ai ouvert les DevTools, épluché les logs, gratté le code source. Ce que j’ai trouvé, c’est mon premier réseau de spam SEO industrialisé. Et ça m’a plus appris sur le vrai fonctionnement des algorithmes que six mois de veille classique.
Le déclic : 340 000 pages indexées en neuf semaines
Le volume d’indexation ne collait pas. Sur un domaine âgé d’à peine quelques mois, la Search Console affichait des dizaines de milliers de pages découvertes chaque semaine. Le ratio pages indexées sur pages soumises dépassait 90 %, ce qui est déjà un signal d’autorité pour un site neuf. Sauf qu’ici, l’autorité n’existait pas : aucun lien externe significatif dans Ahrefs ou Semrush, aucune mention presse, aucun profil social. Le contenu était un assemblage de phrases syntaxiquement correctes mais sémantiquement vides, mêlant du keyword stuffing low-tech avec des paragraphes visiblement générés par un LLM de première génération. Pourtant, Google les gobait.
J’ai commencé à crawler le site avec Screaming Frog en positionnant un user-agent mobile et un user-agent Googlebot. La première anomalie est apparue : 74 % des pages n’étaient accessibles que pour le bot, via un serveur qui détectait l’IP de Google Cloud pour servir une version statique épurée. Pour un navigateur classique, ces mêmes URL renvoyaient un soft 404 avec un contenu inoffensif. Du cloaking pur, mais exécuté avec un niveau de granularité qui rendait la détection difficile. Le spammeur adaptait même la réponse en fonction de la date de crawl, maintenant une fraîcheur artificielle.
Le site ne tentait pas de cacher son absence de valeur ajoutée. Il optimisait chaque signal technique avec une rigueur d’horloger. Son sitemap.xml était segmenté par type de contenu, mis à jour toutes les six heures, avec des priorités de crawl cohérentes. Aucune erreur 5xx, aucune redirection superflue, un TTFB sous les 300 ms.
La mécanique de rendu : un miroir déformant des Core Web Vitals
LCP sous 1,8 seconde, INP stable autour de 70 ms. Ses pages passaient tous les seuils Core Web Vitals. La version servie au bot était un HTML ultra-léger : font-display: swap, lazy-loading natif, JSON-LD propre, zéro JavaScript superflu.
Les algorithmes mesurent la rapidité, pas l’intention. Une page qui charge vite et affiche des mots-clés pertinents reste « satisfaisante » dans les métriques, même quand l’utilisateur humain la trouve inutile. Le spammeur ne trichait pas sur la performance, il l’atteignait vraiment, pour une coquille vide.
💡 Conseil : un site qui affiche de très bons Core Web Vitals sans effort éditorial est un candidat naturel à une inspection manuelle de la Search Console.
La piste des fermes de liens injectées
Le cloaking expliquait l’impunité, pas l’autorité. J’ai pivoté sur l’analyse des backlinks. En filtrant dans Ahrefs sur l’historique des six derniers mois, le schéma est apparu : des centaines de domaines inactifs, surtout des blogs WordPress abandonnés, linkaient vers les pages stratégiques du site spam. Aucun ne renvoyait de trafic, mais tous portaient un PageRank résiduel non nul. Ces liens n’étaient pas achetés, ils étaient injectés via des failles connues de plugins obsolètes.
L’empreinte était mécanique. Chaque domaine injecté affichait le même type d’ancre : une phrase générique avec le mot-clé exact, noyée dans un paragraphe d’article existant. Le maillage donnait exactement un lien par domaine tiers, jamais deux, ce qui réduisait le risque de détection par les filtres de masse. Le réseau comptait environ 1 200 domaines compromis (chiffre que je ne peux pas vérifier à l’unité près, mais l’ordre de grandeur est cohérent avec les volumes d’URL découverts).
En inspectant le bundle.js d’une page d’administration cachée, j’ai repéré un store localStorage qui pilotait les instructions de crawl, une architecture proche de ce qu’on documentait dans notre article sur Zustand et le state management React.
Le retard structurel des algos de qualité
Le cloaking ne durait que quelques semaines par page, le temps d’obtenir une indexation stable. Le contenu était ensuite remplacé par des versions « propres ». Le spammeur jouait sur la fenêtre temporelle entre le crawl d’indexation et l’évaluation de qualité différée, qui arrive des semaines plus tard. Tant que la page reste dans la phase « pas encore évaluée », elle capitalise sur les bénéfices d’indexation. Variante du spam à fenêtre glissante, difficile à contrer sans analyse longitudinale.
Les trois leçons que j’en ai tirées pour mon propre SEO
La première leçon est contre-intuitive : il faut auditer son site comme un spammeur le ferait. Les pages les plus faibles en contenu réel (tags, archives d’auteurs, résultats de recherche interne) sont les premiers points d’entrée qu’un concurrent malveillant cible pour accuser le site de contenu léger. Les profils SEO sérieux désindexent ces URL quand elles n’apportent aucun trafic qualifié.
Deuxième leçon : la supervision des logs. Suivre le comportement de Googlebot ne suffit pas ; il faut croiser user-agents, plages IP et dates de crawl. Un site qui reçoit des crawls Googlebot sans jamais de trafic humain sur une page, c’est un indice de cloaking. La proportion bots/humains se surveille en continu, une dérive massive déclenche un audit.
Troisième leçon, je l’applique chaque fois que je teste un nouvel outil. Les assistants comme ceux qu’on compare dans Claude Code vs Cursor IDE ne remplacent pas la lecture du code source, mais ils accélèrent la détection de patterns suspects : redirections conditionnelles basées sur l’IP, contenu chargé en asynchrone, fetch qui récupère du contenu depuis une API externe. Les node_modules des thèmes premium réservent parfois des surprises.
L’angle mort des audits de performance
J’ai passé des années à prêcher qu’un site techniquement irréprochable est mieux armé pour le SEO. Cette enquête m’a obligé à nuancer. Le zéro défaut technique n’est pas un rempart contre le spam, c’est un amplificateur. Une architecture parfaite sert un contenu médiocre avec la même efficacité qu’un contenu excellent.
Questions fréquentes
Peut-on vraiment manipuler les Core Web Vitals pour tromper Google ?
Oui, si on les réduit à des métriques isolées. Un site statique ultra-light atteindra les seuils sans effort, et Google les prendra en compte. Mais cela ne lui donne pas un « passe-droit » éternel ; les évaluations sémantiques finissent par rattraper le signal technique. Le risque, c’est que cette fenêtre d’opportunité suffise à capter un trafic significatif avant la sanction.
Quels sont les outils les plus efficaces pour détecter ce type de spam sur mon propre secteur ?
Screaming Frog avec deux user-agents distincts reste la première ligne de défense. Ahrefs pour tracker les pics de backlinks basse qualité. Ensuite, un monitoring maison des logs serveur croisant IP de Googlebot et proportion d’URL nouvellement indexées. Il n’existe pas de solution SaaS clé en main qui fasse tout cela automatiquement sans paramétrage poussé.
Le spam SEO est-il en déclin avec l’arrivée des contenus générés par IA ?
Non, il mute. Les LLM permettent de générer du contenu varié à large échelle sans les maladresses du keyword stuffing classique, ce qui rend la détection plus difficile. Le vrai combat se déplace vers l’authenticité des signaux d’autorité et la cohérence temporelle de la publication. Ce qui décline, c’est le spam amateur ; reste le spam industrialisé.
