Ce qui frappe un petit site chaque semaine : nos logs

Entre le 23 septembre et le 7 octobre 2026, ce site a reçu 5 213 requêtes, soit environ 353 par jour. Parmi elles, 3 304 (63,4 %) venaient de scanners qui réclamaient des fichiers que le site n’a jamais eus : des fichiers .env, des pages de connexion WordPress, des dossiers .git, des web shells. Elles provenaient de 190 adresses distinctes et visaient 1 059 chemins distincts. Nous publions des totaux, jamais des adresses.

Ce guide ne repose sur aucune règle AdSense, car Google ne dit rien du trafic des scanners. Nous le publions pour deux raisons pratiques : il change la façon de lire votre propre rapport de 404, et le seul chiffre qui compte ici, le nombre de sondes qui ont obtenu une réponse 200, se vérifie en 5 minutes sur votre site.

Deux semaines de requêtes, en chiffres

La fenêtre couvre 14,8 jours, sur un site de 3 mois. Les erreurs client représentent 3 336 des 5 213 requêtes (64 %), dont 3 317 sont de simples 404. Les sondes ont atteint en moyenne environ 223 requêtes par jour, soit à peu près 1 560 par semaine.

Les 190 adresses ont envoyé en moyenne environ 17 requêtes chacune, et chaque chemin a été demandé environ 3 fois en moyenne : les mêmes chemins reviennent sans cesse. Les plus demandés sont /wp-admin/install.php (191 requêtes) et /xmlrpc.php (44), suivis de nombreuses variantes de .env.

Comparez avec les 404 que nous savons expliquer. Des clients ordinaires ont demandé /favicon.ico 15 fois, /llms.txt 8 fois et /sitemap.xml 3 fois, soit 26 au total, et nous avons corrigé cela le 7 octobre. Le total des 404 et celui des sondes sont proches (3 317 et 3 304), mais ce sont deux décomptes différents, car une sonde peut recevoir autre chose qu’un 404 : ne soustrayez pas l’un de l’autre. La lecture utile est plus simple : sur un petit site, le nombre brut de 404 renseigne très peu sur les liens cassés.

Ce qu’elles cherchaient

Nous avons classé les 3 304 requêtes de sondes par type de fichier demandé. Les parts sont calculées sur les requêtes de sondes, et le chiffre quotidien est la moyenne sur 14,8 jours.

Les fichiers d’environnement arrivent largement en tête, et pour une raison : un fichier .env contient en général un mot de passe de base de données ou une clé d’API, si bien qu’un seul fichier exposé peut livrer toute une application. Les 553 requêtes WordPress ont visé un site qui n’a jamais tourné sous WordPress. Les scanners ne vérifient pas ce que vous utilisez : ils posent les mêmes questions à tout le monde.

La plus petite catégorie est celle que nous avons trouvée la plus parlante. Les 39 requêtes de configuration d’outils d’IA visaient des fichiers comme .anthropic, .claude et .env.openai. Nous y lisons des scanners qui vont là où se trouvent désormais les clés d’API, mais c’est notre interprétation : les journaux enregistrent la requête, pas le motif.

Pourquoi rien n’a été exposé

Aucune sonde n’a reçu de réponse 200. La raison est structurelle : c’est un site statique, sans WordPress, sans PHP et sans fichier .env dans le dossier que le serveur publie. Demandez /.env et vous obtenez un 404. Il n’y avait rien à trouver, donc rien n’a été trouvé.

C’est donc le nombre de réponses 200 qu’il faut surveiller, et non le nombre de sondes, sur lequel vous n’avez pas de prise. Une sonde qui reçoit un 200 signifie l’une de ces deux choses : un vrai fichier est public, ou votre site répond par une page à toute URL inconnue. Le second cas est un soft 404, dont la cause habituelle est une route fourre-tout dans une application monopage, ou un CMS qui affiche sa page d’accueil pour n’importe quel chemin. La documentation de Google décrit un soft 404 comme une page d’erreur servie avec un statut 2xx, et la Search Console le signale. Soft 404 et codes HTTP montre comment renvoyer la bonne réponse, et notre vérificateur AdSense demande une URL volontairement inventée pour voir laquelle votre serveur donne.

5 choses à faire sur votre propre site

1. Refusez les fichiers cachés, sauf .well-known. Le renouvellement des certificats et d’autres standards utilisent /.well-known/ : tout le reste de ce qui commence par un point peut donc répondre 404.

# nginx, à l'intérieur du bloc server
location ~ /\.(?!well-known/) {
    return 404;
}

# Apache 2.4, dans le virtual host ou le .htaccess (mod_alias)
RedirectMatch 404 "/\.(?!well-known/)"

2. Gardez secrets, sauvegardes et dépôts hors du dossier publié. Publiez un dossier de build, jamais la racine du projet, et excluez .git et .env* de votre déploiement. Cherchez ensuite ce qui est passé entre les mailles :

find /var/www/example.com -type f \( -name '.env*' -o -name '*.bak' -o -name '*.old' -o -name '*.sql' -o -name '*.zip' -o -name '*.swp' -o -name '*~' \) -print
find /var/www/example.com -type d \( -name .git -o -name .svn \) -print

3. Vérifiez que les URL inconnues répondent 404. Les deux commandes doivent afficher 404. Un 200 signale le problème décrit plus haut.

curl -s -o /dev/null -w '%{http_code}\n' https://example.com/.env
curl -s -o /dev/null -w '%{http_code}\n' https://example.com/no-such-page-7f3a

4. Sur WordPress, mettez à jour et fermez ce que vous n’utilisez pas. Gardez le cœur, les thèmes et les extensions à jour, supprimez le fichier readme.html de la racine car il indique la version, et refusez xmlrpc.php sauf si une extension ou l’application mobile en a besoin. C’est le cas de Jetpack et de certaines applications.

# nginx
location = /xmlrpc.php { return 404; }

# Apache 2.4
<Files "xmlrpc.php">
    Require all denied
</Files>

5. Freinez les récidivistes, et gardez des journaux courts. Avec fail2ban, le principe tient en une règle : bannir une adresse pendant quelques heures après plusieurs requêtes vers des chemins qui renvoient 404 en quelques minutes. Voyez-y une réduction du bruit, pas une protection. Notre protection, c’est de n’avoir rien à trouver. Faites tourner les journaux et supprimez-les selon un calendrier : les nôtres partent au bout d’environ 14 jours, comme l’annonce notre politique de confidentialité.

Les compter dans votre propre journal

Ces commandes supposent le format de journal combiné que nginx et Apache écrivent tous deux par défaut. Elles affichent des totaux et des chemins, jamais des adresses : le résultat peut donc être partagé. Elles s’en tiennent aux fonctions awk de POSIX, et devraient tourner aussi bien avec mawk qu’avec gawk. Commencez par extraire les sondes dans un fichier, une ligne par requête (catégorie, statut, chemin) :

LOG=/var/log/nginx/access.log

awk -F'"' '
  { split($2, r, " "); split($3, s, " "); p = tolower(r[2])
    if (p ~ /\.env/)                                                      c = "environment files"
    else if (p ~ /\/\.(git|svn|hg)(\/|$)/)                                c = "version control"
    else if (p ~ /\/wp-(admin|login|content|includes|json)|xmlrpc\.php/)  c = "wordpress"
    else if (p ~ /\/\.(aws|ssh|docker|kube)(\/|$)|id_rsa|aws\/credentials/) c = "cloud and credentials"
    else if (p ~ /\.(php|phtml|phar)(\?|$)/)                              c = "php and web shells"
    else if (p ~ /\.(bak|old|sql|zip|tar|gz|swp)(\?|$)|composer\.(json|lock)|package\.json/) c = "backups and dependencies"
    else next
    printf "%s\t%s\t%s\n", c, s[1], p }' "$LOG" > probes.tsv

Lisez-le ensuite :

wc -l < "$LOG"                                         # toutes les requêtes
wc -l < probes.tsv                                     # requêtes de sondes
cut -f1 probes.tsv | sort | uniq -c | sort -nr         # sondes par catégorie
cut -f3 probes.tsv | sort | uniq -c | sort -nr | head  # chemins les plus demandés
awk -F'\t' '$2 == 200' probes.tsv                      # sondes ayant reçu un 200 : ne doit rien afficher
awk '{ print $1 }' "$LOG" | sort -u | wc -l            # adresses distinctes, en nombre seulement

Vos catégories ne coïncideront pas exactement avec les nôtres. Nous avons trié avec une liste de règles plus longue et rangé certains chemins dans « Autres » ou dans « Interfaces d’administration et API », que ces motifs ne couvrent pas. Les étiquettes du script sont en anglais ; ce ne sont que des chaînes de caractères, vous pouvez les renommer. Les règles supposent aussi un site qui ne sert légitimement ni PHP ni composer.json. Si le vôtre le fait, les décomptes incluront du trafic réel, et le contrôle des 200 signalera de vraies pages.

Ce que ces données ne disent pas

Un site, une fenêtre de 14,8 jours, un domaine jeune, une configuration d’hébergement. Nous ne savons pas comment ces proportions se comparent aux vôtres, comment elles évoluent sur un an, ni si un site plus gros attire un autre mélange. Les catégories viennent de nos propres règles. Le nombre d’adresses distinctes est un nombre d’adresses, pas d’opérateurs ni de machines. Rien ici ne montre ce que visait un scanner en particulier.

Ce que les chiffres autorisent à dire est plus étroit : les sondes sont de routine, elles interrogent tout le monde, et elles ne comptent que là où quelque chose répond. Les bloquer n’est pas une protection, mais retirer ce qu’elles cherchent en est une. Les couches suivantes sont les en-têtes de sécurité et une configuration HTTPS correcte, et les visiteurs légitimes des mêmes journaux, Googlebot, Bing et les robots d’IA, sont détaillés dans qui crawle un petit site.