SharePoint Online crawled properties not being generated for custom site columns - 9 September 2026

Question

SharePoint Online crawled properties not being generated for custom site columns - 9 September 2026

ASM2030 15

Hello,

I have created several custom columns of type Single line of text. I have added the columns to a couple of content types, added those content types to a Documents library, and added new items to the library, ensuring for each item that every custom column has a value. I have waited for over a week now and still I am unable to see any crawled properties (for any of the custom columns) under SharePoint Admin > More features > Search > Manage Search Schema > Crawled Properties or add mapping to managed property.

Steps tried :

Ensure the items with the columns/values I want crawled are appearing in search (i.e., that they have been crawled).
Re-index list.
Re-index site.
Ensure list is enabled for search under List Settings > Advanced Settings.
Ensure columns are not excluded from search under Site Settings > Searchable columns.
Ensure site is included in search under Site Settings > Search and Offline Availability.
Created a new custom site column manually through the user interface (to see if the issue was related to the code I used to provision the columns, or if it happens to all new columns). I added the new column to the library, and added new items with a value in this column. After the items were crawled (I could see them in search results), I checked and confirmed there was no crawled property for this new column, either.

Anybody facing same issue?... I'm logging in from New Zealand. I am aware that this is a known bug so am unsure if it's affecting this side of the world or perhaps it's a global issue that a lot of tenants are facing.

FYI, I've logged a support request Case [Moderator note: Personally Identifiable Information removed] - TrackingID#[Moderator note: Personally Identifiable Information removed]. However, they have repeatedly asking about screenshots and more information which I've already provided.

I've asked multiple times to call schedule a time for a call and a remote session but they keep calling randomly outside my working hours despite the fact that I've specifically told them my region. It has been over a week now and they have not escalated me to someone who can help.

Microsoft, if anyone out there that can help, please I'm actually desperate here.

Regards

Simon R 45 Reputation points

2026-09-10T11:38:09.2566667+00:00

we're having the same issue for two weeks now
Daniel-Vo 6,610 Reputation points Microsoft External Staff Moderator

2026-09-11T07:39:30.39+00:00

Hi Simon,

I would recommend creating a support ticket in Microsoft 365 admin center to ask the Support Engineer to review whether there are any known service-side issues affecting crawled property generation and, if appropriate, engage the SharePoint Search Engineering team for further investigation. Based on the troubleshooting already performed, a backend investigation may be necessary to determine why crawled properties are not being surfaced for newly created custom columns.
Haughey, Virginia 0 Reputation points

2026-09-13T16:12:33.8566667+00:00

Does anyone have updates on this? I'm also experiencing this issue.
Daniel-Vo 6,610 Reputation points Microsoft External Staff Moderator

2026-09-15T09:24:33.5966667+00:00

Hi @Haughey, Virginia ,

Please refer my previous reply to create support ticket with Microsoft.
Lise 0 Reputation points

2026-09-21T10:23:28.6433333+00:00

We have the same issue. It turns out that not all crawled properties or managed properties are viewable in de Search Schema in the SharePoint Online Admin center. If you use the Search Query Tool, you might find the crawled properties you are looking for. However, I am still stuck. I'd like to map these crawled properties to Refinable-managed properties and since the crawled properties are not shown in the Admin center, I cannot map them. There are no PowerShell-cmdlets for changing the search schema as far as I know.
Pieter Op De Beéck 0 Reputation points MVP

2026-09-28T09:11:47.9766667+00:00

I have the exact same issue. I thought I was going crazy but 'glad' to see you all seem to have the same issue here ... might be bigger than expected.

4 answers

Your answer

Simon R 45 Reputation points

2026-09-10T11:38:09.2566667+00:00

we're having the same issue for two weeks now
Daniel-Vo 6,610 Reputation points Microsoft External Staff Moderator

2026-09-11T07:39:30.39+00:00

Hi Simon,

I would recommend creating a support ticket in Microsoft 365 admin center to ask the Support Engineer to review whether there are any known service-side issues affecting crawled property generation and, if appropriate, engage the SharePoint Search Engineering team for further investigation. Based on the troubleshooting already performed, a backend investigation may be necessary to determine why crawled properties are not being surfaced for newly created custom columns.
Haughey, Virginia 0 Reputation points

2026-09-13T16:12:33.8566667+00:00

Does anyone have updates on this? I'm also experiencing this issue.
Daniel-Vo 6,610 Reputation points Microsoft External Staff Moderator

2026-09-15T09:24:33.5966667+00:00

Hi @Haughey, Virginia ,

Please refer my previous reply to create support ticket with Microsoft.
Lise 0 Reputation points

2026-09-21T10:23:28.6433333+00:00

We have the same issue. It turns out that not all crawled properties or managed properties are viewable in de Search Schema in the SharePoint Online Admin center. If you use the Search Query Tool, you might find the crawled properties you are looking for. However, I am still stuck. I'd like to map these crawled properties to Refinable-managed properties and since the crawled properties are not shown in the Admin center, I cannot map them. There are no PowerShell-cmdlets for changing the search schema as far as I know.
Pieter Op De Beéck 0 Reputation points MVP

2026-09-28T09:11:47.9766667+00:00

I have the exact same issue. I thought I was going crazy but 'glad' to see you all seem to have the same issue here ... might be bigger than expected.

Answer 1

Daniel-Vo 6,610 Microsoft External Staff Moderator

Hi ASM2030,

Based on the information provided, it appears that you have already completed the standard troubleshooting steps typically recommended for SharePoint Online Search Schema issues, including reindexing the library and site, verifying search settings, confirming that items are searchable, and allowing sufficient time for indexing to occur. The fact that newly created custom site columns are also affected suggests that this may not be an issue with a specific column configuration or content type.

As a few additional validation steps, you may consider:

Verifying whether any automatically generated managed properties exist for the affected columns
Creating a new test column in a separate library or site collection to determine whether the behavior is isolated or tenant wide.

However, given that the issue impacts multiple newly created columns and that the expected crawled properties are not being generated after an extended period, there is a possibility that the problem is related to the SharePoint Online search backend rather than tenant configuration. Similar cases have required investigation by Microsoft's Search or Search Schema engineering teams.

Since you already have an active support case open with Microsoft, I recommend continuing to work directly with the assigned Support Engineer and requesting escalation if the issue remains unresolved. When engaging with the engineer, it would be helpful to provide:

Tenant ID
Site URL
Library URL
Internal name of the affected column(s)
Sample document or item URL containing populated metadata
Confirmation that reindexing has been completed and that items are already discoverable through search

I would recommend asking the Support Engineer to review whether there are any known service-side issues affecting crawled property generation and, if appropriate, engage the SharePoint Search Engineering team for further investigation. Based on the troubleshooting already performed, a backend investigation may be necessary to determine why crawled properties are not being surfaced for newly created custom columns.

Please keep me and other users updated on the outcome of the support escalation, as the Support Engineer will be best positioned to verify whether additional backend diagnostics or remediation actions are required.

Andrew Maybir 0 Reputation points

2026-09-14T00:32:54.5033333+00:00

Hi Daniel,

Thank you for your response. I appreciate you taking the time to review this.

Unfortunately, the difficulty we are now facing is that most of the additional validation you have suggested has already been completed, and I have also been proactively supplying these findings to Microsoft Support as the investigation has progressed.

At this stage, I am posting here because the support experience through the existing case has not resulted in meaningful escalation or progress. If the support case were progressing appropriately, I would not need to seek help through the Microsoft community as well. And on the same note, here, we will have a few a few people that will relate and possibly share their own findings.

We have now reproduced the issue on a completely new SharePoint site

To rule out corruption, legacy configuration, content types, or a problem specific to the original SharePoint site, I created a completely new SharePoint Communication site called:

CoconutHusk

I then created a separate test document library:

SearchSchemaTestDocs

and created fresh test site columns, including:

·        CoconutTestDocumentType

·        CoconutTestResource

I populated multiple new documents with metadata values such as Policy, Form, Standard, Finance, Operations, Health and Safety, etc., and then reindexed the test environment.

The important point is that the same Search Schema administration behaviour was reproduced on this completely separate site.

Therefore this is no longer reasonably explainable as a configuration problem limited to our original document library, original site, historical site columns, or content types.

At minimum, this rules out the original site/library and strongly indicates a tenant-level or SharePoint Online service-side Search Schema issue.

We have also verified the automatically generated managed properties

You suggested checking whether SharePoint had automatically generated managed properties for the affected columns.

We have done this, and this produced one of the most important findings of the investigation.

Although the classic Search Schema interface does not correctly expose these properties, SharePoint Search itself recognises them.

For example, the automatically generated managed properties include:

·        CoconutTestDocumentTypeOWSCHCS

·        CoconutTestResourceOWSCHCS

The same behaviour was previously demonstrated with our original columns:

·        TestDocumentTypeOWSCHCS

·        DocumentTypeOWSCHCS

·        FunctionOWSCHCM

Using PnP PowerShell and Submit-PnPSearchQuery, we can retrieve these properties directly from the SharePoint Search index with their correct metadata values.

We have also successfully used the automatically generated managed properties as property-restricted KQL queries.

For example, queries equivalent to:

DocumentTypeOWSCHCS:"Policy"

and:

FunctionOWSCHCM:"Finance"

return the expected SharePoint documents.

This is therefore not simply a case where Search has failed to crawl or index the metadata.

The Search backend has processed it.

The key contradiction we are seeing

The problem is the difference between the operational SharePoint Search backend and the classic Search Schema administration layer.

Our findings currently look like this:

Component

Documents contain populated metadata Working

Documents contain populated metadata Working

Site columns are valid SharePoint site columns Working

Site columns are valid SharePoint site columns Working

Site included in Search Working

Site included in Search Working

Library included in Search Working

Library included in Search Working

Reindexing completed Completed

Reindexing completed Completed

Documents returned by SharePoint Search Working

Documents returned by SharePoint Search Working

Automatically generated managed properties Working

Automatically generated managed properties Working

Managed-property values returned by Search API Working

Managed-property values returned by Search API Working

Property-restricted KQL against those properties Working

Property-restricted KQL against those properties Working

Classic Search Schema property filtering Inconsistent / failing

Classic Search Schema property filtering Inconsistent / failing

Opening some automatically generated managed properties Failing

Opening some automatically generated managed properties Failing

Crawled-property visibility in mapping interface Inconsistent

Crawled-property visibility in mapping interface Inconsistent

Mapping crawled property to RefinableStringXX Blocked

Mapping crawled property to RefinableStringXX Blocked

Reverse mapping attempt Failed

Reverse mapping attempt Failed

Programmatic Search Configuration mapping Did not persist

Programmatic Search Configuration mapping Did not persist

Programmatic Search Configuration mapping - Did not persist

For example, a managed property can be queried successfully through SharePoint Search, yet searching for the exact same managed-property name in the classic Manage Search Schema interface can return:

There are no items to show in this view.

Some properties can only be located by manually paging through the Search Schema results.

Some appear greyed out.

When opened, we have also received errors such as:

Managed property CoconutTestDocumentTypeOWSCHCS was not found.

We also found relevant crawled properties only after enabling Show unaltered property names and manually paging through the properties.

However, this still does not allow us to establish the required mapping to the reusable RefinableString managed properties.

We have verified this independently with PnP PowerShell

We created a dedicated Entra application for the investigation and tested this using current PnP PowerShell.

We initially identified that the PnP session had AllSites.Read but did not have the delegated SharePoint Search permission required for Submit-PnPSearchQuery.

We subsequently added:

Sites.Search.All

granted administrator consent, reauthenticated, and verified through PnP that the Search permission was present.

Therefore the PnP results below are not caused by insufficient Search API permissions.

We also verified:

·        Site NoCrawl = False

·        Library NoCrawl = False

·        Fields are not hidden

·        Fields are not read-only

·        Fields are not sealed

·        Site-column IDs match the corresponding library-field IDs

·        Metadata exists on the actual SharePoint list items

·        Search returns the relevant documents

·        Search returns the expected managed-property values

·        KQL restrictions against those managed properties succeed

This gives us independent evidence that the SharePoint Search backend is working.

RefinableString mapping is where the problem remains

Our objective requires these metadata properties to be mapped to reusable SharePoint managed properties such as RefinableStringXX.

For the CoconutHusk test we identified unused refinable properties and intended to test mappings such as:

ows_CoconutTestDocumentType → RefinableString134

and:

ows_CoconutTestResource → RefinableString135

The normal Search Schema interface would not allow us to complete this successfully.

A reverse-mapping attempt also resulted in:

SettingDoesNotExist

We then attempted to bypass the classic interface using PnP Search Configuration.

Set-PnPSearchConfiguration accepted the Search Configuration XML without reporting an exception.

However, when we subsequently exported the site Search Configuration, the Search Schema section was still effectively empty:

<SearchSchemaConfigurationSettings i:nil="true" />

and neither RefinableString134 nor RefinableString135 contained the expected mapping.

We therefore treated that mapping as not persisted, rather than continuing to wait indefinitely for propagation.

This is why we are increasingly of the view that the problem is within the Search Schema configuration/provisioning/persistence layer, rather than normal document crawling or indexing.

Microsoft Support case

We already have an active Microsoft Support request and have repeatedly asked for this to be escalated to someone who specialises in SharePoint Search/Search Schema.

I have supplied screenshots, configuration details, reproduction steps and new technical findings throughout the investigation.

The difficulty is that I am repeatedly being asked to provide information that has already been supplied.

I have specifically asked Microsoft Support to:

1.      Escalate the case to somebody experienced with SharePoint Online Search and Search Schema.

2.      Arrange a mutually agreed date and time for a call.

3.      Arrange a remote session so that I can demonstrate the problem directly.

4.      Work through the Search Schema behaviour together rather than continuing to exchange the same screenshots and basic checks.

5.      Investigate whether there is a service-side Search Schema issue affecting the tenant.

Unfortunately, communication around the case has been very difficult.

I have explicitly stated that I am located in New Zealand and have asked several times for calls to be scheduled.

Despite this, I have received calls at approximately 1–3 AM New Zealand time, calls in the evening outside my working hours, and unscheduled calls during meetings and normal BAU responsibilities.

I have repeatedly requested that a date and time simply be agreed beforehand, but unscheduled calls continue to occur.

The most discouraging experience occurred roughly two weeks into the support case.

During a remote session I was asked to reproduce the entire issue again and start a screen recording, effectively returning to the beginning of the investigation.

When we began showing the Search Schema behaviour, it became apparent that the person assisting did not understand what we were demonstrating or the significance of the Search Schema properties being shown.

After approximately two weeks of providing information and troubleshooting results, being placed back at the starting point was extremely discouraging.

We also have a company project deadline that depends on this Search Schema functionality, so the time involved in repeatedly reproducing and documenting the same information is having a genuine business impact.

What we are asking Microsoft for

At this point I am not asking for another standard checklist covering reindexing and Search visibility.

Those checks have been completed.

I would greatly appreciate assistance getting this in front of the appropriate SharePoint Search/Search Schema engineering resource who can look at the discrepancy between:

The effective Search backend

where the automatically generated managed properties are populated and queryable,

and:

The Search Schema administration/configuration layer

where those same properties cannot be consistently located/opened and the required crawled-property-to-RefinableString mappings cannot be established or persisted.

If Microsoft determines that this is simply a propagation/service-processing issue and that we need to wait a defined period, that information alone would be extremely useful.

We need transparency about whether:

·        there is a known service-side issue;

·        a backend Search Schema job is pending;

·        Microsoft needs to perform remediation;

·        our tenant requires Search Engineering intervention;

·        or there is another supported configuration method we should be using.

At the moment the most difficult part is not knowing which of those situations applies while continually repeating troubleshooting that has already been completed.

I will absolutely update this thread for other administrators once Microsoft establishes the underlying cause or provides a supported resolution, as I suspect other tenants may encounter the same symptoms.

If you have any ability to help direct this towards the SharePoint Search/Search Schema team, or if there is specific terminology I should use in the support case to reach that engineering group, I would greatly appreciate it.

Thank you again for your response and for acknowledging that the investigation may now require backend review.

Regards, Andrew
Daniel-Vo 6,610 Reputation points Microsoft External Staff Moderator

2026-09-15T09:23:34.14+00:00

Hi @Andrew Maybir ,

I see that you already have a ticket; unfortunately, as a forum moderator, I do not have the tools or authority to assist you with this matter. Regarding the difficulties you are experiencing with the agent, please email their superiors to lodge a complaint - contact details are usually included in the agent's email signature.
Joywin D'Souza 21 Reputation points

2026-09-15T18:29:00.6533333+00:00

I was facing this issue where in admin center search schema i was not able to find the crawled property. The crawled property is created, the problem is it does not show in search schema when you search. I had a column call OperationStatusDetails and the crawled property it created was ows_OperationStatusDetails. What ever i entered in search bar like Operation, OperationStatusDetails and ows_OperationStatusDetails, it showed no results. I searched for ows_ and was able to find ows_OperationStatusDetails. Please check if this works
Daniel-Vo 6,610 Reputation points Microsoft External Staff Moderator

2026-09-17T12:47:33.1033333+00:00

Hi Joywin,

You can refer the answer of Andrew. Besides that, it is a backend issue, I recommend you create a support ticket in Microsoft 365 Admin center.

Answer 2

So, I'm learning from a friend who works with another company. They raised the same issue with Microsoft support, and then a week later, Microsoft came back saying that this has been a global SharePoint issue and that Microsoft support said that there was a fix rolled out globally, yesterday 16/09/2026.

I think this is a very poor display of communication internally for Microsoft, as you'd think that this information would be shared amongst their team and then relay that out to their customers and a lack of transparency if they knew what the issue was and they kept it from their users.

I've also found a good workaround via PowerShell PnP. Follow this link and you will find the answer. https://www.techmikael.com/2020/11/mapping-or-clearing-crawled-property-to.html?utm_source=chatgpt.com

Context: This approach uses PnP PowerShell with a dedicated Microsoft Entra ID app registration to authenticate to SharePoint Online and work with the SharePoint Search Schema programmatically. Since September 2024, PnP PowerShell requires users to supply their own Entra ID application registration for authentication.

Step	What to do	Why / what it means	Example
1. Confirm the required IT/admin access	Before creating anything, confirm whether your organisation allows users to create Entra ID app registrations.	Some tenants allow normal users to register apps; others disable this. If app registration is disabled, ask IT either to create the PnP app for you or temporarily/appropriately assign the Application Developer role. An Application Administrator or Cloud Application Administrator can also create and manage app registrations more broadly.	Ask IT: “I need an Entra ID app registration for delegated PnP PowerShell administration of SharePoint Online.”
--------	--------	--------	--------
1. Confirm the required IT/admin access	Before creating anything, confirm whether your organisation allows users to create Entra ID app registrations.	Some tenants allow normal users to register apps; others disable this. If app registration is disabled, ask IT either to create the PnP app for you or temporarily/appropriately assign the Application Developer role. An Application Administrator or Cloud Application Administrator can also create and manage app registrations more broadly.	Ask IT: “I need an Entra ID app registration for delegated PnP PowerShell administration of SharePoint Online.”
2. Understand the SharePoint privilege required	The person running the Search Schema changes also needs appropriate SharePoint rights.	For site-collection Search Schema changes, the signed-in user should be a Site Collection Administrator. For tenant-wide Search Schema work, involve a SharePoint Administrator. Microsoft documents that tenant administrators and site collection administrators can manage Search Schema at their respective scopes.	Site-level mapping: Site Collection Administrator. Tenant-level mapping: SharePoint Administrator.
3. Create a dedicated Entra ID app registration	Go to Microsoft Entra admin center → App registrations → New registration. Give it a descriptive name and normally make it single-tenant: Accounts in this organizational directory only.	The registration provides the Application (client) ID that PnP PowerShell uses during authentication. It is better to create a dedicated PnP/admin app rather than reuse an unrelated business application.	Example name: `PnP-SharePoint-Search-Admin`
4. Configure authentication for interactive use	Configure the app for a delegated interactive/device-code authentication flow appropriate for PnP PowerShell.	This solution is intended to run as the signed-in administrator, not as a background daemon. PnP supports both interactive browser authentication and Device Login using your own Client ID.	No client secret is required for the interactive/device-login approach used here.
5. Configure API permissions using least privilege	Add only the delegated Microsoft Graph/SharePoint permissions required by the PnP commands you plan to use.	Do not simply copy a large permission list from another tenant. Current PnP PowerShell includes `Get-PnPCommandPermission`, which reports the delegated/application permissions and minimum SharePoint role required for a particular cmdlet.	Example: `Get-PnPCommandPermission -CommandName Set-PnPSearchConfiguration`
6. Request admin consent where required	Ask the appropriate Entra administrator to review and grant consent for permissions that require organisation-wide/admin consent.	Creating the app and granting API consent are separate operations. A user may be able to create an app but still be unable to approve its requested permissions. Cloud/Application Administrators can grant many types of consent; particularly privileged Microsoft Graph permissions may require a higher role such as Privileged Role Administrator.	IT/security should review the exact permission set before granting consent.
7. Record the Client ID	From the app's Overview page, copy the Application (client) ID.	PnP PowerShell requires this when connecting with your own Entra application.	`$ClientId = "<APPLICATION-CLIENT-ID>"`
8. Install PowerShell 7	Use PowerShell 7 (`pwsh`), rather than legacy Windows PowerShell 5.1.	Modern PnP PowerShell is designed for current PowerShell versions, and keeping it separate from old Windows PowerShell avoids module/runtime compatibility issues.	Open PowerShell 7 and run `$PSVersionTable.PSVersion`
9. Install PnP PowerShell	Install the PnP.PowerShell module if it is not already present.	PnP provides the SharePoint authentication, Search Configuration and Search query cmdlets used by this solution.	`Install-Module PnP.PowerShell -Scope CurrentUser`
10. Import/verify PnP PowerShell	Confirm the module is available before connecting.	This prevents troubleshooting authentication when the actual problem is simply a missing module.	`Get-Module PnP.PowerShell -ListAvailable`
11. Define generic connection variables	Set the app Client ID and target SharePoint site URL.	Keeping these in variables makes the later commands easier to read and reuse.	`$ClientId = "<APPLICATION-CLIENT-ID>"` `$SiteUrl = "https://contoso.sharepoint.com/sites/example"`
12. Authenticate with Device Login	Connect using the dedicated Entra app.	Device Login opens a Microsoft authentication flow where the administrator signs in normally, including MFA/Conditional Access where applicable. PnP supports `-DeviceLogin -ClientId` specifically for this scenario.	`$conn = Connect-PnPOnline -Url $SiteUrl -DeviceLogin -ClientId $ClientId -ReturnConnection`
13. Verify the connection	Query the connected SharePoint web before making changes.	This is an important safety check. It proves you authenticated successfully and are connected to the intended site collection.	`Get-PnPWeb -Connection $conn \| Select-Object Title,Url`
14. Only then perform Search Schema operations	Once the connection is proven, use the PnP Search Configuration commands or your mapping script.	`Set-PnPSearchConfiguration -Scope Site` changes Search Configuration for the current site collection, whereas `-Scope Subscription` targets the tenant scope.	Example site-scope operation: `Set-PnPSearchConfiguration -Scope Site ...`

A useful blog-friendly way to describe the permissions is:

You do not necessarily need Global Administrator rights to build this solution. The person creating the Entra application needs permission to register/manage applications, while the person granting API consent may need an appropriate Entra administrator role. The administrator executing a site-level SharePoint Search Schema change should be a Site Collection Administrator for that site. If application registration is disabled for normal users, involve IT and request either an Application Developer assignment or have an Application Administrator / Cloud Application Administrator create and manage the application on your behalf.

For the API permissions themselves, I would deliberately not publish a fixed blanket permission set because it depends on which PnP commands the reader uses and PnP's permission requirements can evolve. Instead, tell readers to run:

and, if they also intend to query Search:

PnP specifically recommends this method so administrators can determine the minimum permission set before modifying the Entra app registration.

Once authentication is working, the overall solution becomes:

Daniel-Vo 6,610 Reputation points Microsoft External Staff Moderator

2026-09-17T12:45:54.4633333+00:00

Thank you for your update Andrew.

Answer 3

Baader, Stefan 15

Similar issue in our tenant. New created properties not found in Crawled Properties

0 comments

Answer 4

Tone Engebretsen 0

Similar issue in our tenant. New created properties not found in Crawled Properties

0 comments