How Chili Piper moved 3,000 pages from Webflow to Claude

The first Claude version of our Webflow homepage took me about a day.

Moving the whole site took roughly a quarter.

In April, I sent Nicolas and Alina that first link. It looked like we were moving very fast.

Then we got to the rest: around 3,000 pages, live campaigns, forms connected to our lead flow, and a few product features living on chilipiper.com that we didn't even know about. The website also kept changing while we rebuilt it.

Getting one page to look right was the easy part.

Why I wanted us to move

I joined Chili Piper in April. I've been making websites since I was a student, starting with PHP and WordPress. Before Chili Piper, I'd already done two migrations with Claude, including one from Webflow.

So I told Nicolas: I think we should do this here too.

I don't think Webflow is bad. It is a great tool for plenty of teams. If everyone can update your site and it does what you need, don't migrate because everyone on LinkedIn is suddenly rebuilding websites with Claude.

At Chili Piper, marketing wanted to launch pages and experiments faster. Our developers already had a product backlog. And some of the things we wanted were hard to build or optimize inside Webflow.

For us, Claude made sense. We could control when scripts loaded, how pages were built, and how quickly we tested new ideas. We still needed designers and engineers.

Claude became the interface

The website is still a website. The difference is that we can talk to Claude instead of dragging things around with a mouse or handing every Figma file to a developer.

The speed is a double-edged sword. You can build anything really fast, and that is also the problem.

We asked Claude to build a game for our 404 page. Now, if you hit a broken link, you can play it. Someone else can ask for six more icons, three animations, and another section because, well, now they can.

Very quickly, you have a little Frankenstein.

Maria, our designer, was a big part of keeping that from happening. We still needed her to decide what looked good, what belonged in the design system, and when enough was enough.

Move first, improve second

For a large website with traffic, rankings, and paid campaigns, I would take the safe option: move what you already have before you redesign it.

That is what we did. We copied the existing structure and content. Once the new version matched, we started improving it.

If we'd changed the platform, URLs, copy, design, and SEO at once, we wouldn't have known what caused the problem when something broke.

The demo took one day. The migration took a quarter

The homepage made it look easy. It wasn't.

Most of the time went into getting people aligned, finding dependencies, and keeping up with a website that was still changing. Campaigns still had to launch, so we were creating some pages in Webflow while rebuilding them for the new site. Different teams had different priorities. Parts of our product were also using the website domain in ways we hadn't mapped.

More than once, we thought we were ready. Then we found another dependency. We delayed the launch and rolled back one cutover when we found product elements that could have stopped working for customers.

Annoying, yes. Still better than breaking something our customers already use.

You will forget pages

We exported Webflow, crawled the site, checked Analytics, looked in Search Console, and connected the agent to Webflow so it could inspect the collections.

We still kept finding pages.

Every week it was something. “We're launching.” Then: “Wait, the thank-you pages weren't moved.” The next week, we found a URL that wasn't in the crawl but was still indexed or receiving traffic. We now have more than 1,900 redirect rules in the codebase.

Don't ask your agent to “find every page” and assume the answer is complete. Compare several sources:

• Your CMS export
• A crawl of the live site
• Analytics traffic
• Search Console indexing and search traffic
• Paid campaign destinations
• Existing redirects

For every old URL, decide whether it stays, moves, or goes away. If it moves, redirect it straight to the final page. No chains.

Crawl [YOUR-DOMAIN] (or use my exported URL list) and build a complete URL inventory. For every URL, record: title tag, meta description, canonical, robots directives, structured data types, hreflang, and inbound internal links. Then produce a 1-to-1 301 redirect map from every old URL to its new URL, flagging any entry that would chain through another redirect or hit a 404. Rank pages by conversion value, not raw traffic. Output as a table I can diff after launch. Do not change any URL structure without flagging it for my explicit approval.

A success message can still mean zero leads

I learned this one while moving a lawyer friend's site from WordPress to Claude.

The contact form looked perfect. You could fill it in, click submit, and watch a lovely success animation.

For two days, every request went into the void.

The site said thank you. Nothing reached the team.

Recreating a form means more than recreating its fields. Validation, notifications, tracking, consent, CRM records, routing, and follow-up all have to work too.

After that, I don't trust the success message. At Chili Piper, we run checks whenever something goes to production, plus scheduled checks after launch. But a 200 OK still doesn't prove the right person received the lead. Before launch, we submit a real test lead and follow it all the way through.

Audit everything this site does that won't survive an export or content migration: forms and their submission handling, downstream integrations (CRM, marketing automation, lead routing), site search, CMS collections, localized content, memberships, ecommerce behavior, editorial previews and drafts, and runtime interactions. For each item, tell me: what currently handles it, what will replace it in the new stack, and how we'll verify it end to end before launch. Treat forms as highest risk: they look identical after a rebuild while everything downstream is broken.

Why we didn't add another CMS

For now, our content lives in GitHub. A writer, marketer, or salesperson tells Claude what they want, and Claude opens a pull request. The checks run there before the change goes live.

That works for Chili Piper. It won't work for everyone.

That same site had three lawyers writing the articles. They wanted nothing to do with Claude. So we gave them Sanity, and they kept writing the way they were used to.

The right answer depends on who will update the site. For us, that's Claude. For those lawyers, it was Sanity. A mix is fine too.

Done is a claim, not a result

Claude will confidently tell you the migration is finished.

Cool. Show me.

We let Claude build, then asked Codex or Antigravity to check the code, responsiveness, and visual match. They regularly found things Claude had missed.

We also added checks for code quality, missing content, broken links, metadata, translations, forms, and 404s. And we still reviewed the important pages ourselves.

Before we launched

We kept the Webflow site live and put the new site on staging. We planned the switch for a low-traffic weekend. If something went wrong, we could go back.

The forms had to send real leads to the right place. The redirects had to work. Search engines had to see the right pages, and the parts of our product living on the website domain had to keep working.

Those were launch blockers, not things to fix later.

Run the launch blocker checklist and show evidence for each item (curl output, crawl results, test submissions), not an assertion:
1) Full URL inventory completed before rebuild.
2) Complete and correct 301 mapping.
3) Title tags, meta descriptions, canonicals, and JSON-LD preserved.
4) Forms, search, preview, and localization flows working.
5) Content pages server-rendered (SSG/ISR/SSR), not client-rendered shells.
6) No duplicate indexing from WordPress origin, staging, preview, or dual sitemaps.
7) Internal links point at final URLs, not through redirects or old paths.
8) Agent-generated code went through a structured audit, acceptance criteria, and page-by-page QA.
If any item lacks evidence, we do not launch.

The speed looked great. We still needed results

Before launch, one speed test showed first content appearing in about a second and a half on the new page, compared with roughly 17 seconds on the old one.

Seventeen seconds looks dramatic, but I don't think it is a fair Webflow benchmark. Our old setup had legacy scripts and wasn't well optimized. On the new site, we could choose when scripts loaded, how images were served, and how animations were built. That is where the speed came from. Not from sprinkling AI on the page.

At the time of writing this guide, we don't have post-launch traffic, ranking, or conversion results yet. So I'm not going to claim the migration improved conversion. It gave us a faster way to run the next experiment. We still need to see if that experiment works.

We aren't done

We're going to keep updating it with what worked, what broke, and what the numbers look like after the migration. No victory lap before the results.

Once your own site is live, watch leads and form submissions immediately. Rankings can take time to move. A broken form can cost you pipeline today.

The site goes live this week. Build automated health checks into this repo so problems surface in the first two weeks instead of a month later:
1) A script that crawls the live site and reports new 404s, redirect chains, broken internal links, and oversized images. Runnable on demand and on a daily schedule in CI.
2) A metadata diff: compare live titles, meta descriptions, canonicals, and JSON-LD against the pre-migration snapshot and flag anything that drifted.
3) A form check that verifies every form endpoint still responds and every tracking script still loads.
4) A 404 catch: log every hit on the 404 page with the requested path and referrer, and surface new paths in the daily report. Real traffic finds the redirects your crawl missed.
Write the output as a daily report I can read in one minute, with failures at the top. Show me a sample run against the production build before you call it done.

If you're planning your own move, the complete Webflow migration guide has all ten prompts and the launch checklist we use.