Broken Link Checker for SharePoint Online

Every way of checking SharePoint Online links for a tenant, and what each one actually covers:

Approach	Covers	Checks if the target resolves	The catch
Native SharePoint Online	Nothing	No	There is no link health report anywhere in the product or the admin centre.
Microsoft's Power Platform sample	Site pages	Yes	Published as a proof of concept, needs a Power Automate Premium licence, and untouched since November 2023.
A generic web crawler	Rendered page HTML	Yes	Sees no list data, no hyperlink columns and no web part configuration, and needs an authenticated session to see anything at all.
PnP PowerShell of your own	Whatever you write	If you code it	You own the enumeration, the retry logic and the throttling budget. Practical for one site, painful across hundreds.
A commercial link scanner	Pages, lists, navigation	Yes	Licensed per admin or per tenant, and worth asking where the scan runs and what leaves your tenant.
Pattern rewrite without a scan	Known old URLs	No	Fixes links you already know are wrong. Excellent after a rename, useless when you do not know what is broken.

That last row is the one most articles quietly conflate with the others. Replacing a known URL prefix and discovering which links are dead are different jobs, and most tooling does one of them well. If you already know the old address because a site or tenant was renamed, skip the auditing entirely and go straight to finding and fixing broken SharePoint URLs. The rest of this page is for the harder case, where nobody can tell you what is broken.

What counts as a broken link in SharePoint Online?

A broken link is one that no longer reaches the content it was written for. In SharePoint that covers four different situations with four different fixes: the target was deleted, the target moved, the target still exists but the reader has no permission to it, or the address itself was never valid. Only the middle two are common, and only one of them is fixed by editing links.

This matters because a scanner reports status codes, and a status code is a symptom rather than a diagnosis. A tool that hands you nine hundred 404s has told you almost nothing about what to do next.

Microsoft has not shipped a link checker, and says so

The gap is not an oversight you have missed in a settings page. Asked directly whether SharePoint Online could scan a site collection for broken links, a Microsoft engineer answered on Microsoft Q&A:

"There is no OOB broken link checker in SharePoint Online currently."

That answer is from 2021 and it is still the second result for the question, which tells you how little has changed. The Microsoft Community Hub thread on the same question ran from November 2021 to October 2025 without anyone producing a native answer. The one option Microsoft does publish is a sample gallery Power Platform solution labelled a proof of concept, scoped to SharePoint pages, gated behind Power Automate Premium, and last modified in November 2023.

So every real option is something you build or something you buy. Both of them run into the same two walls, and neither wall gets much coverage anywhere.

Wall one: a 404 is not a diagnosis

Before you rewrite a single link, work out which of these you are looking at. The order matters, because the cheap fixes are at the top.

The target is in a recycle bin

SharePoint Online keeps deleted items for 93 days, and that window is the total across the site recycle bin and the site collection recycle bin rather than 93 days in each. Inside it, restoring the file to its original path repairs every link pointing at that file at once. One restore beats editing four hundred links, and it preserves the version history that a rewrite cannot give back. Worth knowing as well: when a file is moved with Move to, it stays in the source site's recycle bin after the move completes, so a link to the old path is broken while the content is sitting there recoverable.

The target moved and the link was absolute

This is the case a link rewrite is actually for. The content exists, the address changed, and a pattern replacement across pages and columns is the efficient fix. It is also the only one of the four where a bulk find and replace is the right instrument.

The reader lacks permission

This is the false positive that makes link reports untrustworthy, and it cuts both ways. A scan authenticated as a tenant admin resolves targets your users cannot open, so those links pass the audit and still generate complaints. Run the check as an ordinary member of the audience if you want to know what the audience experiences. Conversely, plenty of reported failures are permission trimming rather than rot, and editing those links makes nothing better.

The address was never valid

Hand typed paths, links copied out of a desktop sync folder, and URLs pasted from an email client that mangled them. These never worked and no amount of pattern matching will find them, because there is no old value to match on. They surface only from a scan that actually attempts the target.

Wall two: a tenant-wide scan is a bulk operation, with a bulk operation's budget

Checking whether a link resolves means a request per link. Twenty thousand links across a few hundred sites is twenty thousand requests on top of the enumeration needed to find them, and SharePoint Online meters that. Microsoft's own throttling guidance sets out what you are spending:

• A single user account is limited to 3,000 requests in any five minute window.
• An application gets a resource unit budget per tenant, starting at 1,250 units a minute for tenants under 1,000 licences and reaching 6,250 a minute at 50,000 licences and above.
• Through Microsoft Graph those units are priced per call: one for a single item read, two for a multi item query or any write, and five for anything touching permissions, which is why a link audit that also resolves permissions gets expensive fast. CSOM and REST have no published per-call price, generally cost more units than Graph for the same work, and are subject to further internal limits on top.
• Exceed the budget and you get HTTP 429 or 503 with a Retry-After header. Throttled requests still count against your limits, so retrying hard makes the problem worse rather than better.
• Keep failing and the application can be blocked outright, which Microsoft notifies through the Message Center.

Two details are worth designing around. SharePoint Online does not support the IETF RateLimit headers, so Retry-After is the only signal you get and a tool that ignores it is simply guessing. And Microsoft prioritises decorated traffic: calls that identify themselves with an application ID and a user agent in the documented ISV|Company|App/Version form are treated better than anonymous ones. A script you wrote in an afternoon is almost certainly undecorated.

The practical consequence is that a full tenant link validation is not something to run at 10am on a Tuesday. Microsoft is explicit that throttling is likelier during business hours and that off peak means nights and weekends in your tenant's own region.

It is a fair question to ask any tool how it paces itself. ShareMaster caps its own CSOM round trips at 1,150 a minute per site and pauses for a full minute when it reaches that ceiling, which is deliberately inside the smallest per-application allowance Microsoft publishes. A script that fires requests as fast as the network allows has no such brake.

See what Report Master exports if what you need first is the denominator: a list of what exists, per library, with the server relative path of every item.

Scan a sample, not the estate

Given the budget, whole-tenant validation is usually the wrong first move. Rank your scope instead, and check in this order:

1. Hub and intranet landing pages. Highest traffic, highest embarrassment, smallest number of links. This is where a dead link costs you credibility.
2. Anything migrated in the last year. Migrations and renames are where absolute URLs go stale in bulk, so the hit rate here is far above baseline.
3. Policy and procedure libraries. Low traffic, high consequence. A dead link in a compliance document is found by an auditor rather than by you.
4. Hyperlink columns in large lists. Cheap to enumerate because the URL is a field value rather than buried in markup, and they are rarely reviewed by anyone.
5. Everything else, on a schedule, off peak.

Spreadsheets deserve a separate pass. A workbook can reference another workbook, and that relationship is recorded inside the file rather than in SharePoint, so no amount of list or page scanning will reveal it. ShareMaster's Excel link report reads those targets out of .xlsx files directly and lists the absolute http, https and file:// targets it finds, which is the only way to see the link graph your finance team has built. It reports the targets; it does not test whether they resolve, so treat the output as the input to a check rather than the check itself.

What the fix costs you

Once you know which links genuinely need rewriting, the remaining question is what a bulk rewrite does to the items it touches, and this is the part vendors tend not to lead with.

Writing a field value through the ordinary update path stamps the modified date and the editor on the item. Do that across four thousand list items and you have moved four thousand items to the top of every Recent view, potentially triggered alerts and flows attached to the list, and overwritten a column that somebody's retention or reporting process may depend on. The problem is not specific to any one product: it is how the write path behaves, and at least one commercial link fixer documents plainly that preserving the last modified date and editor during a replacement run needs site administrator rights and calls it a SharePoint API limitation.

Replace Master is no exception and it is worth saying so plainly: its column pass writes through the standard update call, so the items it changes get a fresh modified date and a fresh editor. Two habits make that survivable. Run in report mode first and read the output: Replace Master has a report only mode that produces a CSV of every match with the item, the old value, the new value and the occurrence count, without writing anything. And keep the pattern narrow. A replacement keyed on a full URL prefix is safe; one keyed on a bare site name will match prose, and a literal substring replacement has no idea it is inside an anchor tag rather than a sentence.

Stop generating the next batch

Auditing link health repeatedly is a symptom. Three things reduce how much there is to find:

• Relative paths inside a site. A link written as a path below the site root survives a site rename. An absolute one does not. This single habit removes most self-inflicted breakage.
• The Document ID service, activated everywhere. It gives each document a stable identifier and a redirect address of the form /_layouts/DocIdRedir.aspx?ID=, resolved through search rather than by path, so the link survives a move. The catch is that it is per site collection: activate it on every site collection you move content between, because a document landing somewhere the service is not enabled loses its ID. And because resolution goes through search, a freshly moved item is only reachable once it has been reindexed.
• Treat links as a migration deliverable. Capture the link inventory before a move rather than after, so the replacement pass has a known starting point. The pre-migration site inventory guide covers what to capture, and updating SharePoint URLs after a tenant rename covers the pass itself.

Frequently Asked Questions

Does SharePoint Online have a built-in broken link checker?

No. There is no native report, no admin centre page and no scheduled job that reports link health. Microsoft confirmed the gap on its own Q&A site and has not closed it since. The only option Microsoft publishes is a proof of concept Power Platform solution that covers SharePoint pages and requires a Power Automate Premium licence.

Why does a link checker report links that work fine for me?

Because the scan runs as one identity and the reader is another. A scanner signed in as a tenant admin resolves content a permission trimmed reader cannot, so it reports a healthy link where the reader hits a wall. Run the reverse check too: the links your users complain about are often intact and simply not shared with them.

Will a bulk link rewrite change Modified By on every item it touches?

Assume yes unless the tool documents otherwise. Writing a field value through the normal update path stamps the modified date and the editor, which moves every touched item to the top of Recent and can fire alerts and flows. Check what your tool does before you run it across thousands of items, and prefer a narrow pattern over a broad one.

How long do I have to restore a deleted file instead of rewriting the link?

93 days from deletion, counted across both the site recycle bin and the site collection recycle bin together rather than 93 days in each. Inside that window, restoring the file to its original path fixes every link pointing at it at once, which is almost always less work than editing the links. The indexed recycle bin search is how you find out whether the target is still there.

Can I check links inside Word and Excel files stored in SharePoint?

Only by reading the file format itself, because those hyperlinks live inside the document package rather than in SharePoint metadata. A scan of list and page content will not see them. Spreadsheets are the worst offenders, since a workbook can hold links to other workbooks that nothing in SharePoint records.

Try ShareMaster free for 14 days