If your host has flagged "excessive resource usage," your site slows to a crawl during traffic spikes, or your server bill keeps creeping up, this is about your server's CPU, the one running your website, not a visitor's laptop fan spinning up in their browser. That's a different problem with different fixes. This one's about yours.
Quick answer: High website CPU usage typically results from six factors: inefficient database queries, lack of caching, bloated plugins/custom code, on-the-fly media processing, malicious or bot traffic, or an inadequate hosting plan. As of 2026, bot and AI-crawler traffic has significantly increased, so check for that before assuming the issue is your code.
How to Confirm What's Actually Causing It
Don't guess — look at what's actually spiking first. A few minutes of checking saves hours of fixing the wrong thing.
- Check your host's resource dashboard (cPanel, Plesk) or run top/htop if you have server access, and see which process is consuming CPU — mysqld points to the database, php-fpm or your app process points to your code, an unfamiliar process can mean malware.
- Check timing. Does the spike track with real visitor traffic, or does it happen at odd hours with no corresponding human activity? The second pattern usually means bots, cron jobs, or an attack.
- Check your access logs for a flood of requests to the same few URLs, from the same IP range, or from unfamiliar user-agent strings.
- If you have database access, check the slow query log. A handful of queries running repeatedly is a more common culprit than people expect.
Common Causes — and the Fix for Each
Inefficient or Unindexed Database Queries
This is the single most common cause of high CPU on any dynamic site or app. A query that scans an entire table because it's missing an index, or a page that fires dozens of small queries instead of one efficient one (the classic "N+1" pattern), forces the database to work far harder than it should on every single page load.
Fix: Pull your slow query log and look for anything run frequently. Add indexes on columns you filter or sort by. If you're on a custom-built app, this is usually a five-minute fix for a developer once the query is identified — the hard part is finding it, not fixing it.
No Caching Layer
If your server rebuilds the same page from scratch for every visitor, you're burning CPU on work that didn't need to happen twice. This is especially costly on content that rarely changes — blog posts, product pages, marketing pages.
Fix: Add full-page caching for anonymous/public pages, and object caching (Redis or Memcached) for database-heavy pages that can't be fully cached. Be careful not to cache logged-in views, carts, or checkout flows — a fast broken checkout is still broken.
Bloated Plugins, Themes, or Dependencies
Extra code running on every page load adds up, and the worst offenders are rarely the plugin you'd suspect. It's often a forgotten script, an old analytics snippet, or a "related content" widget that queries the database on every single view with no caching of its own.
Fix: On WordPress, disable everything and reactivate one at a time to isolate the culprit. On a custom app, profile your request lifecycle to see which middleware or dependency is eating time — most frameworks have a profiler built in or a well-known one available.
On-the-Fly Image or Media Processing
Resizing, compressing, or converting images at the moment a visitor requests them is expensive, and it happens more often than site owners realize.
Fix: Pre-process and cache resized images instead of generating them per request. Serve modern formats (WebP/AVIF) and let a CDN handle resizing at the edge instead of your origin server.
Malicious or Abusive Traffic
Brute-force login attempts, vulnerability scanners, and cryptomining malware injected into a compromised site all show up as unexplained CPU spikes — often with no obvious correlation to real traffic.
Fix: Rate-limit login endpoints, add a web application firewall, and run a malware scan if the pattern looks aggressive or the spike is truly constant. A sudden spike that started right after a plugin or dependency update is also worth treating as a compromise until ruled out.
Cron Jobs and Background Tasks
Scheduled tasks that overlap, loop longer than expected, or run more often than needed will spike CPU on a predictable schedule — which is actually the easiest cause to confirm, since it repeats at fixed intervals.
Fix: Check your cron logs for jobs that are still running when the next one starts, and space out or consolidate tasks that don't need to run as often as they're currently scheduled.
The Cause Most Guides Don't Mention: AI Crawler Traffic
By mid-2026, bots represent over half of all web HTTP traffic for the first time, with AI-specific crawlers making up about a quarter of that. Cloudflare Radar data shows that AI bot traffic surged in 2025, while human traffic remained stable. Crawlers like GPTBot, ClaudeBot, and Bytespider often request pages aggressively and frequently disregard robots.txt, making polite blocking ineffective.
On shared hosting in particular, this matters because you're sharing a CPU budget with every other site on the server. A crawler hammering someone else's site can slow yours down too, and a crawler hammering your site can push you over a resource cap you didn't know existed.
Fix: Check your access logs for specific user-agents, as new crawlers emerge regularly. Don't assume existing bot-blocking rules cover them. If a crawler ignores robots.txt, block or rate-limit it at the firewall/CDN level (most CDNs support this). Deliberately decide which crawlers to allow, AI search crawlers like OAI-SearchBot can bring real traffic, while pure training crawlers typically do not.
Sometimes It's Not a Bug — You've Outgrown Your Plan
If you've ruled out inefficient queries, missing caching, and bot traffic, and CPU usage still climbs in a way that tracks cleanly with real, legitimate visitor growth, the honest answer is that your hosting tier is undersized for your traffic. That's not a failure — it's a sign the product is working. At that point the fix is a plan upgrade or a move to a VPS/dedicated resource, not another round of debugging.
Frequently Asked Questions
Is high CPU usage actually bad for my website?
Yes, beyond a certain point. Sustained high CPU slows page load times, can trigger your host to throttle or suspend your account on shared plans, and — since site speed factors into search rankings — can quietly hurt your SEO alongside the more obvious problem of frustrated visitors.
Will upgrading my hosting plan fix high CPU usage?
Sometimes, but it's rarely the first thing to try. An upgrade fixes a genuine capacity shortfall, but if the real cause is an unindexed query or a bot flood, you'll hit the new ceiling too — just later, and after paying more for it.
Can bot traffic really cause a website to crash?
Yes. Aggressive AI crawlers have been documented consuming tens of terabytes of bandwidth from a single site in a month, and on shared or undersized hosting, that kind of burst traffic can exhaust available CPU and take a site offline the same way a small DDoS would.
Why does my WordPress site specifically seem prone to this?
WordPress relies heavily on plugins and database queries for functionality that a custom-built app might handle more efficiently, and it's a common target for bots and attacks simply because of how widely it's used. Caching and careful plugin selection matter more on WordPress than on most other platforms as a result.
How do I know if it's my code or my hosting plan?
Check whether CPU usage tracks cleanly with legitimate visitor growth (points to hosting capacity) or spikes independently of real traffic, at odd hours, or on specific endpoints (points to a code, query, or bot problem). Diagnosing this correctly first saves you from paying for an upgrade that doesn't fix anything.
