Redirects for Site Redesigns: A Pre-Launch and Post-Launch Checklist

Overview

The safest way to treat redirects during a redesign is to see them as part of the release plan, not as a last-minute patch. Every changed URL creates a decision: keep it live, redirect it, consolidate it, or retire it with intent. A good redirect strategy protects organic traffic, preserves bookmarks and campaign links, reduces avoidable 404s, and gives search engines a clear path from old content to new content.

For most redesigns, the default redirect for permanently moved pages is a 301 redirect. A 302 redirect is usually reserved for temporary moves, testing windows, or short-lived routing changes. If your team is still debating 301 vs 302 late in the project, pause and document the intended permanence of each change. Ambiguity at this point tends to create mixed signals later.

This article is organised as a reusable pre-launch redirect checklist and post-launch redirect audit. It is especially useful when any of the following apply:

• URL paths are changing during a CMS rebuild
• categories, products, or articles are being merged or removed
• a domain or subdomain is changing
• HTTP to HTTPS or www to non-www redirect rules are being adjusted
• legacy content needs to be preserved without carrying forward weak architecture

If you need a deeper framework for planning page-level rules, see Redirect Mapping for Website Migrations: How to Build, Validate, and Maintain a Redirect Map.

Checklist by scenario

This section gives you a practical checklist by redesign type. Start with the scenario that best matches your launch, then add the general controls that apply to every migration.

Scenario 1: Same domain, new URL structure

This is the most common redesign pattern: the brand and domain stay the same, but templates, taxonomy, slugs, or CMS logic change. It often looks simple from the outside and messy in practice.

• Export all current live URLs from your CMS, sitemap, analytics landing pages, and crawl data.
• Identify which URLs will remain unchanged, which will move, and which will be removed.
• Create a one-to-one redirect mapping wherever a clear equivalent exists.
• Where multiple old URLs now resolve to one consolidated page, document the reason so the team can defend the decision later.
• Avoid redirecting many unrelated pages to the homepage. That is rarely useful for users and weak for SEO.
• Implement server side redirect rules where possible rather than relying on client-side scripts or meta refresh behaviour.
• Test for a single-hop destination: old URL to final new URL, ideally with no intermediate redirect chain.
• Update internal links so they point directly to final URLs instead of passing through redirects.

Scenario 2: Domain change or brand migration

This is where redirect quality matters most because every URL may be affected, not just a subset.

• Confirm the preferred destination format first: HTTPS, host version, and trailing slash rules.
• Decide whether redirects will be managed at the application, server, or edge layer.
• Map every important old URL to its closest new equivalent on the new domain.
• Validate that canonical tags, hreflang where relevant, XML sitemaps, and structured navigation all reflect the new domain.
• Keep the old domain active long enough to serve redirects reliably.
• Check whether marketing links, PDFs, QR codes, and paid campaign destinations still use the old domain.
• Test direct requests for both host variations and protocol variations, such as http://, https://, www, and non-www.

For the infrastructure side of this, see Domain Forwarding vs Website Redirects: What Changes at DNS, Hosting, and Browser Level.

Scenario 3: Platform rebuild, such as WordPress, Shopify, or custom CMS

Platform changes often introduce default URL behaviour that teams notice too late. Slugs may change casing, trailing slash handling may differ, attachment URLs may surface, or collections may be rebuilt under new paths.

• Review platform defaults for permalink structure, category paths, product handles, and archive behaviour.
• Identify any automatically generated redirects and decide whether they are sufficient or need replacing.
• Audit attachment, media, tag, filter, and search-result URLs so they do not create redirect noise.
• Make sure staging rules do not accidentally carry over to production.
• Test editor-created redirects against server-level rules to avoid conflicts.

Platform-specific guidance may help here, especially for WordPress redirects and Shopify redirects.

Scenario 4: Protocol and host normalisation

Sometimes the redesign itself is not the main risk. The bigger issue is inconsistent canonicalisation: HTTP and HTTPS both resolve, or both www and non-www are indexable.

• Choose one canonical host and one canonical protocol.
• Set a single rule for HTTP to HTTPS redirect handling.
• Set a single rule for www or non-www preference.
• Confirm these rules do not create loops when combined with application routing or CDN logic.
• Check that canonicals, internal links, sitemaps, and hreflang references all use the preferred version.

Useful supporting guides include HTTP to HTTPS Redirects: Best Practices, Common Mistakes, and Testing Steps and www vs non-www Redirects: How to Choose and Configure the Preferred Version.

Scenario 5: Large content consolidation

Redesigns often involve cleaning up old content, merging thin pages, or retiring outdated sections. This can improve site quality, but only if redirects reflect user intent.

• Group old URLs by topic, template, and business value.
• Redirect retired pages to the closest relevant destination, not to the nearest available page.
• Use a 410 only where removal is deliberate and no substitute exists.
• Preserve high-value landing pages, linked resources, and frequently shared assets even if they no longer fit the new navigation.
• Keep a record of pages intentionally allowed to return 404 or 410 so they do not get re-added in a panic after launch.

General pre-launch redirect checklist

• Freeze the list of old URLs before final QA begins.
• Approve a master bulk redirect map with source URL, target URL, status code, and owner.
• Check that redirect rules are case-aware if your environment treats case differences as unique URLs.
• Test query string behaviour, especially for campaign links and UTM link tracking.
• Exclude staging, preview, login, cart, and private environments from public redirect logic where appropriate.
• Confirm there are no accidental wildcard rules that send broad sets of pages to irrelevant destinations.
• Prepare a rollback plan in case redirect deployment conflicts with caching, CDN rules, or origin configuration.

General post-launch redirect audit checklist

• Crawl the old URL list immediately after launch and record response codes.
• Use a redirect checker to verify status codes and final destinations for key templates.
• Review server logs, analytics landing pages, and Search Console reports for new 404 patterns.
• Check high-value backlinks and top organic landing pages first.
• Find and fix any redirect chain longer than a single hop where practical.
• Investigate any redirect loop as a priority issue.
• Replace internal links that still point to old paths.
• Regenerate XML sitemaps so only final canonical URLs are listed.

If your redirects are managed at the edge or server layer, these implementation references are useful: Cloudflare Redirect Rules Explained, Nginx Redirect Guide, and Apache Redirect Guide.

What to double-check

Even careful teams miss the same handful of details during a redesign. This section focuses on the items most likely to cause traffic loss, crawl waste, or confusing user journeys.

1. Status codes are intentional

Do not assume your platform is issuing the code you intended. A page may appear to redirect correctly in the browser while returning a temporary code instead of a permanent one, or vice versa. Validate whether each rule should be a permanent redirect or a temporary redirect, then confirm the live response.

2. Redirects point to the final canonical URL

An old page should not redirect to an intermediate page that then redirects again to enforce HTTPS or host preference. The cleaner pattern is old URL straight to final destination. This improves crawl efficiency and reduces avoidable latency. If you need help, review How to Fix Redirect Chains and Redirect Loops on Live Websites.

3. Canonical vs redirect decisions are not mixed up

A canonical tag is not a substitute for a redirect when a URL has moved. Likewise, a redirect is not always the right answer for duplicate-like variations that still need to exist for users. Clarify canonical vs redirect during planning so the implementation is consistent.

4. Query strings and campaign links still behave properly

Some redirect rules accidentally drop tracking parameters. Others preserve every parameter when they should not. Test how your rules handle UTM-tagged links, paid campaign URLs, and tracked short links so reporting remains useful after the redesign.

5. Non-HTML assets are accounted for

PDFs, downloadable guides, image assets, feed URLs, and old campaign landing pages are easy to forget. They may still attract backlinks or branded searches. Include them in your redirect mapping where they have continuing value.

6. Redirect rules do not conflict across layers

A single website redirect may be touched by the CDN, load balancer, application, plugin, and origin server. Conflicts often create loops or duplicate logic. Keep one documented source of truth and test each layer in isolation when troubleshooting.

Common mistakes

Use this section as a final sense check before launch day and again during your post-launch redirect audit.

• Building redirects after the site is already live: this creates a window where search engines and users hit unnecessary 404s.
• Sending deleted pages to the homepage: this weakens relevance and is frustrating for users.
• Ignoring internal links: a well-built URL redirect plan still underperforms if your own navigation points to old paths.
• Leaving temporary redirects in place: many redesigns launch with 302s that were meant only for testing.
• Using broad wildcard rules without review: they can seem efficient, but they often route unrelated pages to poor matches.
• Failing to test host and protocol combinations: what works for one version of the URL may fail for another.
• Not preserving top-performing legacy URLs: some older pages continue to attract traffic even if they no longer fit the new information architecture.
• Overlooking chain creation during phased launches: each mini-migration may work alone, but together they create multi-hop redirects.
• Relying only on browser checks: visual behaviour is not enough; inspect headers and response codes.
• Removing old domains too soon: if the old property stops resolving, even a perfect redirect mapping becomes useless.

One of the most reliable ways to avoid these problems is to treat redirect management like release engineering: version the rules, document owners, test against a fixed URL sample, and review exceptions before deployment.

When to revisit

Redirect planning is not finished when launch day ends. The right review cadence depends on how often your site structure changes, but a few triggers are consistent across most teams.

• Before each major redesign or template rollout: revisit your redirect checklist and update assumptions about slugs, taxonomy, and canonical structure.
• Before seasonal planning cycles: check whether campaign URLs, promotional landing pages, and historic high-traffic paths still resolve correctly.
• When workflows or tools change: a new CDN rule set, CMS plugin, or deployment method can alter redirect behaviour without obvious warnings.
• After content consolidation projects: confirm that merged sections still map old URLs to the best available destination.
• When analytics or Search Console surface new 404 trends: update the redirect map rather than treating every error as isolated.
• When domain, subdomain, or protocol settings are adjusted: retest all canonicalisation rules end to end.

A practical routine is to keep one living redirect document with four columns that always matter: old URL, current expected destination, status code, and validation date. Review it before any release that touches routing, hosting, taxonomy, or navigation. That simple habit turns redesign redirects from a reactive cleanup task into a controlled process.

For teams managing repeated launches, the most useful next step is to build a standard operating checklist from this article: freeze legacy URLs, approve redirect mapping, test status codes, launch with monitoring, then run a post-launch audit focused on chains, loops, and missed legacy paths. If you do that consistently, site redesign redirects become much less risky and much easier to maintain over time.