How to Make SharePoint Search Show the Right Files Firs

You know that moment when you search your intranet, type the exact title of a document, and it still vanishes into the void? That’s not bad luck—that’s bad Information Architecture. Before we start the dungeon crawl, hit subscribe so you don’t miss future best‑practice loot drops.

Here’s what you’ll walk away with today: a quick checklist to spot what’s broken, fixes that make Copilot actually useful, and the small design choices that stop search from failing. Well‑planned IA is the prerequisite for a high‑performing intranet, and most orgs don’t realize it until users are already frustrated.

So the real question is: where in the map is your IA breaking down?

The Hidden Dungeon Map: The Six Core Elements

If you want a working intranet, you need more than scattered pages and guesswork. The backbone is what I call the hidden dungeon map: six core elements that hold the whole architecture together. They’re not optional. They’re not interchangeable. They are the framework that keeps your content visible and usable: global navigation, hub navigation, local navigation, metadata, search, and personalization. Miss one, and the structure starts to wobble.

Think of them as your six party roles. Global navigation is the tank that points everyone in the right direction. Hub navigation is the healer, tying related sites into something that actually works together. Local navigation is your DPS, cutting through site-level clicks with precision. Metadata is the scout, marking everything so it can be tracked and recovered later. Search is the wizard, powerful but only as good as the spell components—your metadata and navigation. And personalization is the bard, tuning the experience so the right message gets to the right person at the right time. That’s the full roster. Straightforward, but deadly when ignored.

The trouble is, most intranet failures aren’t loud. They don’t trigger red banners. They creep in quietly. Users stop trying search because they never find what they need, or they bounce from one site to the next until they give up. Silent cuts like that build into a trust problem. You can see it in real terms if you ask: can someone outside your team find last year’s travel policy in under 90 seconds? If not, your IA is hiding more than it’s helping.

Another problem is imbalance. Organizations love to overbuild one element while neglecting another. Giant navigation menus stacked three levels deep look impressive, but if your documents are all tagged with “final_v2,” search will flop. Relying only on the wizard when the scout never did its job is a natural 1 roll, every time. The reverse is also true: some teams treat metadata like gospel but bury their global links under six clicks. Each element leans on the others. If one role is left behind, the raid wipes.

And here’s the hard truth—AI won’t save you from bad architecture. Copilot or semantic search can’t invent metadata that doesn’t exist. It can’t magically create navigation where no hub structure was set. The machine is only as effective as the groundwork you’ve already done. If you feed it chaos, you’ll get chaos back. Smart investments at the architecture level are what make the flashy tools worth using.

It’s also worth pointing out this isn’t a solo job. Information architecture is a team sport, spread across roles. Global navigation usually falls with intranet owners and comms leads. Hubs are often run by hub owners and business stakeholders. Local navigation and metadata involve site owners and content creators. IT admins sit across the whole thing, wiring compliance and governance in. It’s cross-team by design, which means you need agreement on map-making before the characters hit the dungeon.

When all six parts are set up, something changes. Navigation frames the world so people don’t get lost. Hubs bind related zones into meaningful regions. Metadata tags the loot. Search pulls it on demand. Personalization fine-tunes what matters to each player. That balance means you’re not improvising every fix or losing hours in scavenger hunts—it means you’re building a system where both humans and AI can actually succeed. That’s the real win condition.

Before we move on, here’s a quick action you can take. Pause, pick one of the six elements—navigation, metadata, or search—and run a light audit. Don’t overthink it. Just ask if it’s working right now. That single diagnostic step can save you from months of frustration later.

Because from here, we’re about to get specific. There are three different maps built into every intranet, and knowing how they overlap is the first real test of whether users make progress—or wander in circles.

World Map vs. Local Maps: Global, Hub, and Local Navigation

Every intranet lives on three distinct maps: the world map, the regional maps, and the street-level sketch. In platform terms, that’s global navigation, hub navigation, and local navigation. If those maps don’t agree, your users aren’t adventuring—they’re grinding random encounters with no idea which way is north.

Global navigation is the overworld view. It tells everyone what lands exist and how major territories connect. In Microsoft 365, you unlock it through the SharePoint app bar, which shows up on every site once a home site is set. It’s tenant-wide by design. Global nav isn’t there to list every page or document—it’s the continental outline: Home, News, Resources, Tools. Broad categories everyone in the company should trust. If this skeleton bends out of shape, people don’t even know which continent they spawned on.

Hub navigation works like a regional map. Join a guild hall in an RPG and you see trainers, quest boards, shops—the things tied to that one region. Hubs in SharePoint do exactly that. They unify related sites like HR, Finance, or legal so they don’t float around as disconnected islands. Hub nav appears just below the suite bar, over the site’s local nav, and every site joined to that hub respects the same links and shared branding. It’s also security-trimmed: if a user doesn’t have access to a site in the hub, they won’t see its content surface magically. Permissions don’t change by association. Use audience targeting if you want private links to show up only for the right people. That stops mixed parties from thinking they missed a questline they were never allowed to run.

Local navigation is the street map—the hand-drawn dungeon sketch you keep updating as you poke around. It’s specific to a single site and guides users from one page, list, library, or task to another inside that domain. On a team site it’s on the left as the quick launch. On a communication site it’s up top instead. Local nav should cover tactical moves: policies, project docs, calendars. The player should find common quests inside two clicks. If they’re digging five levels down and retracing breadcrumbs, the dungeon layout is broken.

The real failure comes when these maps don’t line up. Global says “HR,” hub says “People Services,” and local nav buries benefits documents under “Archive/Old-Version-Uploads.” Users follow one map, get looped back to another, and realize none of them match. Subsites layered five deep create breadcrumb trails that collapse the moment you reorganize, leading to dead ends in Teams or Outlook links. It only takes a few busted trails before staff stop trying navigation altogether and fire off emails instead. That’s when trust in the intranet collapses.

There are also technical boundaries worth noting. Each nav level can technically handle up to 500 links per tier, but stuffing them in is like stocking a bag with 499 health potions. Sure, it fits—but no one can use it. A practical rule is to keep hub nav under a hundred links. Anything more and users can’t scan it without scrolling fatigue. Use those limits as sanity checks when you’re tempted to add “just one more” menu.

Here’s how to test this in practice—two checks you can run right now in under a minute. First, open the SharePoint app bar. Do those links boil down to your real global categories—Home, News, Tools—or are they trying to be a department sitemap? Second, pick a single site. Check the local nav. Count how many clicks it takes to hit the top three tasks. If it’s more than two, you’re making users roll a disadvantage check every time.

When these three layers match, things click. Users trust the overworld for direction, the hubs for context, and the locals for getting work done. Better still, AI tools see the same paths. Copilot doesn’t misplace scrolls if the maps agree on where those scrolls live. The system doesn’t feel like a coin toss; it behaves predictably for both people and machines.

But even the best navigation can’t label a blade if every sword in the vault is called “Item_final_V3.” That’s a different kind of invisibility. The runes you carve into your gear—your metadata—are what make search cast real spells instead of fumbles.

Metadata: The Magic Runes of Search

When navigation gives you the map, metadata gives the legend. Metadata—the magic runes of search—is what tells SharePoint and AI tools what a file actually is, not just what it happens to be named. Without it, everything blurs into vague boxes and folders. With it, your system knows the difference between a project plan, a travel policy, and a vendor contract.

The first rule: use columns and content types in your document libraries and Site Pages library. This isn’t overkill—it’s the translation layer that lets search and highlighted content web parts actually filter and roll up the right files. A tagged field like “Region = West” doesn’t just decorate the document; it becomes a lever for search, dynamic rollups, even audience-targeted news feeds. AI copilots look for those same properties. If they aren’t defined, the AI is guessing instead of retrieving.

The second rule: avoid deep folders. Folders are brittle mazes. They break when you move things around, and after a reorg they collapse into bizarre half‑paths no one remembers. In SharePoint, the flat approach works better—topic-specific libraries combined with site columns. Flat tagging scales across teams and years. It doesn’t matter if HR merges tomorrow or Finance gets restructured; metadata-driven libraries keep surfacing content without re‑digging dungeons.

Third rule: publish a small, consistent set of mandatory fields. Don’t try to tag every possible thing under the sun. Stick to core fields like content type, owner, status, and region. That signals what type of artifact the item is, who maintains it, whether it’s current, and where it applies. Those four categories cover 90% of the scenarios users will search for. Anything else can stay optional. When you balance simplicity and precision, creators actually tag their content—and that’s when search shines.

Here’s why this matters. Without mandatory tagging, your policy that expired last year still looks like an active file. Users waste time chasing outdated versions, or worse, compliance officers miss required records altogether. With columns and content types in place, though, SharePoint crawls those properties, search knows exactly how to refine results, and Copilot can answer questions with specific current material instead of noisy guesses.

There’s also a lightweight governance step that makes all of this stick. Define your metadata centrally in the term store or site columns. Then bake those fields into the library templates so they show up automatically whenever someone uploads a file. Instead of leaving it all to chance, creators get a gentle nudge at upload: “Choose status,” “Pick owner,” “Mark region.” This isn’t red tape—it’s guardrails. The tagging happens once, up front, and pays dividends forever after.

Think of it like carving runes on a blade as soon as it’s forged. If you etch them at the start, the sword is recognizable, searchable, and easy for the wizard to use later on. If you skip the runes, you can sharpen it all you want, but it’s invisible at game time. Metadata is that early, crucial step.

If you want one quick test, here it is: pick a single library. Open it up and check if the files actually carry consistent metadata—status fields filled in, regions tagged, content types applied. Then look at whether the Highlighted content or News web parts can surface items by those tags. If nothing shows up, you’ve got a metadata gap. That’s a twenty‑second check that tells you if your system is battle‑ready or if you’re slinging spells blind.

When metadata is working, search feels less like fumbling through ten versions of the same document and more like drawing the right enchanted blade on the first try. It sharpens human productivity and sets AI copilots up for clean, accurate pulls. But metadata can’t solve every maze by itself. If the battlefield underneath is still a labyrinth of subsites and tunnels, the runes get buried just the same. And that’s where the next piece comes in—what happens when you stop tunneling down and decide the world should be flat.

Flattening the Dungeon: Why ‘The World is Flat’ Beats Nested Subsites

Back in the day, every intranet site came bolted to a stack of subsites. Each subsite branched into another, and another, until you hit ten layers deep with no clear exits and no working torches. SharePoint used to encourage that model, but modern SharePoint doesn’t. The current guidance is flat: subsites are generally not recommended. Instead, you build one site per discrete topic, task, or unit of work, and then connect those sites together through navigation and hubs. Think of it less like a dungeon tower and more like a single floor of well-marked rooms. Each room has a door, a label, and a defined purpose. You move sideways, not downward.

The main reason for this shift is fragility. Deep hierarchies look neat on paper, but reorganize one department or archive one project and everything crumbles—permissions drift, links break, and bookmarks die. Users eventually quit following the tunnels altogether. A flat design avoids that trap. Each site stands on its own, and when changes happen, you just move the site into a different hub or archive it, without shattering everyone’s navigation. In practice: deep hierarchies mean brittle links and broken bookmarks when you reorganize. Flat sites tied to hubs mean you can re-home a site with minimal disruption.

Hubs are the connective tissue of a flat structure. They live above individual sites and unify them with common branding and shared navigation. They also roll up activity—news, events, and pages—from the sites below, so users see a bigger picture without chasing every corner. That keeps related areas like HR, Finance, or a regional office tied into one shared experience. It’s flexible: a new project spins up? Create a standalone site and slot it into the right hub. Project closes? Archive it cleanly without destroying navigation trails for everyone else.

You also have roll-up web parts—the News web part stacks updates across multiple sites into one feed, the Highlighted content web part dynamically surfaces tagged documents, and the Sites web part displays key connected locations. Each of these mechanisms works like a spotlight. News shows current signals, Highlighted content pulls artifacts that match metadata, and Sites displays the map of what matters. Users discover what they need across sites without digging through folder ladders.

The payoff for AI is just as real. Copilot doesn’t hunt through some twelfth folder inside a sub-subsite. It works best when it has a clear surface to crawl. Flat sites with topic-based scopes and clean hubs give Copilot obvious boundaries: “this site only governs Finance procedures,” “this site publishes HR news.” The assistant doesn’t have to guess. It can retrieve with confidence.

The operational benefits stack up quickly. In a flat environment, restructuring HR under a new VP isn’t weeks of fixing nav—it’s moving the HR site into a new or existing hub. Need to decommission a project site? Drop it out of the hub and freeze it without triggering link rot everywhere else. Compare that to the old days of tied subsites, where every breadcrumb came apart the minute one branch shifted. Flat design is simply more resilient.

So here’s your practical checkpoint: if your intranet still relies on big subsite trees, it’s time to flatten. Inventory your current layout and identify one core function—like HR or a high-traffic project space—that you could convert into a standalone site tied to a hub. Start there. One clean rebuild proves out the model, and from there, you expand across other functions.

Getting the map flat and connected is only part of the win, though. Once users can reach the treasure rooms without endless ladders, the next challenge is making sure the right rewards actually reach the right players. Because there’s no point in building a smooth system if the mage still ends up holding plate armor while the tank gets handed a scroll. That’s where the next piece steps in.

Targeting the Loot Drop: Personalization and Audience Targeting

Loot only matters if it lands in the right inventory. In Microsoft 365 terms, that means using personalization and audience targeting so content reaches the right people instead of clogging everyone’s feed with junk. A mage doesn’t need plate armor, and frontline staff don’t need executive-only memos. Audience targeting is the feature set that controls who sees which navigation links, web parts, and news items. Personalization is what makes those defaults useful without each person having to dig through settings they’ll never bother with.

Here’s how it actually works. Audience targeting lets you connect navigation, pages, and web parts to Azure AD groups or Microsoft 365 groups. That means a frontline worker sees a different shortcut set than a manager. Regional offices can have their own home-area links without multiple duplicated pages. News and announcements can surface in the feed for engineers while steering clear of marketing. It’s the intranet equivalent of rolling on a loot table that adapts per class—you only get drops you can actually equip.

Best practice here is to combine personalization defaults with audience targeting instead of relying only on Quick Links. Quick Links are fine for a couple of one-off bookmarks, but if you use them as your main tool for tailoring navigation, you’ll end up with walls of icons users ignore. Research shows staff rarely invest time in heavy manual personalization. They want the system to be smart enough by default. So use audience targeting to handle group-level differences, and then add just enough Quick Links for personal flavor. That balance respects attention spans and keeps the UX tight.

Delivery matters too. Microsoft Viva Connections takes targeted content out of the intranet silo and pipes it directly into Teams and the Viva dashboard. That puts alerts in front of people where they already work. No need to check a portal tab just to confirm a shift change—field staff see it on mobile. Governance updates reach managers in their Teams channel instead of being buried in a general feed. The same intranet sits behind the scenes, but the distribution path adapts. That’s how targeting feels seamless instead of forced.

There are guardrails to consider. Multilingual support ensures the navigation strings and page content display in each user’s preferred language. If you enable Spanish and German for a communication site, someone has to translate the nav, footers, and UI elements for those users—audience targeting then makes sure the right variant shows up. For compliance-heavy orgs, information barriers or tight permission groups filter who can actually see sensitive material. It’s still targeting, just at a stricter level, preventing confidential scrolls from flowing to the wrong faction.

The impact is immediate. Targeting cuts noise down to size. Users start trusting the intranet because it stops throwing irrelevant gear at them. Engagement goes up because the feed feels relevant—all killer, no filler. AI copilots thrive on this too, because if the source material is tagged properly for each audience, the AI doesn’t have to guess. Ask it for “latest HR process,” and it pulls the current, local policy aligned to your role, not a stale copy meant for another department. That accuracy is what keeps confidence high.

You can test this today. Open one hub or home page and check: are audience targeting settings enabled on the global nav and key web parts? If not, you’ve got an easy next action. Switch them on, align them to the right groups, and watch the signal-to-noise ratio improve immediately. It’s a small setting with a major payoff.

On a natural 20, targeting turns the intranet into a fair fight. Tanks get armor, healers see potions, mages find spell scrolls. Nobody wastes energy sorting junk. Nobody ignores alerts because they actually matter. Users trust the system, AI pulls with accuracy, and adoption happens without a marketing campaign. That’s how you keep the loot table clean and the party equipped.

Which brings us back to the bigger frame. Information architecture isn’t ornamental. It’s the underlying system code both your users and your AI have to navigate every single day. Neglect it, and you’re just rolling natural 1’s forever.

Conclusion

So here’s the wrap: before you log another ticket, run three quick checks. First, line up your navigation—global, hub, and local—and trim bloated menus. Second, audit your metadata and content types so files actually surface. Third, confirm audience targeting is live and content flows into Teams or Viva where people already work.

One next step: validate your setup with card sorting, tree testing, and usability testing, then scan search logs to spot failed queries. IA isn’t set‑and‑forget—it’s a living system you test, measure, and refine.

Boss down, checklist secured. Subscribe, toss this in your runbook, and drop a quick comment on which check you’ll run first.

This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit m365.show/subscribe