Most WordPress installations fail because of predictable, fixable mistakes about hosting requirements. Not because the host is bad or WordPress is demanding, but because people guess instead of checking. I've seen production sites go dark over a two-dollar-per-month RAM upgrade that nobody knew they needed.
The gaps between what people think WordPress needs and what it actually requires create most of the support tickets I handle. Here are the nine mistakes that come up most often, what goes wrong, and how to get it right.
Mistake 1: Running outdated PHP versions
People assume their host's default PHP version is fine. It usually isn't.
WordPress will run on PHP 5.6, technically. Plugins and themes won't. You'll see white screens, fatal errors, and blank admin pages because a popular plugin requires PHP 7.4 or newer. The site loads until you activate that one plugin, then everything breaks.
What to do instead:
Run PHP 8.0 or newer. Check your current version by creating a file called info.php in your web root:
<?php phpinfo(); ?>
Visit yourdomain.com/info.php and look for the version number at the top. Delete the file immediately after checking.
In cPanel, change PHP versions under "Select PHP Version" or "MultiPHP Manager." Pick the newest version your plugins support. Test on a staging site first if you're jumping multiple major versions.
PHP 7.4 reached end-of-life in late 2022. If your host doesn't offer PHP 8.0 or newer, migrate hosts.
Mistake 2: Ignoring memory_limit settings
The default PHP memory limit is often 128MB. WordPress core might run on that. Your site won't.
Plugins consume memory. WooCommerce with a few extensions can hit 256MB easily during checkout. Page builders, import tools, and backup plugins regularly exceed 512MB. When you run out, you get blank pages or "Fatal error: Allowed memory size exhausted" messages.
What to do instead:
Set memory_limit to 256MB minimum, 512MB if you run WooCommerce or complex plugins.
Add this line to wp-config.php just before "That's all, stop editing":
define('WP_MEMORY_LIMIT', '256M');
If that doesn't work, your host restricts it at the server level. Check the actual limit by looking at your info.php output or asking support to raise it. Shared hosting plans often cap memory below what you need. That's a sign you've outgrown shared hosting.
Mistake 3: Underestimating disk space needs
A fresh WordPress install uses about 50MB. People see that and order a 1GB hosting plan, then wonder why the site crashes after six months.
Media uploads, database backups, plugin caches, and logs fill disk space fast. A single uncompressed video can be 200MB. Automated daily backups multiply that. Full disk errors look like random failures — uploads stop working, the database refuses writes, sessions break.
What to do instead:
Start with 10GB minimum. Budget for growth: every image you upload stays forever unless you delete it, and most people never do.
Check current usage in cPanel under "Disk Usage" or via SSH:
du -sh /home/username/public_html
Set up a monitoring alert at 80% capacity. When you hit that threshold, audit your /wp-content/uploads folder. Old backups sitting in your web root are usually the culprit.
Delete local backups after confirming they're stored off-site. Use something like UpdraftPlus to send backups to S3 or Dropbox instead of keeping them on the same server.
Mistake 4: Skipping database optimization requirements
WordPress ships with MySQL as the database. People install it and never think about it again until queries start timing out.
The default database settings assume you're running a small personal blog. Once your wp_options table has 5,000 autoloaded rows or your wp_posts table hits 50,000 entries, page loads crawl. Revisions pile up, transients expire but don't delete themselves, and every page load runs 50+ queries against unoptimized tables.
What to do instead:
Enable query caching and optimize tables monthly. In cPanel, open phpMyAdmin, select your database, check all tables, and choose "Optimize table" from the dropdown.
Limit post revisions in wp-config.php:
define('WP_POST_REVISIONS', 5);
Install WP-Optimize or a similar plugin to clean expired transients and old revisions automatically. Run it weekly.
If you're on shared hosting and your database shares resources with 200 other accounts, slow queries affect everyone. VPS or managed WordPress hosts give you dedicated database resources, which matters more than CPU specs for WordPress performance.
Mistake 5: Forgetting about max_execution_time limits
PHP scripts time out after 30 seconds by default. Import tools, migration plugins, and backup generators regularly need more time. They fail silently or show vague "connection reset" errors.
You start a 5,000-product WooCommerce import, walk away, come back to a white screen and half the products missing. The script hit the execution limit mid-process.
What to do instead:
Raise max_execution_time before running long operations. Add this to a custom php.ini file in your web root:
max_execution_time = 300
Or use .htaccess if your host allows it:
php_value max_execution_time 300
That gives you five minutes. For big imports, go higher or run them via WP-CLI, which ignores execution time limits:
wp import yourfile.xml --authors=create
WP-CLI is usually available on good hosts. If yours doesn't offer it, that's another red flag.
Mistake 6: Misconfiguring upload_max_filesize
The default upload limit is often 2MB. Theme installers, plugin zips, and media files exceed that constantly.
You try to upload a 5MB logo, WordPress shows a generic error, and you assume the file is corrupt. It's not. The server rejected it before WordPress even saw it.
What to do instead:
Set upload_max_filesize and post_max_size to at least 64MB. They both need to increase together because post_max_size governs the entire HTTP request.
In your custom php.ini:
upload_max_filesize = 64M
post_max_size = 64M
Restart PHP-FPM or Apache if you changed a global config. On cPanel, changes to local php.ini files take effect immediately.
Check the actual limits on the Media Upload page in WordPress admin — it displays the current maximum right on the screen.
Mistake 7: Choosing the wrong web server software
People pick hosts based on price and assume the web server doesn't matter. It does.
Apache with mod_php is fine for small sites. It struggles under traffic because it spawns a new process for every request. Nginx with PHP-FPM or LiteSpeed handles concurrency far better. The difference shows up as slow page loads when you get 50 simultaneous visitors.
LiteSpeed also supports .htaccess rewrite rules, so WordPress permalinks and redirects work out of the box. Nginx requires manual configuration.
What to do instead:
If you're on shared hosting, you're stuck with whatever the host provides. That's usually Apache or LiteSpeed.
On a VPS, install Nginx with PHP-FPM or set up OpenLiteSpeed. For WordPress specifically, managed hosts like Kinsta and Cloudways run optimized Nginx or LiteSpeed stacks by default. You don't configure anything; it just works.
Don't waste time benchmarking web servers if your site gets 500 visitors per day. The difference won't show until you scale.
Mistake 8: Neglecting SSL certificate automation
SSL certificates expire. People install Let's Encrypt, get the green padlock, and assume it's permanent. Three months later the cert expires, the site shows security warnings, and e-commerce conversions drop to zero.
Let's Encrypt certificates last 90 days by design. They renew automatically if your host or server configured the cron job correctly. Many don't.
What to do instead:
Verify automatic renewal is working. On cPanel, check "SSL/TLS Status" to see expiration dates. On a VPS with Certbot, test renewal:
sudo certbot renew --dry-run
If that succeeds, you're set. If it fails, fix it now before the cert expires in production.
Set a calendar reminder 30 days before expiration as a backup. Check the site manually. If the padlock is gone, something broke.
Managed WordPress hosts handle renewals automatically. That's part of what you're paying for.
Mistake 9: Running backups on the same server as the site
Backups stored on the same server aren't backups. They're extra copies waiting to be deleted by the same disaster that kills your site.
Server failures, account suspensions, and malware infections wipe local backups. I've watched people lose a site and all its backups because ransomware encrypted the entire disk, including the /backups folder.
What to do instead:
Store backups off-site. Use UpdraftPlus, BackupBuddy, or another plugin that pushes backups to S3, Google Drive, or Dropbox automatically.
Schedule daily database backups and weekly full backups. Keep at least two weeks of history. Test restoration quarterly by spinning up a staging site from a backup.
If your host includes cPanel backups, those count as off-site only if they're stored on separate infrastructure. Ask your host where backups actually live. If the answer is vague, assume they're local.
What matters most when picking hosting
Get these right first: PHP 8.0+, 256MB memory minimum, 10GB disk space, and off-site backups. Everything else is tuning.
Shared hosting works for new sites with light traffic. Once you hit 10,000 visits per month or run WooCommerce, move to managed WordPress hosting or a VPS. The $30/month difference prevents more downtime than any caching plugin.
Check your current specs against this list, fix the gaps, and you'll eliminate 90% of the "my site is slow" tickets before they happen.
Common questions about WordPress hosting requirements
Can WordPress run on 64MB of RAM?
WordPress core might load. Nothing else will. Plugins and themes need at least 128MB, realistically 256MB.
How do I check my PHP version without creating a file?
Log into cPanel and look under "Select PHP Version" or "MultiPHP Manager." Or ask your host's support.
What happens if I exceed my disk space limit?
The site stops accepting uploads, database writes fail, and sessions break. Users see random errors. Check usage before you hit 100%.
Do I need a dedicated server for WordPress?
No. Shared hosting works for small sites, VPS for medium traffic, and managed WordPress hosting for anything serious. Dedicated servers are overkill unless you're running a network of high-traffic sites.
How often should I optimize my database?
Monthly at minimum. Weekly if you publish daily or run WooCommerce.
Start with the PHP version and memory limit
Those two settings cause more WordPress failures than everything else combined. Fix them first, then work down the list. You don't need to guess at hosting requirements anymore — now you know exactly what to check.