Bot traffic is often framed as a security problem or an SEO problem. But on WordPress hosting infrastructure, it shows up as a performance problem, specifically one concentrated in a very particular set of URLs.

Not all requests cost the same. The difference between a cached static page and a dynamic endpoint isn’t a slight performance nuance. It’s the difference between a request that costs almost nothing and one that reserves a PHP thread, triggers a full database query, and generates session overhead, regardless of whether the visitor is a real customer or a bot that never converts.

Understanding why some endpoints are far more expensive than others is what separates a bot management strategy that actually works from one that blocks too much or too little.

Not all requests are equal

When a visitor lands on a typical WordPress page, such as a blog post, a product listing, or an “about†page, the server almost always serves that response from cache.

Kinsta’s full-page cache handles this at the edge, so the request never triggers a server’s PHP or its database.

But when a request lands on a non-cacheable endpoint, the server has to do real work. A PHP thread is allocated and held for the entire duration of the request, and your database is queried. If the page involves cart state, user sessions, or personalized content, session handling adds another layer. None of this can be cached, because the response is unique to each request.

On a healthy site with mostly human visitors, this is fine. Your dynamic endpoints serve real customers who add items to their cart, check out, and search for products. The load is proportional to actual usage.

Bot traffic breaks this model. A crawler doesn’t add to the cart or convert, but it triggers the same server-side execution as a real customer would, at a rate no human could maintain.

The specific endpoints where this bites

On a WooCommerce store, the following URL patterns and endpoints are non-cacheable by design, and they’re exactly the ones that bot traffic tends to hit hardest.

?add-to-cart=

This is the most resource-intensive example we documented in our AI & bot traffic report. Adding a product to the cart requires PHP execution, a database write, and session creation or validation. There’s no cached version of this response, as each hit is fresh work.

To put the scale in context: Kinsta’s infrastructure data once recorded 7.67 million add-to-cart hits from five bots in a 24-hour window.

That’s about one request every 11 milliseconds, all day and all night, each demanding full PHP and database execution, each generating no meaningful output for the crawler, and none serving a customer.

/cart and /checkout

These pages are excluded from page cache by default in WooCommerce. They carry live session data, personalized cart state, and (in the case of checkout) payment processing logic.

A bot hitting /checkout repeatedly isn’t doing anything useful, but the server doesn’t know that. It processes every request as if it could be a real transaction.

?s= (Search queries)

WordPress and WooCommerce search queries run against your database on every request. There’s no cache layer that can absorb a unique search string.

A crawler working through parameterized URL variations or simply following every search link it finds can generate a long tail of unique, expensive database queries.

Faceted navigation and filter parameters

This is where the problem compounds. A typical WooCommerce product catalog generates URLs like:

/shop/?color=blue
/shop/?color=blue&size=M
/shop/?color=blue&size=M&orderby=price
/shop/?color=blue&size=M&orderby=price&paged=2

To a human, these are minor variations on the same page. To a bot following links, each one is a unique URL worth crawling, and each one requires the server to execute a filtered database query from scratch.

Google’s documentation explicitly identifies faceted navigation as a source of crawl inefficiency, where crawlers explore near-infinite variations of the same content. But the issue isn’t just that this wastes crawl budget. Each variation costs real server resources to generate.

AJAX-powered interactions

Many WordPress plugins, such as wishlists, availability checks, live pricing updates, and calendar views, rely on AJAX requests that bypass page cache entirely.

A bot that triggers these interactions, even indirectly by loading a page that fires them, creates server-side load that doesn’t show up as a “page request†in your analytics but does show up in your PHP thread usage.

What happens when PHP threads run out

Every dynamic endpoint hit holds a PHP thread for the full duration of that request. That detail seems minor in isolation, but thread capacity is finite, and bots don’t queue politely.

Kinsta allocates a fixed number of PHP threads per WordPress site, and each non-cached request reserves one for its duration.

Under normal traffic, this is rarely a constraint. Requests come in, get processed quickly, and threads free up.

Under sustained bot load on dynamic endpoints, threads get reserved and held. When all threads are occupied, new incoming requests wait in a queue. Real customers actually trying to add a product to their cart or complete a checkout experience slow page loads, timeouts, or HTTP 504 errors.

This is the infrastructural reality that makes bot traffic on dynamic endpoints materially different from bot traffic on cacheable pages.

The loop problem: When bots get stuck

Much of the bot traffic Kinsta’s infrastructure team sees isn’t the result of an intentional attack. It’s the result of crawlers following every link on every page without any mechanism to recognize when they’re going in circles.

Here’s what a query-string loop looks like in practice:

The bot follows everyone. It has no concept of “I’ve already seen this product page in a different filter state.†Each URL looks new, gets requested, and hits the server fresh.

This exact pattern of bots traversing query string variations across dynamic endpoints is one of the most common problems we noted in our report. A single loop rule triggered by one misbehaving pattern filtered 550 million requests in 30 days on Kinsta’s infrastructure. That isn’t an attack, but inefficient automation at scale, compounding because nothing caught it early.

What good bot management looks like at the endpoint level

For WooCommerce stores and WordPress sites with dynamic functionality, a few principles hold regardless of your specific setup.

What this looks like for different site types

The dynamic endpoint problem is most acute for WooCommerce stores, but it appears across different site types in various forms.

Going deeper: The full picture on bot traffic

The dynamic endpoint problem is one part of a broader shift in how bot traffic affects WordPress infrastructure. AI crawlers have grown significantly in volume and changed in behavior, more aggressive link-following, more willingness to ignore crawl directives, and more traffic hitting precisely the endpoints that cost the most to serve.

For a complete look at what’s changed, the data behind it, and a framework for making bot management decisions based on your specific site type and priorities, Kinsta’s full report on The AI & Bot Traffic Reality Check covers all of it, including analysis across more than 10 billion requests on Kinsta-managed infrastructure.

If you’re ready to act on what you’ve read here, Kinsta’s Bot Protection handles the most common patterns automatically, including protection for high-cost dynamic endpoints. Enable your desired level of protection once in MyKinsta, and the system manages the rest.

You can also reach out to the support team if you need clarification.