Search Verticals
Common Use Cases
- Department search tabs: a Policies vertical on the HR site that returns only documents tagged as policy content
- Connector content tabs: results from external systems indexed through Microsoft 365 Copilot connectors get their own tab
- Personal work queues: a Tickets vertical that uses profile variables to show only items assigned to the signed in user
- Hub wide discovery: a site level vertical on a hub site that searches across all associated sites in the hub
- Knowledge base scoping: verticals filtered by content type or metadata so help articles never mix with project files
- Archive cleanup: KQL exclusions that keep retired sites and old file types out of a vertical’s results
Benefits
- Focused results: users land on the slice of content they need instead of scrolling a mixed results list
- No code configuration: verticals are defined through a wizard with a name, content source, and optional KQL query
- Right scope at the right place: organization verticals serve everyone while site verticals tailor search per department
- Plays well with filters: verticals combine with custom filters so users can refine further within the tab
- External content inclusion: connector sources bring non SharePoint systems into the same familiar search page
- Personalization built in: profile and query string variables adapt results to the person searching
How It Works
- Tabs on the results page: each vertical is a tab showing results of a specific type or from selected sources, like the default All, Files, and People
- Two management levels: organization verticals appear for searches from the SharePoint start page and Office.com, while site verticals appear on an individual site’s results page
- KQL scoping: a limited KQL set of free text keywords, property restrictions, and boolean operators narrows what the vertical returns
- Query variables: Profile variables such as {Profile.accounts.userPrincipalName} and QueryString variables personalize the query at search time
- Scope follows context: an organization level SharePoint vertical searches everything, while the same vertical on a site or hub respects that site or hub scope
- Result layouts: connector results render through configured result types and layouts on the vertical page
Limits and Nuances
- Propagation delay: new and updated verticals take a few hours to appear, and appending cacheClear=true to the search URL speeds verification
- No mobile view: custom verticals do not appear in the mobile web search experience
- Fixed order: verticals cannot be reordered on the results page
- People vertical exception: the People vertical does not accept a custom query
- One vertical per connection: a connector connection can be used as a content source in only one vertical
- Localization caveat: once a default vertical is renamed, automatic language localization no longer applies to its name
- Query string scope: query string variables work only on SharePoint site searches
- Limited KQL: dynamic ranking operators like XRANK and proximity operators are not supported in vertical queries
Common Questions About Search Verticals
What are search verticals in SharePoint?
Search verticals are the tabs on a search results page that split results by type or source, such as All, Files, and People. Microsoft Search includes default verticals, and you can rename them, disable them, or add custom verticals scoped with a KQL query. They exist at the organization level for searches from the SharePoint start page and at the site level for individual sites.
What is the difference between organization and site level verticals?
An organization vertical appears when people search from the SharePoint start page and Office.com, making it right for company wide content like policies. A site vertical appears only on the search results page of the site where it is configured, which suits department scenarios. A site vertical on a hub site respects the hub scope, returning results from associated sites too.
How do I scope a vertical to specific content?
Each vertical accepts a KQL query that narrows its results, built from free text keywords, property restrictions, and boolean operators. Typical patterns include filtering by a managed property such as an aliased RefinableString, excluding archive paths with NOT path expressions, or restricting by FileType. The managed properties you reference must be queryable, which is where the search schema and verticals work together.
Why is my new vertical not showing up?
Vertical changes take a few hours to propagate, so the most common cause is simply waiting time. Appending cacheClear=true to the search page URL can force a refresh sooner. For verticals built on connector content, a result type and layout must also be configured before results render. Custom verticals also do not appear in the mobile web view, which is a documented limitation.
Can a vertical show content from outside SharePoint?
Yes. Custom verticals can use Microsoft 365 Copilot connectors as their content source, surfacing systems like ticketing tools or file shares as their own tab in search results. A vertical can even combine multiple connector connections, although each connection can only belong to one vertical. Connector results need a configured result layout, and common source properties are used when querying across several connections.
Who can set up search verticals?
Organization verticals are managed by Microsoft Search administrators, while site verticals can be configured by site collection administrators on the site itself, with no custom code needed in either case. When Greg Zelfond designs LookBook 365 search experiences, verticals are paired with managed properties and filters so every department gets its own focused search tab, all configured out of the box.