Le 1er juillet 2026, Cloudflare a annoncé un réglage par défaut qui va remodeler le trafic des sites de contenu : à partir du 15 septembre 2026, les pages affichant des publicités bloqueront par défaut les crawlers d'IA « à usage mixte ». Dans le même temps, l'expérimentation Pay Per Crawl s'élargit en un modèle Pay Per Use.

Qui est bloqué, qui ne l'est pas

Cloudflare répartit le comportement des crawlers en trois catégories, et cette répartition est la clé pour comprendre le changement :

  • Search : collecter et indexer du contenu pour répondre à des questions plus tard — toujours autorisé.
  • Agent : comportement automatisé agissant en temps réel pour le compte d'une personne — bloqué par défaut sur les pages publicitaires.
  • Training : récupérer du contenu pour entraîner ou affiner un modèle — bloqué par défaut sur les pages publicitaires.

Ces nouveaux réglages s'appliquent aux nouveaux clients, aux nouveaux sites ajoutés par des clients existants, et à tous les clients existants de l'offre gratuite. Autrement dit, de nombreux éditeurs indépendants verront le comportement changer le 15 septembre sans rien avoir touché. Les propriétaires peuvent modifier ces valeurs dans leurs réglages. Parmi les premiers partenaires du Pay Per Use figurent Ceramic.ai (qui rémunère les éditeurs lorsque leur contenu apparaît dans des résultats de recherche) et You.com (qui paie lorsqu'un agent accède à du contenu premium).

Ce que cela signifie pour un site auto-hébergé

Si vous diffusez de la publicité et qu'une part notable de votre exposition provient des réponses et des agents d'IA, ce réglage peut réduire à la fois votre charge serveur et votre visibilité. La facture de bande passante s'allège ; les chances d'être cité dans une réponse d'IA diminuent — et la citation devient discrètement un canal de trafic à part entière. Si vous ne diffusez pas de publicité et monétisez par votre propre produit ou service, le réglage ne change rien automatiquement, et c'est à vous de décider qui autoriser.

Quatre actions utiles dès maintenant

  • Mesurez avant de décider : à partir de vos journaux Nginx/Apache, ventilez requêtes et bande passante par User-Agent pour GPTBot, ClaudeBot, PerplexityBot, CCBot et Bytespider, et comparez ce coût aux visites que chacun vous renvoie réellement.
  • Graduez l'accès plutôt que de claquer la porte : autorisez les crawlers de recherche, qui restent un canal de visibilité ; restreignez les crawlers purement d'entraînement ; interdisez d'emblée les chemins d'administration, les espaces membres et les pages de filtres dupliquées.
  • Gardez votre propre point de contrôle : robots.txt n'est qu'un accord de bonne foi. Utilisez limit_req et limit_conn de Nginx par User-Agent ou par IP, et renvoyez un 403 lorsque cela se justifie, plutôt que de déléguer toute la politique à un réglage amont.
  • Surveillez les données de référence autour de la date : établissez une base avant et après le 15 septembre, puis décidez de maintenir le blocage ou de rouvrir.

Pourquoi cela renforce la valeur d'un VPS

Dès lors que « qui a le droit de m'explorer » devient une décision commerciale active, il faut accéder à la couche où cela se configure. En mutualisé, vous ne pouvez pas écrire de règles de limitation, ni consulter des journaux complets, ni appliquer une politique par User-Agent. Sur votre propre VPS, tout cela vous appartient. Les offres SharkCloud incluent des IP dédiées et des spécifications de ressources claires, avec des nœuds à Hong Kong, au Japon et aux États-Unis pour héberger au plus près de votre audience — l'interrupteur reste entre vos mains.