Un site qui ralentit soudainement n’est pas toujours victime d’une attaque. Il peut aussi recevoir trop de requêtes de robots légitimes. Le crawler de Facebook, souvent visible dans les logs sous le user-agent facebookexternalhit, fait partie des robots à vérifier.
Son rôle est normal : quand une page est partagée sur Facebook, Messenger ou une propriété Meta, le crawler lit la page et ses balises Open Graph pour générer l’aperçu du lien. Le problème arrive quand ces requêtes contournent le cache, tombent sur des pages lourdes ou se répètent pendant que le serveur est déjà limite.
Ce qu’il faut confirmer avant d’agir
Il ne faut pas bloquer Facebook au premier ralentissement. On commence par valider les faits.
- Lire les logs serveur : cherchez
facebookexternalhit, les codes de réponse, les URLs touchées et l’heure des pics. - Comparer avec le monitoring : CPU, mémoire, temps de réponse, erreurs 5xx, cache hit ratio si vous utilisez Cloudflare ou un cache serveur.
- Regarder les pages concernées : une page sans cache, une image trop lourde ou une redirection peut coûter cher quand elle est demandée plusieurs fois.
Ce que Facebook vient chercher
Le crawler lit surtout ce qui permet de bâtir un aperçu fiable : titre, description, image et URL canonique. Sur WordPress, ces informations viennent souvent de Rank Math, Yoast ou du thème.
Si les balises Open Graph sont absentes, contradictoires ou lentes à charger, Facebook peut afficher un aperçu incomplet. Après une correction, l’outil Sharing Debugger de Meta permet de tester une URL et de demander une nouvelle lecture de la page.
Corriger sans casser les partages
L’objectif n’est pas de rendre vos liens invisibles sur Facebook. L’objectif est que les aperçus fonctionnent sans forcer le serveur à reconstruire toute la page à chaque requête.
- Cache pleine page : les robots doivent recevoir une version déjà générée quand c’est possible.
- Images Open Graph raisonnables : une image claire, stable et bien compressée évite des téléchargements lourds.
- Balises propres : un seul titre, une seule description, une image déclarée, une URL canonique cohérente.
- Règles mesurées dans le pare-feu : si les logs confirment un excès, Cloudflare permet de créer des règles de limitation basées sur une expression, une période et une action. À tester prudemment pour ne pas nuire aux aperçus ni aux robots utiles.
Ce qu’il vaut mieux éviter
- Bloquer tous les robots parce qu’un pic a eu lieu une fois.
- Ajouter une règle agressive sans regarder les logs avant et après.
- Se fier seulement à Google Analytics : les robots n’y apparaissent pas toujours comme des visiteurs humains.
- Laisser des pages importantes sans cache parce qu’elles contiennent un formulaire ou un script tiers.
Une vérification utile pour les PME
Pour une PME, ce dossier se règle souvent avec une séquence simple : logs, cache, balises Open Graph, test dans Sharing Debugger, puis règle serveur seulement si les chiffres le justifient. Ça évite de transformer un problème ponctuel en blocage qui nuit aux partages sociaux.
Sources techniques : documentation Meta sur le crawler, Sharing Debugger et règles de rate limiting Cloudflare.
Voir aussi : sécuriser un site WordPress.
Les banques d’heures Beriox servent bien à ce type d’intervention : vérifier, corriger, documenter et laisser le site plus stable qu’avant.