How a Vibe-Coded Migration Erased a Year of SEO in a Week

The migration that looked finished

The brief was simple, on paper. A client wanted to move an established website to a new stack, a cleaner design, faster pages, modern tooling. They used an AI coding assistant to do it, describing pages and generating code in a fast back-and-forth loop, what is now commonly called vibe coding. Within a couple of weeks, the new site was live. It looked good. It loaded fast. Every page a human would click on worked correctly.

Nobody on the project had SEO experience, and nothing in the process asked them to think about it. The AI had been told to build a website, not to preserve one.

What actually did not survive the move

When we were brought in afterward to look at what had gone wrong, the first thing we checked was not analytics. It was the two files that take five minutes to get right and cost nothing to include: robots.txt and sitemap.xml. Neither existed on the new site.

On their own, a missing robots.txt is not fatal, most crawlers default to treating a missing file as full access. A missing sitemap is not fatal either, Google can discover pages by crawling links instead. But in this case, neither file missing was really the story. It was evidence. If nobody had thought to carry over the two most basic technical SEO artifacts a website can have, the far more consequential things had almost certainly not survived either.

They had not. The URL structure had changed during the migration, new slugs, a different folder layout, no one had written down what the old URLs were before they disappeared. There was no redirect map, so old URLs that had earned rankings and backlinks over roughly two years now returned a generic 404. Some pages existed at two different addresses briefly, the old structure still cached, the new one live, with nothing telling Google which one was authoritative. Structured data that had been quietly reinforcing the business's identity to Google was gone, nobody had asked the AI to include it because nobody had known to ask.

Why the first week looked like nothing, and the second week did not

For the first few days, very little seemed to change. That is normal, and it is also the trap. Search engines do not instantly notice a site has moved; they revisit pages on their own schedule, at a rate shaped by how much they already trusted the domain.

Then the recrawl happened. Pages that used to rank started returning errors when Google checked them again. Backlinks that had been pointing at those pages for years, the single biggest input into a metric like Ahrefs' Domain Rating, stopped passing any value the moment their target became a 404 instead of a working page or a proper redirect. Keyword positions that had taken months of consistent signals to earn started dropping within days, not because the content had gotten worse, but because Google could no longer confirm the page it used to trust still existed in a form it recognized.

Within roughly a week, organic traffic had not slowed down. It had stopped, on the pages that used to carry it. New pages, meanwhile, had no history to lean on and no sitemap pointing Google toward them efficiently, so they were not yet picking up any of the slack.

Why rebuilding takes so much longer than breaking

This is the part that is genuinely counterintuitive if you have not been through it. A website's search visibility is not a static property of its content. It is closer to a reputation, built out of thousands of small, consistent signals accumulated over a long time: pages that keep working, links that keep resolving, structured information that keeps matching what the page actually says. Search engines extend trust gradually and withdraw it fast, because withdrawing it costs them nothing and extending it wrongly costs them a bad result in front of a user.

Breaking that reputation takes one bad migration. Rebuilding it means re-establishing the same signals from close to zero, correct redirects held in place for months, content re-proving its relevance, backlinks re-pointing at working pages, one crawl cycle at a time, with no shortcut that makes a search engine trust a site faster than the evidence actually justifies.

What a technical migration checklist would have caught

None of what went wrong here required expertise a human SEO specialist would call advanced. It required someone, or something, checking a short technical SEO checklist before launch: a full inventory of existing URLs and their current rankings, a 301 redirect mapped from every old URL to its new equivalent, a robots.txt that matches what should actually be crawlable, a sitemap submitted through Search Console the day the new site goes live, and a side-by-side check that structured data and canonical tags moved over intact.

An AI coding assistant can write every one of those pieces correctly if it is asked to. The failure here was never really that AI wrote the code. It was that nobody in the process knew this checklist existed, so nobody thought to ask for it. AI is very good at building exactly what it is told to build, and has no way of flagging the thing nobody mentioned.

The lesson, stated plainly

SEO visibility behaves asymmetrically. It can take months of consistent, correct signals to earn a ranking, and it can take a single unredirected URL to lose it. That asymmetry is not a reason to avoid AI-assisted development, which can genuinely speed up a rebuild when it is guided by someone who knows what has to be preserved. It is a reason to treat any migration as a technical SEO project first and a design refresh second, regardless of who or what is writing the code.