How to prevent the 'sub-navigation' fragment from polluting search results?

Capabilities Search
, ,
1

Hi

We’re running into an issue where a custom fragment is polluting our search results, and we’re looking for the best way to fix it at scale.

We have a custom fragment named ‘sub-navigation’ that is used across roughly 1,000 pages. Right now, if a user searches for any text contained within that sub-navigation, every single one of those 1,000 pages pops up in the search results.

We absolutely still want these pages to be searchable based on their actual page content, but we need the indexer to completely ignore the text inside the ‘sub-navigation’ fragment. Since it’s on so many pages, we need an automated or centralized way to do this rather than a manual page-by-page fix.

What’s the recommended approach here?

1 Answer

1
2

Hi Kristof,

Each fragment has a checkbox “Hide from Site Search Results“ in Advanced tab, which (from what I understand), should hide the fragment contents from the portal search. Did you already try that?

Screenshot 2026-03-30 at 11.14.00
Screenshot 2026-03-30 at 11.14.00431×442 31.3 KB

Yes, that is correct. However, as stated in the question : Since it’s on so many pages, we need an automated or centralized way to do this rather than a manual page-by-page fix.

 –

I had a quick look at the code, and it seems that the only option is to write a FragmentEntryLinkListener that modifies the indexed config field when a new fragment instance is created. But maybe someone else will propose a better solution.

 –

I believe we had a similar situation and resolved pretty effectively with a groovy script. The script would iterate over the layouts and find the config to then make the update so the fragment was not searchable. It was kind of complicated, but it worked. If that approach seems of interest I may be able to locate it.

 –