Which is the best way of limiting search results to a specific subsite when using the search REST API in SharePoint 2013?

I've tried adding a new content source ("MySubsiteContentSource") (in addition to the default "Local SharePoint sites") that specifies the subsite http://localhost/subsite as the single start address, but I'm unsure of whether this is the right approach and in either case I haven't been able to filter the results to only use this content source.

I've also tried to create a custom result source that uses the transform {searchTerms} ContentSource:MySubsiteContentSource, but when adding &sourceId=[id of the result source] to the query I'm getting an error stating that the sourceId parameter is invalid.

Last, I've tried queries on the form:

http://localhost/_api/search/query?querytext='test path:http://localhost/subsite/*'

But this returns 0 results. Even specifying http://localhost/*as path returns 0 results. When I just use query?querytext='test' I get results, but for the whole site collection (as expected).

I get the same behavior when searching from the search center app GUI. If I specify the id of the subsite web in the query (using webid:[guid]), I get the results I'm after, but I would really rather not hard-code guids like that.

  • What was your url when you tried with sourceId='{source GUID}'? I kept getting Bad Request's, and it turned out I forgot the single quotes around the GUID.
    – wjervis
    May 23, 2014 at 13:38
  • Not an answer to your question but maybe this tool is helpful: sp2013searchtool.codeplex.com
    – joweiser
    May 28, 2014 at 9:36

2 Answers 2


I think it should be:


I have tested it at my end and it only shows the data from the subsite.

If you need more help on search using REST, I found this page to be useful (version taken from the Internet Web Archive)

  • Does not work for me, still getting zero results. May 26, 2014 at 6:31

It turned out that there was a problem with the "alternative access mappings" of the site collection. In my case, I had set up the application in IIS to listen on port 8080 (http) and 8081 (https). I'm not sure exactly where the problem was, but after removing the alternative access mappings (only keeping one - 8080/https) and rebuilding the search index, the path filter started working (without any modifications - I had it right from the start, though the asterisk is unnecessary).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.