Using AI to Improve an Existing WordPress Site: What You Can Change, and What You Should Leave Alone
For an established site with indexed pages, rankings and working habits, distinguish content from structure before deciding where AI fits.
AI × WordPress Series · Part 6 of 8
For an established site with indexed pages, rankings and working habits, distinguish content from structure before deciding where AI fits.View the series contents
Let me start with a case involving someone in the industry we spoke to.
He began running an independently owned website early, using WordPress and a builder. After several years, it had accumulated some search authority. When AI took off, he wanted to hand as much operational work as possible to AI: writing articles, doing SEO and eventually writing entire pages. The direction was sound, but he could not give up his established site's authority and wanted to put the AI-generated pages back into it. He ended up embedding them layer by layer in Bricks. The site became heavier and slower, and its smoothness visibly declined.
Looking back, he had fallen into a very typical trap: equating using AI for efficiency with letting AI change the site itself.
There is more than one source of efficiency. Some are safe and others risky. He began with the riskiest one, changing the site's structure, while leaving the safest and fastest source of gains untouched. Sites with established search authority especially need to distinguish the two. Otherwise, instead of improving efficiency, you lose what you have already built.
This article explains what you can let AI handle freely, and what you should leave alone.
1. First distinguish whether the work you want AI to do concerns content or structure
The test is simple: does the task touch your theme, builder or template files?
If it does not, it belongs to the content layer: writing articles, expanding content, diagnosing SEO and interpreting data. The outputs are articles and content published normally through the WordPress backend. The site's foundations remain untouched, so risk is low.
If it does, it belongs to the structural layer: building pages, changing themes and embedding code in a builder. A mistake can affect a group of pages or even the entire site, rather than just one page. For a site with search authority, this is high-risk territory.
Most people approach it in the reverse order. They immediately want AI to build pages and change the site, at the structural layer, without realizing that they have not yet taken advantage of the safe, fast gains in content. For an established site, reverse that order: get the full benefit from the content layer first. Avoid structural changes where possible, and stay within clear boundaries when they are necessary.
Let us look at them separately.
2. Start by getting the full benefit from content: the safest area and the quickest to show results
Do not reduce content work to asking AI to write articles. The real value is connecting AI to your existing GSC-driven process and making the cycle of data → topic selection → writing → review → iteration work, without touching any of the site's structure.
Start with GSC data, not an arbitrary request for AI to write something.
After your main service page has been live for a while, Google will surface a set of queries. First determine whether these are the page's core terms. If they are the terms you originally targeted, the page is on course and you can keep observing. If they come from one module or represent a more specific long-tail query, that is an opportunity: Google is showing you demand for that part of the content.
This is where AI should come in.
Those emerging long-tail queries, especially complete questions clearly typed by users into a search box, are good material for dedicated blog posts or FAQ additions. Many now also arise from questions people ask AI. One approach is to have AI generate drafts around these queries, reinforcing the main service page's topical authority and linking back to it from each blog post. These articles are not arbitrary AI inventions: data supplies the topic and you set the direction.
AI can mainly do three things at the content layer.
First, write and expand content around queries that appear in GSC, as described above. Second, review content and diagnose SEO: ask AI to inspect your pages from both technical and content perspectives. It can follow logical dependencies, for example reminding you that a change to module three also requires changes to module six. In practice, that saves effort. Third, help interpret data: compare periods in GSC performance reports to see what has fallen or risen, then use tools such as Clarity to examine visitors' actual paths through the page. Locate the problem before making targeted changes.
Across this whole process, one point matters: all outputs are articles and content published normally through the WordPress backend. No theme changes, no builder changes and no template edits. For an established site, structural risk is therefore close to zero. These are the gains you should take first, rather than rushing to let AI change the site.
One final reminder: do not iterate content too frequently. Google needs time to index and reassess it. Give changes time to take effect rather than repeatedly editing, unless the content is seriously off target. For SEO responsibilities that require observation over time, also read After Leaving WordPress, Who Handles All the SEO Work?.
3. Next, the structural layer: before asking AI to build pages, check what your site uses
After taking full advantage of content work, if you still need AI to build pages or change structure, pause and identify how the site is built. This directly determines whether and how AI can connect.
If your site uses a theme or Gutenberg, there are relatively manageable options: for example, writing a skill that lets AI write the final content directly to WordPress's posts table, or packaging common modules as blocks. For Elementor, tools such as MCP can now let AI operate its native capabilities.
The real difficulty is with builders such as Brizy and Bricks, which are currently less AI-friendly. Forcing AI-generated code into them will likely produce the outcome in the opening example. There is a more practical approach, based on firsthand experience shared by another person in the industry:
My site was built with a builder a couple of years ago. Since using Codex, I have AI read the source before generating anything, and that avoids problems.
In other words, let AI understand the structure your existing builder produces, then generate within that structure, instead of forcing its own code into it. If that still does not work, give it a reference page and ask for something similar. That can be more practical.
If you use Brizy, you can go further and build a translation layer.
Brizy is awkward because it stores serialized data rather than native HTML, with the block HTML encapsulated inside. AI cannot read and write it directly. But there is a fairly clean solution: have Codex build a small plugin that acts as a middle layer for conversion in both directions.
On the way in, AI only generates standard HTML, and the plugin converts it to Brizy's encapsulated format before writing it. On the way out, when AI needs to read an existing page, the plugin supplies HTML parsed from the blocks, rather than relying on visual analysis of screenshots. As a result, AI reads and writes the HTML it knows best throughout the process. All the messy work of Brizy's proprietary format is captured in the plugin once, for continued reuse. You can work without this layer: a capable AI may write temporary conversion scripts each time. But that can consume several times more tokens on every run, turning a one-time cost into a recurring tax.
One requirement must be non-negotiable: because this plugin directly manipulates the database and bypasses WordPress's normal write validation, backups are mandatory. Only with automatic backups before every write and the ability to roll back at any time should this approach be used on a site with established authority.
The implementation is discussed further in After AI Generates a Page, How Do You Bring It into WordPress?, so I will not expand on it here.
4. A hard boundary: things an established site should not do
We have covered what you can change. Here are several things I believe sites with established authority should leave alone.
Do not let AI directly edit the production site's theme, especially the parent theme. Theme changes can affect an entire set of pages, and theme updates can overwrite your manual changes. If changes are necessary, use a child theme, work on a test site and prepare backups and rollback first. Never let AI directly edit the production theme.
Do not migrate the site or change architecture just to try something new. There are many new tools around. Seeing others use Astro or new CMSs from Cloudflare can be tempting. But that means leaving WordPress, a route for new sites or people without established search authority to protect. For an older site with authority, it is a site migration: you are gambling with rankings, and the risk far outweighs the novelty. For the distinction between new and established sites, see when WordPress may be unnecessary.
Do not force code-heavy pages into a builder. This caused the failure in the opening example. Builders already have deep nesting. Adding a mass of code makes pages heavier, slows loading and worsens Core Web Vitals, hurting SEO first. The intention to improve efficiency is good, but the wrong implementation takes you in the opposite direction.
Finally
Improving efficiency and preserving search authority do not conflict. The key is separating the layers: make full use of content improvements, keep structural work within clear boundaries and stay away from the hard limits.
If you also have a site that has been running for years and you are reluctant to disturb it, start with content. Connect AI to the GSC-driven cycle, then decide whether structural changes are appropriate based on your theme, builder, backups and rollback options.
Continue reading
- Previous: After Leaving WordPress, Who Handles All the SEO Work?
- Next: Is AI Maintenance a Black Box? Building a Multilingual Site with Hundreds of Products
- Should an established site be rebuilt? Competitors Are Producing Content Quickly with AI. Should You Rebuild a Ten-Year-Old WordPress Site?
- View the full AI × WordPress series
Discuss AI improvements for your existing site
Tell us about your current workflow and the features you need to retain if you want to integrate AI or reduce repetitive maintenance work.