How bot traffic filtering works
What Ordinary counts as bot traffic, how we spot it, what's left out of session counts, how that compares to Shopify Analytics, and how to check a number.
Written by The Ordinary Team · Updated On this page
Short version: every store gets some traffic from automated visitors — search-engine crawlers, AI scrapers, SEO tools, uptime monitors, etc. — that show up on your storefront but aren’t real shoppers. Ordinary classifies these as bot traffic and excludes them from session, visitor, and funnel reports so the numbers reflect what real humans actually did.
Shopify Analytics filters out much of this too, which is why the two session counts are usually close. Crawler floods are the exception — Shopify counts those and Ordinary doesn’t, so on a store that attracts them Ordinary’s session count is the lower number.
What gets classified as bot traffic
Ordinary classifies the following as bot traffic:
- Search engine crawlers — Googlebot, Bingbot, DuckDuckBot, YandexBot, Baidu, Applebot, etc.
- AI scrapers — GPTBot (OpenAI), ClaudeBot (Anthropic), PerplexityBot, Bytespider (ByteDance), CCBot (Common Crawl), Google-Extended, meta-externalagent.
- SEO and analytics tools — AhrefsBot, SemrushBot, MJ12bot, DotBot, Screaming Frog, DeepCrawl, etc.
- Social link unfurl previews — Facebook, Twitter, LinkedIn, Slack, Discord, Telegram, WhatsApp.
- Uptime monitors and performance auditors — Pingdom, UptimeRobot, GTmetrix, Lighthouse, Datadog Synthetics, etc.
- Headless browser tooling — Selenium, Puppeteer, Playwright, HeadlessChrome, PhantomJS.
- HTTP client libraries — curl, wget, python-requests, axios, PostmanRuntime, when used without disguising themselves.
- Context-free automated requests — a page request that arrives with no browser identity at all and no sign of where it came from (no referrer, no campaign tag). Real shoppers’ browsers always identify themselves; a request carrying none of that is automated.
- Crawler floods on a single page — one page taking a burst of visits in a day where effectively every visit leaves on arrival within seconds and Ordinary’s own pixel barely saw anyone there. Article and blog pages attract these; product pages rarely do.
How Ordinary identifies bots
Three layers of classification work together:
1. User-agent pattern matching at the moment of capture
Every event the pixel sends includes the browser’s user-agent string. When the event arrives, Ordinary checks it against a catalog of hundreds of known bot signatures. If it matches, the event is tagged as bot traffic immediately.
This catches the polite, well-identified bots — search engines, AI scrapers, SEO tools, etc. — which is the majority of automated traffic.
2. Context-free request detection
Some automated traffic doesn’t identify itself with a recognizable bot name. For these, Ordinary looks at whether the request has the basic hallmarks of a real visit. A real shopper’s browser always announces what browser it is, and a real visit almost always shows where the shopper came from (a search engine, an ad, a link). A page request that arrives with none of that — no browser identity, no referring source, no campaign tag — is an automated cold request, and Ordinary tags it as bot traffic.
This check is deliberately conservative: if a request carries any of those signals (a recognizable browser, a referrer, or a campaign tag), it is treated as a real visitor and counted. A real shopper who lands on one page and leaves — a bounce — is a normal session and is always counted; Ordinary never treats a short visit as a bot on its own.
3. Crawler floods on a single page
Some crawlers identify themselves as ordinary browsers and arrive in volume. They show up as one page taking far more visits in a day than the store sees anywhere else, with effectively every visit leaving on arrival after a few seconds — and with Ordinary’s own pixel, which runs in the shopper’s browser, seeing almost nobody on that page. That combination doesn’t happen to real traffic: a page that genuinely gets a surge of people has people on it.
All four conditions have to hold together before a page-day is excluded. The pixel check is what keeps a genuinely bad ad landing experience — high volume, high bounce, seconds-long visits, but real shoppers — from being mistaken for a crawler.
What’s excluded from your reports
Once a visitor is tagged as bot traffic, all their events are excluded from:
- Daily session counts and unique-visitor counts
- Funnel conversion rates (session → ATC → checkout → order)
- Channel attribution (you won’t see “Googlebot” listed as a traffic source dragging your numbers around)
- Cohort and retention reports
- Device, browser, and geographic breakdowns
- Page performance and product performance reports
- Onsite search reports
Order revenue is not affected — bots don’t complete orders, so no real order numbers shift. Only the upstream visitor / session metrics tighten.
What’s NOT excluded
- Raw pixel event records — we still capture every event, including ones from bots. Filtering happens at the report layer, not at ingest. This lets us reclassify if we discover a rule was too aggressive, and gives the support team a way to investigate edge cases.
- The cart-stitch coverage metric in the admin dashboard — this measures how reliably the bridge identifier propagates through the funnel; filtering bots would skew the ratio.
- Webhook-synthesized order rows — orders that arrived via webhook without a corresponding pixel event are never bot candidates by construction.
How bot filtering settles in over time
Bot filtering works on the browser’s identity, which Ordinary captures most completely on visits that happen after you’re fully set up. For very recent visits, every bot is caught right away. For older visits in your history, Ordinary only excludes the ones it can positively confirm as bots — it never guesses, because a cautious guess on older data risks dropping a real shopper.
The practical effect: if your store has a lot of bot traffic, your reported sessions tighten toward your true human number over the first few weeks of use as more of your reporting window is made up of fully-classified recent visits. If your store has little bot traffic, you won’t notice a change — your numbers already reflect real shoppers. Either way, Ordinary only ever excludes confirmed bots; it never removes a real visit to make a number look better.
If a session number looks off versus Shopify Admin in either direction, mention it to support — we can look at your store’s specific traffic mix and confirm what’s driving the difference.
How this compares to Shopify Admin
Shopify Admin’s analytics filters self-identifying bots from session counts the way Ordinary does, which is why the two numbers are usually close. It does not exclude crawler floods, so on a store that attracts them — typically one with popular article or blog pages — Shopify’s session count can be much the larger of the two.
Where that happens, Ordinary shows Shopify’s own total beside its own, with the number of crawler sessions excluded and the pages they landed on, so you can confirm it in Shopify Admin → Analytics → Reports → Sessions by landing page. The same pages will be there with almost no time on site and almost every visit leaving on arrival.
This only ever moves the session number, never revenue: the same period will show Shopify’s session count rising while orders are flat or falling, which is the shape crawler traffic makes. If a gap looks wrong in either direction, mention it to support and we can walk through what’s driving it.