Category: WordPress

Your Hosting Says 100% Full With 8 GB Free: How to Fix a WordPress Inode Limit

Why an Inode Limit Reports "Full" While Your Disk Is Half Empty
How to Check Your Inode Limit and Usage in cPanel
The AHosting Inode Ladder and the 42 KB Crossover
What Actually Eats Inodes on a WordPress Account
Find the Real Consumer: A Directory-Level Inode Census
Reduce Inode Usage Safely, in Order of Payoff
Estimate Which Ceiling You Will Hit First
When the Honest Answer Is a Higher Inode Ceiling
A Practical Checklist for Clearing an Inode Limit
Frequently Asked Questions About Inode Limits on Shared Hosting

TL;DR

An inode limit counts files, not bytes, so an account can report itself full with most of its disk unused. Open cPanel and read the File Usage row in the Statistics panel against the Disk Usage row above it. If the file count is near its ceiling while storage is not, adding gigabytes fixes nothing — find the directory holding the files instead, and start with mail, cache and old backups.

Nothing about this failure looks like a capacity problem, which is exactly why it costs people an afternoon. The media library refuses an upload. A plugin update dies halfway through. Last night’s backup says it finished and produced no file. Then you open cPanel, see 3 GB used of 10 GB, and conclude the host is broken. It is not: you have hit an inode limit, a second ceiling that counts how many files you store rather than how large they are. This guide shows you how to confirm it in two minutes, how to find the directory actually responsible instead of guessing, and how to tell a cleanup job from a tier you have genuinely outgrown.

Listen: why a hosting account can refuse every write with gigabytes of disk unused, and the four directories that almost always turn out to be holding the files. By Matt Chrust, Director of Business Development, AHosting.

Why an Inode Limit Reports “Full” While Your Disk Is Half Empty

Your account is capped twice, and the two caps measure different things. One counts bytes and is the number every hosting plan advertises. The other counts entries in the file system — one per file, one per directory — and most people never see it until it stops them. In POSIX terms that entry is the file serial number, described in the standard as a per-file-system unique identifier for a file; on Linux it is universally called an inode, and cPanel labels the running total File Usage.

The consequence of counting entries rather than bytes is the whole of this problem. Size is irrelevant to the count: one 2 GB archive costs a single entry, while 20,000 cache fragments of four kilobytes each cost 20,000. An account can therefore be 96 percent of the way through its file allowance while showing a third of its disk used, and no graph anyone normally looks at will hint at it.

What breaks when the ceiling is reached is every write, all at once and permanently until something is deleted. Uploads fail. Updates fail partway and leave a half-installed plugin. Incoming mail is rejected at the server. Worst of all, scheduled backups stop producing files while still reporting success, so the one thing that would let you recover quietly stops existing. Reading is unaffected, which is why visitors notice nothing and you notice everything.

How to Check Your Inode Limit and Usage in cPanel

Two numbers settle this, and both are already on the screen you land on. Log in to cPanel and look at the Statistics panel down the right-hand side. Find the row labeled File Usage: it prints your current count and your ceiling, separated by a slash, in the form 249,120 / 250,000. Directly above it sits Disk Usage in gigabytes.

Read them as a pair, never one at a time. That pairing is the diagnostic, because it tells you which ceiling is close and therefore which problem you actually have:

File Usage near its ceiling, Disk Usage nowhere near — this article. More storage would change nothing.
Disk Usage near its ceiling, File Usage comfortable — an ordinary storage problem. Find the large files.
Both close — the account is simply full in every sense, and the tier is the answer rather than a cleanup.
Neither close, writes still failing — not a capacity problem at all. Check file permissions and ownership before anything else.

One caution about the reading itself: File Usage is a snapshot updated on a schedule, not a live counter, so a large deletion can take a while to show. Give it time before concluding that a cleanup achieved nothing. Our knowledge base covers the same ground from the server side in understanding inodes and running out of them.

The AHosting Inode Ladder and the 42 KB Crossover

Most hosts do not publish a file ceiling at all, which makes the number impossible to plan against. We publish it on the plan pages beside the storage figure, and reading the two together produces something more useful than either alone. Divide the storage a plan allows by the files it allows and you get the average file size at which both ceilings fill on the same day. Below that figure the count binds first; above it, storage does.

Plan	SSD storage	File ceiling	Files per GB	Crossover average file size
Bronze	10 GB	250,000	25,000	42 KB
Silver	20 GB	400,000	20,000	52 KB
Gold	50 GB	600,000	12,000	87 KB

The AHosting Inode and Storage Ladder — ceilings published on the shared and managed plan pages, and the average file size at which the two ceilings meet on each tier.

Two things fall out of that table. The first is a test you can apply to your own account in ten seconds: mail messages average a few kilobytes, cache fragments similar, and thumbnails commonly run 10 to 60 KB, so any account whose bulk is those three sits below the crossover. Photo originals, video and archives sit far above it.

The second matters when you are choosing a tier. Files per gigabyte falls as the ladder rises — 25,000, then 20,000, then 12,000 — because larger plans are shaped for accounts holding larger files. Gold carries five times the storage of Bronze but only 2.4 times the inode limit. For a media library that is right; for a mail-heavy account it means a tier buys less relief than the storage headline suggests. Every tier is listed on our shared web hosting plans.

What Actually Eats Inodes on a WordPress Account

Four things account for almost every case of an inode limit, and WordPress core is not one of them. A bare installation with a theme and a handful of plugins usually holds 10,000 to 20,000 files, a small fraction of even the entry ceiling. Everything below grows without a natural stopping point, which is the property that matters.

Media Uploads, Multiplied by Every Registered Size

One photograph is never one file. WordPress generates a derivative for each registered image size, and core alone reserves several by name — thumbnail, medium, medium_large and large — then adds further default sub-sizes on top, as the add_image_size reference sets out. Themes and page builders register more. Since version 5.3 an upload wider than 2,560 pixels also gets a scaled copy alongside the preserved original, so a single large photograph can land as eight files. Upload a thousand and the arithmetic stops being abstract.

Email, Where Every Message Is Its Own File

This is the one that catches people, because mail feels like it lives somewhere else. It does not. cPanel stores mail in Maildir format, whose founding property is that each message is stored in a separate file with a unique name. A mailbox holding 40,000 messages is holding 40,000 entries against your ceiling, and Spam and Trash folders are the usual culprits precisely because nothing empties them and nobody looks. Attachment size is beside the point here: a hundred one-line notifications cost exactly what a hundred invoices cost.

Page and Object Caches, Which Write a File Per Cached URL

Caching trades files for speed, and the trade is usually worth making. Full-page caching stores each cached page on disk, so a site with 5,000 URLs can hold thousands of cache files, and warming the cache with a crawler builds that set on purpose. LiteSpeed’s own cPanel documentation shows the per-site cache root configured under the account home directory, so on most cPanel servers those files sit inside your quota. Purging is not a fix, merely a deferral, and it costs you the performance you turned caching on for.

Backups, Staging Copies and Migration Leftovers

Duplicate trees are the quiet giant. A staging site is a second complete copy of every file you have, which is why we recommend running one on hosting built for WordPress staging rather than as a folder inside a full account. Backup plugins that keep local copies store an extracted tree per restore point. Migration debris outlives its usefulness by years, and our guide to migrating WordPress to a new host ends with the cleanup step most people skip.

Find the Real Consumer: A Directory-Level Inode Census

Guessing is the expensive part of this job. Deleting things at random can free tens of thousands of entries and still leave you at the inode limit, because the directory responsible was somewhere you never opened. A census fixes that by ranking directories by file count, and it takes about five minutes.

If you have terminal access, one command does the whole job. GNU coreutils documents du –inodes as being useful for exactly this — finding the directories that contain many files. Run du --inodes -x -d 3 ~ | sort -rn | head -30 from your home directory and read the list from the top; -x keeps it on one file system and -d 3 stops it drowning you in depth.

Without terminal access the same result comes from cPanel’s File Manager, more slowly. Start at the account root and work down, checking these five locations in this order, because they are ranked by how often each turns out to be the answer:

mail/ — every domain, and inside each one the Spam, Junk and Trash folders.
public_html/wp-content/cache/ and any sibling cache directory a plugin created.
public_html/wp-content/uploads/ — sorted by year, so you can see when it accelerated.
Old backup and staging directories anywhere in the account, including outside public_html.
.trash, tmp and .cagefs, which are easy to forget and occasionally enormous.

Write down the count before you start deleting. Without a baseline you cannot tell whether a cleanup freed 2,000 entries or 200,000, and that difference decides whether the next step is another cleanup or a tier.

Reduce Inode Usage Safely, in Order of Payoff

Work down this list and stop when File Usage drops clear of the inode limit. Order is deliberate: each row costs less than the one below it and, on the tickets we see, clears more. Every one of them is reversible except where noted.

Order	Change	What it frees	Effort
1	Empty Spam, Junk and Trash on every mailbox, then set them to auto-purge	Often 30–60 percent of the count on a mail-heavy account	Minutes
2	Delete old backup archives and any extracted restore trees held locally	Whole duplicate file trees at once	Minutes
3	Remove staging and migration leftovers you no longer need	A second complete copy of the site	Minutes
4	Purge page and object cache directories once, as a temporary measure	Thousands of small files, which will rebuild	Minutes
5	Uninstall plugins and themes you do not use, rather than deactivating them	Deactivating frees nothing; the files remain	Minutes
6	Unregister image sizes you never serve, then regenerate thumbnails	Several files per uploaded image, permanently	An hour
7	Move video and large media to object storage or a media host	Removes the growth curve rather than a snapshot	Developer time

Inode reduction in order of payoff — highest-yield and cheapest changes first.

Row 6 deserves a warning, since it is the only one that is not simply reversible: unregistering a size and regenerating thumbnails deletes derivatives that existing posts may reference. Check what your theme actually serves before you run it. Row 5 deserves a correction of a common belief — deactivating a plugin frees nothing at all, because every file stays exactly where it was.

Estimate Which Ceiling You Will Hit First

Both numbers this needs are on your cPanel home screen already. Put them in and it will tell you how far along each ceiling you are, what your average file size works out at, and which of the two will stop you first — which is the only question that decides what you should do next.

Inode Limit Headroom Check

Both figures this needs are already on your cPanel home screen: File Usage and Disk Usage, in the Statistics panel. It compares how far you are along each ceiling and names the one that will stop you first.

Your plan

Your File Usage count

Your Disk Usage in GB

—

Average file size is your storage divided by your file count, and it is the number that decides which ceiling you meet first. Deleting one large archive changes the disk figure and barely moves the file figure; emptying a spam folder does the opposite.

When the Honest Answer Is a Higher Inode Ceiling

Sometimes the files are the business. If you have worked down the list and what remains is a real media library, real customer mail and a cache serving real traffic, then nothing is misconfigured and the allowance is simply too small for what you run. The test we use is whether you can name what is holding the entries: if you can and it is work the site actually does, the ceiling is the problem; if you cannot, it is not.

That is the point where a tier change is the fix rather than an upsell, and the ladder moves every account-wide ceiling on the same step — file count, storage, entry processes, memory and disk throughput together. A content or membership site is usually served by the next step up on managed WordPress hosting. A store is a different shape: order mail, invoices and product image variants make stores unusually file-dense for their size, which is worth knowing before you size WooCommerce hosting. Where a single account is carrying many sites, the shared model itself is the constraint and VPS hosting gives you the whole file system rather than a slice of one.

Before you decide, check the other ceilings in the same sitting, because accounts that run out of files often turn out to be near something else as well. Our write-up of the 508 resource limit error covers the concurrency ceiling, and the companion piece on disk I/O throttling covers the one that never returns an error at all. Clean up first; move when the cleanup runs out.

A Practical Checklist for Clearing an Inode Limit

Writes are failing while reads work normally, and the errors blame permissions or disk space rather than an inode limit.
cPanel Statistics has been opened and File Usage read as a pair with Disk Usage, not one alone.
The file count is genuinely near its ceiling while storage is not — otherwise this is a different problem.
A baseline count was written down before anything was deleted.
Mail was checked first, per domain, including Spam, Junk and Trash on every mailbox.
Backup archives, extracted restore trees and staging copies have been located and assessed.
Cache directories were counted, and it is understood that purging them is a deferral rather than a fix.
Unused plugins and themes are uninstalled rather than merely deactivated.
Registered image sizes have been reviewed against what the theme actually serves.
If the count is still near the ceiling, the files that remain can be named and tie to work the site really does.

Frequently Asked Questions About Inode Limits on Shared Hosting

What does it mean when a hosting account hits its inode limit in 2026?

Typically it means your account has reached the maximum number of files and directories it is allowed to hold, which is counted separately from how many gigabytes those files occupy. Every file counts as exactly one entry regardless of size, so a single 2 GB archive costs one and twenty thousand tiny cache fragments cost twenty thousand. Once the ceiling is reached the account can no longer create anything: uploads fail, plugin installs fail, backups fail and incoming mail is rejected, usually with error messages that mention permissions or disk space rather than the real cause.

How do I check my inode limit and current usage in cPanel?

First and foremost, look at the Statistics panel down the right-hand side of the cPanel home screen and find the row labeled File Usage. It prints two numbers separated by a slash: the count of files and directories your account currently holds, and the ceiling your plan allows. Read that alongside the Disk Usage row directly above it, because the pair is what tells you which of the two ceilings is actually close. If File Usage reads 249,120 of 250,000 while Disk Usage sits at 3 GB of 10 GB, the file count is your constraint and adding storage would change nothing.

Inode limit vs disk space: which one runs out first on a WordPress site?

In practice the answer depends entirely on your average file size, and there is a specific number where the two ceilings meet. Divide the storage your plan allows by the file count it allows and you get the average size at which both fill on the same day. Below that figure the file count binds first; above it, storage does. WordPress accounts that carry a lot of email, a large page cache or years of thumbnail variants sit well below the crossover, which is why an inode limit surprises people who have been watching their disk graph.

Inode limit vs entry process limit: how do the two failures differ?

By contrast with an entry process limit, which throttles you only while traffic is heavy and clears itself the moment the rush passes, an inode limit is a hard stop that does not recover on its own. Running out of entry processes returns a 508 to some visitors for a few minutes; running out of files stops every write on the account until you delete something. The two also fail in different places. One is visible to your visitors and invisible in cPanel, and the other is invisible to your visitors and printed on the cPanel home screen in plain numbers.

What is the inode limit on AHosting shared hosting plans in 2026?

Notably, AHosting publishes the ceiling on the plan pages rather than describing it in adjectives. Bronze allows 250,000 files against 10 GB of SSD storage, Silver allows 400,000 against 20 GB, and Gold allows 600,000 against 50 GB. Those pairs are worth reading together, because the file allowance per gigabyte falls as the tiers rise: 25,000 per GB on Bronze, 20,000 on Silver and 12,000 on Gold. Higher tiers are calibrated for accounts holding larger files, so a mail-heavy or cache-heavy account gains proportionally less headroom from a tier change than a media-heavy one does.

Does email count toward the inode limit on a cPanel account?

Indeed it does, and on many accounts it is the single largest consumer. cPanel stores mail in the Maildir format, whose defining property is that each message is written as its own file, so a mailbox holding 40,000 messages holds 40,000 files. Spam and Trash folders are the usual offenders because nothing deletes them automatically and nobody looks at them. Attachments make the size worse but not the count; a hundred one-line notifications cost exactly as much against the ceiling as a hundred messages carrying invoices.

What happens to a WordPress site when the inode limit is reached?

Specifically, the site keeps serving pages and stops being able to write anything. Visitors usually notice nothing at first, because reading existing files is unaffected. Inside wp-admin the failures start immediately: media uploads return an error about the upload directory not being writable, plugin and core updates fail partway through, and any plugin that writes a log or a cache file fails silently. The most damaging symptom is the quiet one, which is that scheduled backups stop completing while still reporting that they ran.

How does LiteSpeed Cache on AHosting affect how many files an account stores?

Fortunately the trade is usually worth making, but it is a genuine trade and it is worth understanding before you tune anything. Full-page caching works by writing each cached page to disk as a file, so a site with 5,000 URLs can hold thousands of cache files at once, and enabling a crawler to warm the cache builds that set deliberately. On AHosting a cached page also consumes zero entry processes, so the caching layer is buying real protection against the concurrency ceiling with a modest cost against the file ceiling. Purging the cache to reclaim files is therefore a short-term fix that costs you performance.

How many files does a typical WordPress installation hold in 2026?

In fact a bare installation is small: WordPress core plus a theme and a handful of plugins usually lands somewhere between 10,000 and 20,000 files before any content exists. Growth comes almost entirely from four places, and none of them is the core software. Media uploads multiply because every registered image size becomes another file on disk, mail accumulates one file per message, page and object caches write and rewrite constantly, and old backups and staging copies duplicate whole trees. An account at 240,000 files is rarely a big website; it is usually a small website plus one of those four running unbounded.

Does upgrading an AHosting plan raise the inode limit as well as storage?

Accordingly it does, and both move on the same step rather than one at a time. Bronze to Silver takes the file ceiling from 250,000 to 400,000 while storage goes from 10 GB to 20 GB, and Gold carries 600,000 against 50 GB. Entry processes, memory, CPU and disk throughput rise on those same steps, so a tier change lifts every account-wide ceiling together. Check which one you are actually near before you decide, because an account that is at 96 percent of its file count and 30 percent of its storage is buying the file ceiling and nothing else.

September 10, 2026

Your Site Is Slow, CPU and Memory Are Fine: How to Tell If You’re Being Disk-I/O Throttled

Why a Disk I/O Limit Never Shows You an Error
How to Confirm Disk I/O Throttling in cPanel in Five Minutes
The AHosting Disk I/O and IOPS Ladder
- What 10 MB/s Actually Serves
- Why the IOPS Ceiling Usually Binds First
The Five Things That Generate WordPress Disk I/O
Reduce Disk I/O Before You Upgrade, in Order of Payoff
When the Honest Answer Is a Bigger Disk I/O Ceiling
Estimate Your Disk I/O Headroom
A Practical Checklist for Diagnosing Disk I/O Throttling
Frequently Asked Questions About Disk I/O Limits on Shared Hosting

TL;DR

A disk I/O limit never returns an error. CloudLinux puts your processes to sleep, so the page still loads and simply takes longer, which is why CPU and memory look innocent. Open cPanel, go to Logs and then Resource Usage, and read the Faults column for the minutes the site was slow. Faults on the disk rows and none on the entry process row means you are throttled, not out of workers.

A slow site with a clean resource graph is the most frustrating problem on shared hosting, because every diagnostic you can find assumes something is broken and nothing is. The CPU chart is flat. Memory is well under the cap. There is no 508 error to paste into a search box. The site is simply slow while traffic is heavy and fast again twenty minutes later. That pattern has one specific cause that almost nothing in the hosting literature covers: you are being throttled on disk I/O. This post shows how to confirm it from your own cPanel in about five minutes, what inside a WordPress site actually generates the reads and writes, and how to tell a problem you can tune away from a ceiling you have genuinely outgrown.

Listen: 9 minutes on the one shared-hosting limit that slows your site without ever failing a request. By Matt Chrust, Director of Business Development, AHosting.

Why a Disk I/O Limit Never Shows You an Error

A disk I/O limit does not fail your request — it delays it. That single difference is why this problem survives every checklist. Most account limits on cPanel shared hosting are enforced by refusal: ask for more than you are allowed and the server declines, which gives you a status code, a log line and something to look up. The disk limits are enforced by delay instead, and a delay leaves no trace anywhere except one column most people never open.

The Two Limits That Throttle and the Four That Fault

CloudLinux, which enforces per-account resource limits on the great majority of cPanel shared hosting, applies six ceilings to your account. Its published limits documentation names them: SPEED for processor allocation, PMEM and VMEM for memory, NPROC for total processes, EP for concurrent entry processes, and then IO and IOPS for the disk. The first four announce themselves. Exhaust your entry processes and you get a 508; exhaust physical memory and PHP dies with a fatal error. Our diagnostic tree for 503 and 500 resource errors walks those four in detail, and every one of them ends in a visible failure. The last two do not.

What “Put to Sleep” Means for a Page Load

CloudLinux is unusually direct about the mechanism. Its documentation states that when the limit is reached, the processes are throttled — put to sleep — so that they cannot exceed the limit and yet “don’t stop working, nor getting killed – they just work slower when the limit is reached.” A sleeping PHP process is not a failed request. It is a request that will finish, eventually, having produced no error for anyone to find. There is a sting in this, though, and it is the reason the two halves of the diagram below are connected: a request asleep on the disk is still holding its entry process. Throttle hard enough for long enough and the concurrency ceiling fills with sleeping requests, and you finally get a 508 whose actual cause was the disk all along.

Disk I/O Throughput and IOPS Are Two Separate Ceilings

These are not two names for one thing, and confusing them sends you after the wrong fix. Throughput is a volume: KB/sec, how much data may move between your account and the disk. IOPS is a count: how many distinct read and write operations you may perform each second, irrespective of how small each one is. cPanel’s own guidance on high disk I/O puts the underlying idea plainly — disk I/O “describes how long the read and write operations require on a hard disk.” A backup archive is a throughput workload: few operations, enormous volume. WordPress is the opposite, and that asymmetry decides which of your two ceilings you hit first.

How to Confirm Disk I/O Throttling in cPanel in Five Minutes

Open cPanel, go to Logs, then Resource Usage. Everything this section asks for is on that one screen, and it is available on every plan — you do not need shell access, a monitoring plugin or a support ticket to answer the question.

Read the Faults Column, Not the Usage Graph

The usage chart is the wrong number to read, and it is the number everyone reads. Usage tells you how close you came; a fault tells you that the ceiling was reached and enforced. An account can sit at ninety percent of its limit all day without a single fault and be perfectly healthy. One fault means processes were slept. The CloudLinux end-user documentation confirms what the screen exposes: charts for CPU, memory, Input/Output, IO operations, entry processes and processes, plus a Current Usage table carrying a row for I/O and a separate row for IO operations, each showing usage, limit and a fault count. Filter to the hour or the minute of the slowdown. A 24-hour average will hide a ten-minute stall completely, which is exactly how this problem stays invisible for months.

The Snapshot Tab Shows Which Process Was Asleep

Faults tell you that you were throttled; the Snapshot tab tells you what you were doing at the time. When an account hits a limit, the statistics daemon captures a server snapshot containing the process list and, on cPanel, the database and HTTP queries that were running at that moment. Choose the date and the snapshot matching a fault and you will usually be looking directly at the cause — a nightly archive, a scanner walking the filesystem, an unindexed query, or a burst of checkout traffic. This is the step that turns a capacity reading into a specific thing you can change.

The Reading That Rules Disk I/O Out

Zero faults on both disk rows across the whole slow window is a real result and worth as much as a positive one. It means the ceiling was never reached, the slowness lives in the application or the network rather than in your allocation, and no plan upgrade will touch it. Our knowledge base covers the next fork in that road in how to tell whether a slow site is the server or the site. Rule the disk in or out first, though, because it is the one limit that produces no evidence anywhere else.

The AHosting Disk I/O and IOPS Ladder

Most hosts do not publish these numbers at all, which is why sizing against them is so rarely possible. AHosting does. The table below is the same allocation shown on the shared web hosting plans, and it is the AHosting Disk I/O and IOPS Ladder referenced throughout this post.

Plan	Disk I/O	IOPS	Entry processes	Memory	CPU
Bronze	10 MB/s	1,024	30	2 GB	2-core limit
Silver	20 MB/s	2,048	40	3 GB	3-core limit
Gold	30 MB/s	3,072	50	4 GB	4-core limit

AHosting Disk I/O and IOPS Ladder — published shared and WordPress plan allocations, verified against the live plan pages on September 9, 2026.

What 10 MB/s Actually Serves

Throughput is a rate rather than a monthly quota, which changes how you reason about it. Ten megabytes per second is roughly ten thousand kilobytes every second, sustained, forever — so an ordinary cached HTML page of sixty kilobytes leaves room for well over a hundred such responses per second before volume becomes the constraint. Almost no shared site reaches that. The number that matters is what happens when something large runs alongside your visitors: a full-account backup, a large upload, a video file being read end to end. Those compete for the same rate, and they are the reason a site can be slow at 2am for reasons that have nothing to do with traffic.

Why the IOPS Ceiling Usually Binds First

Operations run out long before megabytes do on a database-driven site. An uncached WordPress request reads a large number of small things: PHP files for core, the theme and every active plugin, then the rows behind the page. Each is an operation and almost none of them is large. At Bronze you are allowed 1,024 of those per second across the whole account, which sounds generous until you multiply it by concurrent uncached requests. Our analysis of the server-side factors no plugin can fix covers the storage tier underneath this; the ceiling here is separate from the hardware and applies no matter how fast the underlying disk is. A fast NVMe array you are throttled against is still a throttle.

The Five Things That Generate WordPress Disk I/O

Before changing a plan, find out what is spending the allocation. In practice almost all of it comes from five places, and they are listed here in roughly the order they turn up in real Snapshot output.

Uncached HTML, and What LiteSpeed Cache Changes

Serving a page from cache replaces a few hundred operations with one. An uncached request executes PHP, reads the file tree and runs the queries behind the page; a cached request reads one prepared file and returns it. On AHosting a cached page also consumes zero entry processes, so caching relieves both ceilings at once, which is why it is the first fix rather than a later one. The limit of that relief matters too: pages that cannot be cached never get it. Anything personal to the visitor — cart, checkout, account, any logged-in view — runs in full every time, which is exactly why checkout must be excluded from the cache deliberately, and why stores feel this ceiling far more sharply than brochure sites do.

The Database: Revisions, Transients and Autoloaded Options

Database writes are disk writes, and more of them than people expect. Every committed change is also written to a transaction log before it lands in the table, as MariaDB’s documentation of the InnoDB redo log describes. Three things dominate on a typical site. Post revisions accumulate without limit unless you cap them, which you can do with a single constant documented in the wp-config reference — we measured the effect of that in our post on limiting WordPress post revisions. Expired transients pile up when nothing clears them. And autoloaded options are read on every single request, so a bloated options table taxes every page you serve rather than one.

Backups, Cron and Scanners Running Inside Your Own Limit

This is the category that surprises people, because these jobs feel like infrastructure rather than site traffic. They are not. A backup plugin archiving your whole account, a security scanner walking every file, an SEO plugin rebuilding a sitemap and WordPress’s own scheduler all run as your account, inside your allocation, competing with your visitors for the same operations per second. Worse, the default scheduler fires on visitor requests, so the heaviest jobs can land at your busiest moment. Our measured write-up on disabling WP-Cron and replacing it with a real cron job covers moving that work to a quiet hour, which is often the single cheapest change available here.

Logs, Sessions and the Files Nobody Watches

Small, constant writes are easy to overlook because no single one is expensive. PHP session files are written per visitor per request. Debug logging left enabled after a support session appends on every notice. Object-cache and page-cache files are written as well as read. Individually these are trivial; together, on a busy account, they form a steady baseline of operations that eats the headroom you were relying on for traffic peaks. Check for a `debug.log` that nobody turned off — it is the most common single find.

Media Uploads and On-the-Fly Image Resizing

Uploads are the one genuinely throughput-shaped workload most sites have. A large image or video moves real volume, and WordPress then generates every registered thumbnail size from it, each one a read and a write. A theme registering a dozen sizes turns one upload into dozens of operations. Bulk regeneration after a theme change is the extreme version and can saturate the ceiling for as long as it runs. None of this is a problem at rest; all of it is a problem if it happens while customers are on the site.

Reduce Disk I/O Before You Upgrade, in Order of Payoff

Work down this list and stop when the faults stop. The order is deliberate: each step costs less than the one below it and, in our experience of these tickets, clears more.

Order	Change	What it removes	Effort
1	Turn on full-page caching and verify it is actually serving	Several hundred operations per cached hit	Minutes
2	Move WP-Cron to a real cron job at a quiet hour	Scheduled work landing during peak traffic	Minutes
3	Cap post revisions and clear expired transients	Unbounded table growth and repeated writes	Minutes
4	Reschedule backups and security scans off-peak	A second heavy workload competing with visitors	Minutes
5	Disable debug logging and audit autoloaded options	A constant write baseline on every request	An hour
6	Reduce registered image sizes and stop on-the-fly resizing	Dozens of write operations per upload	An hour
7	Add missing database indexes for slow queries	Repeated full scans reading rows you do not need	Developer time

Disk I/O reduction in order of payoff — cheapest and highest-yield changes first.

When the Honest Answer Is a Bigger Disk I/O Ceiling

Sometimes the writes are the business. If you have worked down that list and the Snapshot tab still shows real orders, real logged-in sessions and real uploads at the moment of each fault, then nothing is misconfigured and you have simply outgrown the allocation. The test we use is whether you can name what is generating the operations: if you can and it is customers, the ceiling is the problem; if you cannot, it is not.

That is the point at which a tier change is the fix rather than an upsell, and it is worth knowing that the ladder moves both ceilings together — throughput, operations, entry processes, memory and CPU all step up on the same tier. For a content or membership site the next step up on managed WordPress hosting is usually enough; a store whose checkout is the bottleneck is better served by WooCommerce-tuned hosting where the uncacheable paths are the design assumption. If the Snapshot shows sustained saturation rather than peaks, the shared model itself is the constraint and VPS hosting gives you the whole allocation instead of a slice of one; genuinely I/O-bound applications belong on a dedicated server. We walk the shared-to-VPS decision in more depth in our comparison of shared and VPS hosting for growing websites. Tune first; move when the tuning runs out.

Estimate Your Disk I/O Headroom

This is arithmetic rather than measurement, and it is here to tell you whether the question is worth pursuing at all. Put in your peak uncached request rate and it will tell you roughly where you sit against the operations ceiling on each tier.

Disk I/O Headroom Estimator

A rough order-of-magnitude check, not a measurement. It assumes an uncached request performs about 300 small read and write operations, which is typical for WordPress with a normal plugin load. Your real figure is in the Faults column.

Your plan

Uncached requests per second at peak

Operations per uncached request

—

Cached requests are excluded on purpose: a page served from the LiteSpeed cache is one read, not three hundred. If this estimate says you are close, confirm it against the Faults column before changing anything.

A Practical Checklist for Diagnosing Disk I/O Throttling

The slowness is load-dependent and there is no 508, no 503 and no fatal error in the log.
cPanel, Logs, Resource Usage has been filtered to the minutes of the slowdown rather than read as a daily average.
The Faults column has been read on the I/O row and the IO operations row, not the usage percentage.
Entry process faults were checked in the same window, so you know which ceiling moved first.
At least one fault has been opened in the Snapshot tab and the process or query behind it can be named.
Full-page caching is on and verified as actually serving, not merely installed.
Scheduled work — cron, backups, scanners — runs outside your peak traffic hours.
Post revisions are capped, expired transients are cleared and no debug log is being written.
Your plan’s published throughput and operations ceilings are known, along with how far the next tier moves them.
If faults persist after all of the above, the customer-facing work generating them can be named.

Frequently Asked Questions About Disk I/O Limits on Shared Hosting

Why is my website slow when CPU and memory look fine in 2026?

Typically because the ceiling you are hitting does not produce an error at all. CloudLinux enforces six per-account limits, and two of them — throughput and operations per second against the disk — are enforced by slowing your processes down rather than by refusing the request. Your CPU graph stays low precisely because your processes are asleep waiting on the disk instead of running. Open cPanel, go to Logs and then Resource Usage, and read the Faults column for the window when the site was slow; that is the only reading that separates this from an application problem.

What does a disk I/O fault in cPanel actually mean?

Specifically, it means your account asked the disk for more than your plan allows during that measurement period, and the server made your processes wait. A fault is a recorded violation rather than a warning: the usage chart can sit close to the ceiling all day without a single fault, and one fault is proof that the ceiling was reached and enforced. Faults are counted separately for throughput and for operations per second, so the two rows tell you different things. A handful of faults during a backup window is normal; faults every hour during business hours are a capacity finding.

Disk I/O vs IOPS: which limit slows a WordPress site first?

In practice IOPS usually binds first on a WordPress site, because WordPress issues a very large number of very small reads rather than a few large ones. Throughput measures megabytes per second and is exhausted by big sequential transfers such as a backup archive or a video file. IOPS measures how many separate read and write operations you may perform each second, and a single uncached WordPress request performs hundreds of them across PHP files, the object cache and the database. A site can therefore be nowhere near its megabytes-per-second ceiling and still be throttled all afternoon.

Disk I/O limit vs entry process limit: how do the symptoms differ?

By contrast with a disk I/O limit, an entry process limit fails loudly. When you run out of entry processes the server refuses the request and returns a 508 or a 503, so you get an error page, a log line and something to search for. When you run out of disk throughput or operations you get no error at all — the same page loads, just slowly. The two are connected, though: a request held asleep on the disk keeps occupying its entry process, so sustained throttling can eventually exhaust the concurrency ceiling and produce a 508 whose real cause is the disk.

What is the disk I/O limit on AHosting shared hosting plans in 2026?

Notably, AHosting publishes the figure rather than describing it in adjectives. The Bronze plan allows 10 MB/s and 1,024 IOPS, Silver allows 20 MB/s and 2,048 IOPS, and Gold allows 30 MB/s and 3,072 IOPS, alongside 30, 40 and 50 entry processes respectively. Those numbers are on the plan pages because you cannot size a plan against a ceiling you are not told. Check them against the Faults column in your own Resource Usage screen before you decide whether the answer is a tuning job or a tier.

My WooCommerce store slows down at checkout: is that a disk I/O problem?

Indeed, and the checkout page is the most likely place on a store for it to show. Cart and checkout are deliberately excluded from page caching because they are personal to the shopper, so every one of those requests runs PHP, reads the database and writes session and order data. Under concurrent load that is a burst of small write operations against the same ceiling. Check the Faults column for the exact minutes of the slowdown; if the operations row shows faults and the entry process row does not, the disk is the constraint rather than the worker count.

Should I upgrade my plan or reduce writes if faults appear every day?

Ultimately that depends on whether the writes are useful. Reduce first when the load is waste — unbounded post revisions, expired transients that never clear, a backup plugin archiving the whole account every night inside your own limit, a security scanner walking every file at midday. Upgrade when the writes are the business: real orders, real logged-in sessions, real uploads. The honest test is whether you can name what is generating the operations. If you can and it is customers, the ceiling is the problem; if you cannot, the ceiling is not.

How does LiteSpeed Cache on AHosting change how much disk I/O WordPress uses?

Fortunately, a cached page skips almost all of the work that generates operations. Serving an uncached page means executing PHP, reading the plugin and theme files, and running the queries behind the page; serving the same page from the LiteSpeed cache means reading one prepared file. On AHosting a cached page also consumes zero entry processes, so caching relieves both ceilings at once. That is why caching is the first fix rather than a later one, and why a site whose traffic is mostly logged-in or mostly checkout gets much less relief from it.

How do I check disk I/O usage in cPanel Resource Usage in 2026?

First and foremost, open cPanel, go to Logs and then Resource Usage. The Current Usage table lists a row for input and output and a separate row for IO operations, each showing your usage, your limit and a fault count. Filter the charts to the day, hour or minute of the slowdown rather than reading a 24-hour average, because an average hides a ten-minute stall completely. If any faults are recorded, open the Snapshot tab for that moment: it captures the process list and the database and HTTP queries that were running when the limit was hit.

Does an AHosting plan upgrade raise the IOPS ceiling as well as disk I/O?

Indeed it does, and the two rise together on every tier. Moving from Bronze to Silver takes throughput from 10 MB/s to 20 MB/s and operations from 1,024 to 2,048 per second; moving to Gold takes them to 30 MB/s and 3,072. Entry processes, memory and CPU rise on the same steps, so a tier change lifts the concurrency ceiling and the disk ceiling together rather than trading one against the other. If the operations row is the one showing faults, that is the number to check on the tier you are considering.

September 9, 2026

Your Server Is Running PHP Version X but WordPress Requires Y” – What to Actually Do

What the WordPress PHP Version Error Actually Is (And Why Your Whole Site Is Down)
- The exact line of WordPress that kills the request
- Why "check Site Health" is advice for a different problem
Which WordPress PHP Version Error Are You Looking At?
The Number in the WordPress PHP Version Error Is Not the Number You Want
- What WordPress requires versus what WordPress recommends
- Where each PHP branch stands right now
How to Fix the WordPress PHP Version Error in cPanel
- Change the version in MultiPHP Manager
- When the version changes and nothing happens – the AddHandler trap
What Breaks After You Raise PHP (And What Doesn't)
- The extension fatal almost nobody hits
- The memory limit that moved when you weren't looking
When You Cannot Change PHP – and What That Says About Your Host
A Practical Checklist: Before, During, and After the PHP Switch
Frequently Asked Questions About the WordPress PHP Version Error

TL;DR

The WordPress PHP version error is a pre-boot fatal, not an admin notice. Raise PHP in cPanel to clear it, but do not stop at the number in the message: WordPress enforces 7.4 and recommends 8.3 or greater.

The WordPress PHP version error is the one that gets pasted into Google verbatim, semicolons and all, because there is nothing else left to do with it. One line of text, no dashboard, no menu, no theme. If you searched the exact string and landed here, your site is returning an HTTP 500 and the fix takes about ninety seconds once you know which of four similar messages you are actually looking at.

Why the version in the message is the floor and not the target.

That last part is where most advice goes wrong. A WordPress PHP version error is not one message but four, and they mean different things, fire in different places, and need different responses. Worse, the version number printed in the message is not the version you should move to. This guide covers all of it, in the order an outage actually forces you to work.

What the WordPress PHP Version Error Actually Is (And Why Your Whole Site Is Down)

The WordPress PHP version error means the PHP interpreter on your server is older than the floor WordPress will start on, so WordPress refuses to boot at all. It is not a warning, not a notice, and not something you can dismiss. Every request to every URL on the site gets the same sentence and nothing else.

The exact line of WordPress that kills the request

A WordPress PHP version error comes from a function called wp_check_php_mysql_versions(), which lives in wp-includes/load.php and runs before almost anything else. It compares PHP_VERSION against a value WordPress sets in wp-includes/version.php. If PHP is older, WordPress sends a 500 Internal Server Error header, prints the sentence, and calls exit. Nothing after that point in the boot sequence ever runs, which is why the page has no styling, no header, and no way back in.

That detail matters more than it sounds. Because the failure happens before plugins, themes, and the admin area are loaded, none of the usual recovery routes exist. You cannot deactivate a plugin, you cannot switch themes, and you cannot reach wp-admin. The only surfaces still available are your hosting control panel, SFTP, and the file system.

Why “check Site Health” is advice for a different problem

Search results for this error are full of instructions that begin inside the WordPress dashboard. Open Tools, then Site Health, then read the PHP recommendation. That advice is written for the version notice WordPress shows when the site is working, not for the fatal that fires when it is not. If you can reach Site Health, you are not seeing the pre-boot error, and you have more time than this guide assumes.

Holding that distinction is worth the effort, because it is also the difference between an urgent fix and a scheduled one. A live site that is down is an emergency you resolve in the panel. A dashboard notice is a maintenance task you can plan around a backup and a staging test. Our white screen of death recovery guide covers the adjacent case where WordPress boots and then fails silently.

Which WordPress PHP Version Error Are You Looking At?

Four distinct strings in WordPress mention PHP versions, and they are routinely treated as one problem. They are not. The table below is the WordPress PHP Error Map: it names each message, the file it is emitted from, when it fires, and whether your site is currently serving traffic. Read your message against it before you change anything.

The WordPress PHP Error Map – four messages, four meanings. Verified against WordPress 7.1 source.

The message you are seeing	Emitted from	When it fires	Is the site up?
Your server is running PHP version X but WordPress Y requires at least Z.	wp-includes/load.php	Every request, before WordPress boots	No – HTTP 500 on every URL
WordPress X requires the json PHP extension.	wp-includes/load.php	Every request, before WordPress boots	No – HTTP 500 on every URL
You cannot update because WordPress X requires PHP version Y or higher and MySQL version Z or higher.	wp-admin/update-core.php, upgrade.php, install.php	Inside wp-admin, when you try to update or install	Yes – only the update is blocked
The update cannot be installed because WordPress X requires PHP version Y or higher and MySQL version Z or higher.	wp-admin/includes/update-core.php	During an update that has already started	Yes – the update aborts, the old version keeps running

If your message is one of the bottom two, close this section and breathe. Your site is serving visitors normally and you are looking at a blocked upgrade, which is a different job with a different urgency. Those bottom two rows also name MySQL alongside PHP, and the database half is the one people miss: WordPress checks both in the same place, so a message that mentions PHP may be failing on the other requirement.

The Number in the WordPress PHP Version Error Is Not the Number You Want

Here is the part almost nobody says out loud. The version a WordPress PHP version error prints is the absolute floor it will start on, and that floor is a version that stopped receiving security fixes years ago. Clearing the error by moving to exactly that number ends your outage and leaves you running unsupported PHP, which is a different problem you have now agreed to have.

What WordPress requires versus what WordPress recommends

WordPress 7.1 sets its minimum to PHP 7.4. That is the number in the error. On its server requirements page, WordPress recommends PHP 8.3 or greater, alongside MariaDB 10.11 or MySQL 8.0, and states plainly that while WordPress will still run on the older baseline, those versions have reached end of life and may expose your site to security vulnerabilities. Two numbers, two purposes: one keeps the software from starting, the other keeps it defensible.

So the target of a WordPress PHP version error fix is not the number in the message. Aim for the recommendation and land above both. If you want the reasoning behind picking a specific modern branch rather than the newest available, our guide to choosing a PHP version in cPanel works through the tradeoff in detail.

Where each PHP branch stands right now

PHP publishes a fixed support calendar: two years of active support, then a third year of security-only fixes, then nothing. The table below is that calendar as it stands today, taken from the PHP project support schedule. Anything not listed on that page, including PHP 8.1 and everything below it, receives no fixes from the project at all.

PHP branch support status, September 2026. Source: the PHP project support schedule.

PHP branch	Active support until	Security support until	What that means for a WordPress site today
8.1 and older	Ended	Ended	No project fixes at all. Move off it.
8.2	2024-12-31	2026-12-31	Security fixes only, and they stop this December.
8.3	2025-12-31	2027-12-31	Security fixes only. Clears the WordPress recommendation.
8.4	2026-12-31	2028-12-31	Actively supported. The sensible default today.
8.5	2027-12-31	2029-12-31	Newest branch. Fine once plugins confirm support.

A quick way to keep this straight later is the PHP end-of-life calendar, which renders the same dates as a timeline. Note the shape of the trap: 8.2 is still described as supported in a lot of writing, and its security window closes in December. Choosing a branch that is merely alive today buys you very little.

How to Fix the WordPress PHP Version Error in cPanel

With the target version settled, clearing a WordPress PHP version error is short work. On any cPanel host, including every AHosting shared plan, the PHP version is set per domain rather than per account, so you can move one site without touching the others. Take a backup first if the account has one available, then work through the two steps below in order.

Change the version in MultiPHP Manager

Log in to cPanel and open MultiPHP Manager under the Software section. You will see a list of every domain and subdomain on the account with its current PHP version beside it. Select the checkbox for the affected domain, choose 8.4 from the PHP Version dropdown, and apply. The change takes effect on the next request, so reload the site immediately and check whether the message is gone.

One setting to avoid here is inherit, which tells the domain to follow the server default. Inherit is convenient until the server default moves underneath you, and it also prevents you from enabling PHP-FPM on that domain. Choose an explicit version so the domain keeps the version you picked regardless of what changes at the server level later.

When the version changes and nothing happens – the AddHandler trap

If MultiPHP Manager reports the new version and the site still returns the same WordPress PHP version error, the panel is not being obeyed. The usual cause is an AddHandler line in the .htaccess file at your document root that names a specific old PHP handler. Directory-level Apache configuration takes precedence over the panel setting, so the panel is telling you one thing while the web server does another.

Open .htaccess over SFTP or the cPanel File Manager and look for a line naming a handler such as ea-php74 or ea-php56. Comment it out with a hash at the start of the line, save, and reload. This is worth checking before anything else, because it explains the majority of cases where a correct version change appears to do nothing at all, and it is invisible from inside WordPress.

What Breaks After You Raise PHP (And What Doesn’t)

Your site is back. Now comes the part the outage hid from view, because raising a PHP version changes the runtime underneath every plugin and theme on the site. Two things are commonly feared here, one of which is almost never the problem, and one genuine change that is easy to miss because nothing announces it.

The extension fatal almost nobody hits

WordPress core requires exactly two PHP extensions to boot: json and hash. Both have been compiled into PHP by default for years, so the missing extension fatal listed in the error map above is rare in practice. If somebody tells you that switching handlers will strip the extensions WordPress needs, they are describing plugin requirements rather than core ones.

The real post-switch failures come from plugin and theme code that has not kept up with the language. Jumping from PHP 8.1 to 8.2 or later, for example, triggers the deprecation described in the PHP RFC on dynamic properties, which raises a warning for every undeclared property an older plugin sets. It still works, but it fills logs, and the same code becomes a hard error in PHP 9. The rest of the 8.2 changes are documented in the PHP 8.2 deprecation notes.

The memory limit that moved when you weren’t looking

This is the change nothing tells you about. On a cPanel host, PHP memory_limit is a property of the handler, not of the site, so selecting a different PHP version can hand you a different per-request memory ceiling. On AHosting shared plans the three handlers we run are not configured identically, and the spread is wide enough to turn a working site into an intermittently failing one.

The AHosting PHP Handler Memory Map – per-request memory_limit by handler on AHosting shared plans.

Handler	PHP memory_limit	Community support status	What changes if you move here
ea-php84	256 MB	Active support until 2026-12-31	Current default. Halves the ceiling coming from ea-php83.
ea-php83	512 MB	Security fixes until 2027-12-31	The highest ceiling of the three handlers.
ea-php81	128 MB	End of life since 2025-12-31	The lowest ceiling, on an unsupported branch.

Read that table in the direction you are actually moving. A site moving from ea-php83 to ea-php84 gains a supported branch and loses half its memory ceiling in the same click, which surfaces later as an exhausted memory error on a heavy admin page rather than as anything connected to the version change. Check phpinfo once the switch is done, and see our guide to WordPress memory limit errors for why raising the value in wp-config often achieves nothing.

One more distinction worth keeping. The PHP memory_limit is not the same thing as the container memory cap your plan enforces, and raising the first above the second buys you nothing at all. If your errors after a handler change look like resource exhaustion rather than a version problem, our diagnostic tree for 500, 503, and resource limit errors separates the three.

Check Your PHP Version Against WordPress

Pick the PHP version your server reports. This tells you whether WordPress will boot, whether the branch is still patched, and what to do next.

Your current PHP version

Select a version to see where you stand.

See which PHP versions our hosting plans run

When You Cannot Change PHP – and What That Says About Your Host

Sometimes MultiPHP Manager is not there, or the versions offered stop below what WordPress recommends, or the setting is locked to the server default. That is a real constraint and worth naming honestly, because at that point the version problem has stopped being a WordPress problem and become a hosting one.

There are two legitimate ways out. If the blocker is application code rather than the panel, commercial long-term support for end-of-life PHP branches exists and covers 7.2 through 8.1, which buys time to rewrite rather than permission to stop. If the blocker is the platform, the answer is a platform where the choice is yours to make.

For context on what that looks like: our shared platform runs CloudLinux 9 and LiteSpeed with ea-php80 through ea-php85 selectable per domain from MultiPHP Manager, and older branches available for legacy applications that genuinely need them. If deciding between handlers is not work you want to own at all, that is exactly the decision our managed WordPress hosting plans make for you, and the root account is yours to hold on a VPS if you would rather own the handler yourself. The tuning above is the part we take off your hands.

Whichever route you take, moving hosts to escape a PHP ceiling is a planned job rather than an emergency one. Our WordPress hosting requirements guide lists what to check before you commit, and a WordPress PHP version error is a poor reason to rush that decision.

A Practical Checklist: Before, During, and After the PHP Switch

Work through this in order. Sequence matters here because two of the steps are things people only discover they skipped once the site is already back up and quietly misbehaving.

Read the exact message against the error map above and confirm whether your site is actually down or merely blocked from updating.
Take a backup, or confirm one exists from within the last day, before touching the handler.
Set the target version to 8.4 in MultiPHP Manager, per domain, and avoid the inherit setting.
Reload the site immediately. If the message survives, open .htaccess and remove any AddHandler line naming an old handler.
Check phpinfo and confirm both the running version and the memory_limit, which may have changed with the handler.
Load a few heavy pages, including the admin dashboard and one editor screen, rather than only the homepage.
Check the error log for new deprecation warnings from plugins and themes, and update anything that is producing them.
If a plugin fatals on the new branch, roll the handler back to the previous version, then fix the plugin rather than living on the old runtime.

The last item is the one worth arguing about. Rolling back is a legitimate move under time pressure, but it is a pause and not a resolution, because the branch you rolled back to is the one that stops receiving fixes. Set a date to come back to it while the details are still fresh.

Frequently Asked Questions About the WordPress PHP Version Error

How do I fix the WordPress PHP version error on shared hosting in 2026?

Specifically, open cPanel, go to MultiPHP Manager, select the affected domain, and set the PHP version to 8.3 or 8.4. The site returns as soon as the handler changes. If the message survives the change, an AddHandler line in .htaccess is overriding the panel, and that line has to be removed before anything else will work.

WordPress PHP version error vs the white screen of death: what is the difference?

In contrast to a white screen, the WordPress PHP version error prints an actual sentence. That difference tells you where the failure happened. The version error is thrown by wp-includes/load.php before WordPress boots, so nothing else has run yet. A white screen means WordPress booted and then something later, usually a plugin or theme, fataled with display_errors off.

PHP 8.3 vs PHP 8.4 for WordPress in 2026: which version should I choose?

Typically, choose 8.4. Both clear WordPress recommended baseline of 8.3, but 8.3 left active support on 2025-12-31 and now receives security fixes only, while 8.4 stays in active support until 2026-12-31 and is patched for security until 2028-12-31. Pick 8.3 only when a plugin you cannot replace is not yet 8.4 compatible.

Does the WordPress PHP version error affect AHosting customers running ea-php81 on shared plans?

Notably, no. PHP 8.1 is far above the 7.4 floor WordPress enforces, so the error never fires on ea-php81. The reason to leave that handler is different: PHP 8.1 fell out of community security support on 2025-12-31, and on AHosting shared plans ea-php81 also carries a 128 MB memory_limit, the lowest of the three handlers we run.

Why does WordPress still show the old PHP version after I changed it in cPanel?

In practice, an AddHandler directive in your .htaccess is pinning the old handler for that directory, and directory-level configuration wins over the panel setting. Open the .htaccess in the document root, comment out or delete the AddHandler line naming the old version, and reload. This is the single most common reason a correct MultiPHP Manager change appears to do nothing.

Which PHP extensions does WordPress 7.1 actually require in order to boot?

Specifically, two: json and hash. Both are compiled into PHP by default on every modern build, which is why the missing extension fatal is rare in practice. Everything else people describe as required, including mysqli, curl, gd, and mbstring, is required by plugins, themes, or particular features rather than by the core boot sequence.

What is the recommended PHP version for WordPress, and is it the same as the minimum?

In fact they are different numbers, and confusing them is the whole trap. WordPress enforces a minimum of PHP 7.4, which is the number printed in the error. WordPress separately recommends PHP 8.3 or greater on its requirements page. Satisfying the minimum clears the outage; only the recommendation leaves you on PHP that is still receiving fixes.

Can I clear the WordPress PHP version error without losing my AHosting memory limit?

Ultimately yes, but check the number afterward rather than assuming it carried over. On AHosting shared plans the per-request memory_limit travels with the handler: ea-php84 ships 256 MB, ea-php83 ships 512 MB, and ea-php81 ships 128 MB. Moving between handlers changes that ceiling silently, so read phpinfo once the switch is done.

How does AHosting help resolve a WordPress PHP version error in 2026 without downtime?

Fortunately, the handler change itself is instantaneous, so the fix is measured in seconds rather than a migration window. Our shared platform runs CloudLinux 9 and LiteSpeed with ea-php80 through ea-php85 selectable per domain, and support will read the .htaccess for a conflicting AddHandler line before you do. The checklist above is the same order we work in.

What does the WordPress PHP version error mean when MySQL is named in the message?

Accordingly, you are looking at the update-time message, not the pre-boot fatal, and your site is still running. The wp-admin variants name both requirements together because WordPress checks PHP and the database in one place before allowing an update. Your site is up; what is blocked is the version jump, and the database half may be the real reason.

September 1, 2026

How to Limit WordPress Post Revisions (2026)

Before You Limit WordPress Post Revisions: Where WordPress Stores Them
- Revisions Live in wp_posts, Not a Separate Table
- What Triggers a Revision When You Limit WordPress Post Revisions
Why You Should Limit WordPress Post Revisions Before the Database Grows
What WordPress 7.0 Changed About Revisions, and What It Did Not
- Visual Revisions Made Revision History Genuinely Useful
- The Field Guide Documents No Change to Retention or Autosave
Three Myths That Make People Limit WordPress Post Revisions Incorrectly
How to Limit WordPress Post Revisions in wp-config.php
Why You Must Clean Up as Well as Limit WordPress Post Revisions
- The AHosting Revision Cleanup Safety Matrix
- Running the Cleanup Without Timing Out
Choosing a Number: Limit WordPress Post Revisions to Fit How You Edit
What the AHosting Stack Changes About Revision Cleanup
- The Daily Backup Is the Step Most Guides Skip
- Concurrency: What a Cleanup Costs While It Runs
A Practical Checklist: Limit WordPress Post Revisions Safely
Frequently Asked Questions About WordPress Post Revisions

TL;DR

Setting WP_POST_REVISIONS caps future growth only. To limit WordPress post revisions and actually shrink the database, you must also delete the rows already stored, because the constant removes none of them.

If your WordPress database has grown to several times the size of your actual content, stored revisions are the most likely cause. Fortunately, you can limit WordPress post revisions with a single line in wp-config.php. However, that line does something narrower than almost every published guide claims, and understanding the difference is what separates a database that shrinks from one that simply stops growing.

Listen: why setting WP_POST_REVISIONS caps growth without removing a single stored row. By Matt Chrust, Director of Business Development, AHosting.

Before You Limit WordPress Post Revisions: Where WordPress Stores Them

A revision is a complete snapshot of a post saved as its own database row. Specifically, WordPress writes a new row every time a revisioned field changes, so a post edited forty times carries forty child rows alongside the one visible version. Notably, the reason to limit WordPress post revisions is a storage question rather than a performance question at first, and it turns into a performance question only once the row count grows large enough to affect scans, exports, and restores.

Revisions Live in wp_posts, Not a Separate Table

Revisions are stored in the same posts table as your published content, distinguished only by their post type value. Consequently, every query that scans that table scans your revision history too, and every database export carries it. In practice, this is why a site with 400 published posts can produce a backup file sized for a site with 12,000. According to the WordPress revisions documentation, revisions are stored in the posts table, and core tracks changes to the title, author, content, and excerpt fields only.

Therefore the postmeta table is largely unaffected by core revision behavior, which contradicts a common claim. Additionally, plugins that hook into the revision save process can add their own meta rows, so a bloated postmeta table points at a plugin rather than at core.

What Triggers a Revision When You Limit WordPress Post Revisions

A revision is written only when one of the tracked fields actually differs from the previous revision. Specifically, core compares the normalized field values before saving and returns early when nothing has changed, a behavior added in version 4.1 and visible in the source of the revision-saving function. As a result, clicking Update ten times without editing anything produces zero new rows.

This matters because it breaks the arithmetic most guides use. In other words, revision counts track meaningful edits rather than save clicks, so estimating your revision debt from publishing activity alone will overstate it. Ultimately, the only reliable number is the one you measure.

Why You Should Limit WordPress Post Revisions Before the Database Grows

Unlimited retention is the default, and nothing in WordPress warns you about it. Specifically, when the constant is left undefined, core treats retention as infinite and keeps every revision a post has ever generated. Consequently, the cost accumulates silently for years, which is why the decision to limit WordPress post revisions is almost always made late.

The visible symptoms arrive indirectly. For example, nightly backups take longer and consume more storage, database exports during a migration time out, search queries against the posts table slow down, and restore operations that once took two minutes take twenty. Notably, none of these symptoms points at revisions, which is precisely why the cause goes undiagnosed. Our guide on moving a WordPress site to a new host covers why export size is the variable that most often breaks a migration window.

Importantly, the fix is cheap and the delay is expensive. A site that decides to limit WordPress post revisions in its first month carries almost no debt. By contrast, a five-year-old publication that has never set the constant may hold tens of thousands of rows that now require a deliberate cleanup with its own risks.

What WordPress 7.0 Changed About Revisions, and What It Did Not

WordPress 7.0 changed how you read revisions and changed nothing about how many are kept. Specifically, the release shipped Visual Revisions, an in-editor comparison view, while leaving retention, autosave behavior, and storage untouched. Therefore the reason to limit WordPress post revisions is exactly as valid after upgrading as it was before.

Visual Revisions Made Revision History Genuinely Useful

Until this release, comparing two versions meant leaving the editor for a separate screen and reading a text diff. In contrast, the WordPress 7.0 Field Guide describes a slider that switches between two versions directly in the editor, a document inspector that summarizes what changed, and color indicators sized to each change that jump to that location when clicked. As a result, revision history moved from a feature most editors ignored to one they will actually open.

Notably, this reframes the retention decision rather than settling it. In other words, keeping history now buys something real, so the reflexive advice to set retention to two or three and move on deserves more thought than it used to.

The Field Guide Documents No Change to Retention or Autosave

The 7.0 Field Guide catalogs more than 419 core tickets and documents Visual Revisions purely as an editor and dashboard change. Importantly, it lists no change to the retention constant, no change to the autosave interval, and no change to how revision rows are written. Consequently, a site that upgraded to 7.0 with unlimited retention still has unlimited retention today.

One caveat belongs here. Specifically, some managed platforms override the retention constant at the hosting layer, so a value you set in wp-config.php may not be the value in force. Therefore confirm with your host before assuming your configuration file is authoritative. On AHosting, no platform-level override is applied, so the constant behaves exactly as core documents it.

Three Myths That Make People Limit WordPress Post Revisions Incorrectly

Each of the three claims below appears in guides that currently rank for this topic, and each is contradicted by core source or by vendor documentation. Notably, each myth leads someone to limit WordPress post revisions in a way that changes nothing, and all three produce the same outcome: a site owner who thinks the problem is solved while the database stays exactly the same size.

Myth 1: The Constant Deletes Revisions You Already Have

Defining the retention constant removes nothing. Specifically, pruning happens inside the function that saves a revision, which subtracts your retention number from the current revision count and deletes the excess. That function runs when a post is updated. Consequently, a post you never edit again keeps every revision it has, permanently, no matter what the constant says.

For example, a site with 800 archived posts averaging 50 revisions each holds 40,000 rows. Setting the constant to five removes zero of them on day one. Ultimately, the number only falls as individual posts are re-saved, which on an archive means never. Therefore capping and cleaning are two separate jobs, and the constant does only the first.

Myth 2: Every Update Click Creates a New Revision Row

As covered above, core compares the revisioned fields first and skips the write when nothing changed. In practice, this means the relationship between editorial activity and row count is looser than the estimates published elsewhere suggest. Additionally, it means a workflow with frequent small saves is far less costly than the arithmetic in most guides implies.

Myth 3: OPTIMIZE TABLE Reclaims Your Space Automatically

This advice predates the storage engine WordPress actually uses. Specifically, modern WordPress installations run InnoDB, and the MySQL reference manual notes that on InnoDB the statement is implemented as a full table rebuild, with disk space returned to the operating system only when each table has its own tablespace file. By contrast, on a shared system tablespace the space is freed inside the database file and never returns to the filesystem.

The rebuild also has a cost worth planning around. According to published testing on InnoDB space reclamation, the operation copies the table row by row into a new file, blocks writes for its duration, and needs roughly twice the table size in temporary space. Therefore run it once, after the deletion, and never on a schedule.

How to Limit WordPress Post Revisions in wp-config.php

Setting the cap takes one line and one rule about placement. Specifically, to limit WordPress post revisions the constant must be defined before WordPress loads its settings file, which means it belongs above the stop editing comment near the bottom of wp-config.php. Notably, a line added below that comment is read after the constant has already been used and has no effect at all.

The Values the Retention Constant Accepts

Value	What WordPress does	Autosave behavior	Sensible for
`true` or `-1`	Stores every revision, forever. This is the default when the constant is undefined	One autosave per post, per user	Nothing on shared hosting
`false` or `0`	Stores no revisions at all	One autosave per post is still kept	Sites with an external version-control workflow
`3`	Keeps the three most recent revisions per post	Plus one autosave per user	Low-edit brochure sites
`5`	Keeps the five most recent revisions per post	Plus one autosave per user	Most blogs and business sites
`10`	Keeps the ten most recent revisions per post	Plus one autosave per user	Multi-author editorial teams

Values accepted by the WP_POST_REVISIONS constant, per the WordPress revisions documentation.

Importantly, disabling revisions entirely does not disable autosave. In other words, a value of false still leaves one autosave row per post, which is the row that recovers a browser crash.

Where the Line Goes, and How to Edit the File Safely

Edit wp-config.php through the cPanel File Manager rather than over FTP, because the built-in editor keeps a copy you can revert and never introduces line-ending corruption. Additionally, a syntax error in this file takes the whole site down, so add the line, save, and load the site in a second tab before closing the editor. Our walkthrough on editing wp-config.php constants through cPanel covers the exact click path and the recovery step if a save goes wrong.

Per-Post-Type Limits With the wp_revisions_to_keep Filter

One number rarely fits every content type on a site. Specifically, the wp_revisions_to_keep filter overrides the constant and receives the post object, so retention can vary by post type, by author, or by any condition you can express in PHP. Furthermore, a post-type-specific variant of the same filter overrides both the constant and the general filter.

For example, a store that edits product copy weekly and blog posts rarely can keep ten revisions on products and three elsewhere. Therefore the filter is the right tool whenever a single site-wide number would either over-retain the quiet content or under-retain the busy content.

Why You Must Clean Up as Well as Limit WordPress Post Revisions

Because the constant is not retroactive, existing rows need a separate deliberate pass. Notably, the four methods available once you limit WordPress post revisions differ in what they remove, not only in how fast they run, and choosing on speed alone is how sites end up with orphaned rows that no cleanup touches afterward.

The AHosting Revision Cleanup Safety Matrix

Method	Removes revision rows	Fires WordPress hooks	Removes related orphan rows	Main risk on shared hosting
Re-saving each post by hand	Only the excess above your cap	Yes	Yes	Impractical beyond a few dozen posts
WP-CLI over SSH	Yes, all targeted rows	Yes	Yes	Long run time on very large sites
Direct SQL statement	Yes, all targeted rows	No	No, leaves orphaned meta and term rows	A mistyped condition deletes published posts
Cleanup plugin in the browser	Yes, all targeted rows	Yes	Varies by plugin	Runs inside a web request and can time out mid-pass
Table rebuild after deletion	Removes nothing further	Not applicable	Not applicable	Blocks writes and needs about twice the table size free

The AHosting Revision Cleanup Safety Matrix: what each cleanup method actually removes and what it leaves behind.

Read the third row carefully. Specifically, a direct statement is the fastest option and the only one that bypasses WordPress entirely, so nothing cleans up the related rows a proper deletion would remove. Therefore it belongs to people who will follow it with a targeted orphan sweep, not to people who want one command and no follow-up.

Running the Cleanup Without Timing Out

A browser-based cleanup runs inside a normal web request, which means it competes with visitor traffic and is subject to the same execution and memory ceilings as any page load. Consequently, on a large site it frequently stops partway with no clear indication of how far it got. Our guide on why raising the memory limit often does not help on shared hosting explains which ceiling actually stops these operations.

By contrast, a command-line run over SSH is not bound to a web request at all, which is why it is the recommended path on AHosting. Additionally, batching the deletion into chunks of a few hundred rows keeps each statement short and leaves the database responsive for live traffic throughout.

Choosing a Number: Limit WordPress Post Revisions to Fit How You Edit

The right retention number is the smallest one that still covers a realistic recovery. Specifically, ask how far back you would ever reach to undo a mistake, then set the cap one step above that. In practice, most site owners answer with one or two edits, which makes three to five the correct range rather than the ten or twenty they were about to choose.

Notably, Visual Revisions changes this calculation slightly. Because comparing versions is now quick and legible, a multi-author team gains real value from a deeper history than a solo publisher does. Therefore an editorial site with several contributors is the one case where ten is defensible.

Revision Debt Estimator

Estimate how many revision rows your posts table is already carrying, and what capping retention today would actually remove.

Published posts and pages: 400 Meaningful edits per post, per year: 6 Years the site has been running: 5 Retention cap you are considering: 5

Estimated revision rows stored now

See WordPress plans with daily backups

Estimate only. Rows = posts x meaningful edits per year x years. Capping retention prunes a post only when that post is next updated.

Read the estimator output as an order of magnitude rather than an exact count. Specifically, it multiplies posts by meaningful edits by years, which is the same arithmetic a database query would confirm in seconds. Ultimately, the number that matters is the gap between what you are storing and what you would ever restore.

What the AHosting Stack Changes About Revision Cleanup

Two parts of the hosting environment change how safely a cleanup runs. Specifically, they are the backup that precedes any decision to limit WordPress post revisions and the concurrency budget the cleanup consumes while running.

The Daily Backup Is the Step Most Guides Skip

Every AHosting WordPress plan includes a daily backup, which means the prerequisite for a revision cleanup is already in place rather than something you have to arrange first. Importantly, confirm the most recent backup predates your change, because a backup captured after a destructive pass preserves the mistake rather than the content. Restores are handled through a support ticket.

Additionally, autosave and revision behavior interact with editor traffic in a way worth knowing before you tune anything else. Our measured guide on how the WordPress Heartbeat API drives editor requests covers the autosave interval specifically, which is a separate control from retention and is often confused with it.

Concurrency: What a Cleanup Costs While It Runs

AHosting allocates entry processes by plan tier, at 15 on Bronze, 25 on Silver, and 40 on Gold, and a command-line cleanup over SSH occupies one of them for its duration regardless of how many rows it touches. Consequently, running a cleanup during business hours is safe on any tier. By contrast, a browser-based cleanup plugin runs inside a web request, so a long pass competes directly with visitor traffic for the same pool.

For stores this matters more, because product descriptions are revisioned and edited constantly. Notably, AHosting WooCommerce hosting sets concurrency at the same level as the Silver tier for exactly this reason. Furthermore, agencies running many client sites from one account should read the reseller hosting isolation model before scripting a cleanup across all of them at once.

Finally, there is a threshold where retention tuning stops being the answer. Specifically, a database large enough that a routine rebuild becomes a scheduling problem has outgrown a shared container, and the honest fix is a VPS with dedicated resources or, at genuine scale, a dedicated server. That said, the overwhelming majority of bloated databases are bloated by revisions alone and need nothing more than the two jobs described here.

A Practical Checklist: Limit WordPress Post Revisions Safely

Work through this in order. Notably, the sequence matters more than any individual step, because capping before cleaning leaves rows behind and cleaning before backing up leaves no way out.

Confirm the most recent daily backup completed and predates any change you are about to make.
Measure what you actually have, so the cleanup can be verified afterward against a real starting number.
Set the retention constant in wp-config.php above the stop editing comment, then load the site to confirm no syntax error.
Decide whether one number fits every post type, and reach for the filter if it does not.
Choose a cleanup method from the Safety Matrix based on what it leaves behind, not on how fast it runs.
Run the cleanup from the command line rather than the browser, in batches, so nothing times out mid-pass.
Rebuild the table once after the deletion, and understand that space returns to the filesystem only under a per-table tablespace.
Re-measure, and confirm the backup file size fell by roughly the amount you expected.

Ultimately, the goal is not the smallest possible database. In practice, it is a retention setting you chose deliberately, a one-time cleanup that removed the debt accumulated before that decision, and a hosting plan whose backups finish inside their window because the database is the size your content actually justifies.

Frequently Asked Questions About WordPress Post Revisions

How do I limit WordPress post revisions in wp-config.php in 2026?

Specifically, add define( 'WP_POST_REVISIONS', 5 ); above the line that reads stop editing in wp-config.php, then save the file. The constant must be defined before WordPress loads its settings file, so a line placed below that comment is ignored entirely. Importantly, this caps future growth only and deletes nothing that is already stored.

Is it true that setting post revisions to a lower number reduces database bloat?

Notably, only for revisions created from that point forward. The cap is enforced inside the function that saves a revision, which runs when a post is updated, so existing rows survive untouched until each affected post is edited again. Therefore an archive of posts you never touch again keeps every revision it already has, forever. The Cleanup Safety Matrix in this post shows which methods actually remove them.

WP_POST_REVISIONS vs the wp_revisions_to_keep filter: which should I use to limit WordPress post revisions?

Specifically, use the constant for one site-wide number and the filter when different post types need different retention. The filter overrides the constant, and a post-type-specific variant overrides both. In practice, a store that wants five revisions on products and two on blog posts needs the filter, because a single constant cannot express that.

How do I remove old post revisions in WordPress without breaking published content?

Therefore work from a verified backup and delete only rows whose post type is the revision type. A revision row is a child record; removing it never alters the published post, which lives in its own row. However, deleting the parent post by mistake does destroy content, which is why a targeted command that filters on post type is safer than a hand-written query.

Does the AHosting daily backup protect me if I limit WordPress post revisions incorrectly in 2026?

Fortunately, yes. Every AHosting WordPress plan includes daily backups, so a cleanup that removes more than intended can be restored. That said, a backup taken after a destructive cleanup is not a safety net, so confirm the most recent backup predates the change before you run anything. Restore requests go through a support ticket.

Do WordPress autosaves accumulate in the database the same way post revisions do?

In fact, no. WordPress keeps a single autosave row per post per user and overwrites it rather than adding new rows, and the pruning routine explicitly skips autosave rows when it deletes old revisions. Consequently, autosaves are a fixed, tiny cost while revisions are the unbounded one. Guides that blame autosaves for database growth have the mechanism backwards.

Why are my WordPress revisions not showing up in the 7.0 editor?

Typically, the revision panel is empty because retention is switched off, because the post type does not declare revision support, or because fewer than two revisions exist to compare. Additionally, a plugin that adds a metabox to the editor can prevent the new visual comparison from loading. Check the constant first, since a value of false or zero disables storage completely.

WP-CLI vs raw SQL for revision cleanup: which is safer on shared hosting?

As such, WP-CLI is safer and raw SQL is faster. WP-CLI routes each deletion through the standard WordPress functions, so hooks fire and related rows are cleaned up properly, while a direct query does not. By contrast, a single statement finishes in seconds where a command loop can run for many minutes and hold a worker the whole time.

Should I limit WordPress post revisions on a WooCommerce store with AHosting WooCommerce hosting?

Specifically, yes, because products are a revisioned post type and product descriptions get edited far more often than blog posts. A catalog of two thousand products edited quarterly generates revision rows faster than most content sites do. Notably, orders are unaffected, since modern WooCommerce stores order data outside the posts table entirely.

How many entry processes does a bulk cleanup use when I limit WordPress post revisions on AHosting in 2026?

In practice, a command-line cleanup run over SSH consumes one entry process for its duration, not one per row deleted. Because AHosting allocates 15 entry processes on Bronze, 25 on Silver, and 40 on Gold, a single cleanup leaves ample headroom. However, a browser-based cleanup plugin is different, since it runs inside a web request that competes with real visitors.

August 21, 2026

How to Push WordPress Staging to Live Without Losing Data

What Actually Breaks When You Push WordPress Staging to Live
- The Overwrite Window: Every Row Production Gained While You Tested
- Why "Just Exclude the Orders Table" Became Wrong Advice in 2024
The AHosting Staging Push Exclusion Map
- How to Tell Whether Your Store Runs HPOS, Compatibility Mode, or Legacy Storage
Three Ways to Push WordPress Staging to Live on cPanel Shared Hosting
How to Push WordPress Staging to Live in Seven Steps
Server Resources That Decide Whether You Can Push WordPress Staging to Live
- Two Memory Ceilings, One Packet Limit, and Why They Get Confused
- What AHosting Includes Before You Push WordPress Staging to Live
Staging Push Exclusion Builder
When You Cannot Safely Push WordPress Staging to Live on Shared Hosting
The Checklist to Run Before and After You Push WordPress Staging to Live
Frequently Asked Questions About How to Push WordPress Staging to Live

TL;DR

To push WordPress staging to live without data loss, exclude the tables production wrote to since you cloned — users, comments, and every WooCommerce order table for your storage mode — then push files and settings only.

The moment you push WordPress staging to live is the single most destructive operation a site owner performs on purpose. Everything else — plugin updates, theme edits, PHP version changes — is reversible in minutes. A database overwrite is not. Furthermore, the failure is silent: the site loads perfectly, the new design is live, and nobody notices the missing orders until a customer emails asking where their receipt went.

Listen: why the standard “exclude the orders table” advice stopped working in 2024, and what replaced it. By Matt Chrust, Director of Business Development, AHosting.

Notably, almost every guide on this topic was written for managed hosts with a one-click “Push to Production” button, or by a plugin vendor whose answer is a Pro upgrade. This guide is neither. It is written for cPanel shared hosting, and it gives you the exact table list — which is the one thing the other guides never publish.

What Actually Breaks When You Push WordPress Staging to Live

Specifically, what breaks is not the code you tested — it is the data production created while you were testing. Staging is a photograph of your site taken at a moment in time. Meanwhile, production kept moving: orders arrived, users registered, comments posted, contact forms filled. Consequently, pushing the photograph back on top of a moving site erases everything that moved.

The Overwrite Window: Every Row Production Gained While You Tested

We call this the Overwrite Window: the elapsed time between cloning staging and pushing it back, multiplied by your production write rate. Therefore a store taking four orders an hour that spends three days on a redesign is risking roughly 288 orders. In practice, the number surprises people, because the instinct is to judge risk by site size rather than by staging duration.

Additionally, the window applies to more than commerce. Membership registrations, WooCommerce sessions holding active carts, Action Scheduler jobs queued for delivery, comment threads, and form submissions all accumulate on production and all sit in database tables. Ultimately, the fix is arithmetic rather than luck: measure the window before you push WordPress staging to live, then exclude the tables that filled during it.

Why “Just Exclude the Orders Table” Became Wrong Advice in 2024

Here is the part almost every published guide gets wrong. WooCommerce moved order storage. Since version 8.2, released in October 2023, High-Performance Order Storage is enabled by default on new installations, and orders live in dedicated tables rather than in wp_posts and wp_postmeta. The HPOS upgrade recipe book documents the schema in full.

Consequently, three generations of advice are now circulating simultaneously, and two of them are wrong for any given store. Pre-2024 guides say to exclude wp_posts — which protects nothing on an HPOS store. Newer guides say to exclude wp_wc_orders — which protects nothing on a legacy store. Notably, one widely-ranked tutorial names a table called wp_woocommerce_orders, which has never existed in any version of WooCommerce.

Furthermore, there is a trap that catches even correct HPOS advice: order line items never moved. Both storage modes keep them in wp_woocommerce_order_items and wp_woocommerce_order_itemmeta. Therefore excluding the four wp_wc_ tables and nothing else preserves the order records while overwriting what was in them.

The AHosting Staging Push Exclusion Map

Specifically, this is the table-by-table verdict for a WordPress site pushing staging changes back to production. In practice, “Never push” means production is the authoritative copy of that table and staging’s version must be discarded. Additionally, “Conditional” means the answer depends on whether the table changed on both sides.

Table	What it holds	Push from staging?	What you lose if you push it
`wp_options`	Site settings, serialized plugin config	Conditional	Any setting changed on production during the window
`wp_posts`, `wp_postmeta`	Content; legacy WooCommerce orders	Conditional	New posts, and all orders on a legacy-storage store
`wp_users`, `wp_usermeta`	Accounts, roles, password hashes	Never push	Every registration and password reset since the clone
`wp_comments`, `wp_commentmeta`	Comments and reviews	Never push	Every comment and product review since the clone
`wp_wc_orders`, `wp_wc_order_addresses`, `wp_wc_order_operational_data`, `wp_wc_orders_meta`	HPOS order records	Never push	Every order on an HPOS or compatibility-mode store
`wp_woocommerce_order_items`, `wp_woocommerce_order_itemmeta`	Order line items — legacy tables in both modes	Never push	The contents of every order, in every storage mode
`wp_woocommerce_sessions`	Active carts	Never push	Every cart in progress at push time
`wp_wc_customer_lookup`, `wp_wc_order_coupon_lookup`, `wp_wc_product_meta_lookup`	Analytics lookup tables	Never push	Reporting history — regenerate rather than restore
`wp_actionscheduler_actions`, `wp_actionscheduler_logs`	Queued background jobs	Never push	Pending emails, subscription renewals, sync jobs
`wp_terms`, `wp_term_taxonomy`, `wp_term_relationships`	Categories, tags, product attributes	Conditional	Terms created on production during the window

The AHosting Staging Push Exclusion Map — table-level verdicts for a WordPress staging-to-production push, current for WooCommerce HPOS.

Notably, a store on a managed WooCommerce hosting plan still needs this map, because the exclusion list is a property of WooCommerce’s schema rather than of the server. Ultimately, the host controls whether the push completes; the map controls whether it costs you anything.

How to Tell Whether Your Store Runs HPOS, Compatibility Mode, or Legacy Storage

In WP Admin, open WooCommerce, then Settings, then Advanced, then Features. Specifically, “High-performance order storage” checked with compatibility mode unchecked means HPOS only. Both checked means compatibility mode, where every order is written to both table families at once. Neither checked means legacy post storage.

Consequently, compatibility mode is the most dangerous state for a push, because excluding one family and not the other leaves the two out of sync — the store then shows an order in one view and not the other. Therefore confirm the mode before you build the exclusion list, not after.

Three Ways to Push WordPress Staging to Live on cPanel Shared Hosting

Specifically, cPanel shared hosting has no vendor “Push to Production” button, which turns out to be an advantage: you choose the method by data risk rather than by what the dashboard offers. Additionally, all three ways to push WordPress staging to live below work on any cPanel account with staging, and none of them require shell access.

Method	What moves	Data risk	Typical time	Best for
Selective table push	Files plus a named subset of tables	Low — production tables untouched	10–25 min	Stores, membership sites, anything with live writes
Files-only push with options diff	`wp-content` only, settings re-entered by hand	Lowest — database never written	15–40 min	Theme and plugin updates with few setting changes
Full push behind maintenance mode	Everything, production overwritten	High — total, and irreversible without a backup	5–15 min	Content-only sites with no registrations or comments

Push method comparison for cPanel shared hosting, ranked by the amount of production data each method places at risk.

Method One: Selective Table Push

Specifically, you export only the tables that changed on staging, then import them over production while leaving the excluded tables alone. In practice, this is the default choice for any site that accepts orders, registrations, or comments. Furthermore, it is the only method where you can name in advance exactly which rows are at risk.

Method Two: Files-Only Push With an Options Diff

Notably, most staging work changes code rather than data. A theme update, a plugin version bump, and a template edit all live in wp-content. Therefore you can copy the files across and never touch the database at all, then re-enter the handful of settings you changed through WP Admin on production.

However, this method has a real cost: plugin configuration usually lives in wp_options, so a page builder or a checkout plugin configured on staging will arrive on production unconfigured. Consequently, keep a written list of every setting you change on staging, or the diff becomes guesswork.

Method Three: Full Push Behind a Maintenance Window

In practice, a full push is legitimate for brochure sites, portfolios, and documentation sites where the owner is the only person writing to the database. Additionally, enabling maintenance mode first shrinks the Overwrite Window to the length of the push itself, which turns a three-day risk into a five-minute one.

How to Push WordPress Staging to Live in Seven Steps

To push WordPress staging to live safely: back up production, exclude every table it wrote to since the clone, replace URLs with a serialization-aware tool, push files before tables, then reconcile the row counts. The seven steps below expand that sequence.

First Step: Measure the Overwrite Window and Back Up Production

Firstly, note the clone date and count what production gained since: orders, users, comments, form entries. Then take a full backup of production — files and database — and confirm it downloaded rather than trusting that it exists on the server. Notably, a backup stored only in the account you are about to overwrite is not a backup.

Second Step: Build the Exclusion List Before You Push WordPress Staging to Live

Secondly, confirm your WooCommerce storage mode, then copy the matching rows out of the Exclusion Map into a written list. Additionally, check your own plugins: membership, LMS, booking, and form plugins each create their own tables, and the WordPress database API documentation explains how those custom tables register alongside core ones. In practice, anything whose name you do not recognize should be excluded until you have checked what writes to it.

Third Step: Run a Serialization-Safe URL Replace

Thirdly, replace the staging domain with the production domain — and never with a raw SQL UPDATE. Specifically, WordPress stores plugin and theme configuration as PHP serialized strings, which record their own byte length. Consequently, swapping staging.example.com for example.com leaves a length prefix that no longer matches, the value fails to unserialize, and the setting silently reverts to its default.

Therefore use a serialization-aware tool. WP-CLI’s search-replace command unpacks serialized values, leaves primary keys alone, and offers a --dry-run flag that reports every change before writing one. Furthermore, run the dry run first every time — it costs seconds and it catches the case where you typed the wrong domain.

Fourth Step: Push Files First, Tables Second

Fourthly, move wp-content across before you touch the database, so the code that the new rows expect is already in place. Additionally, export the staging tables with a consistent snapshot: the mysqldump documentation notes that --single-transaction produces a consistent dump for InnoDB tables without locking other clients, though MyISAM and MEMORY tables can still change mid-dump.

Fifth Step: Reconcile Order and User Counts

Fifthly, compare the counts you wrote down in the first step against what production shows now. Specifically, check the order total, the registered user total, and the newest order ID. Notably, if any number moved downward, stop and restore the backup immediately — a partial recovery attempted an hour later is far harder than a clean restore attempted at once.

Sixth Step: Flush Caches and Regenerate Permalinks

Sixthly, purge the page cache, then open Settings and Permalinks in WP Admin and save without changing anything. In practice, that single save rewrites the rewrite rules against production’s structure, which is the fix for the “everything 404s except the homepage” symptom that follows most pushes.

Seventh Step: Watch the Error Log Before You Walk Away

Finally, place a test order, register a test account, and watch the cPanel error log for fifteen minutes. Consequently, you catch the two failures that appear only under real traffic: a plugin querying a table you excluded, and a scheduled job that cannot find the row it queued against. Ultimately, fifteen minutes of watching is the cheapest insurance in this entire process.

Server Resources That Decide Whether You Can Push WordPress Staging to Live

Specifically, a push is a burst of heavy PHP and database work running on the same account that is serving visitors. Therefore the ceiling is not disk space — it is concurrency and memory. AHosting publishes both figures per plan, which is unusual enough that it is worth stating them plainly: Bronze allocates 15 entry processes and 512MB of container memory, Silver 25 and 1024MB, and Gold 40 and 2048MB.

Consequently, an import that pins several workers for minutes leaves fewer for visitors. Notably, CloudLinux queues the overflow rather than rejecting it outright, and on AHosting’s LiteSpeed stack that queue drains for up to 120 seconds before a visitor sees a 503. Additionally, cached pages consume zero entry processes, so LSCache keeps the storefront answering while the push runs underneath it — which is the single most useful thing you can do before starting.

Two Memory Ceilings, One Packet Limit, and Why They Get Confused

Furthermore, two separate memory ceilings apply, and confusing them wastes hours. PHP’s own memory_limit defaults to 256MB on PHP 8.4 accounts and is raisable through cPanel’s PHP INI Editor without a support ticket; the container PMEM cap is the harder limit, as our guide to why raising the WordPress memory limit often does not work explains in detail. Meanwhile, a browser-driven SQL import is also bounded by the database packet size — the MariaDB server system variables reference documents max_allowed_packet, which is what fails a large import halfway through and leaves a partially written database.

What AHosting Includes Before You Push WordPress Staging to Live

In practice, staging is included on every AHosting WordPress plan rather than reserved for higher tiers, and the same PHP worker arithmetic that governs a push governs everyday traffic — our breakdown of the PHP worker math behind concurrent capacity shows how to size it. For the environment requirements behind the clone itself, see what your hosting plan needs to run a staging site.

Staging Push Exclusion Builder

Notably, the exclusion list changes with your site type and storage mode. Answer the four questions below and the tool prints the list to copy into your push tool, along with the method it recommends.

Build Your Push Exclusion List

Four questions. The output is the table list to exclude and the push method that fits your risk.

What kind of site is this?

WooCommerce order storage mode

What changed on staging?

How long has staging been running?

When You Cannot Safely Push WordPress Staging to Live on Shared Hosting

Specifically, three signals mean the push has outgrown a shared account. Firstly, the database exceeds roughly 2 GB and browser-driven imports keep timing out. Secondly, the store writes continuously enough that no maintenance window is acceptable. Thirdly, the same push has to run across many client sites on a schedule.

In those cases, dedicated resources change the arithmetic: workers are guaranteed rather than shared, and shell access means the import runs from the command line instead of through a browser session that can expire mid-write. Specifically, a store that has outgrown shared infrastructure stops competing for entry processes at all. Meanwhile, agencies running the same workflow across a client portfolio get per-account isolation on reseller plans, so one client’s import never draws down another’s worker pool.

Notably, none of this applies to moving a site between hosting providers, which is a different operation with a different failure mode — our guide to moving a WordPress site between hosts with zero downtime covers the DNS side.

The Checklist to Run Before and After You Push WordPress Staging to Live

Record production’s order count, user count, and newest order ID.
Download a full production backup and verify the file opens.
Confirm the WooCommerce order storage mode in Settings, Advanced, Features.
Write the exclusion list from the Exclusion Map, plus any plugin tables.
Enable maintenance mode if any pushed table is one production writes to.
Run the URL replace as a dry run first, then for real.
Push files, then push the named tables.
Save Settings, Permalinks without changing anything.
Purge the page cache and the CDN.
Re-check the three counts from step one.
Place a test order and register a test account.
Watch the error log for fifteen minutes before closing the laptop.

Frequently Asked Questions About How to Push WordPress Staging to Live

How do I push WordPress staging to live without losing orders placed during testing in 2026?

Specifically, exclude every table that production wrote to while you were testing, then push only the tables that changed on staging. Users, comments, sessions and all WooCommerce order tables stay untouched on production. Furthermore, the exact table list depends on whether your store runs HPOS, compatibility mode, or legacy post storage, which is why the Exclusion Map in this guide splits them out by mode.

Selective table push vs full database push: which is safer when you push WordPress staging to live?

Specifically, a selective table push is safer in every case where production accepted a single order, comment, or registration after you cloned. A full push overwrites the entire database and cannot be partially undone. However, a full push is legitimate for content-only sites under a short maintenance window, and the three-method comparison table in this guide shows the exact data risk of each.

Which WooCommerce tables must be excluded when pushing staging to live on an HPOS store in 2026?

Specifically, exclude wp_wc_orders, wp_wc_order_addresses, wp_wc_order_operational_data and wp_wc_orders_meta, plus wp_woocommerce_order_items and wp_woocommerce_order_itemmeta. Notably, those last two are the trap: line items still live in the legacy tables even on a fully migrated HPOS store, so excluding only the wp_wc_ tables leaves orders whose contents get overwritten.

When should I put a WooCommerce store into maintenance mode before I push WordPress staging to live on an AHosting Bronze plan?

Typically, use maintenance mode whenever the push includes any table production also writes to, and always on Bronze, where 15 entry processes and a 512MB PMEM ceiling leave little headroom for a long import running alongside live traffic. In practice, a five-minute maintenance window costs less than one lost order.

What is the Overwrite Window and how do I calculate how much live data is at risk?

Specifically, the Overwrite Window is the elapsed time between cloning staging and pushing it back, multiplied by your production write rate. Therefore a store taking four orders an hour that stages for three days is risking roughly 288 orders. Additionally, the same arithmetic applies to registrations, comments and form entries, which is why the window matters more than the site’s size.

AHosting shared hosting vs VPS: which handles a 2 GB database import when you push WordPress staging to live?

Typically, an AHosting Gold plan handles a 2 GB import comfortably at 40 entry processes and 2048MB PMEM, while Bronze at 15 entry processes and 512MB frequently stalls. In contrast, a VPS gives dedicated workers and shell access, so the import runs from the command line rather than through a browser session that can time out.

Why does a raw SQL find and replace corrupt serialized WordPress data during a staging push?

Specifically, PHP serialized strings store their own byte length, so replacing a shorter domain with a longer one leaves a length prefix that no longer matches the string. Consequently the value fails to unserialize and the setting silently reverts to default. Therefore use a serialization-aware tool, which is exactly what the third step of this guide covers.

What happens if I push WordPress staging to live while WooCommerce compatibility mode is still enabled?

Notably, compatibility mode writes every order to both the HPOS tables and the legacy post tables, so excluding only one family desynchronizes the two. As a result, the store shows orders in one view and not the other, and reconciliation requires a resync. In practice, confirm your storage mode before building the exclusion list.

How long does a staging to live push take on shared hosting before it times out?

Typically, a database under 500MB imports in two to six minutes on shared hosting. However, browser-driven imports are bounded by the web server connection timeout, which on AHosting’s LiteSpeed stack is 120 seconds for the queue window. Consequently, larger databases need a command-line import or a plan with more entry processes.

Does AHosting include staging on every WordPress plan, and what PHP memory does the push need in 2026?

Specifically, staging is included on AHosting WordPress Bronze, Silver and Gold at no extra cost. Additionally, accounts default to PHP 8.4 with a 256MB memory_limit, which customers can raise through cPanel’s PHP INI Editor without a support ticket. Notably, the container PMEM ceiling is the harder limit, and it scales from 512MB on Bronze to 2048MB on Gold.

August 3, 2026

Best PHP Version for WordPress: The 8.3 vs 8.4 vs 8.5 Decision in cPanel

Why the Best PHP Version for WordPress in 2026 Is Not Automatically the Newest
The 2026 WordPress PHP Version Matrix
- Fully Compatible vs Beta Compatible in WordPress Core
- Where WordPress 7.0's PHP 7.4 Floor Actually Sits
What Changes Behind the Dropdown When You Switch PHP Versions
- Why Your Memory Limit Survives and Your Timeout Does Not
The Best PHP Version for WordPress on cPanel: The AHosting Directive Ladder
Three cPanel Tools, One PHP Version: Which Screen Does What
- OPcache and LSCache: Two Cache Layers, Two Different Jobs
How to Change Your PHP Version in cPanel MultiPHP Manager
Choosing the Best PHP Version for WordPress Across Client Sites
AHosting PHP Version Defaults: What Every WordPress Plan Runs
- PHP Version Decision Checker
A Practical Checklist: Is Your WordPress PHP Version the Right One?
Frequently Asked Questions About the Best PHP Version for WordPress

TL;DR

The best PHP version for WordPress in 2026 is PHP 8.3 for compatibility or PHP 8.5 for speed. On AHosting, each version also sets a different memory limit and timeout.

Choosing the best PHP version for WordPress looks like a one-click decision in cPanel, and that is exactly why it goes wrong so often. The MultiPHP Manager dropdown presents a tidy list of version numbers with no indication that picking a different one also rewrites how much memory your site gets, how long a script may run before it is killed, and whether compiled bytecode is cached at all. Consequently, site owners switch versions to chase a performance headline and inherit three configuration changes they never asked for.

Listen: why the newest PHP version is not automatically the right one for WordPress. By Matt Chrust, Director of Business Development, AHosting.

This guide covers what actually changes behind that dropdown on AHosting shared hosting, why WordPress and PHP disagree about which version to recommend, and how to make the switch without discovering the consequences during a failed import.

Why the Best PHP Version for WordPress in 2026 Is Not Automatically the Newest

The newest PHP release is rarely the version WordPress officially recommends, and in 2026 the gap between those two answers is two full releases wide. Specifically, WordPress core is fully compatible with PHP 8.0 through 8.3 and beta compatible with PHP 8.4 and 8.5. Meanwhile, PHP’s own release schedule tells a different story: 8.3 left active support at the end of 2025 and now receives security fixes only.

Therefore, the version WordPress recommends most strongly is already past its active-support window, while the versions with the longest runway carry a compatibility caveat from the WordPress project. Neither answer is wrong. However, both are incomplete without knowing what your host does with each version, which is where most guides stop and this one starts.

The 2026 WordPress PHP Version Matrix

Ultimately, four PHP branches still receive security patches in 2026, and each occupies a different position on the compatibility-versus-longevity trade-off. The table below pairs the official PHP support timeline with WordPress core’s compatibility tier for each branch.

PHP branch	WordPress core status	Active support ended	Security support ends	Verdict for WordPress
PHP 7.4	Minimum supported	Nov 2021	Nov 2022 (EOL)	Floor only — unpatched runtime
PHP 8.2	Fully compatible	Dec 31 2024	Dec 31 2026	Migrate off within months
PHP 8.3	Fully compatible (recommended)	Dec 31 2025	Dec 31 2027	Safest compatibility choice
PHP 8.4	Beta compatible	Dec 31 2026	Dec 31 2028	Longest practical runway
PHP 8.5	Beta compatible	Dec 31 2027	Dec 31 2029	Fastest — OPcache built in

The 2026 WordPress PHP Version Matrix — PHP branch support status paired with WordPress core compatibility tier.

Fully Compatible vs Beta Compatible in WordPress Core

Notably, beta compatible does not mean broken. WordPress uses the term to signal that core passes its automated test suite on a PHP branch, but that the wider plugin and theme ecosystem has not yet had time to catch every edge case. In practice, core itself runs cleanly; the risk sits in third-party code that has not been updated for the newer branch. Accordingly, the WordPress Core Handbook compatibility reference is the authoritative place to check any specific pairing before you commit.

Where WordPress 7.0’s PHP 7.4 Floor Actually Sits

WordPress 7.0 raised the minimum supported PHP version to 7.4.0, dropping 7.2 and 7.3 entirely. However, the minimum recommended version stayed at 8.3, and the two numbers serve completely different purposes. Specifically, the minimum is the point below which core will not load; the recommendation is where the project believes your site belongs. Furthermore, the core Trac discussion behind the change makes the reasoning explicit — the floor moved because usage fell below the project’s 5% retirement threshold, not because 7.4 became a good idea again. Our full breakdown of the WordPress 7.0 hosting requirements covers the database and memory side of the same release.

Switching PHP versions changes more than the version number, and the additional changes are invisible in the cPanel interface. Specifically, every PHP version on a cPanel server carries its own configuration file with its own default values for memory limit, script timeout, upload size, and input variables. Consequently, when you move a domain from one version to another, you inherit the target version’s defaults for every directive you have not personally customized.

In practice, this produces a failure mode that is genuinely difficult to diagnose. A store owner switches to a newer PHP branch for the performance gain, and a week later a scheduled product import starts timing out. Nothing in WordPress changed. Nothing in the plugin changed. However, the script timeout was halved by the version switch, and no interface announced it.

Why Your Memory Limit Survives and Your Timeout Does Not

Notably, the behavior is asymmetric, and the reason is where cPanel stores your customizations. When you change a directive through the MultiPHP INI Editor, cPanel writes that single directive into a configuration file in your account’s home directory — a file that carries no version number in its path. Therefore, it applies to whichever PHP version is active, and it survives every switch you make.

Directives you never touched are absent from that file entirely. Accordingly, they resolve to the active version’s own defaults, which differ between versions. The practical rule is short: what you customized follows you, and what you left alone changes underneath you. Our guide to why raising the WordPress memory limit does not always work on shared hosting explains the layers involved in more depth.

The Best PHP Version for WordPress on cPanel: The AHosting Directive Ladder

Ultimately, the trade-off is only visible once the version numbers sit beside the directive values they carry. The table below is the configuration AHosting sets on its shared WordPress hosting platform, not PHP’s stock defaults.

Directive	PHP 8.3	PHP 8.4 (default)	PHP 8.5
memory_limit	512M	256M	256M
max_execution_time	300s	60s	60s
post_max_size	128M	128M	128M
max_input_vars	1000	1000	1000
OPcache	Not available	Not available	Built into core
WordPress core status	Fully compatible	Beta compatible	Beta compatible

The AHosting PHP Directive Ladder — configured values per PHP version on AHosting shared WordPress hosting, 2026.

The Case for PHP 8.3 as the Best PHP Version for WordPress

Specifically, PHP 8.3 is the only branch that combines full WordPress core compatibility with the most generous resource allocation on the platform: a 512MB memory limit and a 300-second script timeout. Therefore, it is the correct choice for plugin-heavy builds, large page-builder sites, and any workflow involving bulk imports or exports. The trade-off is runway — security support ends December 31 2027.

The Case for PHP 8.4 as the Best PHP Version for WordPress

Notably, PHP 8.4 is the AHosting default because it balances a long support window against broad ecosystem readiness. It receives security patches through December 31 2028, and by 2026 the major plugin vendors have had eighteen months to test against it. However, the 256MB memory limit and 60-second timeout are half and one-fifth of what 8.3 provides respectively, which matters more than the version number for heavy sites.

The Case for PHP 8.5 as the Best PHP Version for WordPress

In contrast, PHP 8.5 offers something no earlier branch on the platform does: OPcache. As of PHP 8.5, OPcache is compiled directly into the PHP core binary rather than distributed as a separate loadable extension, so it is present and active by default. Consequently, selecting PHP 8.5 in MultiPHP Manager is the single action that enables bytecode caching on an AHosting account. Additionally, 8.5 carries security support to December 31 2029, the longest of any current branch.

Three cPanel Tools, One PHP Version: Which Screen Does What

Confusingly, a cPanel account exposes three separate screens that all appear to control PHP, and they do different jobs. Specifically, MultiPHP Manager sets which version a domain runs. MultiPHP INI Editor sets individual directive values such as the memory limit. Select PHP Version, where present, is a separate CloudLinux tool with its own version list and extension checklist.

Importantly, MultiPHP Manager and Select PHP Version are alternative paths rather than complementary ones. A domain configured through one is not accurately reported by the other, which is why an account can appear to run an old version in one screen while actually serving a newer one. Therefore, pick one tool and stay with it. For AHosting WordPress accounts, that tool is MultiPHP Manager.

OPcache and LSCache: Two Cache Layers, Two Different Jobs

Notably, these two caches are often confused, and they operate at completely different points in a request. OPcache stores compiled PHP bytecode in memory so the server does not recompile your code on every request; it reduces how long PHP takes to run. In contrast, LiteSpeed Cache stores the finished HTML output so that PHP does not run at all for a cached visitor.

Consequently, they stack rather than compete: LSCache handles repeat visitors, and OPcache accelerates everything LSCache cannot serve from cache — logged-in sessions, cart pages, and admin requests. Furthermore, neither is a plugin feature at the layer that matters; both are properties of the server configuration your host provides. Our guide to server-level caching on LiteSpeed hosting covers the page-cache half in detail.

How to Change Your PHP Version in cPanel MultiPHP Manager

Specifically, changing the PHP version for a single domain takes about thirty seconds in cPanel and requires no support ticket on any AHosting WordPress plan. The five steps below include the two verification points most walkthroughs omit.

First Step: Record What You Are Running Now

Before changing anything, open WordPress admin, go to Tools, then Site Health, then Info, and expand the Server panel. Write down three values: the PHP version, the memory limit, and the maximum execution time. Consequently, you will be able to tell afterwards which of them changed, rather than guessing.

Second Step: Switch on Staging Before Production

Notably, every AHosting WordPress plan includes staging, and a PHP version change is exactly the kind of change staging exists for. Clone the site, switch the staging copy first, then load the front end and the admin dashboard, and watch for deprecation notices from older plugins. Additionally, exercise the specific workflows that matter to you — checkout, form submission, imports — because those are where an incompatible plugin surfaces.

Third Step: Select the Version and Apply

In cPanel, go to the Software section and open MultiPHP Manager. Furthermore, tick the checkbox beside only the domain you intend to change, choose your version from the PHP Version menu at the top right, and click Apply. The change takes effect immediately for that virtual host and leaves every other domain on the account untouched.

Fourth Step: Re-Check the Directives That Just Changed

This is the step almost every guide skips, and it is the one that prevents the silent failure described earlier. Specifically, return to Site Health and compare the memory limit and maximum execution time against the values you recorded in the first step. If either dropped, open MultiPHP INI Editor and set it explicitly — once set, it will survive future version changes.

Fifth Step: Verify the Switch Took Effect

Finally, confirm that the version reported by WordPress matches what you selected. Site Health reads what the server is actually serving, whereas the cPanel dropdown reports what you asked for, and those two can disagree when a caching layer or a second PHP tool is involved. Therefore, trust Site Health. If it still shows the old version after a few minutes, WordPress’s own update-PHP guidance covers the remaining checks before you open a ticket.

Choosing the Best PHP Version for WordPress Across Client Sites

Notably, agencies face a version problem that single-site owners do not: one legacy client build can hold an entire portfolio back. However, because MultiPHP Manager sets the version per domain rather than per account, a reseller hosting account can run PHP 8.3 for a fragile legacy site and PHP 8.5 for everything else, on the same server, at the same time.

WordPress multisite is the exception worth knowing. Specifically, every site in a multisite network shares a single virtual host, so they share a single PHP version — the network moves together or not at all. Consequently, multisite networks need the compatibility of PHP 8.3 more often than standalone sites do.

AHosting PHP Version Defaults: What Every WordPress Plan Runs

Specifically, every AHosting WordPress hosting account defaults to PHP 8.4 on a LiteSpeed and CloudLinux stack, with PHP 8.3 and 8.5 selectable per domain at no additional cost. Additionally, the PHP INI Editor is enabled on every plan, so raising a memory limit is a self-service change rather than a support request. For WooCommerce stores, that combination matters more than it does for a brochure site, because cart and checkout requests cannot be served from page cache and therefore run PHP on every hit.

Furthermore, sites that have outgrown shared resource ceilings entirely can move to VPS hosting for dedicated workers and full control over PHP configuration. Our guide to hosting requirements for Elementor builds works through the memory side of the same decision.

PHP Version Decision Checker

Answer three questions to see which PHP version fits your WordPress site on AHosting.

1. What kind of site is it? 2. Do you run bulk imports, exports, or long scheduled jobs? 3. How current are your plugins and theme?

See AHosting Plans

A Practical Checklist: Is Your WordPress PHP Version the Right One?

Finally, run these five checks before you decide you are finished. First, confirm your active version in Site Health rather than in the cPanel dropdown. Second, check that the branch you are on still receives security patches — anything at 8.1 or below does not. Third, compare your memory limit and script timeout against what your heaviest workflow actually needs.

Fourth, if you have ever customized a directive, verify it is still applied after any version change. Fifth, test on staging before production, every time, without exception. Ultimately, the best PHP version for WordPress is the newest branch your plugins tolerate, with the directive values your workload requires — and those two conditions are what the dropdown alone will never tell you.

Frequently Asked Questions About the Best PHP Version for WordPress

What is the best PHP version for WordPress in 2026, and does newest always mean fastest?

Specifically, the best PHP version for WordPress in 2026 is PHP 8.3 for maximum compatibility or PHP 8.5 for maximum performance, not simply the newest release available. WordPress core is fully compatible with PHP 8.0 through 8.3 and only beta compatible with 8.4 and 8.5, so the newest branch carries a small compatibility caveat that the recommended branch does not. Furthermore, on AHosting the version you pick also changes your memory limit and script timeout, which is covered in the directive ladder table in this guide.

PHP 8.3 vs PHP 8.4: which is the best PHP version for WordPress on cPanel hosting?

Notably, PHP 8.3 gives WordPress full core compatibility and, on AHosting, a 512MB memory limit with a 300-second script timeout. In contrast, PHP 8.4 carries security support two years longer, until December 31 2028, but ships with a 256MB memory limit and a 60-second timeout. Therefore, plugin-heavy builds and long imports favor 8.3, while sites prioritizing a longer support runway favor 8.4.

Why does my WordPress memory limit survive a PHP version change but my timeout does not?

Specifically, cPanel writes any directive you customize into a version-agnostic file in your home directory, so it applies to every PHP version you switch to. However, directives you never customized are not in that file at all, so they fall through to the defaults of whichever PHP version is now active. Consequently, a custom memory limit follows you across a switch while an untouched script timeout silently adopts the new version's value.

Does AHosting enable OPcache on WordPress hosting accounts, and on which PHP version?

Specifically, OPcache is active on AHosting accounts running PHP 8.5 and is not available on PHP 8.4 or earlier. Since PHP 8.5, OPcache is compiled into the PHP core binary rather than shipped as a separate loadable extension, so selecting PHP 8.5 in cPanel MultiPHP Manager is what turns bytecode caching on. Moreover, no plugin can enable OPcache on any version, because it operates below the application layer entirely.

When should a WooCommerce store on AHosting switch from PHP 8.4 to PHP 8.3 for the 512MB memory limit in 2026?

Notably, switch when product imports, bulk order exports, or plugin updates fail partway through with a white screen or a memory exhaustion notice. PHP 8.3 on AHosting provides a 512MB memory limit and a 300-second timeout, compared with 256MB and 60 seconds on PHP 8.4. Additionally, stores running large catalogs with heavy extension stacks are the most common case where the extra headroom resolves the failure outright.

How do I change the PHP version for one domain in cPanel MultiPHP Manager without affecting other sites?

Specifically, open cPanel, go to Software, then MultiPHP Manager, tick the checkbox beside only the domain you want to change, choose a version from the PHP Version menu, and click Apply. Furthermore, the change applies to that virtual host alone, so other domains on the same cPanel account keep their existing version. Note that any domain left on the inherit setting follows the server default instead.

Is PHP 7.4 still the best PHP version for WordPress if it remains the official 7.0 minimum?

However, no. WordPress 7.0 raised the minimum supported version to PHP 7.4.0, but minimum supported and recommended are different standards. PHP 7.4 reached end of life in November 2022 and receives no security patches, so running it means an unpatched runtime beneath a patched application. Therefore, treat 7.4 as the floor that keeps core loading, never as a target.

What is the best PHP version for WordPress multisite or a reseller account with mixed client builds?

Notably, cPanel MultiPHP Manager sets the PHP version per domain, so a reseller can run different versions for different client sites on the same server. Consequently, a legacy client build can stay on an older version while newer sites move ahead, without forcing a single version across the whole account. However, WordPress multisite is the exception: all sites in a network share one PHP version because they share one virtual host.

Which PHP version does AHosting use by default on WordPress hosting plans in 2026?

Specifically, AHosting WordPress hosting accounts default to PHP 8.4, with a 256MB memory limit and a 60-second script timeout. Additionally, PHP 8.3 and PHP 8.5 are selectable per domain through cPanel MultiPHP Manager without a support ticket or a plan change. Every version's exact directive values appear in the AHosting PHP Directive Ladder table in this guide.

How can I verify the best PHP version for WordPress actually took effect after switching?

Specifically, open WordPress admin, go to Tools, then Site Health, then Info, and expand the Server panel to read the active PHP version, memory limit, and maximum execution time. Furthermore, this reads the values your site is actually served with, which is the point: the cPanel dropdown reports what you selected, while Site Health reports what is running. In practice, check both the version and the two directive values, because one of them may have changed without you asking.

August 3, 2026

WordPress White Screen of Death: A Host’s Step-by-Step Recovery Guide

What the WordPress White Screen of Death Actually Is (A Fatal PHP Error, Nothing More)
Blank Page vs "Critical Error" vs Recovery Email: The Three Gates Core Runs
The WSOD Outcome Matrix: Reading the White Screen of Death Backwards
Why the WordPress White Screen of Death Is Usually a Hosting Problem
How to Fix the WordPress White Screen of Death in Six Steps
AHosting Recovery Readiness by Plan
WordPress Critical Error Triage: Which Outcome Are You In?
A Practical Checklist: Recovering From a WordPress White Screen of Death
Frequently Asked Questions About the WordPress White Screen of Death

TL;DR

The WordPress white screen of death is a fatal PHP error, not an outage. Three server-controlled conditions decide whether you get a recovery email, a critical error page, or a silent blank screen.

Every hosting support desk knows this ticket: fine last night, a blank white rectangle this morning. In practice the WordPress white screen of death alarms people because it says nothing at all — no code, no file name, no line number. However, that silence is itself information, and it points at three conditions WordPress evaluated before deciding to show you nothing.

Listen: why a blank WordPress page is a fatal PHP error your host controls, and the six-step recovery order. By Matt Chrust, Director of Business Development, AHosting.

What the WordPress White Screen of Death Actually Is (A Fatal PHP Error, Nothing More)

Specifically, the WordPress white screen of death is a fatal PHP error that stopped execution before a single byte of HTML was sent. Notably, nothing was deleted, nothing was necessarily hacked, and the database is almost always untouched.

In practice the mechanics are mundane. PHP hits something unrecoverable — a call to a missing function, a class that never loaded, a memory allocation it cannot make — and terminates the request. Consequently the half-built page is discarded and the browser receives an empty body. Sometimes the server dresses that up as an HTTP 500 Internal Server Error, defined in RFC 9110; other times it arrives as a valid 200 response containing nothing. Notably, that difference is diagnostic.

Additionally, the blankness is deliberate. Specifically, WordPress and PHP suppress error output in production because raw error text names absolute file paths, database prefixes and occasionally credentials — the leak class cataloged as CWE-209, generation of an error message containing sensitive information. In other words, the platform protects you at the moment you most want it to talk.

Blank Page vs “Critical Error” vs Recovery Email: The Three Gates Core Runs

Ultimately, WordPress does not treat every fatal error alike. Since version 5.2 it has shipped a fatal error handler, and that handler evaluates three conditions in sequence before deciding what you see.

Gate One — Can WordPress Blame a Plugin or Theme?

First and foremost, WordPress tries to map the crashing file back to a plugin or theme directory. In practice, when it cannot, core returns an internal invalid_source result meaning the error was not caused by a plugin or theme, and no recovery session is offered. Consequently fatals in wp-config.php, a must-use plugin, core itself, or the database layer never produce a recovery email.

Gate Two — Did It Break on a Protected Endpoint?

Additionally, an attributed error only triggers the email when it happens somewhere WordPress protects. Specifically, the is_protected_endpoint() function in WordPress core returns true for exactly three things: the login screen, the admin backend on non-Ajax requests, and a short list of protected Ajax actions. Therefore a fatal firing only on public pages shows visitors the critical error screen and sends you nothing.

Gate Three — Did the Handler Itself Survive?

Finally, the handler has to run at all. In practice it executes during PHP’s shutdown sequence, so the interpreter must still be usable. Consequently a request that died from exhausted memory may leave no headroom to build a message. Similarly, a parse error in wp-config.php or a must-use plugin fires before WordPress loads its error-protection code. Interestingly, getting nothing at all is therefore a clue rather than a dead end.

The WSOD Outcome Matrix: Reading the White Screen of Death Backwards

Therefore the symptom is the diagnosis. Specifically, match what is on your screen to a row below, then read across to find which gate fired, where the evidence lives, and who can fix it.

What you see	Gate that fired	Likely cause	Evidence	Who fixes it
Critical error page and a recovery email	None — all three passed	Plugin or theme fatal in wp-admin	The email names it	You, in Recovery Mode
Critical error page, no email	Gate 2, or mail delivery	Fatal on a front-end page only	cPanel Metrics, Errors	You, via File Manager
Blank page, HTTP 200	Gate 1 — nothing to blame	Core, mu-plugin or database layer	PHP error log	You, then your host
Blank page, HTTP 500	Gate 3 — handler never ran	Parse error in wp-config or .htaccess	Last modified file	Host, or restore
Blank wp-admin, front end fine	Gate 3 — memory exhausted	Heavy admin screen hits the ceiling	“Allowed memory size” log line	You, then a plan upgrade

The WSOD Outcome Matrix — AHosting, July 2026. Match the symptom, read the row across.

Furthermore, an HTTP 500 and an HTTP 503 mean different things here. In practice our diagnostic tree for 503 and 500 resource errors maps the four CloudLinux limits behind them; this guide covers the fatal-error side.

Why the WordPress White Screen of Death Is Usually a Hosting Problem

In practice all three gates are governed by settings that live on the server rather than in WordPress. Consequently the same broken plugin produces a helpful email on one host and total silence on another.

The Memory Ceiling You Cannot Edit Your Way Past

Specifically, CloudLinux shared hosting has two memory ceilings, and raising the wrong one changes nothing. In practice PHP’s memory_limit governs one request, while the container’s physical cap sits above it, untouchable from wp-config.php. Therefore a site configured for 512MB can still die at the container ceiling — the failure our guide to a WordPress memory limit that refuses to change on shared hosting unpacks.

Additionally, memory exhaustion is the most common route to a genuinely blank screen, because it can kill the handler along with the request. Notably, AHosting WordPress accounts run PHP 8.4 by default at a 256MB memory_limit, with PHP 8.3 selectable at 512MB. Moreover, customers raise that themselves through cPanel’s PHP INI Editor without a ticket, which is why a blank screen on AHosting’s WordPress hosting plans is usually a five-minute problem.

The PHP Version That Kills WordPress Before It Loads

By contrast, a version mismatch produces the most confusing white screens, because nothing in WordPress changed. In practice every PHP release removes functions and tightens behavior — the deprecations introduced in PHP 8.4 are representative — so a plugin that ran cleanly on an older branch throws an uncaught error after a switch. Consequently the site goes blank the moment someone touches MultiPHP Manager.

Notably, this sharpened in 2026. Specifically, WordPress 7.0 raised the minimum PHP version to 7.4, pulling a long tail of sites onto branches their plugin stack was never tested against — the floor our breakdown of the WordPress 7.0 hosting requirements covers in full. Fortunately the fix is trivial: switch the version back, confirm the site returns, then update the offending plugin.

The Recovery Email That Never Arrives

Interestingly, WordPress documents this failure itself. Specifically, the official Recovery Mode documentation warns that when a fatal fires before your SMTP plugin loads, the notification goes out through the server’s own mailer — and that a server IP flagged for spam may see it filtered or blocked. In other words, the feature designed to rescue you depends on your account’s deliverability.

Furthermore, core’s recovery email carries a default line telling the recipient to contact their host for assistance. That is WordPress handing the problem to us. Consequently sending reputation becomes an uptime concern, which is why every AHosting plan includes a free dedicated IP — and why our guide to WordPress email deliverability and hosting is worth reading before you need it.

How to Fix the WordPress White Screen of Death in Six Steps

Read the server error log first, then rename one plugin folder — those two moves resolve most cases in under five minutes.

However, work the sequence in order rather than jumping to a familiar fix. In practice each step rules out one gate, and skipping ahead is how a two-minute rename becomes an unnecessary restore.

First Step: Confirm It Is a Fatal Error, Not Cache or DNS

Initially, load the site in a private window with a cache-busting query string such as ?nc=1. Specifically, if the page renders, you are seeing a cached copy of a broken response and the fix is a purge. Additionally, check a second site on the account: if every site is blank, the fault is account-wide.

Second Step: Read the Server Error Log Before Touching Anything

Next, open cPanel, scroll to Metrics, and click Errors. In practice the interface lists recent server errors in reverse order, and the newest line names the file and line number that crashed. Therefore resist the urge to start deactivating things, because you are ninety seconds from the answer.

Third Step: Turn On Logging Without Turning On Display

Subsequently, if the server log is empty, enable WordPress-level logging. Specifically, set WP_DEBUG and WP_DEBUG_LOG to true and WP_DEBUG_DISPLAY to false, as the WordPress debugging handbook specifies. Consequently everything lands in wp-content/debug.log while visitors see nothing. Notably, capturing rather than displaying errors is the point of OWASP’s security logging and monitoring category. Finally, turn all three back off afterwards.

Fourth Step: Rule Out Plugins by Renaming, Never Deleting

Then, in File Manager, rename the plugin folder the log named, because WordPress deactivates anything it cannot find. Moreover, if the log gave you nothing, rename the whole plugins folder, then restore it and disable plugins one at a time. Similarly, switch to a default theme to test that layer. In contrast to deleting, renaming is reversible.

Fifth Step: Raise the Memory Ceiling at Both Layers

Meanwhile, if the log reports that the allowed memory size was exhausted, raise memory_limit in cPanel’s MultiPHP INI Editor rather than in wp-config.php, because the INI Editor writes at the layer that governs the request. Additionally, remember the container ceiling above it. Consequently, when a site needs more than its plan’s physical cap allows, no editing helps.

Sixth Step: Roll the PHP Version Back, Then Forward Again

Finally, if the blank screen began right after a PHP change, open MultiPHP Manager and select the previous branch. In practice the site returns instantly, which restores service and confirms the diagnosis. Afterwards, update the incompatible extension, move forward again, and verify on a staging copy first — a habit our guide to WordPress staging sites and hosting makes routine.

AHosting Recovery Readiness by Plan

Accordingly, here is what each AHosting WordPress plan gives you. Notably, every row is a published figure, and most hosts never disclose the container cap at all.

Plan	Default memory_limit	Via version switch	Container cap	Entry processes	Dedicated IP
WP Bronze	256MB (PHP 8.4)	512MB (PHP 8.3)	512MB	15	Included
WP Silver	256MB (PHP 8.4)	512MB (PHP 8.3)	1024MB	25	Included
WP Gold	256MB (PHP 8.4)	512MB (PHP 8.3)	2048MB	40	Included
WooStart	256MB (PHP 8.4)	512MB (PHP 8.3)	1024MB	25	Included

AHosting shared WordPress plan limits, verified on server sh193, June 2026.

Consequently the Bronze row is the one to watch: its container cap and its maximum PHP memory limit are the same number, so a stack needing 512MB has no headroom left. In particular, cart and checkout requests bypass caching entirely, which is why WooCommerce-optimized hosting starts at the Silver-equivalent tier. Ultimately, when a site repeatedly exhausts the container cap, a VPS with guaranteed memory ends the problem class rather than postponing it.

WordPress Critical Error Triage: Which Outcome Are You In?

In practice, three questions place you on the matrix. Specifically, the tool below returns your outcome, the gate that fired, and the next action.

WordPress Critical Error Triage

Three questions. No data leaves your browser.

1. What does the page actually show?

2. Where is it broken?

3. Did you receive a recovery email from WordPress?

Answer all three questions to see your triage result.

A Practical Checklist: Recovering From a WordPress White Screen of Death

Ultimately, the same eight moves resolve nearly every case. Therefore keep it where whoever is on call can find it.

Load the site with a cache-busting query string in a private window.
Check a second site on the account to rule out an account-wide fault.
Read cPanel Metrics, then Errors. The newest line usually names the file.
Note the HTTP status code, because 200 and 500 point at different gates.
Enable WP_DEBUG_LOG with WP_DEBUG_DISPLAY off, never the reverse.
Rename the named plugin folder. Never delete it to save time.
Check the memory log line first, then raise the limit at the INI layer.
Roll the PHP version back if the blank screen started with a version change.

Additionally, agencies should keep this checklist beside their isolation policy, because one client’s fatal error must never be diagnosable from another client’s dashboard — the reason our reseller hosting accounts isolate every site at the container level. Finally, remember the reassuring part: a white screen is a rendering failure, not a data-loss event.

Frequently Asked Questions About the WordPress White Screen of Death

What causes the WordPress white screen of death in 2026?

Specifically, the WordPress white screen of death is caused by a fatal PHP error that halts execution before any HTML reaches the browser. In practice the four common triggers are an exhausted memory limit, a plugin or theme incompatible with the active PHP version, a syntax error in an edited file, and a corrupted core file. Notably, the blank page carries no clue, which is why the server error log is the first place to look.

WordPress white screen of death vs critical error message: what is the difference?

In practice, both are the same fatal PHP error, and only WordPress’s ability to catch it differs. Since version 5.2, WordPress has shipped a fatal error handler that intercepts the crash and prints the message There has been a critical error on this website. Furthermore, when the error cannot be traced to a plugin or theme, or the handler has no memory left to run, a blank screen is served instead.

Why does the WordPress white screen of death show no error message at all in 2026?

Notably, WordPress hides PHP error output by default because error text leaks file paths, database names and configuration details to anyone who loads the page. That silence is deliberate rather than a bug. Therefore the fix is never to switch error display on for visitors, but to switch error logging on for yourself, which the six-step recovery in this guide walks through.

My WordPress site went blank after a plugin auto-update on AHosting shared hosting, what do I check first?

First and foremost, open cPanel, go to Metrics, and click Errors, because the newest line names the exact file and line number that crashed. Additionally, if that path points inside wp-content/plugins, rename the single guilty plugin folder rather than disabling everything at once. On AHosting the error log is available immediately without a support ticket, which usually turns a multi-hour outage into a two-minute rename.

What is the WSOD Outcome Matrix and how do I use it to diagnose a blank WordPress page?

In other words, the WSOD Outcome Matrix is the five-row table in this guide that maps what appears on screen to which of WordPress’s three internal gates blocked recovery, where the evidence lives, and who can fix it. Specifically, you match your symptom to a row and read across. It exists because a blank page and a critical error page are different diagnoses.

Is the WordPress white screen of death caused by memory limits or the PHP version more often?

Typically, memory exhaustion is the more common cause on shared hosting, while PHP version mismatches produce the more confusing failures. Moreover, the two are easy to separate in the log: memory reports that the allowed memory size was exhausted, whereas a version mismatch reports a call to an undefined function or a parse error. In contrast to a memory fault, a version fault usually begins the moment someone changes the PHP branch.

Why did I never receive the WordPress recovery mode email when my site showed a critical error?

Ultimately, three separate conditions can stop that email. First, WordPress only sends it when the crash happens on a protected endpoint such as wp-admin or the login screen. Second, if the fatal fires before your SMTP plugin loads, the message goes out through the server’s own mailer. Third, if that server’s IP address carries a poor sending reputation, the email is filtered or dropped before it reaches you.

How does AHosting’s cPanel Errors interface help fix a WordPress white screen of death faster?

Specifically, the cPanel Errors interface surfaces recent server error log entries in the browser, so the file path and line number behind the WordPress white screen of death are one click away rather than buried behind SSH. Furthermore, AHosting pairs it with the MultiPHP INI Editor and MultiPHP Manager, so raising the memory limit and rolling the PHP version back are both self-service. Consequently, most recoveries never need a ticket.

Can the WordPress white screen of death delete my posts or media files?

Fortunately, no. Your posts, pages, users and uploads live in the database and in wp-content/uploads, and a fatal PHP error touches neither of them. In practice the crash stops PHP from rendering a page and runs no deletion of any kind. That said, take a backup before editing files, because the recovery steps rather than the error itself are where data is genuinely at risk.

Does WordPress 7.0 change how the white screen of death behaves on AHosting shared hosting in 2026?

Notably, no, because the fatal error handler and Recovery Mode behave in WordPress 7.0 exactly as they have since version 5.2. However, WordPress 7.0 raised the minimum PHP version to 7.4, so sites dragged forward from an ancient branch now execute code paths they never reached before. On AHosting, every plan can select PHP 8.3, 8.4 or 8.5 through cPanel’s MultiPHP Manager.

July 31, 2026

How to Optimize a WordPress Site for AI Search (AEO/GEO): The Infrastructure Half Nobody Covers

What "Optimize WordPress for AI Search" Actually Means in 2026
- AEO, GEO, and the Retrieval Pipeline in One Pass
- The Content Half Everyone Writes About — and the Server Half Nobody Does
Optimize WordPress for AI Search Factor 1: AI Crawlers Never Run Your JavaScript
- How to See Exactly What GPTBot Sees
- Where WordPress Sites Break This
Optimize WordPress for AI Search Factor 2: Crawler Access — robots.txt, WAF Rules, and the Silent 429
Server Speed Is Factor 3: TTFB and the Retrieval-Time Budget
Factor 4: Uptime, Crawl Consistency, and Why Sampling Punishes Flapping
IP Identity Is Factor 5: What a Shared IP Costs in AI Search
The AI Crawler Reachability Ladder: Blocked to Citable
Does llms.txt Help You Optimize WordPress for AI Search?
How AHosting Covers the Server Half of AI Search Optimization
The Server-Side Audit: Is Your WordPress Hosting AI-Search Ready?
Frequently Asked Questions About Optimizing WordPress for AI Search

TL;DR

To optimize WordPress for AI search, start at the server: AI crawlers never run JavaScript, so whatever your server returns in that first response is the only content ChatGPT, Claude, and Perplexity can ever cite.

Almost every guide that tells you how to optimize WordPress for AI search stops at the content layer: write direct answers, add FAQ schema, build topical authority. That advice is correct, and it is also only half the job. Notably, the other half happens before a single word of your content is read — in the HTTP response your server hands back when an AI crawler knocks.

Listen: the server-side half of AI search optimization, from crawler access to the Reachability Ladder. By Matt Chrust, Director of Business Development, AHosting.

Specifically, this guide covers the five server-side factors that decide whether an answer engine can reach, read, retrieve, and cite your pages at all. Notably, none of them are plugin settings. Every one of them is a hosting decision, and the first alone silently deletes a large share of WordPress sites from AI search results without raising one error in Google Search Console.

Written by Matt Chrust, Director of Business Development at AHosting, drawing on infrastructure we have run since 2002.

What “Optimize WordPress for AI Search” Actually Means in 2026

In practice, to optimize WordPress for AI search means making your pages eligible to be quoted inside a generated answer rather than merely ranked in a list of links. Answer engines do not rank pages the way Google does. Instead, they retrieve candidate passages, evaluate them, and cite a handful. Consequently, the unit of competition shifts from the page to the passage — and from position to eligibility.

AEO, GEO, and the Retrieval Pipeline in One Pass

Typically, the two acronyms get treated as rival disciplines. In fact, they describe the same work at different scopes. Answer Engine Optimization aims at being the extracted answer to one question. Generative Engine Optimization aims at being a cited source inside a longer response. Both sit downstream of one four-stage pipeline: fetch, parse, retrieve, cite. Furthermore, a failure at stage one makes stages two through four unreachable, however good the content is.

The Content Half Everyone Writes About — and the Server Half Nobody Does

Additionally, it helps to name the split plainly. The content half is structure, schema, entity clarity, freshness, and originality — covered thoroughly by plugin vendors and SEO publishers. By contrast, the server half is crawler access, rendering mode, response time, availability, and IP identity. Ultimately, when you optimize WordPress for AI search the server half is a prerequisite rather than an optimization: it does not improve your odds so much as decide whether you have odds at all.

Optimize WordPress for AI Search Factor 1: AI Crawlers Never Run Your JavaScript

In fact, this is the highest-leverage thing you can fix when you optimize WordPress for AI search. Googlebot renders JavaScript in a headless browser. The AI retrieval crawlers do not. Therefore, whatever text sits in your raw HTML response is the complete set of content an answer engine can ever consider — and anything the browser assembles afterward does not exist to them.

Notably, this is binary rather than gradual. There is no partial credit, no second rendering pass, and no retry. Consequently, a WordPress page can hold position one on Google while being functionally empty to ChatGPT, Claude, and Perplexity at the same moment.

How to See Exactly What GPTBot Sees

Specifically, use view-source, not the DevTools Elements panel. The Elements panel shows the rendered DOM after JavaScript has run — precisely the view an AI crawler never gets. Press Ctrl+U (Cmd+Option+U on macOS), then Ctrl+F, and search for a distinctive sentence from the middle of your article.

Similarly, a command-line check gives you the same answer without a browser. Running curl -s https://example.com/your-post/ | grep "a sentence from your post" returns the line if the content is server-rendered, and returns nothing if it is not. For a more faithful test, add a crawler user agent with curl -A "GPTBot" — which also reveals whether anything on your stack treats that user agent differently.

Where WordPress Sites Break This

Fortunately, standard WordPress is server-rendered by default, so most sites start well placed to optimize WordPress for AI search. However, several common additions undo it. Page builders that hydrate tabs, accordions, and FAQ blocks client-side move that text out of the server response. Similarly, “load more” pagination and JavaScript-driven comparison tables leave the initial HTML thinner than the visible page. In particular, an FAQ rendered by JavaScript is costly, because FAQ text is exactly the passage shape answer engines prefer to quote.

Moreover, headless WordPress setups deserve a direct warning. A decoupled front end built on client-side rendering serves an empty shell to every AI crawler. Accordingly, server-side rendering or static generation is not a performance preference — it is the difference between being quotable and being invisible.

Optimize WordPress for AI Search Factor 2: Crawler Access — robots.txt, WAF Rules, and the Silent 429

Consequently, the second question when you optimize WordPress for AI search is whether the crawler is allowed to make the request at all. Access failures are quieter than rendering failures, because nothing on your side reports them. Your analytics show normal traffic, your uptime monitor shows green, and your pages simply stop appearing in generated answers.

Training Bots, Search Bots, and User-Fetch Agents Are Not the Same Thing

Above all, stop treating “AI bots” as one category. Each operator now runs several crawlers with separate jobs and separate robots.txt tokens, and blocking one does not block the others. Notably, OpenAI’s crawler documentation states that sites opted out of OAI-SearchBot will not be shown in ChatGPT search answers, while GPTBot governs training only. Similarly, Anthropic’s crawler documentation separates ClaudeBot, Claude-SearchBot, and Claude-User, and Perplexity’s crawler documentation splits PerplexityBot from Perplexity-User.

In other words, the costly mistake is blocking a search-tier crawler while believing you only opted out of model training. For example, a blanket block on ClaudeBot leaves Claude-SearchBot untouched, and a blanket block on GPTBot leaves your ChatGPT citations intact — which is the opposite of what most site owners assume.

User agent	Operator	Job	What blocking it costs you
`OAI-SearchBot`	OpenAI	ChatGPT search index	Removal from ChatGPT search answers
`GPTBot`	OpenAI	Model training	Future training inclusion only
`ChatGPT-User`	OpenAI	User-triggered fetch	Live page fetches on user request
`Claude-SearchBot`	Anthropic	Search indexing	Reduced visibility in Claude results
`ClaudeBot`	Anthropic	Model training	Future training inclusion only
`Claude-User`	Anthropic	User-triggered fetch	Page fetches on user request
`PerplexityBot`	Perplexity	Search indexing	Removal from Perplexity citations
`Perplexity-User`	Perplexity	User-triggered fetch	Live fetches on user request
`Google-Extended`	Google	Gemini and AI grounding	Gemini grounding; not Google ranking

Table 1: AI crawler user agents and the cost of blocking each one. Verified against operator documentation, July 2026.

Rate Limits and Firewall Rules That Block Crawlers robots.txt Allows

Indeed, this is the failure mode almost nobody audits. A permissive robots.txt is a request, not a guarantee. A Web Application Firewall rule, a bot-fight mode, or an aggressive rate limit sits above robots.txt and can return HTTP 429 Too Many Requests or a 403 to a crawler you explicitly welcomed. As a result, the crawler classifies your site as unavailable and backs off.

Furthermore, the operators themselves treat this as a known problem: Perplexity publishes explicit WAF allow-list instructions alongside its robots.txt guidance. Accordingly, the audit is a log query rather than a file read. Search your access log for the user agent and check the status codes it received, not merely whether it appeared.

Additionally, the same tuning that protects you from genuine abuse can catch legitimate crawlers, which is why blanket bot rules are risky. If you have previously tightened bot filtering to deal with automated traffic — the approach we describe in our guide to stopping an XML-RPC bot flood without breaking Jetpack — re-check those rules against the crawler list above before assuming your access posture is clean.

Verifying Real Crawlers Against Spoofed Ones

Notably, the user-agent header is trivially forged, so raw log counts overstate real AI crawl volume. Each major operator publishes a machine-readable IP list for verification. Therefore, treat a hit as genuine only when the token matches and the source IP falls inside the published range. Requests that pass the first test and fail the second are impostors, and you can block them without touching AI search visibility.

Finally, the underlying access contract is older than any of this. The Robots Exclusion Protocol was standardized as RFC 9309 in 2022, and the major AI operators document compliance with it. In other words, the mechanism is stable and well specified; the errors come from applying it to the wrong token, or from a layer above it overriding the answer.

Server Speed Is Factor 3: TTFB and the Retrieval-Time Budget

Specifically, speed changes category when you optimize WordPress for AI search: retrieval crawlers work to a tighter time budget than Googlebot does. A live answer engine assembles a response while a user waits, so a slow origin is not merely penalized — it is skipped. Consequently, Time to First Byte stops being a Core Web Vitals metric and becomes an eligibility threshold.

In practice, the number to watch is uncached TTFB, not cached. Cached pages are fast almost everywhere; the honest measurement is what your server does when the cache misses, which is what a crawler hitting a deep archive page will experience. Moreover, TTFB is largely a server property rather than a plugin property — a point we work through in detail in our guide to telling whether high WordPress TTFB is your server or your plugins.

Additionally, concurrency matters as much as raw speed. When every PHP worker is occupied, new requests queue and eventually time out — and a crawler that times out records a failure rather than a slow success. Therefore sites with sustained concurrent load should size for headroom, which is the point at which VPS hosting with guaranteed dedicated resources starts to pay for itself.

Factor 4: Uptime, Crawl Consistency, and Why Sampling Punishes Flapping

Ultimately, AI crawlers build their picture of your site by sampling it repeatedly over time, which changes what downtime costs when you optimize WordPress for AI search. A traditional search engine that finds your site down will retry and usually recover its index position. By contrast, a retrieval crawler that finds your site down simply builds its answer from a source that responded.

Furthermore, the damaging pattern is not one long outage but frequent short ones. Intermittent 5xx responses during traffic peaks — the classic symptom of exhausted PHP workers on an undersized plan — produce exactly the inconsistency that lowers crawl frequency. As a result, fewer crawls mean fewer opportunities to be sampled, which compounds quietly over months.

In fact, the arithmetic is worth internalizing: a 99.9% uptime guarantee still permits roughly 8 hours 45 minutes of downtime per year, and we break down what each SLA tier really delivers in our analysis of what a 99.9% WordPress hosting uptime SLA actually delivers. Accordingly, sites that cannot absorb that window — or that have outgrown shared infrastructure entirely — belong on a dedicated server with isolated resources.

IP Identity Is Factor 5: What a Shared IP Costs in AI Search

Notably, the last factor is the one AHosting has argued longest. On a shared IP, your server-level identity is pooled with every other account on that address. Consequently, response-time variability, abuse history, and reputation signals attached to that address are not exclusively yours — and neither is the crawl treatment they attract.

However, it is worth stating the limits of this claim honestly. No AI operator publishes an “IP reputation” ranking factor, and we do not claim one exists. Instead, the mechanism is indirect and mundane: a shared address is likelier to sit behind aggressive rate limiting, likelier to be caught by a blanket firewall rule, and likelier to deliver inconsistent response times — all three of which are the failures described in Factors 2 through 4. In other words, a dedicated IP buys no ranking boost; it removes a class of shared failure modes you cannot otherwise control.

For example, we examined the underlying reputation mechanics in detail in our earlier piece on whether your WordPress hosting IP address affects AI search. Accordingly, every one of our WordPress hosting plans includes a free dedicated IP rather than charging it as an add-on.

The AI Crawler Reachability Ladder: Blocked to Citable

Therefore the five factors resolve into one ordered model, which is the fastest way to optimize WordPress for AI search in the right order. We call it the AI Crawler Reachability Ladder, and the sequence matters: each tier is a precondition for the one above it. Notably, most WordPress sites that fail at AI search are not losing on content quality at tier five — they are stalled at tier two or three and have never checked.

Tier	State	Server-side condition	The check that proves it
1	Blocked	robots.txt, WAF, or rate limit denies the crawler	Access log shows 403 or 429 for the crawler user agent
2	Reachable	Crawler receives HTTP 200 from the origin	`curl -A "GPTBot" -I https://example.com/` returns 200
3	Readable	Main content is present in the raw HTML response	`curl -s URL \| grep "a sentence from the post"` returns a line
4	Retrievable	Response is fast and consistent enough to be fetched during answer assembly	Uncached TTFB measured under load; uptime above 99.9%
5	Citable	Passages are self-contained, structured, and attributable	Section answers its heading in the first two sentences

Table 2: The AI Crawler Reachability Ladder. Tiers 1 to 4 are hosting decisions; only tier 5 is a content decision.

Does llms.txt Help You Optimize WordPress for AI Search?

Fortunately, this one has a clear answer that has sharpened considerably over the past year. The llms.txt proposal is a Markdown index file placed at your domain root, intended to help language models find your most useful content without crawling everything. Notably, it is a community convention rather than a ratified standard.

However, the evidence on retrieval impact is thin. Google Search does not consume it, and no major AI provider has committed to using it as a citation input. Large-scale traffic studies published in 2026 found that the overwhelming majority of published llms.txt files were never requested by an AI retrieval bot. Consequently, treating it as a way to optimize WordPress for AI search overstates what it does.

That said, there is a real and growing use case, and it is not the one most guides describe. Coding agents, documentation assistants, and agentic browsers do read the file, and Chrome’s Lighthouse now audits for it under agentic browsing. Accordingly, our position is measured rather than dismissive: publish one if you have structured documentation an agent would benefit from, keep it accurate, and do not expect it to move citations. Above all, spend the effort on Factors 1 through 4 first — those are load-bearing, and this is not.

How AHosting Covers the Server Half of AI Search Optimization

Specifically, four of the five factors are configuration decisions your host either makes for you or leaves to you, which is why the platform matters when you optimize WordPress for AI search. On our shared WordPress platform, standard rendering keeps content server-side by default, robots.txt ships permissive rather than restrictive, and no blanket AI-bot rule sits in front of customer sites. Additionally, every plan includes a free dedicated IP.

In practice, the measured numbers are these. Our LiteSpeed stack with LSCache delivers a median cached TTFB of about 16 ms across production accounts, while uncached WordPress on the same hardware measures 700 ms to 1,400 ms — which is why cache coverage on deep archive pages matters for crawler-facing performance. Furthermore, entry processes are tiered by plan: 15 on Bronze, 25 on Silver, and 40 on Gold, with container memory and CPU scaling alongside. Cached pages consume zero entry processes, because LiteSpeed serves them before PHP runs.

Moreover, agencies managing many client sites face this audit repeatedly rather than once, which is a reason to consolidate onto infrastructure where the crawler-access posture is consistent — our reseller hosting platform for agencies is built for exactly that pattern.

Finally, use the auditor below to score your own site against the ladder. It asks six questions and returns your weakest tier first, because fixing tier two before tier five is the whole point.

AI Crawler Visibility Auditor

Six server-side questions. Your score is weighted by how much each item blocks retrieval, and the result names your weakest tier first.

1. Does your main article text appear in view-source (Ctrl+U), not just DevTools?

2. Does robots.txt allow OAI-SearchBot, Claude-SearchBot, and PerplexityBot?

3. Have you confirmed no firewall or rate limit returns 403 or 429 to those crawlers?

4. Is your uncached TTFB reliably under 600 ms on deep archive pages?

5. Is your hosting uptime at or above 99.9%, without repeated 5xx spikes?

6. Does your WordPress site run on its own dedicated IP address?

—

Answer the six questions to score your site

Each answer updates the score immediately.

See hosting built for the server half

The Server-Side Audit: Is Your WordPress Hosting AI-Search Ready?

Finally, here is the sequence to work through when you optimize WordPress for AI search, in the order that matters. Notably, each step is either a browser action or a one-line command, and none require a plugin.

View-source a published post and confirm your body text is present in the raw HTML.
Repeat that check on a page whose FAQ, tabs, or accordions come from a page builder.
Fetch your robots.txt and confirm no search-tier crawler is disallowed.
Confirm OAI-SearchBot, Claude-SearchBot, and PerplexityBot each have their own directive, not an inherited one.
Grep your access log for those user agents and read the status codes they received.
Verify apparent crawler hits against each operator's published IP ranges.
Review firewall, bot-fight, and rate-limit rules for anything that catches crawler traffic.
Measure uncached TTFB on a deep archive URL, not the cached homepage.
Check whether concurrency peaks are producing 5xx responses.
Review your 12-month uptime record for frequent short outages, not just total minutes.
Confirm whether your site has a dedicated or shared IP address.
Only then move to content: check that each section answers its heading within two sentences.

Ultimately, if steps one through eleven pass, your content is competing on its merits and you have done the hard part of optimizing WordPress for AI search. If any of them fail, no amount of schema markup compensates, because the crawler never reached the schema.

Frequently Asked Questions About Optimizing WordPress for AI Search

How do I optimize WordPress for AI search in 2026 if my site already ranks well on Google?

Specifically, start with the server response rather than the content. Googlebot renders JavaScript; the AI retrieval crawlers do not. A page that ranks well on Google can still be blank to ChatGPT and Perplexity if its main content is assembled in the browser. Check view-source first, then robots.txt, then your firewall rules.

What is the difference between AEO and GEO when you optimize WordPress for AI search?

In practice, the two labels describe the same work at different scopes. Answer Engine Optimization focuses on being the extracted answer to one specific question. Generative Engine Optimization focuses on being a cited source inside a generated response. Both depend on the same prerequisite: a crawler must be able to fetch and read your raw HTML.

Do GPTBot, ClaudeBot, and PerplexityBot render JavaScript on a WordPress site?

In fact, none of the major AI retrieval crawlers execute JavaScript. They read only the HTML your server returns in the first response, so anything a page builder assembles in the browser is invisible to them. Google Gemini is the one exception, because it draws on Googlebot's rendering infrastructure.

My WordPress site uses a page builder that loads FAQs with JavaScript — will AI crawlers see them?

Typically, no. If the FAQ text is injected after page load, it does not exist in the server response an AI crawler reads. Press Ctrl+U and search for one of your answers. Text that appears only in DevTools and not in view-source is invisible to every retrieval crawler.

Blocking GPTBot vs blocking OAI-SearchBot: which one actually removes you from ChatGPT answers?

Specifically, OAI-SearchBot is the one that matters. OpenAI's crawler documentation states that sites opted out of OAI-SearchBot will not be shown in ChatGPT search answers, though they can still appear as navigational links. GPTBot governs training data only, so blocking it does not remove existing citations.

What is the AI Crawler Reachability Ladder AHosting uses to optimize WordPress for AI search?

Notably, it is a five-tier model that ranks a site from Blocked to Citable: Blocked, Reachable, Readable, Retrievable, Citable. Each tier names one server-side condition and one command that proves it. Most WordPress sites that fail at AI search stall on tier two or three, not at the content layer.

Does AHosting hosting help you optimize WordPress for AI search in 2026?

Fortunately, most of the server half is handled by default. Every AHosting WordPress plan includes a free dedicated IP, LiteSpeed with LSCache, and a 99.9% uptime guarantee. Median cached TTFB measured across production accounts is about 16 ms, which keeps retrieval crawlers well inside their fetch budget.

Can a Web Application Firewall or rate limit block AI crawlers my robots.txt already allows?

Indeed, this is one of the most common silent failures. A firewall rule or a rate limit can return 403 or 429 to a crawler your robots.txt explicitly welcomes. Perplexity's own documentation ships WAF allow-list instructions for exactly this reason. Check your firewall logs, not only robots.txt.

Is llms.txt worth adding to a WordPress site in 2026?

Overall, it is low cost and low risk, but it is not a citation lever. Google Search does not use it, and no major AI provider has committed to reading it for retrieval. That said, coding agents and agentic browsers do read it, so publishing one is defensible as an agent-facing convenience rather than an AI search tactic.

Which AHosting plan features matter most when you optimize WordPress for AI search?

Above all, three of them: the free dedicated IP included on every plan, LiteSpeed with LSCache for fast cached and uncached response times, and the entry-process allocation that keeps the server answering during traffic spikes. Bronze provides 15 entry processes, Silver 25, and Gold 40.

July 30, 2026

How Many Concurrent Users Can WordPress Shared Hosting Handle? The PHP Worker Math (2026)

What "WordPress Concurrent Users" Actually Means on WordPress Shared Hosting
- Sessions Versus In-Flight Requests: A 20x Difference
- What a PHP Worker Is, and Why the Count Is a Hard Ceiling
The WordPress Concurrent Users Formula: Little's Law Applied to PHP Workers
The AHosting Concurrency Ladder: WordPress Concurrent Users by Plan and Workload
Why Your Site Slows Down Before It Shows an Error
How to Measure Your Real WordPress Concurrent Users
WordPress Concurrent Users Capacity Calculator
Caching Versus Upgrading: Which Lever Applies to You
When the Math Genuinely Says VPS
A Practical Checklist: Sizing WordPress Concurrent Users on Shared Hosting
Frequently Asked Questions: WordPress Concurrent Users on Shared Hosting

TL;DR

The number of WordPress concurrent users shared hosting supports is not one figure. It is your PHP worker count divided by execution time, then divided by your cache-bypass rate. A cached blog handles thousands. An uncached membership site handles about 175.

Ask how many WordPress concurrent users shared hosting can handle and you will get answers ranging from “about 50” to “up to 100,000 visitors a month” — figures that are not merely different but measuring entirely different things. The reason is that almost nobody publishes the arithmetic. They publish a number, detached from the two variables that actually determine it: how many PHP workers your plan allocates, and what fraction of your traffic reaches those workers at all.

Listen: the PHP worker math behind WordPress concurrency, and when the numbers actually point to a VPS. By Matt Chrust, Director of Business Development, AHosting.

Furthermore, the honest answer is that a single shared hosting plan can simultaneously be wildly overpowered for one site and dangerously undersized for another with identical monthly traffic. A 50,000-visit blog and a 50,000-visit membership site place demands on a server that differ by more than an order of magnitude. Consequently, “how much traffic can shared hosting handle” is the wrong question. The right one is “how many of my requests hit PHP at the same moment, and how many slots do I have.”

This guide publishes the formula, the measured inputs from AHosting’s own shared infrastructure, and a named reference table — the AHosting Concurrency Ladder — that converts worker counts into concurrent visitor capacity for six distinct WordPress workloads. Additionally, it explains why your site slows down before it errors, and which of the two available levers, caching or plan tier, actually applies to your situation.

What “WordPress Concurrent Users” Actually Means on WordPress Shared Hosting

WordPress concurrent users, in server terms, means the number of requests being processed at the same instant — not the number of people with your site open. Specifically, that distinction is the single largest source of confusion in every shared hosting capacity discussion, and getting it wrong by a factor of twenty is routine.

Sessions Versus In-Flight Requests: A 20x Difference

Consider 200 people reading your membership site. Each one loads a page, then reads it for roughly twenty seconds before clicking again. In that twenty-second window, their browser is idle and your server is doing nothing for them. Therefore, at any given instant, only a small fraction of those 200 sessions are actually executing PHP.

Specifically, if a page takes one second to generate and the reader spends twenty seconds reading it, each session occupies a worker for one second out of every twenty-one — about 4.8% of the time. Two hundred such sessions therefore produce roughly nine or ten simultaneous PHP requests on average, not two hundred. In other words, the ratio between “people on your site” and “requests in flight” is governed by think time, and it is typically between 10:1 and 30:1.

Consequently, any capacity claim that does not state which of these two things it is counting is unusable. A host advertising “supports 50 concurrent users” may mean 50 simultaneous PHP requests, which is a substantial allocation, or 50 people browsing, which is almost nothing. Both statements are technically defensible, which is precisely the problem.

What a PHP Worker Is, and Why the Count Is a Hard Ceiling

A PHP worker is a single process slot that handles exactly one uncached request from start to finish. Notably, it cannot be shared, subdivided, or timesliced — while a worker is generating a page, it is unavailable to everyone else. On CloudLinux shared hosting these slots are called entry processes, and the CloudLinux LVE documentation defines the entry process limit as the number of concurrent requests an account can handle at a given moment.

Additionally, this ceiling behaves differently from bandwidth or storage limits, which degrade gracefully. Worker exhaustion is binary: either a slot is free and your visitor is served immediately, or every slot is busy and your visitor waits. The same architecture governs traditional web servers, where the Apache MaxRequestWorkers directive sets the limit on simultaneous requests and queues connection attempts beyond it rather than rejecting them outright.

In practice, this is why plugin optimization eventually stops helping. Trimming a plugin reduces how long each worker is occupied, which genuinely increases throughput. However, it cannot create a sixteenth worker on a fifteen-worker plan. Once execution time is as low as it will go, the worker count is the ceiling, and only a plan change moves it.

The WordPress Concurrent Users Formula: Little’s Law Applied to PHP Workers

The arithmetic that converts a worker count into a visitor count is not new, and it is not specific to hosting. Specifically, it is Little’s Law, a result from queueing theory proved by MIT’s John Little in 1961, which states that the average number of items in a stable system equals the arrival rate multiplied by the average time each item spends in the system.

Concurrent Users Formula Factor 1: Requests Per Second

Written as L = λW, Little’s Law relates queue length, arrival rate, and service time. Notably, the original Little and Graves chapter emphasizes that the relationship holds regardless of how many servers exist, how arrivals are distributed, or what order items are served in — which is exactly what makes it safe to apply to a PHP worker pool.

Rearranged for our purposes, where L is your worker count and W is average PHP execution time, the sustainable arrival rate becomes workers divided by execution time. Therefore a 15-worker plan generating pages in one second sustains roughly 15 uncached requests per second. The same plan generating pages in two seconds sustains only 7.5. In other words, halving your execution time doubles your capacity without changing plan.

Concurrent Users Formula Factor 2: The Cache-Bypass Multiplier

Requests per second is not yet a visitor count, because most requests never reach PHP at all. Specifically, a cached page is served by the web server directly from memory or disk, consuming zero PHP workers. The fraction of your requests that miss cache and reach PHP is your cache-bypass rate, and it is the variable that separates a comfortable site from a struggling one.

Furthermore, bypass rate is a property of your workload, not your configuration alone. A brochure site serving identical HTML to every visitor can cache almost everything. A membership site cannot: logged-in users see personalized content, so full-page cache is bypassed on every request unless edge side includes are configured. The LiteSpeed Cache ESI documentation describes how a page can be cached publicly while private fragments are punched out and assembled separately — the one technique that recovers cacheability for logged-in traffic.

Consequently, the same 15 workers produce radically different visitor ceilings. At a 5% bypass rate, 15 requests per second of PHP capacity serves 300 page views per second of visitor demand. At a 100% bypass rate, it serves 15. That twentyfold spread, driven entirely by workload type, is why generic “shared hosting handles X visitors” claims cannot be correct for everyone.

Concurrent Users Formula Factor 3: Think Time and Burst Headroom

The final step converts page views per second into people. Multiplying by average think time — the seconds a visitor spends on a page before requesting another — turns a request rate into a session count. Typically this is 8 seconds for a checkout flow, 15 to 20 for browsing, and 30 or more for article reading.

However, sizing to the exact average is a mistake, because arrivals are bursty rather than evenly spaced. Requests cluster, and a pool running at 90% average utilization will overflow regularly. Modeling arrivals as a Poisson process shows that keeping the probability of a queue event below 1% requires holding average utilization to roughly 54% on a 15-worker pool, 62% on 25 workers, and 69% on 40 workers. Notably, larger pools tolerate higher utilization because burst variance averages out — a genuine and underappreciated advantage of the higher tiers.

Accordingly, every figure in the ladder table below is calculated at that sub-1% queue-risk threshold, not at theoretical maximum. These are numbers a site can actually sit at, not numbers it touches immediately before failing.

The AHosting Concurrency Ladder: WordPress Concurrent Users by Plan and Workload

The table below applies the formula to AHosting’s three shared WordPress tiers using verified worker allocations and measured response times from the production shared platform. Specifically, AHosting allocates 15 entry processes on Bronze, 25 on Silver, and 40 on Gold, with container memory of 512MB, 1024MB, and 2048MB respectively — worker counts most hosts decline to publish at all.

The AHosting Concurrency Ladder — concurrent active visitors supported before queueing becomes likely, by workload and plan tier (2026)
WordPress workload	Cache bypass	Bronze 15 workers	Silver 25 workers	Gold 40 workers
Cached blog or brochure site	5%	5,000+	9,500+	17,000+
Content site with search and comments	15%	1,000+	2,000+	4,000+
WooCommerce catalog browsing	40%	~325	~625	1,000+
LMS or course portal	60%	~275	~550	~975
Membership site, logged-in	100%	~175	~325	~575
WooCommerce checkout	100%	~75	~150	~250

Read the table by workload row first, then plan column. Notably, the spread within a single column is the point: Bronze supports over 5,000 concurrent readers of a cached blog and about 75 simultaneous checkouts. Both figures come from the same 15 workers. Only the bypass rate differs.

Furthermore, these figures explain a pattern support teams see constantly. A store owner whose catalog pages are fast cannot understand why checkout stalls during a promotion. The catalog is cached and the checkout is not, so a traffic surge that the browsing tier absorbs easily lands entirely on the workers. Consequently the failure appears at the exact moment revenue depends on it.

For context on scale, WordPress remains the dominant platform in this space — the 2025 Web Almanac CMS chapter reports it powering more than 60% of CMS-driven sites, with self-hosted installations showing far wider performance variance than managed platforms. That variance is largely the gap between sites that have done this arithmetic and sites that have not. Consequently, reading your own workload row against your current tier is the fastest way to know which group you are in.

Why Your Site Slows Down Before It Shows an Error

Exceeding your worker count does not produce an immediate error page. Specifically, CloudLinux queues excess requests rather than rejecting them, holding each one until a worker frees up. That queue is why performance degrades gradually rather than failing cleanly, and why the problem is so often misdiagnosed as a plugin issue.

On AHosting’s shared platform the queue drain window is 120 seconds, set by the LiteSpeed connection timeout. Therefore a request arriving when all workers are busy waits — potentially for a long time — and that wait is added directly to the visitor’s page load. Only if no worker frees within that window does the server return a 503 Service Unavailable response, which signals that the server is temporarily unable to handle the request.

Consequently there are three distinct states, and recognizing which one you are in determines the fix. Below the worker limit, pages are instant. At the limit with the queue draining, pages are slow but nothing errors — this is the state most sites live in without realizing it. Beyond the drain window, visitors receive 503s. Additionally, cached pages never enter this sequence at all, because they are served before PHP is ever invoked.

In practice, the diagnostic value here is considerable. Intermittent slowness that correlates with traffic peaks, affects logged-in pages more than public ones, and disappears at quiet hours is not a plugin problem. It is worker queueing, and no amount of image optimization will touch it. Our guide to WordPress PHP workers and 503 errors covers the error-state diagnosis in depth, while the 508 resource limit guide addresses what happens when the entry process ceiling is hit directly.

How to Measure Your Real WordPress Concurrent Users

Reading the ladder table requires knowing your actual peak concurrency, which is not a number most site owners have. Fortunately, it can be derived from data you already collect, using the same law in reverse.

First Step: Derive Peak Concurrency From Analytics

Open your analytics and find page views in your single busiest hour, not your daily average. Specifically, divide that figure by 3,600 to get average page views per second, then multiply by three to approximate the within-hour peak, since traffic inside any hour is uneven. That result is your peak page views per second.

Multiply by your average think time to convert into concurrent sessions. As a worked example, a site with 9,000 views in its peak hour averages 2.5 views per second, peaks near 7.5, and at 20 seconds of think time carries roughly 150 concurrent sessions. That is the number to compare against the ladder.

Second Step: Find Your Actual Cache-Bypass Rate

Bypass rate is measurable rather than estimated. Load a public page in a logged-out browser and inspect the response headers for the LiteSpeed cache status — a hit means that request consumed no PHP worker. Then repeat while logged in. Notably, most WordPress sites show a hit for anonymous visitors and a miss for authenticated ones, which confirms the pattern the ladder assumes.

Additionally, calculate the proportion of your traffic that is authenticated, cart-bearing, or search-driven, since those requests are your true bypass population. A blog where 2% of sessions log in has a bypass rate near 5%. A membership site where 80% of sessions are authenticated is closer to 85%. Consequently, that percentage, not your total traffic, is what determines your tier.

Third Step: Reduce Execution Time to Buy Capacity

Because execution time sits in the denominator, halving it doubles capacity at no cost. Specifically, the highest-yield target is repeated database work: WordPress issues dozens of queries per uncached page load, and the same expensive queries frequently run on every request.

The WordPress Transients API provides the native mechanism for storing the result of an expensive query with an expiration, so it runs once rather than continuously. Furthermore, a persistent object cache extends that principle across requests entirely — Redis data structures hold query results in memory so repeated lookups never reach the database. Together these two changes routinely cut execution time by a third or more on plugin-heavy sites.

WordPress Concurrent Users Capacity Calculator

Enter your workload type and peak traffic below to see the plan tier your concurrency actually requires. The calculator applies the same formula and the same sub-1% queue-risk threshold used to build the ladder table.

WordPress Concurrent Users Capacity Calculator

Three inputs. Returns the plan tier your peak concurrency actually needs.

1. What kind of WordPress site is this?

2. Page views in your busiest hour

3. Typical time a visitor spends per page

Peak page views per second

Estimated concurrent visitors

Requests reaching PHP

Workers needed at peak

See WordPress Hosting Plans

Caching Versus Upgrading: Which Lever Applies to You

Two levers raise concurrency: lowering your cache-bypass rate, or raising your worker count. Specifically, they are not interchangeable, and applying the wrong one is the most common and most expensive capacity mistake.

For cacheable traffic, caching wins decisively on cost. Moving a blog from no full-page cache to server-level caching drops its bypass rate from 100% to roughly 5%, multiplying effective capacity about twentyfold — a gain no single plan upgrade can match, since Bronze to Gold is a 2.7x change in workers. Therefore a content site struggling under load should exhaust caching before considering a tier change.

However, caching cannot touch traffic that is inherently uncacheable. Checkout pages carry live cart state, payment tokens, and inventory writes. Logged-in member pages carry personalized content. Consequently no cache configuration reduces their bypass rate below 100%, and for those workloads the worker count is the only variable left. Additionally, this is why a store can be simultaneously over-provisioned for browsing and under-provisioned for checkout. AHosting’s WooCommerce hosting plans are allocated at Silver-level concurrency for exactly this reason.

In practice the sequence is: cache everything cacheable, reduce execution time with object caching, then size the tier against whatever uncacheable peak remains. Notably, most sites that believe they need a VPS discover after the first two steps that they need Silver.

When the Math Genuinely Says VPS

The ladder has a top rung, and some sites sit above it. Specifically, when your uncacheable peak exceeds the Gold figure for your workload, no configuration change on shared hosting will close the gap, because the worker allocation is fixed by plan and cannot be raised in isolation.

Three situations put a site there. A membership platform sustaining more than roughly 575 concurrent logged-in sessions has exhausted Gold. A store regularly exceeding about 250 simultaneous checkouts has done the same. Additionally, any site needing direct control over worker counts, object cache configuration, or per-site PHP tuning has hit an architectural limit rather than a numerical one. On a VPS you set pm.max_children yourself against your own RAM, so capacity becomes a resource question rather than a plan question — VPS hosting exists precisely for that transition.

Furthermore, sites whose uncacheable concurrency runs into the thousands eventually exceed a single VPS as well, at which point single-tenant hardware becomes the right answer. Our guide to the seven signs a WordPress site has outgrown shared hosting covers the qualitative symptoms that accompany these numbers, and a dedicated server removes resource contention entirely for workloads at that scale.

Consequently the decision is arithmetic rather than instinct. Measure your peak concurrency, identify your bypass rate, compare against the ladder, and the correct rung is unambiguous. Sites that skip this step routinely upgrade two tiers past what they need, or stay one tier below it while blaming their plugins.

A Practical Checklist: Sizing WordPress Concurrent Users on Shared Hosting

Work through these in order. Notably, the sequence matters — steps one through four are free and frequently remove the need for step six entirely.

Pull page views from your single busiest hour, not your daily or monthly average
Divide by 3,600 and multiply by three to estimate peak page views per second
Multiply by average think time to convert that rate into concurrent visitors
Check cache headers logged out and logged in to establish your real bypass rate
Locate your workload row in the AHosting Concurrency Ladder and read across to your tier
If you are above your tier’s figure, enable full-page caching before changing plans
Add a persistent object cache to cut execution time on whatever remains uncacheable
Re-measure after both changes, since capacity often doubles without a plan change
Only if the remaining uncacheable peak still exceeds Gold does the arithmetic point to VPS

Additionally, re-run this whenever your traffic pattern changes materially — adding a membership tier, launching a store, or gating content all raise your bypass rate sharply even when total traffic is flat. In practice, that shift, not traffic growth, is what pushes most sites past their ceiling. Server-level caching behavior is covered further in our guide to LiteSpeed server-level caching.

Frequently Asked Questions: WordPress Concurrent Users on Shared Hosting

How many concurrent users can WordPress shared hosting handle in 2026?

Specifically, a cached WordPress blog on a 15-worker shared plan handles roughly 5,000 concurrent visitors, while an uncached membership site on the same plan handles about 175. The number is not one figure. It depends on how many of your requests bypass cache and reach PHP, which is why two sites with identical traffic can need completely different plans. The AHosting Concurrency Ladder table above gives the figure for six workload types across all three tiers.

What is the formula for calculating WordPress concurrent users on shared hosting?

Specifically, the formula is concurrent visitors = (PHP workers divided by average PHP execution time) divided by your cache-bypass rate, then multiplied by average think time. This applies Little’s Law from queueing theory to PHP worker pools. Furthermore, sizing to the raw result is unsafe because arrivals are bursty, so every figure in the ladder table is calculated at a utilization level that keeps queue events below one percent.

AHosting shared hosting vs VPS in 2026: what changes for WordPress concurrent users?

Fundamentally, shared hosting gives you a fixed worker allocation set by your plan, while VPS lets you configure the worker count yourself against your own RAM and CPU. On AHosting shared plans the ceiling is 15, 25, or 40 entry processes depending on tier. On VPS you set pm.max_children directly. Consequently the practical difference is that shared hosting has a hard ceiling you cannot raise without upgrading, and VPS has a ceiling you control.

Why does my WordPress site slow down before it shows a 503 error?

Notably, CloudLinux queues excess requests rather than rejecting them instantly. When every PHP worker is busy, new requests wait for a free slot, and that wait time is added directly to your page load, so visitors experience slowness first. Only when a request cannot be served inside the 120-second connection window does the server return a 503. That queue window is the reason slowness always precedes errors, and it is why traffic-correlated slowness is a capacity signal rather than a plugin problem.

How many PHP workers does a WooCommerce store need for 100 concurrent shoppers?

Typically, 100 concurrent WooCommerce shoppers browsing a cached catalog need roughly 7 to 10 workers, but 100 concurrent shoppers at checkout need far more because checkout cannot be cached at all. In practice the distinction matters more than the visitor count: browsing traffic mostly hits cache, while checkout traffic hits PHP on every single request. The ladder table separates these two workloads deliberately, and the gap between the two rows is where most store outages originate.

What cache-bypass rate should I assume for a WordPress membership site in 2026?

Generally, assume a 100 percent cache-bypass rate for logged-in membership traffic unless you have configured edge side includes. Logged-in users receive personalized content, so full-page cache cannot serve them. Consequently a membership site with 500 registered members can need more server capacity than a blog with 50,000 monthly readers, because registered members are a marketing number while concurrent logged-in sessions are a server specification.

How do AHosting Bronze, Silver, and Gold plans differ in concurrent user capacity?

Specifically, AHosting allocates 15 entry processes on Bronze, 25 on Silver, and 40 on Gold, with container memory rising from 512MB to 1024MB to 2048MB alongside. Because higher tiers raise memory and CPU together with worker count, the added workers have real resources behind them rather than being a headline number. Additionally, larger pools absorb traffic bursts more efficiently, so Gold handles roughly 2.7 times the simultaneous PHP load of Bronze.

Is it better to add caching or upgrade my AHosting plan for more concurrent users?

Indeed, caching almost always delivers more capacity per dollar than a plan upgrade for content sites. Moving a blog from no cache to full-page caching can cut its bypass rate from 100 percent to about 5 percent, which multiplies effective concurrency roughly twentyfold, while Bronze to Gold is only a 2.7 times change. However, caching cannot help traffic that is inherently uncacheable, such as checkout and logged-in sessions, so for those workloads the plan tier is the only lever available.

What is the AHosting Concurrency Ladder and how do I use it?

Specifically, the AHosting Concurrency Ladder is a published table mapping six WordPress workload types to the concurrent visitor capacity of each plan tier, calculated from measured worker counts and response times rather than marketing estimates. To use it, identify your workload row, read across to your current tier, and compare that figure to your real peak concurrency from analytics. Notably, most hosts decline to publish worker counts at all, which makes this arithmetic impossible to perform anywhere else.

When should I upgrade from shared hosting to VPS based on concurrency numbers?

Generally, upgrade to VPS when your measured peak concurrency exceeds the Gold tier figure for your workload type, or when you need to configure worker counts and object caching directly. Before that point, moving up the Bronze to Silver to Gold ladder is cheaper and requires no migration. Furthermore, the calculator above identifies which of those two situations you are in, and sites that run it frequently discover that caching changes remove the need for any upgrade at all.

July 24, 2026

How to Stop an XML-RPC Bot Flood Without Breaking Jetpack (2026)

What an XML-RPC Bot Flood Actually Costs Your WordPress Site
- Why the XML-RPC Bot Flood Symptom Is Usually a 503, Not a 508
- The Three Symptoms That Identify an XML-RPC Bot Flood
What 23,993 Real XML-RPC Requests Look Like in 2026
- Nearly Half of XML-RPC Traffic Is Jetpack, Not an Attack
- The Port 80 Gap That Edge-Only Blocking Misses
Why the Advice You Will Find Is Describing a 2015 Vulnerability
- Where WordPress Core Says This Problem Belongs
How to Stop an XML-RPC Bot Flood in Five Steps
Estimate Your Own XML-RPC Bot Flood Worker Cost
When Blocking Is Not Enough
Your XML-RPC Bot Flood Checklist
Frequently Asked Questions: Stopping an XML-RPC Bot Flood

TL;DR

To stop an XML-RPC bot flood, allowlist Jetpack first, then deny xmlrpc.php in .htaccess so LiteSpeed refuses the request before WordPress loads and no PHP worker is consumed.

An XML-RPC bot flood is the most expensive WordPress problem that never shows up on an uptime monitor. Your site responds. Your homepage loads. Yet your cache hit ratio quietly collapses, your entry process graph pegs at its ceiling, and real visitors start seeing errors during exactly the minutes you care about most. Meanwhile the traffic responsible is invisible in analytics, because bots do not fire JavaScript.

Listen: why 47% of your XML-RPC traffic may be Jetpack, and how to block the rest.

Furthermore, most of the fix advice you will find is describing an attack that WordPress patched over a decade ago. This guide is built on 23,993 XML-RPC requests captured across roughly 200 WordPress accounts on a single AHosting shared server during one 18-hour window in July 2026 — what the traffic actually looks like now, what it costs in PHP workers, and the one trap that turns the standard fix into a self-inflicted outage.

What an XML-RPC Bot Flood Actually Costs Your WordPress Site

An XML-RPC bot flood costs you one uncacheable PHP worker per request. That single sentence explains every downstream symptom. Specifically, xmlrpc.php is a POST endpoint that no cache layer can serve from storage, so every request that reaches it bypasses LiteSpeed Cache entirely and executes PHP against your account’s concurrency ceiling.

Therefore the arithmetic is unforgiving. In our July 2026 measurement window, the busiest single account sustained 59 XML-RPC POSTs per minute for a continuous fifteen-minute stretch. That account runs on a plan with 15 entry processes. In other words, the flood alone was requesting nearly four times the account’s entire concurrent capacity every minute, before a single genuine visitor was counted.

Why the XML-RPC Bot Flood Symptom Is Usually a 503, Not a 508

Notably, the error you actually see depends on your web server. On Apache-based cPanel hosts, hitting the entry process ceiling produces the familiar 508 Resource Limit Reached page. On LiteSpeed, which is what AHosting runs, requests are queued first — so the visitor experiences a slowdown and only receives a 503 if the queue window expires before a worker frees up.

Consequently, if you have been searching for why your resource graphs are pegged but you never see a literal 508 page, this is the answer. Our sample logged 50 genuine 503 responses against XML-RPC endpoints during the window. For the full mechanics of that ceiling, our guide to what entry process limits really mean when you hit a 508 resource limit covers how concurrency is calculated and why page generation time is the hidden multiplier.

The Three Symptoms That Identify an XML-RPC Bot Flood

Typically, the pattern is recognizable before you ever open a log file. Firstly, your cache hit ratio drops sharply while total traffic appears flat or even low in analytics. Secondly, your cPanel entry process graph shows sustained plateaus rather than the brief spikes normal traffic produces. Thirdly, wp-admin becomes sluggish or briefly unreachable at moments when your public pages still load instantly, because cached pages need no worker while your admin session does.

What 23,993 Real XML-RPC Requests Look Like in 2026

Most published guidance on this topic reasons from a single incident report. In contrast, we measured every XML-RPC request arriving at one shared AHosting server across an 18-hour window on 20–21 July 2026 — roughly 200 WordPress accounts, no sampling. The response code distribution is the part nobody publishes, and it changes what the correct fix looks like.

Response	Count	Share	What it means
404 Not Found	13,566	56.5%	File already removed or blocked — bots scanning blindly
200 OK	10,025	41.8%	WordPress loaded and a PHP worker was consumed
301 Redirect	535	2.2%	Scheme or host redirect before processing
503 Unavailable	50	0.2%	Queue window expired — no worker available

Interestingly, the 404 majority reframes the whole problem. Most of this traffic is indiscriminate scanning against sites that already removed the file, which means the bots are not selecting targets intelligently. As a result, the accounts that genuinely matter are the ones behind those 10,025 successful responses — each one a PHP worker allocated to answer a bot.

Nearly Half of XML-RPC Traffic Is Jetpack, Not an Attack

Here is the finding that should stop you before you paste any blocking rule. Of the 23,993 requests we captured, 11,388 — roughly 47 percent — carried Jetpack or WordPress.com user agents. Jetpack uses XML-RPC as its transport to communicate with WordPress.com, and it has done so for years.

Consequently, the advice to simply deny xmlrpc.php would have broken nearly half of the observed traffic on this server — taking down Jetpack stats, backups, Publicize, and mobile app publishing for every affected customer. Notably, this caution is not new: the security researchers who originally disclosed XML-RPC brute-force amplification revised their own guidance for exactly this reason, recommending a full block only where Jetpack and similar plugins are not in use.

Additionally, the remaining traffic tells its own story. We recorded requests presenting Chrome, Firefox, and Opera browser user agents against an API-only endpoint that no browser ever posts to — spoofed headers, in other words. The top single source address issued 1,372 requests on its own, and the top twelve addresses together accounted for roughly 35 percent of all XML-RPC traffic on the server.

The Port 80 Gap That Edge-Only Blocking Misses

Specifically, one account in our sample recorded 2,296 XML-RPC POSTs on plain HTTP alongside 964 on HTTPS. That distribution matters enormously for anyone relying on a CDN or edge firewall rule scoped to HTTPS traffic, because it demonstrates the plain HTTP path can carry more than twice the volume of the encrypted one.

Therefore any block you apply must be verified on both schemes. In practice this is the single most common reason a site owner reports that “blocking did not work” — the rule was real, but it only ever covered one door.

Why the Advice You Will Find Is Describing a 2015 Vulnerability

Search this problem and you will repeatedly read that a single POST can carry hundreds or thousands of password attempts through the system.multicall method, with amplification figures of 100x or 500x quoted confidently. That mechanic was real. It was also patched more than ten years ago.

Specifically, WordPress core addressed it in version 4.4, released December 2015, through Trac ticket 34336, which disables XML-RPC system.multicall authenticated requests after the first authentication failure. Once one credential attempt inside a batch fails, every remaining attempt in that batch fails with it. Consequently the amplification window closed for any site running WordPress 4.4 or newer, which in 2026 is effectively all of them.

In contrast, what our logs show is the attack that replaced it: slow, distributed, sequential requests. No batching is required when you control enough source addresses to simply issue 23,993 individual POSTs. Ultimately this distinction matters because it changes the correct defense. Method-level filtering of system.multicall addresses a patched problem, whereas the 2026 problem is request volume reaching PHP at all.

Additionally, it is worth knowing why the endpoint still exists at all. XML-RPC predates the WordPress REST API, which is now the supported interface for remote applications. Modern integrations use the REST API, yet xmlrpc.php remains enabled by default for backward compatibility — which is precisely why it stays a standing target on sites that never knowingly use it.

Where WordPress Core Says This Problem Belongs

Notably, the WordPress project has been explicit about ownership of this issue. Responding to a request that core mitigate XML-RPC flooding, a core developer noted that a denial of service against xmlrpc.php is no different from one against the homepage or the login page, that preventing it falls outside the scope of WordPress and needs to be handled at the server level.

That is the entire argument for fixing this in your web server configuration rather than with a plugin, stated by the people who maintain the software. For the broader picture of which protections belong below the application layer, our guide to the server-level WordPress protection plugins cannot add covers the same principle across firewalls and account isolation.

How to Stop an XML-RPC Bot Flood in Five Steps

Deny xmlrpc.php in .htaccess so the web server returns 403 before WordPress loads — but allowlist Jetpack first if you use it. The steps below establish which case you are in before you change anything.

First Step: Confirm the Flood Exists in Your Raw Access Log

Firstly, establish the problem is real rather than assumed. In cPanel, open Metrics → Raw Access and download the current log for your domain, or run the count directly over SSH if you have shell access.

grep -c 'xmlrpc.php' ~/access-logs/yourdomain.com-ssl_log

Specifically, a healthy site with Jetpack installed shows a steady low-hundreds count over a day. Anything in the thousands within a single log window is a flood. Additionally, run the same count against the non-SSL log, because the port 80 gap described above is easy to miss.

Second Step: Split Your Traffic Into Jetpack and Everything Else

Secondly, and this is the step almost every guide omits, find out how much of that traffic is your own. This single command answers the question that determines which fix you apply.

grep 'xmlrpc.php' ~/access-logs/yourdomain.com-ssl_log | grep -c 'Jetpack'

Therefore compare that figure against your total. In our server-wide sample the Jetpack share was 47 percent. If your own ratio is similarly high and you actively use Jetpack features, proceed to the allowlist method. If it is near zero and nothing else on your site consumes XML-RPC, the full deny is simpler and stronger.

Third Step: Choose Your Blocking Method

Thirdly, pick the method that matches what you found. The table below states the trade-off for each so the decision takes seconds rather than an afternoon of reading.

Method	Runs before PHP?	Jetpack survives?	Best for
.htaccess full deny	Yes	No	Sites with zero XML-RPC dependency
.htaccess with Jetpack allowlist	Yes	Yes	Most sites — the recommended default
Security plugin block	No	Varies	Nothing — still consumes the worker
Rename or delete xmlrpc.php	Yes	No	Nothing — core updates restore it
Edge or CDN rule only	Yes	Configurable	Layered defense, never the sole block

Notably, the security plugin row is the one that surprises people. A PHP-based plugin must boot WordPress in order to decide the request should be refused, so the entry process you were trying to protect is consumed regardless. The block works; the resource saving does not materialize.

Fourth Step: Apply the Rule in .htaccess

Fourthly, edit the .htaccess file in your WordPress root directory. Place this block above the # BEGIN WordPress marker so core updates never overwrite it. For a full deny, use the first form, which applies the Apache 2.4 Require directive for unconditional access denial.

<Files "xmlrpc.php">
  Require all denied
</Files>

Alternatively, to keep Jetpack working, allow Automattic’s ranges before denying everything else. Importantly, Jetpack publishes these ranges and warns that they are subject to change, so verify the current list before deploying and re-check it periodically.

<Files "xmlrpc.php">
  <RequireAny>
    Require ip 122.248.245.244
    Require ip 54.217.201.243
    Require ip 54.232.116.4
    Require ip 192.0.80.0/20
    Require ip 192.0.96.0/20
    Require ip 192.0.112.0/20
  </RequireAny>
</Files>

Importantly, LiteSpeed reads Apache-style .htaccess directives natively, so this rule takes effect on AHosting WordPress hosting plans without any server restart. Furthermore, because the rule is evaluated at the web server layer, a denied request never reaches PHP and never touches your entry process allocation.

Fifth Step: Verify the Block on Both HTTP and HTTPS

Finally, prove it worked. Request the file on both schemes and confirm each returns 403 rather than 200 or 405.

curl -s -o /dev/null -w "%{http_code}\n" https://yourdomain.com/xmlrpc.php
curl -s -o /dev/null -w "%{http_code}\n" http://yourdomain.com/xmlrpc.php

Consequently both commands should print 403. Additionally, check your raw access log an hour later and confirm new xmlrpc.php entries now carry 403 status codes rather than 200. In practice your cache hit ratio and entry process graph should visibly recover within the same day.

Estimate Your Own XML-RPC Bot Flood Worker Cost

Specifically, this calculator converts your raw log count into the concurrency figure that actually matters — how much of your plan’s entry process ceiling the flood is consuming. Enter the number you measured in the first step.

XML-RPC Worker Cost Calculator

Convert your log count into entry process pressure.

XML-RPC requests in your log window Log window length in hours Your entry process ceiling

Importantly, this estimate assumes roughly one second of uncached execution per request, which is typical for WordPress on shared infrastructure. Furthermore, if your result exceeds your ceiling, blocking is urgent rather than optional — and if it still exceeds capacity after blocking, the underlying concurrency headroom is the real constraint. Our guide to how many PHP workers your WordPress site actually needs covers how to size that properly.

When Blocking Is Not Enough

Ultimately, an .htaccess deny returns 403 cheaply, but the request still arrives, still occupies a connection slot, and still appears in your logs. For the volumes in our sample this is entirely sustainable. However, at sustained rates well beyond what we measured, the connection handling itself becomes the constraint.

Therefore the escalation path runs in three stages. Firstly, add an edge or firewall rule so the traffic is refused before it reaches your server at all — layered with, never instead of, the origin rule. Secondly, if a small number of source addresses dominate as they did in our sample, block those ranges at the firewall level. Thirdly, if your site genuinely needs more concurrent capacity for legitimate traffic, dedicated server infrastructure removes the shared ceiling entirely.

Notably, agencies managing many client sites face this at multiplied scale, since every unprotected client site is an independent target. Applying the same rule across a portfolio at provisioning time is far cheaper than diagnosing it per site later, which is one practical argument for isolated per-client hosting accounts.

Your XML-RPC Bot Flood Checklist

Count xmlrpc.php hits in both your SSL and non-SSL raw access logs
Measure what share carries a Jetpack user agent before deciding the method
Confirm you are on WordPress 4.4 or newer, so the multicall amplification window is closed
Apply the rule in .htaccess above the # BEGIN WordPress marker
Allowlist Automattic ranges first if Jetpack handles your stats, backups, or Publicize
Verify 403 on both HTTPS and plain HTTP
Re-check the access log an hour later for 403 status codes on new entries
Watch entry process usage and cache hit ratio recover over the following day
Never rely on a PHP security plugin alone — it consumes the worker it blocks

Frequently Asked Questions: Stopping an XML-RPC Bot Flood

How do I stop an XML-RPC bot flood without breaking Jetpack in 2026?

Specifically, allowlist Jetpack’s Automattic IP ranges first, then deny xmlrpc.php for everyone else in .htaccess so the request is refused at the web server before WordPress loads. In our July 2026 server logs, Jetpack accounted for 47 percent of all XML-RPC traffic, so a blanket deny would have broken nearly half the observed requests. The full allowlist syntax appears in the numbered fix section.

Is the system.multicall XML-RPC amplification attack still a threat in 2026?

Notably, no. WordPress core patched it in version 4.4, released December 2015, via Trac ticket 34336: once one authentication attempt inside a system.multicall batch fails, every remaining attempt in that batch fails too. Much of the advice ranking for this problem still describes the pre-4.4 mechanic. The 2026 problem is sequential request volume, not batched credential amplification.

Why does my site show a 503 error instead of a 508 during an XML-RPC flood?

Specifically, LiteSpeed queues requests when your entry process ceiling is reached rather than rejecting them instantly, so the visitor waits and then receives a 503 only if the queue window expires first. Apache-based hosts surface the same underlying concurrency event as a literal 508 page. Both errors mean the same thing: no free PHP worker.

How many PHP workers does an XML-RPC flood consume on AHosting shared hosting plans?

Specifically, one uncacheable PHP worker per request that reaches WordPress. In our July 2026 measurement window the busiest account sustained 59 XML-RPC POSTs per minute against a 15 entry process ceiling, the AHosting Bronze allocation. Consequently the flood alone can saturate the plan’s entire concurrency allocation before a single real visitor is served.

Should I block xmlrpc.php with a plugin or with .htaccess on AHosting WordPress hosting?

Therefore use .htaccess. A PHP-based security plugin still boots WordPress to decide the request should be denied, which consumes the entry process you were trying to protect. A web server rule refuses the request before PHP ever loads, so the worker is never allocated. WordPress core developers state the same thing: denial of service against xmlrpc.php needs handling at the server level.

Does blocking xmlrpc.php at Cloudflare protect the plain HTTP port 80 path too?

Importantly, not necessarily. One account in our July 2026 logs recorded 2,296 XML-RPC POSTs on port 80 alongside 964 on port 443. Consequently an edge rule scoped only to HTTPS traffic can leave the plain HTTP path fully open. Always verify the block returns 403 on both schemes.

Interestingly, 56 percent in our July 2026 sample: 13,566 of 23,993 requests returned 404 because xmlrpc.php had already been removed or blocked on those accounts. In other words most of this traffic is indiscriminate scanning rather than targeted attack, and the accounts that matter are the 10,025 that returned 200.

When should I disable XML-RPC entirely versus allowlisting Jetpack on a WordPress site?

Specifically, deny it outright when nothing on the site uses XML-RPC: no Jetpack, no WordPress mobile app publishing, no remote editor, and no pingbacks you rely on. Allowlist instead when Jetpack handles your stats, backups, or Publicize. The comparison table in this guide names the trade-off for each method.

How do I confirm an XML-RPC block is actually working on my WordPress site?

Specifically, request the file and confirm the response is 403 rather than 200 or 405. Then grep your raw access log for xmlrpc.php and confirm new entries show 403 status codes. Additionally, watch your cPanel entry process graph and cache hit ratio recover over the following hours.

Does an XML-RPC bot flood hurt cache hit ratio on AHosting LiteSpeed hosting in 2026?

Fundamentally, yes. Every XML-RPC POST is uncacheable by definition, so it bypasses LiteSpeed Cache on AHosting entirely and executes PHP. As a result your cached-to-uncached ratio collapses in reporting, and the workers those requests occupy are unavailable to visitors whose pages would otherwise have been generated quickly.

July 21, 2026