First make sure to set the startingpoint for search to StartPage of your website, as you mentioned. If you are using WebForms you could use the episerver:searchdatasource control to check if you get the same result. Are you using the built in search in EPiServer 7 or do you use the old FTS that was developed for CMS6? If you har using the old FTS tryt to download the latest search via nuget for episerver cms 7.
You could of cource clear and reindex your content but browsing this adress: http://yoursite/EPiServer/CMS/Admin/IndexContent.aspx This is a hidden gem where you can reindex your website.
Really appreciate your reply! I ended up contacting EPiServer support who helped me through to a solution. Your answer would have solved it for me too - I wasn't aware of the orphaned page http://yoursite/EPiServer/CMS/Admin/IndexContent.aspx and firing off the index from there did resolve the issue :) I guess the index must have gotten out of sync - but I'm not sure why as with the amount of mucking around it should have triggured a full index through initialization but nevertheless the link you and support mentioned somehow indexed it correctly.
I'm experiencing an issue where recycling bin content is being returned in search queries. The website is built on EPiServer v7 and is a fairly simple website with straight forward content using EPiServer FTS for search.
The lucene query sent to EPiServer FTS is the following:
I’ve bolded the key line to focus on. This defines the virtual path that FTS should filter the query of content to. The guid “43f936c9\-9b23\-4ea3\-97b2\-61c538ad07c9” represents the very root node of the site (id 1) and the next guid “5ef8dbb4\-92c0\-4ed2\-9235\-94de3f3a9aad” is the start page of the site – this path looks correct to me as it’s the full path to the start page and has the wildcard to allow all descendants to match. But strangely, though we get content we want, we also get items in the recycle bin.
As an example one of the offending results (in the recycle bin) has the virtual path “43f936c9-9b23-4ea3-97b2-61c538ad07c9|2f40ba47-f4fc-47ae-a244-0b909d4cf988|53ef3bd3-d9e7-4842-ad10-ee3edf7a5761|e4e4889f-ce2a-450b-acdf-bec22e45baa9” which to me shouldn’t be returned since the second item in its path doesn’t match the search filter.
I’m not sure if the index is out of sync or whether the querying has an issue. Any thoughts would be appreciated :)