Which WordPress hosting do you actually need?

Both plans sit on the same autoscaling cloud, with the same unlimited LVE resources, the same free SSL, the same daily backups and the same choice of data centre in the UK, the US or Asia. Nobody puts the slow servers behind the cheaper label.

What differs is the tooling on top. WordPress hosting gives you one-click staging, automatic core updates and the WordPress Tools section of the My365i Control Panel. Web hosting gives you the application installer instead: WordPress is in there, and so are Joomla, phpBB, Drupal and the rest of the eighty-odd applications on the list.

Here is the part most comparison pages skip. If you run one WordPress site, never touch staging, and update by hand anyway, the web hosting plan does the same job at the same size. Choose on what you actually run and who maintains it, not on which label has the word WordPress in it.

As a worked example of the platform doing its share: a South Staffordshire locksmith site launched in April 2026 on the standard Linux web hosting plan. It is hand-coded rather than built in WordPress, and it scored a perfect 100 on mobile PageSpeed from day one.

The UK market splits fairly cleanly. Basic shared hosting runs around £3 to £6 a month, managed WordPress hosting around £6 to £15, and managed cloud servers from about £10 upwards with no real ceiling. Our own plans sit inside that middle band. The current figure is on the plan pages rather than typed into an answer that will quietly age.

The price on the sign-up page is often not the price you will pay.

• Renewal. An introductory rate that triples in year two is the oldest trick in hosting. Ask what it renews at before you buy, not after.
• What is bolted on. SSL, backups, staging and migration are chargeable extras at some hosts. If any of them costs more, add it to the headline and compare again.
• What you do yourself. Cheap hosting really is cheap if your time is free. It stops being cheap the first evening you lose to a white screen.

The upgrade path matters as much as the entry price. A UK employment law firm has hosted with us for close to twenty years, through several full rebuilds of its site. When the traffic outgrew the standard package we added the per-site Turbo upgrade to the plan it already had, rather than move the firm onto a standalone Turbo plan, because that was cheaper and did the same job. A host that only ever proposes the bigger plan is telling you something.

Managed means the platform work is ours: server patching, PHP versions, the daily backup run, malware scanning, edge caching, and the SSL that renews itself. It does not mean we maintain your plugins and themes. That is a separate service, and any host implying otherwise is arranging an argument for later.

The honest test is not the feature list. It is what happens when you ask for help. Ours is a helpdesk: you raise a ticket and a person answers it, seven days a week including evenings, weekends and bank holidays. There is no phone support desk, no priority tier and no urgent flag, because every ticket is treated as the priority.

We publish the numbers rather than imply scale. The helpdesk has handled 508 tickets in its entire lifetime, counted on 15 August 2026. At the previous count on 26 July it stood at 498, five of them open that day, against 244 live hosting packages. That is roughly two tickets per package across the whole life of the platform. It is a small number and it is small on purpose.

Eleven of those tickets have been published in full, with their timestamps. They include one submitted at 22:52 on a weekday and answered at 22:56, and a Saturday-night beginner question about email answered on Sunday morning with a screencast recorded for that one customer rather than a link to a knowledge base article.

WooCommerce hosting is sized differently from the rest, and this is why. A brochure site can serve almost every visitor a cached copy. A shop cannot. Cart, checkout, My Account and anything behind a login has to be built fresh for each shopper, so the work lands on PHP and MySQL where no amount of page caching helps.

That is why average traffic is the wrong number to size against. What hurts is the peak. Two of our own customers show the two shapes it takes. A UK community organisation sells course places through WooCommerce and an event ticket plugin, so its load arrives in short violent bursts the moment a new course opens for booking. A store in the Netherlands runs a heavy WooCommerce catalogue alongside a custom membership system for NFC business cards, so its load is steady and sustained, with database work on almost every page a member touches.

Neither needed a bigger plan. Both took the per-site Turbo upgrade on the package they already had, which is where the extra compute lives: 4.20 GHz processors, NVMe storage, 5 GB of MySQL and CDN pre-caching. Unlimited LVE resources are standard on every plan here, so that is not what the upgrade buys.

For most small shops, none of this applies yet. Start on a plan where you hold the backup controls, because a shop that loses its orders table has lost money rather than a weekend, and watch your checkout timings before you spend anything else.

The sequence is the whole trick. It removes the downtime by design rather than by luck.

1. The site is copied to the new server. You do this yourself from the Migration Centre in the control panel: pick your old host, enter its login once, choose what to bring. Your live site carries on serving visitors from the old host throughout, because nothing has been pointed anywhere yet.
2. You check the copy on a temporary address. This is the step people skip and then regret. Click the forms. Log into the admin. Buy something, if you sell things.
3. The domain is pointed at the new server. Visitors reach whichever copy their DNS has caught up with, and both are working sites, so nobody sees an error.
4. The old host stays paid for a week or two. Cancelling on switchover day is how a missed problem becomes an unrecoverable one.

One thing to be clear about, because it is where expectations most often go wrong: a migration copies the site as it is. We do not rebuild it, redesign it or modernise it on the way across. Core files are verified against the WordPress Checksum Report and anything that has been tampered with is replaced from wordpress.org. Themes and plugins are inventoried, anything abandoned or badly out of date is flagged to you, and then you decide. It is your site.

The other honest note is about that temporary address. Every package gets one, and WordPress will cheerfully record it as your site URL if you configure the site while looking at it. It confuses nearly everybody the first time, so ask rather than assume you have broken something.

Google has no opinion about who you pay for hosting. What it notices is a change in what it finds at a URL. So the risk is never the move itself, it is the mistakes that ride along with it.

• URLs that change. A rebuild disguised as a migration, or a permalink structure that resets. If a URL has to change, it needs a 301 to its replacement, and that redirect map is written before the switch, not after somebody notices the traffic has gone.
• The temporary address getting indexed. Two crawlable copies of one site is a real problem. Keep the staging or temporary copy blocked until the switch is done.
• A robots.txt copied across with the block still in it. Staging environments are usually set to disallow everything. Copy that file to live and you have quietly deindexed yourself.
• A split between http and https. Get SSL issued and forcing before you point the domain, not after.

Once you have switched, watch Search Console rather than your instincts. Resubmit the sitemap, check the coverage report for anything new, and give it a fortnight. Positions bounce for reasons that have nothing to do with you, and reading a three-day dip as damage is how people talk themselves into undoing a good decision.

Keep one expectation flat, though. A faster host does not raise rankings by itself, it removes a constraint. If the site was slow because of what runs inside it, it will be slow on the new host too.

Mailboxes are created on the new host first, then their contents are copied across while the old mailboxes are still receiving. When DNS moves, new mail starts arriving at the new server. Anything that landed on the old one during propagation gets pulled over by a second sync, and that step is what closes the classic migration gap where a day of email quietly vanishes.

Then there is authentication, which is where most post-move email trouble actually lives. Your domain needs SPF, DKIM and DMARC records that match whoever now sends your mail. Two patterns from real tickets are worth carrying with you.

There can only be one SPF record. A customer with six business domains started bouncing off Gmail with a 550-5.7.26 rejection in January 2024, when Gmail began enforcing sender authentication. The cause was a second SPF record left behind by a plugin integration nobody remembered setting up. Two records is not twice the permission, it is a failed check. Merge the includes into one record and keep it that way.

Read the bounce before you touch DNS. Another customer moved a personal domain and a 1.8 GB mailbox to us, then had his first test message rejected by Gmail on SPF. It looked exactly like our record was at fault. The bounce headers named the old provider's mail server: his phone was still sending through the account he had just left. Editing the DNS record would have broken something that was working correctly.

Four clocks run at once, and only one of them is the actual work.

• Copying and testing the site. Under an hour for a typical small business site. Longer if the database is large or the media library holds years of unpruned uploads.
• Your checking time. However long you need. This is the only part we cannot compress and the only part worth not rushing.
• DNS propagation. Usually minutes to a few hours, occasionally up to 24. Lowering the TTL the day before shortens it.
• A registrar transfer, if the domain is moving too. A .uk domain is the fast case and usually the quickest thing in the whole job: it moves on an IPS tag change and is typically near enough instant. Everything else runs from a few hours to seven days, seven being the worst case rather than the expectation.

Two that went the way they should. A .com transfer quoted at the usual seven days completed in 109 minutes, with the mailbox migrated and DKIM and DMARC configured the same afternoon. A web designer's first client site was migrated, transferred, secured and switched live inside a single ticket on his first day with us.

And one that went the other way, because the slow cases are the instructive ones. A .co.uk took eight days end to end, which is notable mainly because .uk is normally the near-instant one. Almost none of that was the transfer itself: it went on waiting for the previous registrar, and one round trip of it on an autocorrect, the IPS tag STACK having been typed as STASH. Nothing about the TLD made it slow. A third party did.

So the practical answer is: a .uk domain will very likely be done before you have finished checking the site, anything else is worth allowing a week for while expecting to finish sooner, and do not book the switch for a Friday afternoon.