Hello,
We are currently dealing with a massive wave of AI bot and scraper traffic (GPTBot, ClaudeBot, Bytespider, curl, etc.) hitting our standard CloudPages—experiencing around 20 million hits recently. Because these requests load successfully and return a standard 200 OK, they are rapidly consuming our Super Message budget. We are actively working on mitigation strategies, but our infrastructure has a mixed setup, which brings up a few challenges:
- Self-Hosted Domains For our self-hosted domains, we know the best practice is to handle this at the edge. We are looking to configure WAF rules via Cloudflare to drop or challenge these malicious IPs and User-Agents before they even reach ExactTarget servers.
- Delegated Domains For domains fully delegated to Salesforce, SF controls the DNS and the edge routing. This means we cannot simply put our own Cloudflare/WAF in front of it to drop the traffic.
- Our Current Internal Workaround using SSJS While we figure out the network-level blocks, we’ve implemented a pure SSJS script on Line 1 of our CloudPages. It reads the User-Agent and, if it matches our bot blacklist, we immediately trigger Platform.Function.RaiseError to abort the page and throw a 500 Internal Server Error. According to official documentation, since it doesn't return a 200 OK, it shouldn't count as a billable CloudPage impression (we are waiting for SF Support to definitively confirm this).
My questions for the community:
Delegated Domains Protection: Has anyone successfully requested Salesforce Support to implement custom WAF rules (IP or User-Agent blocking) for a specific tenant on delegated domains? Billing: Can anyone confirm from their own billing reports if the RaiseError (500 status) workaround successfully prevents the Super Message consumption in practice? Are there any other native SFMC settings or alternative architectures we should consider to protect delegated domains from this aggressive scraping?
Thanks in advance for any insights!
Hi Andreea!
There is actually a recent Salesforce guidance specifically covering LLM crawler/bot traffic and CloudPages billing, so your approach is aligned with the documented mitigation strategy.
Salesforce confirms that a CloudPages impression is counted when the request returns HTTP 200, including successful requests from bots/crawlers. A non-200 response therefore avoids that CloudPages impression charge.
Salesforce also documents an SSJS-based approach to detect known bot User-Agents and terminate the request before a successful page response. The guidance specifically recommends putting the check at the beginning of the page.
For your three questions:
- Delegated domains: CloudPages doesn't provide native IP restrictions or authentication. If the domain is fully delegated to Salesforce, you don't have the same edge-WAF control as you would when your own DNS/CDN sits in front of the page.
- RaiseError/500: Salesforce's billing documentation states that successful 200 OK requests are CloudPages impressions. So a request terminated with a 500 should not be counted as a CloudPages impression, but I'd still have Support confirm the behavior against your specific account/billing report.
- Alternative architecture: Salesforce's current guidance also suggests using Code Resources for endpoints that don't need to render a normal landing page. Code Resources do not consume Super Messages, which can be useful for processing/API-style endpoints.
For self-hosted domains, blocking the traffic at Cloudflare/Akamai/AWS WAF before it reaches Salesforce is still preferable because it prevents the request from reaching the CloudPages infrastructure in the first place.
