LumaProbe makes one server-side HEAD request per hop, follows no more than ten redirects and validates every destination before connecting. Private addresses, credentials and non-standard ports are blocked.
A short permanent redirect is usually easier to maintain than several hops. Temporary and permanent codes have different meanings, while some sites reject HEAD requests even though normal browser visits work.
The checker validates the starting public HTTP or HTTPS URL, resolves its host and pins a public address for one HEAD request. When a 3xx response supplies a Location header, LumaProbe resolves that destination against the current URL, validates and pins the next public host, and continues for no more than ten hops.
Each hop reports its status, requested URL, response time and selected non-cookie headers. Loops stop automatically. Credentials, private and reserved destinations and non-standard ports are rejected on every hop rather than only at the starting URL.
Enter the exact URL whose route you need to understand, including http or https and any relevant path. Remove passwords, signed query strings, private tokens and personal identifiers. Use a public page that you own or are authorised to diagnose.
Decide the intended final canonical address before interpreting the chain. For a normal public site, compare http, https, www and non-www starting forms separately because each may follow a different route.
A 301 or 308 generally expresses a permanent move, while 302, 303 and 307 express temporary or method-specific behaviour. The correct choice depends on the application. Several valid redirects can still add delay and create more points of failure, especially when protocol and hostname changes are split into separate hops.
Selected headers can reveal HSTS, Content Security Policy, framing, content-type protection, caching and the next Location. Missing a header is not automatically a vulnerability: the appropriate policy depends on the page, and some controls can also be supplied by the application or browser context.
The tool sends HEAD rather than executing a full browser page. It cannot see JavaScript redirects, every HTML meta refresh, client-side routing, login-dependent destinations or a response that differs by cookie. Some servers reject HEAD and may report an error even when GET works.
The request comes from one United Kingdom server using one user agent. CDNs, language negotiation, regional routing and bot protection can return a different chain elsewhere. A public result must not be used to probe private systems or bypass access controls.
Remove loops, broken destinations and unnecessary intermediate hops. Ensure the intended final page returns a successful code, uses HTTPS and declares the correct canonical URL in its HTML. Update internal links to point directly to the final address rather than relying on redirects.
After a migration, test representative URLs in a browser and search crawler, verify the sitemap contains final canonical locations and monitor logs for unexpected 404 or 5xx responses. Keep redirects long enough for users and search engines to update established links.
Read the complete LumaProbe test methodology and privacy notes →
Up to ten. Every public destination is validated before connection, and loops stop automatically.
The tool sends HEAD and does not execute JavaScript, store a login session or follow client-side application routing. Some sites return different responses to browsers.
They are not automatically an error, but unnecessary hops add latency and failure points. Internal links and sitemaps should normally use the final canonical URL directly.