+1 This functionality would definitely help us declutter search results and help users find the content they're looking for.

This would be a game-changer for our team! We're currently evaluating competing platforms due to the frustration and confusion this causes for our users.

We have a separate space for our team huddle notes and this content spills over into our search results when trying to use our other KB specific space.

+1 We store customer/meeting notes in personal spaces. We want these pages to be accessible to everyone, but not have them available in the global search. There is not an easy way to exclude these pages. 

Being able to easily exclude all personal spaces and/or all meeting note pages would be great.

Please help us spread the word and share it in social media to get more votes  feel free to retweet our post if you like. https://twitter.com/nmc_info/status/994638611499966464 

I up-voted as well for our team. We're a service firm: when we finish a project, I'd love to "demote" its pages while leaving them available for browsing.

This would be extremely helpful. Our experience is that Confluence becomes a massive pile of pages.. and search results often show tons of older, less-relevant pages.

I'd think to add this option to the Restrictions interface... and that it would behave the same way: a child page would inherit its settings from a parent page.

I imagine pages and spaces should have three states, not two:

1. Active page, as today. In search results, browsable, etc.
2. Less-Active page, still content that you want available, but 'demoted' to a child state when it comes to search. I want these sorts of pages to remain in my browsable hierarchy, but I want them ignored for search purposes.
3. Archived pages, no search, no browse.

I think this feature request really is about improving search results, not about page attributes or states. I'd like search to be much more useful... and by 'demoting' various pages and nested directories of pages, the important stuff can float to the top. That's the theory anyway.

Super useful!

Concurring. We have how-to's that are useful for specific teams that I have to put a disclaimer at the top of to ignore for all but a select few. We also want to keep documents for historical purposes.

Concurring. We have how-to's that are useful for specific teams that I have to put a disclaimer at the top of to ignore for all but a select few. We also want to keep documents for historical purposes.

We store tons of retrospective journals as pages. We need them to be accessible by everyone but in the same time they quite pollute search results page. Those pages shouldn't be indexed. Now we can't protect them properly except that moving them to private space

Please add this feature. It doesn't seem like it would be that hard to flag something as either available or unavailable for search results.

The lack of an "unlisted" property on pages or even whole spaces — which excludes them Search results — has been a major pain point for me at three different major startups over the course of five years. It continues to be for us right now.

Stakeholders become immediately frustrated with navigating page trees in Confluence, and shut down when the Search results are indecipherable (because years of content is unintelligibly piled onto the results page). This has led to Confluence being infamously impossible to navigate across all teams at every company I've touched — and to be frank, it makes Confluence near-useless to developers, who are touchy about process and don't tend to dig for anything.

You must, must update the community with confirmation that you're hearing us on this.  Dropping this comment on CONF-35817 as well since either feature would be so deeply impactful.

Just to echo some of the others here, we also have a library of reuse content that's being included in other pages. We've moved the reuse content to the top node as in order to hide it from the end users. But these pages are still returned in the search results, which is confusing for users and disrupts the flow we're trying to achieve. This feature would be very handy.

Adding my two cents. We have pages for software releases and build notes that contaminate the results and make the search unusable for users that are not advanced enough to use filters. 

Thanks, fred.bunting. I've commented on CONF-35817. As to marking spaces as 'archived' - this is not an option for my use case. I want the space to show up in the Space Directory, for example. I just don't want its pages to 'clutter' search results.

@Nitza, it sounds like your comment belongs in CONF-35817, which is about being able to exclude entire spaces from search results.  This ticket is about being able to exclude individual pages from the search results.

But the workaround is just mark the space as Archived.   Despite the name, it doesn't actually do anything to the pages ... it just hides pages in the space from search results, until requested.   

Adding my voice as well. We have spaces such as glossaries, that should not be archived, yet clutter search results unnecessarily. It would be good to be able to exclude them from search results. 

+ 1

We are looking for something similar to this as well. We want to customize the quick navigation search bar to only populate pages, not attachments, when a search is conducted. The current search shows pages AND attachment results.

+1

We have a 2-part requirement that goes like this:
1. We'd like to periodically add some reports – attachments and/or pages – to selected spaces (probably in the hundreds of spaces) via the API. In a bit of experimenting, we've found that doing so starts an indexing storm which affects performance.
2. We don't want to index this material anyway. Much of the content will contain references to terms that exist across the instance. Indexing would be counterproductive for users with access to the reports, cluttering their searches. They'll know where their reports are and how to deal with them.

If we were to try to get around this by temporarily archiving the space, uploading the data, then unarchiving, I'm assuming the indexer will just catch them the next time around, so that seems not to be an option (let me know if I'm wrong).
Best, it seems, to be able to simply flag resources as 'index this thing' or 'don't index this thing'. Thinking a step further, if people were able to change that from 'don't index' to 'do index' after the resource has been added, that wouldn't be the end of the world. It probably wouldn't happen often.

@Normand, Actually: i'm not sure what that property does, but as I said, for us, we found a fix through adapting the interface. We haven't got any spaces which we want to exclude from search results anymore.

@Jacob-Jan: Why don't you use the space-wide property "Archived", which excludes the whole space from the search index?

For our company, we use two main spaces, a space which is maintained by hand and a space which has the same pagename, but with information gathered through an interface with an external system. The page in the 2nd space is included in the first with a page include.
As a result, when i search for a page name I get two results.
So for us: we would like to exclude a whole space from the search results.

__

Edit: we have found a different solution, the interface now directly edits the main page (in my own terminology: it downloads the current content, maintained by hand, and adds all information from the separate system.) So for us, this is no lunger a must-have.

Thanks for the hint Fred. I voted for CONF-35188 as well.

(Sidenote: I was trying to add a mention for Raphael Thoma, and tried highlighting his name and choosing Insert > User mention, as well as @rth1, and neither worked. How do I add a mention?)

@Raphael Thoma comment on 05/Dec/2014 is another issue ... being able to exclude personal spaces from search results.

Oddly enough, this used to be a feature in the search interface (the ability to restrict search to site spaces), but disappeared.

Please comment (and vote) on CONF-35188 to restore this feature.

I have a similar use case to others who have commented here.

I have a (small but increasing) group of pages that each include one small snippet of information that I include on other pages via Excerpt-Include.

Search results should ignore the small pages that contain nothing but one snippet, and find the larger pages that include these snippets.

We have a similar need in my business. We want folks to still be able to access some materials, but we don't want those materials clouding up the search engine. We are looking for this same feature.

Essentially, we have materials that are used in training, and the learners and trainers need to access the information in the training setting. However, we have training materials with very similar titles and content as our process pages, which the end users need to use on a daily basis. So we want the search enging to be dedicated to the process documentation and not be clouded, when searching key words, with the training materials.

We've trained folks to pay attention to the space title when searching, but this would still be a great feature to enhance the end user experience!

+1 for this feature request.

This would indeed be a nice feature. We're maintaining our system documentation in Confluence. At the same time our users fill in their (public accessible) personal spaces.

While searching in confluence it happens that pages from the personal spaces pop up. Some users then think that this page is part of the official system documentation even tough it's just part of another personal space. This is quite irritating for some users - therefore it would be good to be able to exclude some spaces from the search.

+1 for this feature request.

One distinction, however: There is a difference between excluding a page from the index, and just filtering it from search results. Ideally, excluding certain pages should work like archived spaces ... the pages are still indexed, but they are filtered out of search results by default, This is what allows the user to request that they be included in search results if they so wish.

(I'd also like to add my kudos to the Atlassian engineers who updated the indexer ... it is now blistering fast! ... Which means that the cost of indexing pages that most people want to filter out of search results, is not an issue.)

Our primary use case is as others describe ... the ability to create pages used primarily as includes in other pages (such as nav-bars, and lists of links). E.g. we created many pages in our NewProj space, that all shared common include pages with names like NewProj NavBar and NewProj Top Banner, and unfortunately these are at the top of the search results. These are rarely if ever the top pages that people want to find in a search, and yet they invariably clutter up the search results.

This could also be seen as a special case of the wish to archive pages, rather than just spaces. (Currently, "archiving" a page – e.g. the Archiving plug-in – really means moving the page into an Archived space.)

Incidentally, there is a workaround I've toyed with. One could define a label to add to pages – say nosearch – and then a user can manually filter out such pages by adding

NOT labelText:nosearch

to any search query. Unfortunately, that puts the burden on the user to do this.

I thought of this because of the workaround needed to filter out Personal Spaces (add

NOT spacekey:\~*

to queries) ... as the ability to do this using the SPACE pull-down was unfortunately lost when we upgraded from Confluence 5.1 to 5.5. (I filed this as a request in CONF-35188.)

If only there was a way to add filters to the search interface ... (hint, hint).

I may have done a poor job of explaining our use case. The archive plugin probably wouldn't do exactly the thing I need here; it might be a workaround but in our case it would be inelegant. I'll take another quick swing at the use case:

• We have an external web site that is hosted in our campus CMS. It contains hundreds of pieces of user-facing technical support documentation.
• We use Confluence as a "living" internal documentation site, for tech support agents to reference while resolving calls.
• When we conclude a piece of external documentation is no longer relevant to a significant majority of our user base, we remove it from the CMS to avoid clutter and confusion.
• Inevitably, we have calls three years later asking how to configure that old version of some software that can't even be downloaded any more (or what-not), so we've started archiving these documents for internal use. It's a comforting practice so that we're not in the position of just deleting knowledge, but as the documents have collected they begin to crowd the keyword space.

There are several solutions to this issue, but the one that coincides best with our use case is the ability to exclude specific pages from being indexed. I have a couple of other types of pages I'd exclude, as well, but this is the biggest case for us.

@court

Why are you not moving those pages to archive spaces? Those are, by definition, excluded from the search results, activity streams, etc.

To make it easier, use the Archiving Plugin to automate moving your content to archive spaces (also keeping it "well-ordered" by preserving the original page tree structure). That plugin was developed exactly to solve these types of problems.

@jonathan.simonoff
It sounds to me that you are trying to mimic an approval or publishing workflow with this.
If so, consider using this plugin (and saving some grey hair ): https://marketplace.atlassian.com/plugins/com.comalatech.workflow

We also have a use case for this feature. We use a section of our internal documentation space to archive documents which are no longer broadly used by our customer base. We want to keep the information in these documents for reference in the event we receive calls about an arcane issue, but we don't want to pollute our search results with hundreds of pages of content that will not be useful for a vast majority of searches.

Confluence, in our context, is used as an internal documentation repository for a 24-hour IT support call center. The documents we'd hide from search results would be the archives of external documentation hosted on a public knowledge base.

This would be extremely valuable for us, as we have hundreds of archived pages that are well-ordered for browsing, but which contain keywords that collide with searches for more up-to-date internal content.

Hi,

in our case we need to disable search functionality completely to specific users/groups.

That would be a great feature as our customers shouldn't be able to search internal users, groups, pages etc...

So a restriction to users / groups would do the job. Thanks.

Best Regards,
Mario

@Jonathan Simonoff: For tracking revisions vs published pages, have a look at the K15t's ScrollVersions plugin.

Regarding included/reused pages, we created an inclusions library. These included pages are outside the TOC, but still clutter the search results (quote: "The pages will be picked up by other searches, because they are just normal wiki pages." https://confluence.atlassian.com/display/DOC/Creating+your+Technical+Documentation+Space#CreatingyourTechnicalDocumentationSpace-Step5.Createaninclusionslibrary) For this usecase, the option of marking included pages as unfindable would also be valuable.

We have a user who wants to do this because they are using a model where they have a "published" page that is restricted to prevent editing and a "revision" page that begins with the same content but contains proposed (but not yet approved) revisions. The pages have the same name, except the "revision" one begins "Revision". Currently, they show up together in quick search, sometimes with the "Revision" one first.

We also have a problem similar to the one Kirstin mentioned, where we have source pages that exist only to be included elsewhere. Hiding them from search would help users find the correct pages.

For us this would be valuable, because we're using the multi-excerpt macro to reuse content. We've got one page e.g. containing all example references of our product. These examples are included to the documentation via multi-excerpts. Searching for an example would reveal this page, that contains no information for a reader of the documentation. I'd rather hide this page from search results - at least for anonymous users.
But I also could understand, if this like opening Pandora's box for you. I can't overview the consequences of this feature request.

Why do you want this? To be honest, given the thousands of other highly requested features, I can't see us implementing this in the foreseeable future. Just trying to get a bit of context for this.

A property that makes pages "unfindable" – without restricting access to them otherwise – would be valuable for us, too.

We want to prevent certain pages from cluttering up global search results. To access these pages, users will follow explicit links or use the TOC or Favorites.

Similarly, an "untoccable" property should exist to exclude pages from the TOC.

Then under "View in Hierachy" (Space Tools/Content Tools), we could have tabs like "orphaned pages" for "unfindable/untoccable" pages.