Force Safari to respect single word hostnames

Question

TLDR - Looking for a way to make Safari treat host/path as a URL instead of a search query.

Details:
With the conflagration of the address bar and search bar certain expected behaviors have ceased to work, in my case, if my computer has a search domain and/or hosts defined in /etc/hosts using just the hostname should be possible however in Safari unless the string entered in the address bar ends in a / it will always be treated as a search query.

Though I would argue that this behavior breaks several standards¹ all major browsers are currently guilty of this but:

• On Firefox² there are several hidden settings that allow to either set certain words to always be treated as hostnames (and thus hostname/path as a URL) or even a setting to enable single word hostnames.
• On Chrome after the first time you explicitly browse to any instance of hostname/ all subsequent visits to that hostname and any path (even those never visited) will be treated as a URL.

On Safari however even visiting a hostname/path that already was visited in the past will still be treated as a search query unless a / is appended or http(s):// is prepended, this is pretty frustrating, to put it mildly, it also makes creating something like golinks that will work on Safari that much more difficult.

So I'm looking for settings similar to Firefox to bypass/neutralize this behavior.

^{1 As to how URIs (should) work, I would argue that if the string in the address bar contains a / an attempt should be made to resolve the substring before the / and if it resolves the string should be treated as a URL, if not by all means search.}

^{2 On FF I filed the following bug - https://bugzilla.mozilla.org/show_bug.cgi?id=1754546}

Answer 1

The only workaround I found is to "train" safari to recognize go/ links. For the record, I'm using a custom go/ links solution, having a local DNS server and having configured appropriate search domains under network settings.

I did it the following way:

1. Copy https://go/ to clipboard
2. Repeatedly open new tabs, paste https://go/ into url, and hit Enter, close tab after it resolves
3. Repeatedly open new tabs, paste https://go/test (or whatever, it doesn't haven't to redirect anywhere but hopefully resolves to something), close tab

Now, having done that around 15-20 times, if you open a new window or tab (even in private mode) and type in go/whatever (we don't have to explicitly specify the protocol or the FQDN) it will go through the https://go/ host - even though the URL dropdown may indicate that it is about to search through a configured search engine.

Note that fortunately, the path which follows the go/ URL doesn't have to match any of the ones used during training.

This approach is working on Safari Version 16.1, and is extremely unintuitive and implicit to the point of discomfort. Once trained on your Mac, it does NOT carry over onto iOS - so iOS will require its own similar "training" which I have not tested yet and thus cannot confirm whether it is possible which I had just tested and confirmed to work.

---

On a personal note, this is an extremely annoying design decision on Apple's part. This means that anyone who visits my enterprise and connects to my network cannot follow the documented go/link instructions, whereas those who have "trained" their Safari can. Or worse, we would have to instruct users to do silly monkey tasks of pasting, entering, closing tabs; unacceptable. Meaning, we will have people with identical settings who experience different results when asked to enter go/onboarding or whatever, thus adding up to a nightmare for support and a perceived poor implementation by IT. Very frustrated by this.