WordPress → Webflow
Move structured WordPress content into a prepared Webflow CMS model with explicit schema, reference, publishing, validation, and URL rules. Webflow static pages, Designer layouts, and application behavior are separate implementation scope.
Self-service migration path
This pair is not currently listed as a fully supported self-service direction. wordpress: Available. webflow: Beta. Review system status and directions. Available migration objects and capabilities depend on the selected source and target systems.
Create an account, connect a staging destination, and let the app analyze the supported scope for this direction.
No credit card required to analyze the migration and run a free sample.
Scope
The app confirms available entities after connection. Final coverage depends on source access, downloadable assets, and the destination model you prepare.
Before you connect
Use a staging destination and the least-privilege access supported by each platform. Do not send credentials through a public form.
Provide the WordPress URL, migration username, and Application Password. Required post types, taxonomies, media, and plugin fields must be visible through REST or a compatible Bridge.
Provide the Webflow site URL, Site ID, and API token with CMS read and write scopes. Explicit posts, authors, and categories Collection IDs reduce auto-detection risk.
Approve Collection schemas, field slugs and types, required fields, references, URL paths, templates, locale settings, and publishing workflow before loading records.
How it works
You control each stage in the app. Optional expert assistance is available for custom data or destination requirements.
Start in the app and select the real source and target.
Authorize read access to WordPress and connect a prepared staging Webflow destination.
Review detected records, available entities, media, URLs, and anything that needs a decision.
Choose where supported WordPress data belongs in the prepared Webflow model.
Move a small set of real records to staging and inspect the result before purchasing the full migration.
Review counts, records, media, links, warnings, and exceptions, then purchase and start the full migration when ready.
Technical detail
Open only the detail you need for planning, mapping, or validation.
This page is synchronized with the WordPress source and Webflow destination capability snapshots. Both platforms are enabled in both directions, but the current Webflow target writes CMS Collection items—not Designer-managed static pages.
The current REST path reads posts and pages plus supported authors, taxonomies, and media. Broader custom post types, comments, menus, and plugin data depend on the selected Bridge or project-specific extraction scope.
The target creates and updates authors, categories, and configured blog/article Collection items. It resolves the actual Collection schema and drops fields that cannot be safely matched.
Standard means the current adapters expose a direct structured path into configured Webflow Collections. Review means the destination schema or transformation must be approved. Custom means Webflow has no equivalent target entity in the current adapter.
| WordPress source | Webflow target | Status and boundary |
|---|---|---|
| Posts | Configured blog or article Collection items | Standard: title, slug, body, excerpt, date, and approved status are mapped into matching fields. |
| Custom post types | One configured Collection or custom destination model | Review/custom: source extraction depends on the Bridge or adapter, while multiple destination models need routing rules or additional adapter work. |
| Pages | Designer static pages or a CMS Collection | Custom: the current Data API adapter refuses static-page creation. Pages must be rebuilt or deliberately remodeled as Collection items. |
| Authors | Authors Collection and reference field | Standard with mapping: author records load first and their Webflow item IDs are assigned to posts. |
| Categories and tags | Categories/tags Collection and references | Review: WordPress taxonomies may be consolidated or separated according to the prepared Webflow schema. |
| Featured image | Matching Webflow Image field | Standard with validation: a public source URL and compatible destination field are required. |
| Inline images and documents | Rich text, Image, or File fields | Review: body references and standalone files need an explicit hosting, import, rewrite, and optimization rule. |
| Published, draft, scheduled, pending, private, or trash status | Webflow staged/draft or live state | Review: nonstandard WordPress states must be translated explicitly so restricted content is never accidentally published. |
| Publication date | Matching Webflow Date/Time field | Standard when prepared: the destination schema must contain an approved date field. |
| SEO plugin fields and source URLs | CMS fields, Collection template SEO, and redirect plan | Review: recognized metadata can populate matching fields; template bindings and redirects are separate destination configuration. |
| Comments | No configured Webflow target entity | Custom or archive: comments do not have a standard destination path. |
| Menus and menu items | Designer navigation or a custom Collection | Custom: Webflow navigation is not a configured target entity in the current adapter. |
| Users, roles, passwords, and memberships | Webflow users or membership solution | Custom: authors are content identities, not authentication migration. |
| ACF, blocks, shortcodes, plugin records, and forms | CMS fields, components, embeds, or applications | Custom: each business-critical field or behavior needs an explicit transformation and destination implementation. |
| Theme, templates, widgets, and front-end behavior | Webflow Designer implementation | Rebuild: WordPress presentation does not transfer as CMS data. |
The approved mapping workbook ties each WordPress entity and field to a real Webflow Collection field, including its slug, data type, requirement, relationship, and fallback.
| WordPress value | Migration rule | Webflow result |
|---|---|---|
| Post ID | Preserve as source identity in the migration dataset and source-to-target map | Stable Collection item lookup for reruns and delta updates |
| Title, slug, content, excerpt | Normalize rendered content and resolve matching destination field slugs | Name, slug, Rich Text, and summary fields |
| Author ID | Load authors first and replace the WordPress ID through the migration map | Valid Webflow Reference or Multi-reference item ID |
| Category and tag IDs | Load approved terms first, then resolve and consolidate relationships | Category or tag Reference/Multi-reference values |
| Featured media URL | Validate the source URL and match a real Image field in the target schema | Webflow Image field value |
| Published date | Normalize the date and match a Date/Time field | Collection item publication-date field |
| SEO title and description | Normalize recognized plugin values and bind them to approved fields | CMS metadata fields used by the Collection template |
| Post status | Apply the approved WordPress-to-Webflow state table | Staged/draft item or published live item |
Webflow is schema-first: a successful API request can still produce an unusable site if Collections, references, templates, and URL paths were not designed first.
List posts, pages, custom post types, taxonomies, authors, media, plugin fields, counts, statuses, and relationships.
Choose which WordPress types share a Collection, which require separate architecture, and how required fields and URL slugs will work.
Prepare authors and taxonomy Collections before content so Reference and Multi-reference fields receive valid Webflow item IDs.
Connect imported CMS fields to Collection templates, SEO settings, lists, filters, conditional visibility, and conversion components.
WordPress permalink structures and Webflow Collection URLs are different systems. The destination URL model must be approved before item creation.
Crawl every indexable WordPress URL and pair it with an approved Webflow static or Collection destination before launch.
Map recognized metadata into CMS fields, bind those fields to Collection page SEO settings, and verify titles, descriptions, canonicals, and social previews.
Rewrite internal links, decide where assets are hosted, configure old-to-new redirects, and prevent path collisions or redirect chains.
Check sitemap output, crawlability, analytics, conversion paths, redirect logs, high-value pages, and indexation during stabilization.
Acceptance covers the destination CMS model and rendered Webflow site, not only record creation through the API.
Reconcile source, extracted, loaded, skipped, failed, staged, and published totals by post type, taxonomy, and destination Collection.
Inspect rich text, excerpts, dates, required fields, authors, taxonomy references, custom transformations, and source-to-target IDs.
Validate featured images, inline media, files, responsive behavior, Collection templates, lists, filters, links, and representative complex records.
Test metadata, canonicals, sitemap entries, redirects, analytics, and document every corrected, accepted, deferred, or custom exception.
Before purchase
The free sample migration creates a limited set of records in staging. Check fields, relationships, media, URLs, rendering, and reported exceptions before paying for the full run.
Pricing
Package fit depends on supported record volume and complexity. Analyze the source first, then review the fixed package or dynamic estimate shown for the migration.
Compare migration packagesPlan the move
Review Webflow destination Collections, references, localization, publishing, and static-page boundaries.
Open guide →Review WordPress source extraction, plugin-owned data, users, media, and URL handling.
Open guide →Understand the broader content migration scope and delivery boundaries.
Open guide →See how mapping, dry runs, validation, and cutover decisions are controlled.
Open guide →Clear answers
No. The current Webflow target adapter creates CMS Collection items and explicitly rejects static-page writes. WordPress pages need a Designer rebuild or an approved transformation into a Collection.
They require source review because the current WordPress REST content adapter reads posts and pages. A compatible Bridge or project-specific extraction plus destination routing may be needed for custom post types.
Only fields exposed and explicitly mapped to compatible Webflow fields can transfer safely. Blocks, shortcodes, embeds, reusable patterns, and plugin data require content-specific transformation and rendering review.
Authors can migrate as content identities and references. WordPress roles, passwords, customer accounts, and membership behavior are not part of the standard CMS path.
The current Webflow target does not expose standard comment or navigation entities. They must be archived, remodeled into Collections, or rebuilt in Webflow Designer.
Localization is destination- and plugin-specific. WordPress language relationships must be extracted explicitly, and Webflow locale IDs, variants, URLs, and publishing rules must be configured and validated.
Rankings cannot be guaranteed. Reduce risk with URL mapping, metadata and template checks, redirects, internal-link updates, sitemap validation, analytics, and post-launch monitoring.
Yes. Representative content is loaded into Webflow staging, systematic mapping issues are corrected, acceptance checks are completed, and the approved rules are reused for the final or delta run.
Next step
Create an account, connect the systems, and analyze the supported scope before purchasing the full migration.
