What Happens When AI Rebuilds Your Website

We built two websites that, by every number that matters for search, were doing very well. One was a browser game site with about 1,000 individual game pages, each one a small front door for someone arriving from a Google search. The other was a novelty site built around a single joke: click a button and it sends you somewhere random on the internet. Neither is glamorous. Both were quietly effective, pulling in real visitors month after month because the pages did what people were actually searching for.

Then their owners moved on, and both sites were rebuilt in November 2025 using AI-driven tools. Both rebuilds looked, to the eye, like clean upgrades: modern interfaces, smooth interactions, nothing visibly broken. And within a month, both sites started losing search rankings, and they haven't stopped falling since.

AI built these interfaces competently. Both rebuilds worked fine for a person clicking through them. The trouble sits somewhere a browser never shows you: in what happens when AI builds a website and nobody who understands search, code, or crawling checks the parts a person browsing the site would never see. You don't know what you don't know, and in both of these cases, what nobody knew was quietly costing real traffic, every single day, for months.

The Pattern: Two Sites, Same Month, Same Collapse

We didn't go looking for this story. It surfaced because we still track search performance on sites we've built, even years after a client moves to a different provider. It's part of how we learn what actually holds up over time.

Here's what stood out: both sites' search visibility peaked in November 2025. Both were rebuilt that same month, confirmed by pulling public web-archive snapshots of each homepage. Both began losing rankings the following month, December 2025, and both have lost ground every month since. Two unrelated sites, two unrelated AI rebuild projects, the same shape of decline, starting at the same moment.

• ~74% Site A's ranked-keyword footprint, lost since its November 2025 rebuild
• ~69% Site B's estimated traffic, lost over the same period
• ~3% Of Site A's ~1,000 games, the share Google could find after the rebuild, as background data, not links

The two sites didn't lose the same amount, and that gap turns out to matter. We'll come back to it. But the direction, for both, was identical: down, every month, since the rebuild.

Site A: The Bug Google Never Saw

Site A is worth walking through in detail because the cause is specific, findable, and completely ordinary as far as AI mistakes go.

Before the rebuild, Site A's ranked-keyword footprint (the number of distinct search terms it showed up for anywhere in Google's results) sat around 12,000, and had for a while. Today it's about 3,250, a drop of roughly 74%. Estimated organic traffic peaked around 214,000 visits a month in November 2025 and now sits closer to 150,000.

The keyword numbers tell the sharper story, and they turn on a detail worth slowing down for. The site's domain is an exact match for one of the common names of a popular game, and for that name it ranks number one. That is what an exact-match domain buys you: the top spot for the exact phrase in your web address, holding even while everything else is falling apart. Here's the catch. The same game has a second, far more popular name, one people search for well over a million times a month, roughly 16 times the volume of the name the domain wins. For that bigger term, the site sits at position 20, down on the second page of Google's results. The domain hands them the smaller synonym for free and can do nothing for the larger one, because ranking for the popular name takes earned authority, and that is exactly what the rebuild threw away.

Look past that one fortunate term and it gets worse. The long-tail keywords in positions 21 through 50, the ones the site built page by page over years by actually answering specific searches, fell from about 4,000 to about 1,360.

The web archive shows why. The day before the rebuild, Site A's homepage carried 4,386 words of real content, 271 individual links to specific games, 37 links to category pages, and 13 section headings organizing all of it. During the week of November 8 through 13, 2025, the homepage became a bare application shell: no crawlable links to a single game, no crawlable links to a single category.

Here's the specific, teachable part. The rebuilt site is a modern web application, and modern web applications typically need a build step: a process that turns the source code a developer writes into the actual files a browser can run. On this site, the homepage points to a single script, and that script's address leads to a source file that hasn't been through that build step. Instead of returning working program code, the server returns a plain web page. So when Google's crawler requests the homepage, the application never starts. Google receives an empty page.

Real visitors never see any of this. Their browsers load a different, correctly built version of the site, the one that works, complete with the full grid of games front and center. It looks flawless to a person clicking through, and it is nearly invisible to the crawler doing the same thing on Google's behalf. Of the roughly 1,000 games the site offers, about 30 show up anywhere in what Google actually receives, and even those appear only as background data the page could theoretically use, not as links the crawler can follow to an actual page.

Why the Damage Stayed Invisible

If you'd opened Site A in a browser the week after the rebuild, you'd have found nothing wrong. Pages loaded, games launched, and the navigation worked just as you'd expect. That's precisely why this kind of failure is so hard for a non-expert to catch: everything a person can click on and look at was functioning normally.

The version of a page a crawler receives and the version a browser renders aren't always the same file, and that gap is normal. Done correctly, it's invisible in a good way; it's how a lot of fast-loading modern websites work. Checking that gap requires looking at a site the way a search engine does, which is a specific, technical thing to check for, not something that shows up from ordinary browsing.

Rankings don't fall off a cliff, either. They erode. A few keywords slip a few positions one week. A few more the next. Over two or three months that adds up to the kind of numbers we've described here, but in any given week, it can look like the normal fluctuation every site experiences. By the time a decline is undeniable, months of ranking history, and the traffic that came with it, are already gone.

A Lucky Domain Isn't Protection

Compare Site A and Site B and one more piece of this comes into focus. Site A's ranked keywords fell 74%, but its estimated traffic fell only about 30%, from roughly 214,000 to roughly 150,000 visits a month. Site B's ranked keywords fell 67%, from about 900 to about 296, and its estimated traffic fell almost exactly as hard: about 69%, from roughly 84,000 to roughly 26,000.

Same failure, same month, but a very different amount of pain, at least so far.

The difference is the domain name. Site A's address is an exact match for one of the names people already search that game by, so even as its earned, long-tail rankings collapsed, a steady stream of those searches kept landing on the homepage regardless of what else Google could or couldn't crawl. Site B is a novelty site built around a random button. There's no brand term backing it up, no built-in stream of people typing its name into Google. When its rankings fell, its traffic had nothing to lean on, so it fell right alongside them.

The lesson isn't that Site A dodged the bullet. Its long tail is still gone, and that's the part of a site's traffic that tends to compound over years into the biggest share of visits. A strong domain name, an established brand, or an old, trusted set of backlinks can hide a search problem for a while by covering for it with traffic that was never at risk to begin with. That doesn't fix the problem, and it doesn't mean the problem isn't there. It buys time before the rest of the damage becomes obvious.

The Real Lesson (and When AI Is Genuinely Fine)

None of this means AI can't build a good website. In both cases here, the AI produced something that worked for a person using it, and that's a real, useful capability. We use AI every day ourselves, and we've written before about where it genuinely helps and where it quietly doesn't. This is the same tension, showing up somewhere far more expensive.

What AI didn't do, in either case, is recognize that a search crawler is a different kind of visitor than a person with a browser, or check whether the thing it built actually served content to both. AI is unlikely to close that gap on its own anytime soon, because closing it doesn't take better code. It takes someone who knows to ask whether the crawler is seeing the same site the visitor is.

Here's a plain way to sort out when AI needs a human checking its work, and when it's fine running on its own.

AI on its own works fine for a site that doesn't depend on being found in search: an internal tool, a one-off prototype, a page you link to directly instead of hoping someone discovers it. It's fine for drafting and iterating quickly, as long as something at the end verifies what actually shipped.

AI needs an expert checking the parts you can't see whenever a site depends on organic search for real traffic, whenever it has years of earned rankings worth protecting, or whenever "it looks right in the browser" is the only test anyone's run. That describes both of the sites in this piece, and it describes a lot of small businesses and nonprofits that don't yet realize it describes them too.

What to Check Before You Let AI Touch Your Site

If you're weighing an AI build or rebuild, or you already made the move and want to know whether you're standing where Site A and Site B were standing, here's what to actually check, in order.

1. Check what a crawler actually receives from the page, then compare it to what a browser renders. Google's Rich Results Test does this for any URL: run the page through it, open "View Crawled Page," and you'll see the exact code Googlebot got back. If it's less than what a visitor sees, that's the whole problem, right there.
2. Pull up the site's Wayback Machine history from before and after any rebuild. Compare word counts and link counts on the homepage. A page that goes from thousands of words and hundreds of links to a bare shell overnight is the same shape of change we found on both of these sites.
3. Ask whether the site's core content loads through code that runs after the page arrives, and whether that content is also present in the version delivered to a crawler. This is a specific, checkable technical question, and it's the one that broke Site A.
4. Watch keyword counts and rankings for the first two to three months after any rebuild. Don't treat a quiet dashboard as good news. Both of these declines were gradual and easy to miss in the moment they were happening.
5. Bring in someone who can answer the first four questions with evidence, not confidence. That's the entire value an expert adds here: checking the parts a non-expert has no way to see.

We'd rather you catch this before it costs you a year of rankings than after. If you want a second set of eyes on a site you've built, or one you're considering rebuilding with AI, our free Strategic Intelligence Report looks at exactly this kind of thing: what's actually happening under the surface of your site, beyond what it looks like when you click around.