Almost no intranet fails for technical reasons. It fails for three predictable ones: nobody owns the content, the structure mirrors your org chart instead of the jobs people are trying to do, and search was never configured. Staff stop using it because it stops being the fastest way to get an answer — so they ask a colleague instead. All three are fixable without rebuilding from scratch, and none of them is a software problem.
How trust drains away
Intranets rarely die in a single moment. They decay in a predictable order, and by the time anyone notices, staff have already built workarounds.
- 01Launcheverything current, leadership announces it, traffic spikes
- 02Month 3the first outdated policy is found; nobody is sure who updates it
- 03Month 6news feed stalls, search returns three versions of the same form
- 04Month 9staff bookmark the shared drive and ask colleagues instead
- 05Month 12the intranet is a homepage people click past
- 06Fixedowners, task-based structure and tuned search bring the answers back
The important step is the first stale thing. Once people find one outdated document, they stop trusting all of it — because they cannot tell which pages are current. Every later failure follows from that loss of trust.
1. Nobody owns the content
At launch, everything is current. Six months later the policy library has three versions of the same document and the news feed stops at last winter. Once people find one stale thing, they stop trusting all of it — and they go back to asking a colleague.
The fix: every area gets a named owner and a review date. Not a committee. One person, visible on the page.
Making that work in practice:
- Put the owner and "last reviewed" date on the page itself. It tells readers the content is maintained, and it tells them who to ask when it is not.
- Set review cycles by content type. Policies yearly, procedures every six months, contact and team pages quarterly. A simple Power Automate flow can remind each owner when their pages are due, the same way an expiry reminder works.
- Have one version of each document. Link to the controlled copy in the policy library rather than uploading copies to every department site. Copies are where the three versions come from.
- Archive, do not just add. Part of each review is removing what is no longer true. An intranet with fewer, current pages beats one with everything.
Owners need to be people with the knowledge, not the people with spare time. The payroll officer should own the pay pages; the communications coordinator should not own everything because they launched the site.
2. The structure mirrors your org chart
Departmental navigation makes sense to the people who drew it and nobody else. Staff do not think "I need something from People & Culture". They think "I need to book leave".
The fix: structure around tasks and lifecycle — starting here, working on a project, going on leave — and let departments own the content underneath.
The difference is easiest to see side by side:
| Staff member's question | Org-chart navigation | Task-based navigation |
|---|---|---|
| How do I book leave? | People & Culture, then Forms, then Leave | Time off, then Book leave |
| Where is the project kick-off template? | Operations, then Project Management, then Templates | Running a project, then Starting a project |
| What do I do on my first day? | Spread across HR, IT and Safety pages | Starting here |
| Who approves my expense claim? | Finance, then Policies, then Expenses | Money and expenses, then Claiming expenses |
The task-based version does not remove departments; it hides them. People & Culture still owns the leave content, but the reader never needs to know that to find it.
For construction and engineering firms, the lifecycle framing usually extends to projects — tender, mobilise, deliver, close out — with project sites created from a template so every job looks the same. For for-purpose organisations, it often includes volunteer and funder-facing material that lives outside the department structure entirely.
3. Search was never configured
Out of the box, SharePoint search returns documents ranked on very little. Without metadata, content types and a few promoted results, searching "expenses" returns 40 files and the right one is eleventh.
The fix: metadata on the content types people actually search for, and promoted results for the top twenty queries. You can find those queries in the search analytics you already have.
What that involves:
- Find the top queries. Microsoft Search usage reports in the Microsoft 365 admin centre and site-level usage analytics show what people search for and what returns nothing.
- Create bookmarks for the top twenty. Bookmarks — the modern form of promoted results — pin the right answer to the top for a given keyword. "Expenses", "leave", "timesheet" and "org chart" are almost always on the list.
- Add metadata to the documents people hunt for. Policies get a type, an owner and a review date; forms get a category. That lets search filter and lets pages roll content up automatically.
- Remove duplicates and drafts from search. Old versions in someone's working folder will outrank the controlled copy if they have a better title.
None of this is visible at launch, which is exactly why it gets skipped. It is also the cheapest of the three fixes.
The test that predicts adoption
Pick five things a new starter needs in week one. Time how long each takes to find. If any takes more than thirty seconds, the intranet is not finished — regardless of how it looks.
Illustrative times, not measured data, to show how to read the test. Anything past thirty seconds is a fix to make. Run it yourself with a stopwatch.
Do it with someone who did not build the intranet — ideally an actual new starter. Watch where they click first; that tells you how they expect the structure to work. Record the times, fix the slowest, and run it again. It takes an hour and gives you a better roadmap than most intranet strategies.
Rebuild or repair?
Most failed intranets do not need a rebuild. If the platform is modern SharePoint and the problems are the three above, repair is faster and cheaper: assign owners, restructure navigation, tune search, archive the dead content.
A rebuild makes sense when the site is on classic SharePoint pages, when the information architecture is so tangled that repairing it means moving most content anyway, or when the business has changed shape — a merger, a new division, a move from one office to several sites. Our breakdown of what a SharePoint intranet costs covers how those bands are priced; a full build typically runs $10,000–$45,000.
- Run the five-item, thirty-second test and record the times
- Name an owner and review date for every top-level area
- Archive anything not reviewed in the last year
- Redraw the navigation around tasks, with departments underneath
- Add bookmarks for the top twenty search queries
- Pick the day the shared drive becomes read-only, and announce it
The last item matters more than it looks. As long as the old shared drive stays writeable, the intranet is a second place to look, not the place to look. Turning off the old path is the single most effective adoption step, which we cover in getting adoption in the first 30 days.
What to do next
Run the thirty-second test this week. It needs a stopwatch and one new-ish staff member, and it will tell you which of the three failures you have. If it is ownership, start naming owners; if it is structure or search, the fixes above are a few weeks of work rather than a new project. If you want an outside view on whether to repair or rebuild, our SharePoint intranet service page explains how we approach both.
An intranet is not a publishing project. It is a findability project.
Want the version for your business?
Work out what manual processes are costing you — three minutes, no contact details needed.
Work out the cost