What breaks in a WordPress to Webflow migration, and how do you redirect it?

Last updated: 28 October 2026

A WordPress to Webflow migration breaks the URLs that only WordPress serves: category, tag, author and date archives, paginated lists, feeds and the media folder. List every old URL, decide for each whether the Webflow site has an equivalent page, and redirect or retire the rest before launch. Then request each old URL on the new site to confirm the redirects land.

Related guides: the website migration testing checklist, finding broken pages after a migration, and the platform guides for moving into Shopify and Drupal to WordPress.

What changes in the URLs

These are WordPress’s default permalink shapes. The site owner may have changed any of them, so confirm each pattern against the old site’s sitemap and a crawl before you rely on this list.

• Posts and pages: /<slug>/ or /<year>/<month>/<slug>/, with a trailing slash. The plain form /?p=<id> is also in use on links shared years ago.
• Archives: /category/<slug>/, /tag/<slug>/, /author/<name>/ and date archives such as /<year>/<month>/.
• Pagination and feeds: /page/<n>/ on any listing, /feed/ for the site and a feed under each post or archive.
• Media: /wp-content/uploads/<year>/<month>/<file> on the old domain.

In Webflow, static pages sit at /<slug> and CMS collection items at /<collection>/<slug> by default, without a trailing slash, and the site owner chooses both the collection path and each slug. Media is served from the platform’s own file host, not from a path on your domain.

For each WordPress shape above, check whether your Webflow site has an equivalent page. If it has, redirect the old path to it. If it has none, redirect the old path to the closest replacement, or retire it on purpose with a 410.

Build the redirect map

1. Collect the old URLs. Take them from the old site’s sitemap.xml, the Sitemap: lines in its robots.txt and a crawl. Add the feed, archive and media URLs that receive traffic or inbound links; no sitemap lists the feed or the images. The website migration testing checklist covers this inventory.
2. Write the new path next to each old one. A post or page that keeps its slug usually differs only by the trailing slash and any date prefix, but it still needs the old path to reach the new one. Confirm this by requesting the old path on the new site, not by assuming it.
3. Decide each archive shape. Category, tag, author and date archives either map to a Webflow page that lists the same posts, or go to the closest replacement, or are retired. Do this once per shape, then once per URL.
4. Enter the redirects as permanent (301). Webflow offers a per-URL redirect list that maps one old path to one new path. Check whether your list accepts patterns before you rely on one for /page/<n>/ or the dated paths; if it does not, list each path.
5. Request every old URL on the new site. Read the final status of each and check that it lands on the matching page and not on the homepage. The guide finding broken pages after a migration shows how to read each result.
6. Repeat after launch, when DNS and production settings are in place.

What usually goes missing

• Category, tag, author and date archive pages, which the new site never had a page for.
• Feeds, which readers and other sites still request.
• Images and files that old posts and other sites link at /wp-content/uploads/.
• Paginated listings: /page/2/ and beyond.
• Query-string variants, such as tracking parameters on shared links.
• Trailing-slash and upper-case variants of paths that were linked inconsistently.

What DiffiCat automates

DiffiCat compares each page at the same path on both sites. Enter the site you are moving from as Site A and the site you are moving to as Site B. It requests each old URL on the new site and follows redirects hop by hop: a correct redirect passes “Exists”, a missing redirect fails it, and a redirect that lands on the wrong page fails “Content”, because the title and body text no longer match.

• The URL list. DiffiCat reads the old site’s sitemap.xml and the Sitemap: lines in its robots.txt, and falls back to a crawl of the homepage. You can also supply a sitemap URL.
• Three checks on every page. “Exists” compares the HTTP status of both versions. “Content” compares the title, H1, meta description, canonical, robots meta, hreflang and body text, with a 90% word-overlap threshold for the body. “Visual” compares screenshots pixel by pixel at 375 px, 768 px or 1440 px, or any width from 320 px to 2560 px.
• A report you can act on. Pages are listed worst first, and each failure names the site at fault, such as A: 200 → B: 404.

Building the redirect map stays yours: DiffiCat shows which old URLs fail and why, and you add the redirects.

What this does not catch

• Behaviour: forms, search, checkout, sign-up flows and other interactive features need their own functional tests.
• Speed and server load: a page can match exactly and still be slower.
• Pages nobody listed: if a URL is missing from the inventory, no tool checks it.

DiffiCat has its own limits. Both sites must resolve on the public internet: localhost, loopback and private-network addresses are refused, so deploy staging to a public URL (password protection is fine). Pages are rendered in headless Chromium only. Sign-in with a username and password is supported, but sign-ins that need a code (MFA), a CAPTCHA or single sign-on are not.

Run the check on your sites

Enter your old and new site in the try-it form, or open app.difficat.com and start the free trial: 500 captured pages once when signed in, 100 without signing in, with every check and viewport width and no card needed.