Comment détecter un piratage SEO caché grâce aux termes de recherche de la Search Console ?

Pourquoi Google insiste-t-il sur la surveillance des termes de recherche ?

La Search Console expose toutes les requêtes ayant déclenché l'affichage de vos pages dans les résultats de recherche. Si votre site vend des meubles scandinaves et que vous découvrez des impressions sur "viagra pas cher" ou "casino online", c'est le signal d'alarme. Les pirates injectent du contenu invisible ou des pages parasites pour exploiter votre autorité de domaine.

Ce type d'attaque est fréquent sur les CMS mal sécurisés (WordPress avec plugins obsolètes, Joomla non patchés). Les hackers créent des pages camouflées que seuls les bots Google voient, tandis que les visiteurs humains accèdent au contenu légitime. Résultat : votre crawl budget est gaspillé, votre réputation dégradée, et Google finit par appliquer une action manuelle.

Quelle est la différence entre contamination visible et invisible ?

Certains piratages sont immédiatement repérables : pages spam dans le sitemap XML, répertoires bizarres listés dans un site:votredomaine.com. D'autres sont plus sournois : cloaking via user-agent, injection de liens dans les fichiers de thème, redirections conditionnelles 302 vers des sites tiers. La Search Console capture ces deux types parce qu'elle enregistre le comportement de Googlebot, pas celui de votre navigateur.

Un site compromis peut maintenir son apparence normale pendant des semaines tout en saignant son PageRank vers des fermes de liens. Les outils comme Screaming Frog ne verront rien si le cloaking est bien fait. Seule la liste des requêtes dans GSC trahit l'anomalie.

À quelle fréquence faut-il vérifier ces données ?

Pour un site e-commerce ou média avec forte autorité, un contrôle hebdomadaire est le strict minimum. Les sites à croissance rapide attirent les attaques automatisées. Si vous gérez 50 domaines, automatisez l'extraction via l'API Search Console et déclenchez des alertes sur des patterns suspects (explosion soudaine de requêtes hors thématique, pics d'impressions sur des mots-clés jamais ciblés).

Ne vous fiez pas aux seuls outils de sécurité classiques. Un antivirus serveur ne détecte pas un fichier PHP légitime modifié avec trois lignes de code malveillant. La Search Console devient votre canari dans la mine : si les requêtes partent en vrille, fouillez immédiatement logs serveur, base de données et fichiers système.

• Surveillez les onglets "Performances" et "Requêtes" dans GSC chaque semaine minimum
• Filtrez par requêtes à forte impression mais zéro clic : souvent du spam camouflé
• Comparez les 28 derniers jours aux 28 précédents pour détecter des écarts anormaux
• Automatisez via API si vous gérez plusieurs domaines pour recevoir des alertes en temps réel
• Croisez avec Google Analytics : trafic organique stable mais impressions GSC explosées = piratage probable

Cette recommandation reste-t-elle pertinente face aux évolutions de GSC ?

Le conseil de Cutts date de l'époque où la Search Console était encore Webmaster Tools, mais il n'a jamais été aussi actuel. Les attaques SEO négatives et les compromissions automatisées ont explosé avec la démocratisation des botnets. La différence aujourd'hui : GSC filtre mieux les faux positifs et expose 16 mois d'historique au lieu de 90 jours.

Ce qui a changé : Google détecte désormais plus rapidement les patterns de spam et applique des actions manuelles en quelques jours. Mais cette réactivité accrue signifie aussi que vous avez moins de temps pour agir avant qu'une pénalité ne fracasse votre trafic. La surveillance proactive des requêtes n'est plus optionnelle, c'est une hygiène de base.

Quelles sont les limites de cette approche ?

Premier point faible : GSC n'expose que les requêtes ayant généré des impressions. Si un pirate injecte du contenu mais que Google ne l'indexe pas encore (délai de crawl, budget insuffisant), vous ne verrez rien. Les sites compromis avec robots.txt manipulé ou noindex malveillant passent sous le radar jusqu'à ce que le hack soit résolu ou que Google force le crawl.

Deuxième limite : les faux positifs existent. Un site multilingue peut légitimement ranker sur des requêtes étranges si la traduction automatique produit du contenu bancal. Un blog tech peut apparaître sur "crack logiciel" sans être piraté, juste parce qu'un article mentionne le terme dans un contexte légitime. [A verifier] : séparez signal et bruit en croisant avec l'onglet Couverture et en vérifiant manuellement les URLs incriminées.

Dans quels cas cette vérification ne suffit-elle pas ?

Si votre site subit une attaque par injection SQL qui modifie la base de données sans créer de nouvelles pages, GSC ne révélera rien. Les redirections 301 malveillantes vers des sites tiers échappent parfois à GSC si elles ciblent uniquement certains user-agents ou géolocalisations. Les parasites peuvent aussi exploiter des sous-domaines non déclarés dans votre propriété Search Console.

Pour ces cas, combinez GSC avec monitoring serveur (logs Apache/Nginx analysés par GoAccess ou similaire), vérification d'intégrité des fichiers (checksums), et scans réguliers avec Sucuri ou Wordfence. La Search Console est votre première ligne de défense, pas la seule.

Comment auditer efficacement les termes de recherche dans GSC ?

Connectez-vous à la Search Console, sélectionnez votre propriété, puis Performances > Résultats de recherche. Activez l'affichage des requêtes et triez par impressions décroissantes. Scrollez au-delà des 50 premières requêtes habituelles : c'est là que se cachent les anomalies. Filtrez par période (28 derniers jours) et comparez avec la période précédente pour repérer les explosions soudaines.

Exportez la liste complète en CSV et passez-la dans un tableur. Cherchez des mots-clés qui n'ont aucun rapport avec votre thématique : pharmaceutiques, jeux d'argent, adulte, répliques de luxe. Si vous en trouvez, notez les URLs associées en cliquant sur la requête puis l'onglet Pages. Vérifiez immédiatement si ces URLs existent réellement sur votre serveur ou si elles sont camouflées.

Que faire si des requêtes suspectes apparaissent ?

Première action : vérifiez l'onglet Sécurité dans GSC. Si Google a déjà détecté le problème, un message d'alerte s'affiche. Ensuite, utilisez l'outil Inspection d'URL sur les pages incriminées pour voir ce que Googlebot a réellement crawlé (code source, captures d'écran). Souvent, vous découvrirez du contenu invisible pour vous mais visible pour les bots.

Lancez une analyse complète de votre site avec des outils comme Screaming Frog en mode Googlebot, ou un scan de sécurité serveur (Sucuri, MalCare). Cherchez des fichiers PHP suspects dans /wp-content/uploads/ ou /cache/, des injections dans .htaccess, des utilisateurs admin inconnus dans votre CMS. Changez immédiatement tous les mots de passe (FTP, base de données, admin CMS) et vérifiez les permissions de fichiers.

Quelles erreurs éviter lors du nettoyage ?

Ne supprimez pas les pages compromises sans les avoir d'abord bloquées dans robots.txt et désindexées via GSC, sinon Google continuera de les crawler pendant des semaines. N'attendez pas que Google vous envoie un message d'alerte : quand vous le recevez, les dégâts sont déjà massifs. Ne nettoyez pas uniquement les fichiers visibles : les backdoors se cachent souvent dans des fichiers système légitimes modifiés (functions.php, config.php).

Évitez de réinstaller votre CMS sans avoir identifié la faille d'entrée initiale. Si vous ne corrigez pas le plugin vulnérable ou le mot de passe FTP faible, vous serez réinfecté en 48h. Et surtout, ne négligez pas la demande de réexamen auprès de Google après nettoyage : sans elle, l'action manuelle peut persister des mois.

• Auditer les requêtes GSC chaque semaine en exportant la liste complète
• Filtrer par impressions élevées et CTR anormalement bas (signal de spam)
• Inspecter manuellement les URLs associées aux requêtes suspectes
• Lancer un scan de sécurité complet (Sucuri, Wordfence, MalCare)
• Bloquer les pages compromises dans robots.txt avant suppression
• Soumettre une demande de réexamen dès le nettoyage terminé