Most WordPress hosting problems I see in support tickets aren't caused by bad hosts. They're caused by mismatched requirements. Site owners pick a plan, install WordPress, and wonder why plugins time out or the dashboard crawls. The gaps between what WordPress technically needs and what it actually needs to run well are where these mistakes hide.
Here are the nine configuration errors I see most often, plus the correct approach for each.
Mistake 1: Trusting the "Minimum Requirements" Page
WordPress.org lists PHP 7.4 and MySQL 5.7 as minimums. That's technically true—WordPress will install. But running a production site on those versions is a different story.
Modern plugins assume PHP 8.0 or newer. WooCommerce, Yoast, and Elementor have all dropped support for PHP 7.4. You'll install a plugin, see a white screen, and spend an hour troubleshooting before you realize the plugin's changelog quietly required PHP 8.1 six months ago.
The correct approach: Start with PHP 8.1 or 8.2. Check your host's control panel (usually under "Select PHP Version" in cPanel) and switch before you install plugins. If you inherit a site on PHP 7.4, budget time to test the upgrade on a staging copy first.
MySQL 5.7 is end-of-life. Use MySQL 8.0 or MariaDB 10.6 if your host offers it. The performance difference is real, especially on sites with heavy WooCommerce traffic.
Mistake 2: Ignoring PHP Memory Limits
WordPress's default memory limit is 40 MB for single sites and 64 MB for multisite. That's enough to display the Twenty Twenty-Four theme and nothing else. Add WooCommerce, a page builder, and a caching plugin, and you'll hit the limit on every admin page load.
The symptom: "Fatal error: Allowed memory size of 41943040 bytes exhausted." Usually happens when you try to save a page or update a plugin.
The correct approach: Set WP_MEMORY_LIMIT to 256 MB in wp-config.php:
define('WP_MEMORY_LIMIT', '256M');
For admin pages, also set:
define('WP_MAX_MEMORY_LIMIT', '512M');
If that doesn't work, your host is enforcing a lower memory_limit in php.ini. On shared hosting, you'll need to request an increase through support. On a VPS, edit /etc/php/8.1/fpm/php.ini (adjust the path for your PHP version) and restart PHP-FPM.
Don't just throw RAM at the problem forever. If you need more than 512 MB, profile the site with Query Monitor to find the actual bottleneck.
Mistake 3: Misunderstanding "Unlimited" Hosting
Shared hosting plans advertise unlimited bandwidth and storage. What they don't advertise: the CPU and I/O limits that will throttle your site the moment you get real traffic.
I've worked tickets where a site on "unlimited" hosting could barely serve 50 concurrent visitors. The host's acceptable-use policy had a clause about "excessive resource usage," and the threshold was hitting 1% CPU for more than 90 seconds.
The correct approach: Ask these questions before you buy:
- What are the CPU core limits (often listed as "entry processes" in cPanel hosts)?
- What's the IOPS cap on disk I/O?
- At what traffic level do you recommend upgrading to VPS?
If the host won't answer, pick a different host. For reference, a typical shared account can handle 10,000 to 30,000 monthly page views if the site is optimized. Beyond that, you need VPS or cloud hosting.
Mistake 4: Skipping the Database Charset Check
WordPress defaults to utf8mb4 for the database charset and utf8mb4_unicode_ci for collation. Older hosts or manually created databases sometimes default to latin1 or plain utf8, which breaks emoji, non-Latin scripts, and certain plugins.
You won't notice until a user pastes an emoji into a comment or WooCommerce tries to log a product name with Chinese characters. Then you get mojibake or silent data truncation.
The correct approach: Check your database charset before you install WordPress. Log into phpMyAdmin, click your database, and look at the "Collation" column. It should say utf8mb4_unicode_ci or utf8mb4_general_ci.
If it's wrong, you have two options. Convert the existing database:
ALTER DATABASE your_database_name CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
Then convert each table:
ALTER TABLE wp_posts CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
Or drop the database and let WordPress create a new one with the correct charset during installation. The second option is cleaner if you're starting fresh.
Mistake 5: Running Without Opcode Caching
PHP is an interpreted language. Every page load compiles PHP files into bytecode, then executes them. OPcache stores the compiled bytecode in memory so PHP doesn't repeat the work.
Without OPcache, your server recompiles WordPress core, your theme, and 30 plugins on every single request. I've seen this cut response times by 40% once enabled.
The correct approach: Verify OPcache is active. Create a file called info.php in your document root:
<?php phpinfo(); ?>
Visit https://yoursite.com/info.php and search for "opcache." If opcache.enable is off, ask your host to enable it. On a VPS, edit php.ini:
opcache.enable=1
opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=10000
opcache.revalidate_freq=60
Restart PHP-FPM, delete info.php, and test.
Mistake 6: Treating Backups as Optional
So what if your host includes daily backups in the plan?
Host backups are for disaster recovery—hardware failures, data center fires. They're not for rolling back a plugin update that broke your checkout page five hours ago. By the time you open a ticket, the bad version is in tonight's backup snapshot, and yesterday's backup is missing the orders that came in this morning.
The correct approach: Run your own backups independently of the host. Use a plugin like UpdraftPlus or BackWPup, and send copies to a separate location—Amazon S3, Google Drive, or Backblaze B2.
Schedule database backups daily and full backups weekly. Keep at least 7 days of rolling backups. Before you update plugins or themes, take a manual backup and download it locally.
Test a restore at least once. I've seen backups run for 6 months without anyone realizing the restoration process was broken.
Mistake 7: Misconfiguring File Permissions
WordPress wants to write files—uploads, plugin installs, theme edits. Shared hosting usually sets ownership to the Apache or Nginx user, which breaks automatic updates unless permissions are wide open.
The common fix: chmod 777 on wp-content. That works, but now any PHP script on the server (including malware in someone else's compromised account) can write to your site.
The correct approach: Set files to 644 and directories to 755:
find /home/username/public_html -type f -exec chmod 644 {} \;
find /home/username/public_html -type d -exec chmod 755 {} \;
Then set wp-config.php to 440:
chmod 440 wp-config.php
If WordPress still can't write files, the ownership is wrong. On cPanel, ownership should match your account username, not nobody or apache. Run:
chown -R username:username /home/username/public_html
Some hosts require you to define FTP credentials in wp-config.php to enable automatic updates. That's a red flag—it means the host hasn't configured suEXEC or PHP-FPM properly. Consider moving.
Mistake 8: Assuming More Disk Space = Better Hosting
Shared hosting plans compete on storage numbers. But a WordPress site rarely needs more than 5 GB unless you're hosting video files locally (which you shouldn't).
What matters: the type of disk and how it's shared. A site on NVMe storage with high IOPS will outperform a site on HDD with 500 GB of space. I've migrated sites from "unlimited storage" plans to 25 GB SSD VPSs and watched load times drop by 60%.
The correct approach: Prioritize SSD or NVMe over total capacity. Monitor actual disk usage through cPanel or du -sh /home/username/public_html. Most sites use 1-3 GB including the database.
Store media on a CDN or object storage (Cloudflare R2, Bunny CDN, AWS S3). Your hosting disk is for code and the database, not images.
Mistake 9: Forgetting About Max Execution Time
PHP's max_execution_time defaults to 30 seconds on most hosts. WordPress admin tasks—plugin updates, theme imports, WooCommerce CSV exports—can take longer. When they hit the timeout, you get a blank screen or a partial action with no error message.
The correct approach: Increase the timeout for admin pages. Add this to wp-config.php:
if (is_admin()) {
set_time_limit(300);
}
That gives admin requests 5 minutes. If the host's php.ini overrides set_time_limit, use .htaccess (for Apache with mod_php):
php_value max_execution_time 300
Or create a user.ini file in your document root (for PHP-FPM):
max_execution_time = 300
Don't set it higher than 300 seconds. If a task takes longer than that, something is broken—probably an infinite loop or an undersized database query that's scanning millions of rows.
What to Check First
Most WordPress hosting issues come down to three settings: PHP version, memory limits, and OPcache. Check those first when troubleshooting slow admin pages or plugin errors. File permissions and execution timeouts are the next most common culprits.
The "minimum requirements" listed on WordPress.org will get the software installed. They won't keep your site fast or stable under real traffic. Budget your hosting plan around the actual workload—page views per month, plugin count, and whether you run WooCommerce—not the marketing bullet points.