Why SharePoint intranets rot (and what to do about it)
What 'SharePoint intranet health' really means and the four slow-burning issues that age any M365 hub.
Why SharePoint intranets rot (and what to do about it)
A SharePoint intranet does not fail loudly. It rots quietly. The link on the homepage that worked last quarter breaks, the section that someone owns stops getting updates, the alt-text fields never get filled in, and a page the auditors wanted last year is now a 404. Six months later the audit readiness deck is a fire drill.
If you have ever inherited a SharePoint hub that looked fine on launch day, this post is for you. We will walk through what SharePoint intranet health actually means, the four slow-burning issues that age every M365 intranet, and the practical second-order effects that make them a compliance problem rather than an IT problem.
What "intranet health" really means
Most teams talk about intranet health as if it were one thing. It is not. There are four distinct, partially-independent dimensions that all have to be working for a hub to feel recent, and only one of them has anything to do with infrastructure.
- Reachability: every internal link still resolves, and the assets
underneath it (documents, images, embedded web parts) still load.
- Freshness: every page still reflects its owner. Staleness is a
signal that the owner system is broken, not the page.
- Accessibility: the WCAG 2.1 AA trail is intact — alt text, contrast,
headings, form labels. Regressions here are the most common source of ad-hoc audit findings.
- Configuration drift: the M365 baseline (sharing, guest links,
inheritance, label policies) still matches the policy document that the security team last approved.
The trap is to treat each of these as a technical problem to be solved once. They are not. They are four slow-burning second-order problems, and they all share a single root cause: nobody is paying the bill to keep them from decaying.
The four issues that age every hub
Empirically, here are the issues we see surface in 100% of tenants we audit — most of them within months of go-live, all of them within a year.
1. Broken & redirected links
Things move in SharePoint. Pages get renamed, document libraries get re-orged, hub sites get re-parented. The English Read more link, hard-coded into a hundred welcome pages, did not get the memo. After a year, a noticeable fraction of the navigation is dead.
This is not a SharePoint problem; links rot at a rate of roughly 25% per year across any web estate that you do not police. The fix is a crawl that visits every page and flags the ones whose referring links now 404.
2. Stale & missing content
Pages have an owner. Owners move on, get re-orged, or stop caring. The page keeps rendering and the nav still points to it. Six months later a new hire finds it, sends an email, gets no answer.
Site columns are the right primitive here. Every page should carry a Last reviewed date and an Owner id, and the workday a week before that date should email somebody who still has the keys.
3. WCAG regressions
Accessibility is the loneliest part of hub maintenance. The original author carefully wrote alt text on every image. New content gets added by people who do not know that, and the alt-text regression creeps in by quarter-over-quarter.
The audit-grade answer is per-page evidence: alt-text, contrast, heading order, form labels — pulled into a CSV that maps cleanly onto VPAT 2.4 and the company's accessibility statement.
4. Config drift
The hardest of the four to detect, and arguably the most expensive when it goes wrong. Guest-link sprawl, broken inheritance, label policies dropped during a tenant-to-tenant migration — all invisible until an auditor looks under the hood.
The fix is a recurring diff against the baseline that was approved on the security review. Anything that drifts off-baseline is a config ticket, not a content ticket.
The compliance angle
If you are the SharePoint admin or the compliance lead, this is the part that matters to you: every one of the four issues above is a finding on a SOC 2, ISO 27001, or internal audit checklist. The auditor does not care whether the page looked fine on launch day. They care whether the current state of the hub is the state you said it was in your controls.
What that means in practice: SharePoint intranet health is a compliance surface, not an IT surface. The teams that treat it as a compliance surface — by giving it the same continuous-monitoring treatment they already give to endpoint posture or identity — are the teams that walk into the audit and walk out of it the same day. The teams that treat it as an IT project are the ones rewarming last quarter's heat-map the night before.
What to do about it (and what not to)
A useful pattern, if you have just inherited a tenant or are about to:
- Pick one hub to start with. Not the whole tenant. One hub, the one
the audit team keeps asking about. Establish a baseline inside that hub.
- Crawl it. Every page, every document, every web part. Capture what
the hub says about itself as evidence.
- Diff against the baseline. What links break? What pages are stale?
What alt text is missing? What config is drifted?
- Ship the four scans. Broken links, stale content, WCAG, config drift.
The same four today, every week.
- Make the report the deliverable. Compliance does not need a tool;
they need a weekly digest with a paper trail. The tool is what produces the digest.
The thing not to do is treat the problem as a one-time SharePoint cleanup. That is a project with a deadline; this is a process that needs a cadence. The cadence is what stops the rotting.
Where Wardwell fits
We built Wardwell for the SharePoint admin who already knows the four issues above and wants the same continuous monitoring for the hub that they already have for endpoint and identity protection. Read-only Microsoft Graph scope, six permissions, never broader. Broken-link crawl, stale-page queue, WCAG 2.1 AA evidence, and a config-drift diff — end to end. The weekly digest is the same report your auditor will want.
If you want to see it on a tenant of your own, [run a one-shot scan](/scan) — sign in with Microsoft, point us at one site, and the next digest lands in your inbox next Monday.