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.

We had around 3,000 pages, live campaigns, forms connected to our lead flow, and product features living on chilipiper.com that we didn’t even know about.

Now we can change the website much faster. Our CEO, Alina, also worries about publishing over someone else’s work. Bianca, our Senior Product Marketing Manager, is finding product copy that needs fixing. And we lost some of our visual identity along the way.

Here’s what happened, including the parts we’re still figuring out.

Why I wanted us to move

I joined Chili Piper in April. I’d been making websites since I was a student and had already done two migrations with Claude, including one from Webflow.

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

Marketing wanted to launch pages and experiments faster. Our developers already had a product backlog. Claude gave us more control over how we built pages, loaded scripts, and tested ideas. We still needed designers and engineers.

Webflow is a great tool for plenty of teams. If it does what you need, don’t migrate because everyone on LinkedIn is suddenly rebuilding websites with Claude.

Faster changes, more disagreements

The website is still a website. Claude became the interface for changing it.

That also made it easier for everyone to act on their opinions.

Alina didn’t like having a “Book a demo” button in both the header and the middle of the page. She made the header button disappear until visitors scrolled. Costas worried about conversions and reverted the change.

Bianca was concerned about the messaging on our product and competitor pages. Generating a page quickly didn’t mean the copy got our positioning right.

We also lost some of the website’s character. Before the migration, Maria Irie, our Head of Brand Design, manually reviewed pages. Some of the design system was documented. Some lived in her head. We didn’t carry all of that judgment into the new site.

Somewhere along the way, beige appeared. Combined with our orange, parts of the website started looking noticeably Claude-generated.

Even the logo became a disagreement. Alina kept removing the Chili Piper name beside the pepper. Costas kept putting it back. She thought people would recognize the pepper on its own, like Apple. He wasn’t convinced yet.

The demo took one day. Getting ready took a quarter

Our approach was to copy the existing structure and content before improving it. Changing the platform, URLs, copy, and design together would make problems harder to diagnose.

But campaigns kept launching while we rebuilt. We were creating some pages in Webflow and rebuilding them for the new site. Product dependencies kept turning up too.

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

We kept Webflow live, tested the new site on staging, and planned the switch for a low-traffic weekend with a way back. Forms, redirects, search visibility, and product dependencies were launch blockers.

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.

You will forget pages

We exported Webflow, crawled the site, checked Analytics and Search Console, and let the agent inspect the Webflow collections.

We still kept finding pages.

One week, it was thank-you pages. Another, a URL missing from the crawl that still received 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

While moving a lawyer friend’s site from WordPress to Claude, I recreated a contact form that looked perfect, complete with a success animation. For two days, every request went into the void. 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.

At Chili Piper, we run production checks and scheduled checks after launch. Before launch, we submit a real test lead and follow it all the way through. A success message isn’t proof that the right person received it.

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 hasn’t made publishing feel clear to everyone.

We’re still dealing with overlapping changes.

This setup also won’t suit every writer. The three lawyers writing articles for my friend’s site wanted nothing to do with Claude. We gave them Sanity. Choose based on who will actually update the website.

Done is a claim, not a result

Claude will confidently tell you the migration is finished.

Cool. Show me.

We asked Codex or Antigravity to check Claude’s work. They regularly found things it had missed. We also added checks for code quality, content, links, metadata, translations, forms, and 404s.

Humans still reviewed important pages. A page can pass technical checks and still get the messaging or design wrong.

Faster doesn’t prove better

One pre-launch test showed first content appearing in about 1.5 seconds on the new page versus roughly 17 seconds on the old one. That isn’t a fair Webflow benchmark: our old setup had legacy scripts and wasn’t well optimized.

We don’t yet have post-launch traffic, ranking, or conversion results to share. We have a faster way to try things. We still need to prove those things work.

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.

We aren't done

We still think the benefits outweigh the negatives. But overlapping changes, off-brand pages, and generated copy need work. If you’re planning your own move, our complete migration guide has the prompts and launch checklist. Agree on who reviews the copy, design, and demo buttons too. We’re still figuring that part out.