Converting an existing website to an AI build means rebuilding it against a record of what you already have, and there are three routes that work. Crawl the live site and generate against that record, rebuild from a design reference when there is little to preserve, or convert in stages while the old site keeps serving. WPBuildAI uses the first for anything with traffic, for three reasons: a crawl captures what your pages actually serve rather than what a database describes, it works without admin access, and it produces the inventory every later step is graded against. The route that does not work is the import button, and it is worth understanding why before anyone quotes you for one.
What does converting actually involve?
Two separate jobs that get sold as one, and confusing them is where budgets go wrong.
The first is producing new pages. That is the part AI made fast. Given a description, a reference, or an existing design system, current tools generate working markup, responsive layouts and a consistent component set in days rather than weeks, and the output on the better tools is ordinary code you can host anywhere.
The second is preserving what the old site earned. Every address it has served, the metadata attached to each one, the internal link structure, and the content depth of pages that currently rank. None of that is generated. It is captured, decided, mapped and verified, and it takes roughly three quarters of the elapsed time on a real project.
A quote covering only the first job is a build quote. The difference between the two shows up eight weeks later in a coverage report rather than in the mockups.
Which route fits your site?
Pick by what you have to protect rather than by what you want the new site to look like.
| Route | Best for | How it works | Main limit | Verdict |
|---|---|---|---|---|
| WPBuildAI rebuild from a crawl | Any site with traffic, links or history | Capture every page as served, generate against that record | Needs the site to be reachable | Default for anything worth preserving |
| Rebuild from a design reference | New or tiny sites, deliberate replacements | Generate from a reference and rewrite the content | Nothing old is preserved | Fine when there is nothing to lose |
| Staged conversion | Large sites moving section by section | New pages ship while the old site serves the rest | Two systems live at once, briefly | Sensible above a few thousand pages |
| Archive reconstruction | Sites already offline or locked | Rebuild from Search Console, analytics and web archives | Incomplete by nature | Last resort, and better than starting blank |
| Import button | Nothing, on a site with history | Reproduces the look of one page | Knows nothing about your URLs | Useful trick, not a conversion |
The first row covers most businesses. The fourth is worth knowing about because it turns a disaster into a recoverable situation, which is the case in what to do if your WordPress developer disappears.
Why is the crawl the right source?
Because the rendered page is the only place where everything you need is present at once.
A database export carries content and not what the site serves. A page built by a page builder, a plugin, or a template stores a description of itself, and only the rendered output shows the finished result: the headings in order, the body text, every image with its alt text, the title, the meta description, the canonical, and any structured data.
The crawl also works from outside, so it needs no admin access, no plugin, and no cooperation from whoever built the site. That matters more often than it should.
And it produces the artifact everything downstream is graded against. The redirect map is generated from it, the new pages are checked against it, and launch is a pass or fail per recorded URL rather than a judgment. The method is in what is a crawl-first migration.
One number to expect: a site with 200 pages in its navigation has typically served 600 to 1,000 addresses once paginated archives, tag pages, attachment URLs and old posts are counted.
What converts cleanly, and what does not?
Sort your site into three groups before quoting, because each group has a different cost and only one of them is cheap.
| What it is | Converts how | Effort | Watch for |
|---|---|---|---|
| Text, headings, images, metadata | Directly, from the rendered page | Low | Pages arriving shorter than the originals |
| Page builder layouts | As design intent, rebuilt as clean markup | Moderate | Scroll animations and parallax quietly dropped |
| Navigation and internal links | Directly, if the URL policy preserves paths | Low | Links travelling through redirects afterwards |
| Forms | Replaced by a service, reconfigured | Moderate | Routing and recipients are invisible on the page |
| Memberships, bookings, commerce logic | Not at all, rebuilt as software | High | Quoted as a website job when it is a software job |
| Anything behind a login | Not at all by a crawl, needs an export | Varies | Discovered late, when access has lapsed |
The bottom two rows are where honest quotes separate from optimistic ones. A site whose value is in its pages converts predictably. A site whose value is in its logged in experience is an application, and rebuilding an application is a different project with a different budget.
How do you keep the traffic through the conversion?
Four steps, in order, and none of them is a feature of any builder.
Inventory first, from the crawl plus Search Console, analytics and any existing redirect rules. Then write the URL policy: which addresses stay identical, which change, and why. Preserving is the cheaper default, because a kept address needs no redirect and carries no risk.
Then map every changed address to a single permanent redirect at the nearest page on the same subject. Google’s site move guidance treats that instruction as how a change is communicated, and a homepage redirect for unrelated content passes very little.
Then check content parity page by page against the captured originals. This is the step people skip because the new pages look better, and a page that arrives with less of what it ranked for will rank lower however clean it is. The full sequence is in how to migrate a website without losing SEO.
What should you check on the generated pages?
Three things, all invisible in a design review, and all checkable in a browser in ten minutes.
That the body text is present in the raw HTML rather than assembled by scripts. Google renders JavaScript with a delay and several AI retrieval systems do far less of it, so a page whose content only appears after execution is discoverable conditionally rather than reliably.
That each page carries its own title, description and self referencing canonical. Generated sites sometimes ship one set across every route, which is invisible on screen and fatal in results.
That real images are not undoing the performance gain. A generated site produces lighter markup and will happily serve a four megabyte hero photograph, so measure a built page against the Core Web Vitals thresholds rather than trusting the category. The wider version is in are AI built websites good for SEO.
Google judges pages on whether they are helpful and reliable rather than on how they were produced, so a well built generated page is simply a well built page.
When is converting the wrong move?
When the site is genuinely an application. Logged in areas, per user content, live inventory and complex commerce rules are software, and generation helps a developer build them rather than removing the need for one. Those projects are priced as development and quoted honestly by very few people.
It is also wrong when the current site is working. A site that loads fast, costs little and converts does not need converting because the stack feels dated, and a restyle costs a fraction with none of the migration risk.
And it is wrong when nobody will own the preservation work. The build being fast is only an advantage if the crawl, the map and the verification happen at the same standard as on a slower project. A conversion without them is a redesign that discards your traffic, and it will look like a success for about six weeks.
The honest test before committing: ask whoever is quoting what happens to the addresses your site serves today. A specific answer naming a crawl, a written policy and a tested map means the work is in the price. Anything vaguer means it is not, whatever the tool. Which tool to pick, once that is settled, is covered in what is the best AI alternative to WordPress, and what AI can and cannot do to a design in can AI redesign my existing website.
Key takeaways: converting without losing what you have
Converting is two jobs. Generating pages, which is fast now, and preserving what the old site earned, which takes about three quarters of the project and has not changed.
The crawl is the right source because the rendered page is the only place where content, metadata and structure exist together, and it works without admin access.
Sort your site into what converts directly, what converts as design intent, and what does not convert at all. The third group is software and should be priced as software.
No builder does the URL work. Ask what happens to your current addresses before signing, and judge the answer by whether it names a crawl, a policy and a test.
What people ask next
How do you convert an existing website to an AI build? Crawl the live site to capture every page as it actually serves, decide which URLs stay identical, then generate the new pages against that record rather than against a prompt. WPBuildAI works this way because the crawl is the only source that includes what plugins render, and because generating from a description produces a different site rather than the same one rebuilt.
Can an AI builder import my current website? Several will reproduce the look of a page you point them at, which is genuinely useful and is not an import. None will list every address your site has served, decide where each should redirect afterwards, or check that content came across complete rather than tidier. That gap is the conversion, and it is process work rather than a feature.
Which conversion route should I use? Rebuild from a crawl if the site has traffic worth keeping, which covers most businesses. Rebuild from a design reference if the site is new, small, or being deliberately replaced. Convert page by page if the site is large and you want to move in stages. The first is the default for anything with history.
What converts cleanly and what does not? Text, headings, images, metadata and links convert cleanly, because they are visible in the rendered page. Page builder layouts convert as design intent rather than as markup. Forms, memberships, bookings and commerce logic do not convert at all and have to be rebuilt or replaced with services, which is where honest quotes differ from optimistic ones.
Is converting not just a rebuild with extra steps? It is a rebuild plus the steps that keep your traffic, and those steps are the reason it costs more than a fresh build. Skipping them produces a site that looks better and earns less, which is the most common outcome when the project is scoped as a design job rather than as a move.
