What is the problem you are trying to solve?
We have an implementation with 7 Sites, we use Site scoped search with the Result Ranking feature, but would like to be able to set the scope of the items we are pinning so they are only pinned in the Search Results of the Site the items reside in. So if I perform a search within Site A, I only see matching pinned items from Site A.
What is your project about? (e. g. Intranet, Partner Portal, Enterprise Website, etc)
A Customer Portal for a utility company with 7 distinct Liferay Sites, one for each regional subsidiary where customers are members of a single Site based on their regional subsidiary.
What is your proposed solution? (optional)
We would like to see the existing development feature flag LPD-6368 progressed to general availability and made available / backported to 2026.Q1.x.
We need to be able to use the same Search Query for each Site (with different pinned results for each Site occurrence) which is currently supported by the LPD-6368 feature flag, but when the Scope is set to Site we should show the Site Name on the Result Rankings grid screen so we can clearly see which Site the Search Query relates to from the Grid Screen.
Thank you Mike. Following-up on our internal discussion, as your initial testing results look promising, we can look into how much effort it would be to make it GA-ready. When development was parked, we recorded a few aspects and open questions that we have to revisit if we wanted to move forward with the release.
For now, I’ve linked this post on the Initiative ticket in our Jira.
Regarding this, we display the name of the site on the Customize Results screen already:
we should show the Site Name on the Result Rankings grid screen so we can clearly see which Site the Search Query relates to from the Grid Screen.
@michael.wall Where else would you like to see the scope being displayed?
Hi @tibor.lipusz.liferay on the grid screen showing all the Result Rankings. See the example below, I have defined fruit as a Search Query in 4 separate Sites but if I want to tweak the setup in Site A, I need to open each in turn until I find the one that is for Site A. In my use case I will have the same Search Query defined 7 times for most of my Search Queries, so including the Site Name will improve the usability.
Ah, I see. If you hover your mouse over the text “Site”, it shows the name of the actual site in a tooltip. But I agree, it may be better if it was displayed by default in the column.
Hello Michael,
The site scoping feature is intended for later release because it clearly helps with multi-site setups.
However, some additional development is required, the two most important are listed here:
-
Providing backward compatibility: Currently, when the Developer feature flag is enabled, all existing ranking entries are treated as if their scope were ‘Everything.’ This means they only apply to searches with ‘Everything’ as the scope (no site scoping => searching everywhere).
- We need to revisit how to provide backward compatibility so that existing ranking entries can still apply to searches with ‘This Site’ scope on sites without requiring users to manually recreate and duplicate ranking entries.
-
Rethinking the blueprint scope: Curated results organize which results appear at the top, their order, and which items should not appear at all for specific keywords. Blueprints customize how to search by applying pre-filters, boosts, and custom query clauses and configurations. Tying a curated list of results to a particular blueprint creates a confusing relationship; it should be independent of how the search is constructed. Therefore, we will revisit the Blueprint scope—which becomes the 3rd option when the Developer feature flag is enabled, allowing an RR entry to be scoped to a blueprint—and may eventually rework or remove it, or at least split it from the site scoping feature.
- Instead, we can consider providing the ability to apply a blueprint to the Customize Results screen on-the-fly. This would allow the admin to quickly check what results the selected blueprint would return for the given keywords and then pin, reorder or hide them. But at search time, only the user’s keywords and the scope they are searching within should matter. (To be decided.)
These and a few other to-do items are currently being tracked at Jira . (The actual scope can change as we refine it.)
Regarding the tentative release timeline, I want the site scoping feature to be Generally Available (GA) in 2027.Q1 LTS and Release Feature Flag status in 2026.Q4 at the latest. This is not a firm timeline, but rather the intention. As usual, this will be communicated in the Release Notes.
Regarding the current state in 2025.Q1 / 2026.Q1: I was glad to hear that your testing concluded with positive results when using site scoped RR entries with the Developer FF enabled. As I mentioned above, you should probably avoid using the blueprint scoping in production environments because it will likely be reworked.
