What the redirect checker reports
An HTTP redirect tells a browser or crawler to request a different URL. This checker starts with the public address you enter, sends a lightweight request, and records each supported redirect response in order. The report includes the status code, source URL, destination URL, final address, final status, request method, and total number of followed hops. Seeing the complete chain makes it easier to diagnose a migration, canonical-host change, protocol upgrade, shortened link, or routing rule.
The tool recognizes the standard permanent and temporary redirect statuses commonly used on the web: 301, 302, 303, 307, and 308. It follows at most five hops. A longer chain is rejected instead of continuing indefinitely, and a repeated URL is reported as a loop. If a server does not support the initial HEAD request, PagesTools makes one bounded GET fallback without downloading a page body. A redirect response without a usable Location header remains the final response because there is no safe destination to follow.
How to interpret permanent and temporary redirects
A 301 or 308 normally communicates that a resource has moved permanently. Browsers, caches, and search systems can remember that instruction, so a permanent status should point to the durable canonical destination. A 302 or 307 normally describes a temporary move, while 303 explicitly directs the client to retrieve another resource with GET semantics. Application behavior can still depend on the original method, cache headers, and client implementation, so the status should agree with the intended behavior rather than being selected only because it appears to work in one browser.
A direct one-hop redirect is usually easier to maintain and faster for visitors than a chain. For example, an old HTTP address should ideally reach the final HTTPS canonical URL without first moving through several retired hosts or path formats. Every extra hop adds another DNS lookup, connection, request, and opportunity for failure. Replace internal links, sitemap entries, canonical tags, feeds, and marketing URLs with the final address when practical, while keeping necessary redirects for external bookmarks and historical links.
Read the complete path instead of considering only the last successful status. A final 200 response can hide a chain that crosses hosts unnecessarily, changes between HTTP and HTTPS more than once, or passes through a tracking service no longer required. A final 404, 410, 429, or 500-series response shows that the redirect itself worked but its destination did not provide a normal page at the time of the check. The report is evidence for troubleshooting, not a declaration that every redirect is correct.
Common redirect problems to investigate
A loop occurs when routing rules eventually send the client back to an address already visited. This can happen when an application and reverse proxy both enforce a preferred scheme or hostname using conflicting assumptions. Excessive chains often grow during repeated migrations: one rule handles HTTP, another adds www, a third changes a directory, and a fourth points to a replacement page. Consolidating the logic and testing representative old URLs reduces latency and makes future changes easier to reason about.
Check query strings and paths carefully. Some redirects should preserve campaign parameters or language choices, while others should intentionally discard obsolete values. A broad rule can send every missing page to the home page, producing a misleading soft-not-found experience. Redirects should normally lead to the closest relevant replacement. Also inspect case sensitivity, trailing slashes, encoded characters, and internationalized hostnames because a rule that works for one example may fail for another variation.
Compare results from the production hostname rather than a private administration address. A content delivery network, load balancer, geographic policy, login session, consent cookie, or experiment can change what a particular visitor receives. Test a representative set of URLs after deployment and review server or proxy logs for requests that never reach the application. When search visibility matters, also confirm that canonical markup and XML sitemaps consistently name the final indexable address.
Safety, privacy, and network limits
The redirect check requires a network request from the PagesTools server, so the URL is sent to PagesTools and then requested using a clearly identified server user agent. Do not submit confidential, signed, password-reset, preview, or single-use links. The entered URL may contain information in its path or query string even when the page itself is public. Remove secrets and use a safe public example whenever possible.
PagesTools accepts only HTTP and HTTPS destinations without embedded credentials. Before every connection, the hostname is resolved and all returned addresses must be public internet addresses. Redirect destinations are normalized, resolved, and checked again, which prevents a public starting URL from silently redirecting the service toward a loopback, private network, link-local address, or cloud metadata endpoint. DNS results are pinned to the connection for that hop to reduce rebinding risk.
Requests have strict time, response, redirect, and rate limits. These safeguards mean the checker is intentionally not a general-purpose crawler, uptime monitor, load tester, or authenticated browser. It does not execute JavaScript, store cookies, submit forms, or reproduce a personalized session. An unavailable host, blocked bot, transient DNS failure, or rate limit can produce an error even when the page works for another client.
Using the result in a release workflow
Before a migration, list the most valuable old pages and expected destinations. Run the checker for representative paths, export the JSON report when useful, and compare the actual chain with the redirect map. Repeat the checks after proxy, application, or content-management changes. Automated integration tests can cover deterministic rules, while this server-side check provides an independent view through public DNS and the deployed network path.
Treat a clean result as one part of verification. Open the final page, confirm its content and canonical URL, inspect caching rules, and check that analytics or consent behavior still works. PagesTools cannot decide whether a destination is editorially equivalent, whether a permanent status is appropriate for a business process, or how a search engine will consolidate signals. A short, intentional, documented chain remains the most maintainable outcome.