À retenir
Une alerte « Pages trompeuses » dans Google Search Console peut résulter d’un faux positif des classifieurs automatiques Safe Browsing, sans aucune compromission réelle du site. La résolution suit un protocole en 5 phases : diagnostic croisé, hardening serveur, audit WordPress, renforcement des signaux de légitimité, surveillance et demande d’examen. Une check-list complète de 30 contrôles avec un bloc .htaccess durci prêt à coller est téléchargeable en fin d’article.

Table des matières

Le 6 mai 2026, Google Search Console a remonté une alerte « 1 problème détecté » dans la section Sécurité et actions manuelles du site patrickligeron.fr. Type de problème signalé : « Pages trompeuses ». Aucune URL d’exemple n’était fournie, et les vérifications immédiates écartaient toute compromission technique. Quatorze jours plus tard, un mail officiel de Google confirmait la résolution avec la mention « Examen réussi pour le site patrickligeron.fr ».

Cet article documente le protocole appliqué pas à pas, les outils utilisés, les pièges rencontrés, et fournit la check-list complète pour traiter ce type de situation avec méthode. Il s’adresse aux consultants SEO, aux webmasters et aux dirigeants de TPE et PME confrontés à une alerte de sécurité dans Search Console.

1. Le contexte : un faux positif Google sur un sous-domaine de capture

Le site et son architecture

Le site principal patrickligeron.fr est un WordPress 6.9.4 sous GeneratePress Pro, hébergé chez OVH. Le domaine dispose de plusieurs sous-domaines actifs : un sous-domaine d’auto-test gratuit d’évaluation de la maturité IA (avec un formulaire de capture pour recevoir les résultats par email), et un sous-domaine n8n pour les automatisations (sur VPS séparé, accès SSH uniquement, durci).

L’alerte précise reçue dans Search Console

L’alerte indiquait littéralement : « Ces pages tentent d’inciter les internautes à agir de façon dangereuse, par exemple en installant un logiciel indésirable ou en révélant des informations personnelles. » Le champ « Exemples d’URL » affichait « Sans objet ». C’est cette absence d’URL spécifique qui a constitué la première difficulté du diagnostic.

Pourquoi un faux positif sans URL est particulièrement déroutant

Sans URL d’exemple, il faut identifier soi-même la source du signal. Google indique le périmètre du domaine entier, sans préciser quelle page ou quel sous-domaine déclenche la détection. Cela impose un protocole de diagnostic croisé sur plusieurs outils, dans l’ordre, pour éviter les conclusions hâtives.

2. Comment Google détecte les pages trompeuses et pourquoi un faux positif arrive

Le système Safe Browsing et son fonctionnement

Google Safe Browsing analyse des milliards d’URLs chaque jour pour détecter des contenus suspects (source : Google Transparency Report, niveau de preuve officiel). Lorsqu’un signal positif est levé sur une URL, le verdict s’applique généralement au périmètre du domaine et non à une page isolée. C’est pour cette raison que Safe Browsing peut classer « https://patrickligeron.fr » comme suspect alors que « https://www.patrickligeron.fr » reste vert.

La catégorie « Pages trompeuses » correspond au social engineering au sens Google. Plusieurs patterns d’interface peuvent être classifiés comme trompeurs par les algorithmes automatiques, notamment les formulaires qui demandent des données personnelles avec une promesse de retour immédiat. Cette interprétation est cohérente avec la documentation publique Google sur Safe Browsing, sans constituer une règle officielle exhaustive.

Pourquoi les sous-domaines récents avec formulaire de capture sont à risque

Hypothèse opérationnelle : un sous-domaine récent, sans réputation établie, sans backlinks entrants, hébergeant un formulaire de capture, peut être classé comme borderline par les classifieurs automatiques. L’absence de signaux de confiance (identification de l’éditeur, mentions légales, RGPD explicite, ancrage à une entité connue) augmente la probabilité d’un faux positif. C’est précisément ce schéma qui s’est joué ici.

3. Phase 1 : Diagnostic structuré en croisant 4 sources

Pourquoi un seul outil ne suffit jamais

Aucun outil pris isolément ne donne une vue complète. Croiser plusieurs sources permet de discriminer rapidement entre un faux positif des classifieurs et une compromission réelle, et de localiser l’origine du signal sans tâtonner.

Les 4 sources à consulter en parallèle

Google Search Console > Sécurité et actions manuelles : verdict officiel Google sur le périmètre concerné.
Google Transparency Report (Safe Browsing) : statut public testable sur chaque URL stratégique du domaine, y compris les sous-domaines.
Sucuri SiteCheck : scan tiers indépendant qui vérifie malware, présence sur blacklists, niveau de hardening serveur, et version du CMS.
Wordfence (depuis l’admin WordPress) : scan interne complet sur fichiers, vulnérabilités, utilisateurs, modifications récentes.

Arbre de décision rapide après diagnostic

Si Sucuri ne détecte ni malware ni blacklist, et que Wordfence ne signale aucune anomalie, et que Safe Browsing reste suspect sur une URL spécifique, alors la piste « compromission réelle » est très peu probable. Le focus se déplace vers les signaux faibles : hardening serveur insuffisant, pattern UX classifié comme borderline, signaux de confiance manquants sur un sous-domaine.

4. Phase 2 : Sécuriser le serveur en 30 minutes (hardening Apache et WordPress)

Les 5 security headers indispensables à ajouter dans le .htaccess

X-Frame-Options : protection contre le clickjacking en bloquant l’inclusion du site dans des iframes externes.
X-Content-Type-Options : prévention du MIME type sniffing par les navigateurs.
Strict-Transport-Security (HSTS) : forçage HTTPS persistant côté navigateur.
Referrer-Policy : contrôle des informations transmises aux sites externes.
Permissions-Policy : restrictions des API navigateur sensibles (caméra, micro, géolocalisation).

Bloc .htaccess prêt à coller pour Apache 2.4+

Le bloc ci-dessous est à insérer dans le fichier .htaccess à la racine du site WordPress, juste après les règles de redirection canonique et avant les directives WP Rocket. Toujours sauvegarder le .htaccess existant avant modification.

# Security Headers
<IfModule mod_headers.c>
    Header always set X-Frame-Options "SAMEORIGIN"
    Header always set X-Content-Type-Options "nosniff"
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
    Header always set Referrer-Policy "strict-origin-when-cross-origin"
    Header always set Permissions-Policy "geolocation=(), microphone=(), camera=()"
    Header unset X-Powered-By
    Header always unset X-Powered-By
</IfModule>

# Désactiver le directory listing
Options -Indexes

# Bloquer l'accès aux fichiers sensibles
<FilesMatch "^(wp-config\.php|\.htaccess|\.htpasswd|\.user\.ini|readme\.html|license\.txt)$">
    Require all denied
</FilesMatch>

Recommandation pratique : pour HSTS, démarrer avec « max-age=300 » (5 minutes) pendant 24 heures, vérifier que tous les sous-domaines répondent bien en HTTPS valide, puis basculer en « max-age=31536000; includeSubDomains » une fois la stabilité confirmée.

Activer la double authentification WordPress

Avec Wordfence Login Security (gratuit, déjà inclus dans le plugin Wordfence), la configuration TOTP prend moins de 5 minutes. C’est indispensable même avec un compte administrateur unique et un mot de passe complexe, pour se protéger des fuites de bases de données externes (credential stuffing). Toujours sauvegarder les recovery codes dans un gestionnaire de mots de passe.

5. Phase 3 : Audit WordPress de précaution

Lancer un scan Wordfence complet

Dans WP Admin > Wordfence > Scan, activer toutes les options et lancer un scan complet. Sur l’installation auditée, le scan a couvert 21 352 fichiers, 21 thèmes et plugins, 13 275 URLs internes, et l’audit utilisateurs. Aucun malware détecté, aucune vulnérabilité critique signalée.

Vérifier les utilisateurs administrateurs et les fichiers récemment modifiés

Vérifier qu’aucun compte administrateur fantôme n’a été créé (Utilisateurs > Tous, filtre Administrateur).
Trier /wp-content/ par date de modification décroissante via SFTP, repérer tout fichier modifié récemment sans justification.
Vérifier l’absence de fichiers PHP dans /wp-content/uploads/ (vecteur d’attaque classique).
Vérifier la liste des plugins installés : tous doivent être identifiables et installés volontairement.

Le faux positif Skipped Paths à savoir reconnaître

Wordfence affiche systématiquement un résultat « 1 path was skipped for the malware scan due to scan settings ». Severity Low. Ce résultat correspond à l’exclusion par défaut des dossiers de cache (WP Rocket) et de sauvegarde (UpdraftPlus). Ce n’est pas un signal d’alerte et il peut être ignoré sans risque.

6. Phase 4 : Renforcer la légitimité du sous-domaine

Les 6 signaux de confiance à implémenter sur un sous-domaine de capture

Bloc d’identité visible en haut de page (nom complet de l’éditeur, photo, fonction professionnelle).
Footer complet avec lien retour cliquable vers le site principal et liens vers les pages légales.
Mentions légales dédiées ou couvrant explicitement le sous-domaine dans leur périmètre.
Politique de confidentialité détaillant les données collectées par le formulaire et leurs finalités.
Conditions générales d’utilisation distinctes si le service propose une utilisation gratuite spécifique.
Texte RGPD reformulé au-dessus du formulaire, avec case de consentement obligatoire et décochée par défaut.

Le balisage Schema.org pour rattacher le service à une entité connue

Deux schemas complémentaires à ajouter dans le head des pages : Schema.org Person pour l’éditeur (avec sameAs pointant vers les profils LinkedIn et professionnels), et Schema.org WebApplication pour le service lui-même (avec creator pointant vers la Person). Le test Google Rich Results (search.google.com/test/rich-results) valide la cohérence du balisage.

Étendre les pages légales du site principal au périmètre du sous-domaine

Plutôt que de dupliquer des pages, il est plus efficace de compléter les mentions légales et la politique de confidentialité existantes en précisant que leur périmètre couvre explicitement le sous-domaine, en listant les données spécifiques collectées par le formulaire de capture, et en ajoutant tous les sous-traitants impliqués (par exemple Brevo pour l’envoi des emails, OVH pour l’hébergement, Cookiebot pour le consentement).

Réduire les champs du formulaire et inverser la séquence UX

Limiter le formulaire de capture aux champs strictement nécessaires (prénom et email professionnel suffisent dans la plupart des cas). Si techniquement possible, afficher les questions du test avant la demande d’email, et ne présenter le formulaire qu’en fin de parcours pour l’envoi des résultats détaillés. Cette inversion de séquence est cohérente avec les principes UX anti-phishing valorisés par Google.

7. Phase 5 : Surveillance et demande d’examen Google Search Console

Mettre en place un tableau de surveillance journalière

Sur un fichier de suivi (tableur ou simple bloc-notes), trois colonnes au minimum : statut Google Search Console (problème toujours présent ou non), statut Sucuri (Low, Medium, High), statut Safe Browsing par URL stratégique (vert, jaune, rouge). Une ligne par jour pendant 5 à 7 jours avant la demande d’examen.

Quand soumettre la demande d’examen

Trois conditions à réunir pour soumettre : stabilité du score Sucuri pendant 5 jours consécutifs, aucune dégradation Safe Browsing pendant la période d’observation, GSC sans nouveau signal négatif. Si Safe Browsing reste jaune sur le domaine racine malgré les corrections, c’est attendu : seul l’examen humain Google débloque ce verdict.

Le modèle de message à adresser à Google

Structure recommandée du message dans le formulaire de demande : (1) résumé factuel des vérifications confirmant l’absence de compromission, (2) liste des corrections de hardening serveur effectuées, (3) liste des renforcements de légitimité apportés au sous-domaine, (4) identité de l’éditeur avec URL du site principal et profils professionnels vérifiables, (5) résultats consolidés de la surveillance préalable. Format factuel, concis, sans plaidoyer émotionnel.

8. Le résultat : 14 jours du diagnostic à la résolution

La chronologie complète, jour par jour

J0 (6 mai 2026) : détection de l’alerte dans GSC, diagnostic croisé sur les 4 sources.
J0 à J1 : hardening serveur (Sucuri passe de Medium Security Risk à Low Security Risk).
J1 : audit WordPress complet, aucune anomalie.
J1 à J6 : renforcement du sous-domaine (identité, pages légales étendues, schemas, RGPD du formulaire).
J6 à J13 : surveillance journalière sur 3 sources pendant 7 jours, stabilité confirmée.
J13 : demande d’examen GSC soumise avec le message structuré.
J14 (14 mai 2026) : mail Google « Examen réussi pour le site patrickligeron.fr » reçu.

Le mail Google de confirmation

Le message officiel reçu indiquait : « Google a reçu et traité votre demande d’examen de sécurité. Les systèmes Google indiquent que patrickligeron.fr ne contient plus de liens vers des sites ou des téléchargements dangereux. Les avertissements relatifs à votre site visibles par les internautes sont en cours de suppression. Cette opération peut prendre plusieurs heures. »

Les délais de propagation après acceptation de l’examen

La levée des avertissements visibles dans Chrome et les autres navigateurs prend généralement de 24 à 72 heures après la décision Google. La mise à jour du statut public sur Google Transparency Report suit la même temporalité. Pendant cette fenêtre, la surveillance des trois sources doit continuer.

Note de méthode
Le protocole décrit dans cet article s’inspire des pratiques d’audit SEO structuré enseignées dans le cadre de la certification CESEO (Certification Européenne SEO) et de sa version qualité QASEO, deux certifications de référence pour les métiers du référencement en France, délivrées par la FePSeM (Fédération des Professionnels du Search Marketing). L’approche par phases successives, avec preuves et surveillance avant action, est la transposition opérationnelle des principes d’auditabilité valorisés par ces référentiels.

9. Les 5 erreurs à éviter dans ce type de situation

Erreur 1 : Désactiver tout le site dans la panique avant le diagnostic

Réflexe compréhensible mais contre-productif. Tant qu’il n’y a pas de preuve de compromission active (malware détecté, fichiers suspects, activité anormale), désactiver le site amplifie le problème sans le résoudre. Le diagnostic croisé sur les 4 sources prend moins de 30 minutes.

Erreur 2 : Soumettre la demande d’examen avant d’avoir corrigé en profondeur

Un examen Google rejeté complique fortement les demandes suivantes. Mieux vaut prendre 5 jours supplémentaires pour stabiliser les corrections et préparer un message factuel et complet, plutôt que soumettre dans l’urgence et essuyer un refus.

Erreur 3 : Resoumettre plusieurs demandes en boucle

Chaque nouvelle demande remet à zéro la place dans la file d’attente Google. Soumettre trois demandes en une semaine n’accélère pas l’examen, cela le retarde. Une seule demande bien préparée et bien attendre la réponse des équipes Google est toujours la meilleure stratégie.

Erreur 4 : Négliger le hardening « facile » qui envoie des signaux faibles cumulés

Les security headers absents, le directory listing ouvert, la version PHP exposée dans les headers HTTP : pris individuellement, aucun de ces points n’est critique. Cumulés, ils forment un signal de faible qualité serveur qui peut peser dans une évaluation automatique. La correction prend 30 minutes pour un gain de score immédiat.

Erreur 5 : Oublier que les sous-domaines comptent dans le périmètre du domaine principal

Une propriété GSC de type Domain couvre l’ensemble des sous-domaines. Un signal négatif sur un sous-domaine récent et peu visible peut donc déclencher une alerte sur la propriété du domaine principal. Il est essentiel de traiter chaque sous-domaine actif avec le même niveau d’exigence que le site principal : pages légales, identité éditeur, RGPD, schema, hardening.

10. Checklist complète à télécharger gratuitement

Pour appliquer cette méthode sur votre propre site avec rigueur, j’ai rassemblé l’ensemble des contrôles dans une check-list PDF gratuite. Elle contient 30 points de vérification organisés par phase, le bloc .htaccess durci prêt à coller, un modèle de demande d’examen GSC, et la liste des 10 vérifications mensuelles pour ne plus jamais avoir de faux positifs.

Téléchargement gratuit
Check-list sécurité Google Search Console : 30 contrôles + bloc .htaccess durci format PDF, 8 pages, prêt à imprimer ou à classer dans vos procédures internes.

Recevoir la check-list par email

11. FAQ : 6 questions fréquentes sur les alertes de sécurité Google Search Console

Combien de temps prend généralement l’examen Google après une demande de réexamen ?

Le délai officiel indiqué par Google est de quelques jours à 14 jours maximum. En pratique, sur les retours d’expérience publics, la médiane se situe entre 3 et 7 jours pour les problèmes de sécurité bien documentés. Dans l’étude de cas présentée ici, l’examen a été traité en 24 heures, ce qui correspond au scénario rapide.

Le faux positif peut-il revenir après résolution ?

Tant que les signaux faibles d’origine sont corrigés durablement (hardening en place, sous-domaine renforcé, pages légales à jour, schema valide), le risque de récidive est très faible. La surveillance mensuelle suffit. Le retour d’un faux positif serait possible si une nouvelle page ou un nouveau sous-domaine présentait à nouveau un pattern UX classifié comme borderline.

Faut-il payer Sucuri ou la version gratuite suffit-elle ?

Pour le diagnostic ponctuel d’un site, Sucuri SiteCheck en version gratuite (consultation web sitecheck.sucuri.net) suffit largement. Les versions payantes ajoutent du monitoring continu, un WAF cloud et un service de nettoyage en cas d’attaque réelle. Pour une TPE ou PME hors e-commerce, la version gratuite couvre le besoin.

Comment éviter ce problème sur un futur sous-domaine de capture ?

Anticiper dès la création du sous-domaine : identité de l’éditeur visible immédiatement, footer complet avec liens vers les pages légales du site principal, RGPD obligatoire au-dessus du formulaire, balisage Schema.org Person et WebApplication, hardening serveur dès le premier jour. Tous ces signaux préviennent les classifieurs automatiques.

Que faire si l’examen Google est refusé ?

Lire attentivement le motif du refus dans le mail Google : il indique généralement un point précis à corriger. Apporter la correction demandée, attendre 5 jours minimum, puis soumettre une nouvelle demande avec un message mis à jour mentionnant explicitement la correction apportée. Ne jamais resoumettre en boucle.

Le passage à un WAF cloud (Cloudflare, Sucuri Firewall) est-il nécessaire ?

Pas pour résoudre ce type de faux positif. Un WAF cloud apporte une couche supplémentaire de protection (filtrage DDoS, blocage des bots malveillants) mais ne change pas le verdict des classifieurs Google sur le pattern UX. C’est un investissement utile dans un second temps, pas une condition de levée de l’alerte.

Besoin d’un audit de sécurité ou d’un accompagnement personnalisé ?
Vous faites face à une alerte de sécurité dans Google Search Console, ou vous souhaitez sécuriser proactivement votre site WordPress et ses sous-domaines ? Réservez un échange découverte de 30 minutes en visioconférence pour évaluer ensemble votre situation et les actions prioritaires.
Réserver un échange de 30 minutes en visio

Alerte « Pages trompeuses » dans Google Search Console : étude de cas et méthode de résolution en 14 jours