WordPress to Webflow Migration: A Practical Checklist

Your WordPress to Webflow migration should start with a site inventory, a URL redirect map, a CMS field map, and a test plan for forms and tracking. Build and test the new site before switching your domain. Then check the live customer journey, from landing page to CRM record, before calling the migration finished.

I’m a Webflow Premium Enterprise Partner. I’m a developer who thinks like a marketer, so I care about what happens after someone clicks “Book a demo.” I run a company of one, small on purpose, with no handoffs.

This guide covers the technical work that protects your campaigns. I focus on the technical side of SEO.

1. Inventory what your team depends on

I’d start with what your site does, then document how it looks. A page can look right while sending leads to the wrong place.

Create one migration sheet. Give each page or function an owner, a destination, and a test.

• [ ] Crawl the current site and export its URLs.
• [ ] Add URLs from your sitemap, analytics, and Search Console.
• [ ] Include paid landing pages, downloads, and pages outside navigation.
• [ ] Export existing redirects, including rules from plugins and hosting.
• [ ] List forms, notifications, CRM connections, and booking tools.
• [ ] Record tracking tags, conversion events, and consent settings.
• [ ] Save titles, descriptions, canonical URLs, and indexing rules.
• [ ] Back up WordPress files, its database, and media.

Record a baseline for organic landing-page traffic, form submissions, and CRM arrivals. Use comparable periods and note any campaigns that could affect the numbers.

I’d also separate the marketing site from product features. Account access, billing, documentation, or a customer portal may need a different migration plan.

2. Map the CMS before importing content

I’d define your content structure before building templates. Your team needs fields that make sense when publishing a campaign under a deadline.

As of Oct 2026, Webflow documents CSV import for moving WordPress content into CMS Collections. Its guide describes converting the default WordPress XML export to CSV, then mapping fields. Check current pricing and plan limits before choosing a plan. See Webflow’s migration guide.

Here is a starting map. Treat it as a planning comparison, not an automatic conversion.

WordPress source	Proposed Webflow destination	What I’d verify
Posts	Blog posts Collection	Slugs, dates, body formatting
Pages	Static pages or a suitable Collection	Which pages share a repeatable structure
Categories and tags	Category fields or related Collections	Filters, links, and archive pages
Authors	Authors Collection	Bios, images, and post relationships
Custom fields	Matching CMS fields	Field types and missing values
Featured images	Image fields	Files, alt text, and display
SEO plugin fields	Fields connected to page SEO settings	Titles, descriptions, and canonicals
Shortcodes and page-builder blocks	Rebuilt content or components	What needs manual work

Import a small, varied sample first. Include a long article, an older post, a table, an embed, and content with multiple authors or categories.

• [ ] Preserve slugs where the planned structure allows.
• [ ] Map original publication dates explicitly.
• [ ] Rebuild author and category relationships.
• [ ] Replace shortcodes and broken embedded content.
• [ ] Check images, captions, alt text, and downloads.
• [ ] Update internal links to their final destinations.
• [ ] Compare source and destination item counts.
• [ ] Keep drafts and private content out of public publishing.

An import that completes without errors still needs a content review. Check what a reader sees.

3. Build the redirect map before launch

I’d keep existing URLs wherever practical. Every unnecessary URL change adds another thing to test.

For each old URL, record the intended outcome: keep it, redirect it, or retire it.

Old URL example	Intended outcome	Launch check
/pricing	Keep /pricing	Page loads successfully
/2024/05/demo-guide	Redirect to /blog/demo-guide	Permanent redirect reaches the matching article
/old-product	Redirect to its direct replacement	Destination answers the same need
/expired-event	Retire if no useful replacement exists	Clear missing-page response

These are examples, not a suggested structure for every site.

Use permanent redirects for moved pages. Avoid sending unrelated retired pages to the homepage. Google recommends relevant destinations and warns that irrelevant redirects can be treated as soft 404s. See Google’s site migration guidance.

As of Oct 2026, Webflow supports CSV redirect imports. Its documentation says an import replaces existing redirect rules, so export and merge those rules first. Publish for the imported redirects to take effect. Check current pricing before selecting your plan. See Webflow’s redirect import instructions.

• [ ] Map changed URLs to their closest relevant destination.
• [ ] Carry forward redirects from earlier site changes.
• [ ] Remove loops and unnecessary redirect chains.
• [ ] Check trailing slashes and old URL variations.
• [ ] Test campaign links with tracking parameters.
• [ ] Check important PDF and image URLs.
• [ ] Verify that final destinations load successfully.

I’d test the full redirect list with a crawler, then manually check your most important campaign and search landing pages.

4. Test forms all the way into your CRM

I’d treat every form as a small workflow. The thank-you message is only one part of it.

For each form, document its fields, destination, notification recipients, success state, and follow-up action. Decide whether to retain an existing embedded form or rebuild the flow.

Keep the existing form provider if its routing and automation already serve your team. Rebuilding it adds testing work, even when the visible fields look identical.

• [ ] Match required fields and validation.
• [ ] Map fields to the correct CRM properties.
• [ ] Preserve agreed attribution fields, such as campaign source.
• [ ] Test consent fields and stored values.
• [ ] Check notifications and lead assignment.
• [ ] Confirm downloads, booking links, and follow-up emails.
• [ ] Test errors, repeat submissions, and mobile use.
• [ ] Verify spam controls without blocking legitimate submissions.

Submit clearly labeled test leads. Open the resulting CRM records and inspect them.

A success message does not prove that sales received the lead. I’d require that final check before launch approval.

5. Rebuild tracking with a clear event list

I’d list what your team measures before copying scripts. Otherwise, old tags tend to arrive alongside their replacements.

For each event, record its name, trigger, destination, and expected behavior. Start with page views, successful demo requests, signups, downloads, and booking completions.

• [ ] Identify every place analytics code is installed.
• [ ] Use one intended installation path for each tag.
• [ ] Preserve event names where reporting depends on them.
• [ ] Trigger lead events on confirmed success.
• [ ] Check that each intended conversion fires once.
• [ ] Test accepted and rejected consent states.
• [ ] Verify attribution across booking or product domains.
• [ ] Exclude test activity where your reporting setup allows.
• [ ] Keep personal form data out of analytics events.

Use your tag preview tools and analytics debugging reports. Check both successful and failed form attempts.

I’d compare three records: the form submission, the CRM arrival, and the analytics event. They measure different things, so document expected differences instead of assuming every count will match.

6. Set a launch gate your team can use

I’d avoid combining a platform move with a domain change and a full content rewrite. Smaller changes are easier to diagnose. Google also recommends separating major changes in its site move guidance.

Before switching the domain:

• [ ] Agree on a content freeze and a final import.
• [ ] Assign an owner for changes made after the first export.
• [ ] Review mobile layouts and keyboard access.
• [ ] Check page titles, headings, canonicals, and indexing settings.
• [ ] Keep staging out of search results.
• [ ] Confirm production pages can be indexed where intended.
• [ ] Prepare the final sitemap.
• [ ] Record current DNS settings and protect email records.
• [ ] Document rollback steps and who can authorize them.

Hold launch if a core demo form fails, important pages are missing, or tracking cannot be verified.

Keep the WordPress backup and a controlled recovery path until the new site has passed live checks.

7. Check the live site and hand it over

Repeat your critical tests on the production domain. Staging results do not prove that live integrations work.

On launch day, check redirects, forms, CRM arrivals, consent behavior, and conversion events. Crawl the live site for broken links and incorrect destinations.

During the following weeks, review search indexing, landing-page traffic, and lead flow. Investigate changes against your baseline. A reporting drop could come from a broken tag, a campaign change, or fewer visitors.

Then ask someone on your marketing team to complete a real task:

• [ ] Update a page.
• [ ] Publish a CMS item.
• [ ] Change a campaign link.
• [ ] Find a form submission.
• [ ] Explain the publishing and recovery process.

I’d judge the handoff by those tasks. Your team should know how to run the site after launch.

Pick Webflow if... Pick WordPress if...

Pick Webflow if your main need is a marketing site with repeatable content and a clear publishing process. I’d confirm the proposed CMS structure and integrations with a working sample first.

Pick WordPress if your site depends on specialized plugins or custom publishing behavior that would be expensive to recreate. I’d fix the editing bottleneck before assuming a platform move is necessary.

Pick a split setup if your marketing site and product have different needs. I’d keep account features in the product and define how navigation, forms, and tracking connect across the two.

FAQ

How long does a WordPress to Webflow migration take?

I’d estimate after auditing templates, content, integrations, and review needs. Page count alone misses the work. A small site with complex lead routing can need more testing than a larger, simpler blog.

Will the migration affect SEO?

It can. Google notes that rankings may fluctuate during a site move. I’d preserve useful content and URLs, test redirects, and monitor indexing. I would not promise unchanged rankings. See Google’s migration guidance.

Can I move WordPress content automatically?

Partly. Content import can reduce copying, but field mapping and formatting still need review. I’d test representative posts before importing everything. Themes, shortcodes, and form workflows need their own rebuild plan.

Do I need a redirect for every page?

No. If the full public URL stays the same and serves the intended page, it does not need a migration redirect. I’d map every old URL, then add redirects where destinations change.

When can I cancel WordPress hosting?

I’d wait until live checks pass and recovery no longer depends on that hosting. Confirm that media, downloads, email services, and old redirects have no remaining dependency.

Start with your highest-value landing page and trace its full journey. Once you can verify the page, the form, the CRM record, and the tracking, you have a clear pattern for checking the rest.