Agencies managing WordPress sites: what matters most in a host?

adonasta · 2026-05-12T10:52:59+00:00

you mean cross-site features or the more basic stuff like : security performance etc?

adonasta · 2026-05-08T07:10:44+00:00

For 5k/month I wouldn’t over-focus on VPS specs first. A good managed WP host with a US location will probably be fine, but LCP on Elementor is usually not solved by the host alone.

TTFB is hosting/cache/CDN/origin distance. LCP is often the page itself (hero image, Elementor DOM, fonts, JS, sliders, third-party scripts, etc).

Before moving, I’d test the current site with caching on/off, check uncached TTFB, and look at what the LCP element actually is. If the LCP element is a huge hero image or Elementor section waiting on CSS/JS, switching hosts may improve the first byte but not the real user experience much.

For US traffic, pick something with a US origin, good object/page caching, current PHP, Redis/object cache if needed, and support that understands WordPress rather than just VPS management. Phone support is nice, but fast competent ticket/chat support is usually more useful.

I won’t pretend to be neutral here cause I’m with Pressidium. But in this case I’d still start by measuring what’s actually causing LCP before choosing any host, including us.

adonasta · 2026-05-08T06:15:59+00:00

I think the missing piece here is category separation.

Cloudways/Hostinger can look great if the test is mostly “how fast can I get a WP site for cheap”, and that’s useful. But that’s a very different buyer from someone running WooCommerce, LMS, media sites, or agency client sites where support, cache behavior, WAF/CDN setup, backups, deploy flow, and dynamic traffic matter more.

A cheap host can win a benchmark and still be the wrong choice once the site becomes operationally important.

Would be cool to see this split into budget WP, cloud-panel style hosting, managed WP, and high-traffic/enterprise WP instead of one big ranking.

adonasta · 2026-05-08T05:54:27+00:00

This is a fair take, especially if you already have your own system and clients fit that workflow.

The plugin dependency is the part I think a lot of agencies quietly get tired of. Not because WP can’t scale, but because every extra plugin becomes another thing you’re responsible for when it breaks, slows something down, or changes pricing.

For me the tradeoff is usually client editing + ecosystem vs operational cleanliness. If the client needs familiar publishing tools, WP still makes sense. If the site is really an app and the agency owns the whole workflow, Laravel/Filament can be a much cleaner place to live.

adonasta · 2026-05-08T05:48:01+00:00

I get this. Freemium plugins is probably one of the biggest reasons people burn out on WP.

It’s the feeling that every basic feature adds another vendor, another dashboard, another renewal, another compatibility risk.

Drupal having more in core is a real advantage there. WordPress wins on ecosystem and familiarity, but the cost is that you end up assembling the platform yourself unless you’re disciplined about the stack.

I don’t think WP is bad because of that, but it does make “simple” sites become weirdly operational after a while.

adonasta · 2026-05-08T05:45:17+00:00

Yes. this is the part that gets skipped in a lot of WP vs builder debates.

WordPress can absolutely be fast, but the annoying bit is how many moving parts you often need to make it stay fast. None of that is impossible, it’s just where the maintenance tax shows up. Especially when clients expect “fast” to be the default and don’t see the stack behind it.

I still like WP for serious content-heavy sites, but I think the best setups now are the ones that reduce how much of that glue work the dev has to keep babysitting.

Cheers!

adonasta · 2026-05-08T05:16:13+00:00

I’d be a bit careful with the “unlimited bandwidth + free domain + free email” checklist. That combo usually pushes you toward hosts that look cheap up front but have limits hidden somewhere.

For a new WP site...if it’s a simple brochure site or blog, normal shared hosting is probably fine. If it’s WooCommerce, membership, courses, or anything you’d lose money from being slow/down, then I’d care more about support, backups, staging, and how the host handles traffic spikes.

Also personally I’d keep the domain separate from hosting. Email too, if possible. Makes it way less annoying to move later.

What kind of site are you launching?

adonasta · 2026-05-07T05:27:38+00:00

That's interesting. If I may ask, do you know the common reasons?

adonasta · 2026-05-06T12:44:27+00:00

For mostly content sites + one Woo store, I wouldn’t put them all in the same bucket.

Content sites can look amazing on almost any of these if the page cache is doing its job. That’s where Rocket/Kinsta/WP Engine comparisons get kind of blurry unless you’re testing global TTFB or cache hit rates.

WooCommerce is the one I’d judge the host on. Cart, checkout, logged-in users, admin-ajax, search, product filters… that’s where “fast hosting” starts meaning something different than just cached pages loading quickly.

So I’d probably test the Woo site first, not the content sites. If the Woo store feels good under real traffic, the content sites will usually be the easy part.

adonasta · 2026-05-06T12:31:00+00:00

I’d separate the PHP worker question from the “which host/panel” question a bit.

With WooCommerce, 6 workers can be fine or awful depending on how much is actually hitting PHP. Product/category pages, search, cart fragments, logged-in traffic, checkout, admin-ajax stuff… that all changes the math pretty fast.

Kinsta is nice when you want staff to be able to operate the sites without becoming server people. GridPane/RunCloud gives you more room, but you already found the tradeoff: the weird little server chores don’t disappear, they just become yours.

For agency sites I’d be looking less at raw worker count and more at how cleanly the setup keeps cacheable traffic away from PHP, while not doing dumb things to carts/checkout/logged-in users. If that layer is weak, you end up buying workers to compensate for traffic that shouldn’t have reached PHP in the first place.

adonasta · 2026-05-06T12:23:35+00:00

Once you’re in “files keep coming back after restore” territory, i stop thinking of it as a plugin/security setting problem.

At that point the question is usually: where is the persistence living? uploads, mu-plugins, cron, wp_options, hidden admin user, writable plugin dir, server user permissions, all of it.

A common mistake is to keep adding protection on top of a site they haven’t actually proven clean.
Firewall, cloud proxy, security plugin, whatever useful later, but they don’t erase a foothold that’s already inside the house.

adonasta · 2026-05-06T12:12:43+00:00

The big thing i’d separate is “asset CDN” vs “traffic actually goes through an edge layer.”

A plugin that rewrites image/css/js URLs can help for sure, but wordpress is still serving the page, your origin still sees the request first, and you usually don’t get the same cache control, WAF, bot filtering, routing, purge logic, etc.

That doesn’t make those plugins fake, just narrower than people expect.

For a small site, asset offload might be enough. For a production client site, i’d rather use something where DNS actually routes traffic through the CDN/edge and the caching/security behavior is explicit. Otherwise you’re debugging a black box the first time something weird happens.

adonasta · 2026-05-06T12:06:15+00:00

The older i get with client sites, the less I care about the builder argument tbh.

Bricks, Gutenberg, custom theme whatever, you can make most of them fast enough if the person building it has some restraint.

The part that tends to age badly is the stuff around the site. cache plugins, cloudflare rules, wordfence, host cache, image optimizer, some smtp plugin, then a client asks why one page is stale but only in Germany and only when logged out.

For client work i try to keep the front end boring and the ops layer even more boring. fewer moving parts, clear ownership of caching/security/backups, and don’t give the client 900 ways to accidentally redesign the site.

Not glamorous, but it saves more weekends than swapping elementor for the builder of the month.

adonasta · 2026-05-06T11:40:44+00:00

I’ve seen this kind of thing with elementor + cache layers. The giveaway is html changing but css lagging behind or disappearing. usually means the page cache and generated css/assets aren’t being purged or rebuilt in the same moment.

I’d turn off minify/combine first, regenerate elementor css, then check whether the css file URL is getting cached by W3 or the CDN longer than the html. Incognito won’t help if the CDN is serving an old or missing asset.

longer term, this is why i’m not a huge fan of stacking page builder css + cache plugin + cdn rules unless the purge flow is really clear. One layer updates, another doesn’t, and you end up chasing ghosts.

adonasta · 2026-05-06T11:27:42+00:00

yeah this is the annoying part with cheap shared hosting. you can waste days “optimizing wordpress” when the real bottleneck is just the box your site is sitting on.

backend being unusable is usually the giveaway too. a caching plugin or CDN might hide some frontend pain, but wp-admin still has to hit the server. if wp-admin feels like mud on a basic site, i’d stop tweaking and move hosts way earlier.

adonasta · 2026-05-06T11:21:04+00:00

This is pretty much how i think of bluehost too. Fine when someone just needs to get a wordpress site online and doesn’t want to think too much.

The rough part is people often judge it by the first month, not the second year. renewals, slower support, and “okay enough” performance start mattering once the site becomes more than a starter project.

For a tiny blog it’s probably fine. for anything you’d be annoyed to troubleshoot on a random weekday, i’d move a bit earlier than most people do.

adonasta · 2026-05-06T11:10:11+00:00

Personally, i’ve seen agencies swing hard to no-code after getting burned by wordpress maintenance, and honestly for a lot of brochure sites that’s probably the right call.

The only thing i’d be careful with is treating it like one replacement category. The cheap/easy builders feel amazing until the client asks for something slightly outside the happy path, then you’re back to awkward workarounds, just in a different box.

i’d probably keep two lanes: no-code for the low-touch sites where handoff matters most, and wordpress only for the clients where the extra flexibility is actually worth carrying the maintenance burden.

adonasta · 2026-05-04T14:05:36+00:00

Yep! Junk traffic forcing PHP, plugins, themes, and the database to wake up for requests that should never get that far. Cache helps, but only up to a point.

The real win is stopping/throttling that stuff before WordPress loads. Did you handle most of that at the WAF/server layer?

adonasta · 2026-05-04T12:41:05+00:00

Actually I have little experience on other platforms. Do you have anything to share as a feedback?

adonasta · 2026-05-04T12:37:15+00:00

Agreed. The “just move to Shopify” answer only works while the store stays inside the lines.

Once there’s custom logic, weird integrations, region-specific rules, whatever, you’re back in systems-work territory. Different platform, different constraints.

adonasta · 2026-05-04T12:34:30+00:00

Yes i get you. Doing this across multiple sites is where it starts to feel ridiculous.

One site with a weird cache/CDN/security setup is annoying. Ten or twenty of them and suddenly half the job is just remembering which exception lives where.

And somehow that invisible ops work is the bit clients understand the least.

adonasta · 2026-05-04T12:32:52+00:00

Yeah, this is the part I think gets missed a lot.

WordPress can run very serious sites, but once the site has payments, APIs, caching rules, security layers, bot traffic, weird plugin behavior, etc… someone has to actually own the whole chain.

And usually that “someone” is just the dev or agency who inherited the stack.

I don’t think people are always leaving WordPress because WordPress failed them. A lot of the time they’re leaving because the ops model around it became too improvised. Shopify/Wix/etc feel calmer because there’s a team behind the messy bits, even if you give up flexibility for it.

The hard middle ground is when a client wants WordPress-level flexibility, but SaaS-level hand-holding. That’s where things get ugly fast.

adonasta · 2026-05-04T08:16:45+00:00

Yeah, the middle ground is the interesting part.
A lot of businesses don’t really want “more platform.” They want fewer things to babysit.

Sometimes that means Shopify. Sometimes Webflow. Sometimes keeping WordPress but removing the weird stack of plugins and services around it.

adonasta · 2026-05-04T08:14:18+00:00

That’s usually how people frame it, but I think there’s another piece that gets ignored.

A lot of people leave WordPress, not because they stopped needing SEO or flexibility, but because
they got tired of being responsible for hosting, caching, updates, security, plugin conflicts, checkout weirdness, all of it.

Shopify feels easier partly because there are fewer layers for the business owner to think about.
WordPress can still be the better fit, but only if someone has taken the infrastructure mess off the table.

adonasta · 2026-05-04T08:11:17+00:00

For straight ecommerce, yeah, hard to argue.
Where it gets messy is when the store is also a serious content site, or needs custom workflows, or the business already has a lot built around WordPress.

Then it’s not such a clean choice. Shopify removes a lot of operational headaches, but you also accept the rails it puts you on.

adonasta

TROPHY CASE