Most WordPress hosting problems I encounter in support tickets trace back to the same nine mistakes. The hosting landscape shifted this year—LiteSpeed became standard, PHP 8.3 adoption accelerated, and object caching stopped being optional for busy sites. Yet the errors stay the same.
I'll walk through each mistake, why it breaks things, and the correct approach.
Running outdated PHP versions
PHP 7.4 reached end-of-life two years ago. Sites still running it have no security patches and miss substantial performance gains. I see this constantly: a site crawls along on PHP 7.4 when the server offers 8.1 or 8.3.
The fear is plugin compatibility. That fear made sense in 2022. Not anymore.
Most reputable plugins updated their code by early 2024. Check your WordPress admin dashboard for the Site Health tool—it flags plugins blocking a PHP upgrade. Test in a staging environment if you have one. If a plugin hasn't been updated in three years and blocks PHP 8, find a replacement.
Correct approach: upgrade to PHP 8.1 at minimum. PHP 8.3 is faster and recommended unless you confirmed a plugin conflict. In cPanel, go to MultiPHP Manager and select the domain. In Plesk, open PHP Settings for the subscription. For command-line VPS setups:
sudo update-alternatives --config php
sudo systemctl restart php8.3-fpm
After the change, clear all caches—WordPress object cache, page cache, CDN cache, and opcode cache if you manage it manually.
Ignoring resource limits on shared hosting
Shared hosting packages impose CPU, memory, and entry process limits. When your site exceeds them, requests queue or return 503 errors. The error logs say "Resource temporarily unavailable" or "Max entry processes reached."
People assume they need to upgrade immediately. Sometimes yes, often no.
Unoptimized plugins hammer resources. WooCommerce without object caching can spawn hundreds of database queries per page load. PageSpeed plugins that resize images on-the-fly consume CPU every single request instead of generating thumbnails once.
Correct approach: read your hosting control panel's resource usage graphs for the past 24 hours. Identify the spike times. Check your WordPress debug log and server error log at those timestamps. Disable half your plugins, test load, re-enable them in groups to isolate the offender. Add object caching with Redis or Memcached if your plan includes it—this single change often cuts database load in half. Only upgrade the plan after you've confirmed the workload is legitimate and optimized.
Misunderstanding how caching layers interact
Modern WordPress hosting stacks have four or five caching layers: browser cache, CDN cache, server-side page cache (LiteSpeed Cache or WP Rocket), object cache (Redis), and opcode cache (OPcache). Each serves a purpose. Misconfiguring one breaks the others.
The most common mistake: enabling multiple page-caching plugins simultaneously. LiteSpeed Cache and WP Super Cache both running. Or WP Rocket with the server's built-in LiteSpeed cache. Pages serve stale content or logged-in users see cached admin bars.
Another mistake: clearing the WordPress plugin cache but forgetting the CDN cache after a CSS change, then wondering why the old stylesheet persists.
Correct approach: choose ONE page cache solution. If your host provides LiteSpeed with LSCache, use that and disable all other page cache plugins. If not, pick WP Rocket or W3 Total Cache—not both. Configure object caching separately through Redis or Memcached. After any theme or plugin update, clear caches in this order: WordPress plugin cache, then CDN cache (Cloudflare, Bunny, or your provider), then browser cache by hard refresh. Keep OPcache enabled at the PHP level; it's not something you clear manually unless deploying code changes.
Setting incorrect file permissions
WordPress files should be 644, directories 755, and wp-config.php should be 440 or 400. I see 777 permissions on wp-content or the entire WordPress root way too often. This happens after someone FTP'd in, hit a permissions error, and ran chmod -R 777 to "fix" it.
That creates a security hole. Any process on the shared server can write to your files.
Wrong permissions also cause "failed to open stream" errors or plugin upload failures even when the underlying issue is ownership, not permissions.
Correct approach: SSH into the server or use the file manager's terminal and run:
find /home/username/public_html -type d -exec chmod 755 {} \;
find /home/username/public_html -type f -exec chmod 644 {} \;
chmod 440 /home/username/public_html/wp-config.php
Replace username and public_html with your actual paths. If you're on shared hosting and don't have SSH, use the file manager to set directories to 755 and files to 644 manually. For ownership issues—when the files belong to root or the wrong user—contact support. Fixing ownership usually requires root access.
Skipping database optimization
WordPress databases accumulate revisions, trashed posts, transients, and orphaned metadata. A five-year-old site can have a 2 GB database when the real content fits in 200 MB. Queries slow down. Backups take forever.
People ignore it until the site grinds to a halt.
Correct approach: install WP-Optimize or use the command line with WP-CLI. Limit post revisions by adding this to wp-config.php:
define('WP_POST_REVISIONS', 5);
Then clean up old revisions:
wp post delete $(wp post list --post_type='revision' --format=ids) --force
Delete expired transients:
wp transient delete --expired
Optimize tables from phpMyAdmin or the command line:
wp db optimize
Schedule this monthly. A clean database improves query speed and backup reliability.
Misconfiguring or skipping a CDN
Content delivery networks distribute static assets—images, CSS, JavaScript—across edge servers close to your visitors. This reduces latency and offloads bandwidth from your origin server. Cloudflare, Bunny CDN, and StackPath all offer free or cheap tiers.
Mistake one: enabling a CDN but not configuring the WordPress plugin to rewrite asset URLs, so the CDN serves nothing. Mistake two: using a CDN without enabling Brotli or WebP compression, wasting the opportunity. Mistake three: caching HTML at the CDN with aggressive TTLs, causing dynamic content to go stale.
Correct approach: if using Cloudflare, install the official Cloudflare plugin and enable APO (Automatic Platform Optimization) if your plan includes it. For other CDNs, use a plugin like CDN Enabler or configure your caching plugin to rewrite URLs. Set static asset cache TTL to one month or more. Cache HTML only for truly static pages or set a short TTL (five minutes) and use cache tags to purge on updates. Enable Brotli and WebP at the CDN level. Test with your browser's network inspector to confirm assets load from the CDN domain.
Neglecting security headers and SSL configuration
SSL certificates are free and automatic now with Let's Encrypt. There's no excuse to serve WordPress over HTTP. Yet I still encounter mixed content errors—pages served over HTTPS but loading images or scripts from HTTP URLs—because the site was migrated without updating the database.
Another gap: missing security headers. HSTS, Content-Security-Policy, and X-Frame-Options headers protect against common attacks but require explicit configuration.
Correct approach: force HTTPS by adding this to wp-config.php above the "stop editing" line:
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
$_SERVER['HTTPS'] = 'on';
}
define('FORCE_SSL_ADMIN', true);
Search and replace HTTP URLs in the database using WP-CLI:
wp search-replace 'http://yourdomain.com' 'https://yourdomain.com' --all-tables
Add security headers in .htaccess (Apache) or the Nginx config:
# .htaccess for Apache
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Or in Nginx:
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
Verify headers with an online tool like securityheaders.com.
Choosing plugins based on install count alone
A plugin with five million installs isn't automatically safe or well-coded. Some popular plugins ship bloated code, load scripts on every page even when not needed, or haven't been updated in years. I've debugged sites where a single "lightweight" slider plugin added 800 KB of JavaScript to every page.
People install plugins without checking the code quality, update frequency, or support responsiveness.
Correct approach: before installing, check the plugin's last update date—anything older than six months is suspect. Read the support forum for unresolved bugs. Install Query Monitor to see which plugins add database queries and HTTP requests. After activating a new plugin, run a speed test with GTmetrix or WebPageTest and compare before-and-after scores. If a plugin adds more than 200 KB to your page size or ten extra HTTP requests, evaluate whether you really need it. Consider custom code or a lightweight alternative.
Using the wrong backup strategy
WordPress backups fail silently more often than people realize. A backup plugin reports success, but the backup didn't include the database, or the files are corrupted, or the backup is stored only on the same server that just crashed.
Another mistake: backing up daily but never testing a restore. The first time you try to restore is during an emergency, and you discover the backup is incomplete.
Correct approach: use a backup solution that stores copies off-site—UpdraftPlus with cloud storage, BlogVault, or server-level backups to an external bucket. Back up files and database together. Verify the backup succeeded by checking file sizes and testing one restore per quarter in a staging environment. If your host provides automatic backups, confirm what they cover and how far back they go. Many hosts keep backups for seven days only. Add your own solution for long-term archives. Schedule backups during low-traffic hours to avoid resource limits.
How often should I update WordPress core and plugins?
Update minor releases (security patches) immediately. Major releases can wait a few days while you check compatibility reports. Update plugins weekly unless one is known to be buggy—check recent reviews first.
What's the real benefit of object caching?
Object caching stores database query results in memory. Pages that run 100 queries on every load drop to 10 or fewer. Response time improves, server load drops, and you can handle more traffic on the same resources.
Can I run multiple WordPress caching plugins?
No. They conflict. Pick one page cache plugin and one object cache plugin if your host supports it. Do not run LiteSpeed Cache and WP Super Cache together.
How do I know if my host is overselling?
Consistent resource limit errors despite optimization, frequent downtime, or support tickets that go unanswered for days are signs. Use a monitoring tool like UptimeRobot. If uptime falls below 99.5% monthly, start researching alternatives.
Should I use a managed WordPress host or shared hosting?
Managed hosts (Kinsta, WP Engine) handle updates, security, and caching for you. They cost more but save time. Shared hosting is cheaper and fine if you're comfortable managing the stack yourself. VPS hosting sits in between—more control, more responsibility.
What to check first
When WordPress slows down or breaks, start with the error logs—WordPress debug.log and the server error log. Most problems announce themselves there. Check resource usage graphs in your hosting panel. Disable plugins in groups to isolate conflicts. Verify PHP version, file permissions, and caching config. These nine mistakes account for most tickets I handle, and fixing them doesn't require a server migration or expensive plan upgrade. Just methodical troubleshooting.