An online store can look perfectly normal when you visit it. Pages load, products are displayed, the shopping cart works, and customers can place orders without any obvious problems.
Behind the scenes, however, things can look very different.
We recently analyzed a WordPress and WooCommerce store whose server was under almost constant load. CPU usage was hovering around 80%, even though the number of real visitors did not come close to explaining that level of resource consumption.
The first assumption in situations like this is often that the website needs a more powerful server.
But before adding more resources, we wanted to find out who — or what — was actually consuming them.
Visitors that never buy anything
After analyzing the traffic and the requests being processed by WooCommerce, we found an interesting pattern.
A significant amount of server resources was being consumed by automated bots crawling the store. Some were regular web crawlers, while others were associated with various AI-based services.
A bot reading the pages of an online store is not necessarily a problem. Search engines have been doing this for decades, and having your products indexed is obviously useful.
The problem was what some of these bots were doing after reaching a product page.
They were not simply reading the page. They were following links and triggering interactive store actions: adding products to the shopping cart, comparing them, or adding them to wishlists.
In one case we observed, a single bot generated more than 380 add-to-cart requests in approximately five minutes.
Obviously, it had no intention of completing the purchase.
Why 380 requests can matter so much
There is an important difference between loading a regular product page and performing a WooCommerce action.
A product page can often be served from cache. In that case, the web server can respond very quickly without rebuilding the entire page for every visitor.
“Add to cart”, however, is a dynamic operation.
WooCommerce has to start PHP, initialize WordPress and the required plugins, manage the session and shopping cart, and execute the operations associated with the request. A page cache cannot simply eliminate all of that work.
One request is not a problem.
Neither are ten.
But when several bots continuously generate hundreds or thousands of these requests, the server ends up working for “customers” who will never actually buy anything.
In the case we investigated, almost three quarters of the application’s processing time was being consumed by this type of activity. Most of the rest also came from bots: pages with parameters in the URL, which bypass the cache and force the server to rebuild them every time.
We didn’t want to block the bots
The simplest solution would have been to block all automated traffic.
We didn’t do that.
Some crawlers are important for indexing the store, and the rise of AI services is also changing the way people discover information and products online. There is little reason to waste server resources, but there is also little reason to indiscriminately block every bot that visits the website.
Instead, we separated content indexing from actions that only make sense for an actual shopper.
A bot can read a product page.
There is no practical reason for it to add that product to a shopping cart, put it on a wishlist, or automatically compare hundreds of products using the store’s interactive features.
For bots that identify themselves as crawlers, these requests are now stopped before they reach WordPress and WooCommerce. The server responds immediately instead of starting the entire application just to build a shopping cart that nobody will ever use.
But bots don’t always say they’re bots
Identifying known crawlers is only part of the solution.
A User-Agent can easily be changed, and some automated systems can look almost identical to a regular web browser from the server’s point of view.
For that reason, we added a second layer of protection based on behavior.
A customer might add several products to their cart within a short period of time. That’s perfectly normal.
A “customer” attempting to add dozens or hundreds of products per minute is very likely an automated system.
When that happens, requests exceeding the configured limit are stopped quickly, before they consume the resources required to fully process them through WordPress and WooCommerce.
For real customers, nothing changes. The store, shopping cart, product comparison and wishlist features continue to work exactly as before.
From approximately 80% to below 10%
CPU usage generated by the application dropped from approximately 80% to below 10% on average, with lows of around 3%.
The drop in CPU usage came from the bot rules. They do not only stop store actions; they also limit the parameterized pages the same bots were requesting, so almost all of the unnecessary work disappeared, not just the three quarters.
Separately, we adjusted the PHP, database and web server configuration to the store’s actual resources. That is where the memory gain came from: memory usage decreased by roughly 35%.
More importantly, these numbers represent something very practical.
The server now has considerably more capacity available for the moments when the store actually needs it: more visitors, marketing campaigns, order processing, or other genuine traffic spikes.
In other words, the server’s resources are now available for customers instead of being spent on hundreds of shopping carts created by bots.
A more powerful server isn’t always the answer
When a website becomes slow or a server is constantly under load, it is very easy to reach the same conclusion:
“We need more resources.”
Sometimes that’s exactly the right answer.
But sometimes the server already has enough resources and the real problem is how those resources are being used.
You can double the CPU or memory and the problem may temporarily disappear. But if the underlying cause remains, all you have achieved is a more expensive server doing unnecessary work faster.
That’s why, for us, managing a server isn’t simply about keeping it online and making sure it has enough CPU, memory and disk space.
It means understanding what is happening on that server, seeing how its resources are being used, and stepping in when something isn’t working as it should.
This is especially true for WordPress and WooCommerce, where the difference between a website that works and one that works well isn’t always determined by how powerful the server is.
Sometimes the difference comes down to a few hundred shopping carts that nobody ever intended to buy.
Managed WordPress and WooCommerce hosting
At ServerHost, we don’t just provide space on a server. We configure and manage the infrastructure your website runs on, monitor its resources, and step in when performance issues or abnormal traffic appear.
For an online store, the goal is simple: your server’s resources should be used by your visitors and customers, not wasted on unnecessary processes.
You take care of your store. We take care of the infrastructure it runs on.