A Link Can Be Up and Still Be Wrong

Availability and destination answer different questions

An availability check commonly asks questions such as:

• Did the server respond?
• Was the response fast enough?
• Did it return an expected HTTP status?
• Could the page be reached from the monitoring location?

A destination-aware check asks additional questions:

• How many redirects occurred?
• Which domains appeared in the redirect chain?
• Where did the visitor ultimately land?
• Does the final domain match the business's expected destination?
• Did the path change since the previous observation?

How a trusted link can begin going somewhere else

Not every destination change is malicious. Redirects evolve for ordinary operational reasons: campaigns end, vendors migrate platforms, landing pages are reorganized, tracking parameters change, or teams add a preferred www host. These are often legitimate changes, but they still deserve visibility because they can affect customer experience and attribution.

More concerning changes can result from:

• A compromised redirect account or shortened-link service
• An expired domain being registered by someone else
• A partner changing a destination without notifying your team
• An affiliate or tracking path being altered
• A DNS or hosting configuration pointing to the wrong service
• A campaign link being reused after its original purpose ended

The visible link does not need to change for any of this to happen. A printed QR code, old email, social profile, or partner page can keep presenting the same trusted URL while the redirect behavior behind it changes.

Which links deserve destination-aware monitoring?

Start with links whose destination matters after the moment they are published. A practical inventory usually includes:

Prioritize by impact rather than volume. A permanent QR code on thousands of packages may deserve attention before a temporary internal link. A branded billing link may matter more than a low-traffic blog reference.

What useful redirect monitoring should record

An alert saying only that a link changed forces the responder to reconstruct the incident. Useful monitoring should preserve enough context to make the first investigation faster:

1. Original URL: the exact trusted link that was checked.
2. Expected domain: the destination the business considers legitimate.
3. Observed final URL: where the browser would ultimately land.
4. Redirect chain: the intermediate hosts and steps between the two.
5. Timestamp: when the behavior was observed.
6. Change context: whether the result is new, repeated, expected, or suspicious.

This evidence does not automatically prove malicious intent. It gives marketing, ecommerce, security, and operations teams a concrete observation to compare with campaign records, vendor changes, DNS configuration, and approved destinations.

A practical response plan for an unexpected destination

When a trusted link reaches an unexpected domain:

1. Confirm the original URL and reproduce the redirect from a controlled environment.
2. Compare the observed destination with the approved campaign or business destination.
3. Review recent changes to DNS, redirect services, campaign platforms, and partner accounts.
4. Pause affected campaigns or public links when customer exposure may continue.
5. Contact the responsible vendor, partner, or account owner with the redirect evidence.
6. Restore the intended destination and continue checking for recurrence.
7. Document the cause and add similar high-trust URLs to the monitoring inventory.

The urgency depends on the destination and the business context. A routine move from an apex domain to its www host is different from a branded campaign link reaching an unrelated login page. Monitoring helps surface the change; a responsible owner still evaluates what the change means.

Point-in-time checking is useful. Continuous monitoring closes the gap.

Manually checking an important link before a launch is a good practice. The limitation is time: the result describes what happened during that check. A destination can change later because of a platform update, account compromise, expired dependency, vendor action, or configuration mistake.

Continuous redirect monitoring repeats the observation, compares the result with what is expected, and gives the responsible team a chance to investigate before customers become the monitoring system.