AI Website Migration: 450 Pages Rebuilt in a Day

The Site That Was Costing Them Clients

A personal-injury law firm in LA County came to me with a website that looked fine and performed terribly. Here are the numbers that mattered.

The site ran on WordPress. 456 pages total: blog posts, news, practice area pages, location pages. The mobile LCP (the time it takes for the main content to actually appear on a phone) was 32.9 seconds. The page weight was around 6MB. The Lighthouse performance score was 55 out of 100.

Then I found the real problem. The blog index silently hid 229 of 249 posts. They were in the database. They had been migrated at some point. But the index template only surfaced 20 of them. The other 229 were invisible to visitors and invisible to Google. Years of content the firm paid writers to produce, generating exactly zero value.

This firm paid an agency to build and maintain this site.

So here is the buyer doubt I want to address head-on, because it is the right question to ask: can an AI website migration be both faithful to what a firm already paid for AND measurably better than the agency version? Not a rewrite. Not a redesign that loses content. The same copy, the same URLs, just faster and actually working.

The answer is yes, and I am going to show you with before-and-after numbers you can verify yourself with a free tool in two minutes.

I rebuilt the entire site in a day. Mobile LCP went from 32.9 seconds to 2.9. Lighthouse went from 55 to 95. Page weight dropped from 6MB to under 1MB. And those 229 hidden posts are now live and indexable.

I wrote a companion piece on rebuilding a law firm's site in a day if you want the full play-by-play. This article is about the migration discipline and the numbers.

Why a Slow Site Is a Sales Problem, Not a Tech Problem

Before we talk about WebP and static rendering, let me make the business case. A 32.9-second mobile LCP means most visitors never see the page. They are gone before it paints.

For a personal-injury firm, that is not a minor annoyance. Every visitor is a potential case worth thousands, sometimes tens of thousands, in fees. A person who just got hurt in a car accident is searching on their phone, in pain, with zero patience. If your page takes 30 seconds to load, they hit back and call the next firm on the list.

Now layer in Google. Core Web Vitals are a ranking factor. LCP is one of them. A 32.9-second LCP does not just lose the visitors who arrive, it suppresses how many arrive in the first place, because Google ranks faster sites higher for the same query.

Then there is the hidden content problem. Those 229 invisible blog posts were content the firm paid for, sitting in the database, contributing nothing to rankings because nothing linked to them. Google could not crawl what it could not reach. Years of investment, dark.

Here is the part that should make any CEO wince. This firm spends money on Google Ads. Paid clicks, real dollars per click, sent to a landing page that takes 30 seconds to load. That is money lit on fire. You pay for the click, the visitor leaves before the page appears, and you pay for the next one.

This is not a vanity-metric conversation about a number in a dashboard. Page speed is a direct line to revenue for any business that gets customers online. The site was a leak in the bottom of the bucket.

The Migration Plan: Crawl Everything, Change Nothing

The discipline of a faithful migration comes down to two rules: keep the content verbatim, and keep the URLs identical. Break either one and you lose SEO equity or you break the firm's existing copy. Neither is acceptable.

Faithful Migration Pipeline

I am not in the business of rewriting a law firm's legal copy with AI. That copy was written by people who understand liability and how to describe practice areas without making promises they cannot keep. My job was to preserve it exactly and serve it faster.

Crawl all 456 pages to structured JSON

The first step was capturing the entire site as structured data. I firecrawled all 456 pages into JSON: the body content, the headings, the metadata, the page titles, the descriptions. Everything that defined each page, pulled into a clean, structured format I could work with programmatically.

This is the foundation. Once the whole site is structured data, you can render it however you want without touching the original meaning of any page.

Mirror the exact URLs

The second step was preserving every URL. I rendered all 456 pages through a single catch-all route using generateStaticParams, so every page is pre-rendered at build time. Statically served. Fast by default, because there is no database query and no server-side rendering happening when a visitor arrives. The HTML is already built and sitting on a CDN.

The fidelity rule held the whole way through. Same paths, same content, nothing 404s, all the existing SEO equity transfers cleanly. A page that ranked yesterday still lives at the same address today.

This is why the result is both faithful and faster. The old way of doing a migration like this involved a team and weeks of work. I wrote about the new timeline for custom software and why that math has changed completely.

Fixing What the Agency Missed: Real Indexes

This is where an AI migration beats a lazy agency job, and not just on speed. On correctness.

Orphaned Content Problem and Fix

The old blog index was broken in a specific, common way. The posts existed in the database. The template that listed them only surfaced 20. The other 229 had no link pointing to them from anywhere a crawler could reach. They were orphaned.

The fix was straightforward once I had everything in structured JSON. I generated full, real indexes: a blog index that lists every single post, practice area indexes that list every practice area, location indexes that list every location page. Nothing hidden, nothing capped at 20.

The content was already there. The firm had already paid for it. The rebuild simply made it visible and crawlable again.

The SEO upside is significant. Hundreds of pages that were invisible are now linked from real index pages and reachable by Googlebot. That is hundreds of pages of indexable content coming online at once, each one targeting specific injury types and locations that real people search for.

Getting newly surfaced pages indexed quickly is its own task. If you want to skip the wait, I wrote up the approach in getting Google to index a site fast. For a firm sitting on 229 newly visible posts, that is the difference between value next week and value next quarter.

Where the 6MB Went: Image Optimization at Scale

The single biggest cause of those 6MB pages was unoptimized images. Full-resolution photos, served raw, no compression, no modern formats. On a law firm site that means staff headshots, office photos, and stock imagery, all weighing far more than they needed to.

Image Optimization Lever on Page Weight

The fix is unglamorous and exactly the kind of thing automation is built for. I converted every image to WebP, resized them to the dimensions they actually display at, and compressed them. Page weight dropped from 6MB to under 1MB.

That single change is the largest lever on LCP. The main content paints when the largest element loads, and on most of these pages the largest element was an image. Shrink the image, the page paints sooner. It is that direct.

I want to be honest about the nature of this work. It is repetitive. Doing it by hand across 456 pages, finding every image, converting it, resizing it, recompressing it, reattaching it, would take days of mind-numbing clicking. That is precisely why agencies skip it. It is boring and it does not show up in a design mockup.

It is also precisely what automation handles without complaint. I built a pipeline that processes the whole set at once. I documented the detailed version of that pipeline in cut 92% off image weight if you want to see how it works across hundreds of images.

The work was boring. The result was a 6x reduction in page weight.

The Discipline Part: Redacting a Key That Came Along for the Ride

Here is the part that builds trust, because it is the part a careless build gets wrong.

Speed vs Security Tax of AI Migration

When you crawl a live site, you scrape everything. Including things you should never republish. Buried in the scraped content of one of those 456 pages was a third-party Google Maps API key, embedded right in the markup.

I caught it and redacted it before anything shipped.

Think about what would have happened otherwise. An AI migration done without a human who knows what to look for will faithfully republish whatever it finds. The whole value proposition of a faithful migration (preserve everything exactly) becomes a liability the moment the source content contains a secret. The crawler does not know an API key from a paragraph of body copy. It is all just text to be preserved.

This is the honest limitation of fast AI builds, and I am going to state it plainly: speed carries a security tax if nobody is watching. The same tooling that lets me rebuild a 456-page site in a day will, left alone, cheerfully publish exposed credentials, leaked internal notes, or anything else the crawler picked up.

The value is not the speed by itself. The speed is easy now. The value is a builder who knows that scraped content needs to be reviewed before it ships, who knows what an exposed API key looks like, and who treats the migration as a security event and not just a copy-paste job.

Fast and careful are not opposites. But fast without careful is how you turn a website rebuild into a data breach.

The Before and After, Measured

Here are the numbers, clean.

Before/After Migration Metrics

• Mobile LCP: 32.9 seconds to 2.9 seconds
• Lighthouse performance score: 55 to 95
• Page weight: 6MB to under 1MB
• Hidden blog posts: 229 previously invisible posts now live and indexable
• URLs: all preserved, nothing 404s
• Content: verbatim, nothing rewritten
• Time: done in a day

Now let me address the buyer doubt directly, because I know what skepticism sounds like and I respect it. You have been burned by vendors who put pretty numbers on a slide that fell apart the moment you checked.

This is not a slide. This is a Lighthouse audit. Lighthouse is a free tool built into Chrome. You can run it on any URL, including this firm's site, and you will see the score. You could have run it before the rebuild and seen 55. You can run it now and see 95.

That is the entire point. I am not asking you to trust a claim. I am pointing you at a measurement anyone can reproduce in two minutes with a free tool.

And the deeper point is this. The rebuild did not just beat some abstract benchmark. It beat what a firm actually paid an agency to deliver, on speed, on page weight, and on basic correctness, since the agency version was hiding 229 pages of the firm's own content.

AI is not magic here. A measured rebuild is just a measured rebuild. What changed is that the work that used to take weeks and a team now takes a day, and the result is verifiable, not aspirational.

What This Means for Your Site

A bloated, slow, partially-broken website is one of the most tractable AI-assisted jobs there is. The reason is simple: the content already exists, and the win is measurable. You are not inventing anything. You are taking what you already paid for and making it fast and visible.

If you are paying an agency a monthly retainer for a site that scores 55 on Lighthouse, run the audit yourself today. Open Chrome, open DevTools, run Lighthouse on your homepage and a few of your top landing pages. The number will tell you whether your retainer is buying you anything.

This is the kind of work I do as a Chief AI Officer. I build it. I do not show up with a deck and recommendations and a list of vendors to call. I crawl the site, structure the content, rebuild it static and fast, fix what the last shop missed, and hand you a Lighthouse score you can verify. I wrote about why that distinction matters in I don't just advise, I build.

If your site is slow, hiding content, or quietly costing you the paid traffic you are buying, I would happily tell you what an audit of your own site would show. Not a pitch. Just the numbers and what they mean for your business.

Ready to bring AI leadership into your company?

I work with a small number of companies at a time. If you're serious about AI, apply to work together and I'll review your application personally.

Apply to Work Together