In May, WordPress shipped the most consequential release in its history. Version 7.0 brought AI into the core of the CMS platform for the first time, and the people who built it made a choice that's easy to miss in all the noise about the feature itself. They left it switched off.
The infrastructure is in the codebase, but nothing reaches an AI service until the site owner connects a provider and turns it on. Upgrade a site and walk away, and it behaves exactly as it did the day before.
The on-switch was handed to the person who owns the site, not flipped on their behalf.
Co-founder of Flashcloud.
It's worth sitting with how deliberate that was. The team had just shipped the most powerful capability the platform has ever carried, and the posture they chose for it was opt-in, plugin-based, with nothing injected into anyone's site automatically.
In an industry that loves a sensible default, that restraint was itself a statement: this decision is yours to make.
Then the more interesting thing happened.
A reasonable instinct, taken one step too far
Within days of the release, SiteGround, one of the most established managed WordPress hosting companies in the business, did close to the opposite. It pre-installed and activated its own AI product across its customer base, configured it as the default connector, and bundled in a generous allowance of free usage to get people going.
The active-install count crossed a million almost immediately. Plenty of site owners logged in to find capable new software already running on sites they had never touched to put it there.
I want to be fair to SiteGround here, because fairness is where the useful lesson lives. This is a serious operator with a long, well-earned reputation, and the product it built is genuinely good, a real piece of engineering rather than a thin upsell. The reasoning behind the rollout isn't hard to reconstruct either.
The "correct" path to native AI is fiddly, and most people would stall somewhere in the middle and never finish it. Pre-installing the whole thing, free usage attached, removes that friction in a single stroke. From an operator's chair, that's a tempting piece of customer service, and I've sat in that chair for the better part of two decades. I understand the pull of it completely.
So this isn't a story about a company behaving badly. It's a story about a reasonable instinct (reduce friction, help the customer get to the good part faster) carried one step past the line. And the reaction told us exactly where that line is.
The objection wasn't AI. It was consent.
The pushback
The pushback was quick and pointed, and the striking thing about it was its subject. Almost none of it was about whether AI belongs in WordPress, or whether the tool was any good. Many of the people objecting use AI every day. What they objected to was finding it already switched on.
That distinction matters more than it first appears, because it separates two things the industry tends to blur: the quality of a change, and the consent to it. A genuinely good feature, installed without asking, still lands as something done to you rather than for you.
The standard defense (it's optional, you can remove it whenever you like) is all true, and none of it is the same as agreement. "We switched it on and you can switch it off" quietly moves the work of noticing, understanding, and undoing onto the customer, for a change they never approved. "Here's one-click setup if you'd like it" delivers the identical convenience and leaves the decision where it belongs.
This isn't a new tension. Webhosting companies have always made changes customers never see, and most of the time they're glad we do. But AI is going to surface this question over and over, because it's the most consequential thing most of us will ever be tempted to switch on by default. Getting the principle right now, while the stakes are still mostly reputational, is a lot cheaper than getting it wrong later.
The line worth holding
The honest objection to all of this is that hosts intervene on customer sites all the time, and nobody asks permission for that. True, and the distinction is the whole point.
When a host patches a vulnerability, blocks a malicious request, or disables a plugin that's being actively exploited, it's protecting the customer's site and the wider platform from harm. Customers extend us that trust precisely because it's defensive, narrow, and in their interest. Installing a new product is a different category of act.
It isn't protecting anything; it's changing what the website is. The trouble starts when the second borrows the permission we were granted for the first, when goodwill extended for security work quietly gets spent on shipping features. That's the line. Maintain the platform freely; change the product only with a yes.
Holding it doesn't mean making customers do more work. New capabilities can arrive off by default and one click away for anyone who wants them. Multi-site managers can get a single place to see and control what's running, rather than a hunt site by site.
Anything a host pushes can be pulled back as easily as it went out. And changes can be announced in plain language before they happen, including how to say no, because the absence of a clear, opt-out-inclusive heads-up is usually what turns an ordinary product decision into a breach of trust.
Parts of the ecosystem are already moving this way. None of it is anti-AI. If anything, it's what lets hosts lean into AI confidently, because customers can trust that nothing shows up uninvited.
Whose site is it, anyway?
As AI moves from novelty to default across the web, every host will face its own version of this question. Here's a genuinely useful new capability. Do we switch it on for everyone, or do we let people choose? The convenient answer and the right answer won't always be the same one, and the gap between them is where reputations are quietly made or lost.
It helps to remember who actually lives with the answer. When a host changes something on a site, the host moves on to the next ticket. The owner is the one who stays: the one whose visitor hits a page that behaves differently than it did the day before, whose inbox fills up when something looks off, whose name is on the business the site exists to represent. We get to make the change. They have to live with it. That asymmetry, more than anything written into the terms of service, is the real reason asking first isn't a nicety. It's an acknowledgement that the consequences were never ours to carry in the first place.
The site owners who pushed back this spring weren't standing against progress. Most of them, I'd wager, will happily adopt the very tooling they objected to, the moment they get to be the ones who switch it on. They were defending something simple that's easy to lose sight of when the technology is moving this fast: it's their site. Not the site we host for them. Theirs. A host's authority runs right up to the edge of the customer's ownership and stops there, and the best operators I've worked alongside never needed reminding of it. They saw their role as stewardship rather than possession.
That trust is the real product. Not the servers, not the dashboard, not even the support, though every bit of it matters. What a customer is buying is the confidence that nothing happens to their site that they didn't choose, and that when we do step in uninvited, it's to protect what's theirs and never to quietly redraw it. Trust like that takes years to earn and an afternoon to spend. Asking first is simply how you keep from spending it.
Get the boundary right, and AI in hosting becomes exactly what it should be: useful, and genuinely welcome. Get it wrong, and even the best feature in the world arrives as something taken rather than offered. The difference was never the technology. It was only ever whether anyone thought to ask.
We tested, reviewed, and rated the best website builders.
This article was produced as part of TechRadar Pro Perspectives, our channel to feature the best and brightest minds in the technology industry today.
The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: https://www.techradar.com/pro/perspectives-how-to-submit