How to migrate to Sanity from WordPress or Webflow

If you're thinking about moving your website to Sanity, you're probably wondering what that means for your team. A Sanity migration touches your traffic, your rankings, and your publishing calendar, so it's worth answering two questions before anyone writes an import script. Should you migrate to Sanity at all, and what does the move really involve?

Moving to Sanity is two projects. Sanity holds your content, and your website becomes a separate frontend that someone has to build, host, and maintain. When a migration runs over budget, it's usually because you underestimated that second project.

We build on both Webflow and Sanity and have run 100+ migrations, so this guide also covers when staying put is the better call. You'll find a fit test, the 9 steps we follow, what's different for WordPress and Webflow, and how to protect your SEO through launch.

What changes when you move to Sanity?

Moving to Sanity splits your website in two, with Sanity storing the content and a separate application rendering the pages. Sanity is a headless CMS, so it holds your content as structured data and serves it through APIs. The site itself is usually built in Next.js or Astro and hosted somewhere like Vercel.

That's a different setup from what you run today. WordPress renders pages through a theme and a stack of plugins. Webflow puts design, CMS, and hosting in one tool, so a designer can build a page and publish it the same afternoon. If you want the architecture in more depth, our explainer on headless vs. traditional CMS covers it.

For a marketing team, the gains are real. One entry can feed the website, a product UI, and a help center. Several editors can work in the same document at once. And the editing interface, Sanity Studio, is configured around your content and workflow instead of a generic admin panel.

You give some things up too. Nobody designs pages visually on a canvas anymore, and a new layout or section type means a developer has to write code.

Should you migrate to Sanity?

Sanity pays off when your content serves more than one channel, or has outgrown a page-based CMS, and you have developers to keep it moving. For a small team running one marketing site, it usually slows things down.

We build on both platforms, so we can give you either answer without a stake in it. If you want the full cost and trade-off breakdown, read our Sanity vs Webflow comparison first and come back for the migration plan.

Signs you're ready for Sanity

• The same content feeds the website plus an app, docs, or a product UI.
• Your content model has outgrown page templates. You're forcing case studies, integrations, and product features into fields that were built for blog posts.
• Editors copy and paste the same text into several places and fix it in several places when it changes.
• You have in-house or agency developers available every week, well beyond the initial build.

For Webflow teams, collection size is a specific, checkable signal. Per Sanity's Webflow migration course, Enterprise Webflow plans support 20,000 to 100,000+ items per collection. If you're hitting item ceilings on a lower plan and can't justify Enterprise, that's a real reason to look at Sanity.

For WordPress teams, the sign is usually slow releases. Plugin updates, security patches, and a heavy page builder hold up every change, and fixing one thing can break another.

Take a product marketing team that publishes the same feature content on the website and inside the product. If a developer already looks after that setup, the team is ready for Sanity.

Signs you should stay on Webflow

• One marketing website is your only channel.
• Designers want to build and ship pages visually, without a ticket.
• There's no developer capacity after launch.
• The budget is fixed, with no room for a separate frontend and its hosting.

If that's you and you're on WordPress today, moving to Webflow is often the better move than moving to Sanity.

In Sanity, schemas are code, so every new field or section type is a developer task. That's a strength when developers are on hand and a bottleneck when they aren't. Pick the one that matches the team you'll have a year after launch.

Who do you need for a Sanity migration?

A Sanity migration needs five roles, whether they sit in-house, at an agency, or across both:

• Strategist or project lead owns scope, timeline, and sign-off, and keeps marketing and engineering talking.
• Content modeller or Sanity developer designs the schemas and configures Sanity Studio.
• Frontend developer builds the site, handles rendering, and owns performance.
• SEO lead owns the URL map, redirects, and metadata from audit to post-launch monitoring.
• Editors check migrated content and give early feedback on the Studio.

On a small site, one person can hold two or three of these. You can't skip the frontend or SEO roles, though, because nobody else covers that work by accident.

Marketing has to stay in the room for content model reviews and editor testing. A model built without the people who'll use it every day is the most common source of post-launch frustration we see.

Larger teams should also plan permissions early. Our guide to governance and roles in Sanity covers how enterprise teams set that up. If you're bringing in an agency for some of these roles, our website migration RFP template helps you scope the work and compare proposals.

How to migrate to Sanity in 9 steps

We run these nine steps, in this order, on every Sanity project.

Step 1: Audit your content and URLs

Export every live URL with its title, meta description, canonical, and traffic, plus Search Console data for your top pages. Put it all in one spreadsheet, then add:

• Content types and taxonomies, each marked migrate, rebuild, or drop
• Integrations that touch the site, from CRM forms to the chat widget
• A redirect column with each old URL's planned destination

Leaving old drafts and unused media behind now saves cleanup later. The SEO lead and project lead should both sign off on the spreadsheet before Step 2.

Step 2: Design the Sanity content model

Content modelling describes what your content is and leaves the page layout to the frontend. A case study has a client, an industry, a result, and a quote, so the same entry can appear on a page, in a feed, or inside your product.

Three rules keep the model safe:

• Start close to your current structure and improve the model after launch.
• Build pages from reusable sections, like a hero, a feature grid, or a CTA block, so editors can create pages without a ticket.
• Have editors review the model before any import runs, because changing a field after 2,000 entries costs far more than changing it on a whiteboard.

Step 3: Choose and build the frontend

Most teams build the frontend in Next.js, Astro, or Nuxt. Pick the one that suits who will maintain it, what it needs to connect to, and where it will be hosted.

For SEO, ask your developers to pre-build or server-render every page. That way, search engines and AI crawlers see the full content straight away.

Set up visual preview early. Sanity's Presentation tool lets editors click into a live preview of the page and see changes before they publish, which takes some of the sting out of losing Webflow's canvas.

If you're coming from Webflow, budget for interactions and animations. They don't export, so every scroll effect and hover state gets rebuilt in code.

Step 4: Move your content into Sanity

Your developers move the content in four stages:

• Export your content from WordPress or Webflow through their APIs
• Convert rich text into Portable Text, Sanity's structured format for rich text
• Upload images and other media to Sanity
• Create the matching documents in Sanity, keeping the links between authors, categories, and related posts intact

Run the import into a test dataset first, then check a sample of migrated pages by hand. Scripts can report success while quietly dropping formatting.

The WordPress and Webflow sections below cover what's specific to each source.

Step 5: Map redirects and SEO fields

Finish the redirect map you started in Step 1 once the new routes are set, and test every redirect in staging. Redirects mapped in launch week are redirects mapped badly.

At the same time, give every page and post type its own SEO fields so editors can control search and AI visibility after launch without filing a ticket. Each one should have:

• SEO title
• Meta description
• Canonical URL
• Open Graph image
• Noindex toggle
• Schema type

Structured content helps with AI search too. Entries in Sanity are already machine-readable, so schema markup and an llms.txt file can be generated from the same model. Our piece on structured content for LLMs goes deeper, and the SEO section below covers what to protect and monitor.

Step 6: Set up roles, locales, and security

Configure user roles in Sanity Studio for editors, reviewers, and admins, so only the right people can publish.

Decide on localisation early. Translations can live as separate documents per language or as translated fields inside one document. Switching later means re-migrating content, so make the call before the import runs.

Close out security requirements with whoever signs them off. These usually include:

• SSO
• Access control
• Audit needs
• Any compliance rules your industry applies

Step 7: Reconnect integrations and analytics

Make a list of everything that needs rewiring, including:

• CRM forms
• Marketing automation
• GA4 events
• Your tag manager
• Your consent banner

On a custom frontend, tracking is built in code. You can't paste a snippet into a site header the week before launch, so specify every event up front, including form submissions, demo requests, downloads, and key clicks.

During QA, compare conversion events on the old and new sites side by side. A form that never reaches the CRM shows up weeks later as a pipeline problem.

Step 8: QA and launch the Sanity site

Run the launch checks to confirm that:

• Every old URL returns a 301 to the right new page
• Titles, descriptions, and canonicals match the audit
• Pages render correctly in major browsers and on mobile
• Core Web Vitals hold or improve on your top templates
• Forms submit, and tracking fires
• Unpublished drafts show in the preview but never on the live site
• A fake URL returns a real 404 status and a styled error page
• Required fields block publishing when an editor leaves them empty

Freeze publishing on the old CMS during the final content sync, so nothing published in the launch week gets lost between systems. Keep the old site accessible privately until post-launch checks are complete.

If you want these checks in a working document, use our downloadable website migration checklist.

Step 9: Train editors and hand off

Training starts while QA is still running, so editors know the Studio before launch day, and the handoff finishes once the site is live. If editors see the Studio for the first time on launch day, they'll likely hand every small change to a developer instead of making it themselves.

A good handoff includes live training on real content, short video walkthroughs of common tasks, and a written guide to the content model.

Plan for what comes after, too. New sections, new fields, and schema changes keep needing developer time once the site is live. Some teams cover that in-house, and others use ongoing WebOps support so the backlog doesn't stall.

What's different about a WordPress to Sanity migration?

A WordPress to Sanity migration takes the most work in two places, rebuilding what your plugins did and cleaning up old post HTML. Developers can export the content in two ways:

• REST API, for most business sites with custom fields or custom post types
• XML export, for simple blogs only

None of your plugins come across automatically, including:

• Yoast or Rank Math SEO metadata
• Plugin forms and redirects
• Advanced Custom Fields (ACF) data
• Shortcodes and page-builder layouts

Each one has to be rebuilt in Sanity or the frontend, so list every active plugin in your Step 1 audit.

Post bodies also need converting from HTML to Portable Text. Budget time for a person to review the output, on top of the time the script takes to run.

For your developers: WordPress to Sanity

• Pull content through the WordPress REST API (/wp-json/wp/v2/) using an Application Password. Paginate requests, and fetch ACF fields and custom post types explicitly. ACF field groups only appear in the REST API once Show in REST API is switched on in each group's settings.
• Convert post HTML to Portable Text with @portabletext/block-tools (htmlToBlocks) and a JSDOM parser. Map shortcodes and page-builder markup to custom block types instead of leaving raw HTML.
• Pull attachment metadata from /wp-json/wp/v2/media, download the files, and upload them to Sanity assets first. Keep a map of WordPress IDs to Sanity IDs so author, category, and related-post references resolve.
• Batch writes into transactions and stay under the 25 mutations per second per IP rate limit on Sanity's direct API. If migrations still hit it, lower the --concurrency setting.
• Run imports as Sanity CLI migrations, which stay in dry-run mode until you pass --no-dry-run.
• For a step-by-step walkthrough, see Sanity's course Migrating content from WordPress to Sanity.

Engineering leads who would rather not run this in-house can hand it to our WebOps team for engineering teams.

What's different about a Webflow to Sanity migration?

A Webflow to Sanity migration needs extra care with CMS content and images. Webflow's code export leaves out your CMS items, so developers pull every collection through the Webflow Data API, or use CSV exports on very small sites.

Images cause the most trouble. Per Sanity's migration course, the Webflow Assets API misses images in CMS fields and rich text, so developers have to find those files and move them separately. Skip that, and you'll launch with broken images.

Don't cancel your Webflow plan until every asset is confirmed in Sanity.

Designers feel the change most, since interactions get rebuilt in code and visual preview replaces the canvas. Decide early which interactions are worth rebuilding.

For your developers: Webflow to Sanity

• Fetch collections through the Webflow Data API v2 and write items to disk as NDJSON. Reference fields come back as Webflow item IDs, which map cleanly to deterministic Sanity _ids.
• Run an asset pre-upload pass before any documents. Scan CMS fields, rich text, and the HTML export for Webflow CDN URLs, upload them, and save the URL-to-asset map.
• Import collections with no incoming references first, then the collections that reference them.
• Convert rich-text HTML to Portable Text, and extract design tokens (colors, type scale, breakpoints) from the exported CSS for the new frontend.
• Model Webflow Localization content with sanity-plugin-internationalized-array, which matches how Webflow stores locales, or @sanity/document-internationalization if each language publishes separately.
• For a step-by-step walkthrough, see Sanity's course Migrating from Webflow to Sanity.

How do you protect SEO during a Sanity migration?

You protect SEO by redirecting every old URL permanently and changing one thing at a time. Per Google's guide to moving a site with URL changes, 301 and other permanent redirects don't cause a loss in PageRank. Google also advises making big changes, like a new CMS and a new design, one after the other instead of all at the same time.

Our recommendation follows from that. Migrate 1:1 first, launch, let rankings settle, then redesign. When rankings move after a 1:1 launch, you know the platform caused it and can fix it before a redesign adds more change.

Headless sites also need SEO built in on purpose. Sitemaps, canonicals, structured data, and rendering all live in the frontend your developers write, so each one has to be in the spec.

The weeks after launch matter as much as launch day. That's when you catch missed redirects and start the organic work the migration was meant to make easier, which is where our SEO and AEO service usually picks up.

Redirect rules for your old URLs

• Map every indexed URL one-to-one to its new equivalent.
• Use permanent (301) redirects.
• Avoid chains and loops. Each old URL should reach its final page in one hop.
• Update internal links to point to the new URLs directly.
• Test the full redirect map in staging before launch.

Keep them live for a long time. Google's site move guide says to keep redirects for as long as possible, generally at least 1 year, so it can transfer all signals to the new URLs. For visitors, it suggests keeping them indefinitely, and that's what we recommend too.

On Sanity, redirects are often modelled as their own document type. Marketers can add a redirect in the Studio without waiting for a developer deploy.

For the first two weeks after launch, check Search Console coverage and 404 reports every day.

Planning your move to Sanity

Start with the fit test, because the cheapest migration is the one you don't need. If Sanity fits, budget it as two projects, run the nine steps in order, and protect SEO from the audit onward instead of from launch week.

If you want one team to own the model, the frontend build, the migration, and the post-launch work, our Sanity agency team runs exactly that process.

Before you move anything, a free AI website audit gives you an SEO and site-health baseline to measure the new site against. And if you're still weighing Sanity against Webflow, book a free strategy call, and we'll tell you which one we'd pick for your team.

FAQ about migrating to Sanity