Record content and working behavior before rebuilding
The starting point for migration scope is an inventory of the current site. List published posts and pages, custom post types, categories, tags, downloadable documents, images and important entry URLs. A sitemap may not show everything; compare it with media, older campaign links and dashboard records. Reviewing only high-traffic pages can miss a document that remains essential to operations.
Give each item a retain, merge, update or remove decision. The content owner makes this decision; a developer should not silently delete an ambiguous record. Removal may be justified by outdated information, duplication or a discontinued offer. Retain existing HTML, metadata and behavior examples for comparison. Establish whether a date field means original publication or revision; migration day should not reset the history of every article.
Prove CMS field mapping with a small pilot
In Webflow CMS development, converting each post type into a similarly named Collection is insufficient. Map the types and meanings of titles, slugs, summaries, bodies, authors, categories, dates and references. Specify whether relationships are multiple, how empty fields behave and what an editor sees when creating a record. WordPress shortcodes should not remain as unexplained visible text in the new body.
Webflow's official migration guidance describes converting the WordPress XML export into CSV and mapping Collection fields. Start with a small pilot. Compare Turkish characters, internal links, rich text, image addresses and date formats. The imported record count cannot be the only acceptance measure: an article can exist while its body is missing.
| Field | Pilot evidence | Decision if incomplete |
|---|---|---|
| Body and shortcodes | Readable old/new content comparison | Rebuild the component or document its removal |
| Reference field | Working category and author relationships | Map target records before resolving links |
| Images and files | Accessible media URL and usage rights | Move to a new destination; record old-host dependency |
FROM READING TO A NEXT STEP
Review your migration scope
Share your existing URL, content and feature inventory.
Inventory plugins by the functions they provide
During content-platform selection, describe what each plugin does: search, membership, filtering, translation, form delivery or administration. A similar-looking Webflow screen does not necessarily supply the same behavior behind it. WooCommerce orders, customer accounts and payment processes are not blog content transferred by CSV; they may require a separate system and data project.
For each function, choose a native feature, external service, custom implementation or explicit exclusion. Include external-service costs, access ownership, data retention and failure behavior in the scope. For example, a filter's appearance might remain while query behavior needs rebuilding. If a critical replacement is uncertain, validate it before committing to a full move. Keeping the existing system must remain a possible outcome of that decision.
Transfers as content
Posts, pages and compatible fields move through explicit mapping. Validate files, references and body accuracy with examples, then compare totals with the source inventory.
Rebuilt as behavior
Form routing, search, membership and integrations need separate acceptance criteria. A matching screen without a working implementation does not satisfy the check.
Test URL replacements with their search signals
For the technical SEO review, build a table containing old URL, new URL, decision, HTTP result and final destination. Preserve useful addresses where possible. Send a changed address to its closest relevant replacement instead of collecting unrelated pages at the home page. Test nested paths and conflicting examples before applying a broad redirect rule.
Google's site-move guidance covers canonical values, language annotations and updating internal links on new URLs. Also locate images, downloadable files and body links that still depend on the old hostname. Make sure preview robots or noindex preferences do not accidentally follow into production. Prepare Search Console monitoring, but do not describe migration checks as a guarantee that search rankings will remain unchanged.
Accept forms and editor workflows again
For integration acceptance, compare the fields of the old form with the new form. Privacy information, required fields, error states, notification destinations and CRM mappings are functional scope. Do not send an unauthorized live enquiry; use synthetic records in an owner-approved test environment. If end-to-end testing is not authorized, leave the receiving-system check pending.
Define editor permissions by tasks instead of copying WordPress role names. Who writes, reviews and publishes content, and who removes access? Ask an editor to add a post, replace an incorrect image and open a preview. For multilingual content, demonstrate what happens when a translation is incomplete. At the end of training, unresolved tasks need a responsible owner and a date for another supported attempt.
Document the content freeze, recovery and follow-up
In the cutover plan, separate the final content transfer from the domain change. If new WordPress posts are still being created, the initial export is no longer the final version. Assign ownership of the content freeze, last changes and record-count checks. Preserve a working backup and necessary license access as well as technical access to the previous system.
Agree on stop conditions and who can authorize recovery. State the response when a critical form, important URL or CMS template fails. After the domain switch, retest the main visitor tasks, redirects and media addresses. Schedule a first-day check and the following observation date. Close findings with source evidence, a destination URL, an owner and a successful retest. Missing information must remain visible instead of becoming silent acceptance.
Get the checklist and discuss your scope
Your email and phone are used for this request. This does not subscribe you to a newsletter.
BEFORE YOU DECIDE
Frequently asked questions
Can we upload a WordPress backup directly to Webflow?
No. A content export and a full site backup serve different purposes. Compatible data moves through field mapping; themes, plugin code and working features need separate evaluation in the new system. Do not accept the whole transfer before the pilot examples are correct.
Do unchanged URLs still need SEO checks?
Yes. The HTML, metadata, internal links, indexing preferences and content can change even when the address stays the same. Compare old and new examples. If the domain remains unchanged, assess the actual platform and page changes rather than treating it as a domain move.
Should every category and tag migrate?
Not automatically. Retain useful archives and relationships, and document decisions for duplicate or empty archives. Record the status and relevant alternative for removed URLs separately. Reducing the number of records is not, by itself, a sufficient reason to remove content.
When should content be frozen?
Define an interval covering the verified final transfer and domain switch. Depending on editorial needs, choose a short publishing pause or a transfer of the last changes. Record new content and its owner so posts added after the first export cannot disappear unnoticed.
Should every WordPress site move to Webflow?
No. If accounts, membership, commerce or complex editorial features matter, test their replacements and operating burden first. When a migration removes necessary behavior while solving a design problem, improving the existing platform may be the better decision.
LET’S DEFINE THE SCOPE
Review your migration scope
Share your existing URL, content and feature inventory.
Discuss the scope