Why Redirects Matter When You Launch a New Site

When a nonprofit launches a new website — whether migrating from WordPress, Wix, Squarespace, or a previous Webflow build — the URL structure almost always changes. Pages that existed at one address move to a different address. Some pages are retired entirely. The homepage may stay the same but sub-pages often don't.

Every URL that changes without a redirect in place creates a broken link. That broken link has consequences in three directions.

For visitors. Anyone following an old link — from a grant application, a funder's website, an email newsletter, printed materials, a social media post — lands on a 404 error page. For a donor following a link to your annual report, or a grant officer trying to verify your charity registration details, that 404 is a credibility failure at exactly the wrong moment.

For search rankings. Search engines index pages by their URL. When a URL changes without a redirect, the search authority accumulated by the old URL — the backlinks pointing to it, the time it's been indexed, the click-through history — is not transferred to the new page. It evaporates. For a nonprofit that has built up organic search visibility over years, an unredirected migration can cause significant ranking drops that take months to recover.

For grant references and institutional records. Many nonprofits reference specific pages in grant applications, impact reports, and funder communications. Those references persist long after the document is submitted. A funder reviewing a multi-year grant renewal who finds a broken link where your impact page used to be is encountering an entirely avoidable problem.

301 redirects solve all three. A 301 redirect is a permanent instruction to browsers and search engines: the page at this old URL has moved permanently to this new URL. Follow it there. Transfer any search authority to the new address.

What a 301 Redirect Does — and What It Doesn't

A 301 tells browsers and search engines that a page has moved permanently. The browser follows the redirect automatically and loads the new page. The user typically doesn't notice — they see the new page without ever seeing the old URL or a 404.

For search engines, a 301 passes the majority of the link equity from the old URL to the new one. This isn't instantaneous — Google re-crawls pages on its own schedule — but over days and weeks, the new URL accumulates the authority the old one had built.

What a 301 doesn't do:

A redirect doesn't fix a content gap. If a page that previously existed — a programme description, a case study, a specific annual report — is not recreated on the new site, redirecting visitors to the homepage or a generic section page is better than a 404 but still a poor experience. Where possible, redirect old pages to genuinely equivalent new content rather than to the nearest approximation.

A redirect also doesn't recover rankings immediately. If a high-ranking page has its URL changed without a redirect and is then redirected weeks later, the gap period may have already caused ranking loss. Redirects set up before launch — before the old site goes offline — prevent this entirely. Redirects set up after the fact repair the damage but can't recover it instantly.

Before You Build the Redirect Map

The first step is an inventory of every URL on the existing site that needs a redirect. This is done before any design or development work begins on the new site — knowing what exists on the old site informs what needs to be recreated or redirected on the new one.

How to get a complete URL list:

Use Screaming Frog (screaming frog.co.uk) to crawl the existing site and export every URL it finds. Screaming Frog is the standard tool for this — it works like a search engine crawler, visiting every page and following every internal link. The free version crawls up to 500 URLs, which covers most nonprofit sites. Larger sites require the paid licence.

Run the crawl, export the results as a spreadsheet, and filter for HTML pages only — you don't need to redirect image files or scripts. The result is a complete list of every page URL on the existing site.

Screenshot placement: [Screenshot showing Screaming Frog with a crawl completed and the URL list exported, filtered to HTML pages only]

From this list, identify three categories:

Pages being recreated — content that will exist on the new site, potentially at a different URL. These need a direct 301 from old URL to new URL.

Pages being retired — content that won't exist on the new site. These should redirect to the most relevant equivalent page — a related programme page, the relevant section index, or in the last resort, the homepage.

Pages staying the same — if the new site preserves some URLs exactly (the homepage, for example, or a donations page at /donate), no redirect is needed for these. Confirm the URL is identical including any trailing slash conventions.

Document this in a spreadsheet with two columns: old URL and new URL. This is your redirect map. It becomes the source of truth for setting up redirects in Webflow and for testing them after launch. On every migration I work on, this spreadsheet is built before any Webflow work begins — it's the one document that prevents post-launch 404s from becoming a support emergency.

How to Set Up Redirects in Webflow

Webflow has a built-in redirect manager that handles 301 redirects without requiring any code. It's found in the site settings.

Navigating to the redirect manager:

1. In Webflow, open your site's settings
2. Navigate to the Hosting section
3. Look for 301 Redirects — it appears as a section within the hosting settings
4. This is where all redirects for the site are managed

Screenshot placement: [Screenshot showing Webflow's site settings with the Hosting section open and the 301 Redirects section visible]

Adding a redirect:

For each row in your redirect map:

1. Click Add Redirect or the plus icon
2. In the Old Path field, enter the old URL path — the part after the domain. For example, if the old URL was yourcharity.org.uk/about-us/our-team, enter /about-us/our-team
3. In the New Path field, enter the new URL path. For example /team
4. Save the redirect

Screenshot placement: [Screenshot showing the Webflow redirect manager with an old path and new path entered and saved]

Important conventions:

• Paths should start with a forward slash: /old-page not old-page
• Do not include the domain name in either field — paths only
• Trailing slashes matter. If your old site used /about-us/ (with trailing slash) and the new site uses /about-us (without), set the redirect accordingly. Webflow treats these as different URLs
• Redirects are case-sensitive in some configurations — if your old site had uppercase in URLs (/Annual-Report), include the redirect for the uppercase version even if the new URL is lowercase

Bulk Importing Redirects

If you have a large number of redirects — more than twenty or thirty — entering them one by one in Webflow's interface is slow. Webflow supports bulk CSV import for redirects.

Prepare a CSV file with two columns:

• Column A header: old-path
• Column B header: new-path

Each row contains one redirect pair. The paths follow the same conventions as manual entry — start with a forward slash, no domain, no trailing protocol.

In Webflow's redirect manager, look for the import option and upload the CSV. Webflow validates the entries and adds them in bulk.

Screenshot placement: [Screenshot showing Webflow's redirect manager with the CSV import option visible]

For large migrations — WordPress sites with hundreds of posts and category pages — bulk import is the only practical approach. The redirect map spreadsheet you built earlier doubles as the source for this CSV with minimal reformatting.

Testing Redirects Before Launch

Redirects set up in Webflow's redirect manager are active on the live site after publishing — they don't work on the staging URL (yoursite.webflow.io). This means redirect testing happens either on the live site immediately after launch, or using a browser extension that can follow redirects on the staging environment.

The practical approach: Test redirects immediately after launch before announcing the new site publicly. The window between DNS propagating and the site being promoted is typically a few hours — use that time to test the most critical redirects.

How to test:

The simplest method is to visit each old URL in a browser and confirm it lands on the correct new page. For a small site with ten or twenty redirects, this is manageable. For larger migrations, use a tool like Screaming Frog to crawl a list of old URLs and check the response codes — a 301 response with the correct destination URL confirms the redirect is working.

What to check:

• Does the old URL return a 301 (not a 302 or a 404)?
• Does the browser land on the correct new page?
• Does the redirect chain — if a redirect points to another redirect — resolve cleanly? Chains of more than one hop are inefficient and should be collapsed to a direct redirect where possible

Priority URLs to test manually:

Regardless of the overall migration size, test these manually every time:

• Homepage (confirm it's not redirecting when it shouldn't be)
• Donation or giving page
• Contact page
• Any page referenced in current grant applications or funder communications
• Any page with significant organic traffic according to Google Search Console

After Launch: Monitoring for 404 Errors

Even with a thorough redirect map, some 404 errors will appear after launch — URLs that were missed in the crawl, links from external sites pointing to pages that never existed, or old campaign URLs that were never on the main domain.

Monitor these in Google Search Console under Pages → Not Found (404). Search Console surfaces URLs that Google has tried to crawl and found a 404. Review this report in the weeks after launch and add redirects for any legitimate old URLs that should be pointing somewhere.

This isn't a sign that the migration was done poorly — some 404s are inevitable. The goal is to address them promptly when they appear rather than leaving them to accumulate.

Screenshot placement: [Screenshot showing Google Search Console's Pages report with the Not Found (404) section selected and a list of 404 URLs visible]

The Redirect Checklist Before Launch

• Screaming Frog crawl of existing site completed and URL list exported
• Redirect map built — old URLs mapped to new URLs or nearest equivalent
• All redirects entered in Webflow's redirect manager or imported via CSV
• Webflow site published after redirects are added
• Priority redirects tested manually after launch
• Google Search Console property set up to monitor post-launch 404s

Further Reading

• How to Prepare Your Nonprofit Website to Go Live
• SEO Fundamentals for Nonprofit Websites
• How to Connect Your Domain to Webflow via DNS