If AI can't change your website, you're already a generation behind

This June I walked a client through the way our team builds WordPress sites now. Before any of it worked, one thing had to come out: the page builder.

Not because it was broken. Because the AI couldn't read it.

The longer a site sits somewhere AI can't reach, the more it costs to keep — and that gap gets wider every month, not smaller.

There are two kinds of websites now

One kind an AI can change. The other kind a person has to change by hand.

On the first kind you say what you want. Move this section up. Build a new page for this service. Rewrite this block. Change the price. The AI does it, someone checks it, it goes live.

On the second kind, someone opens an editor, drags a box, nudges the spacing, saves, and then checks the page on a phone. Same result. A lot more of your money.

Being changeable by an AI is what a modern website means now. Not a feature to add later — the baseline. Most sites built on a page builder don't have it.

Some builders are adding AI features of their own, and that's fine. But the builder already under your site probably doesn't have one, and a box that writes you a headline is not the same thing as an AI that can rebuild a page. If yours is a hosted builder — Squarespace and its relatives — with no AI inside it, you're locked into the old way of working: open the editor, drag things, push the pixels back and forth. Instead of asking for the change and checking the result.

AI is good at code because code is what it read

AI models were trained on code. Enormous amounts of it. Code is text — every page, every style, every block is written down in a file that can be opened. Point an AI at a site like that and it reads the whole thing before it touches anything.

A page builder was never written for that reader. It was written for a person with a mouse. Elementor's own documentation says a page's data and layout are stored as JSON inside WordPress post metadata, in a private field that isn't visible in the dashboard. Divi keeps its layouts in the database the same way.

Read that as an owner, not as a developer. Your homepage isn't written down anywhere you can open. It's a saved arrangement inside a plugin, in a format nobody was meant to read — including the AI you'd like to point at it, and including the next team you hire.

You can still point AI at a WordPress site running Elementor. It works, and it works badly. It can't pick up enough of the page, so it guesses, and you get patches on top of patches instead of a clean change.

The other direction is the one worth knowing about, and it already works today. Give an AI access to all of your site's code and it reads the whole thing before it changes a line of it. It follows how the site is already built instead of guessing, so what comes back is a real change and not duct tape.

It does have to be set up properly. Somebody has to put the site in files, give the AI access to them, and write down ONCE how the site is meant to be built, so it doesn't invent a second way of doing everything. After that the job is describing the change and reading what came back.

Which is the part people get backwards. Custom-built used to be the expensive option. Now it's the advantage.

The bill you're already paying

None of this shows up as a line on an invoice. It shows up as people.

Somebody has to sit in that editor. A developer on retainer, a contractor, someone on your marketing team who learned that one builder. Every small change goes through that person, and every small change waits for them. That's the real price of a site AI can't read, and you're paying it right now.

On a site that lives in files, the change gets described, written, reviewed, and published.

Our SEO specialist ships to production without a developer, because the change is written down and somebody can read it before it goes live.

The part that doesn't get cheaper is the thinking. What the page should say, who it's for, what the offer actually is — that still takes people and meetings, and it should. What got cheap is everything after that decision. So a team the same size ships more pages, and the pages don't get worse.

So yes, you probably do want to move off it

If an AI can't reach your site, you want to get off it — and the longer you leave it, the more that move costs. Every page somebody adds in that editor is another page to move later. The problem grows while you decide.

It doesn't mean starting a rebuild this quarter. It means two things, in this order:

First, find out whether AI can be connected to the site you already have. Some setups allow it, sitting on top of what's there without touching what works. If yours does, do it now. It's the cheapest thing on this page and it gives you time back immediately.

Second, if your builder can't be reached at all, put a date on moving out. Not an intention — a date.

I'm not going to pretend the move is free. Taking a builder out of a live site is a real migration with a real budget and real risk, and anyone who tells you otherwise is selling something. What changed is that it's now a budget with a return instead of a nice-to-have.

Where you land matters less than people assume. A WordPress site with no page builder on it is already a good place to be, because the pages sit in files an AI can read. It doesn't have to be a fashionable stack. It has to be written down.

And if you have a big site with processes that work — a team who know the builder, a release routine, nothing on fire — that isn't a reason to skip this. It's the case where the bill is biggest, because every one of those small changes is going through a person. Connect AI to what you have, or plan the move out.

Your content team will get the hang of it in a few hours, and the real boost is how much it cuts labor costs — not some marketing hype. We've already seen it in our own team: we now get twice as much done with half the people.

Two questions to ask before your next website project

You don't need an opinion on which technology to use for your new website. Ask these instead, and ask them in writing:

• Can an AI make changes to this site? Show me what that looks like.
• Where will my pages live — in files, or inside a plugin's storage / closed system AI can't reach?

Any team should be able to answer each one in a paragraph. Where the answer gets vague, that vagueness is what you'll pay for.

TL;DR

Page builders were built for people. Code was built for machines.

The machine reading it now is better at it than most of us. That's the whole argument, and it's why the builder went from the easy option to the slow one.

If AI can be connected to your current site — connect it. If it can't, you're running a website from the generation before this one, and staying there costs you every month rather than once.

What I can't tell you is whether that stays true forever. A builder could start writing its pages into readable files, and this argument would move. I'm not predicting it, and I wouldn't plan around it.

We made the same move on our own site, for the same reason — we rebuilt norml.studio on Next.js and Sanity, and now we change it by describing what we want. I never saw the admin panel since moving out and never would go back to it.

If you have a WordPress site and you're not sure which of the two kinds you're on, that's a look at the site rather than a project. Start here.