A short link hides its destination, which is the whole point, and also the reason shorteners attract people with something to hide. The safety warning page exists so a visitor who clicks a link to a phishing site sees a wall before they see the site. This is how the decision behind that wall is made.
When a destination is checked
Three times.
On creation. Before a link is saved, the destination goes through the checks below. A destination that fails is still saved, but the link is marked and the warning shows from the first click.
On a schedule. Destinations change. A page that was a landing page in March can be a credential harvester in June after a domain lapses. Every destination is rescanned on a rolling schedule, more often for links that get more traffic.
On report. A visitor or a mail administrator can report a link from any interstitial page or from /report. A report triggers an immediate rescan and a human look if the scan is clean.
What the scan looks at
- Threat lists. The destination and every hop in its redirect chain are checked against published malware and phishing lists. A hit here is decisive.
- Redirect chains. A destination that bounces through four domains before landing is not always malicious, but it is usually hiding something, and it lowers the score.
- Domain age and reputation. New domains with no history are treated with more suspicion than a ten-year-old one, particularly when the page asks for credentials.
- Page signals. Login forms that post to a different domain, obfuscated scripts, and content that impersonates a known brand each add to the score.
- Your own blocklist. Workspaces can block domains outright, which is what agencies use to stop a client's competitor ever appearing on a client's short domain.
A threat-list hit flags the link on its own. Everything else contributes to a score, and the score has to clear a threshold before the warning appears. The threshold is set so that a false flag is rare and a missed one is rarer.
Why the redirect never waits for a scan
A scan takes anywhere from a hundred milliseconds to several seconds. A redirect answers in about twenty-four. Putting one in front of the other would make every link slow to protect against a case that is decided long before the click.
So the redirect only reads a stored verdict. If the verdict is "flagged", the visitor gets the warning page, which shows the threat categories, the full destination URL, and a choice: go back, or proceed anyway. If the verdict is "clean" or "unknown", the redirect goes straight through.
When the scan is wrong
It will be, occasionally. A legitimate login page on a young domain can trip the score. When that happens:
- The link owner sees the flag on the link's page in the dashboard, with the reasons.
- They can request a review, which puts the link in front of a person.
- A cleared link is allow-listed, so the schedule does not flag it again for the same reasons.
Visitors who choose "proceed anyway" are counted separately in analytics, so an owner can see how much traffic a flag is costing while a review is pending.
What we do not do
We do not fetch destinations from the visitor's IP, inject anything into the destination page, or share the URLs we scan with anyone. The scan runs from our own infrastructure against our own copy of the threat lists, and the only output is the verdict.