How We Migrated Partipost's 900+ Articles to Webflow Without Losing Their Rankings

When Partipost needed to leave WordPress behind, the real challenge wasn't the redesign, it was safely relocating more than 900 CMS articles without losing the search rankings they had already earned. My team of three exported every article, mapped each one into Webflow's CMS by hand, and worked through Partipost's inconsistent old URL structure, some posts lived at /blog/article-slug, others had already dropped to just /article-slug, one redirect at a time. The whole mapping, correction, and review process took about a week. Rankings held, aside from the small dip you'd expect from any migration, and their marketing team hasn't needed a developer to publish a blog post since.

Why This Migration Was Higher-Stakes Than a Typical Redesign

The risk here wasn't the visual redesign. It was volume. Partipost had built up a genuinely large content library on WordPress, and every single one of those articles needed to land safely on Webflow's CMS with its ranking intact.

Most of the redesigns people picture when they hear the word are five, ten, maybe twenty pages. Partipost's blog alone ran past 900 published pieces, each one indexed by Google, some ranking well, some carrying backlinks from their own PR and partner activity. A small brochure site can survive a slightly imperfect migration because there's so little to get wrong. A library that size has 900 different chances to get something wrong, a mistyped slug, a missing redirect, dropped metadata, and any one of them quietly costs the client traffic they'd already earned.

I've written before about the general framework for protecting rankings through a redesign in how to protect your SEO rankings after a website redesign, and that framework holds regardless of scale. But following a checklist for ten pages and following it for 900 are two very different exercises in discipline. Partipost's project is a genuinely useful example of what that discipline looks like when the volume is real.

There was also a regional dimension that raised the stakes further. Partipost operates as an influencer marketing platform across multiple South-East Asian markets, and their content library was doing real work in each of those markets individually, not just for one domain's overall authority. A migration that quietly dropped visibility in even one of those markets wouldn't just be a traffic dip on a chart. It would be a genuinely worse experience for the regional teams relying on that content to reach their own audiences.

The Actual Process: Exporting WordPress and Mapping It Onto Webflow

We exported Partipost's articles directly out of WordPress, then mapped each one onto a corresponding item in Webflow's CMS, checking that the destination URL matched the original wherever possible.

This project predates the AI tooling we use today, more on that later in how we use AI at ALF Design Group, so this was genuinely manual work: reviewing the export, matching it against Webflow's CMS structure, and confirming nothing had been dropped along the way. Our guide to Webflow CMS explains the collection structure we were mapping into, if you're new to how Webflow organises dynamic content, it's a useful primer before attempting something similar.

The /blog/ URL Problem Nobody Warns You About

The complication wasn't the volume alone, it was that Partipost's own WordPress site hadn't been consistent with its own URL structure.

Some articles lived at www.domainname.com/blog/article-slug. Others, for reasons lost to whatever CMS decision had been made years earlier, had already dropped the /blog/ segment entirely and sat directly at www.domainname.com/article-slug. That inconsistency meant we couldn't apply one blanket redirect rule across the whole library. Every article's actual live URL had to be checked, not assumed, before we could map a correct 301 redirect. We went through them one by one. Google's own guidance on site moves is clear that redirect accuracy matters more than redirect speed, and that's exactly where checking each URL individually earned its keep here.

This is also why we didn't rely on the CMS export alone to tell us what needed redirecting. An export tells you what content exists, not what URL it's actually living at right now on the public site. We crawled Partipost's live WordPress site directly to confirm the real, current URL for each article before mapping it, rather than trusting that the export's assumed structure matched reality. That extra step is what caught the /blog/ inconsistency in the first place.

The Team, the Timeline, and Where Mistakes Actually Happened

Three people ran this migration, and the entire mapping, correction, and review process took about a week.

That's a smaller team and a shorter timeline than most business owners probably picture for something this size, and it's worth being honest about why it worked. Webflow's own CMS import tooling maps content accurately in the large majority of cases, so most of the 900+ articles genuinely didn't need much manual correction. What did need attention were the edge cases.

A small team was actually the right call here, not a constraint we worked around. With three people, one person could review the export, another could verify the mapping against the live site, and the third could focus specifically on the flagged exceptions, without the coordination overhead that comes from spreading meticulous, detail-heavy work across a larger group. Fewer handoffs meant fewer chances for something to fall through the gap between two people who each assumed the other had checked it.

Where the Real Risk Was: Missing Categories and Tags

The articles that needed manual attention weren't the ones with unusual body content, they were the ones missing structured data like categories and tags in the original export.

A handful of older articles hadn't been consistently tagged in WordPress, which meant they didn't map cleanly into Webflow's CMS fields for category and tag. Those had to be reviewed and assigned by hand. It's a small detail, but it's the kind of thing that's easy to miss if you're only checking that content transferred and not checking that the metadata around it transferred too. A meticulous team keeps that kind of gap to a minimum, but it doesn't remove the need to actually check for it, and it's worth verifying with a crawl tool such as Screaming Frog once the migration is live, rather than assuming the export caught everything.

What Happened to Rankings After Launch

Rankings dipped slightly after launch, which is normal for any migration, but nothing close to the kind of loss a poorly executed move can cause.

A temporary dip happens because Google has to re-crawl and re-index the new site before it can confidently re-associate your content and authority with the new URLs, even when every redirect is correct. That's a different situation entirely from the kind of migration where redirects are missing or wrong, which is where the genuinely damaging drops happen, sometimes losing the majority of a site's organic traffic in the weeks after launch. Partipost's dip was the ordinary, expected kind, not the kind caused by a mistake.

I'll be straightforward here rather than quote a number I don't actually have on hand: I don't have the exact before-and-after ranking figures for this particular project pulled up. What I can point to is a smaller, more concrete signal that the redirect work held. When Partipost's team shares an old blog link on social media, ones that predate the migration by years, it resolves correctly. No 404. That sounds like a small thing, but it's exactly the kind of detail that quietly breaks on a rushed migration, and it's a genuine, ongoing proof point that the URL mapping was done properly rather than just done fast.

What This Migration Actually Changed for Partipost's Team

The biggest change wasn't visual, it was operational: Partipost's marketing team stopped waiting on developers to update their own website.

On WordPress, even routine updates, a new landing page, a blog post, a campaign page, ran through a developer queue. That's slow by nature, and it's expensive in a different way too: marketing moves at the speed of the market, and a developer queue doesn't. Since moving to Webflow, their team publishes and updates content independently, across the multiple South-East Asian markets they operate in. You can see the fuller results snapshot, including their PageSpeed scores and CSAT rating, on their Partipost case study page. Honestly, the clearest sign the migration is working is the quietest one. I don't hear from Partipost's team with problems. Mostly it's just the occasional "hi, how are you", which, for a project this size, is about the best outcome you can ask for.

How I'd Approach This Same Migration Today

If I were running this exact migration now, I'd still export and map by hand at the core of it, but I'd use Claude to handle the mapping and rectification before anything gets uploaded.

The discipline hasn't changed, every URL still needs checking, every redirect still needs verifying. What's changed is how fast the checking part can happen. My current approach would be to export Webflow's CMS structure after configuring it to match the WordPress article fields, run the mapping and correction pass through Claude, and once that's rectified, upload the finished CSV straight into Webflow in one go, rather than entering items individually.

The specific problems we hit by hand on Partipost, the inconsistent /blog/ prefix and the articles missing categories or tags, are exactly the kind of pattern an AI pass catches quickly across hundreds of rows, rather than requiring someone to notice them article by article. That doesn't remove the need for a human to review the final mapping before it goes live. It just means the first pass surfaces the exceptions for you instead of you having to go hunting for them.

Frequently Asked Questions

Do you need to migrate every WordPress plugin's function when moving to Webflow?

Not necessarily, and trying to replicate every plugin one for one is usually the wrong goal. Most WordPress plugins exist to patch a gap that Webflow already handles natively, forms, SEO fields, image optimisation, so the right question isn't "how do we recreate this plugin" but "does Webflow already do this out of the box." For genuinely custom functionality, a Webflow-vetted integration or a code embed usually covers it. Start by listing what each plugin actually does for the business, not just that it exists, before deciding what needs a replacement.

What do you do when there's no clean equivalent page on the new site?

This comes up on almost every migration of this size. Some old pages genuinely don't have a matching page on the new site, whether because content was retired or consolidated elsewhere. In that case, redirect to the closest genuinely relevant page rather than the homepage by default, a homepage redirect signals to Google that the content simply disappeared, while a relevant redirect preserves at least some of the topical relevance and authority. If nothing relevant exists at all, letting the page 404 is sometimes the more honest option than forcing an irrelevant redirect.

Is 900+ URLs considered a large migration, or is this fairly typical?

It's on the larger end for a content-driven business site. Most SME migrations we handle sit well under that number. What made Partipost's project useful as an example isn't just the count, it's that the same discipline that works for a ten-page site, audit first, map every URL, redirect deliberately, scales up to 900 without needing a fundamentally different approach. The volume changes how long it takes, not what the process actually is.

Conclusion

If you're weighing a similar move and the size of your own content library is what's making you hesitate, the volume alone shouldn't be the blocker. What matters more is whether you're willing to do the unglamorous work first: document every URL, check your own site for the kind of structural inconsistency that caught us out with Partipost, and resist the urge to start building before that map is finished.

A few concrete places to start: pull a full export of your current site's URLs before you do anything else, check for URL structure inconsistencies within your own site rather than assuming uniformity, and if you're doing this today rather than a few years ago, use the AI tools available now to speed up the mapping and verification pass rather than doing it entirely by hand.

If you're facing a migration with real content volume behind it and want a second pair of eyes on the plan before you start building, our Webflow migration team is happy to talk it through with you.

{{build-better-experience="/directory"}}