Peter Dempsey

Principal Premier Field Engineer (Fast ESP / Fast Search for SharePoint / SharePoint 2013)

SharePoint 2013 Searching for a URL

SharePoint 2013 Searching for a URL

  • Comments 11
  • Likes

My colleague Igor Veytskin and I have run into a few issues when trying to search for a document in SharePoint 2013 based on its URL. If you take a look at the Managed Properties returned in search results, you'll see where the URL is stored. It is stored in the 'Path' managed property. The Search Query Tool is very useful see the values of managed properties that may not be displayed or returned for your results page. Here is a search for 'team' that shows the Path managed property.

If you search on an exact url within Path, then you will find the document with that URL

The problems arise when you would like to search for just a part of the URL within 'Path' or search for part of the URL in the full text index. This does not work in the out of the box setup.

This is because Path is set as "Complete Matching"

The reasoning for this configuration is mentioned here: Changes from SharePoint 2010 to SharePoint 2013

URL Query syntax

Description: In FAST Search Server 2010 for SharePoint, the URL-related managed properties (such as site, or path) are tokenized as a text string, and you can query any subpart of the URL. This includes STARTS-WITH, ENDS-WITH, PHRASE and proximity queries on URL properties. Special characters such as “/”, “_” and “-”are handled as word delimiters.

In SharePoint 2013, the entire URL is tokenized as one word. This includes special characters such as “/”, “_” and “-”. You can query these managed properties by:

  • Searching for the full string for the site or path.

  • Searching for the leading part of the site or path.

  • Omitting the protocol part (http, https), and omitting the leading part of the domain address in the query expression, for the site managed property.

Reason for change: The implementation in SharePoint 2013 is aligned with SharePoint Server 2010 search. The FAST Search Server 2010 for SharePoint implementation has a very high query performance cost, especially when you search for the full URL or a leading subset of the URL.

Migration path: The following table provides details on how to change FAST Search Server 2010 for SharePoint query expressions to match the SharePoint 2013 URL query syntax.


To matchThen

The complete URL string

Search for the exact string. Special characters in the URL must match. Do not use the PHRASE operator.

The leading part of the URL

Do not use the wildcard character.

Any part of the URL

  • Map the relevant crawled property to an additional managed property of type text.

  • Use this managed property as a property filter in your query.

Many customers are willing to trade off some additional space in the index and tokenization processing to be able to search on parts of the URL. This is how you set it up. First off, it is a  good policy never to change the default managed properties if you can avoid it. So, we'll create a new Managed Property called 'newpath'. You can create the property as normal using the GUI, but we'll need to handle mapping crawled properties in PowerShell. We want to use the exact same crawled property mapping that Path uses. First create the new managed property.

We will leave Complete Matching unchecked

We will also add Searchable, so we can search against the full text index.

Leave the crawled property mapping empty.

Next is the crawled property mapping. Start by getting the Path managed property and displaying the mapping.


$pathmp= Get-SPEnterpriseSearchMetadataManagedProperty -SearchApplication $ssa -Identity "Path"


Now create the same mapping for newpath. We use PowerShell since that allows us to easily select the exact same propset and name that Path is mapped to.

$newpathmp= Get-SPEnterpriseSearchMetadataManagedProperty -SearchApplication $ssa -Identity "newpath"

$pathmp.GetMappedCrawledProperties(10) | ForEach-Object {
  $cp = Get-SPEnterpriseSearchMetadataCrawledProperty -SearchApplication $ssa -Name $_.Name -Propset $_.propset
  New-SPEnterpriseSearchMetadataMapping -SearchApplication $ssa -ManagedProperty $newpathmp -CrawledProperty $cp


Now you'll see the mapping in the GUI

After a full crawl of your content source. Testing searching on the newpath managed property:

Testing against the default full text index with a subset of the URL. This will not work out of the box

Searching for the same subset of the url against path. This is what you'll get with an out of the box full text search.

  • Thanks for this post. It assisted me greatly in resolving a URL 'contains' search issue. Well done.

  • Hi. I wish this worked for me. This is exactly what we have been looking for at my current client, however, after following the steps in your post the new managed property value always shows up blank. Even after the full crawl. Is there perhaps a step that might be missing?

  • Hi. I've seen that this works (oob) depending on the search text.
    For example I have the path .../sites/pspn13/Documents/normal folder.
    - If I search for "normal" then it appears in the results
    - If I search for just part of the word "norm" it doesn't. This doesn't change with the new managed property "newpath".
    Like @Heather asked, is there something that we are missing?

  • @Heather @Tudor do you have more than 10 crawled properties mapped to path? Do you see data in newpath? Is newpath set to be retrievable?

  • No there are only 3 crawled properties: Basic:11, Basic:9, Web:2
    newpath comes with data if I explicitly put it in the selected properties filter (so, it's retrievable)
    Does it work for you? To search for a substring from a folder name for example...

  • Have you tried using a wildcard search like newpath:norm*

  • Found out that if I check the option "Include in full-text index" for the crawled property Basic:9 (which is linked to the Path column - guid: 49691c90-...) and re-crawl, then I can perform searches like "documents normal" or "folder1/subfolder". So, this was my workaround.

  • Thank you very much!

  • Great . Thanks for sharing

  • Do you know if something similar is possible in SharePoint Online?

  • @Mike I haven't tried it with SharePoint Online, but I expect it should work.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment