SharePoint Search: The Enterprise Guide to Search Architecture, Managed Properties, and PnP Modern Search

SharePoint Search Architecture Overview

Understanding the SharePoint search architecture is essential before configuring managed properties, result sources, or custom search experiences. 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.

SharePoint Online Search Architecture
┌──────────────────────────────────────────────────────────┐
│ Content Sources                                           │
│ ├── SharePoint Sites (document libraries, lists, pages)   │
│ ├── OneDrive for Business                                 │
│ ├── Microsoft Teams (files, messages via compliance)       │
│ ├── Graph Connectors (external content sources)           │
│ └── Delve / People profiles                               │
└────────────────────┬─────────────────────────────────────┘
                     │ Continuous Crawl
┌────────────────────▼─────────────────────────────────────┐
│ Content Processing Pipeline                               │
│ ├── Document parsing (Office, PDF, HTML, images via OCR)  │
│ ├── Language detection and word breaking                   │
│ ├── Entity extraction (people, organizations, locations)   │
│ ├── Crawled property discovery                            │
│ └── Managed property mapping and index update              │
└────────────────────┬─────────────────────────────────────┘
                     │
┌────────────────────▼─────────────────────────────────────┐
│ Search Index                                              │
│ ├── Full-text index (searchable content)                  │
│ ├── Metadata index (managed properties)                   │
│ ├── ACL index (security trimming)                         │
│ └── Analytics index (click-through, popularity signals)   │
└────────────────────┬─────────────────────────────────────┘
                     │
┌────────────────────▼─────────────────────────────────────┐
│ Query Processing                                          │
│ ├── Query parsing and KQL expansion                       │
│ ├── Result source selection                               │
│ ├── Query rule evaluation                                 │
│ ├── Security trimming (ACL enforcement)                   │
│ ├── Relevance ranking (BM25 + Microsoft Graph signals)    │
│ └── Result rendering and display templates                │
└──────────────────────────────────────────────────────────┘

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, and results are security-trimmed so users only see content they have permission to access.

The Search Schema: Crawled Properties and Managed Properties

The search schema is the bridge between raw content metadata and the searchable, queryable fields that power the search experience. At EPC Group, proper search schema design is the foundation of every SharePoint consulting engagement that involves search.

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 in SharePoint generates a crawled property with the prefix ows_ (for standard columns) or ows_q_ followed by the data type and internal name. 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), which is 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:

Configuring Managed Properties for Enterprise

SharePoint Online provides two approaches for creating managed properties: custom managed properties (limited in SharePoint Online) and pre-provisioned RefinableString/RefinableInt properties. Understanding the trade-offs is critical for enterprise search design.

Using Pre-Provisioned Refinable Properties

SharePoint Online provides 100 RefinableString properties (RefinableString00 through RefinableString99), 50 RefinableInt properties, 50 RefinableDate properties, and 50 RefinableDouble properties. These are already configured with Queryable, Retrievable, Refinable, and Sortable attributes. To use them, map your crawled property to the corresponding refinable managed property.

Custom Managed Properties in SharePoint Online

You can create custom managed properties in the SharePoint Admin Center, but with limitations: custom managed properties in SharePoint Online cannot be marked as Refinable or Sortable. For properties that need refining or sorting capability, use the pre-provisioned RefinableString/Int/Date/Double properties instead. Custom managed properties are useful when you only need Searchable, Queryable, and Retrievable attributes.

Search Schema Design Pattern for Enterprise

A well-designed enterprise search schema follows this pattern:

1. 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.
2. 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).
3. 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).
4. 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.
5. 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 the scope of a search query. They control which content the search engine queries and can apply automatic query transformations that filter or boost results. Enterprise organizations typically create multiple result sources for different search scenarios.

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 enables unified search across SharePoint and external systems.

Query Rules and Result Types

Query rules allow you to conditionally modify search behavior based on the query text, query source, or user context. They are one of the most underutilized features in enterprise SharePoint Search.

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 the need for users to navigate through multiple sites 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 of the search results showing the person's profile, contact information, and organizational hierarchy.
• Query rewriting: When a user searches for "PTO policy," a query rule expands the query to also include "paid time off policy" OR "vacation policy" OR "leave policy." This improves recall for queries where users may use different terminology.

Result Types and Display Templates

Result types define how different content types appear in search results. A default search result shows title, URL, and a text snippet. A custom result type for a contract might show: title, contract value (RefinableDouble00), counterparty (RefinableString05), expiration date (RefinableDate01), and contract status (RefinableString06). Custom result types require display templates (classic search) or PnP Modern Search result templates (modern search).

PnP Modern Search: Advanced Search Experiences

PnP Modern Search is the go-to solution for building advanced search experiences on modern SharePoint pages. It is an open-source project from the Microsoft 365 Patterns and Practices (PnP) community that provides SPFx web parts for search results, search box, search filters, and search verticals.

Key PnP Modern Search Web Parts

• Search Results: Displays search results with fully customizable Handlebars or Adaptive Cards templates. Supports KQL queries, result source selection, managed property selection (which properties to retrieve), and paging. This replaces the Content Search Web Part from classic SharePoint.
• Search Box: A search input field that connects to the Search Results web part. Supports query suggestions, recent queries, and custom placeholder text.
• Search Filters: Displays refiners (filter panels) based on managed properties. Supports multi-value filtering, date ranges, and custom filter templates. Connects to the Search Results web part to dynamically filter results.
• Search Verticals: Provides tabbed search experiences (All, Documents, People, News) where each tab queries a different result source. This replicates the multi-vertical search experience from the SharePoint search center.

PnP Modern Search Handlebars Template Example

PnP Modern Search uses Handlebars templates for result rendering. A typical enterprise result template displays different metadata depending on the content type:

{{#each data.items as |item|}}
<div class="result-card">
  <div class="result-icon">
    <img src="{{item.iconSrc}}" alt="{{item.FileType}}" />
  </div>
  <div class="result-content">
    <a href="{{item.OriginalPath}}" class="result-title">
      {{item.Title}}
    </a>
    <p class="result-metadata">
      {{item.Author}} | {{getDate item.LastModifiedTime "MM/DD/YYYY"}}
      {{#if item.RefinableString05}}
        | Department: {{item.RefinableString05}}
      {{/if}}
    </p>
    <p class="result-summary">{{getSummary item.HitHighlightedSummary}}</p>
  </div>
</div>
{{/each}}

Microsoft Search Integration and Graph Connectors

Microsoft Search extends SharePoint Search into a unified cross-application search experience. When users search from the SharePoint home page, Office.com, Teams, or Outlook, they use Microsoft Search, which queries the same SharePoint search index but applies additional AI-powered ranking based on Microsoft Graph signals.

Microsoft Search Administration

• Bookmarks: Curated answers that appear at the top of search results for specific keywords. For example, when users search for "benefits enrollment," a bookmark card with the direct link and description appears above organic results. Bookmarks are managed in the Microsoft 365 Admin Center.
• Q&A: Predefined question-and-answer pairs that appear when users search for specific questions. Ideal for frequently asked HR, IT, and policy questions.
• Acronyms: Define organizational acronyms and their meanings. When users search for "OKR," the acronym definition appears: "Objectives and Key Results — the goal-setting framework used by Product and Engineering teams."
• Floor plans: Upload office floor plans and associate rooms with locations. Users can search for a colleague and see their office location on the floor plan.

Graph Connectors for External Content

Microsoft Graph Connectors ingest content from external sources into the Microsoft Search index. This enables users to find ServiceNow tickets, Confluence pages, Jira issues, Salesforce records, and other external content through the same search experience they use for SharePoint content. Over 150 pre-built connectors are available, and custom connectors can be built using the Microsoft Graph Connectors API. Learn more about integrating external data in our data engineering guide.

Search Governance and Best Practices

Search quality degrades without governance. EPC Group implements these governance practices for every enterprise SharePoint search deployment:

Information Architecture Governance

• Mandatory metadata: Require key metadata fields (document type, department, project) at content creation time. Search cannot surface metadata that was never captured. Use content types with required site columns to enforce metadata entry.
• Controlled vocabulary: Use the SharePoint term store (managed metadata) for key classification fields. Controlled vocabularies ensure consistent metadata values, which is critical for search refiners and filters. Refer to our document management guide for taxonomy design patterns.
• Content lifecycle: Archive or delete stale content. Search results that surface outdated documents erode user trust in search. Implement retention policies that automatically archive content past its retention period.

Search Analytics and Continuous Improvement

• Search usage reports: Monitor top queries, no-result queries, abandoned queries, and click-through rates in the Microsoft 365 Admin Center. No-result queries indicate content gaps or search schema issues.
• Bookmark management: Review the top 50 queries monthly and create bookmarks for queries where users consistently need the same resource. This reduces click-to-result time for common searches.
• Property mapping audits: Quarterly review of the search schema to ensure crawled-to-managed property mappings are current, documented, and aligned with evolving information architecture.

Troubleshooting Common Search Issues

Partner with EPC Group

EPC Group is a Microsoft Gold Partner with 25+ years of SharePoint consulting experience across 500+ enterprise deployments. Our SharePoint consulting practice delivers search architecture design, information architecture governance, PnP Modern Search implementations, and Microsoft Search optimization. We specialize in organizations with complex search requirements — multi-department taxonomies, regulatory content management, and cross-system search experiences that unify SharePoint with external data sources.