How to Verify and Resolve False Positives and False Negatives in Broken Link Reports

Last updated: 2026-10-08

Learn why some links may appear as false positives or false negatives in the Broken Link Manager report. Understand how the SharePoint Essentials Toolkit relies on HTTP status codes, how to verify them with browser developer tools (F12), Windows Server settings (IE ESC, firewalls, group policies), and common causes such as authentication, trusted sites, and redirects.

Overview

The SharePoint Essentials Toolkit's Broken Link Manager validates links by reading the HTTP status code returned by the target web server. The status code is what the report uses to mark a link as broken or valid — not the visible content of the page.

This means a link can occasionally show as broken when it loads fine in your browser (a false positive), or show as valid when the destination page actually displays an error (a false negative). This article explains why this happens and how to verify the result yourself using your browser's developer tools.

How the Toolkit Decides if a Link is Broken

When the toolkit checks a link it sends a request to the destination URL and reads the HTTP status code returned by the web server:

  • 2xx (e.g. 200 OK) — treated as valid.
  • 3xx redirects — followed and the final status code is used.
  • 4xx (e.g. 404 Not Found, 403 Forbidden) and 5xx (e.g. 500 Server Error) — treated as broken.

The toolkit does not parse the HTML body of the response. If a server returns 200 OK together with a "Page Not Found" or custom error page, the link is reported as valid. This is the most common cause of false positives in modern web applications and SPAs (Single Page Applications) that handle missing routes on the client side.

Verifying the HTTP Status Code with Browser Developer Tools

To confirm whether the toolkit is reporting the link correctly, check the actual HTTP status code returned by the server:

  1. Open the link in your browser (Edge, Chrome, or Firefox).
  2. Press F12 to open Developer Tools.
  3. Click the Network tab.
  4. Tick Disable cache and Preserve log.
  5. Reload the page (Ctrl+F5).
  6. Locate the top entry in the request list — this is the document request for the URL itself — and look at the Status column.

Browser developer tools showing HTTP 200 status for a SharePoint page that displays Page Not Found

In the example above, the page displays "Page not found" but the server actually returned 200 OK. Because the toolkit relies on the status code, it (correctly) reports this link as valid even though the page content is an error message. This is a server-side behavior, not a defect in the toolkit.

Common False Positive / False Negative Scenarios

Link shows as valid but the page is actually broken

  • Site uses a SPA framework (React, Angular, Vue) that returns 200 OK for unknown routes and renders a "not found" view in JavaScript.
  • Server is configured to return a custom error page with status 200 instead of 404.
  • Reverse proxy or CDN rewrites error responses to a generic landing page with 200.

Link shows as broken but the page loads fine in your browser

  • The destination requires authentication and returns 401 or 403 when the toolkit requests it without your browser session.
  • The destination blocks non-browser user agents or bots (returns 403 or 429).
  • A firewall, proxy, or web filter on the machine running the toolkit blocks the request before it reaches the server.
  • Internet Explorer Enhanced Security Configuration (IE ESC) on Windows Server blocks the request (see below).
  • TLS/SSL handshake fails because the server uses a certificate not trusted by the machine.

Windows Server: Required Configuration

If you installed the SharePoint Essentials Toolkit on a Windows Server machine, two items are commonly responsible for false negatives:

1. Disable Internet Explorer Enhanced Security Configuration (IE ESC)

The toolkit uses the underlying Windows networking stack, which respects IE ESC settings. When IE ESC is enabled, requests to sites outside the Trusted Zone may be blocked or downgraded, causing valid links to be reported as broken.

  1. Open Server Manager.
  2. Select Local Server in the left pane.
  3. Click the link next to IE Enhanced Security Configuration.
  4. Set IE ESC to Off for both Administrators and Users.
  5. Click OK and re-run your link validation job.

2. Verify Group Policies and Firewalls

Make sure nothing on the machine is intercepting outbound HTTP/HTTPS requests:

  • Confirm that no Group Policy Objects (GPOs) restrict outbound network access for the user account running the toolkit.
  • Confirm that the Windows Defender Firewall (or a third-party firewall such as Symantec, McAfee, CrowdStrike, etc.) is not blocking the toolkit's executable.
  • If the machine is behind a corporate web proxy, ensure proxy settings are configured at the system level so the toolkit can route requests correctly.
  • Check with your network team whether SSL inspection or web filtering appliances are altering responses or returning generic block pages with a 200 status.

Recommended Verification Workflow

  1. Identify a link the report flags as suspicious.
  2. Open the link in a browser on the same machine running the toolkit.
  3. Press F12, open the Network tab, and reload the page.
  4. Compare the Status column to what the report shows.
  5. If they match, the toolkit is behaving correctly — the issue is on the destination server.
  6. If they differ, check IE ESC, firewalls, proxy, and authentication on the machine running the toolkit.

Summary

The Broken Link Manager is only as accurate as the HTTP status codes returned by the target web servers. Use your browser's developer tools (F12 → Network tab) to confirm the real status code, and on Windows Server make sure IE Enhanced Security Configuration is disabled and that no firewall, group policy, or proxy is blocking the toolkit's requests.

Common Causes

  1. Incorrect authentication type — In some cases, you need to switch from Office 365 or Default SharePoint Authentication to Web Browser Authentication. Check the log files for "unauthorized" errors, which may indicate a federated environment or single sign-on that requires Web Browser Authentication. See the User Manual for more information about Authentication Types.

  2. Missing Trusted Sites entry — Make sure your SharePoint environment is added to Internet Options → Trusted Sites.

  3. Redirect issues — Some pages may return a 404 initially and then redirect to a valid page. Use a network traffic tool such as Fiddler to inspect the redirect chain. This may indicate a DNS issue or an incorrect HTTP redirect code. We are working on providing more descriptive status codes for these situations.