When you start learning SharePoint, they teach you about columns and site columns. In SharePoint 2013, everyone talks about the new search and what can be done with it. However, we rarely start from the beginning and explain the basics. To start anything with search-related features, you’ll need to understand crawled and managed properties and the difference between the two.
The basics of SharePoint search
One of the biggest issues I see with SharePoint is how little organizations know about search and the time and effort that needs to go into it. There’s a lot that goes into the configuration alone, and I highly recommend you investigate things like topology, content sources, and crawl schedules, among many other things. But for the purpose of this article, let’s cover the basics of crawling with search for SharePoint.
Pretend for a second that the building where you work is your SharePoint farm. It’s brand new and completely empty, and the rooms represent your SharePoint sites. To be able to ask the search engine what you have in each of these rooms, you’ll first need it to run around the building and take notes of everything. This is what we call crawling.
In SharePoint, content is automatically crawled based on a defined schedule: the crawler picks up content that has changed since the last crawl and updates the index.
At this point, many people assume that the columns they created in their lists and libraries are now searchable. However, in most cases, it’s still not the case.
Fortunately, understanding SharePoint metadata is the key to efficient searching, and it will create a user-friendly system for your organization.
SharePoint search crawled properties
Though there are always exceptions, and I will get to them shortly, once the indexer passes and crawls your content and its metadata, it adds the columns as crawled properties. This means it has passed over your columns and the metadata assigned to each element. You don’t have any control over the creation of crawled properties: they’re the resulting list of columns crawled in some way, though I’m oversimplifying it.
A crawled property by itself is useless when you’re trying to run or build search queries or even display this property’s value in search results. In our previous example, take the crawled properties as the information collected by going around your building. The crawl goes through your sites, lists, and libraries to find your content, picks up the value in your columns, and stores them as crawled properties.
SharePoint search managed properties
Though they have many features and configurations to them, at the core, managed properties are the grouping of one or multiple crawled properties. And here is where it all happens. If you need anything to be search related, like Search Results, Content Search, Refiners, Display Templates, and so on, then you need to understand how to create and manage these managed properties.
Let’s say your organization has many lists and libraries, and users created columns like “Customer Name” and “Client” in them. These two columns might represent exactly the same content for the organization: for search, though, they’re just crawled properties—and two very different ones, because they don’t share the same name.
On top of that, since they’re only crawled properties, if someone searches for all documents where Client = Sharegate, then they’ll find nothing at all. Why? Because no search-related feature works with crawled properties themselves: for that, you’ll need to create a managed property called “Customer” and assign both of those crawled properties to it.
In some scenarios, though, you may find that a managed property has been automatically created for your crawled property. That’s because, as always, there are exceptions. If you create a Site Column and assign it to a list or library, when the indexer crawls over it, it’ll automatically create a managed property for it. Also, whether it’s a site column or not, Managed Metadata columns will always have a managed property created for them.
Where do I create and manage these properties?
Now that we understand the difference between the two at a high level, we’ll need to know how to see the crawled properties our search engine collected and created as well as the existing managed properties. Back in the day, you had to go to SharePoint or Office 365 Central Administration to create them, which is not the case anymore. This is what I still recommend, though, as these will be global and centralized for all web applications associated with this search service application. However, certain Site Collections might need their own Managed Properties and isolate them there.
To navigate, edit, or create these properties, you just need to find the Search Schema under “More Features” in your SharePoint Admin center’s main menu.
The problem with optimistic title override and the title managed property
I take no credit for this since I learned it from a true SharePoint Search king, Mikael Svenson. The problem we’ve been experiencing with SharePoint Search is its over-willingness to help improve search results. You see, search has an integrated feature that extracts what it thinks is your document title and show it in search results, regardless of the value you entered in the Title column.
For example, the search engine will take your Word document headings or the first slide with large text in a PowerPoint presentation and override any other title you specified. This was very unpleasant, as you can imagine: many documents would often have the same heading as if they were the results of a filled-out form. Then, SharePoint would hide our documents in search results, calling them “duplicates.”
Since SharePoint 2013, you’ve been able to see this “special” crawled property in your Title managed property.
As you know by now, SharePoint search results and any other search-related feature can only show and work with managed properties. So if the Title being displayed is wrong, we need to go to the managed property responsible for it and see what crawled properties are assigned to it and in what priority order. In the past, we couldn’t see this special crawled property with the highest priority and adjust it. Fortunately, that’s not an issue anymore. Thank you, Mikael!
Before upgrading SharePoint with a new search solution
You need to understand crawled and managed properties to have a successful and meaningful SharePoint search engine. We all like to kick and scream at SharePoint for not providing us with meaningful results, but, in most cases, it’s due to a lack of configuration.
SharePoint’s search features have improved for some years now, helping us build search-driven sites with the Content Search Web Part or the Catalog feature to integrate them straight into a publishing site. But if we want to take complete control of these features and what they show our visitors, we first need to understand these basics.
I strongly recommend you go through the Microsoft documentation to learn more about crawled and managed properties. Once you feel you have grasped this concept, you will be ready to attack some cool concepts and build awesome things with SharePoint!
