AI for WordPress: What Works, What Breaks Your Site

Ask any AI model for a WordPress plugin that adds a custom post type and it will produce working code immediately. Ask it to add a form that saves to the database and it will do that too, often without a nonce, without sanitising input, and with a direct query where WordPress has a perfectly good API.

I build WordPress sites and I test software professionally, so I read a lot of AI-generated PHP. It is genuinely useful. It also has a consistent set of blind spots, and on WordPress those blind spots have a specific cost: your site is the one running the code, on a platform that is scanned by bots continuously.

Where AI is genuinely good at WordPress

Boilerplate you have written a hundred times

Custom post types, taxonomies, meta boxes, ACF field group definitions, enqueue functions, WP_Query arguments. This is repetitive, well-documented, heavily represented in training data, and AI produces it accurately. This alone saves real hours.

Explaining somebody else's theme

Inheriting a site built by someone who left no documentation is a normal part of this job. Pasting an unfamiliar function and asking what it does is much faster than reading the whole theme. Verify what it tells you, but as a way in, it works.

Regex, wp-config snippets and .htaccess rules

Fiddly, easy to get subtly wrong, and easy to verify once written. A good fit.

Content drafting, with a caveat

AI drafts product descriptions and category copy quickly. Published unedited across a hundred pages, it is exactly the kind of scaled, low-value content Google has been explicit about devaluing. Use it as a first draft that a human rewrites, not as a publishing pipeline.

What it reliably gets wrong

Missing nonces and capability checks

This is the most common one by a distance. AI-generated admin forms and AJAX handlers frequently skip both the nonce verification and the current_user_can check. The code works perfectly in testing, because you are logged in as an administrator. It also lets any logged-in subscriber trigger the action.

Every form handler needs both. Ask specifically for them. The model will add them correctly when prompted, it just does not volunteer them.

Unsanitised input and unescaped output

WordPress has sanitize_text_field, esc_html, esc_url, esc_attr and wpdb->prepare for exactly this. AI-generated code often skips them, which is how you get a stored XSS in an admin field or an injectable query. On a site with more than one user account, that matters.

Deprecated and invented functions

WordPress is old and its training data spans twenty years, so you get functions deprecated in 2016 alongside current ones. Occasionally you get a function that reads plausibly and does not exist at all. Check anything unfamiliar against the developer handbook before it goes near a live site.

Queries inside loops

AI writes correct-looking code that runs a database query for every post in a loop. On the ten posts in your test environment it is instant. On a category page with five hundred products it is the reason the page takes eight seconds, a problem I cover from the other direction in WordPress speed optimization.

Page builder reality

AI does not know that the site runs Elementor, that the client edits pages themselves, and that a hardcoded template will be overwritten the first time someone opens the editor. It writes technically correct code for the wrong architecture.

A review checklist for AI-written WordPress code

Before anything generated goes live, I check these six things. It takes about five minutes and catches nearly everything.

• Does every form or AJAX handler verify a nonce and check user capability?
• Is every input sanitised and every output escaped?
• Does any function here not exist in the current WordPress version?
• Is there a database query inside a loop?
• Does it respect the theme, page builder and plugin architecture already in place?
• Does it still work with the plugin deactivated and reactivated, and after a WordPress update?

The one rule

Do not run code on a live site that you cannot explain. Not because AI code is bad, much of it is fine. But because the site will eventually break at an inconvenient moment, and debugging code nobody in the room understands is a genuinely bad afternoon.

If you cannot explain what a generated function does, that is the signal to read it properly rather than the signal to deploy it.

Related

The broader version of this problem: vibe coding risks. Security specifics: WordPress security checklist. Recent builds: portfolio.

Digər yazılar