WordPress bots need a measured response, not a blanket ban
WordPress bots are now a routine operational issue for site owners, and Kinsta says its analysis of more than 10 billion requests over a year reinforces why they need active management. The company frames the problem against a wider rise in automated traffic, including a reported 300% increase in AI-driven bot traffic. For WordPress publishers, shops and agencies, the practical point is clear: not every automated request is harmful, but unmanaged bot traffic can still drain hosting resources, slow pages and disrupt real visitors.
A bot is software that visits a website automatically rather than as a person clicking through pages. Some bots are useful. Search crawlers help search engines find and index pages, monitoring tools check whether a site is working, and some AI crawlers may support visibility or citations in AI-generated answers. Other bots may scrape content, probe login pages, hit expensive dynamic pages or generate large numbers of requests without offering any clear benefit. Kinsta’s central recommendation is not to block everything, but to assess the traffic, stabilize the site if needed, decide what to allow, challenge or block, then monitor and document the result.
The first step is to work out whether the site is facing a normal bot-management problem or an acute incident. Kinsta advises checking whether page loads have slowed, errors have increased, server, PHP or database usage has risen, traffic spikes fail to match real visitor metrics, or many requests are landing on the same URLs. PHP is the programming language WordPress uses to build many pages, and a database is the store where WordPress keeps posts, settings, users and order data. If these systems are being overworked, legitimate visitors may be competing with automated traffic for the same resources.
Kinsta describes its bot analytics as breaking requests into categories including likely humans, verified bots as verified by Cloudflare, likely bots, AI crawlers, excessive-rate AI crawlers, unclassified traffic, automated traffic, malicious traffic, custom rules configured for a site by Kinsta, and WP automations. Its dashboard can also show top paths, user agents, countries and IPs for different traffic classifications. A user agent is the label a browser or bot sends to identify itself, and an IP address is the network address a request comes from. Those details help a site owner see whether a specific crawler is hitting useful content, whether an unknown scraper is crawling thousands of URLs, or whether automated requests are concentrated on sensitive or resource-heavy pages.
If real visitors are already affected, Kinsta says site owners should stabilize first and investigate in more detail afterwards. That can mean temporarily increasing bot protection, blocking clearly abusive traffic before it reaches the site, challenging suspicious traffic, and preserving access for critical crawlers and integrations. A challenge is an extra verification step before access is allowed. Kinsta says that, with its system, a visitor who successfully passes a challenge generally will not be challenged again for at least 10 days while using the same browser and IP address. The company says its baseline security protections already block traffic classified as malicious, while stricter levels can be used for automated traffic that is not necessarily classified as malicious, such as challenging all non-verified bots or challenging everyone during a serious pressure event.
Once the site is stable, the longer-term decision is whether each type of automated traffic should be allowed, challenged or blocked. Allowing means the request can reach the site. Blocking means it cannot. Challenging sits between the two when the right answer is uncertain. Kinsta suggests weighing three questions: whether the bot provides value, how much the traffic costs in processing, bandwidth and database queries, and what would happen if the bot were blocked. A bot fetching a cached blog post usually costs less than one hitting a dynamic page such as a WooCommerce cart. Cache means a saved copy of a page that can be served faster without rebuilding it every time.
That distinction matters because WordPress sites often contain both low-cost and high-cost pages. Static or cached content may handle crawler traffic well. Dynamic endpoints, meaning pages or functions generated fresh for each visitor, can be far more expensive. Kinsta gives examples such as shopping carts, checkouts, searches and logins, and notes that this is common in WooCommerce stores but can affect other kinds of sites too. Requests to these areas can bypass cache, require PHP processing, trigger database queries and leave real customers competing for resources. The measured response is to protect the specific expensive endpoints, prevent unnecessary crawler access to cart and checkout functions, investigate URL parameter sprawl and crawl loops, and keep search crawlers able to reach valuable content elsewhere.
Search engine crawlers require particular care. If a crawler is generating heavy traffic, Kinsta advises checking which URLs it is visiting, whether those URLs are useful indexable content, whether it is stuck in parameters, filters or dynamic endpoints, and whether real performance is actually suffering. Indexable content is material that a search engine can add to its results. Blocking an entire search crawler can be harmful, especially if it prevents Googlebot from crawling and indexing content, because that can severely damage visibility in Google Search. A better response is to preserve access to important pages while restricting or discouraging crawling of unnecessary dynamic URL variations.
AI crawlers are more ambiguous. Kinsta notes that they can create many requests, while their value may be hard to judge. Site owners should ask whether AI visibility or citations matter to them, whether a crawler sends meaningful referral traffic, whether it is mostly collecting content without obvious benefit, and whether the traffic consumes significant infrastructure resources. Kinsta also stresses that not all AI crawlers need to be treated alike. Some may align with a site’s goals, while aggressive crawlers may be challenged or restricted, and those that provide little value while creating meaningful costs may be blocked.
Unknown scrapers deserve investigation rather than instant assumptions. Kinsta says an unidentified bot is not automatically malicious, but if it is crawling aggressively and consuming resources, owners should check its user agent, IPs, paths and request behavior. They should also confirm whether it belongs to an integration the site actually depends on. If uncertain, a challenge can reduce risk. If the traffic is clearly unwanted and causing issues, blocking may be appropriate. Afterward, owners should watch for broken services, identity rotation or changing request patterns.
Monitoring closes the loop.