WordPress needs five things from a host: a PHP version the project still supports, a MySQL or MariaDB database, enough PHP memory to load your plugins, a scheduler that fires on time, and a writable uploads directory. That is the whole list. Nearly everything else sold as WordPress hosting is ordinary hosting with a label on it.
The label is not always dishonest. A few of those features do real work, and knowing which ones is the difference between paying for a staging environment you will use every week and paying for an installer you will run once.
The WordPress Hosting Requirements That Come From WordPress Itself
The project publishes its own server requirements, and that page is the only version of this list worth trusting, because any number printed in an article goes stale the year after it is written. Read it before you read a host's marketing.
Four of the five are easy to check and rarely a problem on a paid plan.
Start with PHP. Your host should let you pick a branch that still receives security fixes, and let you move back if a plugin breaks. The supported versions table at php.net tells you which branches those are on any given day. A host that pins you to one version with no selector is a host you will fight with in two years.
The database matters less than people expect. MySQL or MariaDB, with a user that owns it outright, and shared plans hand you that at signup.
Memory is where it gets interesting, because there are two ceilings and they are set in different places. PHP has a memory_limit, and WordPress applies a second limit of its own on top of it, which is lower than what a site running a page builder and a dozen plugins actually consumes. You raise the WordPress side in wp-config.php:
php
define( 'WP_MEMORY_LIMIT', '256M' );
That line does nothing if the PHP limit underneath it is lower, which is exactly why the white screen keeps coming back after somebody edits the file. The host controls the floor.
The last requirement is a writable uploads directory. wp-content/uploads has to be writable by the web server, or media uploads fail with a permissions error and plugin installs fail silently. Watch upload_max_filesize and post_max_size too, since a video that exceeds either is rejected by PHP before WordPress ever sees it.
If you are reading plan comparison tables while you work through this, our guide to what hosting plan specifications actually mean covers the vocabulary the tables use.
Cron Is the Requirement Nobody Checks
WordPress schedules work: publishing a post you queued, checking for updates, expiring transients, running whatever your backup plugin promised to do at 3 a.m. It has no scheduler. What it has is WP-Cron, which checks the schedule when somebody loads a page and runs anything overdue.
You can see the two failure modes from that description alone.
A quiet site misses its jobs. If nobody visits between midnight and nine, the post you scheduled for 6 a.m. publishes when the first visitor arrives, and the backup you thought ran nightly ran on Tuesday and then not again until Friday. A busy site has the opposite problem: every request pays the cost of asking whether anything is due, and on a site with several plugins registering jobs, that check turns into real work happening inside a visitor's page load.
The fix is the same for both. Turn off the built-in behavior in wp-config.php and hand the job to a real scheduler:
php
define( 'DISABLE_WP_CRON', true );
Then set a system cron entry to request wp-cron.php on a fixed interval. So the question for a prospective host is short: is there a scheduler in the control panel, and can it run on a schedule I choose? Hepsia includes one, and its hosting control panel page lists what the panel manages. Most panels do, but plenty of entry-level plans restrict how often it may fire, and that limit is worth asking about before you rely on it.
Which of Those Extras Are Worth Paying For?
Here is my honest ranking of the things marketed as WordPress-specific, from useless to worth money.
One-click installers are close to worthless. They save you fifteen minutes, once, at the start of a project that will run for years. Installing WordPress by hand means uploading the files and answering a handful of questions in a browser once a database exists. Paying a premium for a wizard that does that is paying for the least demanding part of the job, and some installers make the situation worse by pinning you to their own update mechanism.
Automatic updates are mostly already yours. WordPress core applies its own minor and security releases by default, so a host advertising automatic updates is usually offering plugin updates instead. That is useful and risky in equal measure, because an unattended plugin update on a site with no staging copy is how a checkout page breaks at nine on a Saturday morning.
Staging is worth paying for. A one-click copy of the site where you can update plugins, edit a theme, and break things without an audience is the single feature on this list that changes how you work. If a plan advertises it, ask whether pushing changes back to production overwrites the database, since that detail decides whether staging is usable on a site that takes orders.
Server-side caching is worth paying for. A page cache in front of PHP is the difference between rebuilding a page from the database on every request and sending bytes that are already assembled. A plugin can do this from inside PHP, and it helps. Doing it at the server, before PHP starts, helps considerably more.
Anything described as "optimized for WordPress" with no further detail is a sentence, not a feature. Ask what it does. If the answer is caching and a PHP version selector, you already know how to evaluate that.
How WordPress Behaves Under Load Compared to a Static Site
A static page is a file. The server reads it and sends it, and a cheap machine will do that thousands of times a second without noticing.
An uncached WordPress request is a program. PHP starts, WordPress loads its core files, then every active plugin loads whether or not the current page needs it, then the theme runs, and somewhere in there the database answers a few dozen queries. The result is HTML that usually looks identical to what it looked like an hour ago. Caching exists to stop paying that cost repeatedly, and on a content site a good cache means most visitors are effectively being served a static file.
Which is why the admin side is the part that hurts. wp-admin cannot be cached, because every screen depends on who you are and what changed a second ago. Editing a post fires repeated background requests through the Heartbeat API to save revisions and hold your post lock. Uploading a photo makes PHP resize it into every registered image size, which is the most CPU your site will spend on any single action. Two writers working in the editor, one bulk plugin update, and a crawler hitting uncached URLs will collide on the same small pool of PHP workers, and the front end slows down for reasons no page speed report will explain.
That collision is the reason a WordPress site can pass every front-end audit and still feel unusable to the people who run it. If your slow pages are slow for visitors as well, the question is whether the delay is server time or browser time, and our post on Core Web Vitals and which metric to fix first splits those apart. If the site is only slow when you are working in it while traffic is high, you are running out of concurrency, which is one of the signs a site has outgrown shared hosting.
Five Questions Worth Asking Before You Pay
- Which PHP versions can I select, and can I switch back within a day? The second half matters more than the first. Upgrading PHP is the most common way to break an old plugin, and a host without a rollback turns a five-minute experiment into an outage.
- Is there a scheduler I control, and how often may it run? This is the WP-Cron question from earlier, and it decides whether your scheduled posts and backups are reliable.
- How many PHP processes can my account run at once? Storage numbers are easy to publish and rarely the constraint. Concurrency is what actually decides how the site behaves during your busiest hour, and it is the number least likely to appear on a comparison table.
- What do the backups cover, how far back do they go, and can I restore one site without restoring everything? A backup you cannot restore selectively is a backup you will hesitate to use.
- Can I get a copy of the database and files without opening a ticket? Direct access to a dump and an archive is what makes leaving possible, which is worth confirming while you are still a prospect rather than a customer.
Matching a Site to a Hosting Tier
| Your site | Sensible tier | The constraint you will hit first |
|---|---|---|
| Brochure site, small blog, portfolio | Shared | Rarely the plan, provided the front end is cached |
| Content site with steady daily traffic and several authors | Semi-dedicated | Concurrent PHP processes during peak hours and editing |
| Store, membership site, or anything with a logged-in checkout | VPS | Uncachable pages, since carts and accounts bypass the page cache entirely |
| A dozen client sites on one account | VPS or dedicated | One busy site starving the others, plus backup and restore granularity |
One thing drives that table. It is how much of your traffic can be cached. A blog serves the same HTML to everybody, so a small plan carries it a long way. A store serves a different page to every logged-in customer, so the cache stops helping precisely when the site is busiest, and PHP and the database have to do the work for real. That is why a modest store often needs more server than a much larger blog.
The WordPress hosting plans at BestPaidHosting run on Hepsia rather than cPanel, which matters here for one practical reason: the PHP version selector and the cron scheduler sit in different places than most WordPress tutorials assume, so follow the panel's own documentation rather than a screenshot from a blog.
Where to Start
If you are launching, keep it simple. Get a plan with a PHP version selector and a real scheduler, install WordPress, and stop there. You do not know your traffic shape yet, and buying a VPS on a guess is how people end up paying for capacity while also being responsible for patching it.
If you are migrating, the WordPress-specific part is the easy half. The parts that break a move are DNS and email, plus the order in which you request the certificate, and our checklist for switching web hosts walks that sequence.
And if you are here because something is slow, resist the upgrade for one afternoon. Find out first whether the site is slow for visitors or only slow for you in the admin, because those two have different causes and only one of them is fixed by a bigger plan. Measure, then buy.