Redirects and Site Migration

This content was generated with the assistance of AI and should be verified against the official Webflow documentation before being relied on in production.

This sub-section’s Webflow bibliography lists the reference material consulted while preparing these pages.

This page describes Webflow as it was on 2026-10-28, the date on which its facts were checked against the official documentation. Redirects are a hosting feature, so the rules below are properties of the Webflow platform and carry no version number; the Product Changes and Deprecations page tracks later changes. Plans are named by tier only: the Data API endpoints for redirects need an Enterprise Workspace. See Plans, Workspaces, Seats and Roles for what each tier unlocks.

The running example is Fernbrook Gardens. Before the new Webflow site went live, the garden had a small site on an old platform whose addresses looked like /plants/rose.html, /whats-on/2019/spring-fair and /blog/2021/05/pruning. Visitors have bookmarked those addresses, search engines have indexed them and other sites link to them. The new site uses /plants/rose, /events/spring-fair and /garden-journal/pruning. This page shows how to map the old to the new so that nothing breaks on the day of the cut-over.

What a redirect does

A redirect is a response from the web server that tells the browser, and the search-engine crawler, that a page has moved and where it is now. Webflow hosting answers a request for an old path with the status code 301 Moved Permanently and a Location header holding the new address. The browser then requests the new address automatically.

The choice of 301 matters. A 301 tells search engines that the move is permanent, so they replace the old address with the new one in their index and pass the ranking of the old page on to the new one. A temporary redirect (302) tells them to keep the old address. Webflow’s redirect table creates 301 redirects, which is the right tool for a migration or a renamed page. See SEO and AEO for the other signals (canonical URLs, sitemap) that work together with redirects.

Redirects run on the hosting layer, before any page is looked up. This has three consequences.

  • A redirect applies to a path that no longer exists on the site. If a page with the old path still exists, the page is served and the redirect is not used, so remove or rename the old page first.

  • Redirects take effect only when the site is published. Saving the table does nothing until the next publish, as described in Publishing and Scheduling.

  • Redirects work on the live domains of the site. They do not run inside the Designer, so test them on the published site, and use a private window because browsers cache 301 responses aggressively.

Where redirects live

Redirects are a site-level setting. In the Dashboard, open the site’s settings and go to Publishing, where the 301 redirects section holds the table. Webflow has moved its settings screens several times, and some third-party guides still describe an older Hosting tab, so treat the Help Center article in the references as the authority for the current location.

Each row of the table has two fields.

Field Meaning

Old path

The path that visitors request, written from the root of the site and without the domain, for example /plants/rose.html.

Redirect to path

The destination. It is either a path on the same site, for example /plants/rose, or a full URL with the protocol when the target is on another domain, for example https://shop.fernbrook.example/seeds.

Both fields start with a slash when they are paths on the site. Query strings are not part of the old path, so a rule for /plants does not match /plants?zone=7; the visitor’s query string is a separate matter that wildcard rules do not carry over automatically.

Order and precedence

Webflow evaluates the redirects in the order in which they were added to the site: older rules first, newer rules after. The first rule that matches wins. The practical rule is therefore to add specific rules before broad wildcard rules. Webflow’s own SEO guidance also notes that the wildcard redirects do not support regular expressions or a user-controlled order of operations, so a table is easiest to keep predictable when no two rules can match the same path.

For Fernbrook Gardens the table is designed so that exact rules come first and one wildcard comes last.

Old path Redirect to path Kind

/plants/rose.html

/plants/rose

Single

/whats-on/2019/spring-fair

/events/spring-fair

Single (the name changed)

/plants/(.*).html

/plants/%1

Wildcard with a capture group

/blog/(.*)

/garden-journal/%1

Wildcard with a capture group

The (.*) group in the third row matches any text, and %1 in the destination inserts what the first group matched. A request for /plants/lavender.html therefore goes to /plants/lavender, which is the Plants collection item with that slug. Because the exact rule for the rose page is older than the wildcard, it wins for that one path.

The /blog/(.*) rule shows the limit of wildcards. The old addresses had a year and month in the path (/blog/2021/05/pruning), so the captured text would be 2021/05/pruning and the destination /garden-journal/2021/05/pruning does not exist. A rule that cannot reproduce the new slug must be written as one exact row per post, or as a wildcard that targets a landing page, such as /garden-journal. Decide this for every group of old addresses in the mapping step below.

Wildcards and capture groups

A wildcard rule lets one row stand for many pages. Webflow’s syntax is its own and is not regular expressions.

  • (.*) in the old path is a capture group. It matches any sequence of characters, including slashes.

  • %1 in the redirect target is replaced with the text matched by the first capture group, %2 by the second, and so on, when the old path has several groups.

  • A group can sit anywhere in the path, so /plants/(.*).html captures only what lies between the folder and the extension.

Because % introduces the placeholders, other special characters in a path have to be escaped with a leading %. The Help Center lists the characters that need it in the old path and in wildcard rules: the percent sign itself and the characters -, &, *, (, ), =, _, ? and the plus sign. In practice the hyphen is the character that bites most often, because almost every slug contains one. An old path such as /business-blog/ is written /business%-blog/. The rule that "does not work" on a forum is, most of the time, a rule with an unescaped hyphen, and the fix is to add the percent sign.

Keep the number of rules small. Webflow has no hard limit on the number of redirects, but its guidance is to stay within about 1,000 rules and to prefer wildcards over long lists of single rows, because a smaller table is faster to evaluate and easier to maintain.

Managing many redirects with CSV

Typing hundreds of rows into the table is impractical, so Webflow can import and export the table as a CSV file from the same screen.

  • Export downloads the current table.

  • Import uploads a CSV file with two columns: the old paths in the first and the new paths in the second, one redirect per row. The file may be up to 16 MB.

  • Import replaces the table. The upload overwrites every existing redirect; it does not append. To add rows to an existing table, export first, add the new rows to the exported file and import the combined file.

  • If any row is invalid, the whole import fails and Webflow sends an email explaining how to correct the file.

  • After a successful import, publish the site to put the new table live.

The Fernbrook migration file looks like this.

/plants/rose.html,/plants/rose
/whats-on/2019/spring-fair,/events/spring-fair
/whats-on/2020/autumn-fair,/events/autumn-fair
/plants/(.*).html,/plants/%1
/blog/2021/05/pruning,/garden-journal/pruning
/visit-us,/visit
/volunteer-signup,https://fernbrook.example/volunteers

Source: https://help.webflow.com/hc/en-us/articles/33961211526291

The specific blog posts appear above the wildcard rules in the file because the order of the file is the order of the table. Paths that contain a hyphen in the old column would be escaped with %- in the same way as in the Designer.

A spreadsheet is the natural tool for building the file: one column of old addresses exported from the old platform or a crawl of it, one column of new addresses, and a check that every old address is unique. Build the file from the mapping described below rather than editing the table by hand.

Redirects through the Data API

For sites in an Enterprise Workspace the Data API can manage the same table. The endpoints sit under /v2/sites/{site_id}/redirects. Listing needs the sites:read scope; creating, updating and deleting need sites:write. A create request takes the old path as fromUrl and the destination as toUrl.

# Create one redirect for the Fernbrook Gardens site (placeholders, not real values)
curl --request POST \
  --url "https://api.webflow.com/v2/sites/SITE_ID/redirects" \
  --header "Authorization: Bearer YOUR_ACCESS_TOKEN" \
  --header "Content-Type: application/json" \
  --data '{
    "fromUrl": "/plants/rose.html",
    "toUrl": "/plants/rose"
  }'

Source: https://developers.webflow.com/data/reference/enterprise/site-configuration/301-redirects/create

Other plans manage redirects in the Designer and Dashboard only. The authentication and scope model is covered in Data API Authentication and Scopes, and the site-level endpoints in Data API: Sites, Pages and Components.

Migrating a site from another platform

A migration has two halves, content and addresses, and the second is where rankings are won or lost. Webflow has no automatic importer for other platforms, so the work is a sequence of steps that you control.

flowchart LR A[Crawl the old site] --> B[Map old URLs to new URLs] B --> C[Move the content] C --> D[Build and review on the staging address] D --> E[Load redirects and publish] E --> F[Point the domain at Webflow] F --> G[Monitor and fix]

1. Inventory the old site

List every address that matters: pages, blog posts, images and documents that others link to. Sources are the old platform’s own export, its sitemap, a crawler, the analytics report of the most visited pages and the list of pages that receive links from other sites. A page with traffic or links needs a redirect; a page with neither can be dropped.

2. Map old URLs to new URLs

Make a table with an old address, a new address and a note. Rules that make later work easier follow.

  • Prefer a one-to-one mapping. A visitor who followed a link to the old rose page expects the rose page, not the home page.

  • Redirect to the closest equivalent when a page has been merged or removed, and to a parent page when there is none. Do not redirect everything to the home page: search engines treat many such redirects as soft errors.

  • Keep a slug the same wherever the new structure allows it. A rule that is the identity does not need to exist.

  • Mark groups that can be covered by a wildcard, and every group whose new slug cannot be derived from the old one.

  • Check redirect chains. If /a goes to /b and /b goes to /c, change the first rule to go to /c.

  • Decide the locale paths up front. Fernbrook’s Spanish and German versions use /es and /de prefixes, so the mapping covers them too; see Localization.

3. Move the content

Structured content moves best as data. Export the old platform’s posts, products or events as CSV or JSON, reshape the columns to match a Webflow collection and import them. Two routes exist.

  • The CMS CSV import, described in CSV Import and Export, suits one-off moves of a few thousand items. Reference fields need the target item’s slug or name and therefore need the referenced collection to be imported first.

  • The Data API, shown in Data API: CMS, suits a repeatable script. This is how the fernbrook-sync script of this sub-section imports the nursery inventory, and the same approach works for migrated content.

Images are best uploaded to the Assets panel or through the API and referenced from the items; see Images and Assets. Set the slug of every migrated item on purpose, because the slug becomes the new address and the redirect target.

4. Review before the cut-over

Build and check the site on its webflow.io staging address. Compare titles and descriptions with the old site, fix headings, check forms and confirm that every new address in the mapping table opens. Keep the site hidden from search engines while this is going on; the Webflow staging address is not meant to be indexed, and the SEO and AEO page lists the settings that control this.

5. Load the redirects, publish and switch the domain

Import the CSV or enter the rules, then publish. The order below keeps the downtime to the time DNS needs to propagate.

  1. Add the custom domain to the Webflow site and publish with the redirect table loaded.

  2. Lower the TTL of the DNS records a day before the change, if the provider lets you.

  3. Change the DNS records to the values Webflow shows, as described in Domains, Hosting and Publishing Options.

  4. Wait for the SSL certificate to be provisioned.

  5. Test a sample of old addresses on the real domain in a private window.

Redirects take effect for a domain only once it serves the Webflow site, so run the final test of old addresses on the real domain after the DNS change, and keep the old platform available until it passes.

6. Monitor

After the cut-over, watch the Search Console coverage report for not-found errors and the analytics for landing pages that return a 404. Each unmapped address that still receives traffic is a missing redirect: add it to the table, export, edit and re-import, or add the row in the Designer. Keep the redirect table in place for as long as the old addresses have links, which in practice means indefinitely.

Moving content between Webflow sites

Redirects are also needed when a Webflow site is restructured: a renamed folder, a collection with a new slug or merged pages. The rule is the same as for a migration: change the slug and add a rule from the old path to the new one in the same publish. Renaming a page’s slug does not create a redirect by itself.

When a site moves to a different Webflow site, such as a redesign built on a new site, the new site’s redirect table is independent of the old one and has to be built again. Exporting the old table to CSV and importing it into the new site is the shortest way, as long as the target table is empty or merged first, since import replaces what is there.

Transferring sites and Workspaces

Webflow separates the ownership of a site from the ownership of the Workspace, and the two have different transfer paths.

  • A site belongs to the Workspace it lives in. A client does not automatically gain the right to transfer or duplicate a site built in a freelancer’s or agency’s Workspace; this has to be agreed explicitly.

  • Transferring a site moves it to another Workspace from the Dashboard, through the transfer option that sends the site To a Workspace. The transfer carries the Designer content and settings such as pages, assets, collections, Ecommerce data and logic flows. A site that has an active Site plan, or that is showcased in Made in Webflow, cannot be transferred until that has been resolved.

  • Transferring a Workspace is done by the Workspace owner only. The new owner needs a Webflow account, the owner confirms the request by email, and the Workspace needs enough seats for the new arrangement.

  • If the owner has left the organisation, Webflow has a separate support route for recovering ownership.

For Fernbrook Gardens the agency that built the site works in its own Workspace. At hand-over the agency transfers the site to the garden’s Workspace, the garden buys or moves the site plan and the domain, and the agency’s people keep access through guest seats if the agreement says so. Hosting, domain connections and redirects belong to the site, so they go with it; confirm after the transfer that the domain still points at the site and republish. Roles and seats are described in Plans, Workspaces, Seats and Roles, and the code export route for leaving Webflow altogether in Code Export and Portability.

Pitfalls

  • Import replaces the table. An import that contains only new rows removes every existing one. Always export first.

  • Unescaped hyphens in old paths and wildcards are the commonest reason for a rule that does not match.

  • Old page still exists. A live page at the old path is served instead of redirecting; delete or rename it.

  • Chains and loops. Each extra hop slows the visitor and dilutes the signal; a rule that sends a path to itself produces a loop.

  • Redirecting everything to the home page loses the relevance of each old page.

  • Caching. A browser that has seen a 301 remembers it, so test in a private window or on another device.

  • Forgetting to publish. Redirects are part of the published site, not of the saved Designer state.

  • Query strings and fragments. Rules match paths; campaign parameters on the old addresses need separate thought.

  • Large tables. Past about 1,000 rows, prefer wildcards or restructure the new slugs so that fewer rules are needed.

References