On TechNet, there is documentation on how to tune ranking using a custom rank profile. This procedure is somewhat cumbersome, and does not allow the full flexibility provided by the FQL xrank operator. Fortunately, there is an easier way, which also opens up for arbitrary xrank statements. Let us take an example. We want to boost "aspx" documents to the top of the result list.
Open a PowerShell on your SharePoint server and run the following commands:
New-SPEnterpriseSearchQueryScope -SearchApplication "FAST Query SSA" -Name "Boost aspx" -Description "A scope to boost aspx pages" -DisplayInAdminUI 1 -ExtendedSearchFilter "xrank(size:range(0,max), fileextension:aspx, boost=5000, boostall=yes)"
The key part here is towards the end:
This will add 5000 extra "rank points", which is typically enough to always bring these documents to the top of the result list. TIP: In order to get an idea of what number of points make sense, and also to debug this process, it can be very useful to see the current rank values. This is easily done by applying the first part of my previous posting, to add the "Show all" toggle.
NOTE: This example uses a simple property and a simple value. You are free to boost based on multiple values at the same time, with different boost leves. This is done by putting multiple xrank's inside one another, like this: xrank( xrank(..., author:thomas, boost=500, ...), fileextension:docx, boost=2000, ...). You can also boost based on ranges, e.g. xrank(..., write>2011-01-01, boost=1000), to boost documents written this year. Unfortunately, there is no easy way to say "written last 3 months", but a workaround would be a scheduled script which updated the value, e.g., every night.
OK, let's try it out. Bring up the Search center, run a query, and click "Edit Page":
Next, click "Edit webpart" on the "Search core results" web part:
Under "Location Properties", fill in the "Scope" field with the name of your scope ("Boost aspx" in this case).
Click "OK" and then click "Save" in the upper left part of the ribbon. Now, you can try running your query, and probably get this:
Hey, that failed! Why? There is a job which runs every 15 minutes, publishing these scopes. Depending on timing, it may take up to 15 minutes before your scope is active. But after that, you should be getting results ranked according to your xrank-FQL:
There are some peculiarities in the FQL above, which may be worth explaining:
is used as a "match all" dummy query. This is due to the way xrank was implemented. Ideally, your end user query should have been there instead, but there is no easy way to achieve that. This works just as well since the end user query is "and'ed" to this xrank by the webpart.
is even harder to explain. The default is "no", for performance reasons, since a value of "yes" will give somewhat lower query throughput. But in enterprise search scenarios, the difference will be negligible in the large major of cases.
Thanks to Vance Miller who first documented the approach!