What Most Hosting Comparisons Miss
A few years ago I took over hosting for a small accommodation business in New Zealand. Their website was not a brochure. It was the booking desk.
Over a 17-month period the site had been compromised more than once. There had been repeated downtime, spam problems, and the kind of access issue where the owner could not reliably reset her own password. The failures were not exotic. Weak credentials, no useful monitoring, unclear recovery, and backups that were not part of a proper restore process.
That is not a rare technical mystery. It is the normal result of treating hosting as storage, bandwidth, and a support label instead of as an operating system for the business.
Every booking that did not happen during those outages was not delayed revenue. It was gone. A guest looking for a weekend stay does not wait for a ticket queue to work through the finer points of DNS, malware, or plugin conflicts. They book the next place that loads.
That is the gap this series is about.
The Problem: Specs Instead of Outcomes
Hosting has been sold for years on the easiest things to compare: storage, bandwidth, uptime percentages, support badges, and one-click installs.
Those are not useless. They are just incomplete. The expensive failures usually happen in the parts that are harder to put in a pricing table.
An uptime guarantee does not tell you whether anyone will notice the site is down before your customers do. A backup feature does not tell you whether the restore has been tested. A plugin update button does not tell you whether the checkout will still work afterwards. A support badge does not tell you whether the person answering the ticket understands your stack.
This is where many hosting decisions go wrong. The comparison starts with what is easy to count, not what is expensive when it fails.
99.9% uptime still allows about 8 hours and 46 minutes of downtime a year. That may be acceptable for a hobby site. It is less amusing when the outage lands during a product launch, event registration window, or peak booking weekend. The guarantee may offer a small credit later. The customer who could not buy from you is not usually part of the refund calculation.
Unlimited storage usually has a limit. It just arrives as a surprise. The mechanism is simple: every platform has CPU, inode, file count, backup, and fair-use boundaries. The problem is not that limits exist. The problem is finding them for the first time when the site is already slow, blocked, or being upsold.
Round-the-clock support labels often mean the ticket system is awake. That is not the same as the person who can fix the problem being awake. For MHP, the honest position is different: monitoring runs around the clock, human response is generally available from 6am to 10pm NZT, and urgent alerts are prioritised by business impact. We do not run a round-the-clock call centre. We run a managed platform designed to detect problems early and get them in front of someone who can actually fix them.
Those distinctions matter because websites fail in specific ways. A server can be online while WordPress is broken. A backup can exist while no one knows whether it restores. A plugin can be patched while the business process it supports stops working.
The report can be happy while the customer is not.
That is why the useful hosting conversation starts after the headline features. The question is not only what the platform includes. The question is who owns the boring operational work when the site is busy, ageing, being updated, or recovering from a problem.
What Twenty Years of Hosting Actually Teaches You
After building and hosting sites for more than twenty years, the pattern becomes fairly clear. The same avoidable failures appear under different names: weak passwords, untested restores, rushed updates, plugin sprawl, no staging, no monitoring, and infrastructure chosen because it looked cheap on a comparison page.
The following eleven points are the operating rules behind how we think about WordPress hosting at MHP. They are not abstract preferences. They are the rules you end up with after cleaning up enough compromised sites, broken checkouts, expired certificates, failed restores, and update surprises.
The truths are grouped by theme here. Each will be unpacked as its own article.
Platform Choice
Truth #2: WordPress Is the Lingua Franca of the Web
WordPress powers a large share of the web, but market share is not the main reason it matters.
The practical reason is labour. SEO specialists, copywriters, marketing assistants, virtual admins, developers, and agencies already know WordPress. Choosing WordPress is choosing the largest labour market in the web industry.
That matters commercially. A business should not need a specialist handover every time it wants to change a landing page, publish an article, add tracking, or brief a new marketing person. WordPress is the common language of digital work, and common language reduces friction.
Truth #3: Open Source Guarantees Longevity
WordPress is not attractive because it is fashionable. It is attractive because it survives.
Closed platforms can change pricing, change strategy, retire features, or push customers into new plans. That may be fine for some businesses, but it is still dependency on one company’s incentives.
Open source does not remove all risk. It changes the risk. The code, ecosystem, hosting options, and developer market are not controlled by one board meeting. For a business that expects to be around for years, that matters. Your website should not age out because a platform’s investor story changed.
Plugin Philosophy
Truth #1: Fewer Plugins, More Custom Code
Plugins are useful. Plugin sprawl is expensive.
If a plugin exists to add a tiny site-specific behaviour, I would usually rather put that behaviour in a small custom mu-plugin. One per site, version-controlled, visible in the filesystem, and boring to maintain.
A plugin that saves three lines of code can still cost you a future upgrade cycle. It can add admin noise, remote dependencies, update risk, and a support trail that has nothing to do with the business outcome. Convenience is only convenient if it stays cheap to own.
Truth #6: Only 3-5 Plugins Per Vertical Actually Matter
Most businesses in a vertical need a small number of serious plugins and a larger number of decisions not to install things.
An ecommerce site may need WooCommerce and a handful of well-supported extensions. A booking site may need a specific booking engine. A professional services site may need forms, SEO, caching, and little else.
Every extra plugin adds code that must be updated, tested, secured, and understood. The issue is not plugin count as a moral score. The issue is maintenance surface. More moving parts means more things to inspect when production behaves badly.
Truth #9: Plugin Authors Inevitably Burn Out — Plan for It
Plugin dependency has a human supply chain.
Some plugins are maintained by excellent teams. Others are maintained by one person after work, on weekends, or until the economics stop making sense. That is not a criticism of those authors. It is how software ecosystems behave.
For business-critical behaviour, the question is not “does this plugin work today?” It is “what happens if this plugin is abandoned, sold, rewritten, or stops supporting our version?” Sometimes the right answer is still to use the plugin. Sometimes the cheaper long-term answer is a small custom solution owned by the site.
Security & Operations
Truth #4: Poor Passwords Are the Primary Attack Vector
The boring attack vector is still the one to fix first: weak or reused passwords.
Many compromises do not start with a sophisticated WordPress core flaw. They start with reused credentials, old admin accounts, missing two-factor authentication, forgotten users, or plugin vulnerabilities left unpatched.
The business consequence is ugly because the visible failure often comes late. The site redirects, sends spam, gets blocked by browsers, or quietly leaks trust before anyone inside the business knows what happened. Security work should start with credential hygiene, least privilege, updates, backups, and monitoring. Not drama. Just the basics done properly.
Truth #5: Backups Must Be Automated, Frequent, Off-Site, and Tested
A backup strategy has four parts: automated, frequent, off-site, and tested.
Leave one out and the failure mode is predictable. Manual backups get forgotten. Same-server backups disappear with the server. Untested backups produce a file when what you need is a working site.
A backup on the same server is a souvenir, not a recovery plan. The useful question is not “do backups exist?” The useful question is “how quickly can we restore the site to a known-good state, and when was that last tested?”
Truth #8: Monitoring Is Still Underused
Monitoring does not fix the site by itself. It fixes the worst failure mode: nobody knowing.
That sounds basic until you have taken over sites where the first alert came from a customer, a supplier, or someone trying to pay an invoice. For an accommodation provider, a retailer, or an event business, hours of unnoticed downtime can become real lost sales.
If your uptime monitoring depends on a customer texting you, you have built a very honest but fairly expensive alerting system.
Maintenance Discipline
Truth #7: Updates Should Be Scheduled and Deliberate, Not Rushed
Updates matter. Unsupervised change is the problem.
Automatic updates can be sensible for some low-risk patches, but business-critical WordPress sites need a deliberate update process. The mechanism is simple: update on staging, test the workflows that make money, then push live.
A rushed update on production can turn customers into testers. That is certainly one way to get customer feedback.
Truth #10: Staging Sites Are Non-Negotiable
I treat staging as basic professional discipline.
The cost comparison is not close. Testing first takes minutes. Repairing a broken production site can take hours, and those hours happen while customers are trying to use the site.
A staging site is boring. That is the point. It gives you somewhere to find the problem before the problem becomes public.
Infrastructure
Truth #11: AWS Public Cloud Beats Traditional VPS
Shared hosting versus VPS is an easy comparison, but it is no longer the most useful one.
The stronger question is whether the infrastructure is predictable, monitored, backed up, and configured for the workload. A VPS gives you a server. It does not automatically give you good caching, sensible backups, security posture, deployment discipline, or recovery.
We use AWS because predictability is the product. Customers are not buying AWS complexity. They are buying the boring parts already configured.
Why This Matters
Back to the accommodation business.
The fix was not a magic hosting plan. It was operational discipline: strong credentials, two-factor authentication, round-the-clock monitoring, automated off-site backups, a clearer restore path, and a staging environment for updates.
None of that is glamorous. That is why it works.
The value is not that the business owner now knows more about hosting. The value is that she has to think about it less. Good infrastructure removes avoidable decisions from busy people at exactly the moments when rushed decisions are most expensive.
The owner did not need a bigger storage allowance. She needed the site to stay clean, recover when something failed, and keep taking bookings. That is the difference between selling server space and taking technical ownership of a business website.
Managed hosting should be closer to a mechanic than a storage unit. You do not care about the brand of oil filter. You care that the engine starts on Monday morning.
What’s Next
Over the next twelve weeks I will unpack each of these eleven truths in detail: real incidents, practical rules, and the trade-offs behind them.
No affiliate listicles. No pretending a $9 plan and a production operating model are the same thing. Just the parts of hosting that tend to matter after the comparison table has stopped being useful.
If you are not sure whether your backups restore, your updates are tested, or your site is monitored properly, I am happy to take a look.
Do it once. Do it right.
