WordPress Server Requirements in 2026: What the Official List Leaves Out

WordPress.org recommends PHP 7.4 or greater, MySQL 8.0 or MariaDB 10.5 or greater, and HTTPS support. Those are the floor for the software to run, not the specification for a site that stays up. A WooCommerce store on a plan that meets every published requirement will still fail on max_input_vars, a 128M memory cap, and no persistent object cache, and none of those three appear on the requirements page.

The Short Answer

Run PHP 8.3 or 8.4, MySQL 8.0 or MariaDB 10.6, 256M PHP memory, and a persistent object cache. The published minimums describe what WordPress tolerates; that list describes what a plugin-loaded site in 2026 actually needs. The gap between the two is where most "my site is slow" tickets originate.

The Published Requirements, and What They Leave Out

The official requirements have three entries: PHP 7.4+, MySQL 8.0+ or MariaDB 10.5+, and HTTPS support. Apache or Nginx are named as the recommended servers. That list is deliberately conservative, because WordPress core is written to run almost anywhere, and it does.

PHP version is a security decision before it is a speed decision

PHP branches get roughly two years of active support followed by one year of security fixes, on a schedule published by php.net. On that cadence, PHP 8.1 fell out of security support at the end of 2025, PHP 8.2 runs out at the end of 2026, PHP 8.3 at the end of 2027, and PHP 8.4 at the end of 2028. A host still defaulting new accounts to 8.1 in 2026 is defaulting them to an unpatched interpreter.

Version also moves throughput. Each 8.x release has been measurably faster than the last on typical WordPress workloads, and the jump from 7.4 to 8.x is the largest single free performance change available to most sites. Check the current version in the WordPress admin under Tools, then Site Health, then Info, then Server. If it reads 7.4 or 8.0, the fix is a dropdown in the hosting panel on nearly every host, and it costs nothing.

The PHP extensions nobody lists

WordPress core and the common plugin stack expect a specific extension set: json, mysqli, curl, dom, exif, fileinfo, hash, mbstring, openssl, pcre, sodium, xml, and zip, with imagick strongly recommended for image handling. A host missing imagick falls back to GD, which produces visibly worse resized images and cannot handle some formats. Site Health flags missing extensions, and it is the first place to look when image uploads behave strangely.

Published requirements per the WordPress.org requirements page as of 2026. Loaded-site figures reflect the values the common plugin stack needs; verify against your own plugin documentation.

What the Numbers Mean for the Buying Decision

Three of these settings account for most of the difference between a plan that works and a plan that does not, and only one of them is advertised.

The memory cap is the hard wall. WordPress core sets WP_MEMORY_LIMIT to 40M for single sites and 64M for multisite by default, and it can be raised in wp-config.php, but only up to whatever the host's PHP configuration permits. A host capping PHP at 128M means WooCommerce and page builders run against a ceiling regardless of what your config file says. This value is rarely on the pricing page and is always in the knowledge base. Look it up before buying.

max_input_vars fails silently, which makes it worse. The PHP default is 1000. A WooCommerce product with many variations, or a menu with a few hundred items, exceeds that, and PHP simply drops the extra fields without an error. The symptom is data that will not save and no message explaining why. A host that sets this to 3000 or higher by default has thought about WordPress specifically.

The object cache is the largest available performance difference. Page caching serves anonymous visitors a static copy and is nearly universal. A persistent object cache stores database query results between requests, which is what speeds up logged-in traffic, cart pages, and admin screens, the exact pages page caching cannot help. Managed WordPress plans generally include Redis; entry shared plans generally do not. This distinction is covered in more depth in the shared versus managed WordPress comparison.

Who Should Buy What

• Buy entry shared hosting if: the site is a brochure or a low-traffic blog, PHP 8.3 is available in the panel, and there is no store. The published requirements are enough here, and paying for Redis you will not use is waste.
• Buy mid-tier or business shared if: you need 256M memory and raised input limits but not dedicated resources. SiteGround and GreenGeeks both sit in this band; check the specific plan's memory and Redis availability, since both vary by tier rather than by brand.
• Buy managed WordPress if: the site is a store, a membership site, or anything with meaningful logged-in traffic. Kinsta, WP Engine, and Rocket.net ship Redis, current PHP, and WordPress-aware limits as defaults rather than as upgrades. Pricing for this tier is broken down in the managed WordPress pricing guide.
• Buy cloud or VPS if: you want to set these values yourself and have someone who can. Cloudways and Nexcess sit between managed and raw VPS. The tradeoff is worked through in the cloud VPS versus managed hosting decision.
• Skip a plan if: the host will not tell you the PHP memory limit, will not confirm max_input_vars, or has no Redis or Memcached option at any tier. Those three answers are free to obtain before purchase and expensive to discover after migration.

The Fine Print

Three details reliably surprise buyers after checkout.

Renewal pricing is the first. Shared plans advertising a low monthly rate almost always quote a 12-month or 36-month prepay at an introductory rate, with renewal landing substantially higher. The spec sheet does not change at renewal; the price does. Confirm the renewal rate before the first invoice rather than after, using the approach in the renewal pricing guide.

Resource limits below the advertised ones are the second. A plan advertising unmetered bandwidth typically has a concurrent-process or CPU-seconds limit in the terms of service, and those are what actually throttle a busy site. Ask for the number.

PHP version pinning is the third. Some hosts let you select a version and then hold it back for shared-node compatibility, or roll accounts forward automatically on a schedule you do not control. Both behaviors are defensible; neither is discoverable from the pricing page. Ask whether version selection is per-account and whether forced upgrades are announced.

The Verdict

Treat the WordPress.org requirements as a compatibility statement rather than a buying specification. The four numbers that decide whether a plan works are PHP version, PHP memory limit, max_input_vars, and whether a persistent object cache is available, and exactly one of those is usually advertised. Get all four in writing before buying, run Site Health after migrating, and re-check PHP version annually against the php.net support schedule. For sites already outgrowing an entry plan, the sizing thresholds are laid out in the small business hosting sizing guide.

Compare hosting plans on HostingDive with the specs, renewal pricing, and support response data side by side.

Frequently Asked Questions

What PHP version should WordPress run on in 2026?

PHP 8.3 or 8.4. WordPress.org still lists 7.4 or greater as the requirement, but PHP 8.1 left security support at the end of 2025 and 8.2 does so at the end of 2026 on the published php.net schedule. Running 8.3 or 8.4 buys both security headroom and the throughput gains of the newer branches.

How much PHP memory does WordPress actually need?

WordPress core defaults WP_MEMORY_LIMIT to 40M for single sites and 64M for multisite, which is enough for core alone. A real plugin stack wants 256M, and WooCommerce at scale wants 512M. The value in wp-config.php cannot exceed the host's own PHP limit, so a 128M host cap is a hard ceiling no matter what you write in the config.

What is max_input_vars and why does it break WooCommerce?

It caps how many input fields PHP accepts in a single request, defaulting to 1000. A product with many variations or a large menu exceeds that, and PHP discards the surplus without raising an error, so the save appears to succeed and the data is gone. Setting it to 3000 or higher resolves it, and hosts that tune for WordPress usually already have.

Do I need Redis or is page caching enough?

Page caching is enough for a site whose visitors are all anonymous. It does nothing for logged-in users, carts, checkout, or the admin, because those pages cannot be served from a static copy. A persistent object cache such as Redis or Memcached is what speeds those up, which is why it matters for stores and membership sites and not for a brochure site.

How do I check what my current host is actually providing?

In the WordPress admin, open Tools, then Site Health, then the Info tab, then the Server and Database panels. That reports PHP version, memory limit, max_input_vars, max_execution_time, database server and version, and the loaded extensions. It reads the live configuration rather than the plan description, which is the point.