Redirect Audit Checklist

Use this for: Existing redirects and URLs affected by a planned or recent change.

Combine the existing redirect export with old migration maps, previous sitemaps and important landing pages from Search Console or analytics. Keep the full host, path and query string when they affect the route. Deduplicate exact repeats without collapsing distinct language or product URLs.

Create columns for source URL, intended destination, permanent or temporary intent, observed route and next action. For a small review, start with the old addresses that customers still use. For a larger migration, test the full known list rather than only the URLs a homepage crawl discovers.

1. Export existing rules and collect historical URLs from the sources you have.
2. Assign a relevant destination, temporary route or genuine removal decision to each source.
3. Keep unresolved mappings visible until the content owner decides where the old page belongs.

Use this for: Every source URL in the redirect sample or uploaded list.

In Chrome, open Developer Tools, choose Network, and enable Preserve log. Keep DevTools open, enable Disable cache, clear the log, then enter the exact source URL. Inspect the document requests in order. Under Headers, read the status and any Location response header; open the final document and check its content.

For a larger list in Screaming Frog, use Mode > List, upload the source addresses, and enable Always Follow Redirects in the spider configuration. Review the All Redirects report for source, hops and final response. A test that stops at the first 301 has not checked the destination.

1. Request the exact source with redirect history retained.
2. Read every document status and destination, including the last response.
3. Compare the observed route with the intended mapping.

Use this for: Permanent moves, content merges and retired pages with proposed replacements.

Open the proposed target and compare it with the old page’s title, main topic, language and user task. Use the previous content or migration record when the old page can no longer be opened. A specific repair-service page needs a useful continuation of that service, not merely a page on the same domain.

If content has no relevant replacement, a genuine 404 or 410 can be the correct outcome. Do not create a homepage redirect just to remove an error count. Where several old pages were merged, check that the combined page actually covers the material users came for.

1. Compare the old page’s purpose with the proposed target’s main content.
2. Check language, product or service identity and the action a visitor needs.
3. Choose the closest useful replacement, or retain a genuine removal response when none exists.

Use this for: URLs that have permanently moved.

In the CMS redirect screen, hosting rules or CDN rule, confirm that the move is permanent. Then check the source in Network or your crawler: the published response should be 301 or 308 and its Location should name the intended destination. The setting in the editor is not proof of the response visitors receive.

Use 302 or 307 for a genuinely temporary route. Do not rewrite every redirect to 301 because a crawler highlights it. If a rule affects form submissions or an API, have the developer check request-method behavior before changing it.

1. Confirm with the page owner that the move is lasting.
2. Inspect the source response and Location at the public URL.
3. Correct an unintended temporary rule and request the source again.

Use this for: Pages that move after an initial successful response or rely on browser scripts.

If the source initially returns 200 and the browser moves afterward, inspect the original response for a Refresh header or a meta refresh element. Check the Network initiator and page script for location-based navigation. This is different from an HTTP 301 or 302 response, even if the final address looks identical.

For an ordinary moved public page, prefer a server-side redirect when the platform supports it. JavaScript redirects depend on rendering, which can fail. If a platform forces a client-side fallback, verify the actual mechanism and destination instead of reporting it as a server redirect.

1. Compare the source HTTP response with the browser’s subsequent navigation.
2. Identify the HTTP, meta refresh, Refresh-header or JavaScript mechanism.
3. Use the platform’s supported server redirect for the move when possible and retest.

Use this for: 302 and 307 page redirects.

Filter your crawler’s redirects for 302 and 307. In the matching CMS, application or CDN setting, find why each route exists. Ask whether the source should return later, and identify the event or date that ends the temporary arrangement.

Keep an intentional temporary redirect while it serves that purpose. When the original page returns, remove the temporary rule and test the original address. If the move has become permanent, update the decision and response together; there is no universal number of days that makes every temporary redirect wrong.

1. Review the 302 and 307 sources in the crawl results.
2. Confirm their temporary purpose and the event or date for review.
3. Restore the source or change the move to permanent when that decision is made.

Use this for: Public redirects controlled by session, language, region or device conditions.

Open the source in a fresh signed-out session and compare it with the normal browser session. If your site uses language, region or device routing, use approved test settings or ask the developer to test those branches. Check the actual landing language and route, not only whether the browser loads something.

A locale redirect that works for your saved preference can send first-time visitors elsewhere. Keep private account routes protected, and do not treat a signed-in success as proof that a public search landing page is accessible.

1. Test the same public source in a signed-out session.
2. Compare applicable language, region or device branches with their intended destinations.
3. Repair the incorrect branch and repeat the affected visitor journeys.

Use this for: Redirect paths containing avoidable intermediate hops.

In Screaming Frog, open Reports > Redirects > Redirect Chains, or read the preserved Network document requests. For each chain, locate the rule for the first old URL and compare its target with the final relevant page. Change the old rule to that final page when no required intermediate behavior is lost.

Keep each old source that still needs to work. Flattening /old-a/ → /old-b/ → /current/ means making both old addresses lead to /current/; it does not mean deleting /old-b/ while other visitors still use it.

1. Identify each avoidable hop and its rule owner.
2. Point affected sources directly at the intended final page.
3. Retest every changed source and confirm the final response and content.

Use this for: A crawler loop finding or a browser’s too-many-redirects error.

Use the redirect trace to find the first repeated URL. Then inspect the rules producing the two conflicting moves. Common places to compare are the CDN’s hostname or HTTPS settings, the origin server and the CMS redirect plugin.

Correct the conflicting condition at its source. Do not add another redirect on top of a loop. After the change, test both URLs and any affected host or protocol variants so the same conflict cannot restart from another entry point.

1. Find the repeated address in the redirect trace.
2. Locate and correct the rules creating the cycle.
3. Request every affected entry URL and confirm that each route terminates.

Use this for: Sites using alternate hosts, HTTPS upgrades or path normalization.

For a representative deep page, test the hostnames and HTTP or HTTPS forms your site supports. Include the path variants your rules deliberately normalize, such as a trailing slash. Inspect the full destination: a hostname rule that keeps the domain but drops the path still sends people to the wrong page.

Prefer a direct route to the chosen secure URL. Do not introduce blanket lowercase or trailing-slash rules without checking the application’s real URL behavior; different paths can represent different resources. Fix a certificate problem through the host rather than bypassing a browser warning.

1. Choose a real deep URL and the variants supported by your site.
2. Trace each variant and compare its final host, protocol and path.
3. Correct inconsistent normalization and retest the deep page plus the homepage.

Use this for: Redirect rules involving queries, path captures, encoded values or useful fragments.

Choose source URLs with meaningful query strings, encoded characters or page fragments. Compare the full destination and the visitor’s result after the redirect. A product identifier may determine the content; a campaign parameter may support attribution. Keep what the destination needs and remove only parameters your site intentionally discards.

Test parameterized examples separately from the clean URL. If a rule uses a wildcard or captured path, check a normal match, an edge case and a URL that should not match. Ask the developer to narrow an overbroad rule rather than assuming every query string should be copied.

1. Select URLs whose query, encoding or fragment changes the intended result.
2. Compare the complete redirect target and the page or section reached.
3. Repair lost context or an overbroad match, then test a nonmatching control.

Use this for: Redirects to public pages intended to serve as search destinations.

Open the final page directly. For a public page intended for search, check that it serves the expected content successfully and has no accidental login requirement or noindex. Inspect its canonical in page source or the response headers when one is supplied; it should agree with the intended representative, not send a conflicting preference back to a retired URL.

Update your own navigation and contextual links to the final page. In an ordinary current sitemap, replace retired redirecting entries with the intended canonical destination. Review separate migration sitemap handling with the migration owner rather than deleting a deliberate migration artifact.

1. Inspect the final page’s response, content and indexing signals.
2. Find internal links and sitemap entries that still use the retired address.
3. Update conflicting references and test the destination directly and via the old URL.

Use this for: Changes to redirect rules or shared routing configuration.

Before editing a shared redirect file, CMS export or CDN rule set, save the current version in the site’s normal change history. Identify the exact change to restore if it causes a loop or sends important pages to the wrong place. A copy of a mapping spreadsheet is useful, but it is not a backup of the deployed rules.

Test the proposed matches with your platform’s rule tester or normal development checks. Include a source that should redirect, a target that should load directly, and an unrelated path that should remain unchanged. For a broad change, have the developer check rule order and overlapping wildcard conditions.

1. Save the current deployed rules through the platform’s normal backup or history feature.
2. Test the intended match, final destination and unaffected control.
3. Confirm the restoration method before publishing the change.

Use this for: Published redirect fixes and decisions about retiring old redirects.

After publication, rerun the changed source list with redirects followed to the end. Open important final pages and repeat the host, parameter and nonmatching controls affected by the change. If the new rule creates a critical loop or wrong destination, restore the known working version and investigate.

Keep lasting redirects available for as long as old links still need them. For a site move, Google recommends retaining redirects for at least one year; visitor bookmarks and external links can justify longer. A clean internal crawl is not a reason to delete redirects that serve those old links.

1. Rerun all changed sources and affected controls against the published site.
2. Fix or restore any regression, then repeat the same checks.
3. Keep useful historical redirects and compare later crawler records separately from the live repair.