"But Who Maintains All Those AI Sites?" — A Courteous Answer From Someone Who Maintained 68 WordPress Ones

Every so often a WordPress YouTuber posts something that isn't a rage-bait thumbnail with an arrow pointing at a crying emoji, and it deserves better than a pile-on. Paul C at WPTuts has done exactly that. His video opens with the comments he gets — 'WordPress is cooked', 'why are web developers even needed anymore' — and instead of getting defensive he thinks out loud for ten minutes and then asks the audience a straight question.

He's polite about it, too. He explicitly says he isn't telling you you're wrong for using AI, that he uses AI every day, that this isn't judgemental. That's rarer than it should be in this argument, and I'd rather answer a fair question well than a stupid one loudly.

So let's take his questions seriously, one at a time. I'm not arguing from theory. At my peak I ran 68 WordPress sites for clients, the vast majority of them on Elementor. Semi-retired now, that's down to about 20 — and I've migrated half of those off WordPress entirely onto Lovable. I have been the person doing the maintenance he's asking about. That's the whole reason I have an opinion.

The question, stated properly

“"What happens when you have 30, 40, 50, 100 sites all created with AI and then you want to make changes to it? You have to go back and make those changes via AI. When there's changes to the API protocols or a payment gateway changes... you simply update the plug-in and you are back up and running. Whereas if you are handling it yourself via AI, you have to take care of all of that."”

That is the strongest argument the WordPress side has, and I want to be fair to it before I take it apart. The claim is that a plugin ecosystem is a maintenance-sharing co-operative. Thousands of sites pool the cost of tracking Stripe's API changes, and one vendor absorbs it on everyone's behalf. You pay a licence, you press Update, you go to lunch.

Beautiful theory. I lived inside it for over a decade. Here is what it actually looks like from the inside.

What 'someone else handles the updates' really means

I did this properly. I standardised on trusted plugins from serious vendors — Crocoblock, WP Rocket, Elementor, Rank Math, Wordfence. No dodgy nulled anything, no abandoned freebie from 2019 doing something load-bearing, no 'it had good reviews' installs. Textbook discipline. The exact strategy every WordPress professional will tell you protects you.

And the majority of my working days still went on plugin updates, conflict resolution, and unexplained weirdness.

Not some of my days. The majority. Update Elementor, a flex container drifts. Update the SEO plugin, schema output changes shape. Update the cache plugin, something that worked yesterday doesn't. Update WooCommerce, a payment gateway add-on lags a fortnight behind and now checkout throws a fatal for logged-out users on mobile Safari only.

Yesterday — actually yesterday, while this argument was going on — a client's news publishing site started losing its layout on some pages and not others. No deploy. No change. Nobody touched it. Obviously a caching issue. It resolved itself. I still don't know why, and I never will. That is the tax nobody puts in the pricing table.

“The plugin model doesn't remove maintenance. It converts your maintenance into someone else's release schedule, and then bills you for the privilege of reacting to it.”

Paul frames AI-built sites as making you 'the person that has to handle updates.' I'd gently point out that I already was that person. I just wasn't allowed to choose when.

The dependency count is the whole argument

Here's the bit that gets skipped. The maintenance question isn't 'AI versus plugins.' It's 'how many independently-versioned moving parts does this site have?'

A well-behaved Elementor business site: WordPress core, PHP, MySQL, a theme, a page builder, the builder's pro add-ons, a form plugin, a caching plugin, an image optimiser, an SEO plugin, a security plugin, a backup plugin, a cookie banner, an analytics connector, and a small pile of glue. Twenty-plus release cycles from fifteen-plus organisations, all shipping on their own calendars, into one shared PHP process, on a schedule none of them coordinate.

One of my migrated sites: a React front end, a Postgres database with row-level security, auth, storage, and a handful of server functions. Managed platform, managed database, managed auth. Payment gateway talked to directly through its official, versioned API — which, contrary to the way this gets argued, does not lurch about randomly. Stripe versions its API and keeps old versions working for years precisely so that nobody has to hold hands with a plugin author to get paid.

That's not 'no maintenance'. It's a maintenance surface small enough that I can hold it in my head, and — critically — one where nothing changes underneath me unless I choose to change it. Nobody ships a marketing nag into my checkout page overnight.

'Why reinvent the wheel?' Because check the wheel

The video's other core point is a good one: e-commerce and CMS are solved problems, tested, maintained by other people, free at the point of use. Why rebuild them?

Right. Let's check the state of the tested, maintained, free thing. WP Goldmine crawled all 60,257 plugins in the WordPress.org directory on 1 August 2026 and published the numbers:

• →43.8% of the directory — 26,387 plugins — has not shipped an update in two years. 39.4% hasn't in three.
• →207 plugins with 10,000+ active installs each are abandoned outright. That's a floor of two million live sites running dead code.
• →The single most-installed abandoned plugin is a brute-force login protection plugin: 300,000+ installs, nothing since April 2023, still rated 4.6 stars, because star ratings never decay and last-updated dates sit below the fold.
• →And the maintained end isn't a refuge: WooCommerce PayPal Payments sits at 2.8/5 across 800,000 installs, Google for WooCommerce at 2.7, and SiteGround's own AI Agent plugin at 1.4/5 on a million sites. These are actively updated. That's the good list.

So yes — the wheel exists, and it's shared, and it's maintained by other people. Roughly half the wheels in the shop have nobody behind them, the labels still say five stars, and the shop has no removal process for abandonment because the plugin count is a marketing asset.

'Someone else maintains it' is only reassuring if you check whether anyone actually does. The honest version of the pitch is: someone else maintains it, probably, until they get bored, sell to a private-equity roll-up, or die, and you will find out on a Friday.

The age problem, which is not snobbery, it's arithmetic

WordPress shipped in 2003. It is 23 years old. It was forked from b2/cafelog to make blogging easier, in an era before smartphones, before HTTPS by default, before JSON was a thing anybody cared about, before the word 'framework' meant what it means now.

PHP is older still — 1995 — and while modern PHP 8.x is genuinely a decent language, WordPress cannot use it as one. Backwards compatibility is WordPress's headline virtue and its structural curse: the plugin API is a global hook bus where any of your twenty plugins can filter any other plugin's output, in any order, with no contract and no type safety. That isn't a bug in any single plugin. It is the architecture. It's why 'unexplained weirdness' is a recognised phase of the WordPress working day and why conflict resolution is a billable skill rather than an embarrassment.

And every one of those 23 years of compatibility promises is why a pre-auth remote code execution chain in core — wp2shell, CVE-2026-60137 and CVE-2026-63030 — was possible at all in 2026. Nobody gets to hand-wave the security column at AI-built sites while core itself is handing out keys.

'Security and things are being handled for you'

By whom, exactly? That's the question I'd put back, courteously.

On the WordPress side, 'handled' means: core auto-updates for minors, plugin vendors patching on their own timetable, and you running a security plugin whose job is to sit in front of the other twenty-five plugins and hope. Handled means Wordfence emailing you about a plugin whose author last shipped in 2021.

On my migrated sites, 'handled' means: no plugin attack surface at all, database access governed by row-level policies rather than whatever a plugin decided to trust, and an AI agent that runs a security review of every site weekly and tells me what it found. Uptime monitored. Nothing to log into and patch. Nothing to conflict.

Neither of those is magic. One of them has 26,387 abandoned attack surfaces in its supply chain and one of them doesn't.

The bit I genuinely cannot explain, and it matters

Here's the observation that changed my mind harder than any argument in any forum.

For years I tuned WordPress sites for SEO properly — content, semantic structure, on-page, schema, internal linking, Rank Math configured by someone who knew what he was doing, WP Rocket configured aggressively, premium VPS hosting rather than cheap shared nonsense. And they'd rank... fine. Never as well as the work deserved. I could never explain the gap.

“The AI-built replacements rank 50–75% better in the SERPs than the WordPress versions of the same sites, with the same content, written by the same person.”

I can't prove the mechanism. My best guess is page speed and the absence of thirty scripts fighting each other, plus the fact that a static-first, server-rendered page doesn't need three layers of caching to fake being fast. But I don't need the mechanism to act on the result. Same content, same author, same niche, better rankings — and no caching plugin to tune, because nothing needed hiding.

Which raises the uncomfortable question the WordPress performance industry exists to avoid: if advanced caching is mandatory, what exactly is being cached over?

'Do you want to be the person handling all this?' Yes. Because I already was.

This is where I'd answer the video's closing question directly and without sarcasm.

I despise logging into a WordPress site now. Not because of tribalism, and not because AI told me to. Because the maintenance robbed me of my creativity. There were days — frequent days — where I shut the machines down and thought: I did nothing constructive today. I updated things, I fixed things that broke because I updated things, and I billed for it. That's not a career. That's a treadmill with an invoice attached.

The AI-built sites gave those days back. And to be concrete, because 'AI can't do real sites' is the usual comeback: on Lovable I've shipped blogging platforms, membership sites with gated content and roles, and working e-commerce. They run, they run at volume, and they don't need a Tuesday sacrificed to them.

Where I think the video is right

I'm not going to pretend it's all wrong, because it isn't:

• →You are the maintainer now. Correct, and people should hear it. If you don't understand what you shipped, you have no business selling it. The difference is that you were always the maintainer — you just used to be one with less control.
• →Fleet-scale change is a real problem. Making the same change across 50 AI-built sites is genuine work. Though I'd note that WordPress solved this with ManageWP-style dashboards precisely because updating 50 WordPress sites was already a full-time job — you don't build tooling for a problem you don't have.
• →Don't rebuild what's genuinely solved. Payments, auth, database, storage — use platforms for those. That's exactly what the modern stack does; it just uses managed services with versioned APIs rather than a plugin bolted into a PHP process.
• →AI progress is plateauing into incremental gains. Probably true, and irrelevant to the argument — the tooling as it stands today is already sufficient. Nobody needs Claude Megacapable 5000 to ship a brochure site with a booking form.

Where I think it's wrong

The framing. The video quietly compares AI-built sites as they are today against WordPress as it's advertised — an ecosystem where maintenance is handled, security is handled, and plugins are updated by attentive vendors. Compare against WordPress as it actually is in August 2026 and the ledger changes: 43.8% of the directory abandoned, payment plugins at 2.8 stars, a pre-auth RCE in core, Elementor laying off a third of its staff in June 2026 and blaming AI rather than its own market share, and the platform's two biggest commercial powers — Automattic and WP Engine — having spent the better part of two years in litigation over who controls the supply chain that everyone's 'someone else maintains it' argument depends on.

That last one is the part I'd most like an answer to from the WordPress side, and I ask it without any pleasure. The maintenance-sharing co-operative only works if the co-operative is stable. When the person who controls wordpress.org can unilaterally cut a major host out of the update infrastructure, 'you simply press Update' stops being a technical statement and becomes a political one.

So: where am I in the journey?

He asks. Here's my honest answer, and it isn't a victory lap.

Sixty-eight sites down to twenty, half of them migrated, and I do not see myself ever building another website with WordPress. Not out of fashion. Out of accounting. The maintenance line item never came down no matter how disciplined I was, the SEO ceiling never lifted no matter how much I tuned, and the creative days never came back until I left.

And no, I don't want to talk about Elementor's updates, add-ons and marketing nags. I've served my time.

Genuine credit to Paul for asking the question in good faith rather than farming outrage with it. The answer just happens to be one his platform won't enjoy: the maintenance burden he's warning us about is the one we're leaving.