How to Audit WWW Redirects After a Website Migration

A website migration can leave different versions of the same hostname pointing to different locations. Visitors, crawlers and third-party services may request HTTP or HTTPS, with or without “www.” A redirect audit checks whether every supported entry point reaches the intended canonical destination without unnecessary hops, loops or errors.

The goal is not merely to find a redirect. You need to confirm its status code, full path, final destination and consistency across representative URLs. The WWW Redirect Checker can support this review, but its observations should be combined with browser, server, CDN and crawling checks.

When is this review useful?

• Immediately after changing domains, platforms, hosting providers or URL structures.
• After choosing between a www and non-www canonical hostname.
• When enabling HTTPS, replacing certificates or changing CDN settings.
• When users report redirect loops, privacy warnings or unexpected pages.
• When analytics, crawl reports or server logs still show requests to an old hostname.
• After changing reverse-proxy, load-balancer, web-server or HSTS configuration.

Before you begin

Record the intended canonical scheme and hostname. For example, the preferred origin might be https://www.example.com. Also document whether paths and query strings should be preserved, which old URLs have specific replacements, and whether any sections intentionally move elsewhere.

Make configuration changes in a staging environment where possible. Export current rules and coordinate with whoever controls DNS, hosting, the CDN and the application. A mistaken hostname-wide rule can make an entire site inaccessible.

Prepare a sample containing the homepage, important category pages, articles, media URLs and several old addresses. Include URLs with query parameters, mixed letter case where relevant, trailing-slash variations and at least one nonexistent path.

Step-by-step redirect audit workflow

1. Test all four hostname variants. Submit the HTTP www, HTTP non-www, HTTPS www and HTTPS non-www versions to the WWW Redirect Checker. Test complete URLs rather than only hostnames:

   • http://example.com/sample-page
   • http://www.example.com/sample-page
   • https://example.com/sample-page
   • https://www.example.com/sample-page

   Repeat this test across the sample set. One successful homepage check does not establish that deeper paths behave identically.

2. Record each response hop. Note the initial status, every intermediate destination and the final status. Permanent migrations commonly use 301 or 308 responses. A 302 or 307 may be intentional during testing or for temporary routing, but it should be reviewed if the move is meant to be permanent.

3. Confirm the canonical destination. Every general variant should normally converge on the selected scheme and hostname. Check that the final path is correct and returns the expected content. A redirect to the preferred hostname is not sufficient if every old page is sent to the homepage.

4. Look for chains. A request such as HTTP non-www to HTTPS non-www to HTTPS www contains two redirects. Where infrastructure permits, a direct redirect from each alternate variant to the final URL is usually easier to maintain. Do not remove a hop without checking application, CDN and HTTPS dependencies.

5. Check for loops and limits. A loop may alternate between www and non-www, HTTP and HTTPS, or slash and non-slash forms. Stop repeated testing if the same URLs recur. Compare rules at every layer because the origin and CDN may each be enforcing a different preference.

6. Verify path and query handling. If an old article should map to a replacement article, confirm that exact mapping. Determine whether useful query parameters survive and whether obsolete tracking parameters may be discarded intentionally. Avoid blindly appending all parameters when they can alter application behavior.

7. Compare redirects with canonical signals. The final page’s canonical tag, internal links, sitemap entry and alternate-language references should use the preferred hostname and scheme. A canonical tag is a hint about duplicate URLs; it does not replace a server-side redirect where one is required.

8. Repeat from different request contexts. Test in a private browser window, with a command-line HTTP client if available, and from outside your corporate network. Then compare the behavior with and without the CDN or proxy only if your infrastructure allows safe origin testing.

Illustrative findings

The following examples are hypothetical and do not represent results produced for Bytorr or any specific website.

How to interpret the findings

A final 200 response is useful only when it belongs to the intended page. A 404 or 410 may be appropriate when content has no replacement; redirecting every removed URL to the homepage can obscure genuine removals. A 5xx response indicates that the destination or an intermediary could not complete the request and should be investigated through server and CDN logs.

Treat redirect length as an operational observation rather than a score. A single hop is generally preferable, but some environments require an edge-level HTTPS step. Prioritize loops, wrong destinations, broken paths, cross-domain surprises and inconsistent behavior before optimizing a stable extra hop.

Cache, CDN and HSTS considerations

Browsers, CDNs, reverse proxies and applications can cache redirects. After a rule changes, an old response may remain visible until its cache lifetime expires or an authorized purge is completed. Compare a normal browser with a private session and a fresh HTTP request. Do not assume that clearing only the browser cache clears the CDN.

CDNs may apply redirects before a request reaches the origin. Review edge rules, page rules, worker logic, forwarding settings and cached responses alongside origin configuration. Use provider-supported purge controls rather than broad, repeated purges without a plan.

HSTS instructs compatible browsers to use HTTPS and can make an HTTP request appear to upgrade locally before contacting the server. That is useful behavior, but it can hide the actual HTTP response during browser testing. Inspect network details or use an HTTP client that shows the request sequence. Be especially cautious with long HSTS lifetimes, subdomain coverage and preload-related changes because recovery may not be immediate.

Common mistakes

• Testing only the homepage or only one hostname variant.
• Checking the final page while ignoring intermediate responses.
• Using temporary redirects indefinitely for a permanent migration.
• Sending all old URLs to the homepage regardless of relevance.
• Dropping paths or meaningful query parameters through a broad rule.
• Creating conflicting redirect logic at the CDN, server and application layers.
• Assuming a canonical tag will redirect visitors.
• Changing HSTS and redirect rules simultaneously without a rollback plan.
• Reading cached behavior as proof that the current configuration is wrong.

Follow-up manual checks

• Open representative final pages and confirm their content, title and navigation.
• Inspect canonical tags and alternate-language references.
• Update internal links so they do not rely on redirects.
• Check XML sitemaps for old schemes, hostnames and paths.
• Review server, application and CDN logs for old-host requests, loops and errors.
• Crawl a representative section of the site and export redirect chains.
• Test forms, logins, checkout steps, APIs, images and downloadable files separately.
• Monitor the sample set after cache expiration and after subsequent releases.

Limitations

A redirect checker observes responses available from its request environment at a particular time. Results may differ by geography, user agent, cookies, authentication, device, DNS resolver or CDN node. The tool may not reveal browser-only JavaScript navigation, personalized routing, cached HSTS behavior or rules triggered after login.

A successful redirect also does not prove that content mapping, analytics, canonicals, sitemaps or application flows are correct. Use the findings as evidence within a wider migration review, not as a substitute for logs, crawling and manual inspection.

Frequently asked questions

Should a site prefer www or non-www?

Either can work. Choose one based on existing architecture and operational needs, then use it consistently in redirects, canonical tags, internal links and sitemaps.

Is one redirect hop always required?

No. A URL already using the canonical scheme, hostname and path should normally serve its response directly. Alternate variants may need one redirect to reach it.

Are 301 and 308 redirects interchangeable?

Both indicate permanent movement, but 308 preserves the request method and body explicitly. Application and client behavior should be reviewed before changing status codes, especially for non-GET requests.

Why does a browser show different behavior from a checker?

The browser may hold a cached redirect, apply HSTS, send cookies or execute client-side logic. A checker may use a different location, user agent or network path.

How long should post-migration redirects remain?

There is no universal duration. Keep useful mappings while old URLs continue to receive legitimate requests and while removing them would disrupt visitors or integrations. Review logs before retiring rules.

Should missing pages redirect to the homepage?

Usually not by default. Map an old URL to a closely relevant replacement when one exists. Otherwise, an appropriate 404 or 410 response may communicate the outcome more clearly.

When should the audit be repeated?

Repeat it after deployment, after CDN caches have refreshed, after major configuration changes, and periodically while migration-related requests remain visible in logs.