Findability is whether somebody who needs a page can get to it. The decisions behind it are who owns the navigation at each level it exists, what gets curated so a common question lands on a chosen answer, and who answers when a page that exists cannot be found. This area is the one place in intranet governance where the central team can act on a content problem without asking anybody, and that is what makes it worth governing rather than simply managing.
The one area where the intranet team can act alone
Everywhere else on an intranet, the intranet team owns the rule and the area that publishes owns the content. A page is wrong and only the area can correct it. A page needs retiring and only the area can say so.
Findability does not work that way. Navigation and curated answers are levers the central team can pull on its own, without the agreement of whoever published the content. So when somebody reports that they could not find the travel policy, the fix within reach is a link, and the link gets added. Nothing is decided about which of the three travel pages is the current one or who answers for it, and the intranet gains an entry in the menu.
That progression is visible on plenty of intranets: a navigation menu that grew every time somebody asked, holding links to pages nobody has owned for years. What goes in the menu is a decision worth governing in itself. The harder one is whether a complaint calls for a new link or for somebody to sort out the pages behind it.
Who owns the navigation
Navigation exists at more than one level and each level has a different owner. Global navigation appears in the SharePoint app bar and requires a designated home site, the site set as the intranet's entry point. Whoever owns that site owns the global navigation, which in practice usually means the intranet team. Hub navigation is shared by every site associated with a hub, so it belongs to the hub owner rather than to the sites that inherit it. Site navigation belongs to the site owner.
What follows is a decision about who may add to a shared menu. A hub owner can put a link in front of every site in the hub, and the areas publishing on those sites inherit it without being asked. Deciding that additions to hub and global navigation follow a set route, on a cycle rather than on request, is the kind of decision this area needs and the kind SharePoint will not make for you.
What a curated answer commits you to
Bookmarks and acronyms are curated in the Microsoft 365 admin center under Search & intelligence, where a bookmark pins a chosen link to a set of query terms and an acronym records what an internal abbreviation stands for.
A curated answer is a shortcut you chose to maintain rather than a sign that something underneath is broken. It needs what anything published on an intranet needs, which is somebody who owns it and a reason it exists, because a bookmark pointing at last year's page is worse than no bookmark. Answer analytics reports impressions and clicks for each bookmark along with the queries that triggered it, which is one of the better native reports in this area and more than the navigation will ever tell you about if a link is being used.
A few of our apps sit in this same category of maintained shortcut rather than search fix. Page Tags connects to existing managed properties or the term store so readers can find similar content from a page itself, and Pages Directory gives people a browsable route to content alongside search. Neither replaces the navigation-ownership decision above; they're supplementary structure that still needs someone keeping it current, the same as a bookmark.
Where the mechanics stop short
Navigation holds no record of who added a link or why, and no setting asks whether the page at the end of it is still the right one. Reporting on failed searches does exist, in two places. At site level, the No results queries and Abandoned queries reports cover the past 31 days and are available to site collection administrators. At tenant level, a query report under Search & intelligence separates queries that returned no results from queries a person abandoned, over 28 days.
What no report does is join a failed search to the page that should have answered it. So the case for adding a link to the navigation is made from a complaint rather than from anything you can look up, which is the reason menus grow.
Common questions
Who should own intranet navigation?
Our view is that each level should be owned by the person answerable for the site it belongs to, and that the two shared levels need a route for additions rather than an open door. Global navigation requires a designated home site, so it sits with whoever owns that site, in practice the intranet team. Hub navigation reaches every site associated with the hub, which is why the hub owner needs to be somebody who will say no.
Who is responsible when people cannot find things on the intranet?
Our view is that it is the area that published the content, with the intranet team keeping the right to require a page be corrected. SharePoint records none of this, since there is no field on a page for the person answerable for it. The practical trap is that the intranet team can add a link without involving that area at all, which answers the complaint and leaves the content as it was.
How do you stop intranet navigation growing out of control?
By deciding in advance who may add to it and how a request gets made, rather than judging each request as it arrives. Nothing in SharePoint will stop a menu growing, and no report will tell you which links are being used. A cycle where the shared menus get looked at as a whole, by the person who owns them, is what keeps the answer to one complaint from becoming permanent.
Series links
→ Next in the series: oversharing and Copilot in your intranet
