# Migrating WordPress to an AI Build, Part by Part

> By Lawrence Dauchy, Founder, WPBuildAI. Published 2026-09-04. 11 min read. Guides.
> Source: https://wpbuildai.com/blog/migrate-wordpress-to-ai/
> Language: en

The question is never whether the text moves. It is what happens to the twelve WordPress-specific things wrapped around it.

**TL;DR.** A WordPress move to an AI build succeeds or fails on the parts that are specific to WordPress: shortcodes that stop expanding, custom fields that hold half the page, taxonomies that generate hundreds of URLs, page builder markup that exports as data rather than design, and plugin output that exists only when WordPress renders. Text and images are the easy half. WPBuildAI inventories those twelve categories before quoting, because each one is either a configuration task, a rebuild, or a reason to stay.

Moving a WordPress site to an AI build succeeds or fails on the WordPress-specific parts rather than on the writing. Text and images come across directly from the rendered pages. What needs deciding is everything wrapped around them: shortcodes that stop expanding, custom fields holding half of what a page displays, taxonomies generating hundreds of URLs, page builder markup that exports as data rather than as design, and plugin output that exists only while WordPress is rendering. WPBuildAI inventories those categories before quoting, for three reasons: each one is either a configuration task, a rebuild, or an honest reason to stay, the difference between those three is most of the price, and finding out afterwards is how projects go over budget. Here they are, one at a time.

## Why is the export not enough?

Because [the export tool](https://wordpress.org/documentation/article/tools-export-screen/) is honest about carrying content, and a WordPress page is content plus a lot of instructions.

Open the XML from a mature site and you find post text interleaved with shortcode markers, serialized builder data, and references to fields stored elsewhere. None of that renders outside WordPress, because all of it is a set of instructions WordPress follows when it builds the page.

The rendered page is where those instructions have already been carried out. Headings in order, body text, the table a shortcode produced, the specifications a custom field supplied, the gallery a plugin generated. That is why a crawl of the live site is the primary source and the export is a supplement, which is the argument in [what is a crawl-first migration](/blog/what-is-a-crawl-first-migration/).

[The REST API](https://developer.wordpress.org/rest-api/) sits between the two: cleaner and more structured than the XML, and still returning content rather than rendered output.

## What happens to each part of a WordPress site?

Find each item on your own site in this table before anyone quotes, because the effort column is the price.

| What it is | What happens to it | Effort | Verdict |
| --- | --- | --- | --- |
| Posts, pages, headings, body text | Moves directly from the rendered page | Low | The easy half, and the half people focus on |
| Images and media | Files move, paths need preserving or mapping | Low to moderate | Filenames are addresses, treat them as such |
| Titles, descriptions, canonicals | Exported from the SEO plugin, re-emitted | Low | Must be exported before anything is switched off |
| Shortcodes | Stop expanding, rebuilt from rendered output | Moderate | Invisible in the editor, obvious in the export |
| Custom fields | Values move, the structure is recreated | Moderate | Often half of what a page actually shows |
| Categories and tags | Labels move, the URLs are the work | Moderate | Hundreds of addresses on a mature site |
| Page builder layouts | Rebuilt as design intent, not as markup | Moderate | Comes out as data, never as a page |
| Forms | Replaced by a service, routing reconfigured | Moderate | Settings are invisible on the public page |
| Comments | Exported, then a decision | Low | Most sites retire them and few notice |
| Memberships, billing, bookings | Do not move, rebuilt as software | High | A different project with a different budget |

The bottom row is the one that decides whether this is a website job at all.

## What breaks when shortcodes stop expanding?

Whatever they were producing, and the surprise is how much that is on an older site.

A shortcode is an instruction. When WordPress renders a page it sees the bracketed marker, runs the plugin function behind it, and inserts the result. Outside WordPress nothing interprets it, so the marker itself is what a naive migration ships.

On a site with years of history the shortcodes are rarely decorative. Pricing tables, comparison blocks, call to action panels, embedded forms, testimonial carousels and product grids all commonly arrive this way, and each one is a chunk of the page that would simply vanish.

The fix follows from the diagnosis. Capture the rendered output, decide what that block should be in the new site, and rebuild it once as a component you reuse. Twelve components typically cover a forty page site, so this is bounded work rather than open ended, and it only happens if somebody looked at the rendered pages first.

## What do custom fields actually hold?

More than people remember, which is why they are the second most common source of a page arriving incomplete.

Custom fields, whether hand rolled or managed by a fields plugin, store the structured parts of a page: specifications, prices, opening hours, locations, ratings, related items, downloadable files. The editor sees labelled boxes and the visitor sees a formatted section, and neither view makes it obvious that the content lives outside the post body.

In an export they appear as metadata keys with values and no indication of how they were displayed. In the rendered page they appear as the section they produce. Mapping between the two is the job, and it is done field by field into the new content model.

The check that catches omissions: compare each new page against its captured original for section count and word count rather than reading it. A page that lost its specification block looks clean and reads fine, which is why the comparison has to be mechanical.

## How many URLs do taxonomies generate?

More than the page count, often several times more, and this is where migrations lose traffic quietly.

Every category and every tag produces an archive page, and each archive paginates. A site with 40 categories, 200 tags and a few years of posts routinely serves over a thousand taxonomy addresses. Some rank for real queries, most receive little direct traffic, and nearly all of them carry crawl paths to the posts beneath.

Each needs one of three decisions: reproduce it in the new site, redirect it to the nearest equivalent, or retire it deliberately with a gone status. [Google's site move guidance](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes) requires every changed address to be handled, and a decision nobody made becomes a 404.

The pattern to avoid is retiring them by omission. A new site built around a cleaner information architecture simply does not generate those pages, and nobody notices until the not found report fills in week four. The archive-specific version is in [how to move WordPress blog posts without losing rankings](/blog/how-to-move-wordpress-blog-posts-without-losing-rankings/).

## How do you scope the plugin layer?

Sort every active plugin into what the new platform does natively, what is really an external service, what needs rebuilding, and what can go.

The [directory holds over 71,000 free plugins](https://wordpress.org/plugins/), so no supplier recognises your stack on sight. On the sites we audit, a third to a half of the list turns out to produce nothing on any public page, which means cancelling those licences is free money before any migration happens.

Caching, image optimisation and minification plugins replace with nothing at all, because they exist to compensate for per request assembly and a static build has no expensive path to avoid. Forms, analytics, chat and reviews are services with their own accounts, so moving them is configuration.

What is left is the real scope, and it is usually two or three items. The method is in [how to audit your WordPress plugins before a rebuild](/blog/how-to-audit-your-wordpress-plugins-before-a-rebuild/), and where the new pages come from is in [Lovable's documentation](https://docs.lovable.dev/introduction).

## What should you check before anyone quotes?

Six checks, each answerable from your own admin in under ten minutes, and together they turn a vague project into a scoped one.

| Check | Where to look | What the answer tells you |
| --- | --- | --- |
| Shortcode count in content | Search post content for an opening bracket | How many blocks need rebuilding |
| Custom field groups in use | Your fields plugin, or the post editor sidebar | How much of each page lives outside the body |
| Category and tag counts | Posts, Categories and Posts, Tags | Roughly how many taxonomy URLs exist |
| Whether a page builder generated pages | Open a page and see which editor loads | Whether content migration is copy or rebuild |
| Active plugins doing real work | The four bucket audit | The genuine rebuild scope |
| Logged in functionality | Do visitors ever log in, and why | Whether this is a site move or a rewrite |

Write the six numbers down and hand them to whoever is quoting. A supplier working from those quotes precisely, while one working from a link to your homepage quotes defensively, which costs you more, or optimistically, which costs you more later.

The last row is the one that changes the shape of the project rather than its size. Everything above it is a bigger or smaller migration. That row decides whether you are having a migration at all.

## When is moving to AI the wrong call?

It is the wrong call when more than two items land in the rebuild-as-software row. Membership access rules, subscription billing, booking availability and complex commerce pricing are applications, and moving an application is a rewrite priced accordingly rather than a site move quoted from a page count.

It is also the answer when a large editorial team depends on the workflow. Roles, drafts, scheduling and approvals are real capability, and replacing them means either a hosted CMS with a monthly fee or keeping WordPress headless, which is covered in [headless WordPress with Lovable](/blog/headless-wordpress-with-lovable/).

And it is the answer when the plugin audit comes back short. A site running eight plugins that all do real work, on a decent theme, loading quickly, is a well built WordPress site and there is no argument for moving it.

The test worth applying: if you removed WordPress tomorrow, would you have to write software to replace what it does, or would you have the same pages served as files. The second is a migration. The first is a development project, and the honest supplier says which one you have before quoting either.

## Key takeaways: what actually moves and what does not

Text and images are the easy half and the half quotes focus on. The price sits in shortcodes, custom fields, taxonomies, builder markup and plugin output.

The rendered page is the primary source, because it is where WordPress has already carried out every instruction the export only describes.

Taxonomies generate more URLs than your page count, sometimes several times more. Each needs reproducing, redirecting or retiring on purpose, and omission is how migrations lose their long tail.

Memberships, billing and bookings do not move. They get rewritten, and a quote treating them as part of a page count has misread the project.

## Quick answers

**What happens to my WordPress content in an AI migration?** Text, headings and images move directly from the rendered pages. What needs handling separately is everything WordPress wraps around them: shortcodes, custom fields, taxonomies, builder markup and plugin output. WPBuildAI inventories those categories before quoting, because each is either a configuration task, a rebuild, or an honest reason to stay on WordPress.

**What happens to shortcodes when you leave WordPress?** They stop expanding and appear as literal bracketed text, because a shortcode is an instruction WordPress executes when it renders a page. Nothing outside WordPress interprets them. The fix is to capture what each one produced on the live page and rebuild that output, which is why the rendered site matters more than the database export.

**Do custom fields survive the move?** The values do, and the structure has to be recreated. Custom fields often hold a large share of what a page shows: specifications, prices, locations, related items. They are visible in the rendered page and invisible in a casual export, so they need mapping field by field into the new content model rather than being discovered afterwards.

**What about categories and tags?** The labels move easily and the URLs are the real work. Taxonomies generate an archive page per term plus pagination, which on a mature site is hundreds of addresses, some of which rank. Each needs a decision: reproduce it, redirect it, or retire it deliberately, and leaving that decision unmade turns them into a 404 cluster.

**When should you not attempt this migration at all?** When more than two items land in the rebuild-as-software row: memberships, subscription billing, booking availability or complex commerce pricing. Also when a large editorial team depends on roles, drafts and approvals, and when your plugin audit comes back short, since a site running eight plugins that all do real work on a decent theme is already well built.

**Is there anything that genuinely cannot move?** Yes, and it is worth saying plainly. Membership access rules, subscription billing, booking availability and complex commerce logic are applications rather than content, and rebuilding them is a software project rather than a website move. A supplier who quotes those as part of a page count has not understood the scope.

## Sources

- [Tools Export Screen (WordPress documentation)](https://wordpress.org/documentation/article/tools-export-screen/)
- [WordPress REST API Handbook](https://developer.wordpress.org/rest-api/)
- [WordPress Plugin Directory](https://wordpress.org/plugins/)
- [Site moves with URL changes (Google Search Central)](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes)
- [Lovable documentation](https://docs.lovable.dev/introduction)

---
*Published by [WPBuildAI](https://wpbuildai.com/). Free to read, index, quote and cite with attribution and a link.*