SharePoint search after the move: tuning, ownership, and when to build
On launch day, search on a new SharePoint Online intranet usually looks fine. The content is fresh, the test queries were written by the people who built the site, and everyone knows where things are because they just put them there.
Then the organization starts using it. People search for "leave form" when the page is titled "Absence request." They type an internal acronym nobody defined. A division renames a column and a refiner stops returning anything. None of this is a platform failure. It is what happens when search is treated as a feature that was delivered, rather than a service someone runs.
This note is about the running part: who owns search after the move, what they review, which tools to reach for first, and when a custom SharePoint Framework (SPFx) web part is worth building on a small IT team.
Name a search owner
Search needs one named owner. Not the communications team as a group, and not whoever happens to hold the global admin role.
Microsoft 365 has roles built for this. The Search admin and Search editor roles let a person manage bookmarks, acronyms, and search reports without holding broader tenant rights. Give the search owner the narrowest role that fits, and give a backup the same.
The owner's standing job is short: review what people failed to find, decide the fix, and route it to the right person.
Read what people fail to find
SharePoint Online gives site collection administrators search usage reports for modern sites, including top queries, abandoned queries (popular searches with few clicks), and no-results queries. The Microsoft 365 admin center adds organization-wide query analytics. Those lists are the most honest feedback an intranet gets.
For each failed query, the owner asks one question: why?
The content is missing. Route it to the division owner who should publish it.
The content uses different words. Fix the page title, description, or keywords, or add a bookmark.
The vocabulary is internal. Add an acronym.
The content exists but the person cannot see it. Check with the access model owner. Do not fix search by widening permissions.
Reviewing more often right after launch, then settling into a steadier cadence, is a reasonable default. The owner sets the rhythm based on what the reports show.
Reach for the cheapest fix first
Most search problems are solved with configuration and content hygiene, not code. In rough order of cost:
Page titles and descriptions. Ask content owners to write them in the words people search with. It is free and it lasts.
Bookmarks. A curated answer that puts a known destination at the top of results for chosen keywords. Bookmarks can be drafted, reviewed, and scheduled, and they need an owner to keep links current.
Acronyms. Admin-curated definitions for the internal shorthand that confuses new staff. Microsoft also notes that bookmarks and acronyms carry into Copilot Search where it is licensed, so the work is not wasted if AI arrives later.
Metadata and managed properties. When people need to filter by division, document type, or effective date, site columns can be mapped in the search schema to managed properties that drive refiners. Do this only for fields people actually filter on, and reindex after changes.
Custom verticals and result layouts. Useful when a whole category of content, such as policies or forms, deserves its own search tab.
Managed properties need a steward
Search schema changes are quiet. Someone maps a column, a refiner appears, and months later a different someone renames the column or changes a content type. The refiner goes blank and nobody connects the two.
Keep a short, living record of which columns map to which managed properties, which pages depend on them, and who may change them. When a small IT team inherits the schema after go-live, that record lets them maintain it without the original builders in the room.
When a custom SPFx web part is worth building
SharePoint Online already ships a capable set of web parts: news, highlighted content, quick links, people, events, and lists. Start there. Build custom when at least one of these is true:
A recurring task cannot be done cleanly with what ships, such as a search experience that needs refiners and layouts the standard page cannot present.
The intranet needs to show data from a line-of-business system in a way people will use daily.
A well-maintained open-source web part already does most of the job and can be adopted with a clear owner.
Do not build custom for styling alone, for a one-off request, or for something Microsoft has announced and is shipping.
Who maintains it on a small IT team
Custom code is a long-term commitment, and the organization should own it outright. That means:
The source code lives in the organization's own repository, with a documented build and deployment process.
Each web part has a named owner in IT and a written reason for existing.
Toolchain upgrades are planned. Each SPFx release supports specific Node.js versions, and older ones age out, so someone should budget time to update, test, and redeploy.
Testing uses a normal account, not an admin, so permission behavior matches what staff see.
Every web part has a retirement condition, so it can be removed when Microsoft ships an equivalent.
Fewer, well-owned custom web parts beat a large catalog nobody can upgrade.
Who carries it
Search owner — reviews reports, curates bookmarks and acronyms, routes fixes.
Division content owners — fix titles, descriptions, and missing content.
IT — maintains the search schema and custom code.
Intranet product owner — approves any new custom build against the rule above.
A short checklist
Is there a named search owner with a scoped admin role and a backup?
Does someone read no-results and abandoned queries on a set rhythm?
Is the column-to-managed-property mapping written down?
Does each custom web part have an owner, a repository, and a retirement condition?
If you want help running search after launch
McCloy Data helps organizations on Microsoft 365 set up search ownership and decide what to build, with the same content discipline we bring to OpenText and SAP landscapes. If search after the move is the open question, we would welcome a brief conversation.
