I’ve been opening the bonnet on AI-built WordPress sites. Here’s what’s inside.

Before I get into this: I’m not writing it to have a go at anyone. AI tools are impressive. The marketing is compelling. The idea that you can build yourself a professional website without hiring a developer is genuinely appealing, and if you gave it a go, that was a reasonable call based on what you’d been told.

The problem isn’t that you used AI. It’s what you probably weren’t told about what happens six months later.

Over the past year or so I’ve had a steady trickle of a particular kind of job land in my inbox – someone arriving with a WordPress site that’s been built, or heavily modified, by an AI tool with no developer involved at any point. Often the site looks fine on the surface. Sometimes it looks really good. The problems tend to show up later, at the worst possible moment, and by the time someone with a bit of experience looks at it, things are worse than they needed to be.

So here’s what I keep finding.

It works now. It won’t later.

AI-generated code is optimised to work right this minute, in the context it was given. It isn’t written with six months’ time in mind – when WordPress releases a major update, when a plugin you rely on changes its API, when you want to add something new and the existing code wasn’t written to be extended.

The site runs fine until something changes. Then something breaks. And the break is usually hard to diagnose, because the code wasn’t written by someone who understood what they were doing – it was generated by a tool that produced something that seemed to work at the time.

I’ve had a poke around plenty of these codebases. Functions duplicated across three or four files. Database queries written straight into templates. Security nonces missing, or there but implemented wrong. None of it is visible from the front end. All of it causes real problems when something shifts.

Updates are where it usually falls over

WordPress updates constantly. Core, plugins, PHP versions. A well-built site handles that cleanly because it was built cleanly.

AI-built sites often don’t.

The reason is that AI tools reach for the quickest solution, not the most correct one. That frequently means overriding core WordPress behaviour in ways that work in isolation but fall to bits the moment the thing being overridden gets updated. I’ve seen AI-generated code that modifies WordPress core files directly – something no developer with any experience would ever do, because it gets wiped on the next update. I’ve seen plugins recommended by AI tools that were abandoned years ago and haven’t been touched since.

When the update runs and something breaks, the owner has no idea why. There’s no developer to ring. No documentation. Just a broken site and no thread to pull on.

Nobody actually owns the code

This is the one that takes people by surprise.

When a developer builds your site, they understand what’s there. Something goes wrong, they can fix it. You need a change, they can tell you what it affects. When your site came out of a series of chat sessions, nobody owns it in any meaningful sense. The AI doesn’t remember. You probably can’t explain to another developer why specific decisions got made, because nobody really made them. They just emerged from a series of prompts.

A developer arriving at a site like this is working blind. Reverse-engineering decisions that were never really decisions takes time. Time costs money. And sometimes the most honest thing I can tell someone is that a rebuild is cheaper than a fix.

Security is usually an afterthought, if it’s a thought at all

Any developer with a bit of experience thinks about security the whole way through a build. Sanitising input, escaping output, capability checks, nonces, preventing SQL injection – these are habits, not things you bolt on at the end.

AI tools solve the task they’re given. Security has to be explicitly asked for, and most people building their own site don’t know which questions to ask. The result is code that does what you wanted but leaves doors open that a developer would have shut without thinking.

I’ve found AI-generated form handlers passing user input straight into the database with no sanitisation. Contact forms that don’t check whether the request is even legitimate before processing it. Admin functionality accessible to logged-in users who should never have it.

None of it is obvious. Right up until it isn’t.

What to do if this sounds familiar

If any of this is landing close to home, don’t panic. A site that’s currently working is better than no site. The question is what to do next.

If your site is broken right now – after an update, a plugin conflict, something mysterious – get a proper diagnosis before anyone starts clicking about trying to fix it. Uninformed tinkering with a broken WordPress site tends to make recovery harder, not easier. We offer a free assessment for exactly this kind of situation – we’ll take a look, tell you honestly what’s wrong, and tell you what it would take to sort it.

If your site is currently working but you’re worried – a developer can review what’s there, identify the risks, and tell you what needs attention. Some AI-built sites are actually in reasonable shape and don’t need much. Others need more. Either way, it’s better to know than to find out when something falls over.

If you’re thinking about using AI tools to build or substantially change your site – by all means use them, but with a developer in the loop. AI tools are genuinely useful when someone who understands the code is reviewing what gets generated. They’re not a substitute for that understanding.

The honest bit

AI tools aren’t bad. The problem is the gap between what they’re marketed as and what they actually are. They’re powerful tools for people who already know what they’re doing. In the hands of someone without that background, they produce code that looks right but isn’t – and that creates real problems that real businesses end up paying to fix.

I’ve been building and maintaining WordPress sites for over 20 years. I mention that not to boast but to give a sense of where I’m coming from when I look at these codebases. The stuff I’ve described isn’t edge cases or theoretical risks. It’s what I keep finding, on real sites, belonging to real businesses.

If you’re dealing with the fallout from an AI-built site – or you just want to know what’s actually under the bonnet before something goes wrong – get in touch. I’ll give you a straight answer.

Mark Benewith

Xinc Digital is led by Mark Benewith. With over 20 years building and maintaining WordPress sites — across hosting infrastructure, custom plugin development, WooCommerce, security, and performance — the technical work is handled by someone who’s seen it all.

When you’re on a care plan, you’re not dealing with a junior developer or an overseas helpdesk. You’re working directly with the person who knows your site, handles your updates, and responds when something needs attention.

For operational continuity, we work with a trusted group of developers we’ve collaborated with over the years — so there’s always cover if something requires additional capacity. Your site won’t be left unattended.

We’re straightforward about scope. Care plans cover technical work — updates, security, fixes, performance.