Author: Matt Chrust

Matt Chrust

Director of Business Development, AHosting Matt has led business development at AHosting since the company’s founding in 2002. He writes about WordPress hosting infrastructure, server performance, and the evolving requirements of WordPress sites at scale.

Hosting Uptime and Support: How to Verify the Claims (2026)

Why Hosting Uptime and Support Claims Need Independent Verification
- The Three-Document Problem
- What a Product Page Badge Legally Commits a Host To
Audit Step One: Find the Measurement Clause in the Hosting Uptime and Support Terms
- Who Holds the Stopwatch
- What Counts as Down, and What Quietly Does Not
Audit Step Two: Decode the Credit Schedule and the Claim Window
- Why the Claim Window Costs Buyers More Than the Percentage Does
- The Second Availability Clock Most Buyers Never Find
Audit Step Three: The Hosting Uptime and Support Response Test
Audit Step Four: Stop Trusting the Status Page for Hosting Uptime and Support
How AHosting Reads Against This Hosting Uptime and Support Audit
The 10-Minute Hosting Uptime and Support Audit Checklist
Frequently Asked Questions About Hosting Uptime and Support

TL;DR

Verify hosting uptime and support claims yourself: read the measurement clause, decode the credit schedule and claim window, then time a pre-sales technical reply. Marketing badges are not contracts.

Every provider advertises excellent hosting uptime and support. The claims are near-identical across the market, which makes them useless as a comparison signal and leaves buyers choosing on price. There is a better method, and it takes ten minutes: stop reading the marketing page and audit the documents underneath it.

Listen: the four-step audit that separates a collectible uptime guarantee from a decorative one. By Matt Chrust, Director of Business Development, AHosting.

This is an audit procedure rather than a ranking, and it applies to any provider including this one. For the arithmetic on what a given percentage costs in minutes per year, see our breakdown of what a 99.9% uptime SLA actually delivers. This guide covers whether that number is worth anything at all.

Why Hosting Uptime and Support Claims Need Independent Verification

Advertised availability and advertised responsiveness are objective claims, not opinions, which means they are supposed to rest on evidence the advertiser already holds. The verification problem is not that providers lie. It is that the badge, the contract and the remedy live in three separate documents, and almost nobody reads past the first one.

The Three-Document Problem

Availability commitments are split across a product page, a terms of service clause and a service level agreement. Notably, each layer carries a different trigger, a different deadline and a different channel for making a claim. The badge sets an expectation, the terms of service defines what counts as an outage, and the service level agreement decides what you actually receive when one happens.

That split is why two providers advertising identical hosting uptime and support figures can offer wildly different protection. One measures a single reachability probe from its own network; another measures application response from several regions. Furthermore, one pays automatically while the other requires a written claim inside a window most customers miss.

What a Product Page Badge Legally Commits a Host To

On its own, very little. A badge is an expectation, and the enforceable version of it lives further down the stack. The distinction is standard engineering vocabulary rather than legal hairsplitting: Google’s site reliability engineering handbook frames an objective as a target and an agreement as a target with a defined consequence attached. Ask what happens when the number is missed, and if the honest answer is nothing, you were reading a target.

That said, the badge is not meaningless. Under the FTC policy statement on advertising substantiation, an advertiser making an objective claim is expected to hold a reasonable basis for it before publishing. So the badge is a legitimate thing to ask questions about. It is simply the beginning of the audit rather than the end of it.

Audit Step One: Find the Measurement Clause in the Hosting Uptime and Support Terms

Open the service level agreement and find the sentence that defines what is being measured and by whom. In practice this single clause determines more than the headline percentage does, because it decides which of your outages are even eligible to be counted.

Who Holds the Stopwatch

Most agreements state that availability is determined by the provider’s own monitoring agents rather than any individual customer’s experience. That wording is defensible, since a customer’s ISP or a routing fault can make a healthy server look unreachable. It also means your own monitor is evidence rather than proof.

Accordingly, ask in writing where the monitoring agents sit, how often they probe, and how many consecutive failures constitute an outage. A precise answer tells you the measurement is real. Silence is also an answer.

What Counts as Down, and What Quietly Does Not

Most hosting agreements measure network connectivity for HTTP access. Therefore a request that completes is a success by that definition, regardless of what the page contains. The HTTP semantics specification, RFC 9110 is explicit that a successful status code reports on the request, not on whether your application produced anything a customer would recognize as working.

The practical gap is large. A WordPress site returning a database connection error, a blank page, or a checkout that times out after thirty seconds may still be answering requests. Similarly, PHP worker exhaustion under load produces the queued 503 responses covered in our PHP worker guide that never appear as downtime in a connectivity-based measurement. Grade the definition, not the number in front of it.

Then read the exclusion list, which is where most claims quietly die. Standard exclusions cover scheduled maintenance, customer-side configuration, third-party software, and events outside the provider’s control including DNS propagation and upstream network faults. Consequently the honest way to read a schedule is to assume anything you caused, anything announced in advance, and anything upstream is uncounted.

Audit Step Two: Decode the Credit Schedule and the Claim Window

A credit schedule converts a missed target into money. Six clauses decide whether that conversion is realistic or theatrical, and every one of them has a published answer somewhere in a reputable provider’s documents. Below is the table to run any provider through.

#	Clause to extract	Where it lives	The disqualifying answer
1	Measurement basis	SLA, service level section	No definition of what is measured
2	Who monitors	SLA, limitations section	Unstated, or “at our discretion”
3	Credit tiers and percentages	SLA, credits section	Credit amount decided case by case
4	Claim window and channel	SLA or terms of service	No deadline published anywhere
5	Exclusion list	SLA, restrictions section	Open-ended “including but not limited to” with no examples
6	Measured support response time	Product page or support policy	Availability hours with no number attached

The Hosting SLA Audit Table – six clauses to extract from any provider before purchase, with the answer that should end the evaluation.

Why the Claim Window Costs Buyers More Than the Percentage Does

Credit percentages cluster in a narrow range across the industry, so they rarely separate providers. Deadlines do. A window measured in business days runs from the outage itself, not from the moment you notice it, so a Friday evening incident found the following Tuesday has already burned much of the time available.

For example, AHosting publishes a three-tier schedule paying 10 percent of the affected month between 95 and 99.4 percent, 25 percent between 90 and 94.9 percent, and 50 percent at or below 89.9 percent, with claims filed by support ticket inside seven business days and credits applied within sixty days. Those figures appear in the published service level agreement, which is exactly where they should be findable without a phone call.

The Second Availability Clock Most Buyers Never Find

One further trap catches buyers of higher-tier products. A provider can run more than one availability clock, each with its own deadline and its own submission channel, and hosting uptime and support terms rarely cross-reference them.

Dimension	Network availability clock	Hardware replacement clock
What it covers	HTTP reachability across the network	Physical component failure on a dedicated machine
Commitment	99.9% network uptime per calendar month	Replacement within 1 to 8 hours of confirmation
Credit curve	Three tiers: 10%, 25%, 50%	5% per additional 8-hour block, up to 100%
Claim window	Seven business days	Ten days
Where to file	Support ticket	Email to the sales address
Review hours	Standard ticket handling	Monday to Friday, 9am to 5pm EST

The AHosting Two-Clock Table – the network and hardware availability commitments differ in trigger, credit curve, deadline and filing channel.

Both clocks are published, one in the service level agreement and one in the terms of service. Ultimately the lesson generalizes to every provider you evaluate: if you buy a dedicated server, confirm which clock covers your failure mode before you need it, because filing against the wrong one wastes the window.

Audit Step Three: The Hosting Uptime and Support Response Test

Support is the half of the equation with no contract behind it at almost every provider, which makes it the half you must test yourself. Fortunately the protocol is cheap and runs before you spend anything.

The Pre-Sales Timing Test

Open a pre-sales conversation with a specific technical question rather than a pricing question, because pricing routes to sales and tells you nothing about the technical queue. Time the first substantive reply, not the automated acknowledgement.

Ask something concrete: which PHP versions are selectable, what the container memory ceiling is, whether staging pushes to production.
Run the test twice, once inside business hours and once after midnight in the provider’s stated timezone.
Record the gap between your message and the first human answer that contains information.
Compare that gap against whatever response figure the provider advertises.

Notably, a provider that publishes a measured figure has already accepted the comparison. AHosting states an average first response of two to five minutes across every hosting package, which is a number you can hold it to. Providers advertising only coverage hours have published nothing testable, and that distinction is worth more than any review score.

The Tier 1 Diagnostic Question

One question separates support organizations: can the first person who answers read your server error logs? A tier that reads logs resolves incidents. A tier that cannot merely records them and forwards a ticket into a queue, turning a fifteen-minute problem into an overnight one.

Service management practice treats this as a design decision rather than an accident. The international service management standard ISO/IEC 20000-1 requires providers to define service levels with measurable targets and to report against them, which is precisely the discipline missing wherever a support tier exists only to triage. Ask the question during the pre-sales test and note the answer verbatim.

Understand the capability ladder before asking. First-touch technicians who read error logs, inspect resource faults and restart a PHP handler cover most real incidents. Work needing kernel-level access belongs on a VPS plan where you hold root, and that boundary should be stated rather than discovered.

Which Channel Creates a Record You Can Cite Later

Chat and tickets serve different purposes and only one of them produces evidence. A ticket carries a timestamp, a persistent thread and a reference number you can quote inside a credit claim. Chat transcripts are frequently not retained in any form the customer controls, so a chat-only exchange about a billable outage leaves you arguing from memory.

In practice the workflow that survives a real incident is simple: use chat for triage, and open a ticket the moment an outage looks like it might cross a credit threshold. Where chat runs through a support portal, ask whether the transcript attaches to your account afterward.

Agencies carry this problem multiplied by their client count, so standardize on ticket-first reporting across every managed site. Reconstructing outage timelines for twenty clients out of chat history is not a recoverable position.

Audit Step Four: Stop Trusting the Status Page for Hosting Uptime and Support

A status page reports what the provider measured. It is a useful signal and a poor sole source, because the basis is the provider’s own and the exclusion list has already been applied before anything is published.

Therefore run your own probe. A free external monitor such as UptimeRobot checking every five minutes from outside your network gives you an independent timeline, and the setup takes under ten minutes. Point it at a URL that exercises the database rather than a static file, so an application-layer failure registers instead of hiding behind a cached page.

How AHosting Reads Against This Hosting Uptime and Support Audit

Running a provider through its own checklist is the only honest way to publish one. AHosting commits to 99.9 percent network uptime per calendar month in its terms of service, publishes a tiered credit schedule with a seven business day claim window, and states an average first response of two to five minutes across every package.

Additionally, first-touch technicians read server error logs directly rather than escalating for a diagnostic read, and the claim channel is a support ticket that produces the timestamped record a credit request needs. Those are the six clauses from the audit table, answered in public. Every WordPress hosting plan carries the same commitments regardless of tier.

Score any provider below, including this one. The scorer is deliberately unforgiving on the clauses that decide whether a hosting uptime and support guarantee is collectible rather than decorative.

SLA Collectibility Scorer

Answer six questions from the provider’s own published documents. No answer found counts as a no.

1. Does the agreement define what is measured and how often?

2. Does it name who performs the measurement?

3. Are the credit tiers published as fixed percentages?

4. Is there a published claim deadline and filing channel?

5. Is the exclusion list itemized rather than open-ended?

6. Is a measured support response time published anywhere?

0 of 6Answer the six questions to score this provider.

Compare published hosting commitments

The 10-Minute Hosting Uptime and Support Audit Checklist

Work the list in order. Every hosting uptime and support item below resolves to a written answer, and a provider that cannot supply one has told you something useful.

Locate the service level agreement from the footer, not from a search engine result.
Read the measurement clause and write down what is measured and by whom.
Copy the credit tiers into a note, including the lowest qualifying band.
Find the claim deadline and the filing channel, then set a calendar reminder template for it.
Scan the exclusion list for open-ended language with no examples.
Check whether a second availability clock exists for your product tier.
Send a pre-sales technical question and time the first substantive reply.
Repeat the timing test outside business hours in the provider's timezone.
Ask directly whether first-touch support reads server error logs.
Point an external monitor at a database-backed URL before you migrate anything.

Run this before you buy and you will never again choose a host on a badge. If the audit fails on a provider you are already using, our guide to migrating WordPress to a new host covers the mechanics of leaving without an outage of your own making. The wider evaluation framework sits in our 12-point checklist for choosing a web hosting provider.

Frequently Asked Questions About Hosting Uptime and Support

How do you verify hosting uptime and support claims independently in 2026?

Specifically, you read three documents in order: the product page badge, the terms of service clause that defines the commitment, and the service level agreement that sets the credit schedule. Each one says something different, and only the third one is enforceable. The audit checklist near the end of this guide walks the sequence in about ten minutes.

Uptime SLA vs uptime guarantee: what is the difference in hosting uptime and support terms?

In practice, a guarantee is a marketing target with no stated consequence, while a service level agreement names a measurement method, a credit schedule and a claim deadline. Google's site reliability engineering team draws the same line: if missing the number carries no defined consequence, you are looking at an objective rather than an agreement.

What percentage credit does a 95 to 99.4 percent hosting uptime and support month actually pay?

Typically, that band pays the smallest tier on a published schedule. On AHosting's schedule it returns 10 percent of that month's service charge, rising to 25 percent between 90 and 94.9 percent, and 50 percent at or below 89.9 percent. The audit table in this guide shows why the percentage matters far less than the deadline attached to it.

What is the AHosting SLA credit schedule and how many days do I have to claim?

Notably, AHosting publishes a three-tier credit schedule paying 10, 25 or 50 percent of the affected month's service charge, and the claim must be filed by support ticket within seven business days of the outage. Credits are typically applied within sixty days, and the credit is the sole remedy.

When should I run a pre-sales hosting uptime and support response test before buying a 2026 plan?

Ultimately, run it twice before you pay: once during business hours and once after midnight in the provider's stated timezone. Send a specific technical question rather than a pricing question, because the second one routes to sales. Compare the two response times against whatever number the provider advertises.

Support ticket vs live chat: which channel creates a usable record for an SLA claim?

Indeed, the ticket wins on every SLA claim. A ticket carries a timestamp, a persistent thread and an identifier you can quote in a credit request, whereas most chat transcripts are not retained in a form the customer controls. Use chat for triage and open a ticket the moment an outage looks billable.

Can AHosting Tier 1 support read server error logs, or does that require escalation?

Fortunately, AHosting's first-touch technicians read server error logs directly rather than routing the request upward. That single capability is what separates a support tier that resolves an incident from one that merely records it, and it is worth asking every provider before you buy.

What is the three-document problem in hosting uptime and support evaluation?

Furthermore, this guide names the pattern the audit is built to defeat: availability commitments are split across a product page, a terms of service clause and a service level agreement, each with a different trigger, deadline and channel. Buyers read only the first document, then discover the other two after an outage.

Does AHosting publish an average support response time for 2026 shared hosting plans?

Moreover, AHosting publishes an average first-response time of two to five minutes across all hosting packages, alongside round-the-clock coverage. A published figure is itself the signal worth grading, because most providers advertise availability hours without ever attaching a measured number to them.

Why do buyers check Reddit for hosting uptime and support experiences instead of provider pages?

Interestingly, they are compensating for a disclosure gap rather than distrusting the provider. Peer reports fill in what the marketing page omits, which is the measurement basis, the exclusion list and the claim window. Reading the contract yourself gets you the same answers faster, and this guide's scorer grades any provider on six clauses.

August 6, 2026

Shared Hosting vs VPS Hosting for Growing Websites

Shared Hosting vs VPS Hosting: The Constraint Changes Kind, Not Size
- On Shared Hosting Your Ceiling Is Assigned
- On a VPS Your Ceiling Is Something You Configure
Shared Hosting vs VPS Hosting Factor by Factor: The Four Specifications That Differ
The AHosting Shared-to-VPS Equivalence Map
- Converting Entry Processes into PHP-FPM Children
- Why Bronze Runs Out of Memory Before It Runs Out of Workers
Shared Hosting vs VPS Hosting: What Transfers and What You Take Over
Shared Hosting vs VPS Hosting Equivalence Calculator
When the Shared Hosting vs VPS Hosting Math Says Stay Put
A Practical Checklist: Sizing Your First VPS
Frequently Asked Questions About Shared Hosting vs VPS Hosting

TL;DR

Shared hosting vs VPS hosting is not a bigger-number choice. Shared assigns you a fixed entry-process ceiling; a VPS gives you an unassigned pool you size yourself, and hands back the guardrails too.

Shared hosting vs VPS hosting is usually sold as a volume decision — more memory, more CPU, more room to grow. However, the two products do not measure capacity in the same unit. On an AHosting shared plan, concurrency is an integer the platform assigns to your account. On a KVM virtual server, no such integer exists until you create one. Consequently, comparing the two by their headline specifications answers a question nobody asked.

Listen: why a VPS upgrade buys bigger workers rather than more of them. By Matt Chrust, Director of Business Development, AHosting.

This guide does the conversion instead. Specifically, it maps AHosting’s published entry-process allocations onto its KVM virtual server tiers, shows which constraint actually binds on each side, and lists what stops being someone else’s job the moment you get root.

One caveat before the numbers. Every figure below for the shared side comes from AHosting’s own container configuration on its WordPress hosting servers, and every VPS figure comes from the published plan specifications. Neither set is an industry estimate. Consequently the conversion holds precisely for AHosting accounts and directionally for any host running CloudLinux, which is the majority of the cPanel shared market.

Shared Hosting vs VPS Hosting: The Constraint Changes Kind, Not Size

The single most useful thing to understand about shared hosting vs VPS hosting is that the ceiling is a different type of object on each side. In one case it is a number handed to you. In the other it is a number you are responsible for choosing, and choosing badly is entirely possible.

On Shared Hosting Your Ceiling Is Assigned

CloudLinux allocates every AHosting shared account a fixed count of entry processes — simultaneous PHP request slots. Bronze receives 15, Silver 25, and Gold 40, with WooCommerce plans set at 25. Notably, exceeding that count does not produce an instant error: LVE queues the surplus, and LiteSpeed holds the connection for up to 120 seconds before a 503 is served. In practice, visitors experience the ceiling as sluggishness long before they see a failure, which is why the limit is often diagnosed late. For a fuller treatment of that failure mode, see our guide to what entry process limits really mean.

On a VPS Your Ceiling Is Something You Configure

A KVM virtual server has no entry-process counter. KVM gives each instance private virtualized hardware — its own CPUs, memory, and disks — and then steps back. Therefore your concurrency ceiling becomes whatever pm.max_children you set in PHP-FPM. The PHP manual is explicit that this directive sets the limit on simultaneous requests served. Ultimately it is the same job the entry-process count performed, relocated from your host’s configuration into yours.

Shared Hosting vs VPS Hosting Factor by Factor: The Four Specifications That Differ

Four specifications genuinely change across the boundary. Interestingly, the two most heavily advertised — storage and monthly transfer — are almost never the ones that decide anything for a growing WordPress site.

Factor 1: The Concurrency Unit

On shared hosting the unit is the entry process, capped per account and invisible from inside WordPress. On a VPS the unit is the PHP-FPM child, capped by a directive in a file you own. Accordingly, the first number is a fact about your plan and the second is a decision about your server. Our breakdown of concurrent user capacity by plan tier covers how to derive the shared-side figure from real traffic.

Factor 2: The Memory Model

Shared accounts sit inside a container with a hard memory cap — 512MB on Bronze, 1024MB on Silver, 2048MB on Gold. That cap is a kernel control-group limit, and the kernel documentation describes memory.max as the final protection mechanism, invoking the out-of-memory killer when usage cannot be reduced. By contrast, VPS memory is guaranteed and unshared. Furthermore, this is the layer that surprises people most often, as our post on why raising the WordPress memory limit fails documents in detail.

Factor 3: The Privilege Boundary

Shared hosting grants configuration without administration. AHosting enables the cPanel PHP INI Editor, so raising memory_limit or switching PHP versions needs no support ticket. However, installing a system daemon, compiling an extension, or running a persistent queue worker sits on the far side of the boundary. A VPS moves that boundary: root access makes all of it possible, and equally makes all of it your responsibility.

Factor 4: The Tenancy Model

Shared accounts are neighbors under one kernel, separated by CloudLinux. Its documentation describes CageFS as a virtualized file system locking each user in a cage, with LVE partitioning CPU, memory, and connections per tenant. Consequently the noisy-neighbor problem on a well-run CloudLinux server is a contention problem, not a security one. A VPS removes contention entirely by giving you a hardware-level slice.

The AHosting Shared-to-VPS Equivalence Map

Here is the conversion nobody publishes, because it requires both datasets at once: the container limits behind a shared plan and the hardware behind a virtual server. Both are AHosting’s own numbers.

AHosting shared plan	Entry processes	Container memory	MB per saturated worker	Nearest KVM tier	vCPU / RAM	Practical child ceiling
WP Bronze	15	512 MB	34 MB	KVM-2	2 / 4 GB	~16
WP Silver	25	1024 MB	41 MB	KVM-2 to KVM-4	2-4 / 4-8 GB	~16-32
WooCommerce (WooStart)	25	1024 MB	41 MB	KVM-4	4 / 8 GB	~32
WP Gold	40	2048 MB	51 MB	KVM-4	4 / 8 GB	~32
Beyond Gold	n/a	n/a	n/a	KVM-8	8 / 16 GB	~64

The AHosting Shared-to-VPS Equivalence Map. Child ceilings assume a starting band of four to eight PHP-FPM children per vCPU; measure your own process size before committing to a value.

Read the fourth column first. It is the one figure in this comparison that no plan page on any host publishes, and it reframes what the upgrade is actually for.

Converting Entry Processes into PHP-FPM Children

Two bounds govern the VPS side, and the lower one wins. The memory bound divides usable RAM — total RAM less roughly 1.5GB for the operating system, database, and web server — by your measured average process size. The CPU bound is a heuristic band of four to eight children per vCPU, because PHP that blocks on database input and output can safely exceed its core count while CPU-bound PHP cannot. Notably, on every AHosting KVM tier the CPU bound is the lower of the two.

Why Bronze Runs Out of Memory Before It Runs Out of Workers

Now run the same arithmetic on the shared side and the symmetry inverts. Bronze allocates 15 entry processes against a 512MB container: about 34MB per worker at full saturation. Silver affords 41MB and Gold 51MB. Meanwhile AHosting sets PHP’s default memory_limit to 256MB per request. In other words, a single request is permitted roughly seven times more memory than the container can afford it if the account is busy. Therefore the entry-process number was rarely the real ceiling — the container was.

This inversion is the whole decision in one line. On shared hosting memory binds before workers; on a VPS CPU binds before memory. Consequently the upgrade does not primarily buy more concurrent requests. Instead, it buys far more memory per concurrent request — from 34MB on Bronze to well over 100MB on a KVM-2. Ultimately you get bigger workers, not a proportionally larger number of them.

Shared Hosting vs VPS Hosting: What Transfers and What You Take Over

Capacity is only half the trade. The other half is operational, and it moves in the opposite direction to the resources.

Layer	On AHosting shared hosting	On an AHosting KVM VPS
Tenant isolation (CageFS)	Running by default	Available if you select CloudLinux; you configure it
Resource capping (LVE)	Enforced per account	No equivalent unless you build one
Web server and page cache	LiteSpeed with LSCache available	Your choice of stack; you install and tune it
Kernel and OS patching	AHosting	You
PHP version management	cPanel MultiPHP, no ticket needed	You, at the package-manager level
Firewall policy	Managed at server level	You
Backups	Daily, included	Daily offsite, included
Dedicated IP	Included	Included
Uptime commitment	99.9% SLA	99.9% SLA

The AHosting Guardrail Transfer Table. Rows where the right column reads “you” are the real cost of root access.

Patching deserves particular attention, because it is the row people discover last. CISA maintains a catalog of vulnerabilities under active exploitation and recommends every organization monitor it and prioritize remediation. On shared hosting the operating-system half of that work is already being done for you. Furthermore, on a VPS it becomes a recurring task with a real cadence, not a one-time setup step.

Shared Hosting vs VPS Hosting Equivalence Calculator

Enter your current plan and your measured average PHP process size. The tool applies both bounds and reports the lower one, which is your real ceiling.

Shared-to-VPS Equivalence Calculator

Both bounds are applied. The lower one is your ceiling.

Current AHosting shared plan

Candidate KVM tier

Measured average PHP process size (MB)

Choose your plan and tier, then calculate.

Compare WordPress plan tiers

When the Shared Hosting vs VPS Hosting Math Says Stay Put

Frequently the map argues against moving. If your traffic is largely cacheable, the entry-process ceiling barely engages: LiteSpeed serves cached responses before PHP runs, consuming no worker at all, and AHosting measures roughly 16ms cached time to first byte against 700 to 1,400ms uncached on the same hardware. Accordingly, enabling LSCache can be worth more than a tier change.

Similarly, if the symptom is intermittent rather than structural, diagnose before you buy. Our companion post on the signs a WordPress site has outgrown shared hosting covers the trigger conditions in depth, and it is the better starting point if you are still establishing whether a move is warranted. Conversely, when the hypervisor layer itself becomes the constraint, a bare-metal dedicated server is the next honest step rather than a larger virtual one.

There is also a staffing question hiding inside the technical one. A virtual server is a machine somebody has to own, and the guardrail table is really a list of recurring responsibilities rather than a list of features. In practice, teams without a named person for that work tend to run a well-specified VPS worse than a modest shared plan, because an unpatched server with generous resources is a worse outcome than a constrained one that is maintained.

A Practical Checklist: Sizing Your First VPS

Work through these in order. Above all, resist provisioning first and measuring afterwards.

Measure your average PHP process resident size across a busy hour, not an idle one.
Record your current cache-bypass rate; cached traffic never touched a worker anyway.
Divide usable RAM by measured process size to get the memory bound.
Multiply vCPU by four to eight for the CPU band, and take the lower figure.
Set pm.max_children to that number, then re-measure before raising it.
Decide your operating system and control panel before migration, not during.
Schedule kernel patching as a recurring task with an owner.
Confirm your backup restore actually works, rather than that backups exist.

Frequently Asked Questions About Shared Hosting vs VPS Hosting

Shared hosting vs VPS hosting: what actually changes for a growing WordPress site in 2026?

Specifically, the unit of concurrency changes. Shared hosting assigns a fixed entry-process count that you cannot alter, while a KVM VPS has no equivalent counter at all — you set pm.max_children yourself against the vCPU and RAM you bought. Everything else, including storage and bandwidth, rarely decides the outcome. The AHosting Shared-to-VPS Equivalence Map in this guide converts one unit into the other tier by tier.

Does shared hosting vs VPS hosting change how many concurrent requests my site can serve?

Notably, not as much as most buyers expect. An upgrade raises the memory available to each concurrent request far more than it raises the number of requests, because a VPS ceiling is bounded by vCPU rather than by an assigned integer. The practical result is bigger workers, not necessarily more of them.

How many PHP-FPM children replace AHosting’s 15, 25, or 40 entry processes?

Typically, a KVM-2 sustains roughly 16 children, a KVM-4 roughly 32, and a KVM-8 roughly 64, using a starting band of four to eight children per vCPU. Consequently AHosting Bronze at 15 entry processes maps closely to a KVM-2, while Gold at 40 lands near a KVM-4 — a match on capacity, not a multiplication of it.

Why does AHosting Bronze run out of container memory before it runs out of workers?

In fact, the arithmetic is unforgiving: Bronze allocates 15 entry processes against a 512MB container cap, which affords about 34MB per worker if all fifteen run at once. Meanwhile PHP’s default memory_limit on AHosting is 256MB per request. Therefore the container ceiling, not the worker count, is what a memory-heavy plugin stack hits first.

Shared hosting vs VPS hosting vs dedicated server: which tier fits a growing site in 2026?

In practice, the tiers answer three different questions. Shared hosting suits sites whose traffic is mostly cacheable and whose stack is standard. A VPS suits sites that need root, a custom stack, or guaranteed memory per request. A dedicated server suits workloads where the hypervisor layer itself is the constraint, which is rare below sustained enterprise load.

What protections do I lose when moving from AHosting shared hosting to a KVM VPS?

In particular, the ones you never had to think about. CageFS isolation, LVE resource capping, LiteSpeed with LSCache, kernel patching, and firewall policy are all operated for you on shared plans. On a VPS every one of those becomes a decision you own. The Guardrail Transfer Table in this guide lists each item and who holds it after the move.

Shared hosting vs VPS hosting in 2026: does an upgrade automatically increase concurrency?

Ultimately, no — not by itself. A freshly provisioned VPS runs whatever PHP-FPM defaults its control panel shipped, and those defaults are frequently lower than the entry-process count you left behind. Concurrency rises only after you size the pool deliberately, which is why the migration is a configuration exercise rather than a purchase.

Is CloudLinux CageFS available on an AHosting VPS, or only on shared plans?

Fortunately, CloudLinux is one of the operating systems AHosting offers and licenses on its VPS plans, so CageFS and LVE remain available. However, availability is not configuration: on shared hosting those layers are already running, whereas on a VPS you choose the OS and then set them up. The protection is offered rather than inherited.

Shared hosting vs VPS hosting: how do I measure my average PHP process size?

First and foremost, measure before you size anything. On a running server, list the resident set size of every PHP-FPM process and take the mean across a busy period rather than an idle one. That single number divides your usable RAM into a defensible child count, and it is the input the calculator in this guide asks for.

When does shared hosting vs VPS hosting come down to root access rather than resources?

Indeed, this is the clearer of the two cases. If the blocker is a system-level daemon, a non-standard PHP extension, a custom web server module, or a queue worker that must persist between requests, no amount of shared-plan headroom resolves it. In contrast, if the blocker is simply concurrency, caching and a plan upgrade often close the gap for less effort.

August 6, 2026

Shared vs Cloud vs Dedicated Hosting: What Isolation Actually Buys You (2026)

Shared vs Cloud vs Dedicated Hosting: The Analogy and Its Limits
- The Apartment, the Serviced Building, and the Detached House
- Where the Analogy Breaks Down
Resource Isolation Is the Real Dividing Line in Shared vs Cloud vs Dedicated Hosting
Cloud Is a Deployment Model, Not a Performance Tier
The AHosting Isolation Ladder: Shared vs Cloud vs Dedicated Hosting Across Six Axes
Failure Blast Radius: What Breaks, and Who Notices
What Support Tickets Reveal About Shared Hosting Isolation
How Billing Differs Across Shared vs Cloud vs Dedicated Hosting
Choosing Between Shared vs Cloud vs Dedicated Hosting: The Isolation Matcher
A Practical Checklist: Which Tier Does Your Site Need in 2026?
Frequently Asked Questions About Shared vs Cloud vs Dedicated Hosting

TL;DR

Choosing between shared vs cloud vs dedicated hosting is a resource isolation decision, not a speed decision. Each tier draws its boundary in a different place, and that boundary decides what a bad neighbor can do to you.

Comparing shared vs cloud vs dedicated hosting usually turns into a speed contest, and that framing is wrong. All three tiers can serve a page in under 100 milliseconds on modern hardware. What actually separates them is where the isolation boundary sits and what that boundary prevents when the account next door misbehaves.

Listen: what each hosting tier actually contains, and the six axes that decide between them. By Matt Chrust, Director of Business Development, AHosting.

This guide starts with the analogy everyone reaches for, then immediately goes past it into the mechanisms — kernel namespaces, control groups, hypervisors, and bare metal — because the analogy is where most published comparisons of shared vs cloud vs dedicated hosting stop.

Shared vs Cloud vs Dedicated Hosting: The Analogy and Its Limits

The Apartment, the Serviced Building, and the Detached House

Shared hosting is an apartment. You have your own locked unit, but the plumbing, the electrical supply, and the elevator are common property, and a neighbor running a workshop in their living room affects the whole floor. Cloud and VPS hosting is a serviced building where each unit has its own metered supply and its own boiler, so a neighbor can be as demanding as they like without touching your water pressure. Dedicated hosting is a detached house on its own lot: nothing arrives or leaves except through infrastructure you control.

Where the Analogy Breaks Down

However, the property metaphor misleads in two specific ways. First, it implies the detached house is automatically faster, which is false — an empty house with old wiring performs worse than a well-run apartment. Second, it hides the maintenance transfer. Moving up a tier does not only buy separation; it moves responsibility for patching, monitoring, and recovery onto you. That trade is the part buyers underestimate, and it is why the twelve-point checklist for choosing a hosting provider treats support model and isolation as separate criteria.

Resource Isolation Is the Real Dividing Line in Shared vs Cloud vs Dedicated Hosting

Isolation is a promise about containment: it defines what one tenant can observe, consume, and damage. Consequently, comparing tiers means comparing three different enforcement mechanisms rather than three price points.

What Isolation Actually Prevents

Isolation prevents four distinct failures, and it is worth naming them separately because no single tier addresses all four equally:

Visibility — one tenant reading another tenant’s files, environment variables, or process list.
Consumption — one tenant exhausting CPU, memory, or I/O that others need.
Escalation — a compromised account becoming a compromised server.
Contagion — one tenant’s crash or reboot interrupting everyone else.

Shared Hosting: CageFS and LVE Draw the Line Inside the Kernel

On AHosting shared plans, isolation is enforced by CloudLinux rather than by a hypervisor. CageFS gives each account a virtualized file system in which the account cannot see other users, cannot read server configuration files, and gets a restricted view of /proc that hides other processes. That closes the visibility and escalation problems. Consumption is handled separately by Lightweight Virtual Environments, which apply per-account ceilings on CPU, memory, and entry processes.

Underneath both sits ordinary Linux plumbing. Control groups meter and cap what a group of processes may consume, and the cgroup v2 memory controller is what turns an over-limit account into a contained error rather than a server-wide outage. Notably, this is why a runaway script on a neighbor account produces a 503 for that neighbor and nothing at all for you. The same mechanism is what our cPanel web hosting plans rely on.

Cloud and VPS: The Hypervisor Boundary

Virtualized hosting moves the boundary down a layer. KVM turns the Linux kernel into a hypervisor, giving every guest private virtualized hardware and an unmodified operating system of its own. Contagion drops sharply as a result: a neighbor can panic their kernel without touching yours. Additionally, you gain root, which means you can install what you like — and must now patch what you installed. Our KVM-based VPS plans sit at this boundary, and the signs a site has outgrown shared hosting guide covers the triggers in detail.

Dedicated: Physical Separation

Dedicated hardware removes the hypervisor entirely. There is no scheduling contention with other guests, no shared page cache, and no noisy-neighbor variance, which makes tail latency far more predictable than any multi-tenant tier. In exchange, the machine is a single failure domain that belongs entirely to you. Our dedicated server configurations and the Detroit peering breakdown show what that predictability is worth when network geometry matters.

Cloud Is a Deployment Model, Not a Performance Tier

The word “cloud” describes how capacity is provisioned and billed, not how fast it runs. NIST Special Publication 800-145 defines cloud computing through five essential characteristics — on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service — plus three service models and four deployment models. Read that list again: not one entry is a performance guarantee.

Therefore a cloud instance is exactly as fast as the stack someone configured on it. An entry instance running unturned Apache with a plugin cache will lose to a LiteSpeed shared account with server-level caching, and that outcome surprises people only because the marketing implies otherwise. Our server-versus-plugins TTFB diagnostic works through the measurements behind that comparison. In short, treat “cloud” as a billing and provisioning shape, then evaluate the stack separately.

The AHosting Isolation Ladder: Shared vs Cloud vs Dedicated Hosting Across Six Axes

Below is the comparison the tier decision actually turns on. Each axis is scored from AHosting’s own published plan specifications rather than from generic industry claims.

Axis	Shared (CageFS + LVE)	Cloud / VPS (KVM)	Dedicated (bare metal)
Entry cost per month	$2.79	$8.79	$96.75
Isolation mechanism	Kernel namespaces + cgroup limits	Hypervisor, private kernel per guest	Physical machine, no co-tenants
Burst capacity	Capped at the plan entry process ceiling	Guaranteed vCPU and RAM, burst within the guest	Entire machine available at all times
Scaling speed	Instant plan upgrade, no migration	Resize the instance, brief reboot	Hardware provisioning lead time
Administration burden	None — fully managed stack	Root access; you patch and monitor	Root access plus hardware lifecycle
Failure blast radius	Your account only	Your guest only	Every site on the machine

The AHosting Isolation Ladder — shared vs cloud vs dedicated hosting scored across six decision axes.

Above all, notice that cost and isolation move together while speed does not appear as an axis at all. That omission is deliberate, because on a correctly configured stack the tier is not what determines first-byte time.

Failure Blast Radius: What Breaks, and Who Notices

Blast radius is the axis buyers most often skip when weighing shared vs cloud vs dedicated hosting, and it is the one that decides how a bad day feels. The table below traces four failures through each tier.

Failure	On shared	On cloud / VPS	On dedicated
Runaway PHP script	Hits your own LVE ceiling; errors served to your visitors only	Consumes your guest’s vCPU; neighbors unaffected	Consumes the whole machine
Neighbor account compromised	CageFS blocks file and process visibility	Separate kernel; no crossover	No neighbors exist
Kernel panic	Affects every account on the node	Affects that guest only	Affects everything you host
Disk or component failure	Handled by the provider, transparently	Handled by the provider, guest migrated	Your machine is down until replaced

Failure blast radius by hosting tier — the same four failures traced through each isolation boundary.

In other words, moving up a tier narrows the radius of other people’s failures while widening the radius of your own. That symmetry is the honest reason to choose dedicated hardware, and it is the axis that reframes shared vs cloud vs dedicated hosting as a risk question rather than a performance one.

What Support Tickets Reveal About Shared Hosting Isolation

Here is a figure from our own queue rather than from a vendor datasheet. Across AHosting shared plans, “my site is slow” tickets resolve roughly fifty-fifty: about half trace to the account hitting its own entry process or memory ceiling, and about half trace to genuine contention on the node.

That split matters for the tier decision in a way averages usually hide. Half of the people who assume a noisy neighbor is punishing them are actually running into their own plan ceiling, which a tier change would fix only incidentally and expensively — a plan upgrade within shared hosting, or a caching fix, addresses it for a fraction of the cost. Meanwhile the other half have a real isolation problem that no amount of tuning inside the account will solve. Measuring which half you are in, using the method in our concurrent user capacity guide, is worth more than any generic tier recommendation.

How Billing Differs Across Shared vs Cloud vs Dedicated Hosting

Measured service is one of the five characteristics in the NIST definition, and it has a direct budgeting consequence: true cloud billing is metered, so your invoice tracks consumption rather than a fixed line item. That is genuinely useful for workloads that idle most of the month and spike hard, and genuinely dangerous for workloads that get unexpectedly popular.

By contrast, fixed-tier hosting trades elasticity for predictability. You buy a ceiling, you pay the same figure every month, and exceeding the ceiling produces an error rather than an invoice. Neither model is superior in the abstract. Agencies carrying client sites usually prefer the predictable shape, which is why our reseller hosting tier is priced that way, while a seasonal campaign site may genuinely benefit from metering. Decide which failure you would rather explain: a slow page, or a surprising bill.

Choosing Between Shared vs Cloud vs Dedicated Hosting: The Isolation Matcher

Answer five questions about containment rather than about traffic. The matcher weighs your answers against the six axes in the Isolation Ladder above.

Hosting Tier Isolation Matcher

Five containment questions. No traffic estimates required.

1. How much of your traffic bypasses the page cache?

2. Do you need to install software outside cPanel?

3. Who patches and monitors the operating system?

4. Does a compliance rule require single tenancy?

5. How predictable does tail latency need to be?

Answer all five questions to see which isolation boundary fits.

A Practical Checklist: Which Tier Does Your Site Need in 2026?

Finally, work through these six statements before settling shared vs cloud vs dedicated hosting for your own site. Each one maps to an axis in the Isolation Ladder, so a gap here tells you precisely which boundary you are missing.

My cached-to-uncached request ratio is measured rather than assumed.
The plan's entry process ceiling is known, and so is how often I reach it.
Someone specific patches the operating system next month, and I can name them.
Any contract or regulation requiring single tenancy has already been checked.
Tail latency has a target expressed as a number rather than an adjective.
When this site fails, I know exactly which other sites go down with it.

Six yes answers means the tier decision is already made for you by the evidence. Any no answer is cheaper to resolve with measurement than with an upgrade, since a managed WordPress plan and a bare-metal machine solve genuinely different problems.

Frequently Asked Questions About Shared vs Cloud vs Dedicated Hosting

What are the pros and cons of shared vs cloud vs dedicated hosting?

Specifically, shared hosting wins on cost and zero administration but shares a kernel, so your ceiling is a per-account limit rather than a private machine. Cloud and VPS hosting buy a private kernel and burst headroom at roughly three times the price, with root access you now have to maintain. Dedicated hosting removes the hypervisor entirely and gives predictable single-tenant performance, but you own every failure. The Isolation Ladder table in this guide scores all three across six axes.

Which of shared vs cloud vs dedicated hosting is right for a small business in 2026?

Typically, a brochure site, portfolio, or blog under a few thousand monthly visitors belongs on shared hosting, because the workload never approaches the per-account ceiling. A store taking regular orders, or any site with logged-in traffic that bypasses the page cache, is the point where a VPS starts earning its price. Dedicated hardware makes sense when compliance, sustained concurrency, or a hard latency target drives the decision rather than raw traffic volume.

Is cloud hosting faster than shared hosting, or is that a marketing claim?

In fact, neither label predicts speed. The NIST definition of cloud computing lists five essential characteristics, and not one of them is a performance guarantee, so a cloud instance is only as fast as the stack running on it. A well-tuned LiteSpeed shared account with server-level caching routinely returns pages faster than an untuned cloud instance running Apache. Judge the stack, not the deployment model.

What does CloudLinux CageFS isolate on AHosting shared hosting that a hypervisor does not?

Notably, CageFS and a hypervisor solve overlapping problems at different layers. CageFS gives every AHosting account a private view of the filesystem and of /proc, so one account cannot read another account's files, enumerate usernames, or inspect other processes, while LVE caps what that account can consume. A hypervisor instead hands each guest a private kernel. The practical difference is that CageFS isolation is enforced without the memory and scheduling overhead a full guest operating system costs you.

When should a WooCommerce store with 500 daily orders move from shared hosting to a VPS?

In practice, order volume matters less than how much of that traffic bypasses the cache. Checkout, cart, and account pages are uncacheable by definition, so 500 daily orders concentrated into a two-hour promotional window behaves very differently from the same 500 spread evenly. Move when uncached concurrent requests regularly exceed your plan's entry process allocation, not when a round order number is reached.

How does AHosting price shared vs cloud vs dedicated hosting tiers in 2026?

Specifically, AHosting web hosting starts at $2.79 per month, VPS hosting at $8.79 per month, and dedicated servers at $96.75 per month. Furthermore, the gaps between those tiers are not linear, because each step buys a different isolation boundary rather than simply more of the same resource. Verify current figures on the product pages before budgeting, since promotional and renewal rates differ.

What is the failure blast radius in shared vs cloud vs dedicated hosting?

Ultimately, blast radius answers a single question: when something breaks, how many of your sites go with it. On shared hosting a runaway script hits your own account ceiling and returns errors to your visitors only, because LVE contains it. A kernel panic inside a VPS takes down that one guest and nothing else. Dedicated hardware behaves differently again, since a failed component takes down everything you put on that machine, which is why single-tenant performance and single-tenant risk arrive together.

If my site gets a traffic spike of 200 concurrent visitors, does cloud hosting handle it better than shared?

Interestingly, that depends entirely on whether those visitors hit cached pages. Two hundred concurrent readers of a cached article barely register on a shared plan, because cached responses never reach PHP. Two hundred concurrent logged-in users are a different workload and will exhaust a shared plan's worker allocation regardless of price. Measure your cached-to-uncached ratio before assuming the tier is the problem.

Can I move from shared to dedicated hosting on AHosting without downtime or a migration fee?

Fortunately, yes. AHosting handles cPanel-to-cPanel migrations free of charge with zero downtime, and most transfers complete in under 20 minutes. Because the control panel and the LiteSpeed stack are the same on every tier, moving up does not force you to relearn your environment or rebuild your configuration from scratch.

What changed about shared vs cloud vs dedicated hosting decisions in 2026?

Overall, the meaningful change is that the performance argument has largely collapsed. Server-level caching, kernel-enforced resource limits, and modern PHP have narrowed the gap between a tuned shared account and an entry cloud instance to the point where isolation, not speed, is the honest reason to move up a tier. Consequently, the right question in 2026 is what you need contained, not what you need to be faster.

August 5, 2026

What Does Website Hosting Cost Per Month? Real 2026 Pricing

What Does Website Hosting Cost Per Month in 2026? The Honest Bands
Why the Advertised Website Hosting Cost Per Month Is Not What You Pay
- How Introductory Pricing Actually Works
- The Renewal Multiplier Curve
The Multi-Year Prepay Trade: What 36 Months Really Buys
Calculate Your Real Website Hosting Cost Per Month
The Hidden-Cost Audit: What Gets Billed Extra
What You Are Actually Buying Is Concurrency
Cost Per Visitor: The Metric That Survives Any Price Comparison
Two Levers That Change Your Website Hosting Cost Per Month
Frequently Asked Questions About Website Hosting Cost Per Month

TL;DR

Advertised website hosting cost per month starts near $2.79, but that price requires a three-year prepayment. Standard rates run $9.79 to $13.79 on shared hosting. Billing cycle, not plan tier, drives the biggest difference.

The advertised website hosting cost per month and the amount that actually leaves your bank account are rarely the same number. Typically the gap is not a trick, and it is not hidden in the small print either. Rather, it is arithmetic that almost no hosting page performs on your behalf, because performing it makes the headline figure look less impressive.

Listen: Why the advertised hosting price and the billed price are rarely the same number. By Matt Chrust, Director of Business Development, AHosting.

This guide does that arithmetic in public, using pricing pulled directly from a live billing system rather than a marketing page. Furthermore, it draws on data from 88 active hosting accounts to show which billing choices real customers actually make. Notably, the answer to that last question turns out to be the most useful part of the whole exercise.

What Does Website Hosting Cost Per Month in 2026? The Honest Bands

Hosting divides into four practical price bands, and the boundaries between them are set by how resources are allocated rather than by how much disk space you receive. Consequently a band is a useful shorthand, but only once you know what sits behind it.

Hosting type	Typical advertised range	Typical standard rate	What you are buying
Shared / web hosting	$2 – $6 / mo	$9 – $16 / mo	A slice of a managed server, isolated by container
WordPress hosting	$2 – $8 / mo	$9 – $20 / mo	Shared resources plus staging, auto-updates and tuned caching
VPS hosting	$8 – $45 / mo	$12 – $60 / mo	Guaranteed vCPU, RAM and root access on a virtualized host
Dedicated server	$95 – $415 / mo	$129 – $450 / mo	An entire physical machine with no virtualization overhead

Table 1: 2026 hosting price bands by type. Advertised ranges assume multi-year prepayment; standard rates apply after any introductory term ends.

Interestingly, the bands overlap more than most buyers expect. Moreover, a shared plan at its standard rate can cost more per month than an entry VPS at its advertised rate, which is why comparing headline numbers across tiers produces bad decisions. In practice the useful comparison is standard rate against standard rate.

AHosting publishes both figures on every plan. For a full walk-through of how to evaluate a provider beyond price alone, our 12-point checklist for choosing a web hosting provider covers the criteria that matter before cost enters the conversation.

Why the Advertised Website Hosting Cost Per Month Is Not What You Pay

How Introductory Pricing Actually Works

Introductory hosting pricing is a discount against a standard rate, applied for the length of a committed term. Specifically, you are not buying a cheap plan; you are buying a normal plan with money off for as long as you have paid ahead. Therefore the discount expires on a known date, and the account steps up to the standard rate.

Disclosure of that step-up is governed by a patchwork rather than a single federal rule. In fact the Federal Trade Commission rule covering negative option programs that would have standardized renewal disclosure was vacated in July 2025 before it took effect, and a fresh rulemaking began in January 2026. Meanwhile the Restore Online Shoppers Confidence Act still requires sellers to disclose all material terms clearly before taking billing information, and several states impose stricter rules of their own.

Consequently the obligation to check the renewal figure sits with the buyer. Above all, it is the single number worth writing down before any hosting purchase.

The Renewal Multiplier Curve

Divide the standard rate by the advertised rate and you get a multiplier. Notably, when that calculation is run across a full product line, a pattern appears that no hosting page states outright.

Tier	Advertised	Standard rate	Renewal multiplier
Shared / WordPress Bronze	$2.79	$9.79	3.51x
Shared / WordPress Silver	$3.79	$11.79	3.11x
Shared / WordPress Gold	$4.79	$13.79	2.88x
VPS KVM-2	$8.79	$12.79	1.46x
Dedicated (Xeon E-2136)	$96.75	$129.00	1.33x

Table 2: The AHosting Renewal Multiplier Curve. Verified against live billing, August 2026. The multiplier falls as the entry price rises.

Ultimately the cheapest advertised price carries the steepest increase. Furthermore this is structural rather than deceptive: deep discounts exist to win price-sensitive buyers, and price-sensitive buyers cluster at the entry tier. Similarly, dedicated server buyers compare on specification rather than headline price, so the discount there is shallow and the step-up is mild.

The practical reading is straightforward. Specifically, the lower the advertised figure that attracted you, the more carefully you should read the renewal line beneath it.

The Multi-Year Prepay Trade: What 36 Months Really Buys

Every shared plan offers four billing cycles, and each is discounted against the same standard rate. In addition, monthly billing carries a flat $2.79 setup fee that the longer cycles waive. Running all four across an identical three-year window produces the guide’s central data asset.

Plan	Triennial (36 mo)	Biennial	Annual	Monthly	Spread
Bronze (5 sites, 15 GB)	$100.44	$196.44	$280.44	$355.23	3.54x
Silver (10 sites, 30 GB)	$136.44	$244.44	$340.44	$427.23	3.13x
Gold (20 sites, 60 GB)	$172.44	$292.44	$400.44	$499.23	2.89x

Table 3: The AHosting 36-Month True Cost Worksheet. Total paid across 36 months, including the $2.79 monthly setup fee, with every term reverting to the standard rate at expiry.

Identical hardware, identical features, identical three years. However, on Bronze the difference between the cheapest and most expensive route is $254.79, decided by a radio button at checkout.

Here is the part that makes this more than a pricing table. Across 88 active hosting accounts in the AHosting billing system, not one sits on the 36-month cycle. Annual billing is the most common choice on shared plans, monthly is close behind, and every VPS and dedicated customer pays month to month. In other words, the discount that produces the steepest renewal multiplier is one that almost nobody takes.

Calculate Your Real Website Hosting Cost Per Month

Advertised rates answer the wrong question. Instead, the number that matters is total spend across the period you will actually keep the site, divided by the months in it. Accordingly, the worksheet below performs that calculation for any tier and any billing cycle.

36-Month True Cost Worksheet

Pick a tier and a billing cycle to see what three years actually costs.

Hosting tier

Billing cycle

Months you expect to keep the site

$2.79

true cost per month over 36 months

Committed term: – Months at standard rate: – Setup fee: – Total paid: – See current WordPress plan pricing

Two behaviors emerge quickly from the worksheet. Firstly, shortening the expected lifespan of a site erodes the advantage of prepayment, because unused committed months are still paid for. Secondly, extending it beyond the committed term pushes the effective rate back toward the standard figure, since every month past expiry is billed at full price.

The Hidden-Cost Audit: What Gets Billed Extra

Line items excluded from a headline price are where hosting comparisons usually break down. Similarly, two plans at the same advertised rate can differ by several dollars a month once the extras are added. Below is what commonly attracts a separate charge, and how AHosting handles each.

Line item	Commonly billed as	Included at AHosting
SSL certificate	Free tier available, paid upgrade pushed at checkout	Included on every plan
Dedicated IP address	Add-on, roughly $2 - $5 / mo, or higher-tier only	Included on every plan
Daily backups	Add-on, or weekly on entry tiers	Daily offsite backup included
Staging environment	Higher tiers only, or unavailable	Included on every plan
Malware scanning	Security add-on subscription	Included on every plan
Site migration	One-time fee, or self-service only	Free expert migration
Private nameservers	Reseller tiers only	Included on every plan
Setup fee	Charged on short billing cycles	$2.79, monthly billing only

Table 4: Hidden-cost audit. Items commonly billed separately across the shared hosting market, compared against what AHosting bundles.

Two entries on that list deserve explanation, because both are frequently misunderstood.

SSL rarely needs to cost anything for a standard site. Indeed Let's Encrypt issues browser-trusted certificates at no charge to anyone who controls a domain, which is why a basic certificate appearing as a paid line item is worth questioning. Conversely, a dedicated IP genuinely does carry a cost, because the regional registry for North America exhausted its IPv4 free pool in September 2015 and now places approved requests on a waiting list. Addresses are consequently a scarce, traded asset rather than a free allocation, which makes bundling one a real concession rather than a marketing line.

What You Are Actually Buying Is Concurrency

Storage and bandwidth dominate hosting comparison tables because they are easy to quantify. Nevertheless neither is what fails when a site struggles. Instead, the limit almost every growing site meets first is concurrency: how many visitors the server can process at the same moment.

One entry process handles one uncached request at a time. Therefore a plan with fifteen of them can process fifteen simultaneous dynamic requests, and further requests queue rather than fail outright. According to CloudLinux resource limit documentation, that queuing behavior is what separates a brief slowdown from an outright error page.

Caching changes the equation entirely, because cached pages never reach PHP. Consequently a well-cached site on an entry plan can absorb traffic that would overwhelm an uncached site on a larger one. Our guide to how many concurrent users shared hosting supports works through the arithmetic in detail, and the signals that indicate a VPS upgrade covers what to do when caching is no longer enough.

Cost Per Visitor: The Metric That Survives Any Price Comparison

Dividing monthly hosting spend by monthly visitors converts an abstract price into a business number. Moreover it makes tiers directly comparable, because a plan that costs three times more but serves ten times the traffic is cheaper by the only measure that matters.

A site drawing 10,000 monthly visits on a Bronze plan at the standard rate runs slightly under a tenth of a cent per visit. Similarly, the same site on monthly billing pays roughly a third more per visit for identical infrastructure. Ultimately that gap comes entirely from the billing cycle rather than from any difference in service.

Uptime belongs in the same calculation, since hosting that is unavailable serves nobody at any price. Our analysis of what each uptime SLA tier actually costs quantifies the downtime hours behind each guarantee. For sites that have outgrown shared infrastructure entirely, bare-metal dedicated servers change the math again by removing resource contention altogether.

Two Levers That Change Your Website Hosting Cost Per Month

Most buyers treat hosting price as fixed once they have signed up. In fact two levers remain available, and both are underused.

The first lever is the billing cycle, chosen at checkout. Specifically, moving from monthly to annual billing on an entry plan cuts the effective rate by roughly 61 percent and removes the setup fee, which is the largest single saving available anywhere in this guide. Furthermore the cycle can usually be extended at any renewal rather than only at first purchase.

The second lever is the renewal conversation. Long-standing customers can ask support to review their renewal rate, and at AHosting that request is considered on its merits rather than refused automatically. However, almost nobody asks, which is why the lever stays theoretical for most accounts. Notably, a single support ticket sent shortly before a term expires costs nothing and occasionally changes the number entirely.

Both levers apply equally across general web hosting plans and virtual private servers. For a side-by-side view of how renewal rates differ across the wider market, our WordPress hosting comparison lists the standard rates alongside the advertised ones.

Frequently Asked Questions About Website Hosting Cost Per Month

What is the minimum cost to host a website in 2026?

Specifically, entry shared hosting starts near $2.79 per month in 2026, but that rate almost always requires a three-year prepayment. Monthly billing for the same plan runs $9.79 plus a one-time $2.79 setup fee. Therefore the honest minimum depends entirely on how far ahead you are willing to pay, and the 36-Month True Cost Worksheet in this guide shows the full spread.

Website hosting cost per month vs annual billing: which is cheaper?

Ultimately, annual billing wins on a like-for-like plan. On AHosting Bronze, annual billing works out at $3.79 per month against $9.79 for monthly billing, and monthly billing also carries a $2.79 setup fee that the longer cycles waive. Consequently the website hosting cost per month falls by roughly 61 percent simply by moving from a monthly cycle to a yearly one.

What is a realistic website hosting cost per month in 2026?

Typically, a small business site lands between $3 and $15 per month on shared hosting, $10 to $50 on a VPS, and $95 or more on a dedicated server. However, those bands describe advertised rates. Notably, the realistic website hosting cost per month for anyone who does not prepay sits at the renewal rate, which is where the price bands table in this guide becomes useful.

Shared hosting vs VPS hosting: where does the price jump happen?

In practice, the jump happens at the point where guaranteed resources replace shared ones, not at a fixed traffic number. Shared plans top out around $14 per month at renewal, while an entry VPS begins near $8.79 and renews at $12.79. Interestingly, the renewal gap between the two tiers is far smaller than the advertised gap suggests.

Does the website hosting cost per month change if my AHosting plan renews?

Indeed, it does. An AHosting plan bought on a discounted term reverts to the standard monthly rate when that term expires, which is $9.79 on Bronze, $11.79 on Silver and $13.79 on Gold. Fortunately, long-standing customers can ask support to review their renewal rate, and the two-lever section of this guide explains when that conversation is worth having.

Why do hosting companies charge a setup fee on monthly billing?

In practice, a setup fee offsets the provisioning cost of an account that may only stay active for a single billing period. Furthermore, it is a deliberate nudge toward longer commitments. On AHosting the fee is a flat $2.79 across every shared tier, applied only to monthly billing and waived on annual, biennial and triennial cycles.

What website hosting cost per month should a WooCommerce store with 25 concurrent shoppers expect?

Specifically, twenty-five concurrent shoppers hitting uncached cart and checkout pages needs roughly twenty-five PHP entry processes, which maps to a Silver-tier or WooStart allocation rather than an entry plan. Accordingly the website hosting cost per month for that store starts around $3.79 prepaid or $11.79 at the standard rate, not at the headline entry price.

Which features does AHosting include free that other hosts bill separately?

Notably, AHosting includes a dedicated IP address, private nameservers, an SSL certificate, expert migration, daily offsite backups, a malware scanner and a staging environment on every shared plan, including the entry tier. In contrast, several of those items appear as paid add-ons or higher-tier-only features elsewhere, which is exactly what the hidden-cost audit in this guide itemizes.

How is AHosting's website hosting cost per month calculated over 36 months?

In particular, the calculation multiplies the discounted rate by the length of the committed term, then adds the standard monthly rate for every remaining month. On Bronze that produces $100.44 for a full three-year commitment against $355.23 for month-to-month billing, and the interactive worksheet in this guide performs the same arithmetic for any tier.

Will my website hosting cost per month increase after 2026?

In fact, yes, unless you are already paying the standard rate. Any account currently inside a discounted introductory term will step up to the standard monthly rate when that term ends, regardless of provider. Therefore the figure worth recording today is not what you pay now but what your plan renews at, which most invoices state in the fine print.

August 4, 2026

How to Push WordPress Staging to Live Without Losing Data

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

TL;DR

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

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

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

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

What Actually Breaks When You Push WordPress Staging to Live

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

The Overwrite Window: Every Row Production Gained While You Tested

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

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

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

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

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

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

The AHosting Staging Push Exclusion Map

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

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

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

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

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

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

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

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

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

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

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

Method One: Selective Table Push

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

Method Two: Files-Only Push With an Options Diff

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

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

Method Three: Full Push Behind a Maintenance Window

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

How to Push WordPress Staging to Live in Seven Steps

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

First Step: Measure the Overwrite Window and Back Up Production

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

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

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

Third Step: Run a Serialization-Safe URL Replace

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

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

Fourth Step: Push Files First, Tables Second

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

Fifth Step: Reconcile Order and User Counts

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

Sixth Step: Flush Caches and Regenerate Permalinks

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

Seventh Step: Watch the Error Log Before You Walk Away

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

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

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

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

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

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

What AHosting Includes Before You Push WordPress Staging to Live

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

Staging Push Exclusion Builder

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

Build Your Push Exclusion List

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

What kind of site is this?

WooCommerce order storage mode

What changed on staging?

How long has staging been running?

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

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

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

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

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

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

Frequently Asked Questions About How to Push WordPress Staging to Live

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

August 3, 2026

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

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

TL;DR

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

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

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

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

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

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

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

The 2026 WordPress PHP Version Matrix

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

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

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

Fully Compatible vs Beta Compatible in WordPress Core

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

Where WordPress 7.0’s PHP 7.4 Floor Actually Sits

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

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

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

Why Your Memory Limit Survives and Your Timeout Does Not

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

OPcache and LSCache: Two Cache Layers, Two Different Jobs

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

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

How to Change Your PHP Version in cPanel MultiPHP Manager

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

First Step: Record What You Are Running Now

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

Second Step: Switch on Staging Before Production

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

Third Step: Select the Version and Apply

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

Fourth Step: Re-Check the Directives That Just Changed

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

Fifth Step: Verify the Switch Took Effect

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

Choosing the Best PHP Version for WordPress Across Client Sites

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

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

AHosting PHP Version Defaults: What Every WordPress Plan Runs

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

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

PHP Version Decision Checker

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

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

See AHosting Plans

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

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

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

Frequently Asked Questions About the Best PHP Version for WordPress

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

August 3, 2026

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

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

TL;DR

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

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

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

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

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

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

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

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

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

Gate One — Can WordPress Blame a Plugin or Theme?

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

Gate Two — Did It Break on a Protected Endpoint?

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

Gate Three — Did the Handler Itself Survive?

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

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

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

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

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

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

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

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

The Memory Ceiling You Cannot Edit Your Way Past

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

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

The PHP Version That Kills WordPress Before It Loads

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

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

The Recovery Email That Never Arrives

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

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

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

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

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

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

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

Second Step: Read the Server Error Log Before Touching Anything

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

Third Step: Turn On Logging Without Turning On Display

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

Fourth Step: Rule Out Plugins by Renaming, Never Deleting

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

Fifth Step: Raise the Memory Ceiling at Both Layers

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

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

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

AHosting Recovery Readiness by Plan

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

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

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

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

WordPress Critical Error Triage: Which Outcome Are You In?

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

WordPress Critical Error Triage

Three questions. No data leaves your browser.

1. What does the page actually show?

2. Where is it broken?

3. Did you receive a recovery email from WordPress?

Answer all three questions to see your triage result.

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

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

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

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

Frequently Asked Questions About the WordPress White Screen of Death

What causes the WordPress white screen of death in 2026?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

July 31, 2026

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

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

TL;DR

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

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

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

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

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

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

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

AEO, GEO, and the Retrieval Pipeline in One Pass

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

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

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

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

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

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

How to See Exactly What GPTBot Sees

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

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

Where WordPress Sites Break This

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

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

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

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

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

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

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

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

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

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

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

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

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

Verifying Real Crawlers Against Spoofed Ones

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The AI Crawler Reachability Ladder: Blocked to Citable

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

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

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

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

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

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

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

How AHosting Covers the Server Half of AI Search Optimization

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

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

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

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

AI Crawler Visibility Auditor

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

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

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

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

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

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

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

—

Answer the six questions to score your site

Each answer updates the score immediately.

See hosting built for the server half

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

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

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

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

Frequently Asked Questions About Optimizing WordPress for AI Search

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

July 30, 2026

How to Fix WooCommerce Cart Fragments Slowing Every Page (2026)

TL;DR

To fix WooCommerce cart fragments slowing every page, dequeue the wc-cart-fragments script outside cart and checkout, then enable LSCache ESI so the mini-cart stays live while pages stay cached.

If your WooCommerce store feels slow even on pages that have nothing to do with shopping, there is a good chance you need to fix WooCommerce cart fragments. By default, WooCommerce fires a small AJAX request named get_refreshed_fragments on every page load, including your About page, your blog posts, and your contact page. Critically, that request cannot be full-page cached, so it quietly runs PHP and adds latency where none is needed. Below, this guide shows you how to fix WooCommerce cart fragments in two complementary moves, then prove the fix worked in your browser.

Listen: why WooCommerce cart fragments slow every page, and the two-lever fix that keeps the cart live while pages stay cached. By Matt Chrust, Director of Business Development, AHosting.

Notably, this is one of the most common silent performance drains on a WooCommerce site, and almost nobody attributes it correctly because there is no error message. Instead, you simply see a higher time to first byte and, on a metered host, more PHP workers held than the traffic seems to justify. Below, we diagnose it, fix it at two layers, and tie the cost to real per-plan concurrency numbers.

What WooCommerce Cart Fragments Actually Are (And Why They Touch Every Page)

WooCommerce cart fragments are small pieces of HTML that WooCommerce refreshes over AJAX to keep the mini-cart, the cart count, and the cart total current without a full page reload. Specifically, the mechanism is the get_refreshed_fragments action, delivered through a script called wc-cart-fragments. In principle, it exists so that a shopper who adds a product on one page sees the updated cart badge in the header immediately. That is genuinely useful behavior on shop and product pages.

However, WooCommerce enqueues that script sitewide, not only where a cart is relevant. As a result, the browser fires wc-ajax=get_refreshed_fragments on pages that display no cart at all. Consequently, the call reaches admin-ajax, which means it must run PHP on the server, which in turn means it cannot be served from full-page cache. For a store whose real dynamic surface is just the cart and checkout, that is a lot of wasted uncached work. Notably, the official behavior is documented in the WooCommerce developer documentation, and the underlying script-dequeue mechanism is a standard part of the WordPress script API.

Why the Uncacheable Call Costs More Than It Looks

Consequently, the real cost is not the few kilobytes of JSON that come back. Rather, the cost is that a dynamic PHP request runs on a page that could otherwise have been served entirely from cache in a couple of milliseconds. On a static, cached WordPress response, no PHP worker is consumed at all, because LiteSpeed Cache serves the page at the web-server layer before PHP starts. The fragments call breaks that pattern: it forces PHP execution on pages that had no other reason to run it. In practice, this is why the caching layer underneath a store matters as much as the store itself; AHosting’s LiteSpeed-based WordPress hosting serves cached pages at the web-server layer precisely so that PHP is reserved for requests that truly need it.

Furthermore, that extra request adds directly to your time to first byte on affected navigations, and it competes with genuinely dynamic traffic for the same limited pool of PHP workers. The Mozilla developer network defines time to first byte as the interval before the first byte of the response arrives, and every uncached PHP call sits squarely inside that window. Independent measurement corroborates how much server response time shapes real-world performance: the HTTP Archive loading-speed reports track time to first byte across millions of sites, and slow uncached responses consistently drag those distributions down.

Where Cart Fragments Fire vs. Where They Are Actually Needed

Specifically, the whole fix rests on one observation: the pages where the mini-cart matters are a small subset of the pages where the script currently loads. Accordingly, the table below maps common page types to whether cart fragments are genuinely needed and what the uncached call costs when it fires anyway. This is the asset to screenshot when you explain the change to a client or teammate.

Page type	Mini-cart needed here?	Fragments call by default?	Cost when it fires
Shop / product archive	Yes	Yes	Justified — keep it live
Single product page	Yes	Yes	Justified — keep it live
Cart page	Yes	Yes	Justified — never dequeue here
Checkout page	Yes	Yes	Justified — never dequeue here
Home page	Usually (header badge)	Yes	Use ESI, not a raw call
Blog post / article	Rarely	Yes	Wasted PHP worker
About / Contact page	No	Yes	Wasted PHP worker
Landing / policy pages	No	Yes	Wasted PHP worker

WooCommerce cart fragments coverage vs. need, by page type. The rows marked “wasted” are what the fix removes.

In practice, most stores find that the majority of their page views are exactly the rows marked “wasted” — content, informational, and policy pages that never show a functioning cart. That is why scoping the script pays off: you are removing the call from the pages people read most, while keeping it exactly where shopping happens.

How to Fix WooCommerce Cart Fragments in Four Steps

To fix WooCommerce cart fragments, dequeue the wc-cart-fragments script everywhere except cart and checkout, enable LSCache ESI so the mini-cart stays live on cached pages, then verify in DevTools that no wc-ajax call fires off-cart. The four steps below do exactly that, in order.

First, Confirm the Symptom in the Network Panel

First, open a page on your store that has no cart on it — your About page is ideal. Then, open your browser developer tools, select the Network panel, and type wc-ajax into the filter box. Reload the page. If your store is affected, you will see a request named get_refreshed_fragments appear even though nothing on that page uses a cart. That single request is the symptom you are about to eliminate. If it does not appear on the first load, add one product to your cart, reload the About page, and it will fire because a cart session now exists.

Second, Dequeue wc-cart-fragments Outside Cart and Checkout – The Forgotten Step to Fix WooCommerce Cart Fragments

Next, add the following snippet to your child theme functions.php. Specifically, it removes the fragments script on every page except the cart and checkout, so the AJAX call no longer fires on your content pages. Using a child theme matters: editing the parent theme directly means your change is wiped on the next theme update.

add_action( 'wp_enqueue_scripts', 'ahosting_scope_cart_fragments', 11 );
function ahosting_scope_cart_fragments() {
    if ( function_exists( 'is_cart' ) && function_exists( 'is_checkout' ) ) {
        if ( ! is_cart() && ! is_checkout() ) {
            wp_dequeue_script( 'wc-cart-fragments' );
        }
    }
}

Then save the file. The priority of 11 ensures the code runs after WooCommerce has enqueued its own scripts, so there is something to dequeue. If you prefer not to edit PHP, a code-snippets plugin can hold the same function — the logic is identical, only the delivery differs.

Third, Enable LSCache ESI to Keep the Mini-Cart Live on Cached Pages

On a LiteSpeed host, enable ESI next. Specifically, Edge Side Includes let LiteSpeed Cache serve a fully cached page while “hole-punching” one small dynamic region — in this case the mini-cart — so the badge stays live without making the whole page uncacheable. In the LiteSpeed Cache plugin, open Cache → ESI, turn Enable ESI on, and save. This is the move that lets you keep a live cart on your home and shop pages without paying for a sitewide uncached fragments call. Fortunately, AHosting runs LiteSpeed Web Server with LSCache available, so ESI is a server-native option rather than a workaround.

Moreover, ESI and the dequeue snippet are complementary, not redundant. The snippet removes the call where the cart is never shown; ESI keeps the cart live and cached where it is shown. Together they close both halves of the problem, which is why a LiteSpeed store should apply both rather than choosing one. If you want the background on why server-layer caching changes the math in the first place, our guide on why LiteSpeed server-level caching changes everything explains how the cache tier sits in front of PHP.

Fourth, Verify the Fix Without Breaking the Cart

Finally, prove it. Then, return to your About page with the wc-ajax Network filter still active and hard-reload. The get_refreshed_fragments request should no longer appear. Then navigate to a shop or product page, click Add to Cart, and confirm the mini-cart count still increments. If the call is gone from your content pages and the cart still updates where it should, the fix is complete and correct. The checker below turns this into a quick self-diagnosis.

Dequeue Script vs. LSCache ESI: Which Method Does What To Fix WooCommerce Cart Fragments

Because the two methods are easy to confuse, here is the direct comparison. Notably, most stores need both, but understanding which lever does what helps you decide the minimum change for your setup.

Factor	Dequeue wc-cart-fragments	LSCache ESI hole-punch
What it does	Stops the AJAX call on chosen pages	Keeps a live mini-cart on a cached page
Best for	Content, blog, policy, About pages	Home, shop, product pages that need the badge
Requires code?	Yes — a small functions.php snippet	No — a LiteSpeed Cache toggle
Requires LiteSpeed?	No — works on any host	Yes — LiteSpeed Web Server + LSCache
Effect on PHP workers	Removes wasted uncached calls	Serves the page from cache, punches one region
Risk if misapplied	Dequeuing on cart/checkout breaks the cart	None — falls back to normal caching

Two levers, two jobs. On a LiteSpeed host, apply both; on a non-LiteSpeed host, the dequeue snippet is the primary fix.

Cart Fragments Cost in PHP Workers on AHosting

Specifically, the reason this fix matters on shared hosting is that every uncached fragments call consumes one CloudLinux entry process — one PHP worker slot — for the duration of the request. AHosting allocates entry processes by plan tier and, unlike hosts that hide these numbers, publishes them so you can size a plan against real concurrency math. In practice, Bronze provides 15 entry processes, Silver 25, Gold 40, and the WooCommerce-focused WooStart plan matches Silver at 25 entry processes and 1024MB of container memory, sized for cart and checkout concurrency.

The Concurrency Math: Worker Cost by Visitor Load

As a result, the worker cost of unscoped cart fragments scales with how many people are browsing your non-cart pages at once. The table below shows the concurrency math. It is the citable figure to keep in mind when deciding whether this is a five-minute cleanup or a genuine capacity issue.

Concurrent visitors on content pages	Fragments calls in flight (unscoped)	Workers held on WooStart (25 EP)	After scoping the script
5	Up to 5	Up to 5 of 25	0 — pages serve from cache
10	Up to 10	Up to 10 of 25	0 — pages serve from cache
20	Up to 20	Up to 20 of 25 (queue risk)	0 — pages serve from cache
25+	25+	Ceiling hit — queue or 503	0 — pages serve from cache

Uncached cart fragments worker cost by concurrency on an AHosting WooStart plan (25 entry processes). Scoping the script drops the content-page cost to zero because those pages serve from cache with no PHP.

Notably, when a burst of visitors on content pages approaches your entry-process ceiling, CloudLinux LVE briefly queues the excess rather than rejecting it instantly, and only requests that cannot drain in time receive a 503. Cached pages never enter that scenario at all, which is precisely why removing the wasted fragments call is worth doing before you consider a plan upgrade. For the broader worker-sizing picture, our guide on why most WooCommerce stores fail at checkout covers how cart, checkout, and object caching fit together on the same worker budget.

How You Fix WooCommerce Cart Fragments – Our Diagnostic Checker

Use the checker below to decide which fix your store needs. Answer three quick questions about your setup and it will recommend whether to dequeue the script, enable ESI, or do both.

Cart Fragments Diagnostic Checker

Three questions. Get the exact fix for your store.

1. Is your store on a LiteSpeed host with LSCache?

2. Do most of your page views land on content pages (blog, About, policy)?

3. Do you need a live mini-cart badge in the header on those cached pages?

Need guaranteed workers? See VPS hosting

A Practical Checklist: Is Your WooCommerce Store Cart-Fragments-Clean?

Before you call this done, run through the short checklist below. Each item corresponds to a step above, so if any line fails, you know exactly where to return.

Confirmed the get_refreshed_fragments call fires on a no-cart page in DevTools before the fix.
Added the dequeue snippet to the child theme functions.php, not the parent theme.
Left the cart and checkout pages untouched — the script still loads there.
Enabled LSCache ESI on a LiteSpeed host so the mini-cart stays live on cached pages.
Re-checked the About page: no wc-ajax call appears in the Network panel.
Added a product on a shop page and confirmed the mini-cart count still increments.
Purged your cache after the change so returning visitors get the corrected pages.

Ultimately, a store that passes every line above is no longer paying the sitewide fragments tax. Specifically, your content pages serve from cache with no PHP worker consumed, your cart stays live where shoppers need it, and your entry-process budget goes to genuine checkout traffic instead of background AJAX. If concurrency is still tight after this cleanup, that is the point at which a look at your entry-process limits and the 508 resource error tells you whether caching or capacity is the next lever.

Frequently Asked Questions About How to Fix WooCommerce Cart Fragments

What is the wc-ajax=get_refreshed_fragments request and why does it slow every page?

Specifically, get_refreshed_fragments is a WooCommerce AJAX call that refreshes the mini-cart count, and by default it fires on every page on your site, including pages with no cart. Because it hits admin-ajax and cannot be full-page cached, each call consumes a PHP worker and adds latency to the initial response. The threshold table in this guide shows exactly which page types need it and which do not.

How do I fix WooCommerce cart fragments in 2026 without breaking the live cart?

Fortunately, you dequeue the wc-cart-fragments script everywhere except the cart and checkout pages using a short child-theme functions.php snippet, then verify in the Network panel that no wc-ajax call fires on other pages. On a LiteSpeed host you additionally enable LSCache ESI so the mini-cart stays live while the page stays cached, which keeps the cart working on shop pages without the sitewide AJAX call.

Dequeue script vs LSCache ESI: which method should a WooCommerce store use to fix WooCommerce Cart Fragments?

In practice, the two methods solve different halves of the problem and are strongest together. Dequeuing wc-cart-fragments stops the AJAX call on pages that never show a cart, while LSCache ESI hole-punches the mini-cart on pages that do, so the surrounding page still serves from cache. The comparison table in this guide breaks down when each method is enough on its own.

Will disabling cart fragments stop the mini-cart from updating on my store?

Generally, no, provided you scope the fix correctly. Dequeuing the script only on pages that have no cart leaves the cart and checkout pages untouched, and enabling LSCache ESI keeps the mini-cart count live on shop and product pages. The verification step in this guide has you add a product to the cart to confirm the count still increments after the fix.

Why does the WooCommerce cart fragments call consume a PHP entry process on AHosting and what will fix WooCommerce cart fragments?

Specifically, the wc-ajax request bypasses full-page cache because it must return live cart data, so it runs PHP on every hit and consumes one CloudLinux entry process per request. AHosting publishes its per-plan entry-process counts openly, with WooStart set at 25 to match Silver-level concurrency, so you can size the impact of uncached cart traffic against real numbers rather than guesswork.

Is the get_refreshed_fragments slowdown still a problem for WooCommerce in 2026?

Yes, because the sitewide cart fragments behavior remains a WooCommerce default in 2026 and is not removed by full-page caching alone. Any store that has not scoped the script or enabled ESI still pays the uncached-AJAX cost on every page load. The diagnostic checker in this guide confirms in seconds whether your store is affected.

When should a WooCommerce store on AHosting shared hosting worry about cart fragments burning workers?

Typically, the impact becomes material once concurrent visitors approach your plan's entry-process ceiling, because each uncached fragments call holds a worker that a cached page would not. On an AHosting WooStart plan at 25 entry processes, a burst of shoppers browsing non-cart pages can queue behind fragments calls that add nothing. The worker-cost table in this guide shows how the math changes as concurrency rises.

Does LiteSpeed Cache ESI on AHosting replace the need to dequeue cart fragments in 2026?

Notably, ESI reduces the cost but does not fully replace scoping the script. ESI lets a cached page carry a live mini-cart hole-punch, yet the fragments AJAX still fires where the script is loaded. Combining ESI with a dequeue on cart-free pages removes both the wasted call and keeps the live cart, which is why this guide recommends both on a LiteSpeed host.

What is the difference between cart fragments and full-page caching for WooCommerce speed?

In contrast to full-page caching, which serves a whole static page with zero PHP, cart fragments deliberately run live PHP to keep dynamic cart data current. Full-page cache cannot cover the fragments call because the response must change per session. Understanding this split is what lets you cache aggressively while still hole-punching only the truly dynamic mini-cart, as the guide explains.

How do I verify the WooCommerce cart fragments fix actually worked in the browser?

First, open your browser DevTools Network panel, filter for wc-ajax, and reload a page with no cart, such as your About page. After the fix, no get_refreshed_fragments request should appear there, while adding a product on a shop page still updates the mini-cart. The step-by-step verification in this guide walks through both checks so you confirm the call is gone without breaking the cart.

July 28, 2026

Choosing a Web Hosting Provider: The 12-Point Small Business Checklist (2026)

Why Choosing a Web Hosting Provider Is a Disclosure Problem, Not a Ranking Problem
The 12-Point Checklist for Choosing a Web Hosting Provider
The Spec Disclosure Test: What a Host Publishes Versus What It Withholds
Choosing a Web Hosting Provider by Business Type: What Actually Changes
The SSL Question Changed in 2026
Renewal Pricing and Exit Terms: The Two Numbers Most Checklists Skip
Score Your Shortlist
How AHosting Answers All Twelve Questions
A Practical Checklist Before You Decide
Frequently Asked Questions About Choosing a Web Hosting Provider

TL;DR

Choosing a web hosting provider comes down to twelve questions with published numbers behind them. A host that will not disclose worker counts, memory ceilings, or renewal pricing is telling you something.

Choosing a web hosting provider is usually presented as a ranking problem, and that framing is why so many small businesses end up on the wrong plan. Specifically, the advice available online almost always arrives as a list of providers rather than a method for interrogating one. Consequently, buyers compare marketing pages against marketing pages, and the decision turns on which company writes the most confident copy rather than which one publishes the numbers that govern whether a site stays up.

Listen: the twelve disclosure checkpoints that decide whether a hosting plan can be sized against real load. By Matt Chrust, Director of Business Development, AHosting.

This guide inverts that. Instead of naming providers, it treats choosing a web hosting provider as an interrogation: twelve questions to put to any host, and — more usefully — the answer to each one that should disqualify them. Notably, every question below has a checkable answer, which is precisely why some providers avoid answering it.

Why Choosing a Web Hosting Provider Is a Disclosure Problem, Not a Ranking Problem

The single most predictive signal in hosting is what a provider will put in writing. Specifically, four numbers govern whether a shared hosting account performs under real load: concurrent PHP workers, the per-account memory ceiling, CPU allocation, and disk IO throughput. Furthermore, all four are configured values that every provider knows exactly, which means an unwillingness to publish them is a choice rather than an oversight.

Those limits are not marketing abstractions. In practice, they are enforced at the kernel by CloudLinux LVE, which caps CPU, physical and virtual memory, IO, process count, and entry processes per account — and returns an error once the entry process ceiling is reached. Therefore, “unlimited” is never a description of the underlying configuration. Indeed, it is a description of the billing policy.

Ultimately, this is what separates a useful hosting evaluation from a comparison of adjectives. Every question in the checklist below is written so that a vague answer is itself the finding.

The 12-Point Checklist for Choosing a Web Hosting Provider

Below, each checkpoint is written as a question to ask the host, paired with the reply that should end the conversation. Notably, you can run the whole list through a pre-sales chat window in about ten minutes, and the pattern of evasion tends to appear well before question twelve.

First Group — Resource Transparency (Questions 1 to 3)

Specifically, this group establishes whether the provider will quantify what you are renting. In practice, a host that answers all three has almost certainly sized its plans deliberately; a host that answers none is selling density.

Notably, question two catches a common substitution. Many providers quote the PHP memory_limit value, which governs one request, while staying quiet about the container ceiling that governs the whole account. Consequently, a site can be configured for 512 MB per request inside an account capped well below that in aggregate — and the failure surfaces as an intermittent white screen rather than a clear error.

Second Group — Uptime Measurement and Remedy (Questions 4 to 6)

Generally, uptime guarantees are the most quoted and least examined line in hosting, and they are where choosing a web hosting provider most often goes wrong. In particular, almost every provider advertises 99.9%, which means the figure carries no comparative information at all. Therefore, the useful questions are what the number measures, how it is measured, and what happens when it is missed.

Most SLAs, including ours, measure network reachability rather than whether your application returned a usable page. Accordingly, the honest reading is that application-level availability remains your responsibility — which is exactly why worker exhaustion can take a site down without ever breaching an SLA. Our guide to what a 99.9% uptime SLA actually delivers works through the arithmetic in detail.

Third Group — Isolation and Reputation (Questions 7 and 8)

On shared infrastructure, your neighbors are part of your threat model. Specifically, the FTC’s Start with Security guidance for businesses makes segmentation and sensible access control two of its core lessons, and the same principle applies one layer down: a firewall guards the perimeter, not the accounts inside it.

Furthermore, reputation is shared by default. In contrast to a dedicated address, a shared IP means another account’s spam or malware incident becomes your email deliverability problem. Our breakdown of server-level protection that plugins cannot add covers what isolation actually prevents.

Fourth Group — Support, Backups, and Recovery (Questions 9 and 10)

Backups are where vague answers cost the most. Specifically, NIST SP 800-34 Rev. 1 states that a backup policy should designate the frequency of backups, the location of stored data, media rotation frequency, and the method for transporting data offsite. Therefore, a provider that describes backups as a courtesy rather than a policy has answered the question — just not the way it intended.

Similarly, “24/7 support” is a staffing claim rather than a performance claim. Accordingly, ask for a measured first-response figure and confirm it applies to your plan tier rather than only to the premium one.

Fifth Group — Renewal, Migration, and Exit (Questions 11 and 12)

Finally, the commercial terms — the part of choosing a web hosting provider that surfaces twelve months after the decision. Notably, introductory pricing governs only the first term, and renewal increases of three to nine times the entry rate are common enough across the market to be the default assumption rather than the exception. Consequently, the number worth writing down is the year-two price.

Migration deserves the same scrutiny. In particular, confirm who performs the transfer, whether a fee appears after purchase, and how an unusually large site is handled — because a fee disclosed at checkout is a reasonable predictor of how later surprises will be handled.

#	Ask the host	The answer that should disqualify them
1	How many concurrent PHP workers (entry processes) does this plan get?	“Unlimited,” or “we don’t publish that”
2	What is the per-account memory ceiling, and is that PHP `memory_limit` or the container cap?	Quoting only `memory_limit` and changing the subject
3	What CPU percentage and disk IO throughput are allocated to this plan?	“Our servers are fast” with no figure
4	What does your uptime SLA measure — network, or application response?	Refusing to state which
5	Is there a published credit schedule when you miss it?	No published schedule of any kind
6	Who measures uptime, and can I see the method?	“Third-party verified” with no source named
7	What kernel-level technology isolates my account from its neighbors?	Naming a firewall as the isolation layer
8	Do I get a dedicated IP, or do I share sending reputation?	“IP reputation doesn’t matter anymore”
9	What does your backup policy specify — frequency, location, offsite method?	“Backups are provided as a courtesy”
10	What is your measured first-response time, and does it apply to my tier?	“24/7 support” with no number attached
11	What is the renewal price, in writing, before I buy?	Renewal pricing not published anywhere
12	Who performs migration, at what cost, and what if my site is unusually large?	A migration fee that appears only at checkout

The 12-Point Host Qualification Table — each checkpoint paired with its disqualifying answer.

The Spec Disclosure Test: What a Host Publishes Versus What It Withholds

Rather than compare providers on features, compare them on disclosure. Specifically, the table below lists the six figures that determine real-world behavior on a shared plan, alongside how commonly each is published across the market and what AHosting states.

Figure	What it governs	Commonly published?	AHosting (Bronze / Silver / Gold)
Entry processes	Concurrent dynamic requests	Rarely	15 / 25 / 40
Container memory (PMEM)	Per-account RAM ceiling	Rarely	512 / 1024 / 2048 MB
CPU allocation	Share of processor time	Rarely	100% / 200% / 400%
Disk IO throughput	Read and write speed	Rarely	5120 / 10240 / 20480 KB/s
Measured TTFB	Real server response time	Rarely	~16 ms cached; 700-1,400 ms uncached
Renewal price	Year-two cost	Sometimes	$9.79/mo (from $2.79/mo intro)

AHosting Spec Disclosure Table — the figures that govern shared hosting behavior, and whether providers publish them.

Notably, the point of this table is not the values themselves. Rather, it is that they exist in a published form at all — which is the property you are testing for when choosing a web hosting provider. Our side-by-side hosting comparison applies the same disclosure standard across eight providers.

Choosing a Web Hosting Provider by Business Type: What Actually Changes

Site shape matters more than traffic volume. Specifically, the deciding variable is what proportion of your requests can be served from cache, because cached pages consume no PHP workers at all. Consequently, two sites with identical visitor counts can sit two plan tiers apart.

Before sizing anything, define the business model the site serves — the SBA’s guidance on market research and competitive analysis is the standard starting point. Afterward, the specification follows from the model rather than from a guess.

Site type	Uncacheable share	What actually changes in the spec	Typical shape
Brochure site (5-15 pages)	Very low	Almost nothing — server-level cache carries it	Entry tier is genuinely sufficient
Lead-generation site	Low, but bursty	Form posts bypass cache; email deliverability becomes critical	Entry tier plus a dedicated IP
Small online store	High per session	Cart and checkout never cache; object caching and worker headroom decide it	Mid tier or store-specific plan
High-traffic content site	Low but high volume	Cache hit ratio and IO throughput dominate; bursts need headroom	Top shared tier, then VPS

Business-type sizing matrix — how site shape, not visitor count, determines the specification.

For a straightforward business site, our web hosting plans cover the first two rows comfortably. Meanwhile, stores benefit from the cache-exclusion rules and worker allocation that ship pre-configured on WooCommerce hosting, and high-traffic content sites eventually move to VPS hosting for guaranteed resources. For a full breakdown of the arithmetic, see our guide to how many concurrent users shared hosting handles.

The SSL Question Changed in 2026

Free SSL stopped being a differentiator years ago. However, the question underneath it just became sharper: Let’s Encrypt is reducing default certificate lifetimes to 64 days in February 2027 and 45 days in February 2028, with the authorization reuse window falling to seven hours.

Consequently, manual renewal stops being viable, and a certificate nobody renews automatically becomes a scheduled outage. Therefore, the useful question is no longer whether SSL is included but whether renewal is automated through ACME and what the provider does when a renewal fails. Notably, this is one checkpoint where a host running its own automation has a structural advantage over one that hands you a certificate and wishes you luck.

Renewal Pricing and Exit Terms: The Two Numbers Most Checklists Skip

Renewal pricing is the most reliably underexamined term in hosting. Specifically, a plan advertised at a low introductory rate may renew at several times that figure, and the increase typically lands at the moment switching is most inconvenient. Therefore, treat the year-two price as the real price.

Exit terms deserve equal weight. In particular, ask what happens on the way out: whether you can export a full account backup yourself, whether a refund window exists, and whether migration assistance is offered in both directions. Fortunately, these are all answerable before purchase. AHosting publishes a $9.79 monthly renewal rate, a 30-day money-back guarantee, and free cPanel-to-cPanel migration with no published per-site limit — with unusually large or multi-subdomain sites scoped with the customer before the transfer runs. Our walkthrough of migrating to a new host without downtime covers the mechanics.

Score Your Shortlist

Run each candidate through the twelve checkpoints and score the result, so that choosing a web hosting provider becomes arithmetic rather than impression. Specifically, tick only the boxes where you received a specific, published answer rather than a reassurance.

How AHosting Answers All Twelve Questions

Applying our own checklist to ourselves is the only honest way to publish a guide on choosing a web hosting provider. Specifically, entry processes, container memory, CPU, and IO are published per tier in the disclosure table above. Furthermore, every shared plan runs CloudLinux CageFS and LVE for kernel-level isolation, includes a free dedicated IP, and carries daily offsite backups.

On support, our measured first response averages two to five minutes across all packages rather than only the premium tiers. Meanwhile, the SLA publishes a tiered credit schedule of 10, 25, and 50 percent, and renewal pricing appears on the product page before purchase rather than after it. For businesses that outgrow shared capacity entirely, dedicated servers remove the shared-resource variable altogether.

Indeed, the one checkpoint worth flagging honestly is the SLA scope: like most providers, ours measures network connectivity for HTTP access rather than application response. Consequently, we publish worker counts precisely so that the application-layer half remains something you can plan for rather than discover.

A Practical Checklist Before You Decide

Collected published worker, memory, CPU, and IO figures for every shortlisted plan
Confirmed the year-two renewal price in writing
Identified which kernel technology isolates accounts
Confirmed a dedicated IP is available and priced
Obtained a backup policy stating frequency and offsite method
Asked for a measured support response figure that applies to your tier
Confirmed migration cost, ownership, and large-site handling
Matched the plan to your uncacheable request share, not your visitor count
Checked that SSL renewal is automated ahead of the 2027 and 2028 lifetime changes
Scored each provider out of twelve and kept the notes

Ultimately, choosing a web hosting provider well is less about finding the best host than about eliminating the ones that will not tell you what you are buying. Notably, that filter removes most of the market before price ever enters the conversation. If your current provider fails more than four checkpoints, our guide to telling whether your server or your plugins are the problem is the fastest way to confirm it with data.

Frequently Asked Questions About Choosing a Web Hosting Provider

What should I look for when choosing a web hosting provider for a small business in 2026?

Specifically, ask for four numbers a host can either publish or cannot: concurrent PHP workers, the per-account memory ceiling, CPU allocation, and disk IO throughput. Furthermore, a provider that answers all four in writing is measurably easier to size a plan against than one that answers none. Therefore, treat an unwillingness to publish as the finding itself. The full 12-point table above pairs every question with the answer that should end the conversation.

Shared hosting vs VPS when choosing a web hosting provider: which does a small business actually need?

Typically, the deciding factor is not traffic volume but how much of your traffic is uncacheable. In practice, a brochure site serves almost everything from cache and rarely needs a VPS, while a store whose cart and checkout bypass cache on every session runs into the worker ceiling far earlier. Consequently, the business-type table in this guide maps four common site shapes to what actually changes in the specification.

Is a cheap web hosting plan in 2026 a false economy once renewal pricing is included?

Frequently, yes. Notably, the introductory rate governs only the first term, and several major providers renew between three and nine times their advertised entry price. Therefore, the number that matters is the year-two price, published in writing before purchase. Notably, a provider that prints its renewal rate on the product page has already cleared checkpoint eleven.

What does a web hosting uptime SLA actually measure, and what happens when a provider misses it?

Generally, an uptime SLA measures network reachability rather than whether your application returned a usable page. Additionally, the meaningful question is whether a published credit schedule exists at all. Consequently, a guarantee with no stated remedy is a marketing line rather than a commitment. Our uptime guide breaks down what the remaining downtime allowance costs an average small business per year.

How do I verify a web hosting provider's account isolation, and what does AHosting actually use?

Specifically, ask which kernel-level technology separates accounts, because a firewall protects the perimeter rather than the neighbors inside it. In contrast, CloudLinux CageFS and LVE isolate each account's filesystem and resource pool at the kernel, and AHosting runs both on every shared plan. Therefore, treat a firewall-only answer from any provider as a failed checkpoint.

Why does the shift to 45-day SSL certificates change what to ask a hosting provider in 2026?

Notably, Let's Encrypt is reducing default certificate lifetimes to 64 days in February 2027 and 45 days in February 2028. Consequently, free SSL is no longer the useful question, because a certificate nobody renews automatically becomes an outage on a schedule. Instead, ask whether renewal is automated through ACME and what happens when it fails.

What backup policy details should a small business demand before choosing a web hosting provider?

Specifically, NIST SP 800-34 states that a backup policy should designate frequency, the location of stored data, media rotation, and the method for transporting data offsite. Therefore, the disqualifying answer is a provider that treats backups as a courtesy rather than a stated policy. Consequently, ask for the policy itself rather than the reassurance.

How many PHP workers does a small business site need on AHosting's shared hosting tiers?

Typically, a brochure or lead-generation site running server-level caching needs far fewer workers than owners assume, because cached pages consume none at all. However, uncacheable requests such as form posts, logged-in sessions, and checkout are what actually draw against the ceiling. AHosting publishes 15, 25, and 40 entry processes across Bronze, Silver, and Gold, and our concurrency guide works the arithmetic against those tiers.

Free migration vs paid migration: what should a small business confirm before switching hosts?

Specifically, confirm who performs the transfer, whether a fee appears after purchase, and how an unusually large site is handled. Indeed, migration fees disclosed only at checkout are a reliable signal of how the rest of the relationship will run. AHosting performs cPanel-to-cPanel migrations at no charge with no published per-site limit, and scopes outsized sites with the customer in advance.

Does choosing a web hosting provider with a free dedicated IP, as AHosting includes, change anything for a small business?

Fortunately, the answer is now easier to reason about than the old ranking debate suggested. In particular, a dedicated IP protects transactional email deliverability and separates your reputation from every other account on the machine. AHosting includes one free on every plan, which is unusual enough that most comparison tables treat it as a differentiator rather than a given.

July 28, 2026