How to migrate from Webflow to a coding agent

More teams are rebuilding their marketing sites with AI coding agents like Claude Code, Codex, Cursor, and Antigravity. The pitch is real: an agent can rebuild in weeks what used to take a quarter. But the most common pitfalls aren't really "Next.js problems" so much as migration-discipline problems. Teams forget that Webflow or WordPress was doing a lot more than rendering pages. The agent can accelerate the rebuild, but it can't safely replace audit, verification, and SEO parity work.

This guide combines the failure patterns we've seen with what practitioners reported in a 189-comment LinkedIn thread on exactly this kind of migration. Each section ends with a prompt you can paste straight into your agent.

Why these migrations fail

It's rarely the framework. It's discipline. Your old platform was quietly handling redirects, metadata, forms, search, and sitemap logic. None of that "comes along" automatically when you rebuild. The teams that lose rankings and pipeline are the ones that treated the migration as a code conversion instead of a controlled replatform.

You are helping me migrate a marketing website from Webflow to Next.js. Before writing any code, produce a migration audit of the current site at [YOUR-DOMAIN]. List: 1) every feature the platform is handling beyond page rendering (forms, redirects, search, CMS collections, localization, memberships, ecommerce, analytics, integrations), 2) what will own each one after migration, 3) what breaks silently if it's missed. Do not generate any code until I approve the audit.

SEO parity comes first

The biggest failure is changing URLs without a complete 1-to-1 redirect map. That routinely causes traffic loss, broken long-tail pages, redirect chains, or soft 404s after launch.

A close second is losing metadata, canonicals, schema, hreflang, sitemap ownership, or robots logic that Webflow settings or WordPress plugins were previously handling automatically. Teams assume those settings will "come along" into Next.js. They won't. Every one of them needs an explicit owner in the new codebase.

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.

Hidden platform features you'll have to rebuild

What Webflow was quietly doing

People often underestimate how much is not portable from a Webflow export. CMS collections, forms, site search, localized content, memberships, ecommerce behavior, and runtime interactions all need to be rebuilt deliberately. Forms are the sneaky one: they look identical after the rebuild, but the submission handling, validation, and everything downstream (like routing form fills to the right rep) has to be rewired and tested end to end.

What WordPress was quietly doing

The common trap is assuming the CMS migration is done once content appears in Next.js. Editorial previews, draft mode, revisions, taxonomy archives, plugin-generated routes, and SEO plugin output still need explicit replacement on the frontend.

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.

Rendering and indexing mistakes

A frequent technical mistake is shipping important pages as thin client-rendered shells instead of returning complete HTML on first response. That weakens crawlability and can leave content or metadata missing from what search engines fetch.

Another common issue is indexation leakage. Preview URLs, draft routes, staging domains, old WordPress origins, or duplicate sitemaps remain crawlable, so Google sees multiple competing versions of the same site.

Migrating is also when booking flows break. Forms get rebuilt, scripts get dropped, and lead routing rules quietly stop firing. Test yours before you launch.

Verify every important page in this build returns complete HTML on first response. For each route, confirm: rendering mode (SSG, ISR, or server-rendered, not a client shell), and that the title, meta description, canonical, and JSON-LD are all present in the raw HTML returned by curl. Then check for indexation leakage: staging domains, preview URLs, draft routes, old-origin URLs, and duplicate sitemaps that are still crawlable. Show me the curl output as evidence, not just an assertion.

Agent-specific mistakes

The main pitfall is using the agent like a blind converter instead of a migration copilot. Asking it to "convert Webflow/WordPress to Next.js" often produces brittle JSX, copied markup, and weak component boundaries instead of a clean architecture.

The better pattern: use the agent to audit the source site, extract patterns, define route, component, and content models, generate redirect and SEO parity checklists, and then rebuild section by section with verification against the live source.

Do not convert this site in one pass. Work as a migration copilot: 1) audit the live source site and extract layout and component patterns, 2) propose a route map, component model, and content model for my approval, 3) generate the redirect map and SEO parity checklist, 4) rebuild one section at a time, and after each section verify it against the live source (URLs, metadata, content, forms) before moving on. Stop and ask when anything is ambiguous.

What teams gained after migrating

The dominant theme from teams who'd already migrated (from Webflow, WordPress, HubSpot, Framer, or CraftCMS) was speed. Dozens of commenters said publishing and editing pages went from hours or days to minutes, letting marketers ship pages without waiting on engineers.

Several reported concrete SEO and performance wins: faster load times, better Lighthouse and PageSpeed scores, and in some cases improved rankings once they escaped a clunky builder. A few highlighted cost savings (no dedicated web-ops hire needed) and greater design flexibility, including easier localization, custom animations, and interactive components that were hard to achieve in Webflow.

Multiple people also liked that it freed marketing teams to test and iterate independently, needing only a designer's judgment rather than an engineer's involvement for routine changes.

The risks practitioners warn about

The single biggest fear, raised by many people independently, was SEO and organic traffic collapse. One commenter described being called in to rescue a client site where rankings and indexing "fell off the charts" within two days of a similar migration, with losses estimated at €20,000 per day.

Others warned that AI tools can quietly change things you didn't ask for: URL conventions, wording, icons. That silently erodes SEO equity and brand consistency. Several flagged that custom or headless CMS setups (like Supabase plus Vercel) saw slower Google discovery and indexing compared to platforms like Framer or WordPress.

Forms-to-CRM handoffs and marketing automation integrations were repeatedly named as fragile points that can break invisibly. And a few skeptics pushed back on the premise itself: an AI agent isn't a hosting or CMS platform, AI alone won't fix a weak underlying strategy, and governance and access-control gaps can cause problems as a company scales past a small team.

The do's and don'ts

Across many independent comments, a consistent playbook emerged. Toggle between the two lists:

Add these rules to the agent's rules file (CLAUDE.md, AGENTS.md, or equivalent) before any migration work starts:
- Never change URL structures, page wording, or design elements without flagging for explicit review.
- Never mark redirects, tracking codes, or integrations as complete without showing verification output.
- Never assume forms, webhooks, or CRM triggers work: test each one and show evidence.

The launch blocker checklist

Treat these pitfalls as launch blockers for a Webflow or WordPress to Next.js migration using an agent. Check them off as you clear them:

If any of these are unresolved, you're not ready to launch. The agent will happily ship a beautiful site that bleeds rankings and drops leads. Audit first, rebuild second, verify everything.

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.

Going to production

Clearing the blockers gets you permission to launch. It doesn't launch the site. The cutover itself is where the practitioners' advice gets specific: flip during a low-traffic window, keep a restorable backup of the original site, and push a test lead through every form before you call it done. Those parts are on you. What the agent can do is prove the codebase is ready before you flip anything:

We're about to point the domain at this codebase. Run a production readiness check against a production build and show me the output for every item, not a summary:
1) Confirm the production environment config lifts every staging guard: no noindex meta tags, no X-Robots-Tag headers, robots.txt allows crawling and points at the sitemap. Paste the rendered robots meta and headers.
2) Curl the top 20 URLs by conversion value from the redirect map against the production build: every old URL returns a single 301 to the right destination, no chains, no 404s. Paste the results as a table.
3) Confirm canonicals on every page template point at the production domain, not staging or localhost.
4) Confirm the generated sitemap includes every migrated URL and excludes staging, preview, and draft routes.
5) Grep every form in the codebase and confirm each one posts to its production endpoint, with tracking scripts and hidden fields intact.
Anything that fails blocks the cutover. Flag it, don't fix it silently.

And launch day isn't the finish line. The teams that caught problems early were watching conversions, not rankings. Rankings move slowly. A broken form or a routing rule that stopped firing shows up in your pipeline the same day. Have the agent build the checks that catch it:

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.

The checks that keep the site healthy

Webflow enforced a lot of this for you. In a codebase, nothing is enforced until you make CI enforce it. Once the site is live, every new page and blog post is a chance to quietly break what the migration got right. Make sure the website has these checks implemented:

Code quality:

• Lint: scans the code for common mistakes and style issues.
• Format check: makes sure everything's consistently formatted (spacing, quotes, etc.).
• Typecheck: catches type errors (mismatched data types) across the whole codebase.

Content:

• Translations: every piece of text exists in all languages with no missing or empty entries, and matching placeholders (like {count}).
• Content validation: blog posts, guides, and other content have valid required fields, and their images actually exist.
• Blog SEO: a post's page title and its visible headline aren't identical (bad for search ranking).
• Blog FAQs: FAQ sections use the right format so Google and AI search engines can read them.
• Blog references: internal links in posts actually point to real pages.
• Locale switcher and slugs: every page has working links in all languages, and web addresses (slugs) are clean.

Implement these checks in the repo and wire them into CI so they run on every pull request and block merge on failure:

Code quality:
1) Lint: scan the code for common mistakes and style issues.
2) Format check: everything consistently formatted (spacing, quotes, imports).
3) Typecheck: catch type errors across the whole codebase.

Content:
4) Translations: every piece of text exists in all languages, no missing or empty entries, and placeholders (like {count}) match across locales.
5) Content validation: blog posts, guides, and other content files have all required fields, and every referenced image actually exists.
6) Blog SEO: a post's page title and its visible headline are not identical.
7) Blog FAQs: FAQ sections use valid structured data so Google and AI search engines can read them.
8) Blog references: internal links in posts point to real pages, not 404s or redirects.
9) Locale switcher and slugs: every page links to a working version in every language, and slugs are clean (lowercase, hyphenated, no trailing junk).

Run the full suite once and paste the output. Any check that can't pass yet gets a failing entry and a note, not an exemption.

One caveat on the phrase "migrate to a coding agent"

Several commenters, even sympathetic ones, pointed out that the phrase is a little loose. A coding agent isn't itself a hosting or CMS platform. The actual implementations described in the thread ranged from custom code on Vercel, to an agent paired with headless CMSs like Sanity or PayloadCMS, to agent-assisted edits layered on top of an existing platform like Webflow. So the specifics of "how" matter a lot. The advice above applies most directly to the code-plus-hosting approach, where the agent owns the codebase and a platform like Vercel serves it.