Migrate CMS content with the Webflow MCP

We have a blog but it’s on another platform, and now we want to move into Webflow. The most straightforward thing to do is to copy everything over field for field. But what if the old structure was limited? We’d just be bringing those same limits with us. Or we build the blog we actually need.

So in this lesson, we’ll take a different approach. We’ll do all of this with the Webflow MCP and our agent, Claude. First, we'll plan the CMS we actually want. Then we'll compare Claude's proposed structure against what we actually need. Once it's approved, we'll build it, then review the result in Webflow. After that, we'll map our old content into the new structure, including what Claude can fill in for us. And finally, we'll test the migration with a small batch.

By the end, our blog content will be fully migrated into Collections with all the fields our site and our users need.

Let’s start with the plan.

We’re working with an export from a WordPress-style blog. Each post has a slug and a Rich Text body. That’s it. Yours might also have headlines, summaries, record IDs, or any other data that came with your previous site, but the overall process is the same.

And migrations are also a chance to improve your structure. For example, add fields or Collections for authors, categories, and metadata, giving search and answer engines more context about the content.

With MCP, we could easily import our two fields as-is, but before we move anything, we want to figure out what the blog needs behind the scenes to work well on our new site.

We’ll tell Claude that we need a Blog Collection and ask it to recommend the full structure, including any other Collections and the relationships between them. We’ll also ask it to look for anything the export might be missing, including fields that could help with user experience, and SEO and AEO.

And before it builds anything, we’ll have it explain its choices, flag any open questions, show us a plan, and wait for our approval. Let’s send it.

Alright. It’s ready. Let’s take a look at it and compare it.

Claude is recommending a Blog Posts Collection, along with Categories and Authors, with each Blog Post referencing both. It’s also suggesting fields the export doesn’t include, like a meta description and last-updated date. Depending on the site, it might also suggest something like a short summary or an Open Graph image for social links.

Claude can recommend the structure, but we still need to make human, site-specific decisions, like whether there are enough categories for a separate Collection versus a field in the Blog Collection. Or whether reusable Author items also make sense as their own Collection.

In our case, both do. We want category landing pages and reusable author information on different blogs, so the plan looks right.

That’s the plan. Let’s build it.

We’ll approve it and ask Claude to build the structure on our site through Webflow MCP.

That’s building it. Let’s go review the result in Webflow.

Here we have Blog Posts, Categories, and Authors. The Blog Posts Collection has a place for the content we already have and the fields we still need to fill, and the reference fields are connected the way we approved.

We should still check the details ourselves one more time. Are the field names clear? Are the right fields required? Did Claude add anything the team doesn’t really need?

If something looks off, we can fix it now, before we start bringing in content.

Ok, the new setup is ready. Let's map the old content into it.

We’ll give Claude the export and ask it to compare what we have with the CMS structure we just built. But again, we don’t want it creating anything yet.

The slug can move directly into the slug field unless the team has planned improvements for SEO or needs to think about a redirect plan. The post body can move into the Rich Text post body field.

But one thing to know first: how the body text is formatted in your source export affects how it’ll be formatted in Webflow. Ours is already simple, previously reviewed HTML, so it should come over cleanly. If yours is plain text or has more complex or unreviewed HTML, we recommend working with your agent first.

For our categories, we’ll give Claude an approved list and ask it to suggest the best match for each post. For the meta description, it can write a draft based on the existing content.

For authors, Claude should flag the author field and wait for us to give it an author mapping or a default author.

The same goes for images. Ours are stored on a public URL, but the export doesn't include those URLs, so once we hand that over to Claude, they'll come along fine.

However, if your files are stored locally, like mine, Claude can't access them automatically. Upload the exported files to Webflow's Assets panel first. Once they're there, each image gets a Webflow-hosted URL you can drop into the CMS item.

So now we have three kinds of content to sort through. Some fields can move over directly, like our slug and body. Some can be figured out from what’s already there, like our categories and meta description. And some still need information from the team, like our authors and images. And we’ll send it.

Now that it's all mapped out, let's test it.

And we’ll start with a batch of three blog posts to work through all of this, and ask for the migration plan and how things will map first.

Ok, here’s Claude’s plan.

This time, we’re checking the choices Claude made with the content.

Did Claude keep the original slug and body? Did it format our Rich Text correctly? Does the suggested category fit? Does the meta description match the post? And did it flag anything it couldn’t work out from the source? Did it? No, that's it.

Once everything looks right and we give it anything it needs — this could take a few tries — we’ll approve the plan and ask Claude to create the posts as drafts.

Back in Webflow. The new items are ready, so let’s open one of them.

And here we have all of our approved parts: the original slug and Rich Text body, the category, the author, and all our other new fields in the structure we planned.

And because the post is still a draft, the team can review everything in Webflow before it’s ready to publish.

And that’s why we’re starting with a small batch. It gives us a chance to catch things like missing authors, image handling, or inconsistent formatting while there are only a few items to fix.

Once the test looks right, we can use the same process for the rest of the content in manageable batches, with the same review steps along the way.

And if the team expects to use this workflow again, it could be worth turning it into a skill. That skill could keep track of the approved field mapping, category rules, what to do when information is missing, and what Claude should check before creating each batch.

So. We didn't just move the content from one system to another. We moved it into a structure the team and your AI agent can work with, and one that performs better on your site.

That’s migrating CMS content with MCP, in Webflow.

‍