Every hosting provider claims to be the best for WordPress. Fast servers, 99.99% uptime, unlimited everything, award-winning support. The marketing copy is interchangeable. The actual infrastructure behind it is not.
This post is written from a technical perspective. It covers the specific things that affect how your WordPress site performs, how secure it is, and how much headache you deal with over time. No affiliate rankings. No “top 10 best hosts” list. Just the criteria that matter and how to evaluate them yourself.
The technical criteria that actually matter#
PHP version support
WordPress runs on PHP. The PHP version your host provides affects both performance and security.
PHP 8.x is significantly faster than PHP 7.x for WordPress workloads. The JIT compiler, preloading improvements, and internal optimizations mean the same WordPress code runs faster on a newer PHP version without changing anything on your end. Upgrading from PHP 7.4 to PHP 8.3 can reduce page generation time by 20-40% depending on the workload.
More importantly, older PHP versions reach end of life and stop receiving security patches. If your host only offers PHP 7.4 or 8.0, your site is running on software with known, unpatched vulnerabilities. Every page load, every form submission, every checkout runs through that vulnerable runtime.
What to check:
- Which PHP versions are currently available?
- How quickly does the host add new PHP versions after release?
- Can you switch PHP versions yourself through a control panel, or do you need to contact support?
- Can you configure PHP extensions and settings (memory_limit, max_execution_time, upload_max_filesize) per site?
A host that lets you select from multiple current PHP versions and switch between them easily is doing the basics right. A host that is still defaulting new accounts to PHP 7.4 in 2026 is not keeping up.
MySQL/MariaDB version
WordPress stores everything in a database – posts, pages, options, user data, plugin settings, WooCommerce orders. The database engine and its version directly affect query performance, reliability, and what features are available.
Most hosts run either MySQL or MariaDB. Both work with WordPress. The differences between them are worth understanding if you care about performance characteristics, but the more important question is whether the version is current and properly configured.
What to check:
- Is the database version currently supported and receiving security updates?
- Is the database configured with appropriate buffer pool sizes for WordPress workloads?
- Are per-account connection limits reasonable (not so low that WooCommerce runs into them during traffic)?
You probably will not get answers to the configuration questions from a sales page. But “what MySQL/MariaDB version do you run?” is a fair question, and a host that cannot answer it clearly is a flag.
Memory limits
PHP memory limits determine how much RAM your WordPress site can use per request. WordPress itself needs a baseline amount, and every active plugin adds to that. A WooCommerce store with a page builder, SEO plugin, analytics, and a handful of other plugins can easily need 256 MB or more per request.
The default PHP memory limit on many shared hosts is 128 MB or even 64 MB. That is fine for a minimal WordPress install. It is not fine for a production WooCommerce store or a content-heavy site with 20+ active plugins.
What to check:
- What is the PHP memory_limit for your plan?
- Can you increase it yourself, or is it locked?
- What is the total RAM allocated to your account (not just per-request PHP memory)?
“Unlimited memory” is not a real answer. Every server has physical RAM limits. A host that specifies actual numbers – 512 MB RAM per account, 256 MB PHP memory_limit – has thought about resource allocation. A host that says “unlimited” is hoping you never test that claim.
NVMe vs SATA SSD vs HDD
The storage type your hosting runs on affects database performance, PHP file loading, and how the site handles concurrent traffic. NVMe storage delivers meaningfully lower latency than SATA SSD for the random I/O patterns that WordPress generates, particularly database queries and uncached page loads.
The difference is most visible in:
- Time to first byte on uncached pages
- WooCommerce checkout and cart operations (which cannot be fully cached)
- WordPress admin panel responsiveness
- Database performance during traffic spikes
HDD hosting still exists at the budget end of the market. If a host does not mention their storage type, ask. “SSD” without further specification usually means SATA SSD, not NVMe. The distinction matters.
Container isolation vs shared process space
This is one of the most important and least discussed criteria. It determines what happens when another site on your server has a problem.
Traditional shared hosting uses CloudLinux CageFS for isolation. CageFS creates a filtered filesystem view for each account but shares the process table, PHP worker pool, and database instance across all accounts on the server. When another account spikes in traffic or gets compromised, your site can feel it through shared PHP workers, shared database connections, and shared CPU time.
Container-based isolation gives each account its own process namespace, its own PHP workers, and its own resource allocation enforced at the kernel level. Other accounts on the same server cannot consume your PHP workers or affect your resource allocation because the boundaries are enforced by the kernel, not by application-level filtering.
What to check:
- Does the host use CageFS, containers, or something else for account isolation?
- Are PHP workers dedicated per account or shared across the server?
- Are resource limits (CPU, RAM, I/O) hard limits enforced at the kernel level?
Most hosts use CageFS because it is the industry standard and integrates with cPanel. It works. But if you want stronger isolation without managing your own VPS, container-based hosting provides it.
Server-level security
WordPress is the most targeted CMS on the internet. Automated bots scan for vulnerabilities, brute force login pages, and probe for exposed files around the clock. The security your hosting provider runs at the server level determines how much of that traffic ever reaches your site.
What to look for:
Web application firewall (WAF). A WAF like ModSecurity with the OWASP Core Rule Set inspects every HTTP request and blocks SQL injection, cross-site scripting, path traversal, and other attack patterns before they reach PHP. This runs at the web server level, not inside WordPress, so it catches attacks that WordPress security plugins cannot see.
Bot detection. Automated vulnerability scanners, credential stuffing bots, and content scrapers generate a significant portion of traffic on any WordPress site. Server-level bot detection identifies and blocks this traffic before it consumes PHP resources. This is fundamentally different from a WordPress plugin doing the same thing – the plugin still has to load WordPress to evaluate the request, which means the bot is already consuming server resources.
Malware monitoring. Real-time file monitoring that detects and quarantines malicious files is more effective than a scheduled daily scan. A backdoor that exists for 23 hours before detection has already done its damage.
Firewall rules. Network-level rules that block unauthorized ports, rate limit connections, and filter traffic before it reaches the web server.
A host that provides all of these at the infrastructure level gives you a security baseline that does not depend on WordPress plugins. A host that tells you to install Wordfence and handle security yourself is shifting that responsibility to you, and plugin-level security has architectural limitations that server-level security does not.
Backup frequency and retention
Backups are insurance. When a plugin update breaks your site, when malware gets past your defenses, when you accidentally delete something critical, backups are how you recover.
What to check:
- How frequently are backups created? Daily is a reasonable minimum.
- How long are backups retained? 14 days gives you enough history to recover from problems that are not discovered immediately.
- Are backups stored on separate infrastructure from the hosting server? A backup on the same disk as your site is not a backup if the disk fails.
- Can you restore with one click, or do you need to contact support and wait?
- Can you download backups to keep your own copy?
Some hosts create backups but charge extra for restoration. Some create weekly backups and call it “regular backups.” Read the specifics.
SSH access
SSH access lets you manage your site from the command line. For developers and technical users, this is essential. WP-CLI (WordPress command line interface) runs over SSH and lets you manage WordPress – update plugins, export the database, search-replace URLs, manage users – faster than clicking through the admin panel.
SSH access also enables:
- Secure file transfers via SFTP/SCP
- Direct database access via MySQL CLI
- Debugging with tools like grep, find, and tail
- Running custom scripts and cron jobs
Not every WordPress user needs SSH. But if you are technical enough to be evaluating hosting criteria, you probably want it. Some budget shared hosts do not provide SSH at all. Others provide it but restrict which commands are available. Check before you sign up.
Marketing claims to ignore#
“Unlimited” everything
Unlimited storage, unlimited bandwidth, unlimited email, unlimited databases. No server has unlimited resources. “Unlimited” means the host is overprovisioning – selling more capacity than the server physically has – and betting that most accounts will use very little.
The practical consequence: when you actually need significant resources, you hit soft limits, get throttled, or receive an email saying your account is using “excessive resources” and needs to upgrade. The unlimited plan was never unlimited. It was a marketing number designed to prevent you from comparing actual resource allocations between providers.
A host that specifies real numbers – 20 GB NVMe storage, 2 CPU cores, 2 GB RAM, 2 TB bandwidth – has thought about what each account gets. You can evaluate whether those numbers meet your needs. “Unlimited” gives you nothing to evaluate.
99.99% uptime SLAs
99.99% uptime means less than 53 minutes of downtime per year. Most shared hosting providers cannot reliably deliver this, and their SLA terms typically define “downtime” so narrowly that real outages do not qualify.
Read the SLA. Check what constitutes “downtime” (usually only complete server unavailability, not slow performance or partial outages). Check what the remedy is (usually service credits, not refunds, and often capped at a percentage of one month’s fee). A 99.99% SLA that pays you $0.50 in service credits when your site is down for a day is not meaningful protection.
Uptime monitoring by the host counts differently than uptime experienced by your visitors. A server can be “up” (responding to health checks) while your site is effectively down (returning 500 errors because PHP workers are exhausted).
What actually matters is how the host handles incidents: monitoring quality, response time, communication during outages, and post-incident transparency. Those things are harder to put in a marketing bullet point.
“Optimized for WordPress”
This phrase means everything from “we pre-installed WordPress” to “we built custom caching infrastructure specifically for WordPress workloads.” Without specifics, it tells you nothing.
Ask what the optimization actually is. Server-level page caching? Object caching with Redis or Memcached? OPcache tuned for WordPress? PHP-FPM pools configured for WordPress memory patterns? These are real, measurable optimizations. “Optimized for WordPress” without technical detail behind it is marketing copy.
“Free migration”
Free migration is genuinely useful if the host actually handles it well. But the quality varies enormously. Some hosts have automated migration tools that handle most WordPress sites correctly. Others have a support agent manually copy files and import a database, which works until it does not (serialized data, hardcoded URLs, multisite configurations, custom table prefixes).
What to check: does the migration include DNS assistance? Do they verify the site works correctly before you switch DNS? Is there a rollback plan if something goes wrong? Free migration that breaks your site is not a feature.
For what is involved in a proper WordPress migration, see how to migrate WordPress to another hosting provider.
How to test a host before committing#
Use free trials or money-back guarantees
Many hosts offer trial periods or 30-day money-back guarantees. Use them. Set up your actual site (or a copy of it) and test real-world performance, not a fresh WordPress install with the default theme and no plugins. Your site with your plugins, your theme, and your content is what needs to perform well.
Measure what matters
Once your site is running on the test host:
- Time to first byte (TTFB): measure uncached TTFB from multiple locations. This tells you how fast the server generates a response without caching masking underlying performance.
- Admin panel speed: navigate the WordPress admin, edit posts, save settings. The admin bypasses page cache, so it reflects actual server performance.
- WooCommerce operations: if you run WooCommerce, test the cart, checkout, and order processing. These are database-heavy operations that cannot be fully cached.
- Concurrent load: if possible, run a basic load test with a tool like k6 or Apache Bench to see how the server handles multiple simultaneous requests.
Check the support
Open a support ticket with a technical question before you need urgent help. Ask about PHP configuration, or ask how container isolation works on their platform, or ask what WAF rules are active. The response tells you whether support is knowledgeable or reading from a script.
Review the control panel
Log in and try to do the things you will need to do: change PHP versions, view error logs, manage databases, set up a staging site, configure cron jobs. If the control panel is confusing or missing features you need, you will deal with that friction for as long as you host there.
Questions to ask before signing up#
These are specific, concrete questions that separate hosts who have thought about their infrastructure from those who have not:
- What storage type do your servers use? NVMe, SATA SSD, or HDD? This directly affects database performance.
- What isolation model do you use? CageFS, containers, or something else? This determines how other accounts on the server affect yours.
- What PHP versions are available, and how do I switch between them? Current PHP versions with easy switching is baseline. Outdated PHP is a security and performance problem.
- What are the actual resource limits for my plan? CPU, RAM, I/O, PHP workers. Real numbers, not “unlimited.”
- What security is provided at the server level? WAF, bot detection, malware monitoring, firewall rules. What do you get without installing anything?
- How do backups work? Frequency, retention period, storage location, restoration process.
- Do I get SSH access? And if so, is it full SSH or restricted?
- What happens when I outgrow my plan? Can you upgrade seamlessly, or does it require a migration?
- What is your average response time for support tickets? Not the SLA target – the actual average.
- Can I see a demo of the control panel? Knowing how you will manage your site day to day is worth evaluating before you pay.
Hosts that answer these questions clearly and specifically are the ones worth considering. Hosts that deflect with marketing language or cannot provide specifics are telling you something about how much thought they have put into their infrastructure.
Choosing based on your actual needs#
Small sites and blogs
A basic shared hosting plan with current PHP, daily backups, SSL, and a WAF is sufficient. You do not need container isolation or NVMe for a site that gets a few hundred visitors a day. Spend the minimum and focus on your content.
Business websites
If your website represents your business – generates leads, serves customers, or creates first impressions – step up to a host with container isolation, NVMe storage, server-level security, and reliable support. The cost difference between budget hosting and proper managed hosting is negligible compared to the cost of a slow or compromised website.
WooCommerce stores
E-commerce has the highest infrastructure requirements. Checkout cannot be cached, database performance directly affects order processing, and security incidents mean compromised customer data. You need dedicated PHP workers, NVMe storage, server-level security including a WAF and bot detection, and reliable backups. Managed WordPress hosting built for WordPress workloads handles these requirements at the infrastructure level.
High-traffic content sites
If you consistently serve thousands of concurrent visitors, you need a host with strong caching infrastructure (server-level page cache, object cache, OPcache), adequate PHP workers, and enough resources to handle traffic spikes without degradation. The caching stack matters more than raw hardware specs at this scale – a server with excellent caching will outperform a more powerful server without it.
Developer and agency sites
SSH access, staging environments, WP-CLI, Git integration, and the ability to manage multiple sites efficiently. If you manage sites for clients, the control panel and workflow matter as much as the infrastructure. A host that requires a support ticket for routine operations will slow you down.
What Hostney provides#
Hostney is built for WordPress workloads with infrastructure decisions driven by the technical criteria covered in this post:
Container isolation with Podman. Each account runs in its own container with a separate process namespace, mount namespace, and cgroup-enforced resource limits. PHP workers are dedicated per account. Other accounts on the server cannot affect your performance or security.
NVMe storage on all servers with per-account I/O bandwidth and IOPS limits. Database queries and PHP file operations run at NVMe speeds without contention from other accounts.
Current PHP versions from 5.6 through 8.5, selectable through the control panel with per-site extension configuration. Switching takes effect immediately without a support ticket.
Server-level security including ModSecurity WAF with the OWASP Core Rule Set, behavioral bot detection at the edge, real-time malware monitoring with automatic quarantine, and SELinux in enforcing mode on all servers.
Automated daily backups stored on separate infrastructure with retention and one-click restore through the control panel.
SSH access on all plans with full WP-CLI support.
Specified resource allocations – CPU cores, RAM, storage, I/O limits – per plan. No “unlimited” claims. What the plan says is what you get, enforced at the kernel level.
The infrastructure handles the technical criteria. You focus on your WordPress site.
Explore the hosting plans, compare pricing, or read more about managed WordPress hosting and shared hosting to understand how the models compare.