Le referrer spam : quand vos logs racontent n’importe quoi
Le referrer spam, ou spam de référent, consiste à envoyer des requêtes vers votre site avec un faux header Referer.
Résultat : vos logs Apache ou Nginx affichent soudain des domaines étranges, souvent sans rapport avec votre contenu. Vous avez l’impression que des visiteurs arrivent depuis des sites douteux pour lire une analyse économique, un exposé de littérature espagnole, Don Alvaro ou Dona Inés. Ambiance.
En réalité, ces “visiteurs” ne visitent souvent rien du tout. Ils bombardent votre serveur, polluent vos statistiques, consomment parfois de la bande passante, et espèrent surtout attirer votre curiosité vers leurs domaines.
Pourquoi l’ancienne méthode par grosse blacklist ne suffit plus
À l’époque, la solution classique consistait à empiler des dizaines de règles dans le fichier .htaccess. Cela fonctionnait, mais cette approche vieillit mal.
- Les domaines de spam changent constamment.
- Les expressions régulières trop larges peuvent bloquer du trafic légitime.
- Une redirection vers un autre site gaspille des ressources.
- Un long
.htaccessdevient vite illisible. - Le header
Refererpeut être falsifié facilement.
Aujourd’hui, il vaut mieux procéder par étapes : mesurer, bloquer ce qui est clairement abusif, puis garder la configuration courte et maintenable.
Étape 1 : confirmer le spam dans les logs
Avant de bloquer quoi que ce soit, commencez par regarder vos logs. Sur Apache, vous pouvez extraire les référents les plus fréquents avec une commande simple.
awk -F\" '{print $4}' /var/log/apache2/access.log | sort | uniq -c | sort -nr | head -50
Sur Nginx, le principe reste le même si votre format de log contient le référent.
Vos mises à jour vous font peur ?
PHP 8.x qui casse un plugin, un thème qui n'est plus maintenu, une mise à jour de WooCommerce qui change tout — je gère les montées de version proprement, avec environnement de staging et rollback prévu.
Mettons votre stack à jour sans risque →awk -F\" '{print $4}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -50
Si un domaine inconnu envoie des centaines ou milliers de requêtes sans cohérence avec vos contenus, vous avez probablement trouvé le coupable.
Étape 2 : bloquer proprement avec Apache
Avec Apache, vous pouvez utiliser mod_rewrite pour refuser les requêtes qui arrivent avec un référent indésirable.
Placez ce bloc dans le vhost Apache si vous avez accès à la configuration serveur. Sinon, vous pouvez l’utiliser dans le fichier .htaccess, en restant prudent.
RewriteEngine On
RewriteCond %{HTTP_REFERER} bad-domain-example\.com [NC,OR]
RewriteCond %{HTTP_REFERER} another-spam-domain\.tld [NC]
RewriteRule ^ - [F,L]
La règle renvoie un 403 Forbidden. C’est plus propre qu’une redirection vers un site tiers. Le serveur refuse la requête, point final.
Évitez les listes interminables. Bloquez uniquement les domaines qui provoquent un vrai volume de requêtes. Sinon, vous transformez votre configuration en musée des horreurs.
Étape 3 : bloquer avec Nginx
Sur Nginx, le module ngx_http_referer_module permet de filtrer les requêtes selon le header Referer. Là encore, ce n’est pas une protection parfaite, mais c’est efficace contre du spam massif et basique.
valid_referers none blocked server_names
*.skyminds.net
~bad-domain-example\.com
~another-spam-domain\.tld;
if ($invalid_referer) {
return 403;
}Code language: PHP (php)
Testez toujours la configuration avant de recharger Nginx.
sudo nginx -t
sudo systemctl reload nginx
Attention : ne bloquez pas tous les visiteurs sans référent. Beaucoup de requêtes légitimes n’envoient aucun Referer, selon le navigateur, la politique de confidentialité, l’application ou le contexte de navigation.
Étape 4 : bloquer à l’edge avec Cloudflare
Si votre domaine passe par Cloudflare, le plus efficace consiste souvent à bloquer avant même que la requête touche votre serveur d’origine.
Dans Cloudflare, créez une règle WAF personnalisée avec une expression proche de celle-ci :
(http.referer contains "bad-domain-example.com") or (http.referer contains "another-spam-domain.tld")Code language: CSS (css)
Choisissez ensuite l’action Block ou Managed Challenge. Pour du spam évident, le blocage direct suffit généralement.
Cloudflare permet aussi d’utiliser des règles de limitation de débit. C’est utile si le problème vient moins d’un référent précis que d’un volume anormal de requêtes sur certaines URL.
Étape 5 : nettoyer les statistiques dans Google Analytics 4
Le referrer spam peut aussi polluer les outils d’analyse. Dans GA4, Google propose une liste de référents indésirables. Elle sert surtout à éviter que certains domaines soient comptés comme sources de trafic référent.
Chemin courant dans GA4 : Admin → Flux de données → votre flux web → Configurer les paramètres de balise → Afficher plus → Répertorier les référents indésirables.
Cette action ne bloque pas les requêtes serveur. Elle corrige seulement l’interprétation des données côté Analytics. Pour protéger votre hébergement, bloquez côté serveur ou côté Cloudflare.
Tester une règle de blocage
Vous pouvez simuler une requête avec un faux référent grâce à curl.
curl -I -e "https://bad-domain-example.com/" https://www.skyminds.net/Code language: JavaScript (javascript)
Si votre règle fonctionne, vous devez obtenir une réponse 403, ou une réponse Cloudflare correspondant à l’action choisie.
Bonnes pratiques anti-referrer spam
- Ne bloquez pas sur des mots trop génériques comme
sex,loanoucasinosans vérifier le contexte. - Ne redirigez pas les spammeurs vers un autre site : renvoyez un
403. - Gardez une liste courte, fondée sur vos logs réels.
- Préférez Cloudflare ou le vhost serveur au fichier
.htaccessquand c’est possible. - Testez chaque règle avant de la déployer largement.
- Surveillez les logs après modification pour éviter les faux positifs.
Exemple de stratégie simple
Pour un site WordPress classique, je recommande cette approche :
- Identifier les référents suspects dans les logs.
- Vérifier le volume réel des requêtes.
- Bloquer les domaines abusifs à l’edge avec Cloudflare si disponible.
- Ajouter une règle Apache ou Nginx seulement si Cloudflare n’est pas en frontal.
- Nettoyer les rapports GA4 avec la liste des référents indésirables.
- Recontrôler les logs après 24 à 48 heures.
Cette méthode évite la grosse artillerie. Elle garde votre configuration lisible, limite les faux positifs et réduit la charge côté serveur.
Conclusion
Le referrer spam n’a rien de nouveau. Ce qui a changé, c’est la bonne manière de le traiter.
La vieille blacklist géante dans .htaccess peut encore dépanner, mais elle ne doit plus être votre premier réflexe. Aujourd’hui, il vaut mieux analyser les logs, bloquer précisément, utiliser Cloudflare quand le site passe déjà par son proxy, puis nettoyer les données Analytics séparément.
Moins de bruit dans les logs, moins de requêtes inutiles, moins de bricolage. Et un serveur qui respire mieux.
Sources et documentation
- Documentation Apache : mod_rewrite
- Documentation Nginx : ngx_http_referer_module
- Documentation Cloudflare : WAF custom rules
- Documentation Cloudflare : champ http.referer
- Documentation Cloudflare : rate limiting rules
- Documentation Google Analytics : référents indésirables
Marre des agences qui sous-traitent ?
Avec moi, vous parlez directement au développeur qui fait le travail. Pas d'intermédiaire, pas de promesses creuses. Juste du code propre et un interlocuteur joignable.
Travaillons directement ensemble →
