"Go to" search suggestions improvements

The Kagi browser extension and the website could benefit from some quality of life enhancements for the user. This could also benefit Kagi on the cost side for those 5% of searches (and ultimately the user by saving them some searches).

First, the extension does not place the "go to" search suggestion in the first position as it does in Kagi's search box popup and in Orion. This could be changed so that the first result of the auto-suggestion is the direct URL when relevant. The extension could be smart by hiding the "go to" search if the exact same URL is found in the history, and letting the browser display the history entry.

Also, when you select the "go to" suggestion from the omnibox, it literally searches for the URL and displays search results instead of redirecting to the suggested URL.

Second, a setting could be added to the "Settings" page so that a user can choose to go directly to the suggested website URL instead of performing a search. This could save Kagi some money. In this case, if a "go to" search suggestion appears when entering a query, hitting "Enter" would redirect to the suggested URL. This could be for the extension as well as the website.

Finally, this "go to" suggestion feature could be improved in some cases. Some queries do not return a website such as "youtube", "vlc", and "gitlab". Some others seem to return an incorrect URL, such as "spotify". This may be worth reporting in another thread.

carl I tried a website I did not have in the history, such as "inkscape". It is even worse in Firefox. The "go to" suggestion does not even appear.

Kagi:

Chrome (note the lack of https):

Firefox:

carl Probably. My suggestion is mainly for first time visits when you do not know the URL of the website you want to visit. Also, some people might have their history turned off for various reasons, so it might benefit them while saving some searches.

Vlad I'm sorry, but I don't know of any extension that does this. Maybe someone else does.

However, I thought that Kagi redirected the URL entered as a query.

In the example above, I can literally search for a URL:
https://kagi.com/search?q=https://krita.org/
https://kagi.com/search?q=https%3A%2F%2Fkrita.org%2F

The encoding doesn't matter in this case.

I think the easiest solution is to manipulate the order of the suggestions and put the "go to" suggestion at the top as soon as it appears. Again, this would wrongly search the URL instead of redirecting to it. However, I don't know if the order should be manipulated from Kagi's servers or from the extension.

An immediate first step might be to redirect the URL suggestion to the URL instead of searching:

• Either on Kagi, by changing the behavior of the search engine when entering a full URL. It seems that the "go to" suggestion on kagi.com works some magic.
• Either on the extension, by recognizing a "go to" URL in the suggestions and directly redirecting to it when selected.

I know it doesn't solve what we're trying to accomplish, but it's probably an easy workaround for now. Then a better solution to manipulate the order of the suggestions and maybe the look and behavior of the "go to" ones can be achieved later.

Vlad The default behavior of the browser bar is very simple, which is to be expected. It just makes a query with the raw suggestion.

The suggestions are sent to the browser in this form (example with twitter):

["twitter",["Twitter","twitter stock","https://twitter.com/","twitter video downloader","twitter elon musk","twitter search","Twitter Blue","twitter login","twitter news"]]

I think the easiest way to solve this problem, if we don't want to mess with the extension and make it extremely complex, is to let Kagi redirect to any queried URL. If a user really wants to search the URL, then they could put double quotes around it.

For example:

• The user (or the browser) queries https://twitter.com/: Kagi understands that this is most likely a "go to" suggestion and redirects to the website. This could also be a user using Kagi as if they were using their browser bar (sometimes some people don't understand the difference, so this could happen).
• The user queries "https://twitter.com/": Kagi understands that this is a normal query and returns results for the queried URL.

Steps to fix the problem:

1. Rearrange the results from Kagi's suggestion API so that the "go to" one is always at the top of the array.
2. Make Kagi understand the two different types of queries from the example above.

Vlad It seems that there are two ways to handle this.

First approach: as soon as possible

"Go to" suggestions appear as soon as the user types their query.

Let's take an example with the query t.

Here are the suggestions that I got:

["t",["translate","twitter","telegram","tiktok","twitch","tamilyogi","tui","teams"]]

So we can find some popular websites like: Twitter, Telegram, Tiktok, Twitch, Teams (from Microsoft I think).

In the example above, since Twitter seems to be the first suggestion, unless Translate is referring to Google Translate, I think maybe the "go to" suggestion for Twitter should be the first suggestion in this case. Then when I type te, I think the "go to" suggestion should be updated to refer to Telegram's website.

Of course, the normal Twitter suggestion (not the URL) should still appear too.

If these suggestions are really ranked by relevance or popularity, then chances are that when someone types in t, they want Twitter over the others. They can still type in the name of the site until they find the right one.

One problem with this approach is that users will probably get used to doing it this way, i.e. just typing t to get to Twitter, but if the order ever changes, it will cause some confusion or even frustration.

Second approach: exact match only

"Go to" suggestions appear when the user types a recognized website name in their query.

I tried the un query but I do not get any reference to the United Nations at all.

["un",["uniqlo","unibet","unsplash","under armour","unive","united airlines","university of amsterdam","uncharted"]]

If we follow the logic of the first approach, then it would refer to Uniqlo's website. But here, if you really want the United Nations site to appear in the un query, some extra work seems to be necessary.

Perhaps this could lead to some kind of custom "go to" index where you could associate site home pages with multiple keywords (including bangs keywords).

Examples:

• https://www.un.org/ to un, united nations, etc.
• https://developer.mozilla.org/en-US/ to mdn, mozilla developers network, mdn web docs, etc.
• https://twitter.com/ to tw, twitter, etc.

So in this second approach, everything would be "static" and not related to the order of the suggestions as in the first approach.

• Bangs keywords would be associated with websites. tw would be Twitter, and w would be Wikipedia. But what's the point if you can just type !tw or !w?
• Other sites would be referenced by their full name.

The advantage of this approach is that there is almost no ambiguity about the queried site. The disadvantage is that it takes longer to type, especially if it is done frequently.

Conclusion

I think the comparison of the two approaches answered most of your questions, but ultimately it is your decision which approach is best from a UX perspective.

Personally, I think the first approach is better because it opens up the eligibility of this feature to a wider range of sites. Also, it can be 100% automatic and dynamic compared to the second approach. Less maintenance and manual manipulation of suggestions (and results) is always better. Also, power users can still type bangs without a query to get to the related site, which could be another available shortcut.

Finally, I see no reason to limit this feature to the top 1,000 or 10,000 sites. Any site where you can associate a unique name with a unique domain could be eligible. Of course, some sites have the same name and the same domain, but different TLDs. In this case, the most relevant one should be selected.

To be fixed, also:

• Chrome: do not literally search for a URL but redirect to it (see the message above discussing this).
• Firefox: make "go to" suggestions listed (how?) and redirect to the URL (same problem as Chrome, as this is a problem on Kagi's side).

z64 My first question is if we think the "Go to" bang should be the first suggestion or the second one.

If these "Go to" suggestions are a setting that can be turned on or off, then I think it would be logical to have them as the first suggestion when turned on.