Looking to be able to exclude certain spaces from search also.
Sheila L, I think what you're looking for already exists as an option in advanced search, but I'd imagine it'd be much more user friendly to be able to exclude certain spaces all together so users don't have to pop in and set advanced options.

+1

For the use cases about deprecated documentation and archiving pages to another space, we use Better Content Archiving to handle the move and back in the active space, our default search excludes archived spaces. In my case, we have certain active pages that I want to exclude from the default search.

I'm moving 2000 pages from one space to another. In the original space, the pages will be moved to an Archive folder. I don't want the archived pages to show up in search results. For one thing, the search results are already clogged with thousands of pages. And I don't want users to read or update the archived pages.

For these reasons, we must be able to omit specific pages from the search results. Otherwise, the search results are frustrating and nearly useless.

This would be a useful feature to have for the reasons other users have stated above.

We also would like to do this. We keep records of deprecated documentation for historical purposes, and it would be helpful to be able to exclude these from normal search results.

Not knowing how it was coded or whether search is third-party, it would seem to be as simple as for each filter criteria, enabling a Boolean NOT.

Excluding pages from search results would be very useful for internal team sites where you might want to keep outdated pages for reference  (for example, plans for previous releases) but would not want the pages to come up in search results.

+1

This would be very useful

Yes please! An ability exclude pages from Search would be GREAT for internal organizational docs only needed by one team, or pages being used just for exerpts etc.

An exclude option for speficic pages without weird hot-fixes would be awesome. I mean, that should be technically just a marker that says 'exclude me dear search engine' 

+1 

I will update the status.
When storing documents on a page (Excel, Word), a quick search on them is also carried out, which is very inconvenient. Has anyone found options to hide the search on them?

I tried all the app described above, but did not find anything suitable.

nreiling Finally, how do you fix or workaround use for your use cases?

Here's a use case different from archiving. We have some documentation spaces where pages are categorized in a hierarchy. So the space homepage is the root, the first level is categories, and the second level is documentation content pages. These category pages often don't contain any relevant content, but are named the same as other pages within confluence that are more likely to be what the user is looking for. That means the category pages end up polluting the quicksearch results, and it would be better for them to be hidden from those results.

For example, I have a space that documents internal utilities, categorized by area, for example "Customer Service". If someone is searching "customer service", they are more likely looking for process documentation in a different space. I could name each of these category pages like "Customer Service Utility Documentation", but that would look redundant when browsing the category pages in the space.

@Scott Love – Both inheritance and the three states are really good ideas. Thanks for contributing.

@Aron Gombas – thank you, looks like an interesting app.

I think I have confused things by using the term "archive". I think 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.

That all said, I also want to manage archiving well. Interesting app! Thanks!

@Scott Love, do you know the app called Archiving Plugin?
It does pretty much what you outlined, cleans up content by moving the not-relevant pages to semi-hidden spaces.

I up-voted as well for our team. We're a service firm: when we finish a project, I'd love to "archive" 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, not-relevant pages.

I'd imagine adding 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.

Super useful!

Hello,

my company would also like this feature very much.
It would be very great to exclude older archived projects from search.

Many thanks,
Gerhard

Hi all,

Thanks for your interest in this issue.

While this suggestion has gathered significant interest, we're unable to implement all of the excellent suggestions you make. We appreciate the benefits of such requests, but don't plan to work on this for the foreseeable future.

This suggestion will be reviewed in about 12 month's time, at which point we’ll consider whether we need to alter its status.

Best,
Confluence Product Management

I +1 for this feature.

Although the Drafts workflow is in place and works ok, I find Drafts hard to share when looking to approve final content (sharing with approvers, etc).

Being able to publish, not index, approve it and only then make it properly live would be awesome.

The current workaround i know of is to publish and set viewing restrictions to only the approvers.

But, having a no-index function would also be an interesting solution for deprecating content.

Cheers,

Giuliano

My organization is using Confluence more and more, and I love it but it's beginning to get impossible to find things anymore. It would really help us to be able to remove personal spaces from search results but still have that information accessible.

Looking further ....... this is never going to happen because there are paid add-ons to achieve this . It's al about politics ......

+1 also would like this feature.

I'm very surprised that this feature doesn't already exist. 

It would be extremely useful to exclude specific topics from the internal search feature. 

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.