WordPress Server Requirements: PHP, MySQL and Cron

WordPress' official minimum requirements are almost useless for judging real hosting. They're a floor, not a spec for a site that needs to survive a plugin update, a traffic spike or a client hitting "publish" on a 40MB PDF. What you actually need is a supported PHP version, MySQL or MariaDB at a sane version, HTTPS by default, a memory limit north of the WordPress default, generous execution time, proper upload limits, working rewrite rules and real cron. Here's how to check every one of those on a host you're considering, not just take their word for it.

What does WordPress officially require?

The official WordPress requirements page lists PHP, MySQL or MariaDB, and HTTPS support. That's it. No mention of memory limits, execution time, upload caps or cron reliability, which is exactly why I get calls from agencies whose "compatible" hosting can't handle a media-heavy import or a scheduled backup. Compliance with the official minimum tells you the host can technically install WordPress. It tells you nothing about whether it can run one properly.

Which PHP version should you actually be running?

Check php.net's supported versions page before you sign up anywhere. You want a version still receiving active support, not one limping through its final months on security-only patches. I've inherited client accounts running PHP versions that had already gone end of life, because the host never forced an upgrade and nobody asked. That's not a hypothetical risk. It's a support ticket waiting to happen the moment a plugin drops compatibility.

How to check it on a live host: log into cPanel or the host's control panel and look for "PHP Selector," "MultiPHP Manager" or similar. If you can't find a version switcher anywhere in the dashboard, that's itself a red flag. Good WordPress hosting gives you visible, changeable PHP versions, not a fixed setting buried behind a support ticket.

What MySQL or MariaDB version does WordPress need?

WordPress' documented minimum sits around MySQL 5.7 or MariaDB 10.3, but plenty of current plugins and themes assume something newer. Older database versions also tend to be slower on the query patterns WordPress actually runs, particularly on sites with heavy custom post type usage or WooCommerce.

You can check this from phpMyAdmin (look at the server info panel) or by adding a quick line to a test file that echoes the database version. If a host can't tell you their default MySQL or MariaDB version without you digging for it yourself, don't assume it's current.

Is HTTPS actually required to run WordPress?

Not officially in the strictest sense, but functionally, yes. Modern browsers flag non-HTTPS sites, Google treats HTTPS as a baseline ranking signal, and plenty of plugins and payment integrations simply refuse to work without SSL. Any host worth using now includes a free certificate, usually via Let's Encrypt, applied automatically at signup. If a provider is charging extra for basic SSL, that's a pricing decision worth noticing, not a technical limitation. I've covered what genuinely protects a WordPress install, HTTPS included, in more detail in Secure WordPress Hosting: What Actually Protects Your Site.

What memory limit does WordPress actually need?

WordPress core will technically start with very little memory, but the moment you add a handful of plugins, a page builder and an SEO tool, you'll hit the wall fast. Anything under 128M as a PHP memory limit is going to cause white screens and silent failures the first time you try to bulk-update plugins or import content. I've had clients on cheap shared plans stuck at 64M wondering why their site kept dying during routine maintenance. The fix wasn't a plugin conflict. It was the hosting plan.

How to check it: install a simple plugin like Site Health (built into WordPress core under Tools) and look at the PHP memory limit reported there. You can also add define('WP_MEMORY_LIMIT', '256M'); to wp-config.php, though that only raises the ceiling if the underlying PHP configuration allows it. If your host's PHP.ini caps memory below what WordPress requests, the WordPress constant does nothing.

What max execution time and upload size do you actually need?

Default PHP max execution time on plenty of budget hosts sits around 30 seconds, which sounds fine until a plugin installation, a large import or a backup job needs longer than that to complete. Anything doing real work, migrations, WooCommerce order processing, media imports, wants at least 60 to 90 seconds of headroom, and ideally a host that lets you raise it further for specific tasks.

Upload size is the other quiet limiter. Default PHP upload_max_filesize on many shared plans sits low enough that a single high-resolution product photo or a short video clip gets rejected outright. Check both upload_max_filesize and post_max_size, not just one, because WordPress needs both raised to actually accept larger files. You'll find these settings in the same PHP configuration panel as your memory limit, or in a php.ini file if you're on VPS or dedicated hosting.

Do you need mod_rewrite or nginx rewrite rules?

Yes, without exception, if you want clean permalinks instead of ugly query-string URLs. On Apache, this means mod_rewrite needs to be enabled and .htaccess overrides need to be permitted at the server level, not just present in your WordPress install. On nginx, there's no .htaccess equivalent, so the host needs to have written proper rewrite rules into the server block for WordPress specifically. I've seen agencies migrate to nginx-based hosts and lose working permalinks overnight because the host's default config didn't account for WordPress's rewrite structure at all.

How to check it: go to Settings > Permalinks in WordPress and save the "post name" structure. Then visit a non-homepage page directly. If you get a 404, either the rewrite rules aren't in place or .htaccess overrides are disabled server-side. That's a support ticket to the host, not a WordPress problem.

Does WordPress need cron, and will your host actually run it?

WordPress has its own pseudo-cron, wp-cron.php, which fires on page load rather than on a real schedule. On low-traffic sites this means scheduled posts, scheduled backups and plugin update checks can sit delayed for hours because nobody visited the site to trigger the fake cron event. The fix is disabling WP-Cron in wp-config.php and setting up a real system cron job through the host's control panel to hit wp-cron.php on an actual schedule. Cheap shared hosts sometimes don't expose cron job management at all, or bury it several menus deep, which tells you plenty about how seriously they take anything beyond the basic install.

What do "unlimited" hosting plans quietly cap?

Nothing is genuinely unlimited, and the fine print always exists somewhere. "Unlimited storage" plans commonly cap inode counts (the total number of files, including every cached thumbnail and email), which trips up media-heavy sites long before disk space becomes the issue. "Unlimited bandwidth" plans often throttle CPU seconds or concurrent processes instead, so your site technically stays online but crawls under any real traffic. I've walked through exactly this pattern, and several others that quietly cost agencies clients, in 5 WordPress Hosting Mistakes That Cost Agencies Clients. Read the acceptable use policy, not the marketing page, before you trust the word "unlimited" on anything.

How do you check all of this on a host before you commit?

Most reputable hosts give you a trial period or a short money-back window specifically so you can test this. Sign up, install WordPress, and immediately check Site Health under Tools in wp-admin. It reports PHP version, memory limit and several other server details in one place. Then manually test permalinks, try uploading a large file, and check whether cron jobs are manageable from the control panel. If a host resists giving you this level of visibility, or support can't answer direct questions about PHP version and memory limits without escalating the ticket, that tells you what kind of support you'll get once something actually breaks. For general-purpose WordPress sites, start with our best WordPress hosting picks. If budget is the priority, our cheap hosting comparison flags which providers still hit these technical marks without the premium price tag. And if you want the server-level requirements handled entirely for you, managed WordPress hosting exists specifically so you never have to think about php.ini again.

Frequently asked questions

What is the minimum PHP version for WordPress?

WordPress core will technically install on older PHP branches, but you should never run a version that php.net no longer actively supports. Check the current supported versions list directly rather than trusting a host's marketing claim about compatibility.

How much memory does WordPress actually need?

The bare WordPress default is low enough to cause problems the moment you add plugins and a theme with any complexity. In practice, 128M is a sensible working minimum, and sites running page builders, WooCommerce or several active plugins should look for hosting that allows 256M or higher.

Why does my WordPress site show a 404 on every page except the homepage?

This is almost always a rewrite rule problem. Either mod_rewrite isn't enabled on Apache, .htaccess overrides are disabled at server level, or on nginx the host hasn't configured the rewrite block WordPress needs. Re-saving your permalink structure won't fix a server-side rewrite issue.

Does WordPress need real cron or does WP-Cron work fine on its own?

WP-Cron only fires when someone visits the site, so on lower-traffic installs, scheduled tasks like backups and scheduled posts can sit delayed. Disabling WP-Cron in wp-config.php and setting up a genuine system cron job through your host gives you reliable, on-time execution instead.