Bad bots don’t rewrite your theme code—they flood your store’s server and CDN with requests, slowing the response time (TTFB) that real shoppers experience. That extra delay pushes your Largest Contentful Paint past Google’s 2.5-second mark, weakening the Core Web Vitals its ranking systems use. Blocking bad bots at the front door keeps those scores clean.
Bad bots are automated programs—scrapers, scalpers, credential stuffers, and aggressive AI crawlers—that visit your store without ever buying, consuming the same server and bandwidth capacity your paying customers depend on.
That capacity is under real pressure. According to the 2025 Imperva Bad Bot Report, automated traffic overtook humans to reach 51% of all web traffic in 2024, and bad bots alone now account for 37%—their sixth consecutive year of growth. On retail sites specifically, 33% of all traffic came from bad bots, up from 26% a year earlier. Every one of those requests competes with a shopper for your store’s response time.
On this page
- Can bad bots really affect Core Web Vitals?
- What are Core Web Vitals, and which ones do bots hit?
- How does bot traffic actually slow down a Shopify store?
- The TTFB-to-LCP chain: from slow server to failing score
- Do slow Core Web Vitals really cost Shopify sales and rankings?
- When the damage is worst: flash sales and BFCM
- How to stop bad bots from wrecking your Core Web Vitals
- Frequently asked questions
Can bad bots really affect Core Web Vitals?
Yes—indirectly, but measurably. Bots don’t appear in your Core Web Vitals data themselves; Google scores your store from the real Chrome shoppers who visit it. The damage is second-hand: when thousands of automated requests tie up your store’s server and CDN, the humans loading the page at the same time get slower responses, and their slow experience is what gets recorded.
That distinction matters because of how Google collects the data. Core Web Vitals are field metrics, drawn from the Chrome User Experience Report (CrUX), which aggregates real-user performance over a 28-day rolling window. A sustained bot problem doesn’t spike one page load—it drags down the 28-day average that decides whether your store passes or fails. So a store can look fast in a quick lab test yet still fail in the field, because the field data captures every moment a shopper waited behind a wall of bots.
Curious what’s already hitting your store? See what bots, data-center networks, and proxies Kedra Shield filters at the storefront front door—before they ever consume the server capacity your Core Web Vitals depend on.
What are Core Web Vitals, and which ones do bots hit?
Core Web Vitals are Google’s three field metrics for real-world page experience: loading, interactivity, and visual stability. Google describes them as “a set of metrics that measure real-world user experience for loading performance, interactivity, and visual stability of the page.” They became part of Google’s ranking systems, so a store that fails them gives up ground to competitors that pass.
Per web.dev, the “good” thresholds—measured at the 75th percentile of page loads—are:
- Largest Contentful Paint (LCP): 2.5 seconds or less. How fast the main content appears.
- Interaction to Next Paint (INP): 200 milliseconds or less. How quickly the page responds to taps and clicks. INP officially replaced First Input Delay as a Core Web Vital on March 12, 2024.
- Cumulative Layout Shift (CLS): 0.1 or less. How much the layout jumps around while loading.
A bad-bot surge doesn’t hit all three equally. It attacks the two metrics tied to your server and main thread hardest:
| Core Web Vital | ”Good” threshold | How a bad-bot surge pushes it the wrong way |
|---|---|---|
| LCP | 2.5 s or less | Origin and CDN contention raises TTFB—the first slice of LCP—so the main content paints later for real shoppers |
| INP | 200 ms or less | A strained backend and busier main thread make cart, search, and filter interactions lag behind the 200 ms target |
| CLS | 0.1 or less | Least affected, but slow, staggered asset loads under contention can still shift late-loading elements |
The takeaway: bots primarily wreck LCP through server response time, and secondarily INP. That is where you focus.
How does bot traffic actually slow down a Shopify store?
Bad bots slow your store by forcing expensive, uncacheable work onto the origin that serves your pages. Shopify runs your storefront on a managed, CDN-backed platform (fronted by Cloudflare and Fastly, with a dedicated server-side Storefront Renderer), so no merchant’s server literally “falls over.” But that managed layer only protects you for cacheable, static assets. The moment traffic hits something dynamic, it reaches the origin—and bots specialize in the dynamic.
Cloudflare, which fronts a large share of the web, explained the mechanism plainly in its April 2026 analysis of crawler traffic: automated crawlers fetch mostly unique URLs and rarely repeat, so they constantly miss the cache. “Each of those cache misses represents a request to the origin, slowing response times as well as increasing egress costs and load on the origin,” the company wrote. The Wikimedia Foundation measured the same imbalance on its own infrastructure: at least 65% of its most resource-intensive, uncached traffic came from bots, even though bots were only about 35% of raw pageviews—because bots hit the long-tail pages that miss regional caches. During one traffic spike, Wikimedia reported crawler load “causing slow page load times for some users.”
On a Shopify store, the endpoints bots hammer are exactly the ones a CDN can’t serve from the edge:
- Search results and predictive search, generated fresh per query
- Collection pages with filters and sorting, where every combination is a new URL
- Product variant and inventory lookups that scrapers poll to track your pricing
- Cart and checkout endpoints that scalpers and card testers probe
- Any app or Liquid rendering that runs server-side on request
Every scraper crawling your catalog, every scalper watching a drop, and every AI bot indexing your pages competes for that origin capacity. Fastly’s threat research, published in August 2025, found aggressive fetcher bots can hit an origin with up to 39,000 requests per minute—“consuming bandwidth, overwhelming servers and mimicking the effects of DDoS attacks, even without malicious intent.” That is the same bandwidth-and-server drain we break down in the hidden cost of bot traffic on your Shopify store.
The TTFB-to-LCP chain: from slow server to failing score
Here is the exact chain that turns bot load into a failing Core Web Vitals score. It runs through one metric: Time to First Byte (TTFB)—how long your server takes to send the first byte of the page.
According to web.dev, LCP breaks into four sequential parts, and TTFB is the very first one: TTFB, then resource load delay, resource load duration, and element render delay. Because nothing else can start until the server responds, TTFB sets the floor for the whole metric. As Google’s guidance puts it: “Nothing can happen on the frontend until the backend delivers that first byte of content, so anything you can do to speed up your TTFB will improve every other load metric as well.”
Google recommends most sites keep TTFB at 0.8 seconds or less; above 1.8 seconds is poor. When bots pile onto your origin and push cache misses higher, server response time climbs—and TTFB climbs with it. Add half a second of TTFB and you’ve spent a fifth of your entire LCP budget before a single image starts downloading. The chain looks like this:
- Bad bots flood dynamic endpoints → CDN cache misses rise.
- Cache misses hit the origin → server response time increases under contention.
- TTFB climbs for every visitor served during the load, including real shoppers.
- LCP inherits the slow TTFB and slides past the 2.5-second “good” threshold.
- CrUX records those slow real-user loads into your 28-day field data.
- Core Web Vitals weaken—the assessment Google’s ranking systems read.
Crucially, TTFB is a diagnostic input to Core Web Vitals, not a Core Web Vital itself. But because it precedes and feeds LCP, a bot-driven TTFB problem shows up in the metric Google actually ranks on. This is also why the type of protection you choose matters: a security app that adds heavy client-side JavaScript can worsen the very scores you’re trying to defend, which we cover in security app performance and its impact on Core Web Vitals.
Do slow Core Web Vitals really cost Shopify sales and rankings?
Yes, on both fronts—and the sales hit usually outweighs the ranking hit. Google confirms in its Search Central documentation that “Core Web Vitals are used by our ranking systems.” It also keeps the signal in perspective: Google notes that “Google Search always seeks to show the most relevant content, even if the page experience is sub-par.” So weak Core Web Vitals won’t sink genuinely relevant pages on their own—but between two comparable stores, the faster one wins, and every place you slip costs organic traffic.
The conversion damage is more direct and better quantified. Shopify’s own analysis of store speed and conversion found that for every 100 milliseconds slower a store loads (LCP), conversion tends to be about 3.5% lower, and stores with a 2.5-second LCP convert roughly 30% below stores at 1.5 seconds. Responsiveness matters too: Shopify found conversion drops about 1.5% for every 32 milliseconds of added INP.
Independent research points the same way:
- Bounce rises fast with load time. Google/SOASTA research (2017) found the probability of a mobile bounce increases 32% as load time goes from 1 to 3 seconds, and 90% from 1 to 5 seconds.
- Milliseconds compound into money. A Google/Deloitte study, “Milliseconds Make Millions” (2020), analyzed 30M+ sessions across 37 brands and found a 0.1-second mobile speed improvement lifted retail conversions 8.4% and average order value 9.2%.
Read those numbers together and the stakes are clear: bots that add half a second of TTFB aren’t a technical footnote—they’re a standing discount on your conversion rate that you never approved.
When the damage is worst: flash sales and BFCM
Bot damage isn’t constant—it peaks at the exact worst moment. The Imperva data shows retail bot traffic increases two to three times during major sales events. Scalpers, scrapers, and inventory-checking bots converge on limited drops and Black Friday promotions precisely when your real shoppers arrive in force, so origin contention and TTFB spike together with legitimate demand.
That is the scenario where Fastly’s “DDoS-like” description bites hardest: your store is slowest when a slow store costs the most revenue. Preparing for it means keeping automated traffic off the origin before the rush, not after—the same logic behind why bots love flash sales and how to stop them. Clean Core Web Vitals during a peak event are worth more than at any other time of year, because that is when the highest volume of shoppers is judging your speed—and converting, or not, on it.
How to stop bad bots from wrecking your Core Web Vitals
The fix is to block bad bots at the front door—before they reach the origin and consume the capacity your Core Web Vitals depend on. Kedra Shield is a Shopify security app that filters automated and known-bad traffic at the storefront entry point, server-side, so bots never load your dynamic pages, never inflate cache misses, and never slow the store for real shoppers. Because the enforcement happens before the page is served, it adds no client-side JavaScript—it removes load rather than adding it. Read the Docs proved the lever works: after blocking abusive AI crawlers, it cut its bandwidth by 75%.
Here’s a practical setup that maps to the mechanism above:
- Install and open the dashboard. Add Kedra Shield from the Shopify App Store and open its protection settings. You’ll see live blocked-traffic reporting by network type and country—the fastest way to gauge how much automation is reaching your store.
- Block bots and data-center networks. Scrapers and fetcher bots overwhelmingly run from cloud and hosting infrastructure. Turn on bot and data-center (ASN/hosting) blocking so traffic from AWS, OVH, and similar networks never touches your origin endpoints. This removes the largest share of cache-miss-inducing volume.
- Enable VPN, proxy, and Tor detection. Sophisticated bots rotate through anonymized connections to dodge limits. Switch on anonymized-connection detection to challenge or block that masked traffic; our VPN and proxy blocking guide walks through the settings.
- Apply rate limiting and velocity rules. Cap how many requests a single visitor or IP can fire in a short window, so a script polling your product and search endpoints thousands of times gets throttled instead of served.
- Layer in country and city rules. If abusive traffic clusters in regions you don’t sell to, add geographic blocking to close that lane while keeping your real markets fully open.
- Keep the good crawlers in. Bot management is not “block everything.” Configure your rules to welcome Googlebot and legitimate AI crawlers while stopping the scrapers and scalpers—the balance we detail in the complete guide to anti-bot measures for Shopify.
Because this is server-side, front-door enforcement, it’s the opposite of the heavy client-side scripts that hurt performance—a distinction worth understanding from our breakdown of server-side vs client-side blocking. You also get a cleaner picture of your real traffic, since blocked bots stop polluting your Shopify analytics at the same time they stop dragging your speed.
Ready to protect your scores at the source? Install Kedra Shield, turn on bot and data-center blocking first, and watch your dashboard reveal how much automated traffic was quietly loading your store.
Frequently asked questions
Do bad bots directly lower my Core Web Vitals scores?
Not directly—bots don’t appear in Google’s field data. The effect is indirect: bots consume your store’s server and CDN capacity, so the real Chrome shoppers loading pages at the same time experience slower response times. Those slow real-user loads are what CrUX records over its 28-day window, which is what drags your scores down.
Won’t Shopify’s CDN already absorb all the bot traffic?
Shopify’s Cloudflare- and Fastly-backed CDN handles cacheable, static assets well. But bots target dynamic, uncacheable endpoints—search, filtered collections, variant lookups, cart, and checkout—that must reach the origin and its server-side renderer. Those cache misses raise response time for everyone, which is exactly what degrades LCP. The CDN reduces the problem; it doesn’t eliminate it.
Will blocking bots actually improve my Google ranking?
It removes a drag rather than guaranteeing a jump. Google confirms Core Web Vitals “are used by our ranking systems,” but also that it favors the most relevant content even when page experience is sub-par. Blocking bots protects the field-data scores that act as a tiebreaker between comparable pages—and, more reliably, protects the conversion rate that slow speed erodes.
How do I tell if bots are hurting my store’s speed?
Compare lab and field data. Run your key pages through Google PageSpeed Insights: if lab scores look fine but field (CrUX) LCP is poor, contention during real traffic is a likely cause. Then check a bot-protection dashboard for the volume of automated requests hitting your store—a high share of data-center and proxy traffic confirms it.
Can I block bad bots without accidentally blocking Google or AI crawlers?
Yes. Legitimate crawlers like Googlebot identify themselves and behave predictably, while scrapers and scalpers hide behind data-center IPs, proxies, and rotating identities. A tool like Kedra Shield lets you block the abusive networks outright while allowing the search and AI crawlers you want indexing your store, so visibility stays intact while the load drops.
Does a bot-blocking app slow my store down like other apps?
It depends entirely on architecture. Client-side security apps that inject heavy JavaScript can worsen LCP and INP themselves. Kedra Shield enforces server-side, at the storefront front door, so it adds no rendering-blocking scripts to your pages—it subtracts bot load instead of adding app weight, which is why it protects Core Web Vitals rather than taxing them.
The bottom line
Bad bots don’t need to breach anything to cost you money—they just need to show up in volume. At 37% of internet traffic and a third of all retail visits, automated requests pile onto the dynamic endpoints your CDN can’t cache, raise your server response time, and push TTFB and LCP past the thresholds Google and your customers judge you on. Because Core Web Vitals are measured from real shoppers over 28 days, a persistent bot problem quietly bakes itself into the scores that drive both rankings and conversions.
The durable fix is to stop the traffic before it reaches your origin. Server-side, front-door blocking removes scrapers, scalpers, and abusive crawlers without adding a byte of client-side weight—so your Core Web Vitals reflect your real store, not the bots crowding it. Install Kedra Shield, start with bot and data-center blocking, and give your fastest shoppers the fast store they came for.
