How to Monitor Website Redirects

Why a redirect can break your site without breaking uptime

A successful response tells you that a server answered your request. It does not tell you which server answered, or that the content it returned belongs to you. Most availability checks follow every redirect hop and then judge only the final response, so a page served from somebody else's domain passes exactly the same test your own homepage does.

The most common way this happens is a lapsed domain. An auto-renewal fails because the card on file expired, the registrar takes back the nameservers, and a parking page goes up in place of your website. The parking page loads quickly and returns a normal success status, so uptime stays at one hundred percent and response time may even improve, because a parking page is a fraction of the size of a real site.

The second way is a compromise. An attacker who gets into a content management system or a build pipeline rarely takes the site offline, because an offline site gets fixed within the hour. Instead they add a redirect to an affiliate, spam, or malware destination, and they often make it conditional so it only fires for mobile visitors or for people arriving from a search engine. The site looks perfectly normal to the person who owns it.

The third way is an ordinary mistake. A rebrand or domain migration adds a redirect rule that was meant to move an old domain to a new one, and the rule turns out to be broader than intended. Traffic that should have stayed on the live site starts leaving it. Nothing has failed in any technical sense, which is exactly why no alert fires.

In every one of these cases the visitor experience is severe and the monitoring signal is silent. Search engines begin dropping the pages, paid traffic lands somewhere unrelated, and conversions stop, while the dashboard stays green for as long as nobody looks at what the check actually saw.

How to monitor redirects so off-site landings are caught

The first change is to judge the destination rather than the journey. It is tempting to inspect the chain of redirect responses and raise an alert when one of them leaves your domain, but that approach only catches redirects issued by the server. A compromised page usually redirects with JavaScript after the page has loaded, or with a meta refresh in the page head. Neither produces a redirect response at all, so the chain is empty while the visitor still ends up on a different website. Checking where the browser finally landed catches every mechanism, because all of them change the final address.

The second change is to compare at the level of the registrable domain instead of the exact hostname. Almost every website redirects its bare domain to the www version, and every website should redirect insecure requests to the secure one. Comparing hostnames flags both of those as off-site and produces constant false alarms. Comparing registrable domains treats them as the same website and stays quiet, so the only thing that raises an alert is a genuine move to a different domain.

The third change is to work out domain boundaries from the public suffix list rather than by counting dots in the name. Guessing produces wrong answers for country domains such as co.uk, and it produces a more subtle error on shared hosting platforms. Two sites on the same platform host, belonging to different customers, are different websites, and a redirect from one to the other should be treated as leaving your site even though the ending of the address is identical. NorthDuty uses the full public suffix list, including the private section that covers those shared platforms, so tenants on the same host are correctly treated as separate sites.

The fourth change is to keep the redirect chain for diagnosis while ignoring it for the verdict. Recording each hop and its status is valuable when you are writing up what happened, but only for the main page navigation. If you record every redirect that any part of the page produced, advertising and analytics requests will add hops that have nothing to do with where your visitors ended up.

The last change is to report an off-site landing as its own named failure rather than folding it into a generic failed check. NorthDuty publishes a machine-readable reason alongside every result, and an off-site redirect is one of them, sitting next to reasons such as a DNS failure, an invalid certificate, a blank page, and an HTTP error. That distinction matters because the response is different. A site that is down is an engineering problem. A site that is up but answering from a domain you may no longer control is a call to your registrar and possibly a security incident.

Conclusion

A redirect is one of the few failures that can move your entire audience somewhere else while every conventional health signal stays green. The check passes because a page answered, and nobody asks whether the page belonged to you.

NorthDuty compares the address each check finally landed on against the one it was asked to visit, at the registrable-domain level so ordinary redirects stay silent, and reports an off-site landing as a distinct failure reason so you know immediately whether you are dealing with an outage or with a domain you no longer control.