Every week someone shows up wanting to move a real site — one with traffic, backlinks, a few years of Google's trust behind it — into an AI builder. Not a fresh idea, not a prototype. An existing business with something to lose. That's a different job than starting from a blank prompt, and most of the pain I've seen comes from treating it like the same job anyway.
There are three ways this goes wrong often enough that I can predict the support ticket before I read past the subject line. The right way isn't clever. It's just the thing you get to once you've stopped doing these three.
Mistake one: dumping the old content in and hoping structure sorts itself out
The instinct makes sense. You've got a site, it has words on it, so you paste the words into the chat and ask the builder to "make this better." What comes out is usually a site that looks new and reads old — the same run-on service paragraphs, the same three headings doing the work of fifteen, now wrapped in a nicer template. The builder did what you asked. You asked it to redecorate, not to rethink.
The wreckage shows up about six weeks later, when the new site's rankings sit exactly where the old one's did, or slightly under. Nothing improved because nothing about the actual information architecture changed — same flat page for a service that should've been three pages, same missing FAQ content a competitor's site has been ranking on for a year. A fresh coat of paint on a house with the wrong number of rooms is still the wrong number of rooms.
I had a client with a 4,000-word "Services" page that covered eleven distinct offerings. She wanted it migrated as-is because "it's always worked." It hadn't worked — it ranked for nothing specific because it was about everything at once. Migrating it faithfully would've just made a nicer version of the same non-ranking page.
What actually works here is treating migration as an audit before it's a build. Feed the old content in, but ask for a content inventory first: what pages exist, what each one is actually trying to rank for, where two topics are crammed into one URL and where one topic is thin across five. That inventory becomes the plan. The old site is a source, not a template.
Mistake two: forgetting that URLs are the thing Google actually trusts
This is the expensive one. A site migration that changes URL structure without mapping old paths to new ones — even when the new content is genuinely better — throws away years of accumulated signal. Backlinks point at a 404. Google has to re-crawl and re-earn trust in pages it already trusted under a different address. Direct traffic from old bookmarks and email signatures dead-ends.
I've watched people notice this only after launch, when the analytics dashboard shows a cliff instead of a bump. By then the fix is redirects added after the fact, which recovers some of the loss but not all of it — the gap between "the URL moved" and "someone noticed and fixed it" is measured in weeks of lost equity you don't get back.
| Old approach | What breaks | What to do instead |
|---|---|---|
| Let the builder generate whatever URL structure fits the new design | Every inbound backlink and bookmark now points at a 404 | Export the old sitemap first, map every existing URL to its new equivalent before build starts |
| Redirect the homepage only, let inner pages 404 | Deep pages carry their own individual link equity — losing them individually adds up | 301 every meaningful old URL, even ones getting merged into a broader page |
| Add redirects "later, once it's live" | Crawlers and clicking users hit dead ends during the exact window traffic is most volatile | Redirects go live the same moment the new site does, not after |
None of this is exotic. It's a spreadsheet with two columns, made before anyone touches the builder. It's just the step people skip because it's boring and the build itself is the fun part.
Mistake three: the big-bang cutover with no way back
The third failure mode isn't about content or URLs at all — it's about how the switch actually happens. Someone builds the new site, likes what they see in preview, and points the domain at it that afternoon. No staging period, no side-by-side comparison under real traffic, no plan for what happens if something's broken that preview didn't catch — a contact form silently failing, a checkout flow that works in testing but chokes under real payment volume, a page that renders fine on desktop and breaks on the exact phone half your customers use.
The wreckage here is the loudest kind because it's immediate. Support inboxes fill up. Someone's refreshing analytics every ten minutes watching a graph go the wrong direction, and rolling back means re-pointing DNS again, which itself takes time to propagate, which means the bad experience persists even after you've decided to reverse it.
The fix is unglamorous: lower the DNS TTL a day or two before cutover so any rollback propagates fast if you need it, run the new site on a preview or staging subdomain first and actually use it the way a customer would, and keep the old site's hosting live and untouched for at least a couple of weeks after cutover instead of tearing it down the moment the new one's up. That last part costs a few dollars of hosting for real insurance. People skip it because canceling the old plan feels like closing a loop, and closing loops feels like progress.
What the right way actually looks like
Put together, none of this is more work than the wrong versions — it's the same amount of work in a different order. Audit before you rebuild. Map URLs before you launch. Stage before you cut over, and keep a way back for a couple of weeks after you do. The site that comes out the other end doesn't just look newer. It keeps everything the old one had already earned, which was the entire point of migrating instead of starting over.
