Category: WordPress

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

Disable WordPress AI Features in WordPress 7.0 (2026 Guide)

How WordPress 7.0 Turned AI Connectors On by Default
How to Disable WordPress AI Features in 7.0
Three Ways to Disable WordPress AI Features: Constant vs. Filter vs. Plugin
Disable WordPress AI Features: What's Covered and What Isn't
Optional: Hide the Settings → Connectors Screen With an mu-plugin
Diagnostic: Did You Fully Disable WordPress AI Features?
Editing wp-config.php Safely on AHosting WordPress Hosting
Frequently Asked Questions: Disable WordPress AI Features in 7.0

TL;DR

To disable WordPress AI features in WordPress 7.0, add define( 'WP_AI_SUPPORT', false ); to wp-config.php. It overrides the wp_supports_ai filter, blocks every AI provider call site-wide, and a plugin cannot re-enable it.

Disable WordPress AI Features: Audio Explainer

WordPress 7.0 shipped a built-in AI Client and a Settings → Connectors screen that any administrator or editor can wire to OpenAI, Anthropic, or Google — and there is no dashboard switch to turn it back off. This guide shows how to disable WordPress AI features in minutes by adding one line to wp-config.php, then proving the change actually took effect. The whole fix is a single constant, but the reasons to apply it — contracts, data-protection rules, and a smaller attack surface — are worth understanding first.

How WordPress 7.0 Turned AI Connectors On by Default

WordPress 7.0, released May 20, 2026, added three AI building blocks to core: the AI Client (a provider-agnostic PHP API exposed through wp_ai_client_prompt()), the Connectors API, and a new Settings → Connectors admin screen. That screen lists three featured provider cards — OpenAI, Anthropic, and Google — and lets an administrator paste one API key that every compatible plugin then shares, as documented in the WordPress 7.0 Field Guide.

Importantly, this infrastructure is inert until someone enters a key. WordPress core bundles no provider credentials, and per core changeset 61700, the platform “will not send prompts or data to any external service” without explicit configuration and explicit calling code. The provider-agnostic layer itself lives in the bundled WordPress php-ai-client library.

However, “off until configured” is not the same as “safe to ignore.” Any user with the right capability can open Settings → Connectors and paste a key, at which point content can flow to a third-party model. Connector keys are also stored masked but not encrypted in the database (tracked in Trac #64789), so a live key can travel inside database dumps, staging refreshes, and backups. For a site under an NDA or a data-protection obligation, that is a surface most teams would rather remove than police. In practice, disabling the AI Client by default and opting sites in later is the cleaner policy — and it is one line.

How to Disable WordPress AI Features in 7.0

To disable WordPress AI features, add define( 'WP_AI_SUPPORT', false ); to wp-config.php above the “stop editing” line, then confirm wp_supports_ai() returns false. The four steps below do exactly that, safely, using the tools included with your hosting.

First, Back Up and Open a Staging Copy

First and foremost, never edit wp-config.php straight on production. On AHosting, open cPanel, create a one-click staging clone, and confirm your daily backup is current so you have a restore point. Editing a staging copy first means a typo in the config file — the classic cause of a white screen — never touches your live site. If you also manage many sites, the same edit is easy to standardize across them, which is why the wp-config approach scales better than clicking through each dashboard.

Next, Open wp-config.php in cPanel File Manager

Next, in cPanel open File Manager, navigate to the site’s document root (typically public_html), select wp-config.php, and click Edit. Scroll to the line that reads /* That's all, stop editing! Happy publishing. */. Everything you add must go above that line, because WordPress ignores configuration defined after it. If you prefer SFTP, the same file in the same location works identically.

Then, Add the WP_AI_SUPPORT Constant

Then paste this single line above the “stop editing” comment and save. The constant is read at the very top of wp_supports_ai(), before any plugin or theme loads, which is why it is the most reliable off switch and cannot be reversed by a plugin at runtime, per the official wp_supports_ai reference.

// Disable the WordPress 7.0 AI Client site-wide (enforced)
define( 'WP_AI_SUPPORT', false );

Finally, Verify That AI Support Is Off

Finally, prove the fix took effect rather than assuming it. If you have terminal access, WP-CLI answers in one line and should print bool(false):

wp eval "var_dump( wp_supports_ai() );"

Alternatively, reload Settings → Connectors in wp-admin: with AI support off, provider connections no longer initialize. For a deeper look at editing configuration safely, our guide on why raising limits in wp-config often fails covers the same file and the two-ceiling gotcha that trips people up.

Three Ways to Disable WordPress AI Features: Constant vs. Filter vs. Plugin

Specifically, WordPress 7.0 gives you three levers, and they are not equal. The constant is enforced earliest and cannot be undone by a plugin; the filter is flexible but runs later and is override-able; a plugin is the no-code option for owners who cannot edit wp-config.php. The developer-friendly filter version, popularized in Shawn Hooper’s write-up, looks like this:

add_filter( 'wp_supports_ai', static function ( $supported ) {
    return false;
}, 1000 );

Table 1 compares the three methods so you can match the lever to the site. Use it as a standalone reference when deciding what to deploy across a fleet versus a single site you fully control.

Table 1 — WordPress 7.0 AI Disable Methods Compared
Method	Where it lives	Can an editor undo it?	Hides Connectors screen?	Best for
`WP_AI_SUPPORT` constant	wp-config.php	No — loads before plugins	No (add the mu-plugin)	Production sites, whole fleets
`wp_supports_ai` filter	Theme or snippet	Yes — a later hook can override	No	Single sites you fully control
Disable-AI plugin	Plugins screen	Yes — if deactivated	Yes (most hide it)	No-code owners, locked wp-config

Consequently, the plugin route matters on managed platforms where wp-config.php is not directly editable. Two well-maintained options are “Turn Off AI Features” and “Disable AI for Security,” both of which wrap the same wp_supports_ai filter and add an admin badge. On AHosting you have full cPanel access, so the constant remains the recommended path.

Disable WordPress AI Features: What’s Covered and What Isn’t

In practice, the constant is comprehensive for core AI but has one honest boundary: it only governs code that checks wp_supports_ai(). Plugins that ship their own AI integration — rather than calling the core client — are unaffected and must be handled in their own settings. Table 2 draws that line clearly so you do not assume more coverage than the constant provides.

Table 2 — What WP_AI_SUPPORT = false Stops (and What It Doesn’t)
Surface	Covered by the constant?
Core AI Client calls (`wp_ai_client_prompt()`)	Yes — short-circuited site-wide
Featured connectors (OpenAI / Anthropic / Google)	Yes — no prompts run, keys stay inert
Settings → Connectors admin screen visibility	No — still visible unless you add the mu-plugin
Plugins with their own bundled AI	No — disable each plugin’s AI separately

Optional: Hide the Settings → Connectors Screen With an mu-plugin

Additionally, the constant blocks AI calls but leaves the Settings → Connectors menu item visible. To remove it and block direct access, drop a small must-use plugin into wp-content/mu-plugins/ — a location that loads automatically, survives theme switches, and cannot be deactivated from the Plugins screen. The removal hooks admin_menu at a high priority (not admin_init, which would break admin-ajax) using the core remove_submenu_page function:

<?php
/**
 * Plugin Name: Hide WordPress AI Connectors
 * Description: Removes Settings -> Connectors and blocks direct access.
 */
add_action( 'admin_menu', function () {
    remove_submenu_page( 'options-general.php', 'options-connectors.php' );
}, 999 );

add_action( 'admin_init', function () {
    global $pagenow;
    if ( 'options-connectors.php' === $pagenow ) {
        wp_safe_redirect( admin_url() );
        exit;
    }
} );

That said, screen names can change between releases, so treat the mu-plugin as belt-and-suspenders on top of the constant, not a replacement for it. The constant is what actually stops the AI calls; hiding the menu just removes the temptation.

Diagnostic: Did You Fully Disable WordPress AI Features?

Interestingly, most “still exposed” sites have the constant right but miss the two edge cases: the visible Connectors screen and plugins with their own AI. Answer the four checks below to see exactly where your site stands.

AI Connector Exposure Check

1. Is your site running WordPress 7.0 or newer?

Yes No

2. Is define( ‘WP_AI_SUPPORT’, false ); in your wp-config.php?

Yes No

3. Have you hidden the Settings -> Connectors screen (mu-plugin)?

Yes No

4. Do any active plugins ship their own built-in AI?

Yes No

Answer all four to see your exposure verdict.

Editing wp-config.php Safely on AHosting WordPress Hosting

Fortunately, the riskiest part of this fix is not the constant — it is editing wp-config.php without a safety net. Every AHosting WordPress hosting plan ships one-click staging, daily backups, and cPanel File Manager, so you can test the edit on a clone and restore instantly if anything looks off. That staging-plus-backup workflow is the same one we recommend in our server-level WordPress security guide.

Moreover, if you run AI features intentionally, they make outbound calls from your server to provider endpoints — and every AHosting plan includes a free dedicated IP, so those calls carry a stable, isolated identity rather than a shared reputation. Agencies standardizing an AI-off policy across many client sites can do it per account on white-label reseller hosting, and sites that have simply outgrown shared concurrency can move the same configuration onto managed VPS without changing a line of it. For the full pre-update picture, see our WordPress 7.0 hosting requirements checklist.

Frequently Asked Questions: Disable WordPress AI Features in 7.0

How do I disable WordPress AI features in WordPress 7.0?

Specifically, add define( 'WP_AI_SUPPORT', false ); to your wp-config.php file above the “stop editing” comment. The core function wp_supports_ai() then returns false everywhere, so no provider connector or AI-aware feature runs.

WP_AI_SUPPORT constant vs. wp_supports_ai filter: which should I use?

Fundamentally, the WP_AI_SUPPORT constant is the stronger control because it is read at the top of wp_supports_ai() before any plugin loads, so nothing can override it. The wp_supports_ai filter runs later and a higher-priority plugin can undo it.

Is it safe to disable WordPress AI features in 2026?

Yes. Disabling WordPress AI features only short-circuits the core AI Client; it does not affect posts, editing, media, or any non-AI functionality. You can re-enable it in seconds by removing the constant.

Should agencies disable WordPress AI features across client sites on AHosting reseller hosting?

Typically, defaulting AI off is the lower-risk posture for agencies. On AHosting reseller hosting each client account is isolated, so you can set WP_AI_SUPPORT per account and opt a client in only when their contract allows external AI processing.

Does WordPress 7.0 send my content to AI providers by default?

Notably, no. WordPress core ships no AI provider keys and, per changeset 61700, will not send prompts or data externally without explicit configuration and explicit calling code. The risk is that an editor can add a connector key later.

WP_AI_SUPPORT constant vs. the Turn Off AI Features plugin: which is more reliable?

Typically, the constant is more reliable for production because it lives in wp-config.php and cannot be deactivated from the Plugins screen. A plugin is easier for non-technical owners but only enforces the setting while it stays active.

Will disabling WordPress AI features also stop plugins that have their own AI?

Importantly, no. WP_AI_SUPPORT gates only plugins that call the core AI Client. A plugin bundling its own AI integration ignores the setting, so you must disable that plugin’s AI separately in its own settings.

What happens if I define WP_AI_SUPPORT as false on a WordPress multisite network?

On multisite, the constant applies network-wide from wp-config.php, so every subsite has AI off at once. The Settings → Connectors screen can still appear on subsites, so pair the constant with the optional mu-plugin to hide it.

Can I edit wp-config.php to disable AI on AHosting WordPress hosting in 2026?

Yes. Every AHosting WordPress plan includes cPanel File Manager, one-click staging, and daily backups, so you can edit wp-config.php on a staging clone, verify the fix, and push it live with a restore point in place.

Does AHosting support disabling WordPress AI features in 2026?

Indeed. AHosting runs WordPress 7.0 on LiteSpeed with cPanel access on every plan, so the WP_AI_SUPPORT constant, the wp_supports_ai filter, and the mu-plugin method all work without a support ticket.

July 17, 2026

How to Disable the WordPress Heartbeat (Before It Eats Your PHP Workers)

What the WordPress Heartbeat Actually Does (And Why It Costs You If You Don't Disable WordPress Heartbeat)
- The uncacheable-path problem in one sentence
- Heartbeat is not WP-Cron — do not confuse the two
See the Problem: Watch Heartbeat Fire in Your Own Browser
Heartbeat Worker Cost vs Your AHosting Plan (The Numbers)
How to Disable WordPress Heartbeat Safely in 4 Steps
Plugin vs Filter vs LiteSpeed Toggle: Which Method to Use
Heartbeat Decision Checker: Throttle, Scope, or Disable WordPress Heartbeat?
When Disabling Heartbeat Is a Symptom of Outgrowing Your Plan
Frequently Asked Questions: Disabling the WordPress Heartbeat

TL;DR

To disable WordPress Heartbeat safely, throttle its interval to 60 seconds and deregister it on the front end with one heartbeat_settings filter — this cuts admin-ajax.php load about 75% while keeping autosave and post locking.

Listen: why the Heartbeat costs PHP workers and how one filter fixes it. By Matt Chrust, Director of Business Development, AHosting.

If you want to disable WordPress Heartbeat, the goal is almost never to kill it outright — it is to stop it from quietly flooding admin-ajax.php with requests that consume PHP workers while nobody is reading your site. The Heartbeat API polls your server on a timer every time an admin or editor tab is open, and because that request path cannot be cached, even a well-tuned WordPress hosting stack serves each tick through PHP. Fortunately, one filter fixes it without breaking autosave.

Notably, this is a silent cost. There is no error, no warning, and no visible slowdown until concurrency stacks up and the server starts queuing requests. Below, we show you how to confirm the problem in your own browser, apply the safe fix, verify it worked, and — using AHosting’s published PHP-worker counts — see exactly how much of your plan the Heartbeat can occupy.

What the WordPress Heartbeat Actually Does (And Why It Costs You If You Don’t Disable WordPress Heartbeat)

Specifically, the Heartbeat API is a polling system introduced in WordPress 3.6 that lets your browser talk to the server on a fixed interval — a “tick” every 15 to 120 seconds. It powers autosave, post locking (so two editors do not overwrite each other), session expiry warnings, and plugin notifications. Under the hood it is a classic AJAX request pattern. According to the WordPress Heartbeat API handbook, each tick sends a POST to admin-ajax.php, the server prepares a response, and the browser waits for it.

However, the design has a sharp edge. In practice the tick runs whether or not the site has visitors, and the admin-ajax.php path is uncacheable — it bypasses page caching entirely and executes PHP on every call. Consequently, an open dashboard left in a background tab keeps spending server resources on nothing. Multiply that by several editors, several tabs, and a few plugins hooking the stream, and you get high CPU that looks mysterious because traffic is low.

The uncacheable-path problem in one sentence

Ultimately, this is why “just add more caching” does not help. Server-level caching — including the LiteSpeed and LSCache stack AHosting runs — serves a cached visitor page with zero PHP workers, but it cannot cache a logged-in admin-ajax.php POST. Therefore every Heartbeat tick is a full dynamic request. The fix is not more cache; it is fewer, smarter ticks. For the deeper server-side picture, our companion guide on the server-side factors no plugin can fix covers the caching layer in full.

Heartbeat is not WP-Cron — do not confuse the two

Importantly, the Heartbeat is often mistaken for WP-Cron, and the mix-up leads people to apply the wrong fix. In contrast, WP-Cron runs scheduled server tasks triggered on page loads, while the Heartbeat is a browser-to-server poll that only runs while an admin tab is open. They are separate subsystems on separate triggers. If your issue is scheduled jobs stacking up rather than idle-tab polling, see our guide on why WP-Cron fails and how to replace it instead.

See the Problem: Watch Heartbeat Fire in Your Own Browser

First, confirm the symptom before you change anything. Open any post in the editor, press F12 to open your browser’s developer tools Network panel, and watch the request list. Type admin-ajax into the filter box, then simply wait — without touching the keyboard. Within about 15 seconds a POST request to admin-ajax.php appears; roughly 15 seconds later, another. That steady pulse, with no visitor activity, is the Heartbeat.

Furthermore, you can watch the same pattern in your hosting resource graphs. On a CloudLinux account, sustained admin-ajax.php processes appearing in the process list — often flagged near a 508 “resource limit reached” event — are the Heartbeat and similar loopback calls competing for the same PHP workers your visitors need. That connection to your plan’s worker ceiling is the part most guides skip, so we quantify it next.

Heartbeat Worker Cost vs Your AHosting Plan (The Numbers)

Here is the data no generic tutorial can give you, because it requires knowing the host’s real worker counts. AHosting publishes its PHP worker (entry-process) allocation per plan — Bronze 15, Silver 25, Gold 40 — so we can map the Heartbeat’s appetite directly onto a ceiling. Each open post-editor tab ticks about four times per minute, and each tick occupies one worker on the uncacheable path. The table below shows what that means as concurrent editors climb.

Open post-editor tabs (15s ticks)	Ticks / min	Share of Bronze (15 EP)	Share of Silver (25 EP)	Share of Gold (40 EP)
1 editor	4	7%	4%	2%
2 editors	8	13%	8%	5%
5 editors	20	33%	20%	12%
10 editors	40	67%	40%	25%
15 editors	60	100%	60%	38%

Heartbeat Worker Cost vs AHosting Plan EP Ceiling. Each open post-editor tab ticks ~4×/min; each tick is one uncacheable admin-ajax.php request occupying one PHP worker. Cached visitor pages consume zero workers. Source: AHosting published per-plan entry-process counts.

Consequently, the headline figure is stark: 15 editors with post-editor tabs open can occupy 100% of a Bronze plan’s PHP workers — spent entirely on polling, with zero visitors served. Even at throttled 60-second intervals, that pressure drops roughly fourfold, which is precisely why throttling beats brute-force disabling for busy teams. If your concurrency is regularly pushing these numbers, that is a genuine signal to move to a plan with more workers or to WordPress VPS hosting with dedicated resources.

How to Disable WordPress Heartbeat Safely in 4 Steps

Here is the shortest correct fix: add one heartbeat_settings filter that raises the interval to 60 seconds and deregisters Heartbeat on the front end, leaving the editor’s autosave and post locking intact. The four steps below walk through it and verify the result.

First Step: Choose Where the Code Lives

First, decide where to put the snippet. A code-snippet plugin such as WPCode or Code Snippets is the durable choice because it survives theme switches; a child theme’s functions.php works too but disappears if you change themes. Either way, you are adding a small PHP filter — no core files are touched. Avoid pasting into the parent theme’s functions.php, since a theme update will overwrite it.

Second Step: Add the Throttle-and-Scope Filter To Disable WordPress Heartbeat

Next, add the filter below. The first function raises the tick interval to the maximum 60 seconds; the second stops Heartbeat entirely on the public front end, where logged-out visitors gain nothing from it. Together they keep the editor fully functional while removing the bulk of the load. The heartbeat_settings hook reference documents the interval values (anything 15–120).

// 1. Throttle Heartbeat to the maximum 60-second interval.
add_filter( 'heartbeat_settings', 'ah_throttle_heartbeat' );
function ah_throttle_heartbeat( $settings ) {
    $settings['interval'] = 60; // allowed range is 15-120
    return $settings;
}

// 2. Disable Heartbeat on the public front end only.
add_action( 'init', 'ah_disable_frontend_heartbeat', 1 );
function ah_disable_frontend_heartbeat() {
    if ( ! is_admin() ) {
        wp_deregister_script( 'heartbeat' );
    }
}

Third Step: Save and Clear Cache

Then save the snippet (or update functions.php) and clear any page cache so the front-end change takes effect. On a LiteSpeed host, purge LSCache; if OPcache is active on your PHP pool, the new function may take a few seconds to load, so allow a moment before testing. No visitor-facing markup changes, so there is nothing to break on the front end.

Fourth Step: Verify in the Network Panel

Finally, prove it worked. Reload the post editor, open developer tools, and filter the Network panel to admin-ajax again. Where you previously saw a request every 15 seconds, you should now see roughly one per minute — about 75% fewer calls. Type a word in the draft and confirm the “Saving… / Saved” autosave indicator still fires. If it does, you have throttled the Heartbeat without losing the features that matter.

Plugin vs Filter vs LiteSpeed Toggle: Which Method to Use

Above all, pick the method that matches how you manage the site. The filter is the lightest; a plugin is the most approachable; the LiteSpeed Cache toggle is convenient if you already run that plugin. All three reach the same outcome — fewer admin-ajax.php calls — so the decision is about maintainability, not capability.

Method	Best for	Trade-off
`heartbeat_settings` filter	Developers; leanest install	Requires editing PHP
Heartbeat Control / snippet plugin	Non-coders; theme-independent	One more plugin to maintain
LiteSpeed Cache toggle	Sites already on LSCache	Only if LSCache is installed

Three routes to the same result; choose by maintainability.

Moreover, the choice interacts with your other plugins. If a page builder such as Elementor, or a WooCommerce extension, depends on Heartbeat for editor or cart behavior, prefer the throttle-only route rather than deregistering the script — a point the interactive checker below helps you decide. For a store specifically, the same worker math applies to checkout, which we cover in our WooCommerce hosting breakdown.

Heartbeat Decision Checker: Throttle, Scope, or Disable WordPress Heartbeat?

Use the checker below to get a recommendation based on your setup. It maps three common answers to the safe action so you do not accidentally disable a feature your site relies on.

Heartbeat Decision Checker

What does your site depend on? Pick the closest match.

Your setup

See AHosting WordPress plans

When Disabling Heartbeat Is a Symptom of Outgrowing Your Plan

Finally, treat a chronic Heartbeat problem as a signal, not just a nuisance. Occasionally, throttling is enough forever. But if you are throttling, deregistering, and still bumping the worker ceiling during normal editing, the real constraint is concurrency headroom. As the table above shows, the same tick count that occupies 100% of a Bronze plan barely touches a Gold plan — the difference is published worker allocation, not a hidden setting.

Therefore, the durable fix for a growing team is more workers behind the same polling, which is what higher shared tiers and VPS provide. Heartbeat tuning buys you room; capacity buys you certainty. Size the plan against the concurrency math in this guide, and you will stop firefighting admin-ajax.php for good.

Last updated: July 15, 2026

Frequently Asked Questions: Disabling the WordPress Heartbeat

Does disabling the WordPress Heartbeat break autosave or post locking?

Specifically, disabling Heartbeat everywhere removes autosave and post locking, but throttling it to 60 seconds keeps both while cutting requests by about 75 percent. Therefore the recommended pattern is throttle in the editor, disable on the front end. The filter earlier in this guide does exactly that.

What is the safest way to disable the WordPress Heartbeat in 2026?

Generally, the safest way to disable the WordPress Heartbeat in 2026 is to throttle the interval to 60 seconds and deregister the script only on the front end, leaving the editor untouched. Consequently autosave and post locking keep working while admin-ajax.php load drops sharply.

Heartbeat Control plugin vs the heartbeat_settings filter: which should I use?

In practice, the heartbeat_settings filter is lighter because it adds no plugin overhead, while the Heartbeat Control plugin is friendlier if you avoid code. Both reach the same result. The comparison table above maps each method to the resource cost it removes.

Disable WordPress Heartbeat in functions.php or in a snippet plugin: what is the difference?

Notably, a functions.php edit is theme-bound and disappears on theme switch, whereas a code-snippet plugin survives theme changes and is easier to toggle. Therefore a snippet plugin is the more durable place to disable the WordPress Heartbeat on a production site.

How much server load does the WordPress Heartbeat cause on AHosting shared hosting in 2026?

Concretely, each Heartbeat tick is one uncacheable admin-ajax.php request that consumes one PHP worker for its duration. As a result, fifteen open editor tabs can occupy every worker on an entry-level plan. The plan-by-plan table above shows exactly where that ceiling sits on Bronze, Silver, and Gold.

Why does admin-ajax.php show high CPU even when my WordPress site has no traffic?

Fundamentally, admin-ajax.php runs the Heartbeat API on a timer, so it fires whether or not visitors are on the site. Because that path bypasses page caching, LiteSpeed cannot absorb it. In other words, the CPU is spent polling from an open admin tab, not serving readers.

Does AHosting's LiteSpeed cache stop Heartbeat from consuming PHP workers without needing to disable WordPress Heartbeat?

Unfortunately no, because admin-ajax.php is uncacheable by design, so LiteSpeed serves it through PHP like any dynamic request. However, AHosting publishes its per-plan worker counts, so you can size the Heartbeat cost against a known ceiling rather than guessing.

Should I throttle the WordPress Heartbeat or disable WordPress Heartbeat on a 2026 WooCommerce store?

Typically, throttle rather than disable when a WooCommerce store or membership plugin depends on Heartbeat for cart, stock, or session updates. Accordingly, set the interval to 60 seconds instead of deregistering the script, so real-time features survive while load falls.

Is the WordPress Heartbeat the same thing as WP-Cron?

No, and confusing the two leads to the wrong fix. Whereas WP-Cron runs scheduled server tasks on page load, the Heartbeat is a browser-to-server poll that only runs while an admin tab is open. Disabling one does nothing to the other.

Will my WordPress 7.0 dashboard on AHosting be faster if I disable WordPress Heartbeat?

Often yes, because a sluggish WordPress 7.0 dashboard is frequently a Heartbeat storm from several open editor tabs rather than a slow server. After you disable the WordPress Heartbeat on the front end and throttle the editor, admin-ajax.php pressure drops and the dashboard feels lighter.

July 15, 2026

Is WP-Cron Actually Slowing Your Site?

Why We Measured WP-Cron Instead of Just Telling You to Disable WP-Cron It
What an Empty WP-Cron Check Actually Costs: 18 Milliseconds
- The Three Numbers: 18 ms vs 475 ms vs 1,540 ms
- Why wp-cron.php Returns Zero Bytes (And Why That Is Healthy)
The Audit: 26 WordPress Installs, 676 Scheduled Events, Zero Overdue
- Not One Site Had Disabled WP-Cron
- What 26 Events Per Install Tells You About Plugin Bloat
When You Should Disable WP-Cron: The Four Conditions
How to Disable WP-Cron the Right Way: The cPanel Walkthrough
WP-Cron vs Server Cron on CloudLinux: The Entry Process Difference
The Disable WP-Cron Decision Checker
A Practical Checklist: Should You Disable WP-Cron?
Frequently Asked Questions: Disabling WP-Cron

TL;DR

We measured before telling anyone to disable wp-cron. An empty WP-Cron check costs 18 ms, just 1.17% of an uncached page load. On 100% of the WordPress installs we audited, the default was fine.

Every guide telling you to disable wp-cron makes the same claim: WordPress fires its pseudo-cron on every page load, and that overhead is dragging your site down. Notably, none of them publishes a number. Therefore we measured it on our own production hardware, and the result reframes the entire recommendation.

Specifically, an empty WP-Cron check costs 18 milliseconds. On the same account, an uncached WordPress page load costs 1,540 milliseconds. In other words, the thing everyone tells you to remove accounts for roughly one percent of the request it rides along inside.

Why We Measured WP-Cron Instead of Just Telling You to Disable WP-Cron It

The advice to disable wp-cron is repeated almost universally, and it is repeated without evidence. Specifically, we searched the top-ranking pages for this topic and found the same assertion on every one of them, with no supporting measurement on any of them. Consequently, site owners disable a core WordPress subsystem on the strength of an unverified claim, and a meaningful share of them break their scheduled tasks in the process.

Furthermore, we are in an unusual position to check. We run the servers. Therefore, rather than repeat the claim, we audited every WordPress installation on one of our shared hosting servers and timed the operations directly. In practice, that turns a talking point into a measurement, and the measurement disagrees with the talking point.

What an Empty WP-Cron Check Actually Costs: 18 Milliseconds

An empty WP-Cron check costs 18 milliseconds on AHosting’s LiteSpeed stack. Specifically, that is the time for PHP to boot WordPress, read the scheduled event queue, find nothing due, and exit. Consequently, when people describe WP-Cron as a performance drain, this 18 millisecond operation is the drain they are describing.

The Three Numbers: 18 ms vs 475 ms vs 1,540 ms

Context turns that 18 milliseconds from a number into an argument. Specifically, we timed three operations on the same WordPress account, on the same server, within the same minute. In contrast to the assumption behind the standard advice, the cron check is the cheapest thing on the list by a wide margin.

Operation (measured on AHosting sh193, July 14, 2026)	Cost	Relative to the cron check
Empty `wp-cron.php` check (PHP boots, no jobs due)	18 ms	1x (baseline)
Same WordPress boot via WP-CLI	475 ms	26x
Uncached homepage load, same account	1,540 ms	86x

The AHosting WP-Cron Cost Table. The WP-Cron check represents 1.17% of an uncached WordPress page load.

Therefore the conclusion writes itself. If an uncached page load takes 1,540 milliseconds and the WP-Cron check inside it takes 18, then removing WP-Cron addresses 1.17 percent of the problem while leaving 98.83 percent untouched. Ultimately, if your WordPress site feels slow, WP-Cron is not why. Your caching layer is why, and our guide to server-level LiteSpeed caching for WordPress addresses the other 98.83 percent.

Why wp-cron.php Returns Zero Bytes (And Why That Is Healthy)

A healthy wp-cron.php request returns HTTP 200 with an empty response body. Specifically, WordPress executes any due jobs and then terminates without printing anything, so zero bytes is the signature of success rather than a symptom of failure. Notably, this trips up a lot of troubleshooting, because an empty response looks broken to anyone expecting output.

Furthermore, you can confirm PHP genuinely ran by inspecting the response headers. In practice, WordPress emits its own no-cache headers on this endpoint, including a deliberately absurd expiry date set in 1984. As a result, if you see that header, PHP executed. If you see a cache header instead, your request never reached WordPress at all and any timing you take from it is meaningless.

Notably, the reason the check is this cheap is architectural. Specifically, WordPress fires the cron request as a non-blocking loopback with a 0.01 second timeout, so the visitor’s page load never waits for the cron work to finish. In fact, WordPress core contributors debated raising that timeout for seventeen years before closing the ticket, precisely because the fire-and-forget design is the thing keeping the cost off your page load.

The Audit: 26 WordPress Installs, 676 Scheduled Events, Zero Overdue

On July 14, 2026 we audited every WordPress installation on one AHosting shared hosting server. Specifically, this was a census rather than a sample: 26 installations, all of them, with no selection applied. Consequently the percentages below describe the whole population on that machine, not an estimate drawn from part of it.

Not One Site Had Disabled WP-Cron

100 percent of the WordPress installations were running WP-Cron in its default configuration. Specifically, 0 percent had DISABLE_WP_CRON set in wp-config.php, and 0 percent had a replacement server cron of any kind. Therefore, despite the advice being one of the most widely repeated optimizations in WordPress, adoption on a real shared server was nil.

AHosting sh193 WP-Cron Census (all installs, July 14, 2026)	Count	Percent of total
WordPress installations audited	26	100%
Running default WP-Cron	26	100%
With `DISABLE_WP_CRON` set	0	0%
With a replacement server cron	0	0%
Serving no reachable frontend	10	38.5%
Scheduled events across all installs	676	avg 26 per install
Events overdue	0	0%

The AHosting WP-Cron Census. Every WordPress install on one shared server, audited in full.

Notably, the overdue figure is the one that matters. Specifically, across 676 scheduled events on 26 sites, 0 percent were overdue. In other words, the failure mode that the entire disable-wp-cron recommendation exists to prevent was not occurring on any site we examined. As a result, the default configuration was doing its job on 100 percent of the population.

Furthermore, 38.5 percent of these installations were serving no reachable frontend at all, and even those had zero overdue events. In practice, that is the strongest possible test of the traffic-dependency argument, because these are the sites that should have been starved of the page loads WP-Cron depends on. They were not.

What 26 Events Per Install Tells You About Plugin Bloat

The average WordPress installation on the server carried 26 scheduled events. Specifically, a clean WordPress core install schedules roughly a dozen, so the remainder arrives with plugins. Consequently, the size of your cron queue is a reasonable proxy for how much background work your plugin stack has quietly signed you up for.

Therefore the queue length is worth checking even if you never disable wp-cron. In practice, an install carrying 40 or more events is usually running duplicate scheduling from a misbehaving plugin, and the WordPress Plugin Handbook warns that calling wp_schedule_event on every page load can register the same task thousands of times.

When You Should Disable WP-Cron: The Four Conditions

You should disable wp-cron when at least one of four specific conditions applies to your site. Notably, none of them is “your site feels slow,” because we have now measured that the cron check contributes 1.17 percent of a page load. In contrast, each condition below describes a real failure that the default configuration genuinely cannot handle.

Condition One: Your Scheduled Jobs Are Time-Critical

Disable wp-cron when a job must run at a specific time rather than eventually. Specifically, WP-Cron has no clock of its own; it inherits the timing of your traffic. Consequently a backup scheduled for 3:00 AM on a site with no overnight visitors runs whenever the first morning visitor arrives, which may be 7:00 AM. In practice, if the difference between 3:00 AM and 7:00 AM matters to you, that is a reliability requirement and only a server cron satisfies it.

Condition Two: Low Traffic Plus a Deadline

Disable wp-cron when your site has genuinely sparse traffic and something depends on a schedule. Specifically, this is the classic case the WordPress Plugin Handbook’s cron documentation describes: schedule a task for 2:00 PM, receive no page loads until 5:00 PM, and the task runs three hours late. Notably, our audit found zero overdue events even on sites with no reachable frontend, so this failure is less common than assumed, but it is real when it happens.

Condition Three: A Heavy Queue, Not a Long One

Disable wp-cron when your queue contains expensive jobs rather than merely numerous ones. Specifically, our 18 millisecond measurement is the cost of checking an empty queue, and that figure rises with the work actually due. Therefore a WooCommerce store draining a large Action Scheduler backlog is a genuinely different case from a blog with 26 idle events, and our WooCommerce-optimized hosting plans allocate 25 entry processes precisely because checkout and queue work compete for the same pool.

Condition Four: You Are Near Your Entry Process Ceiling

Disable wp-cron when you are already close to your concurrency limit, because every cron run occupies a worker that a visitor could be using. Specifically, on CloudLinux each PHP request consumes one entry process, and CloudLinux’s resource limit documentation explains that exceeding the ceiling queues or rejects requests. Consequently, if you are already seeing 508 resource limit errors during traffic spikes, cron work is competing with real visitors and moving it to WP-CLI removes it from the pool entirely.

How to Disable WP-Cron the Right Way: The cPanel Walkthrough

Build the replacement cron first, then disable the page-load trigger. Specifically, doing it in the reverse order leaves a window in which no scheduled task runs at all, and because WordPress reports no error during that window, sites have sat with silently dead cron queues for months. Therefore the ordering below is deliberate.

First Step: Create the Server Cron in cPanel

Open cPanel, find Cron Jobs under the Advanced section, and add a new job. Specifically, set the interval to every 15 minutes for a standard site, or every 5 minutes for a WooCommerce store. Furthermore, AHosting exposes full cron control on every managed WordPress hosting plan and on standard cPanel web hosting accounts, so this requires no support ticket and no shell access.

# Every 15 minutes - standard WordPress site (recommended)
*/15 * * * * /usr/local/bin/wp cron event run --due-now --path=/home/USERNAME/public_html >/dev/null 2>&1

# Every 5 minutes - WooCommerce or time-critical jobs
*/5 * * * * /usr/local/bin/wp cron event run --due-now --path=/home/USERNAME/public_html >/dev/null 2>&1

Second Step: Add DISABLE_WP_CRON to wp-config.php to Disable WP-Cron

Open wp-config.php and add a single line above the “stop editing” comment. Specifically, this constant tells WordPress to skip the cron check on page loads, while still permitting wp-cron.php to be called directly by your new server cron. In practice, this is the entire code change, and it is fully reversible by deleting the line.

define( 'DISABLE_WP_CRON', true );

/* That's all, stop editing! Happy publishing. */

Third Step: Choose WP-CLI Over curl or wget

Use WP-CLI rather than curl or wget, because only WP-CLI keeps the cron run out of your visitor worker pool. Specifically, curl and wget both issue an HTTP request back to your own site, which travels through LiteSpeed and consumes one entry process exactly as a visitor would. In contrast, the WP-CLI cron event run command loads WordPress directly from the command line and never touches the web server.

Cron method	Entry processes consumed	Goes through the web server	Blocked by security layers
`curl` to wp-cron.php	1 per run	Yes	Sometimes
`wget` to wp-cron.php	1 per run	Yes	Often (sends no user agent)
WP-CLI `cron event run`	0	No	Never

The AHosting Cron Method Comparison. On a Bronze plan with 15 entry processes, one curl-triggered cron run occupies 6.7% of your concurrency ceiling.

Notably, the WordPress Plugin Handbook’s own guidance on hooking WP-Cron into the system task scheduler still demonstrates the wget approach, which is why it propagates through so much hosting documentation. Therefore, on an entry-process-metered host it is the wrong default, and the table above is the reason.

Fourth Step: Verify the Cron Actually Fired After You Disable WP-Cron

Wait one interval, then list your scheduled events and confirm nothing is overdue. Specifically, if events that were due have moved to a future run time, the server cron executed. Consequently, this single command is the difference between a working configuration and the silent failure described above.

# Nothing should show as overdue after one interval has passed
wp cron event list --fields=hook,next_run_relative --path=/home/USERNAME/public_html

WP-Cron vs Server Cron on CloudLinux: The Entry Process Difference

On CloudLinux, the real difference between WP-Cron and a server cron is which resource pool the work comes out of. Specifically, entry processes cap how many PHP requests your account can run at the same instant, and AHosting publishes those numbers by tier rather than hiding them. Therefore you can calculate the cost of a cron run against your own ceiling.

AHosting plan	Entry processes	Cost of one curl-triggered cron run	Cost of one WP-CLI cron run
WP Bronze	15	6.7% of ceiling	0%
WP Silver	25	4.0% of ceiling	0%
WooCommerce (WooStart)	25	4.0% of ceiling	0%
WP Gold	40	2.5% of ceiling	0%

The AHosting Entry Process Cron Cost Table. A WP-CLI cron run bypasses the web server and consumes no entry process on any tier.

Furthermore, this is where a genuine upgrade decision lives. In practice, if cron work and visitor traffic are competing for the same 15 workers often enough to cause errors, the answer is either to move cron off the pool with WP-CLI or to raise the pool itself. Our guide to how many PHP workers a WordPress site actually needs covers the sizing math, and a VPS plan with dedicated resources removes the ceiling from the equation entirely.

Notably, none of this changes why WP-Cron is unreliable in the first place. Specifically, that mechanism is the page-load dependency itself, which we cover in detail in our guide to why WordPress cron jobs fail on shared hosting. In contrast, this post is about whether the standard fix is worth applying to your particular site.

The Disable WP-Cron Decision Checker

Answer four questions and the checker returns a verdict. Specifically, it applies the four conditions above to your situation. In practice, most sites get told to leave WP-Cron alone, and that is the honest answer rather than an evasive one.

Should you disable WP-Cron?

Four questions. Based on the conditions measured above.

1. Do any scheduled jobs have to run at a specific time?

2. Does your site go hours at a time without visitors?

3. Do you run WooCommerce or a large Action Scheduler queue?

4. Do you see 508 or 503 errors during traffic spikes?

Answer the four questions

The checker will tell you whether disabling WP-Cron is worth it for your site, or whether the default is fine.

See AHosting WordPress plans

A Practical Checklist: Should You Disable WP-Cron?

Check the queue first. Run wp cron event list and look for overdue events. If nothing is overdue, the default is working, exactly as it was on 100% of the installs we audited.
Stop blaming cron for speed. The check costs 18 ms against a 1,540 ms uncached page load. Fix caching instead.
Build the server cron before disabling anything. Reversing the order leaves scheduled tasks silently dead.
Use WP-CLI, not curl or wget. Only WP-CLI keeps the run out of your entry process pool.
Set 15 minutes for a standard site, 5 for WooCommerce. Shorter intervals pay the WordPress boot cost for no work.
Verify after one interval. If due events have moved to a future run time, the cron fired.

Frequently Asked Questions: Disabling WP-Cron

Should I disable WP-Cron on a low-traffic WordPress site in 2026?

Typically, yes, but for reliability rather than speed. On a low-traffic site the problem is not that WP-Cron is expensive; it is that scheduled jobs wait for a visitor who may not arrive for hours. Therefore you disable WP-Cron to make timing predictable, not to reclaim performance. Our own audit found the page-load cost is roughly 1 percent of an uncached request, so if you disable WP-Cron on a quiet site, do it because your backups and scheduled posts need to fire on a clock. The four-condition test in this post tells you which reason applies to you.

What happens if I disable WP-Cron and forget to add a server cron?

Specifically, every scheduled task on the site stops running, silently and without any error message. Consequently, scheduled posts never publish, backups never run, update checks never fire, and WooCommerce emails never send. Notably, WordPress does not warn you, because from its perspective you asked it to stop. This is the single most common way a well-intentioned WP-Cron fix breaks a production site, and it is why the walkthrough in this post orders the two steps deliberately: build the server cron first, then disable the page-load trigger.

WP-Cron vs system cron: which is more reliable for scheduled posts?

Specifically, a system cron is more reliable because it runs on the server clock, while WP-Cron runs only when a visitor loads a page. As a result, a post scheduled for 2:00 AM on a site with no overnight traffic may not publish until the first morning visitor arrives. In contrast, a system cron firing every 15 minutes publishes it within 15 minutes regardless of traffic. The WordPress Plugin Handbook itself recommends the system scheduler for exactly this reason.

How much does WP-Cron actually slow down a WordPress page load?

Specifically, we measured an empty WP-Cron check at 18 milliseconds on our own production hardware, against an uncached WordPress page load of 1,540 milliseconds on the same account. Therefore the cron check accounts for roughly 1.17 percent of the request. In practice this means WP-Cron is almost never the reason a WordPress site feels slow. The AHosting WP-Cron Cost Table in this post shows all three measured figures side by side.

Does AHosting run a server cron for WordPress accounts by default?

Specifically, AHosting does not configure a server cron for you by default, and our July 2026 audit confirmed that 0 percent of the WordPress installations on the server we examined had one in place. Instead, cPanel exposes full cron job control on every WordPress and web hosting plan, so you can add one in about three minutes. The cPanel walkthrough in this post covers the exact command, including which of the three common commands to use.

WP-CLI vs curl vs wget for a WordPress server cron: which should I use?

Specifically, use WP-CLI, because it runs WordPress directly from the command line and never touches the web server. In contrast, curl and wget both make an HTTP request back to your own site, which travels through the web server and consumes one entry process from the same pool that serves your visitors. Furthermore, wget with default options sends no user agent, which some security layers reject outright. The three-method comparison table in this post breaks down the tradeoffs.

How many entry processes does a wp-cron.php request consume on AHosting?

Specifically, one. A curl or wget request to wp-cron.php passes through LiteSpeed and occupies a single entry process for the duration of the run, exactly like a visitor loading an uncached page. Consequently, on an AHosting Bronze plan with 15 entry processes, that one request represents 6.7 percent of your concurrency ceiling. Notably, a WP-CLI cron run consumes zero entry processes, because it bypasses the web server entirely.

When should I disable WP-Cron on a WooCommerce store with Action Scheduler queues?

Specifically, disable WP-Cron on a WooCommerce store as soon as Action Scheduler is regularly carrying more than a few hundred pending actions, because Action Scheduler is triggered by WP-Cron and inherits its traffic dependency. In practice, a store processing subscription renewals or abandoned-cart emails cannot afford for its queue to wait on a visitor. Furthermore, a heavy queue is the one case where the cron run itself becomes expensive, which is the third of the four conditions in this post.

Is DISABLE_WP_CRON still recommended for WordPress in 2026?

Specifically, DISABLE_WP_CRON remains the documented approach in the WordPress Plugin Handbook, but it is a reliability fix rather than a universal speed fix. Notably, our July 2026 audit found that 100 percent of the WordPress installations on the server we examined still ran the default WP-Cron, with 0 percent of their 676 scheduled events overdue. As a result, the honest answer for most sites in 2026 is that the default works, and the four-condition test in this post tells you whether yours is an exception.

What cron interval does AHosting recommend for WordPress in 2026?

Specifically, AHosting recommends a 15-minute interval for most WordPress sites and a 5-minute interval for WooCommerce stores or any site with time-critical scheduled jobs. Furthermore, intervals shorter than 5 minutes rarely help, because each run still has to boot WordPress, and on a quiet queue you are paying that boot cost for no work. The cPanel walkthrough in this post gives the exact crontab syntax for both intervals.

July 14, 2026

WordPress TTFB Too High? How to Tell If It’s Your Server (Not Your Plugins)

What WordPress TTFB Actually Measures (And What It Doesn't)
- The Part Your Server Owns vs. The Part Your Browser Owns
- Why "Reduce TTFB WordPress" Advice Usually Targets the Wrong Layer
The TTFB Split: How to Attribute Your Number Before You Fix It
How to Tell If It's Your Server (Not Your Plugins): A Diagnostic
When High WordPress TTFB Is Really a Server Problem
The Server-Side Fixes: LiteSpeed, LSAPI, Redis, and SSD
Managed Cloud vs. LiteSpeed cPanel Hosting for Low TTFB
A Practical Checklist: Is Your Hosting Built for Low WordPress TTFB?
Frequently Asked Questions: Reducing WordPress TTFB

TL;DR

To reduce TTFB WordPress owners must first split the number: compare the same URL cached versus uncached. Low cached but high uncached TTFB is a server and PHP problem, not a plugin one, and LiteSpeed with LSCache fixes it at the server layer.

To reduce TTFB WordPress site owners almost always reach for a caching plugin first, yet a high TTFB usually points at the server layer that runs before any plugin loads. Time to First Byte measures how long the browser waits for the first byte of the response, and that wait is split across three owners: the network, your host, and your application. This guide shows how to tell whether a WordPress high TTFB is coming from your server or your plugins, then walks through the server-side fixes that actually move the number.

Listen: how to split, diagnose, and fix a high WordPress TTFB at the server layer. By Matt Chrust, Director of Business Development, AHosting.

What WordPress TTFB Actually Measures (And What It Doesn’t)

Time to First Byte measures the delay between a browser sending a request and receiving the first byte of the response. Importantly, it does not measure how fast your page renders, how heavy your images are, or how many plugins you run. Those affect later metrics, but TTFB captures only the round trip up to the server producing a response, as Google’s web.dev guidance on Time to First Byte describes. That distinction matters because most WordPress high TTFB advice targets rendering and asset optimization, which cannot change a number that is already fixed before the first byte leaves the server.

The Part Your Server Owns vs. The Part Your Browser Owns

Specifically, TTFB is not one thing your host controls end to end. It contains network segments the browser and DNS resolve, and it contains a server segment where your host builds the response. In practice, DNS lookup, TCP connection, and TLS negotiation happen before your server does any WordPress work, while the server wait time reflects PHP execution, database queries, and whether the request was served from cache, a split the MDN definition of Time to First Byte lays out clearly. Separating these two zones is the entire diagnostic: the network zone is rarely your host’s fault, and the server zone rarely has anything to do with your plugins.

Why “Reduce TTFB WordPress” Advice Usually Targets the Wrong Layer

Notably, the highest-ranking guides on this topic are written by caching-plugin vendors and managed-cloud hosts, so their advice bends toward their product. As a result, a reader with a genuine server bottleneck is told to install another plugin, defer JavaScript, or buy a CDN, none of which touches the server wait time that is actually high. By contrast, this guide starts from measurement and attribution, so the fix you reach for matches the segment that is actually slow. For a broader view of the infrastructure involved, our breakdown of the server-side factors no plugin can fix maps where each bottleneck lives.

The TTFB Split: How to Attribute Your Number Before You Fix It

The TTFB Split is a simple attribution method: break one measured TTFB into three segments and assign each to its owner before spending any effort on a fix. Fundamentally, a single 900 ms TTFB tells you nothing actionable, but the same number split into 120 ms of connection time, 40 ms of redirect, and 740 ms of server wait tells you exactly where to look. Below, each segment is defined with the tool reading you would see and the owner responsible for it.

First Segment — Redirect & Connection Time (Network/DNS)

Firstly, redirect and connection time covers DNS resolution, TCP handshake, and TLS negotiation, plus any HTTP-to-HTTPS or www redirects. Typically, this segment is owned by your DNS provider, your CDN, and your redirect configuration, not by WordPress or your plugins. Consequently, if this segment dominates, the fix is DNS performance, HTTP/2 or HTTP/3 support, and removing redirect chains, not touching a line of PHP. A well-configured host with modern protocol support keeps this segment small, but the levers here sit largely outside your application.

Second Segment — Server Wait Time (Where the Host Lives)

Secondly, server wait time is the interval between your server receiving the request and beginning to send the response, and it is the segment your host truly owns. In practice, this is where PHP boots, WordPress loads, database queries run, and the server decides whether to serve from cache. Therefore, a high server wait time on an uncached request points at PHP execution speed, database performance, and worker availability, which are hosting-stack properties. This is the segment plugin advice cannot reach, because the plugin itself runs inside this window.

Third Segment — First-Byte Delivery (Cache Hit or PHP Run)

Thirdly, first-byte delivery is decided by one question: was this request served from cache, or did it run full PHP? Specifically, a cache hit at the server layer returns in a few milliseconds because no PHP worker is involved, while a cache miss runs the entire WordPress bootstrap. On AHosting’s LiteSpeed stack, cached WordPress pages return a median TTFB of roughly 16 ms, whereas the same page uncached runs 700 ms to 1,400 ms. As such, the gap between your cached and uncached readings is the single most revealing measurement in the entire diagnostic, and it feeds directly into Largest Contentful Paint as a Core Web Vitals input.

The TTFB Attribution Table

Accordingly, the table below is the citable core of the TTFB Split. It maps each segment to its owner, the server-side fix, and the AHosting reference value, so you can match your own reading against a known-good stack.

TTFB segment	Who owns it	Server-side fix	AHosting reference
Redirect & connection (DNS/TCP/TLS)	DNS + CDN + redirect config	Fast DNS, HTTP/2 or HTTP/3, remove redirect chains	Modern protocol support at edge
Server wait (PHP + DB)	Your host’s stack	Faster PHP (LSAPI), DB isolation, adequate workers	PHP 8.4 over LSAPI, tiered EP by plan
First-byte delivery (cache hit)	Server-level cache layer	LiteSpeed + LSCache serving below PHP	~16 ms cached median
First-byte delivery (cache miss)	Your host’s stack	SSD, OPcache, Redis object cache	700–1,400 ms uncached range

How to Tell If It’s Your Server (Not Your Plugins): A Diagnostic

Fundamentally, three quick tests attribute a WordPress high TTFB to the correct layer without guesswork. Each test isolates one variable, so the result points at a single owner. Run them in order, because the first test alone resolves most cases.

First Test — Cached vs. Uncached Response on the Same URL

Firstly, request the same URL twice and compare the server wait time between a cached and an uncached response. In practice, a logged-out page hit twice should serve from cache on the second request, so a large gap between the two readings confirms that caching is doing the heavy lifting and your uncached PHP path is slow. Conversely, if both readings are similar and both are high, caching is not engaging and the server wait time is your problem regardless of which plugins are active.

Second Test — Origin TTFB Behind a CDN

Secondly, measure TTFB directly against your origin server, bypassing the CDN, to see what your host actually delivers. Notably, a CDN can report a fast edge TTFB while your origin is slow, which hides a real server problem behind cached edge responses. Therefore, comparing edge TTFB against origin TTFB tells you whether the CDN is fixing the problem or merely masking it. When origin TTFB is high, the fix belongs to your hosting stack, and no amount of edge tuning will change it.

Third Test — The Repeat-Request Consistency Check

Thirdly, request the same page several times in quick succession and watch whether TTFB stays stable or spikes. Specifically, consistent low readings indicate a healthy cache and adequate resources, while readings that swing wildly suggest worker contention, a noisy shared neighbor, or an undersized plan. As such, variability itself is a signal: a server under concurrency pressure produces inconsistent first-byte times even when a single test looks acceptable. If your readings spike under repeat requests, the issue is resource allocation, which is a hosting decision rather than a plugin setting.

When High WordPress TTFB Is Really a Server Problem

Ultimately, once the three tests point at the server zone, the useful question becomes which server-side property is responsible. Use the diagnoser below to translate your own measured TTFB and cache state into a likely cause and owner. It applies the same TTFB Split logic described above so you can sanity-check your reading before committing to a fix.

TTFB Split Diagnoser

Enter your measured server response time and cache state to attribute it to a layer. This is a directional guide, not a benchmark.

Your measured TTFB in milliseconds

Was this page served from cache?

Are you measuring through a CDN or at origin?

Owner

See the LiteSpeed stack behind low TTFB

The Server-Side Fixes: LiteSpeed, LSAPI, Redis, and SSD

Once the diagnostic attributes a WordPress high TTFB to the server zone, four stack properties do the real work of lowering it. Notably, none of them is a plugin you install; they are characteristics of the hosting platform underneath WordPress. Together they decide how fast both cached and uncached requests return.

LiteSpeed + LSCache at the Server Layer

Primarily, the largest single lever on first-byte delivery is where caching happens. Specifically, LiteSpeed Web Server with LSCache caches full pages at the server layer, so a cache hit returns before PHP ever starts and consumes zero PHP workers. As a result, AHosting’s cached WordPress responses measure a median TTFB near 16 ms, and once the LiteSpeed Cache plugin is installed from the WordPress plugin repository it activates automatically without additional server configuration. For the deeper mechanics of why server-layer caching outperforms plugin-layer caching, our guide to why server-level caching changes everything covers the full comparison.

LSAPI: Why PHP Execution Overhead Shrinks

Furthermore, cache misses still run PHP, so how efficiently PHP executes controls the uncached segment of your TTFB. In practice, LiteSpeed’s LSAPI keeps PHP processes persistent and communicates with them more efficiently than older handlers, which trims the server wait time on every uncached request. Consequently, a site that runs many logged-in or dynamic pages benefits from LSAPI even when full-page cache cannot help, because the PHP that must run, runs faster. This is why the execution layer matters as much as the cache layer for real-world TTFB.

Redis Object Caching for Uncached, Logged-In Requests

Additionally, Redis object caching attacks the part of server wait time that full-page cache never reaches. Specifically, it stores the results of repeated database queries in memory, so logged-in dashboards, membership pages, and WooCommerce carts spend less time waiting on the database. As a result, the uncached segment of TTFB drops on exactly the pages that matter most for dynamic sites. The Redis Object Cache plugin connects WordPress to a Redis instance, and pairing it with adequate PHP workers produces the full effect. For a store that runs constant uncached checkout traffic, this combination often decides whether shared hosting still fits or a move to VPS hosting with guaranteed workers is due.

Managed Cloud vs. LiteSpeed cPanel Hosting for Low TTFB

Consequently, the common advice to “just move to managed cloud” for TTFB deserves scrutiny, because the server-layer mechanics that lower first-byte times are available on LiteSpeed cPanel hosting too. The comparison below sets the two approaches side by side on the factors that actually drive TTFB rather than on brand positioning.

TTFB factor	Managed cloud (plugin-cache model)	LiteSpeed cPanel (AHosting)
Full-page cache location	Often above PHP or at an edge tier	Server layer, below PHP (LSCache)
Cached TTFB	Varies by tier and region	~16 ms measured median
PHP execution handler	Varies; often PHP-FPM	LSAPI, persistent processes
Object cache for uncached pages	Add-on or higher tier	Redis available
Dedicated IP	Usually paid add-on	Included on every plan
Cost model	Premium managed pricing	Standard cPanel pricing

By contrast, when a site genuinely outgrows shared concurrency, the honest answer is not always another plugin or a pricier managed plan. Instead, moving to a dedicated server with isolated resources removes the noisy-neighbor variability that makes shared TTFB inconsistent. The right destination depends on whether your bottleneck is cache configuration or raw concurrent load, which the diagnostic above is designed to reveal.

A Practical Checklist: Is Your Hosting Built for Low WordPress TTFB?

Finally, use this checklist to judge whether your hosting stack is built to keep first-byte times low. Each item maps to a segment of the TTFB Split, so a gap here predicts exactly where your number will climb.

Server-level full-page caching that serves below PHP, not a plugin that runs inside a worker.
A modern PHP handler such as LSAPI that keeps execution overhead low on cache misses.
Current PHP, ideally 8.3 or 8.4 in line with the WordPress server requirements, since older versions run slower and raise server wait time.
Redis object caching available for logged-in, membership, and WooCommerce pages that skip full-page cache.
SSD storage so database and file reads do not become the bottleneck on uncached requests.
Adequate PHP workers for your concurrency, so TTFB stays stable under repeat requests instead of spiking.
A dedicated IP and account isolation so a noisy neighbor cannot inflate your server wait time.

Together, these seven properties determine whether your host helps or hurts your first-byte time. If your current plan is missing several of them, the fastest path to a lower number is a stack change rather than another optimization plugin. AHosting builds all seven into every managed WordPress hosting plan, which is why cached responses land near 16 ms without customer configuration. When even that is not enough because uncached concurrency stays high, our guide to the signs your site has outgrown shared hosting covers the upgrade decision in detail.

Frequently Asked Questions: Reducing WordPress TTFB

How do I tell if high WordPress TTFB is my server or my plugins in 2026?

Specifically, request the same URL cached and uncached and compare the wait time. If cached TTFB is low but uncached TTFB is high, the delay lives in PHP execution and your host’s stack, not your browser or plugins. In contrast, if even cached responses are slow, the delay is network or connection related. The TTFB Attribution Table in this guide maps each segment to its owner.

What is a good TTFB for a WordPress site in 2026, and what number signals a server problem?

Generally, a served-from-cache TTFB under about 200 ms is healthy, and under 100 ms is excellent. On AHosting’s LiteSpeed stack, cached WordPress responses measure a median of roughly 16 ms. By contrast, an uncached WordPress request on the same server runs 700 ms to 1,400 ms, so a consistently high TTFB across cached pages points at the server layer rather than a plugin.

Why does my WordPress high TTFB stay high after I install a caching plugin?

Typically, a caching plugin only helps once a page is actually cached and served from cache. First-visit, logged-in, cart, and AJAX requests still run full PHP, so if those uncached paths are slow the plugin cannot mask it. Moreover, on Apache-based hosts the plugin itself runs inside a PHP worker, adding overhead a server-level cache avoids entirely.

How does AHosting’s LiteSpeed with LSCache reduce WordPress TTFB compared to Apache plus a plugin?

Notably, LSCache runs at the LiteSpeed server layer, serving cached pages before PHP starts and consuming zero PHP workers. As a result, cached responses on AHosting measure around 16 ms. In contrast, an Apache host caching above PHP must boot a worker for every hit, which raises both TTFB and concurrency pressure under load.

Does a CDN like Cloudflare fix WordPress high TTFB, or does it hide the real problem?

In practice, a CDN improves TTFB only for cacheable, edge-served requests, and it can mask a slow origin rather than fix it. Ultimately, cache-miss and dynamic requests still fall back to your origin server, so if the origin is slow the CDN merely delays the diagnosis. Test origin TTFB directly to separate the edge from the host, as this guide’s diagnostic explains.

When should I upgrade from shared hosting to VPS to reduce TTFB for a WordPress store with heavy uncached checkout traffic?

Ultimately, upgrade when your uncached TTFB stays above roughly 600 ms during real concurrency and cache cannot cover logged-in or checkout requests. Because carts and account pages bypass full-page cache by design, a store that runs many concurrent uncached requests benefits from the guaranteed workers and memory a VPS provides. The diagnostic in this post shows how to confirm the bottleneck first.

What is the TTFB Split and how does it help diagnose WordPress high TTFB?

Specifically, the TTFB Split is this guide’s method for breaking one TTFB number into three attributable segments: redirect and connection time (network), server wait time (host and PHP), and first-byte delivery (cache hit or PHP run). By attributing each segment to its owner, you learn whether to reduce TTFB WordPress problems at the network, the host, or the application layer instead of guessing.

Can Redis object caching on AHosting reduce WordPress TTFB on pages that never hit the full-page cache?

Yes. Redis object caching stores repeated database query results in memory, which cuts server wait time on uncached, logged-in, and dynamic requests that full-page cache cannot serve. Consequently, membership sites, dashboards, and WooCommerce carts see lower server-side TTFB even though those pages run PHP on every request. Pair it with adequate PHP workers for the full effect.

Is TTFB a Google ranking factor for WordPress sites in 2026?

Indirectly, yes. TTFB is not a named ranking factor, but it feeds directly into Largest Contentful Paint, a Core Web Vitals metric Google uses, so a high server response time drags down the scores that do influence ranking. Furthermore, slow first-byte times reduce crawl efficiency and hurt the AI-search retrieval that increasingly shapes visibility.

How does AHosting keep WordPress TTFB low without asking customers to configure a caching plugin?

Fundamentally, AHosting runs LiteSpeed Web Server, so full-page caching activates at the server layer and pairs with SSD storage and PHP 8.4 over LSAPI for fast execution. Because the cache lives below PHP, cached WordPress pages return in roughly 16 ms whether or not a plugin is configured. The practical checklist near the end of this guide lists every server-side factor that keeps first-byte times low.

July 10, 2026

Category: WordPress

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

Method One: Selective Table Push

Method Two: Files-Only Push With an Options Diff

Method Three: Full Push Behind a Maintenance Window

How to Push WordPress Staging to Live in Seven Steps

First Step: Measure the Overwrite Window and Back Up Production

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

Third Step: Run a Serialization-Safe URL Replace

Fourth Step: Push Files First, Tables Second

Fifth Step: Reconcile Order and User Counts

Sixth Step: Flush Caches and Regenerate Permalinks

Seventh Step: Watch the Error Log Before You Walk Away

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

Build Your Push Exclusion List

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

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

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

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

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

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

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

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

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

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

Does AHosting include staging on every WordPress plan, and what PHP memory does the push need in 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

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

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

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

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

First Step: Record What You Are Running Now

Second Step: Switch on Staging Before Production

Third Step: Select the Version and Apply

Fourth Step: Re-Check the Directives That Just Changed

Fifth Step: Verify the Switch Took Effect

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

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

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

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

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

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

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

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

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

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

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

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

Gate One — Can WordPress Blame a Plugin or Theme?

Gate Two — Did It Break on a Protected Endpoint?

Gate Three — Did the Handler Itself Survive?

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

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

The Memory Ceiling You Cannot Edit Your Way Past