Limiter les requêtes par IP sur PrestaShop sans bloquer Google

Lundi matin. La boutique est tombée deux fois dimanche, le journal d’accès montre trois adresses qui ont demandé quatre-vingt mille pages chacune, et vous les bloquez sur le serveur. Vous êtes tranquille. Mardi, quarante nouvelles adresses font exactement la même chose.

Bloquer par adresse est la première réaction de tout le monde et celle qui dure le moins. Non parce que l’idée est mauvaise, mais parce que le problème n’est pas qui demande, mais combien. Et cela se mesure, cela ne se devine pas.

Pourquoi bloquer des adresses ne finit jamais

Un robot qui parcourt votre catalogue ne vient pas d’une adresse : il vient d’un réseau, ou de plusieurs, et il tourne. Quand vous en coupez une, il continue avec la suivante sans perdre le rythme. Même chose avec les noms : ils se présentent comme un navigateur ordinaire, changent d’identité chaque semaine et trois nouveaux apparaissent chaque mois. La liste de blocage grossit et la charge ne baisse pas.

Ce qu’ils ne peuvent pas déguiser, c’est la cadence. Une personne qui achète ouvre une catégorie, coche deux filtres, tourne une page et va sur la fiche produit : trois ou quatre recherches coûteuses sur toute la visite. Un robot en fait trois ou quatre par seconde, depuis chaque adresse qu’il utilise. Compter combien de recherches coûteuses fait chaque origine en une minute distingue les deux sans avoir besoin de connaître leur nom.

Ce qu’est la limitation par IP, et pourquoi aussi par réseau

Limiter par IP, c’est poser un plafond : combien de requêtes la boutique accepte d’une même adresse dans une fenêtre de temps — soixante secondes, en général. Sous le plafond, tout passe ; au-dessus, la requête reçoit un « revenez dans un moment » qui ne coûte rien à servir.

Avec cela seul, un robot qui répartit le travail entre deux cents adresses du même réseau reste sous le plafond sur chacune. C’est pourquoi la deuxième limite est par réseau : les adresses qui partagent leurs trois premiers blocs (ce qu’un technicien appelle un /24) sont comptées ensemble. Un opérateur mobile peut ressembler à cela, donc ce plafond est plus haut que celui par adresse, mais tourner cesse d’être gratuit. Et un troisième frein, pour toute la boutique, sert de limite d’urgence : quand le total de recherches par minute dépasse ce que votre serveur supporte confortablement, seuls passent les visiteurs qui ont déjà prouvé être des personnes.

Où mettre la limite : sur le serveur ou dans la boutique

Il y a trois endroits où l’on peut compter, et ils ne voient pas la même chose.

• Sur le CDN (les règles de limitation de Cloudflare, par exemple). Il compte par adresse et par motif d’URL. Il ne sait pas quelle requête est coûteuse et laquelle est une image, ne sait pas si le visiteur est connecté, et traite Googlebot comme n’importe qui. Pour un pic d’un après-midi, ça marche ; pour vivre ainsi, soit vous freinez trop vos clients, soit pas assez les robots.
• Sur le serveur web (les modules de limitation d’Apache ou de nginx, ou fail2ban qui lit le journal). Il compte tout ce qui entre, CSS et photos compris, donc le plafond doit être si haut qu’il freine à peine. Et il faut savoir administrer un serveur pour y toucher, ce qui n’est même pas permis sur un hébergement mutualisé.
• Dans la boutique elle-même, avant que PrestaShop ne commence à chercher. C’est le seul endroit qui sait ce qui est coûteux : une recherche filtrée, le moteur de recherche, une page de liste, un changement de tri. Seul cela compte pour la limite. Il sait si le visiteur est connecté — et alors ne le limite pas — et peut vérifier si celui qui se dit Googlebot l’est vraiment. C’est là que le place Anti-Bots pour PrestaShop, et c’est pourquoi la limite peut être basse sans gêner personne qui achète.

Comment laisser entrer Google

C’est la peur qui retient la plupart des gens, et à raison : une limite mal réglée vous efface de Google tout seul. La réponse n’est pas une liste de noms, car n’importe qui peut se présenter comme Googlebot : c’est de demander au réseau. Chaque requête qui prétend venir de Google est vérifiée par une résolution DNS inverse, et si l’adresse n’appartient pas à Google, cette requête ne vient pas de Google, quoi qu’elle dise.

Les moteurs vérifiés entrent avec leur propre quota, séparé de celui des visiteurs, et reçoivent les pages de filtres marquées comme non indexables. C’est exactement ce que Google recommande pour la navigation à facettes : les combinaisons de filtres ne doivent pas devenir des milliers de pages répétées. Quand vous cessez de gaspiller son temps dessus, il explore mieux celles qui vous intéressent.

Que se passe-t-il quand quelqu’un dépasse la limite

Un script reçoit un « trop de requêtes » avec l’heure à laquelle il peut revenir, et cela ne coûte rien à votre base de données. Mais une limite par adresse a un cas gênant : le bureau avec trente personnes derrière une seule connexion, ou le client qui filtre très vite. Ceux-là, il ne faut pas les mettre dehors : il faut vérifier que ce sont des personnes.

La vérification qui marche est celle qu’on ne voit pas. Une preuve de travail — un petit calcul que le navigateur résout seul en quelques millisecondes, sans puzzle ni case à cocher — et un laissez-passer d’une heure. Le laissez-passer n’exempte pas totalement, parce que résoudre cette preuve est aussi bon marché pour un script : celui qui en porte un garde un plafond par adresse, simplement dix fois plus haut.

Les chiffres pour commencer

Avec une fenêtre de soixante secondes, trente recherches coûteuses par adresse, quatre-vingt-dix par réseau et six cents pour toute la boutique couvrent l’immense majorité des boutiques sans qu’aucun client ne s’en aperçoive. Un client rapide en fait vingt en une minute ; trente, c’est déjà quelqu’un qui ne regarde pas ce qu’il filtre.

Si vous ne lui faites pas encore confiance, il y a un mode observation : la limite regarde et note ce qu’elle aurait arrêté, mais laisse tout passer. Une semaine ainsi, et le panneau vous dit combien de requêtes seraient restées à la porte et d’où elles venaient, et vous décidez avec des données.

Comment savoir si la limite est bien réglée

Une limite qu’on ne mesure pas est une limite qui, un jour, gêne un client sans que vous le sachiez. Ce qu’il faut regarder chaque semaine, ce sont trois choses : combien de recherches coûteuses ont été servies et combien arrêtées, quelles origines ont été arrêtées le plus et pour quel motif, et si l’une d’elles est à vous — votre moniteur de disponibilité, votre comparateur de prix, un client qui s’est plaint. Celle-là reçoit un clic de confiance et n’est plus jamais comptée.

Et pour les doutes, un vérificateur : collez l’adresse et le navigateur qui figurent dans le journal, la page demandée, et il vous dit exactement ce qu’il ferait de cette requête maintenant et pourquoi. C’est la façon de toucher une limite sans le faire à l’aveugle.

Tout cela — les trois plafonds, le rebond de cookies, Google vérifié par DNS, la vérification invisible, le mode observation et le panneau avec le vérificateur — est ce que fait Anti-Bots pour PrestaShop dès la minute où il est installé, sur PrestaShop 1.7.6 à 9 et derrière Cloudflare. Et si vous voulez d’abord savoir si le problème est bien celui-là, envoyez-nous le journal d’accès d’une mauvaise journée via le formulaire de contact : nous vous dirons gratuitement combien de ces requêtes sont des personnes et combien sont du bruit.