Someone built a landing page with scrollytelling animations in 10 minutes using Claude Code. The kind of work agencies charge 5k for.
And honestly, that is cool. Agencies that still charge premium prices for a single landing page with no photo shoots, no freelance creators, and no strategic thinking behind it should be worried.
But building a landing page and running a website are two completely different problems.
AI is solving the wrong bottleneck
AI can generate a page. It can write the CSS, handle the animations, and ship something that looks impressive in a screen recording. For a single page with no history, no existing traffic, and no systems attached to it, that genuinely works.
The tools are getting better fast. Cursor, Bolt, v0, Lovable, and a growing list of AI-assisted builders can produce functional, responsive pages from a prompt. For a startup validating an idea or a freelancer shipping a portfolio, that is a real shift. No argument there.
But most businesses are not starting from zero. They have a website that has been running for years. It ranks for hundreds of keywords. It has backlinks pointing to specific URLs. It connects to their CRM, their analytics, their internal workflows. And at some point, that site needs to move.
That is where things get complicated.
The migration problem nobody talks about
Website migrations are one of the highest-risk technical projects a marketing team can go through, and most of them go badly. That is why we built a framework specifically for migrations.
According to research that analyzed hundreds of domain migrations, only about 1 in 10 migrations actually improve SEO performance. The rest either flatline or lose traffic, sometimes permanently. A study of nearly 900 domain migrations found that the average recovery time after a failed migration was 523 days. And 17% of the sites in that study never recovered at all.
These are not edge cases. A major UK retailer lost roughly £3.8 million in the first month after a migration because the IT team dismissed redirect mapping as too complex. That happened during a £7.6 million redesign. The migration was not cheap. The planning was.
Even well-executed migrations typically see a temporary traffic dip of 5 to 10%. The difference between a well-executed migration and a disaster is not talent or budget. It is planning, redirect mapping, content preservation, and someone who stays accountable through the process and after it.
What AI does not solve
Here is what actually goes wrong during migrations, and why no AI tool addresses it today:
Redirect mapping. Every URL with traffic or backlinks needs a corresponding redirect in the new system. For a site with hundreds of pages across multiple languages, this is a detailed, manual inventory that requires understanding the old system, the new system, and the SEO implications of every structural change. We wrote a detailed guide on how to build a redirect strategy for website migrations. Missing or incorrect redirects cause over 75% of post-migration traffic loss according to practitioners who work on these projects regularly.
Content architecture. The way content is structured in your old CMS rarely maps cleanly to a new one. Proprietary formats, content locked inside page builder plugins, metadata that only exists as custom fields in WordPress. Moving this content without losing its meaning, its internal relationships, and its search relevance is tedious, technical work.
Integration dependencies. Your website talks to other systems. Forms feed your CRM. Analytics track conversions. Search connects to your product catalog. E-commerce syncs with your ERP. Every one of these connections needs to be re-established and tested in the new stack. A broken form that silently stops sending leads to your sales team can cost more than the entire migration budget.
SEO equity. Years of accumulated search authority do not automatically transfer to a new URL structure. Schema markup, canonical tags, internal link structures, and structured data all need to be mapped and verified. Understanding how Core Web Vitals change during a headless migration is part of getting this right. If your redesign changes the URL structure, the page hierarchy, and the content simultaneously, Google treats it as a brand new site and re-evaluates everything from scratch.
Post-launch monitoring. The 48 hours after a migration are critical. Redirect chains, indexing errors, broken analytics, and crawl issues all surface in real time. If nobody is monitoring, problems compound before anyone notices. One case study described a team that did not realize their traffic had dropped 52% until the following Wednesday, nearly a week after launch.
Building is the visible part. Everything else is invisible.
The reason the “I built a landing page in 10 minutes” narrative is so compelling is that building is the visible, demonstrable part of web development. You can record it, share it, and impress people with it.
But for a marketing team managing a real website, building was never the bottleneck.
The bottleneck is the migration that preserves three years of SEO work. The CMS that lets editors publish without calling a developer. The performance that does not degrade six months after launch. The system that survives the next team change, the next campaign push, the next integration request.
A marketing team that just relaunched their site and watched organic traffic drop 40% because nobody mapped redirects properly does not care how fast the new pages were built.
What this means for marketing teams
If you are evaluating a website project right now, here is what matters more than how quickly someone can build a page:
Who is responsible for the migration plan? Not just the build, but the audit of what exists, the redirect strategy, the content migration sequence, and the SEO preservation plan. If nobody owns this explicitly, it will fall through the cracks. This is exactly what our headless migration service covers end to end.
Who monitors after launch? The first two weeks after a migration determine whether you keep your traffic or spend the next 18 months trying to recover it. If the plan ends at “go live,” that is a red flag.
Who stays accountable after the project? Websites are not finished when they launch. They need ongoing attention, optimization, and maintenance. If the team that built it disappears after launch day, you are on your own when things start to break. This is why we offer a website subscription that keeps us accountable long after go-live.
Building is getting easier every month, and that trend is real. But the hard part was never building. It was making sure what you already have survives the transition, and that someone stays responsible for the system after it goes live.