Working links appear as broken in Insytful
Page last updated 11 February 2026
Sometimes Insytful may flag a working link as broken even though it opens correctly when you paste it into your browser. Below are reasons a link may be considered broken.
How Insytful checks if links are 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:
- Error responses
- Working internal and external links
- Missing images
- Orphaned pages
- Invalid link formats
- Access issues
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.
What “broken” means in Insytful
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 occaisionally, a link can be classified as broken in Insytful, but it is still usable in a broswer. Below are common reasons why working links are flagged as broken in Insytful.
Common reasons a link is flagged as broken
1. Login or authentication is required
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.
2. Microsoft Safe Links
Insytful struggles with Microsoft Safe Links because they are designed to get in the way of normal link reading. Microsoft may detect a suspicious link and respond with CAPTCHA challenges, 403 Forbidden errors, or bot blocking.
Therefore, Insytful cannot follow the redirect. Using Safe Links on your website is a poor practice for several reasons.
Why are using Safe Links on your website bad practice?
Safe Links are designed to protect users clicking links in Outlook 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.
3. IP or bot blocking
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.
4. JavaScript-rendered pages
Some modern websites only load content after JavaScript runs.
Insytful does not execute JavaScript and checks the initial server response only.
In a browser:
JavaScript runs and the page appears normal.
In Insytful:
The server returns little or no content, so the link appears broken.
5. Temporary server or network issues
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.
6. Redirect chains or conditional redirects
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.
7. Restricted content (Geo, firewall, or policy-based)
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.
What you can do to fix incorrectly reported broken links
Verify the context
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 ask Insytful to mark as resolved.
Future feature: Users will be able to mark links as resolved and to be ignored in the broken link count.
Use public URLs where possible
For content meant to be publicly accessible:
- Avoid authentication-gated links
- Use stable, canonical URLs
- Minimise redirect complexity
Recheck later
If you suspect a temporary issue:
- Re-run the analysis
- Check whether the issue persists across scans
Mark or exclude known exceptions
For links that are intentionally restricted:
- Document them internally
- Exclude them from “broken link” KPIs where appropriate
Summary
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.