Redirects are easy to add and easy to forget.
A page moves, so someone creates a 301. The site switches to HTTPS, so another rule is added. A trailing-slash convention changes. A new CMS rewrites the route again. Years later, one click may travel through several old decisions before reaching the current page.
The visitor may see only the final destination. The browser, crawler, analytics system, and server still process every step.
That is why a redirect audit should not stop at “the old URL works.” A useful audit asks whether the redirect is necessary, whether its status matches the intent, whether it points directly to the right page, and whether the rest of the site has been updated to use the final URL.
This guide explains how to audit permanent and temporary redirects, detect chains and loops, review destination quality, align canonicals and sitemaps, and prioritize fixes before a launch or migration.
What a redirect communicates
A redirect sends a request from one URL to another URL.
For users, it means the requested page is available somewhere else. For search engines, the type of redirect also communicates whether the move is expected to be permanent or temporary.
Common HTTP redirect status codes include:
- `301 Moved Permanently`
- `302 Found`
- `303 See Other`
- `307 Temporary Redirect`
- `308 Permanent Redirect`
Google treats `301` and `308` as strong signals that the destination should replace the source. Temporary redirects such as `302`, `303`, and `307` are weaker canonicalization signals because the original URL may return later.
The correct status depends on intent, not habit. A permanent URL replacement should normally use a permanent server-side redirect. A temporary outage, test, campaign handoff, or short-lived availability change may justify a temporary redirect.
Start with the source and final destination
Every redirect audit begins with two questions:
- Which URL did the user or crawler request?
- Which URL ultimately returned content?
Record both values. A redirect can look harmless until you notice that an old product page ends on the homepage, a secure URL falls back to HTTP, or a localized page lands in the wrong language.
For each source URL, capture:
- the initial response status
- every intermediate location when available
- the final URL
- the final response status
- whether the destination is relevant
- whether the destination is indexable
- whether the redirect is intended to be permanent
This turns a list of status codes into a map of actual routing behavior.
Distinguish a redirect from a chain
A direct redirect has one step:
`old URL → final URL`
A chain has multiple steps:
`old URL → intermediate URL → another URL → final URL`
Googlebot can follow multiple redirect hops, but Google recommends pointing directly to the final destination. Its site-move guidance advises keeping unavoidable chains low, ideally no more than three hops and fewer than five.
The practical target is simpler: if you control the source, redirect it directly to the current final URL.
Long chains create several costs:
- extra network latency for users
- additional server requests
- more opportunities for a timeout or configuration error
- less efficient crawling
- harder debugging
- inconsistent analytics attribution
- greater risk that an intermediate URL disappears later
A chain is not automatically catastrophic. It is still technical debt worth removing when the source can be updated safely.
Find redirect loops
A redirect loop occurs when the sequence never reaches a page that can return content.
Simple loop:
`Page A → Page B → Page A`
Longer loop:
`Page A → Page B → Page C → Page A`
Browsers eventually stop following the redirects and show an error. Crawlers also stop without processing a final page.
Loops often come from rules that work independently but conflict when combined:
- HTTP forces HTTPS while another proxy forces HTTP
- www redirects to non-www while the application redirects back to www
- a trailing slash is added by one layer and removed by another
- a locale rule sends users to a global URL that detects the locale and redirects back
- a CMS rule conflicts with a CDN or hosting-platform rule
- uppercase paths redirect to lowercase while another route restores the old form
Treat every loop as a launch blocker. There is no useful content at the end of the request.
Choose permanent redirects for permanent moves
Use a permanent redirect when a URL has been replaced and the old address should no longer be the primary version.
Typical cases include:
- moving from HTTP to HTTPS
- changing a domain
- changing a URL path
- consolidating duplicate URLs
- replacing an old product or service page with a direct equivalent
- standardizing www or non-www
- standardizing trailing-slash behavior
Server-side `301` and `308` responses are the clearest options when the platform supports them. Google states that permanent redirects do not cause a loss of PageRank, although the move still takes time to crawl and process.
The important part is not merely returning a permanent status. The destination must be the correct replacement.
Use temporary redirects only for temporary situations
A temporary redirect tells search systems that the source URL may remain the preferred address.
It can be appropriate when:
- a service is temporarily unavailable
- inventory or regional availability changes briefly
- a campaign runs for a defined period
- an experiment routes users without permanently moving the page
- maintenance sends visitors to a temporary explanation
Do not leave a temporary redirect in place for a permanent migration simply because it appears to work in the browser. The status continues to communicate uncertainty about which URL should be treated as canonical.
During an audit, investigate old `302` and `307` responses. Confirm whether they are still temporary. If the source will never return, update the rule to a permanent redirect and align the other signals.
Check that the destination matches the original intent
A technically valid redirect can still be wrong.
The destination should satisfy the same or a closely equivalent user need. An old pricing page should lead to the current pricing page. A renamed product should lead to its replacement. A translated article should lead to the corresponding language version.
Avoid sending many unrelated URLs to the homepage. Google warns that irrelevant redirects may be treated like soft 404s. They are also frustrating for users who expected specific content.
When no useful replacement exists, a genuine `404` or `410` may be more honest than a redirect to an unrelated page.
Ask these questions for every destination:
- Does it answer the same intent?
- Is the topic, product, or service genuinely equivalent?
- Is the language and region correct?
- Is the destination live and indexable?
- Would a visitor understand why they arrived there?
Redirects should preserve usefulness, not merely avoid an error status.
Verify the final response
Do not stop the test when you see a `Location` header. Follow the complete route and inspect the final response.
The destination should normally return `200 OK` and usable content. Watch for chains that end in:
- `404 Not Found`
- `410 Gone`
- `500` server errors
- another temporary redirect
- a login page
- a blocked regional page
- a consent or security challenge
- a soft 404
- a page marked `noindex`
A redirect to a broken destination is still broken. In some reports it may look better than a direct 404 because the first response is 301, but the user journey fails at the end.
Audit protocol, hostname, and path normalization
Many redirect chains come from normalization rules rather than content moves.
One request may pass through several layers:
- HTTP to HTTPS
- non-www to www
- uppercase to lowercase
- no slash to trailing slash
- old path to new path
Each rule may be reasonable on its own. The combined result should still be one direct redirect whenever possible.
Instead of routing `http://example.com/Old-Page` through four intermediate forms, configure the earliest layer you control to send it directly to the canonical final URL.
Test common variants deliberately:
- HTTP and HTTPS
- www and non-www
- trailing slash and no trailing slash
- uppercase and lowercase paths
- encoded characters
- default documents such as `index.html`
- parameters that should or should not be preserved
Normalization should be consistent across the entire site.
Decide what happens to query parameters
Redirect rules can accidentally drop, duplicate, or carry query parameters into places they do not belong.
Review parameters used for:
- campaign attribution
- search and filtering
- pagination
- affiliate tracking
- language or region selection
- application state
A domain migration may need to preserve useful campaign parameters. A canonical cleanup may intentionally remove obsolete parameters. A broad rewrite rule might duplicate the query string or attach it to a URL where it changes the page behavior.
Test both a clean source URL and representative parameter variants. Confirm that the final address matches the desired analytics and indexing behavior.
Update internal links to the final URL
Redirects protect old links. They should not become the normal internal navigation path.
After a URL changes, update internal links so they point directly to the final destination. This includes:
- navigation
- breadcrumbs
- article links
- product recommendations
- calls to action
- footer links
- image and download URLs
- alternate language links
- structured data URLs
Leaving internal links on redirecting URLs makes every visit pay the redirect cost. It also hides old paths inside templates and content where they may survive for years.
Prioritize high-volume and sitewide links first. A redirect in the main navigation affects far more requests than one link in an old archive.
Align canonical tags with the redirect target
The redirect and canonical should point toward the same preferred URL.
After a permanent move, the final page should normally use a self-referencing canonical on the new URL. Avoid situations where:
- the redirect ends on Page B but Page B canonicalizes back to Page A
- the destination canonicalizes to another intermediate URL
- the canonical uses HTTP while the redirect forces HTTPS
- the canonical points to a staging or old domain
- regional redirects and hreflang point to conflicting URLs
Conflicting signals force search engines to interpret what the site meant. A clean implementation makes the preferred version obvious at every layer.
Remove redirecting URLs from XML sitemaps
An XML sitemap should list canonical, indexable URLs that you want search engines to discover.
After a migration, replace old source URLs with the final destinations. Do not keep redirected URLs in the active production sitemap as a permanent discovery strategy.
Also update:
- sitemap indexes
- image and video locations
- hreflang annotations inside sitemaps
- `lastmod` values when the content genuinely changed
- sitemap references in robots.txt
Submitting new URLs helps discovery. Redirects remain important for old links and historical addresses, but the sitemap should describe the current site.
Review redirects during a migration
A migration redirect audit starts with a URL map, not with random spot checks.
Build a source-to-destination table from:
- the old sitemap
- analytics landing pages
- server logs
- pages with backlinks
- paid campaign URLs
- bookmarked tools or downloads
- top internal pages
- crawled URLs from the old site
Every important old URL needs an intentional outcome: a direct equivalent, a consolidated replacement, or a real not-found response when no replacement exists.
Test the mapping before launch where possible. After launch, test it again on production and compare the actual final URLs with the plan.
Google recommends keeping migration redirects for at least one year and as long as possible. From a user perspective, useful redirects can remain indefinitely. At the same time, update links you control so the redirect infrastructure handles historical traffic rather than everyday navigation.
Watch for redirect regressions after launch
Redirects can break after the initial migration succeeds.
A later release may add another normalization rule. A CDN change may reintroduce HTTP. A CMS update may generate a new path. A product team may redirect an existing destination again, turning every old source into a longer chain.
Monitor for:
- new redirecting internal links
- increased 404 or 5xx responses at final destinations
- temporary redirects that never expire
- sudden changes in final hostnames
- loops affecting specific devices or regions
- chains introduced by retired destination pages
- old URLs reappearing in sitemaps
Save a redirect baseline for important migrations and check it after platform or routing changes.
Prioritize redirect findings
Not every redirect needs the same response.
**Fix before launch:**
- redirect loops
- redirects ending in an error
- a wrong or irrelevant destination
- HTTP and HTTPS loops
- redirects to staging, login, or blocked pages
- permanent migrations implemented as inconsistent temporary routes
- destination pages with conflicting canonicals or `noindex`
**Fix soon:**
- multi-hop chains
- internal links that still use old URLs
- redirecting URLs in sitemaps
- unnecessary hostname or trailing-slash hops
- temporary redirects whose intent is no longer temporary
**Monitor:**
- intentional short-lived redirects
- historical sources with low traffic and a correct direct destination
- external links you cannot update
- redirects retained for user bookmarks and old campaigns
This order keeps teams focused on failed journeys and conflicting signals before low-impact cleanup.
A practical Crowra redirect audit workflow
Open the page you are reviewing and run Crowra. In the Links tab, check the page links and identify which URLs redirect. Expand a redirected link to compare its original address with the final URL.
Use this to find internal links that should be updated, unexpected destination changes, and links that resolve successfully only after a redirect. If a change affects many pages, run a same-site crawl and export the results for prioritization and handoff.
Crowra shows that a link redirected and where it finished. Because browser fetch behavior follows the route, use response-header inspection, server logs, or a dedicated redirect tracer when you need every intermediate hop and exact status code in a chain.
Then review the destination page in Crowra for the related signals: canonical, indexability, robots directives, links, hreflang, schema URLs, and sitemap discovery. The redirect is only healthy when the final page is healthy too.
For a migration, compare the observed final URL with the approved source-to-destination map. Export the findings, assign owners, deploy corrections, and repeat the checks on production.
Redirect audit checklist
Before launch or migration, confirm all of the following:
- Every important source URL has an intentional outcome.
- Permanent moves use a permanent server-side redirect where possible.
- Temporary redirects are genuinely temporary.
- Each source points directly to the final destination when possible.
- No redirect loop exists.
- The final destination is relevant to the original page.
- The final response is successful.
- The destination is crawlable and indexable.
- HTTP, hostname, case, and trailing-slash rules agree.
- Query parameters are preserved or removed intentionally.
- Internal links point directly to final URLs.
- Canonical tags agree with redirect destinations.
- Hreflang and structured data use final URLs.
- Redirecting URLs have been removed from active sitemaps.
- High-traffic and backlink-rich source URLs were tested.
- Mobile, regional, and language routing does not create loops.
- The production implementation matches the migration map.
- Redirects will remain available long enough for users and search engines.
- The site will be crawled again after deployment.
A redirect audit is not about eliminating every 3xx response. Redirects are essential infrastructure for a site that changes over time. The goal is to make every redirect intentional, direct, relevant, and consistent with the rest of the site's technical signals.