Our farm is 2010, but our sites are still in 2007 UI. We're planning to migrate in the next month or so, but for now we're just upgrading the Search site. We're also running BA Insight's Longitude for search previews, but their product has an issue in the 2007 UI that prevents us from effectively using it in production right now, so that's why we're doing the Search web upgrade first.

In order to demo Longitude and the upgraded features of 2010 search to an internal client, we copied their site (Site A) into a new site collection on the same webapp (Site B) and then set up a new search site in that site collection and directed all searches to the new search site. This means we have two copies of these documents now - one set in Site A, and one set in Site B.

I now navigate to Site B and perform a contextual search (eg - This Site, This List). The results from both Site A and Site B are returned, but the links all point to Site B. I know they're partially coming from Site A because the Modified date on all the documents in Site B is their creation date, which is yesterday, and half the results have a Modified date in April. The issue happens in both the Longitude search site and the OOTB search site. The issue also occurs if I do a contextual search from Site A.

Is this a configuration issue, or a bug?


2 Answers 2


All search queries run against a common index regardless of whether the query comes from Site A or Site B. However, given the rather unusual way that you have created your sites, it is quite possible that Search itself is a bit confused.

Go into Central Administration, Application Management, Manage Service Applications, SharePoint Server Search and select that row and click 'Manage' in the Ribbon. Go to Crawl Rules and create a new rule that excludes Site A's URL. You will then need to go into Content Sources and kick off a full crawl of whatever content sources may include Site A and Site B. Once that is done, Site A should no longer be visible in any search results.

Eventually, Site A should probably just be deleted if it is no longer needed.

  • Site B is actually the one that will be wiped in the long-term, this was just a way to test using a different search site in the v4 UI since we only have a single site collection for all the content on this web app (it was like that when I got here). Commented Jul 6, 2012 at 20:41
  • Either way, one of the two sites should probably be excluded from the indexing of content.
    – Dave Wise
    Commented Jul 6, 2012 at 20:46

I tried to use the content exclusion filter in the Search Service Application to remove the duplicate entries and prevent content from that site from showing up. The rule ended up causing both sets of data to be excluded. I removed the exclusion and restarted a full crawl, and now it seems to be working correctly, so I think I'll chalk this one up to bad behavior.

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.