Webflow Exporter logo
ResourcesContact
All resources

Webflow Migration Redirects: The Checklist That Saves Your SEO

The single biggest SEO regression after a Webflow migration isn't the export, the host, or the framework — it's broken redirects. URLs change shape in subtle ways during a move, Google's indexed version 404s, rankings dip for a few weeks while it sorts itself out. Most of this is preventable with about an hour of careful work before flipping DNS.

This post is the exact checklist, with per-host syntax for the four hosts an exported Webflow site usually lands on.

What actually changes during a Webflow migration

It's usually not what people expect. Five shapes of change show up:

  1. Trailing slash convention. Webflow served /about; the new host serves /about/. Or vice versa. Same page, but Google sees two URLs.
  2. CMS template path changes. Webflow uses /blog/[slug]; the new framework might render it as /posts/[slug]. Or you decided to flatten — /blog-posts/[slug] → /blog/[slug].
  3. Locale prefix. Webflow Localization put English at /en/; the new site puts English at /.
  4. Old marketing URLs you forgot about. /2023-launch, /black-friday-2024, the press release that got 400 backlinks once.
  5. The Webflow staging URL. Sometimes indexed accidentally (forgot to noindex it). Redirect it to production.

Each of these breaks at least one external link or at least one Google-indexed URL. Each is fixable with a redirect rule. The checklist below catches all five.

The pre-migration audit

Before any redirect work, you need the list of URLs that exist on the Webflow site today. Three sources, in order of completeness:

  1. Google Search Console > Pages report. Export the “Indexed” list. These are the URLs Google currently knows about — the ones you absolutely must keep working.
  2. The site's sitemap. Pull yourdomain.com/sitemap.xml. Webflow generates this automatically and it covers everything published.
  3. A crawl with Screaming Frog or similar. Catches pages that aren't in the sitemap because they're linked but not in nav, or because Webflow's sitemap is misconfigured.

The union of these three is your “must keep working” URL list. Save it as a CSV; you'll use it to verify after deploy.

The five rule shapes you usually need

In order of how often each comes up:

1. Trailing-slash canonicalization

Source:      /about/
Destination: /about
Status:      308 (permanent, preserves method)

You're saying “both URLs are the same; here's the canonical one.” Pick the form Webflow was serving and make the other 308 to it.

2. CMS path renames

Source:      /blog-posts/the-case-against-cms
Destination: /blog/the-case-against-cms
Status:      301 (permanent)

Often you have one rule per template, with a wildcard:

Source:      /blog-posts/:slug
Destination: /blog/:slug
Status:      301

3. Locale-prefix simplification

Source:      /en/about
Destination: /about
Status:      301

Same pattern for every page. Be careful — if you have a /en/about and a /de/about, you only collapse the default locale.

4. Specific legacy URLs

Source:      /2024-product-launch
Destination: /pricing
Status:      301

Hand-written, one per URL. From the GSC export, pick the URLs that still get any traffic at all and map them to the closest live page on the new site.

5. Webflow staging URL

Source:      https://yoursite.webflow.io/(.*)
Destination: https://yourdomain.com/$1
Status:      301

This one's per-host: you need access to the Webflow staging URL to set the redirect, which usually means a custom 301 rule on the Webflow side before cancelling the Webflow Site plan, OR an explicit robots.txt Disallow on the staging subdomain to discourage future crawl.

Syntax per host

Same five rules, four different syntaxes.

Vercel — vercel.json

{
  "trailingSlash": false,
  "redirects": [
    { "source": "/blog-posts/:slug", "destination": "/blog/:slug", "permanent": true },
    { "source": "/en/:path*",        "destination": "/:path*",     "permanent": true },
    { "source": "/2024-product-launch", "destination": "/pricing", "permanent": true }
  ]
}

trailingSlash: false handles the first rule shape automatically. The rest go in the redirects array. The Next.js docs also accept redirects in next.config.js for a framework rebuild — same semantics.

Netlify — _redirects file at the root

/about/                     /about                     301
/blog-posts/*               /blog/:splat               301
/en/*                       /:splat                    301
/2024-product-launch        /pricing                   301

One rule per line, source/destination/status. :splat is Netlify's wildcard syntax. Drop this file at the root of the deploy folder.

Cloudflare Pages — _redirects file at the root

/about/                     /about                     301
/blog-posts/*               /blog/:splat               301
/en/*                       /:splat                    301
/2024-product-launch        /pricing                   301

Same syntax as Netlify — Cloudflare Pages adopted Netlify's _redirects format for compatibility.

GitHub Pages — meta refresh fallback

GitHub Pages doesn't support server-side redirects. The fallback is per-page <meta http-equiv="refresh">, which Google treats as a weaker signal than a 301. If you have many redirects and SEO matters, this is the cue to host somewhere that supports real redirects.

If GitHub Pages is the right host for other reasons (it is, sometimes — see host on GitHub Pages), consider putting the redirect-heavy section behind Cloudflare with Page Rules for redirects, and using GitHub Pages just for serving.

The four common mistakes

We've seen migrations regress on the same four mistakes:

1. Forgetting the www vs apex redirect

www.yourdomain.com and yourdomain.com are different URLs to Google. Pick one as canonical, 301 the other. Every host has a different way to do this; almost everyone forgets it on first deploy.

2. Redirect chains

/old-url → /intermediate-url → /new-url. Google follows chains but loses signal at each hop. Collapse them: the source should redirect directly to the final destination.

3. Using 302 instead of 301

302 = “temporary,” Google doesn't pass full ranking signal. 301 = “permanent,” full signal. For a migration, you want 301 (or 308, which is 301 with method preservation). Some default redirect configurations use 302 — check explicitly.

4. Not testing before flipping DNS

The redirects only work after DNS points at the new host, so “test in production” feels unavoidable. It isn't: most hosts let you preview the deploy at a .netlify.app or .vercel.app URL. Test the rules there first, against the deploy preview, then flip DNS.

After deploy — verification in three steps

The moment DNS is propagated, verify before walking away:

  1. Walk the GSC URL list with curl. A short script that hits every old URL and checks the response code:

    while IFS= read -r url; do
  code=$(curl -s -o /dev/null -w "%{http_code}" "https://yourdomain.com$url")
  echo "$code $url"
done < old-urls.txt | grep -v "^200\|^301\|^308"

    Anything that comes back 404 needs a redirect added.

  2. Request indexing in GSC. Submit the new sitemap. Use “Inspect URL” on the three most-trafficked pages and request indexing.

  3. Watch impressions in GSC for two weeks. Expect a small dip the first week, recovery the second. If impressions stay down at three weeks, walk the URL list again — usually a redirect rule got missed.

The shortest possible checklist

  1. Export GSC indexed pages, sitemap, and Screaming Frog crawl → URL list.
  2. Pick trailing-slash convention; configure host accordingly.
  3. Map any path renames as wildcard redirects.
  4. Hand-add 301s for high-traffic legacy URLs.
  5. Set www vs apex canonical.
  6. Test against the deploy preview, not production.
  7. Flip DNS.
  8. Verify with curl, submit sitemap to GSC, monitor for two weeks.

About 90 minutes of work, end to end, for a typical marketing site. Skipping any of these steps is the most common reason post-Webflow sites report ranking drops. Doing them is the reason most don't.

For the broader host comparison, see where to host an exported Webflow site. For the export itself, Webflow Export produces the static files and a fresh sitemap that you'll submit to GSC after deploy.