Working links appear as broken in Insytful

Sometimes Insytful may flag a working link as broken even though it opens correctly when you paste it into your browser. These are classified as false positives.

Below are reasons a link may be considered broken.

When Insytful scans links, it does not open them in the same way a human user does in a browser. Because of this, Insytful may see a different result than you do.

To detect a broken link, Insytful scans websites looking for:

• Malformed URLs
• Response codes for request

To determine whether a link is broken, Insytful sends an automated request to the URL, checks for valid responses (status codes, redirects, accessibility), and inspects the link without logging in, clicking buttons, or running scripts.

A broken link in Insytful means the scan could not reliably access a link using automated checks. Most often, the broken link is because of one of the reasons above. But occasionally, a link can be classified as broken in Insytful, but it is still usable in a browser. Below are common reasons why working links are flagged as broken in Insytful.

1. Login or authentication is required
2. Microsoft Safe links
3. IP or bot blocking
4. JavaScript links
5. Temporary server or network issues
6. Redirect chains or conditional redirects
7. Restricted content (Geo, firewall, or policy-based)

If a page requires a user account, a session cookie, SSO or token-based authentication, Insytful cannot access it. Lack of access to the destination URL will flag the link as broken.

What you see in a browser: The page loads because you’re logged in.

What Insytful sees: A login page or an access denied response, which will flag as broken.

Insytful struggles with Microsoft Safe Links because they are designed to get in the way of normal link reading. Organisations using SafeLinks may detect a suspicious link and stop it from working at any time. it also takes away any analytics tracking you might be using on your site.

Insytful cannot follow Microsoft Safe links. Using Safe Links on your website is a poor practice for several reasons.

Safe Links are designed to protect users from clicking on malicious links in emails. They're not designed to be permanent website URLs or shareable web resources.

In addition to looking suspicious and possibly damaging user trust, they are also:

• Not accessible. They are encoded and unreadable for assistive technology
• Terrible for SEO because they obscure the link destination
• Slow down page load speeds due to an extra layer of page redirects
• Mess up analytics data making reporting a nightmare

On a website, you should always use a clean, HTTPS destination URL. If you need tracking, standard UTM parameters are a good alternative.

Some websites block automated traffic, non-browser user agents, and requests from cloud or data centre IPs.

These security measures are common on enterprise platforms, banking or government sites and sites protected by services like Cloudflare or Akamai.

The result is Insytful’s request is rejected even though normal browser traffic is allowed.

Some sites rely on JavaScript to make elements clickable, for example on buttons.

This is terrible practise for accessibility and SEO as screen readers, other assistive technologies and crawlers cannot see the links and therefore follow them.

As these links don't exist on page load, Insytful cannot follow and check them. Read more on why JavaScript links are a bad practise.

Websites can intermittently return timeouts, 5xx server errors and rate-limit responses.

If this happens during Insytful’s scan, the link may be flagged as broken even if it works later.

Some links redirect multiple times or redirect differently based on location, device, or headers.

Insytful may not follow the same redirect path as your browser, resulting in a failed check and a broken link.

Some pages are Geo-restricted, limited to internal networks or accessible only from specific regions or IP ranges.

If Insytful’s scan originates outside that allowed range, access will fail.

To clarify if a link is broken, check if:

• A link is behind a login?
• Is the link only meant for internal users?
• The link is protected by security tools?

If the answer is yes, the link isn't broken, so you can ignore it or mark it as a false positive in Insytful. A false positive is reporting something as broken, when in reality it is working correctly.

For content meant to be publicly accessible:

• Avoid authentication-gated links
• Use stable, canonical URLs
• Minimise redirect complexity

If you suspect a temporary issue:

• Re-run the analysis
• Check whether the issue persists across scans

For links that are intentionally restricted:

• Document them internally
• Exclude them from “broken link” KPIs where appropriate
• Mark as a false positive within the Insytful UI

A link can work perfectly in your browser but still appear broken in Insytful because:

• Insytful checks links as an automated system
• It does not log in, run JavaScript, or bypass security rules
• Many modern websites behave differently for automated requests

In most cases, this is expected behaviour, not a defect. If you’re unsure whether a flagged link indicates a real issue, checking how the page is accessed and who it’s intended for will usually provide the answer.