Ecommerce bot protection when some bots are buyers

Ecommerce bot protection is the set of rules that decide which automated visitors reach your catalog, cart and checkout, and since some AI agents buy for real shoppers, the job is to sort bots, not block them all.

That retires the old default of ecommerce bot prevention: keep every bot out. Shopify's Fall '26 Edition, dated October 28, 2026, "opens Shopify's catalog, cart, and checkout to any agent or app" (Shopify). Meanwhile the blunt switch catches buyers: Cloudflare's Agent policy covers "browser-use agents", and each of its AI policies "applies to Verified bots with that behavior and matching unverified bots" (Cloudflare).

For store owners and developers on any platform, before Cyber 5 (November 26 to 30, 2026): the three kinds of bots, how to tell a buying agent from an impostor, where to set each rule, and the GA4 fix for bot traffic.

What ecommerce bot protection covers#

Bot detection decides what a request is; bot mitigation decides what happens to it. Ecommerce bot protection makes that call for every crawler, script and agent that reaches a store, with one of four answers: allow, rate-limit, challenge or block. It's made at four layers: the edge (your CDN), the WAF, the platform's own settings, and the payment gateway, the card testers' real target.

Ecommerce bot prevention isn't fraud prevention. Shopify says its checkout Bot protection is "meant only to limit the effectiveness of auto-checkout bots and isn't meant to combat forms of fraud that are related to bot activity" (Shopify), and Mastercard reminds merchants that "Certification adds a layer of trust; it does not replace your existing risk management" (Mastercard). No layer is a guarantee, and each puts some friction on real shoppers.

Why "block all bots" now blocks customers#

Because some of the bots are shopping. Shopify's developer announcement says "Every Shopify store is agent-ready by default", with WebMCP tools that let browser agents "search products, update the cart, and complete checkout once the buyer approves" (Shopify). The checkout part came first: TechCrunch reported on September 28, 2026 that "browser-based AI agents can now complete purchases on Shopify merchants' sites" (TechCrunch). And Shopify's merchant announcement says "Shop Pay stays secure with tokens from Mastercard, Visa, Discover, and coming soon, American Express, for agent purchases from merchants off Shopify" (Shopify).

Identity already sets the rate limits. In a changelog entry posted May 7, 2026, Shopify said "Bots and agents that don't sign their requests are subject to the strictest limits", and that operators "should sign their requests with Web Bot Auth" to qualify for more (Shopify). OpenAI's Merchant Feed Terms, updated October 13, 2026, have feed merchants let its agents in, "including by allowlisting OpenAI's and its Affiliates' signed Web Bot Auth traffic" (OpenAI). Our guide covers how to keep ChatGPT's shopping crawler and feed working under those terms.

The bad bots didn't leave. Radware's 2026 E-Commerce Bot Threat Report found that on the retail sites Radware protects, bad bots made up 43% of traffic during Cyber 5 2025, against 46% humans and 11% good bots. A year earlier the split was 31% bad bots, 42% humans and 27% good bots, and over the whole 2025 holiday season bad bots took 41% (Radware). That's a vendor's own customers, with no sample size given: a direction, not a census.

Keep one number out of this story. Adobe expects AI traffic to US retail sites over the 2026 holiday season to rise 130% year over year, "measured by shoppers clicking on a link" (Adobe). That's people arriving from AI tools, not bots.

Mastercard's merchant playbook is blunt: "The worst response to consumer-owned agents is to block them indiscriminately" (Mastercard).

Good bots, bad bots and buying agents#

Good bots vs bad bots is a two-box answer to a three-box problem:

• Search and service bots. Googlebot, Bingbot, AI search crawlers, uptime monitors, feed fetchers. Verify them, then let them in.
• Abusive automation. Card testers, credential stuffers, scalpers, scrapers. Slow them, challenge them or block them.
• Agents acting for a buyer. Software that browses, fills a cart and checks out for a shopper, signed or not. Treat it like a customer who came in by the side door.

Mastercard's developer playbook splits agents into five levels (Mastercard). Certified agents, registered with a card network, get "Full access. Streamlined checkout. Reduced friction." Anonymous ones get "Open discovery. Higher checkout friction. Rate limiting. Behavioral analysis." Malicious ones get "Block. Report." And browsing stays open: "Product pages, search, and category browsing should be open to all agents."

Which AI crawlers get in is a business decision for an AI crawler policy, not whatever the person with the CDN login clicked last.

Crawlers vs agents#

A crawler reads pages on its own schedule; an agent acts in real time for one person. Cloudflare's AI Crawler and Agent access policies (formerly Configure AI bot policies) set an action for Search, Agent and Training, and define Agent as "automated activity acting in real time on a person's behalf, such as chat fetch bots and browser-use agents"; Cloudflare "recommends Allow (do not block) for Personal Agents" (Cloudflare). So read any setting to block AI bots before you flip it: the Agent policy is where the buyers are.

A user agent string proves nothing#

The User-Agent header is a name tag anyone can write. The IETF draft behind Web Bot Auth says User-Agent, "when used alone, can be spoofed meaning anyone may attempt to act as that agent" (IETF). For search crawlers, Google's check is DNS: "Run a reverse DNS lookup on the accessing IP address from your logs", confirm the domain is Google's, then run a forward lookup back to the same IP (Google). Cloudflare's verified-bot program runs checks like these for you, and asks for "Honest self-identification": a "Web Bot Auth signature, a published IP list with a stable user-agent, or reverse DNS" (Cloudflare).

The bot attacks that hit stores at peak#

OWASP's Automated Threats to Web Applications gives each attack an ID, so a WAF rule, a vendor report and your incident notes can name the same thing (OWASP). Five matter most at peak.

Card testing (OAT-001 Carding, OAT-010 Card Cracking). "Multiple payment authorisation attempts used to verify the validity of bulk stolen payment card data." Stripe warns that heavy card testing "might, for example, enlist you into Card Monitoring Programs", and that "simple firewall rules or filters based on a single heuristic such as IP addresses are usually not sufficient to prevent card testing on their own" (Stripe).

Credential stuffing (OAT-008). Stolen username and password pairs, tried in bulk. In Radware's report, one retailer's account-takeover attempts "surged roughly 1,100% just four days ahead of Black Friday" (Radware).

Scalper bots and inventory hoarding (OAT-005 Scalping, OAT-021 Denial of Inventory). Scalpers buy limited stock; hoarders hold it in carts without buying. Radware says "Sophisticated variants of this attack can defeat session-based cart timeouts by revisiting and re-adding items to cart".

Price scraping (OAT-011 Scraping). One retailer in Radware's report saw it climb "roughly 70% through the Cyber 5 period, peaking on Cyber Monday". And a scraper can be verified. Cloudflare's verified-bot taxonomy includes a "Data Collection" behavior: "Price scraping, competitive intelligence gathering, and third-party analytics" (Cloudflare). Verified means identified, not welcome.

Fake accounts and coupon guessing (OAT-019 Account Creation, OAT-002 Token Cracking). Radware says fake accounts exist "to exploit new customer promotions, referral bonuses and other acquisition incentives", and one large retailer saw fake registrations increase "7x year over year". Token cracking is the same game played on coupon and gift-card codes.

Radware also found that "Close to 70% of bad bot traffic was low in sophistication, up from 44%", and "77% of bad bot traffic originated from data centers and 23% from ISP networks". Cheap traffic from data centers is what rate limits and network checks are for. The rest is why the payment layer exists.

How to verify a buying agent: Web Bot Auth and signed agents#

A signed request carries proof of who sent it. The operator publishes a public key in a key directory and signs each request with the private key; the store's CDN, if it supports Web Bot Auth, fetches the key and checks the signature.

Web Bot Auth is an IETF working-group draft, draft-ietf-webbotauth-httpsig-protocol-01, last updated October 29, 2026, with "Intended status: Standards Track" in its header (IETF). It isn't a standard yet. Built on HTTP Message Signatures, it "defines the Signature-Agent header field for in-band key discovery, a key directory format based on JWKS, and a well-known URI at which that directory is served".

Who asks for signatures. Shopify tells agents to sign their requests with Web Bot Auth. Unsigned bots get its strictest rate limits (Shopify), and its docs warn that unsigned browser agents may be deprioritized or blocked: "Without it, bot detection might deprioritize or block your requests" (Shopify).

Who checks them. Since July 1, 2026, Cloudflare counts signed agents as Verified bots, marked for "Direct versus Intermediary access" (Cloudflare). Vercel verifies Web Bot Authentication, "which employs HTTP Message Signatures (RFC 9421)" (Vercel).

The card networks. Visa built its Trusted Agent Protocol "in collaboration with Cloudflare" and listed the merchant's first problem as "Managing bot detection systems that can mistakenly block legitimate agentic transactions" (Visa). Cloudflare says Visa's protocol and Mastercard Agent Pay both use Web Bot Auth "as the agent authentication layer" (Cloudflare), with one tag for browsing, agent-browser-auth, and one for paying, agent-payer-auth.

What a signature proves. Which operator sent the request, not that the buyer said yes. Shopify tells agents to "show the buyer the current order and total, and get their permission to place it", and adds: "WBA and ready_for_complete don't grant it" (Shopify). A signed agent still meets your card checks at payment.

What a missing signature proves. Nothing on its own. A shopper's own agent won't carry a payment network's credentials, and Mastercard says "The absence of scheme credentials does not make this traffic malicious" (Mastercard). So agent policy isn't a yes or no per AI company: a signature identifies the operator, a card network's registration adds a tier, and unsigned traffic gets a rate limit and your usual checkout checks, not a block.

Allow, rate-limit, challenge or block: the decision table#

Verify the signed, rate-limit the unknown, challenge the suspicious, block the abusive. Mastercard's merchant guide sets the floor under the second rule, "avoid blocking agents solely because they lack scheme registration", and files CAPTCHA under "Blocks legitimate agents along with malicious bots" (Mastercard). So the challenges here sit at login and checkout, not on product pages.

Two cautions. A false positive at checkout is a lost order, so run every new challenge or block in log mode first where the tool has one, and otherwise on one narrow path with a test order. And these are defaults: no row stops every bot, and we don't promise a protection outcome from any setting. Putting them on a live store is our WAF and bot hardening work.

How to stop bot traffic on Shopify, BigCommerce, WooCommerce, Magento and headless stores#

How to stop bot traffic depends on where the store runs. Each platform exposes a different slice of the four layers, and moving platforms resets every default, which is why bot rules after a platform move get a line on our replatforming checklist.

Shopify#

Shopify bot protection comes in three parts, and you schedule only one.

Forms, every plan. Online Store > Preferences > Spam protection has "Enable hCaptcha on contact and comment forms" and "Enable hCaptcha on login, create account, and password recovery pages", and "hCaptcha is activated by default on all Shopify stores" (Shopify).

Rate limits, set by Shopify. Unsigned bots get the strictest, signed ones get more (Shopify). Shopify verifies agents' keys itself; we found no merchant setting that requires or waives a signature.

Checkout Bot protection, Plus only. You activate it through Shopify Plus Support; then Settings > Bot protection schedules an event for up to 500 products or the whole store (Shopify). The gotcha is in the limits: "Only one bot protection event can be scheduled at a time", "The maximum duration for a bot protection event is 60 minutes", and an active event "can't be edited. It can only be deactivated." It challenges with reCAPTCHA or hCaptcha, "Don't allow bots to auto-complete checkouts" is on by default, and it covers the Online Store channel only. That's a tool for a drop, not a five-day sale. The page says nothing about AI agents, so how an event treats a signed agent checking out through WebMCP is undocumented.

Your own crawlers. If an SEO audit tool or monitor hits rate limits, create a signature under Online Store > Preferences, "Crawler access" (Shopify). Each covers one domain, lasts 3 months at most, and "Signatures don't grant access to your Shopify Checkout". Still rate-limited? Shopify's verdict: "your signature isn't valid".

Headless Shopify. Without the Shopify-Storefront-Buyer-IP header, "Shopify can't differentiate requests from different buyers, which can result in throttled API requests, limited bot protection, and unauthenticated flows at checkout", and Plus bot protection "is only available for the Cart object" (Shopify). That header belongs in the first sprint of any headless Shopify development build.

BigCommerce#

We found no bot management in BigCommerce beyond robots.txt and reCAPTCHA, and its help page says that to block problematic bots, "you must use a service, such as Cloudflare, to manage access at the infrastructure-level" (BigCommerce). Rate limits and agent verification happen at the edge.

reCAPTCHA sits under Settings > General, on the Security & Privacy tab, for "account sign-ups, reviews, and contact forms", though "The built-in newsletter sign-up form is not protected by reCAPTCHA" (BigCommerce). On checkout it's off by default "as it can affect your conversion rate due to increased checkout friction". On Optimized One-Page Checkout the switch is under Settings > Checkout, in the Security section, and "reCAPTCHA on the checkout page is invisible" (BigCommerce).

The robots.txt has rules you can't edit. BigCommerce says "a separate set of rules applies specifically to known high-volume and AI crawlers", rules that "add a crawl delay as well as block crawlers from select sensitive pages, such as cart, checkout, account, admin, and filter pages", and that "you cannot view or edit these entries" under Settings > Website, though they show in the live robots.txt file (BigCommerce). No source we found says whether shopping agents honor a disallowed checkout, and robots.txt was never a lock: RFC 9309 says "These rules are not a form of access authorization" (RFC 9309).

WooCommerce#

WooCommerce core has one bot control we found, and it's off by default: Store API rate limiting, under WooCommerce > Settings > Advanced > Features, "Rate limiting Checkout block and Store API" (WooCommerce). The settings switch covers only "the POST /checkout and Place Order flow for Checkout block", at "a maximum of 3 requests per 60 seconds". It counts logged-in shoppers by user ID and everyone else by IP, so behind a CDN or load balancer the store has to see each shopper's own IP, or everyone behind one proxy address shares those 3 requests. WooCommerce's proxy support for that is off by default and set in code, not in the settings (or the web server can restore the real IP), and it reads forwarding headers, so make sure only your CDN can reach the store. A shortcode checkout gets nothing from the setting.

For card testing, WooCommerce is plain: "merchants are responsible for their own fraud prevention techniques" (WooCommerce). It suggests you "prevent guest checkout" and "Avoid pay-what-you-want or donation products with no minimum", and warns about CAPTCHA plugins: "If the plugins are not configured correctly, they will offer little or no protection!"

Magento Open Source and Adobe Commerce#

Magento has the most native bot controls of the four.

reCAPTCHA is set per form under Stores > Settings > Configuration > Security > Google reCAPTCHA Storefront, separately from the admin's. The scopes include "Enable for Customer Login", "Create New Customer Account", "Checkout/Placing Order", "Coupon Codes" and "Gift Card (Adobe Commerce only)" (Adobe). There's no add-to-cart scope, so hoarding defenses go at the edge.

From 2.4.7, both editions can rate-limit order placement, which Adobe's release notes say "supports prevention of carding attacks" (Adobe). The switch, "Enable rate limiting for placing orders" under Stores > Settings > Configuration > Sales > Sales, Rate Limiting, is off by default, and it needs a Redis connection for its request log: without one, Adobe says, "the rate-limiting will not apply". Guests are counted by IP address, 50 orders a minute per IP in Adobe's example, so behind a CDN Magento has to see each shopper's own IP, or every guest behind one proxy address shares one count (Adobe). Stores on 2.4.6 or earlier don't have it.

On Adobe Commerce on cloud infrastructure, the standard Fastly WAF "does not support the following features: Protection against malware or bot mitigation … Rate limiting" (Adobe). Under Adobe's shared responsibility model, bot protection is one of the "merchant responsibilities, which Adobe Commerce Advanced Security is designed to address" (Adobe). Advanced Security, a paid add-on covering card testing, inventory hoarding and AI bot policies, is for cloud PaaS projects only and is configured by support ticket, so change rules before the freeze. Self-hosted Magento picks its own CDN and WAF, so the next section applies, and edge hardening is part of our Magento development work.

Headless stores on Cloudflare or Vercel#

A headless storefront puts the edge, and its defaults, in your hands.

On Cloudflare, Bot Fight Mode is "a simple, free product" with a trap: "You cannot bypass or skip Bot Fight Mode using WAF custom rules or Page Rules", and "they may challenge API or mobile app traffic" (Cloudflare). If your storefront calls its own APIs, or you want agents through, leave it off. Super Bot Fight Mode, "included in your Pro, Business, or Enterprise subscription", can be scoped, because "Custom rules are executed before Super Bot Fight Mode" (Cloudflare). Rate limiting rules come by plan: one on Free, two on Pro, five on Business (Cloudflare). Keep verified search crawlers out of them: Cloudflare warns that "Applying rate limiting rules to verified bots might affect Search Engine Optimization (SEO)". And Cloudflare's AI policy page, updated November 2, 2026, says "For new domains, Search, Agents, and Training use Allow (do not block) by default", and that "Training actions also apply to mixed-purpose crawlers used for both Search and Training" (Cloudflare), without listing which crawlers those are. Check what your own zone shows.

On Vercel, the bot protection ruleset is "available on all plans", "automatically excludes verified bots, such as Google's crawler", runs in log or challenge mode and is "inactive by default" (Vercel). The AI bots ruleset is off by default too (the dashboard labels it Allow) and covers bots that crawl "for training data, search purposes, or user-generated fetches", so deny mode turns away search and user agents with the trainers. And one line decides your architecture: "Bot Protection doesn't work when a reverse proxy (e.g. Cloudflare, Azure, or other CDNs) is placed in front of your Vercel deployment."

Filter bot traffic out of GA4 so conversion rate means something#

Does GA4 filter out bot traffic? Some, and it won't say how much. GA4's bot filtering works from a list: "traffic from known bots and spiders is automatically excluded", identified "using a combination of Google research and the International Spiders and Bots List, maintained by the Interactive Advertising Bureau", and "you cannot disable known bot traffic exclusion or see how much known bot traffic was excluded" (Google). Google doesn't say whether the list covers AI agents driving a real browser, so assume their visits can land in your reports.

How to identify bot traffic in Google Analytics comes down to sessions where nobody was there: no engagement, a hostname that isn't yours, a spike from one city that no campaign explains; GA4 has no network dimension, so check the network in your edge logs. GA4's data filters cover developer traffic, internal traffic by IP, and "Web hostname traffic", which filters "excluded domains where your property's event data comes from" (Google); that last one handles spam sent to your measurement ID from other sites. The same page warns: "Once you apply a data filter, the effect on the data is permanent." Report filters hide data without deleting it.

The cleaner fix is upstream: a request your edge blocks never loads the page, so it never fires a tag. Server-side tagging, if you run it, can drop traffic the edge flagged. Leave AI referrals out of every filter; as Adobe measures them, they're shoppers clicking a link.

Shopify Analytics and GA4 will disagree by design. Shopify says "identified bot sessions are filtered out of session-related reports by default", using a classification "designed to be conservative because it's better to miss some bots than incorrectly label real customers as bots" (Shopify). When the gap jumps, read the edge logs before you rewrite the ads.

Bot readiness before a traffic peak#

Cyber 5, the five days Adobe calls Cyber Week, runs from Thanksgiving, November 26, 2026, through Cyber Monday, November 30 (Adobe). Every rule goes in, gets tested and gets an owner before the code freeze, because the worst time to learn that a rule blocks checkout is the morning it does.

Bot rules don't end with the peak. Someone owns them all year, and that time belongs in the budget next to what maintenance and other running costs add each year.

Ecommerce bot protection FAQ

Sources