SharePoint Search: The Enterprise Guide to Search Architecture, Managed Properties, and PnP Modern Search
SharePoint Search is one of the most powerful and most misconfigured capabilities in the Microsoft 365 ecosystem. Done right, it transforms SharePoint from a document repository into a knowledge discovery platform. Done wrong, users abandon search entirely and navigate through folder structures — defeating the purpose of metadata-driven content management. This guide covers enterprise search architecture, the search schema (crawled properties, managed properties, mappings), result sources, query rules, PnP Modern Search, and integration with Microsoft Search — based on EPC Group's experience across 500+ SharePoint deployments.
SharePoint Search Enterprise Configuration Guide 2026
TL;DR: Enterprise SharePoint search configuration starts with proper search schema design — crawled properties mapped to managed properties, result sources scoped to business units, query rules for promoted content, and PnP Modern Search for advanced experiences. EPC Group builds search architectures for Fortune 500 organizations across healthcare, financial services, and government. Last updated: 2026. Read time: 6 min.
Key facts
- In SharePoint Online, Microsoft manages the search infrastructure. Your configuration responsibility is the search schema, result sources, query rules, and user experience.
- The search schema is the bridge between raw content metadata and the searchable fields that power the search experience.
- SharePoint has a documented limit of 500 custom managed properties per tenant. Plan carefully — you cannot add unlimited custom managed properties.
- EPC Group treats proper search schema design as the foundation of every SharePoint consulting engagement involving search.
- PnP Modern Search web parts provide full control over the search experience — layout, facets, refiners, and custom result templates — without custom code deployment.
SharePoint search architecture overview
In SharePoint Online, Microsoft manages the search infrastructure — the content processing pipeline, the search index, and the query processing engine. Your configuration responsibility is the search schema (property mappings), result sources, query rules, and the search user experience.
The critical concept for enterprise search is the crawl-to-query pipeline. Content is crawled, properties are discovered (crawled properties), mapped to the search schema (managed properties), and indexed. At query time, users search against managed properties. Results are security-trimmed so users only see content they have permission to access.
The search schema: crawled properties and managed properties
Crawled properties
When the search crawler processes a document or list item, it discovers metadata fields called crawled properties. These come from multiple sources:
- SharePoint site columns: Every site column generates a crawled property with the prefix ows_. For example, a site column named "Department" generates ows_Department.
- Office document properties: Title, Author, Comments, Category, and other document properties from Word, Excel, and PowerPoint files generate crawled properties with the ows_ prefix.
- Web page content: HTML meta tags, page titles, headings, and body content are extracted and indexed.
- Content type metadata: The content type name itself is a crawled property (ows_ContentType), critical for filtering search results by content type.
Managed properties
Managed properties are the configured, searchable fields in the search index. Each managed property has specific attributes that control how it behaves in search:
- Searchable: Content is included in the full-text index and returned in keyword searches
- Queryable: Property can be used in property queries (e.g., Department:Finance)
- Retrievable: Property value can be returned in search results and display templates
- Refinable: Property can be used as a refiner (filter) in the search experience
- Sortable: Results can be sorted by this property value
Configuring managed properties for enterprise
SharePoint Online provides two approaches for creating managed properties: custom managed properties (limited) and pre-provisioned RefinableString or RefinableInt properties.
The pre-provisioned refinable properties (RefinableString00 through RefinableString499, RefinableInt00 through RefinableInt49, etc.) are the recommended approach for enterprise deployments. They are already configured as Refinable and Sortable — you cannot make custom managed properties refinable without raising a Microsoft support ticket.
Maintain a property mapping registry
Keep a spreadsheet or SharePoint list that tracks every crawled property to managed property mapping across your tenant. This registry prevents duplicate mappings, identifies conflicts when multiple content types generate similar crawled properties, and documents the purpose of each managed property for future administrators.
Search schema design pattern for enterprise
- Define your information architecture first: Identify the content types, site columns, and metadata taxonomy that support your business processes. Search schema is downstream of information architecture — if the metadata is not captured at content creation time, search cannot surface it.
- Identify the search use cases: What do users search for? How do they refine results? What metadata should appear in result cards? Each use case maps to specific managed property requirements (Searchable, Queryable, Retrievable, Refinable, Sortable).
- Map crawled properties to managed properties: For each custom site column, verify the crawled property exists, then map it to the appropriate managed property (custom or refinable).
- Configure result types and display templates: Define how search results appear based on content type. A contract should display differently from a project plan or a policy document.
- Test with representative queries: Validate that managed properties return expected results using the Search REST API or PnP Modern Search web parts.
Result sources and query transformations
Result sources define what content is searched and how queries are transformed. They scope the search index to specific content subsets. This powers department-specific search pages and content-type-specific search verticals.
Common enterprise result source configurations
- Department-scoped result source: A result source with a query transformation like
{searchTerms} path:"https://contoso.sharepoint.com/sites/finance"limits results to the Finance department's sites. This powers department-specific search pages. - Content type result source: A result source filtering on
{searchTerms} ContentType:"Policy Document"returns only policy documents across the entire tenant. This powers vertical search experiences (search only policies, only contracts, only projects). - People result source: The built-in Local People Results source searches the people index. Configure it with additional profile properties to surface expertise, department, and location alongside people results.
- External content result source: For content indexed via Graph Connectors (ServiceNow, Confluence, Jira), create a result source that queries the external content index. This gives unified search across SharePoint and external systems.
Query rules and result types
Query rules trigger special actions when users search for specific terms or queries matching certain patterns. They are the primary tool for promoting high-value content and injecting contextual results.
Practical query rule examples
- Promoted results (best bets): When a user searches for "expense report," a query rule promotes the link to the expense report form as the first result. This eliminates navigation to find frequently accessed resources.
- Result block injection: When a user searches for a person's name, a query rule injects a people result block at the top showing the person's profile, contact information, and organizational hierarchy.
PnP Modern Search: advanced search experiences
PnP Modern Search is an open-source solution that provides full control over the SharePoint search experience. It uses SharePoint Framework (SPFx) web parts that deploy to your tenant's app catalog — no SharePoint farm solution required.
Key PnP Modern Search web parts
- Search Box: Custom search input with auto-suggestions, scoped search, and URL-based query passing
- Search Results: Fully customizable results layout using Handlebars templates, with support for result grouping, paging, and sorting
- Search Refiners: Custom filter panels with checkbox, range slider, and date picker refiner types
- Search Verticals: Tab-based navigation between different result sources (All, Documents, People, News)
When to use PnP Modern Search vs. native search
Use native SharePoint search for basic hub site search pages, simple departmental pages, and organizations without dedicated SharePoint developer resources. Use PnP Modern Search when you need custom result layouts, advanced refiners, multiple result sources on one page, or integration with external Graph Connector content.
Microsoft Search integration and Graph Connectors
Microsoft Search is the unified search experience across Microsoft 365 — SharePoint, Teams, Outlook, Bing for Business, and Office applications. It is powered by the Microsoft Search index, which includes SharePoint content alongside other Microsoft 365 data sources.
Graph Connectors allow you to index external content (ServiceNow, Confluence, Jira, SAP, Salesforce, custom databases) into the Microsoft Search index. Once indexed, external content appears alongside SharePoint content in search results across all Microsoft 365 surfaces.
Frequently asked questions
How do I add a custom managed property in SharePoint Online?
Navigate to the SharePoint admin center → More features → Search → Manage Search Schema. Create a new managed property or map a crawled property to an existing pre-provisioned refinable property. Note: new managed properties require a full crawl cycle (up to 24 hours) before they appear in search results.
Why do my custom metadata columns not appear in search results?
Custom site columns generate crawled properties after the first crawl. These crawled properties must then be mapped to managed properties with the "Retrievable" attribute enabled. Check that the site column has been crawled (view crawled properties in the search schema) and that the mapped managed property has Retrievable set to Yes.
What is the difference between Result Sources and Query Rules?
Result sources define what content is searched (scope and query transformation). Query rules define what happens when specific queries are executed (promote specific results, inject result blocks, change the ranking). Use result sources to scope search to specific content areas. Use query rules to promote high-value content for common searches.
When should I use PnP Modern Search instead of native SharePoint search web parts?
Use PnP Modern Search when you need custom result card layouts, advanced refiner types (range sliders, date pickers), multiple search result sources on one page, or integration with external Graph Connector content. Use native search web parts for basic hub site and department site search pages where standard layouts are acceptable.
Configure your SharePoint search
EPC Group designs enterprise SharePoint search architectures for Fortune 500 organizations in healthcare, financial services, and government. Call (888) 381-9725 or schedule at /schedule to discuss your search requirements.
Frequently Asked Questions
What is the difference between crawled properties and managed properties in SharePoint?
Crawled properties are metadata fields discovered by the search crawler from content sources — site columns, document metadata, web page content, and BCS data. Managed properties are the searchable, queryable, and retrievable fields used in search queries and result displays. A crawled property must be mapped to a managed property before it can be used in search queries, refiners, or result templates. SharePoint Online automatically maps many common crawled properties, but custom site columns require manual mapping through the search schema administration page.
How do I configure custom managed properties in SharePoint Online?
In SharePoint Online, navigate to the SharePoint Admin Center, then More Features, then Search. In the search schema management page, you can create new managed properties or edit existing ones. For custom site columns, first verify the crawled property exists (it appears after content using that column has been crawled). Then create a managed property with the appropriate settings: Searchable (included in full-text index), Queryable (can be used in KQL queries), Retrievable (returned in search results), Refinable (can be used as a search refiner), and Sortable (results can be sorted by this property). Alternatively, use the pre-provisioned RefinableString00-99 and RefinableInt00-49 managed properties by mapping your crawled property to them.
What is PnP Modern Search and when should I use it?
PnP Modern Search is an open-source collection of SharePoint Framework (SPFx) web parts that provide advanced search capabilities in modern SharePoint pages. It includes Search Results, Search Box, Search Filters, and Search Verticals web parts. Use PnP Modern Search when you need custom result layouts (Handlebars templates), multi-vertical search experiences, advanced filtering with custom managed properties, or search-driven page layouts that go beyond the native SharePoint search web parts. PnP Modern Search supports KQL and the SharePoint Search REST API, providing full control over query construction and result rendering.
How does Microsoft Search differ from SharePoint Search?
Microsoft Search is the unified search experience across Microsoft 365 — accessible from the search bar in SharePoint, Office.com, Bing.com/work, Teams, and Outlook. It uses AI-powered ranking (Microsoft Graph signals including user activity, organizational relationships, and content popularity) to personalize results. SharePoint Search (the classic search service) is the underlying index and query engine that powers search within SharePoint. In SharePoint Online, both use the same index, but Microsoft Search adds AI ranking, answers (bookmarks, Q&A, acronyms), verticals, and connectors for non-SharePoint content sources.
How do I troubleshoot SharePoint Search when content is not appearing in results?
Follow this troubleshooting sequence: (1) Check the crawl log in the SharePoint Admin Center for crawl errors on the affected content. (2) Verify the content is not in a site or library excluded from search (NoIndex setting). (3) Confirm the crawled property exists for the metadata field in question. (4) Verify the crawled property is mapped to a managed property. (5) Check that the managed property has the correct attributes enabled (Searchable, Queryable, Retrievable). (6) For newly created or modified content, wait up to 15 minutes for re-indexing in SharePoint Online. (7) Request a re-index of the specific site or library from the site settings. Full tenant re-indexing can take 24-48 hours.
What are result sources in SharePoint and how do I configure them?
Result sources define the scope and provider for search queries. They specify which content index to query (Local SharePoint, Remote SharePoint, OpenSearch), optional query transformations (KQL filters applied to every query using this source), and protocol settings. Common enterprise configurations include: a result source scoped to a specific site collection (using a query transform with path filter), a result source for a specific content type (filtering by ContentType managed property), and a result source for external content (using a BCS or Graph connector). Result sources are configured in the SharePoint Admin Center under search management and can be set at the tenant, site collection, or site level.