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 '14 at 13:38
  • Not an answer to your question but maybe this tool is helpful: sp2013searchtool.codeplex.com – joweiser May 28 '14 at 9:36

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 the link below to be useful


  • Does not work for me, still getting zero results. – Anders Fjeldstad May 26 '14 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, privacy policy and cookie policy

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