Why nobody can find anything on your intranet

A lone figure in a dark suit stands in an enormous surreal gallery beneath a bright blue sky, surrounded by hundreds of near-identical framed documents stretching impossibly into the clouds. One document glows neon yellow among the otherwise cream, orderly rows, suggesting the difficulty of finding the right information when everything looks equally authoritative.

Every organisation with an intranet eventually performs the same ritual.

Someone runs an employee survey. “I can’t find anything on the intranet” appears somewhere near the top. Everyone nods gravely. A project is formed.

Perhaps the search needs improving. Perhaps the navigation needs another go. Perhaps the homepage needs fewer tiles, or more tiles, or the same number of tiles but in a different order. Someone suggests AI, because it is 2026 and someone always suggests AI.

Things are moved around. Search is upgraded. The new navigation is launched with considerable ceremony.

Eighteen months later, someone runs another survey.

“I can’t find anything on the intranet.”

And round we go.

The problem is that organisations tend to treat findability as a technology problem. Sometimes it is. Quite often the technology is simply the place where a much messier organisational problem has chosen to make itself visible.

Before you start dragging things around the navigation again, it’s worth working out which problem you actually have.

Search matters. But it can’t perform miracles

Let’s get this out of the way first: bad enterprise search absolutely exists.

Search can be badly configured. Synonyms can be missing. Important results can be buried beneath ancient PDFs. Promoted results can point proudly to something nobody has used since Theresa May was prime minister. Pages can have titles written entirely in the language of the team that owns them.

If your expenses page is called “Expense Management Policy and Procedures” while everyone in the organisation searches for “claim expenses”, you have given your search engine an unnecessarily difficult afternoon.

As Jonathan Phillips and I put it in Digital Communications at Work, enterprise search is not Google with a lanyard.

Google has an almost unimaginably large pool of behavioural data from which to infer what you probably meant. Your intranet has Hannah from Procurement looking for the travel policy twice a year.

So yes: configure your search properly. Use synonyms. Look at what people are actually typing into the box. Write page titles for humans. Retire the promoted result for the 2018 office move.

All of that’s important.

But search can only work with what you give it. And “I can’t find anything” can mean at least five quite different things.

Five reasons employees can’t find information on your intranet

1. The information isn’t there

The simplest problem is also the one no search engine can fix. Sorry.

Someone wants to know how to request a new laptop. There is no page explaining how to request a new laptop.

They search for “new laptop”. Nothing useful appears. They try “replacement computer”. Nothing. They browse IT. They try Help. Eventually they message someone on Teams, who messages someone else, who sends them a link to a form they have inexplicably had bookmarked since 2021.

From the employee’s perspective, the intranet has failed.

This is a content gap, not a search problem. But search data can help you find it. Repeated searches with no useful result are a pretty good signal that people expect information to exist that doesn’t.

That makes zero-result searches some of the most interesting data your intranet produces. They’re people submitting content requests without knowing they’re doing it.

Does better search help? Not really. Search can tell you where the hole is. It cannot fill it.

2. It’s there, but called something unexpected

This one is more fixable.

The information exists, but the person who published it and the person looking for it use completely different language.

HR has published a page about “Family Leave”. Your employee searches for “maternity leave”.

Finance has “Travel and Expense Management”. Everyone else wants to “claim expenses”.

IT has an “End User Device Replacement Process”. Dave just wants a new laptop.

This is where search configuration, synonyms and better content design genuinely earn their keep. If hundreds of people search for “holiday” and your organisation insists on calling it “annual leave”, your search engine should be capable of holding both thoughts in its head.

But there’s a content lesson here too. Internal language has a habit of leaking into intranets. Department names, programme names, operating-model terminology and acronyms make perfect sense to the fourteen people who use them every day and considerably less sense to everyone else.

Organisations then compound this by insisting the technically correct term is the right one.

It may be. Your employees are still typing something else.

Does better search help? Yes. This is exactly the sort of problem it should help with. Better titles and content design help too.

3. It lives somewhere they wouldn’t think to look

Now things get more interesting.

The page exists. It has a perfectly sensible title. Search can probably find it.

But the employee is browsing.

Where should information about parental leave live?

Under Benefits? Policies? Working Here? Life Events? HR? People? Family?

There may be a perfectly logical answer from the perspective of the team that owns the content. Unfortunately, nobody has informed the employee of that logic.

This is how intranets end up reproducing the organisation chart in clickable form. Information is grouped according to who owns it rather than why someone needs it.

Finance owns expenses, so expenses live under Finance. IT owns collaboration tools, so guidance on Teams lives under IT. HR owns flexible working, so flexible working lives under HR.

Administratively, this is beautifully tidy. But all it asks of the employee is that they understand your operating model before they can book a train, which is simply not a thing people actually do.

Search provides an escape hatch here, but it doesn’t make the underlying structure good. And people don’t always search. They browse, particularly when they don’t know what the thing they need is officially called.

Does better search help? Sometimes. But this is fundamentally an information architecture problem.

4. Several plausible versions exist

This is where search can actively make things worse.

Someone searches for the travel policy.

Excellent news: the intranet has found it. In fact, it has found six of them.

There’s the current policy page, a PDF from 2024, another PDF attached to an old news story, a version sitting in Finance’s SharePoint site, a regional variation and a PowerPoint deck from somebody’s manager briefing.

All contain roughly the right words. All look plausible. One is correct.

Possibly.

Your search engine has done exactly what you asked it to do. It has found things matching the query. You cannot really blame it for the fact your organisation has spent seven years quietly breeding travel policies.

This is not a search failure. It is a content management failure.

Organisations accumulate information because creating content is easy and retiring it is not. A new version gets uploaded but the old one stays where it was. Teams create local copies because they don’t trust the central one to remain available. PDFs escape into document libraries and spend the next decade popping up in search results like administrative ghosts.

The result isn’t a lack of information; it’s an excess of it.

Does better search help? Potentially the opposite. It can surface all the duplication with tremendous efficiency.

5. Nobody has agreed which version is authoritative

And now we reach the problem search cannot touch.

Imagine there are three pages explaining how a particular process works. Not three old versions of the same thing. Three current versions.

Operations says the process works one way. HR describes it slightly differently. A regional team has adapted it because the central process doesn’t quite work for them.

Which one should search rank first?

There is no technical answer to that question, because the organisation has not agreed what is true.

This is the point at which “findability” stops being an intranet problem at all. You can tune search weights, tidy the metadata, redesign the navigation and put a shiny AI assistant over the top of the whole lot.

The AI assistant will still need to decide which of your three contradictory answers to believe. That isn’t artificial intelligence. That’s asking a chatbot to referee your governance dispute.

Search can only help you find the wrong answer faster.

And that distinction’s kinda critical, because all five problems feel exactly the same to the employee: I can’t find the bloody thing.

Underneath that one complaint might be a technology problem, a vocabulary problem, a structural problem, a content problem or a governance problem.

Treat them all as “search” and you can spend quite a lot of money solving the wrong one.

Intranet findability is a set of trade-offs

I’ve been working recently on information architecture for an organisation we’ve worked with, on and off, for several years.

They have an intranet. It works. People still struggle to find things.

That’s less damning than it sounds. In an organisation of any real complexity, findability isn’t a problem you solve so much as a set of trade-offs you choose deliberately.

Ten teams can have a legitimate claim on the same page. Three of them call it something different. The structure that makes perfect sense to the person responsible for maintaining the information may make no sense at all to the person who needs it once every eighteen months.

Take parental leave.

HR might think of it as a policy. A benefits team might think of it as part of the employee offer. The employee concerned may be thinking “having a baby”. Their manager may be looking for “what do I need to do when someone goes on maternity leave?”

None of these people is wrong. Which is, frankly, inconvenient.

This is why information architecture gets difficult surprisingly quickly.

You cannot simply ask people where something “belongs” and expect one correct answer to emerge. Nor can you hand the problem to the content owners, because content owners know too much. They understand distinctions, structures and organisational boundaries that ordinary employees have neither the time nor inclination to learn.

Once you have worked somewhere long enough, all sorts of absurd things start to feel self-evident. Of course Expenses sits under Corporate Services. Of course Flexible Working is in People Policies rather than Ways of Working. Of course P&C means People and Culture and not, say, something involving procurement.

Then someone joins the company and ruins everything by having no idea what any of it means.

The job isn’t to discover the perfect structure. It’s to find the compromises that create the least friction for the greatest number of people.

And to do that, you need evidence.

How to diagnose intranet findability problems

The useful question is not “How should we reorganise the intranet?”

It’s “Why are people struggling to find things?”

Different research methods let you see different bits of the problem.

Analytics and search logs show you what people do

Start with behaviour. What are people searching for? Which queries produce no results? Which searches are repeatedly reformulated? Where do people bounce backwards and forwards?

Search logs are particularly useful because they capture people expressing a need in their own language, rather than the language you’ve thoughtfully invented for them.

If 600 employees search for “payslip” every month and your payroll team calls the page “My Compensation Statement”, you have learned something.

If they repeatedly search for something that doesn’t exist, you may have found a content gap.

If they search for a policy that exists in seven places, congratulations: you may have found an entirely different problem.

Analytics tell you what happened. They don’t necessarily tell you why.

Interviews show you how people think

Talk to people and you begin to understand the mental model behind the behaviour.

What words do they use? Where would they expect something to live? What do they do when they can’t find it? Who do they ask instead?

This is often where apparently obvious organisational logic begins to wobble.

A content owner may tell you that something “obviously belongs under Operations”. An employee may reveal that they have no idea what Operations actually does.

Both are useful findings. Only one of those people is trying to find the page.

Open card sorting shows how people group things

In an open card sort, you give participants a collection of content items and ask them to group them in whatever way makes sense to them, then name the groups.

The important thing here is that you are not holding a referendum on the navigation.

If seven out of ten people put something under “Working Here”, democracy does not require you to put it there.

What you’re looking for is pattern.

Which things repeatedly end up together? Where is there broad agreement? Where do people diverge wildly? What words do they naturally use for categories?

And, often most usefully, which distinctions that seemed enormously important to the project team turn out to be invisible to everyone else?

Closed card sorting tests your proposed categories

A closed card sort starts from the other direction.

You provide the categories and ask people where they would expect particular items to sit.

Now you’re testing your homework.

If almost everyone puts an item where you expected, lovely.

If participants scatter it across five categories like confetti, also useful.

It tells you that the distinction which looked beautifully crisp on the workshop whiteboard may not survive contact with anyone who wasn’t in the workshop.

Again, the result does not tell you what you must do.

It gives you evidence.

Tree testing tells you whether people can actually navigate it

Once you have a proposed structure, tree testing lets you test the hierarchy without all the distracting furniture of an actual intranet.

Give someone a task: You want to find out whether you can work from another country for a month. Where would you go?

Then watch.

Can they reach the right destination? Do they take a direct route? Do they wander around? Does everyone confidently choose the same wrong branch?

That last one is particularly valuable. One person getting lost might be a person getting lost. Twenty people getting lost in exactly the same place is a design decision waving at you.

And it is considerably cheaper to discover this before launch than six months afterwards, when the navigation is live, the project team has disbanded and everyone has developed strong emotional attachments to the nouns.

Test the structure before you build the bloody thing.

None of these methods gives you the whole picture.

In Digital Communications at Work, we use the analogy of reconstructing an extinct animal from fossils. You rarely have a complete skeleton laid obligingly in front of you. You have fragments and traces from which you build the most plausible picture.

The same is true here.

Analytics cannot tell you about the page someone never found. Interviews tell you what people say they do, which is not always what they actually do. Card sorts strip away much of the context in which real information-seeking happens. Tree tests tell you whether people can navigate your proposed hierarchy, not whether the content waiting at the end is any good.

Every method gives you a partial view.

The useful stuff happens when you put them together.

Research still doesn’t give you the answer

This is the bit that tends to disappear from neat diagrams of the UX process.

You can run interviews, analyse search data, conduct card sorts and tree-test your proposed navigation.

At the end of all that, the computer does not flash up:

CONGRATULATIONS. YOU HAVE DISCOVERED THE CORRECT INFORMATION ARCHITECTURE.

Annoying, really. You still have to make decisions.

Research gives you evidence with which to make better compromises. It shows you where people’s mental models converge and where they don’t. It gives you grounds for pushing back when a team insists its content absolutely must have a top-level navigation item because it is Very Important Indeed. It helps you distinguish an edge case from a widespread need.

But there is no objectively perfect taxonomy sitting somewhere in the data waiting for a sufficiently diligent consultant to uncover it.

At some point, someone has to choose.

And sometimes the research takes you straight back to the organisational questions you were hoping the intranet project would allow you to avoid.

Who owns this information?

Who is allowed to change it?

Which version takes precedence?

Who decides when two parts of the organisation disagree?

Those are not search questions.

Bad search is a technology problem. Bad structure is a design problem. Duplication is a content problem. Authority is a governance problem.

To the employee, they all look exactly the same: I can’t find anything on the intranet.

That’s why curiosity is more useful than certainty here. Don’t begin with the solution you already wanted to implement and work backwards until the research agrees with you. Work out which problem you actually have.

If people can’t find anything on your intranet, don’t start by moving the navigation around.

At Lithos Partners, we help large and complex organisations work out what is actually going wrong before jumping to the solution: using research, analytics, card sorting, tree testing and good old-fashioned conversations with the people who have to use the thing.

And if you’re not quite ready to have that conversation, Jonathan Phillips and I go into considerably more detail about search, information architecture, governance and designing channels around employee needs in Digital Communications at Work: Designing Channels for Employee Engagement and Experience.