SharePoint 2013 Searching for a URL
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 In SharePoint 2013, the entire URL is tokenized as one word. This includes special characters such as “
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.
|
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.
$ssa=Get-SPEnterpriseSearchServiceApplication $pathmp= Get-SPEnterpriseSearchMetadataManagedProperty -SearchApplication $ssa -Identity "Path" $pathmp.GetMappedCrawledProperties(10)
|
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} $newpathmp.Update() |
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.
Comments
- Anonymous
August 28, 2014
Thanks for this post. It assisted me greatly in resolving a URL 'contains' search issue. Well done. - Anonymous
January 05, 2015
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? - Anonymous
April 03, 2015
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? - Anonymous
April 03, 2015
@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? - Anonymous
April 06, 2015
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... - Anonymous
April 10, 2015
Have you tried using a wildcard search like newpath:norm* - Anonymous
April 15, 2015
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. - Anonymous
August 28, 2015
Thank you very much! - Anonymous
September 30, 2015
Great . Thanks for sharing - Anonymous
October 02, 2015
Do you know if something similar is possible in SharePoint Online? - Anonymous
October 02, 2015
@Mike I haven't tried it with SharePoint Online, but I expect it should work. - Anonymous
March 28, 2016
Can we search against the full path
ex: newpath:http:yahoo.com ? - Anonymous
March 28, 2016
@Basant that should work make sure you include the '//' you might need to quote the url newpath:"http://yahoo.com"