
Ed Abazi
140 articles
Co-founder at Raze, writing about development, SEO, AI search, and growth systems.

Learn how to migrate from Webflow to Claude Code and Next.js without damaging SEO, analytics, design fidelity, or demo conversion paths.
Written by Ed Abazi
TL;DR
Use Claude Code to accelerate a Webflow to Next.js migration, not to own it. Inventory the current site, rebuild around reusable components, preserve SEO and analytics, then launch with QA controls that protect conversion.
Moving a marketing site from Webflow to a custom Next.js stack can create more control, faster iteration, and cleaner engineering ownership. But migrating from Webflow to Claude Code is only useful if the new site preserves the parts that already work: rankings, conversion paths, brand trust, analytics, and page structure.
The wrong move is to ask AI to rebuild the site from screenshots and hope the launch holds. The right move is to treat Claude Code as an accelerator inside a controlled migration process.
Webflow is often the right choice for early marketing teams. It is visual, fast to launch, and accessible to non-engineers. For a seed or Series A company still testing positioning, that matters.
The pressure usually appears later.
The CMS gets harder to govern. Landing page variants multiply. Product pages need interactive sections. Engineering wants reusable components. Growth wants faster experiments. SEO needs cleaner control over templates, structured content, redirects, and page performance.
At that point, the website stops being a set of designed pages. It becomes a revenue system.
Migrating from Webflow to Claude Code should not mean replacing a visual builder with vibe-coded markup; it should mean rebuilding the marketing site as a controlled, measurable sales argument.
That distinction matters. A strong product still loses if buyers do not understand it fast enough. A custom Next.js site can help, but only when the migration improves clarity, trust, speed, and operational control.
Raze's point of view is simple: do not migrate because custom code feels more serious. Migrate when the current site is constraining GTM execution, search visibility, conversion testing, or technical trust. AI can compress the rebuild timeline, but it cannot replace the commercial judgment behind the site architecture.
In an AI-answer world, brand is your citation engine. AI answers pull from sources that feel trustworthy, specific, and easy to verify, so the migration needs to protect more than HTML. It needs to preserve the signals that make the company understandable, comparable, and citeable.
A move to Next.js makes sense when the team needs deeper control over:
Page templates and reusable content modules.
Technical SEO, metadata, schema, and URL handling.
Performance budgets and Core Web Vitals work.
Analytics events and funnel instrumentation.
Product-led experiences, calculators, sandboxes, or interactive demos.
Collaboration between marketing, design, and engineering.
This is why SaaS, AI, devtool, and infrastructure companies often outgrow no-code marketing setups. The site needs to explain technical value quickly, support enterprise evaluation, and ship campaign assets without waiting on product engineering every time.
If the only problem is visual polish, migration is probably the wrong first move. Fix the messaging, page hierarchy, and conversion paths first. Raze sees this often in SaaS redesign work: traffic does not fix unclear positioning. It exposes it.
A custom stack is usually worth considering when at least three of these are true:
The homepage narrative no longer matches the sales conversation.
The CMS has become fragile or difficult to model.
SEO pages are hard to scale without duplicate layouts.
Pricing, comparison, migration, or integration pages need tighter conversion logic.
The design system exists in Figma but not in production code.
Marketing experiments require engineering tickets every time.
AI search visibility is weak because pages lack clear, structured answers.
Analytics cannot isolate demo intent, product interest, or content-assisted conversion.
This is also where a conversion-focused web design agency or embedded design/growth team can help. The migration is not just technical. It is a chance to rebuild the site's argument, page system, and measurement model together.
For example, if a pricing page is getting traffic but not producing qualified hand-raisers, the issue may be tier comparison, enterprise trust, objection handling, or buyer routing. We have covered that pattern in our guide to pricing page UX, and the same logic applies during migration: do not carry weak conversion structure into a cleaner codebase.
The simplest reusable model is the four-layer migration model: inventory, rebuild, preservation, release.
It keeps the work from collapsing into one vague request like, rebuild this in Next.js. Each layer has a different owner, risk profile, and QA standard.
Inventory means documenting what exists before anything is rebuilt.
This includes:
Every indexable URL.
Page type and template.
Primary CTA per page.
Current title tag and meta description.
H1 and heading structure.
Canonical tag.
Structured data, if present.
CMS collection and field mapping.
Assets, fonts, icons, and imagery.
Forms, scripts, integrations, and tracking events.
Top organic landing pages and assisted conversion pages.
Do this before asking Claude Code to generate anything.
The inventory becomes the control document. It tells the team what must be preserved, what can be improved, and what should be removed. It also prevents the common migration failure where the new site looks close enough visually but silently drops metadata, redirects, form events, or internal links.
Rebuild means translating the Webflow site into a component-based Next.js system.
Claude Code can speed up this stage by producing early component drafts, extracting patterns, converting static HTML into JSX, and refactoring repeated sections into reusable modules.
But the rebuild should be based on a planned component map, not random page copying.
A useful map might include:
HeroWithProof
LogoWall
ProblemSection
ProductWorkflow
PersonaUseCases
ComparisonTable
IntegrationGrid
TestimonialCard
DemoCTA
FAQBlock
SEOArticleLayout
The naming does not need to be clever. It needs to be obvious enough for marketing and engineering to discuss without translation.
Preservation means protecting SEO, analytics, accessibility, and conversion behavior while the visual system changes.
This layer is where many AI-assisted migrations fail.
A critical review from Karpi Studio describes Google Search Console errors appearing within days after an improperly managed AI-built replacement. That is the risk of treating the migration as a design replication exercise instead of a search and systems migration.
Preservation should include:
URL parity or redirect mapping.
Metadata parity for pages that already rank.
Canonical rules.
Sitemap generation.
Robots.txt review.
Schema review.
Form submission tracking.
Demo CTA event tracking.
Cookie and consent behavior.
404 monitoring.
Internal link review.
If a page ranks, earns qualified traffic, or supports sales enablement, it deserves a preservation decision. Do not let it disappear because it did not appear in the first design export.
Release means launching the new site with controlled risk.
A serious migration should have a staging environment, crawl comparison, analytics validation, redirect QA, performance check, and rollback plan. The launch should not be a Friday afternoon DNS change followed by a Slack message.
Release also includes post-launch monitoring. Search Console, analytics, server logs, form submissions, and CRM attribution should be watched closely during the first two to four weeks.
The goal is not a perfect launch. The goal is a measurable launch where issues are visible quickly.
The process below assumes the site already exists in Webflow and the destination is a Next.js marketing stack. Claude Code is used to accelerate refactoring, not to own strategy, QA, or final code review.
Start by creating a clean baseline.
Export or document:
Full URL list from the current sitemap and crawl.
Webflow CMS collections and field names.
Static page screenshots at desktop and mobile sizes.
Current metadata for every indexable page.
Current conversion events and form destinations.
Top landing pages by organic traffic.
Top pages by demo assists or pipeline assists, if available.
Existing scripts, pixels, consent tools, and embeds.
This baseline is the difference between a controlled migration and a visual rebuild.
If the site has enterprise buyers, capture trust assets too: security pages, compliance mentions, customer logos, analyst badges, case studies, and technical documentation links. Early-stage SaaS teams often underestimate how much brand trust is carried by small cues, and we have written about that problem in our article on enterprise trust signals.
A migration is the right time to remove weak pages.
Do not blindly migrate:
Old campaign pages with no traffic or conversions.
Blog posts that overlap and compete with each other.
Thin integration pages with no clear buyer intent.
Demo pages with outdated screenshots.
Feature pages that describe product mechanics but not buyer value.
CMS items created for one-off launches and never maintained.
Create three buckets: keep, improve, retire.
Keep pages that rank, convert, support sales, or explain core product value. Improve pages where intent is strong but conversion is weak. Retire pages that create crawl waste or confuse positioning.
This is a commercial decision before it is a technical one.
Claude Code performs better when the target architecture is explicit.
Define:
Directory structure.
Page routing model.
Component naming conventions.
Styling approach.
CMS or content source.
Image handling.
Metadata generation.
Schema handling.
Form integration.
Analytics event naming.
A simple content-first structure might look like this:
app/
page.tsx
pricing/page.tsx
customers/[slug]/page.tsx
blog/[slug]/page.tsx
components/
marketing/
conversion/
seo/
lib/
cms/
analytics/
seo/
content/
pages/
posts/
Then ask Claude Code to work within those constraints. Give it the component map, sample design tokens, exported assets, screenshots, and one representative page before scaling to the full site.
A post by Gen Furukawa on LinkedIn describes a workflow built around uploading brand assets and using Claude to replicate Webflow designs in a new framework. That is useful, but the stronger version is to provide brand assets plus component rules, SEO requirements, and conversion requirements.
Do not start with the homepage if it is the most complex page on the site.
Start with a representative mid-complexity page, such as a feature page, integration page, or use case page. The goal is to test whether Claude can translate spacing, responsive behavior, section hierarchy, image treatment, and content structure into usable components.
A good first prompt includes:
Rebuild this Webflow page as a Next.js page using the existing component structure. Preserve the content hierarchy, CTA placement, image aspect ratios, metadata requirements, and mobile section order. Do not invent new copy. If a design detail is unclear, flag it instead of guessing.
The instruction not to invent copy is important.
AI-generated migration errors often appear as small wording changes, missing proof points, weaker CTA labels, or section reorderings. Those changes can damage conversion even when the page looks visually close.
Your website is not a portfolio. It is a sales argument. Protect the argument.
Webflow CMS fields rarely map perfectly into a custom content model.
Before importing, define the target schema. For example, a blog post may need:
Title.
Slug.
Meta title.
Meta description.
Excerpt.
Author.
Publish date.
Modified date.
Category.
Related articles.
FAQ items.
Schema type.
Canonical URL.
Body content.
For comparison pages, add fields for competitor name, product category, proof points, pricing notes, and CTA logic. For integration pages, add fields for use case, system requirements, workflow steps, and supported personas.
This matters for AI search as much as SEO. AI answers reward companies that are easy to understand, verify, compare, and cite. If the content model is vague, the site becomes harder for both humans and answer engines to parse.
A migration should preserve and improve the path to action.
Map every page to one primary buyer action:
Book a demo.
Start a trial.
View pricing.
Compare alternatives.
Explore a sandbox.
Read a technical proof page.
Contact sales.
Then check whether the new templates make that action easier.
For product-led companies, the strongest conversion path may not be a form. It may be a sandbox, guided demo, ROI calculator, or technical proof center. If the old Webflow site buried those assets, the Next.js migration should bring them forward. We cover a related path in our guide to product sandbox UX.
Do not assume the old CTA placement was right. Preserve what is proven. Improve what is not.
Use this action checklist before the new site is allowed to ship:
Crawl the Webflow site and export all indexable URLs.
Crawl the staging site and compare status codes, titles, H1s, canonicals, and metadata.
Create a redirect map for every changed URL.
Validate sitemap.xml and robots.txt.
Check that important internal links still point to live destination pages.
Confirm that forms submit to the right system.
Fire every key analytics event in staging.
Test desktop and mobile layouts for each reusable template.
Confirm cookie consent, tracking scripts, and CRM attribution behavior.
Review top organic pages manually before launch.
Submit the new sitemap after launch.
Monitor 404s, indexing issues, and form errors daily during the first week.
This checklist is not glamorous. It is what keeps migration from becoming a hidden pipeline problem.
For a small marketing site, a single launch may be fine. For a large site with hundreds or thousands of URLs, phased release is safer.
A phased plan might start with core static pages, then CMS content, then programmatic SEO pages, then interactive tools.
The larger the site, the more important the migration control layer becomes. ZenML reported rebuilding 2,224 pages and 20 CMS collections from Webflow to a custom stack in one week using Claude Code and a multi-model workflow. That case shows the speed ceiling can be high. It also reinforces the need for structure when the page count is large.
Speed is useful only when the team can validate what shipped.
Claude Code is strongest when the desired output is specific and reviewable.
It can accelerate the migration by reducing repetitive code work, generating component drafts, identifying duplicated patterns, and helping refactor Webflow exports into a cleaner architecture. It is weaker when the task requires judgment about positioning, buyer intent, trust hierarchy, analytics meaning, or launch risk.
Good Claude Code tasks include:
Convert exported HTML into JSX.
Extract repeated sections into components.
Generate responsive CSS based on existing design tokens.
Create metadata helpers.
Draft redirect config from a URL map.
Normalize image imports.
Refactor repeated CTA blocks.
Generate test cases for key components.
Identify unused CSS or duplicate markup.
These tasks are bounded. The output can be reviewed.
A good prompt gives Claude the constraint, the pattern, and the acceptance criteria. For example:
Convert these three repeated testimonial sections into one reusable React component. Keep the existing copy unchanged. Support logo, quote, name, title, company, and optional case study URL. Return the component plus the updated page usage.
That is a useful coding task.
The contrarian stance: do not ask Claude Code to migrate the whole site end-to-end. Ask it to perform controlled tasks inside a migration plan.
The tradeoff is clear. End-to-end prompting feels faster at the beginning. Controlled prompting is faster by launch because it reduces rework, QA failures, SEO surprises, and stakeholder review cycles.
Claude should not decide:
Which pages matter commercially.
Which URLs can change.
Which proof points should be retained.
Which CTAs deserve priority.
Which product claims are risky.
Which schema types apply.
Which pages should be consolidated.
Which analytics events define success.
Those decisions belong to strategy, SEO, design, and engineering leads.
The same principle applies to the Webflow side. Webflow's Anthropic Claude integration page describes an MCP connector that can help manage CMS items, run audits, and create content through natural language. That is operationally useful, but it does not remove the need for migration governance.
The strongest public proof point in this space is the ZenML rebuild: 2,224 pages, 20 CMS collections, and a reported one-week migration from Webflow to a custom stack using Claude Code and multiple models, as described by ZenML.
Baseline: a large Webflow marketing site with thousands of pages and many CMS collections.
Intervention: AI-assisted rebuilding into a custom framework with a structured workflow.
Outcome: a reported rebuild completed in one week.
Timeframe: one week, based on the published case study.
That does not mean every SaaS company should expect the same timeline. It means the ceiling for AI-assisted migration speed is materially higher when the work is structured. The practical question is not whether Claude Code can move fast. It is whether the team has enough control to know what moved correctly.
A marketing site migration touches acquisition, conversion, and sales confidence at the same time. Treat launch readiness as a set of controls, not opinions.
The first rule is simple: if a URL has organic traffic, backlinks, sales usage, or internal links, it needs a decision.
The decision can be:
Preserve the URL.
Redirect it to a stronger equivalent.
Consolidate it into a better page.
Retire it intentionally.
Do not let URL changes happen as a side effect of routing preferences.
A redirect config might look like:
const redirects = [
{
source: '/old-feature-page',
destination: '/features/new-feature-page',
permanent: true
},
{
source: '/customers/old-slug',
destination: '/customers/new-slug',
permanent: true
}
]
The important part is not the syntax. It is the mapping discipline.
A migration is a chance to improve how the site is understood by search engines and answer engines.
Each important page should have:
A clear title tag.
A specific meta description.
One primary H1.
Logical H2 and H3 structure.
Direct answers to buyer questions.
Entity-rich copy that explains the product category, audience, use cases, and alternatives.
FAQ sections where the questions are real.
Schema where it accurately reflects the page.
Internal links to related proof and conversion pages.
The goal is not to stuff pages with schema. The goal is to make the company easy to understand, verify, compare, and cite.
This is where Raze connects website migration with AI SEO and AEO. A Next.js rebuild can create the technical foundation, but the content must still answer the questions buyers and answer engines are asking.
For example, a migration page should not only say that the product supports migration. It should explain who migrates, from what systems, how long it takes, what breaks, what data moves, what support exists, and what proof exists. That is the difference between a page that looks complete and a page that reduces buyer effort.
Do not carry messy analytics into a cleaner codebase.
Define events before launch:
demo_cta_clicked
pricing_viewed
contact_sales_submitted
sandbox_started
integration_docs_clicked
comparison_page_cta_clicked
roi_calculator_completed
Then define required properties:
Page path.
Page type.
CTA location.
Persona, if known.
Content category.
Campaign source.
Form destination.
This gives growth teams the ability to see which templates and messages create qualified action. Without event discipline, the migration may improve the codebase while leaving the funnel just as opaque.
Most migration issues are not dramatic. They are small leaks that compound.
If the homepage narrative is unclear in Webflow, moving it to Next.js will not fix it.
Before migration, tighten the sales argument:
Who is this for?
What painful problem does it solve?
Why is this different?
What proof reduces risk?
What action should the buyer take next?
Only then should the design and code system scale the story.
Claude may summarize, smooth, or rephrase copy unless told not to.
That can remove specificity. A phrase like reduce SOC 2 evidence collection time for security teams can become streamline compliance workflows. The second version sounds cleaner but sells less.
During migration, protect product terms, customer language, proof points, and CTA labels. If copy is changing, make it a deliberate messaging project.
CMS content is not just rows and fields.
It contains editorial structure, internal links, author credibility, image metadata, related content, and conversion modules. A bulk import without schema design can create hundreds of pages that technically exist but perform worse.
For B2B SaaS sites, this is especially risky on comparison pages, integration pages, and technical trust pages. Those pages often influence buyers before they talk to sales.
Desktop screenshots are not enough.
Buyers research on laptops, tablets, and phones. Investors, consultants, and operators often share links in Slack or email where mobile preview and first-scroll clarity matter.
Check mobile order for:
Hero proof.
CTA visibility.
Product screenshots.
Comparison tables.
FAQ accordions.
Forms.
Sticky navigation.
Customer proof.
A beautiful desktop page can still bury the buying argument on mobile.
The launch is not the end of the migration. It is the start of the risk window.
Track these daily for the first week:
404s.
Form errors.
Demo submission volume.
Top landing page traffic.
Indexing warnings.
Redirect behavior.
Page speed regressions.
Analytics event firing.
CRM attribution gaps.
Then review weekly for the first month.
If rankings dip slightly while search engines process changes, the team needs to know whether the fundamentals are intact. If demo volume drops, the team needs to isolate whether the issue is traffic, tracking, form behavior, or conversion design.
No. Claude Code is the AI-assisted coding environment used to help rebuild or refactor the site, while Next.js is the destination framework. In practice, migrating from Webflow to Claude Code usually means using Claude Code to accelerate the move from Webflow into a custom codebase such as Next.js.
Claude Code can accelerate component creation, refactoring, and code generation, but it should not be treated as a fully automatic migration owner. The team still needs URL inventory, CMS mapping, SEO preservation, analytics QA, design review, and conversion review.
Start with the page inventory, CMS model, assets, metadata, analytics events, and top-performing URLs. Then rebuild one representative page in Next.js to validate component structure, responsive behavior, and content fidelity before scaling the process.
Preserve or redirect important URLs, maintain metadata where pages already perform, validate canonical tags, generate a clean sitemap, and crawl staging before launch. After launch, monitor Search Console, 404s, indexing behavior, and organic landing page performance.
Hire help when the migration affects pipeline, SEO, brand trust, or product-led conversion paths. A SaaS web design agency or AI SEO agency is useful when the project needs positioning, design systems, Next.js execution, analytics, and answer-engine visibility handled together.
It is worth it when Webflow is slowing growth execution, limiting technical control, or making the site harder to scale. It is not worth it if the team only wants a more premium-looking site without fixing messaging, conversion paths, content structure, and measurement.
If your Webflow site is starting to limit GTM speed, search visibility, or conversion clarity, book a migration planning session with Raze.

Ed Abazi
140 articles
Co-founder at Raze, writing about development, SEO, AI search, and growth systems.

Learn how SaaS pricing page UX can help consultants and evaluators compare tiers faster, reduce friction, and improve qualified conversions.
Read More

Learn how SaaS brand identity should evolve after Series A, with 5 visual cues that help early-stage teams look credible to enterprise buyers.
Read More