Off-topic: I can't help but be nosy and check the https version of your page. You seem to be serving a cert with CN=albertstreetantiquescentre.co.uk. Might want to get this looked at :)
So, firstly don't put a dot at the end. Whatever you might feel about it, the decision in practice was that the host part of the URL is an FQDN but doesn't need a dot at the end. So don't write one there. The browser should probably trim it out when you type in or follow such a link.
The Apache web server that the bulk host is using for that site has a fairly poor implementation of HTTPS. It's unsatisfactory in various ways, some very technical, but what you're seeing here is the weird way it handles SNI.
By default when you say you want jdebp.uk. and there is no such virtual host (there's only jdebp.uk with no trailing dot) Apache will pick a default virtual host and act as though you asked for that, sending over the certificate for that host and so on. In this case, at a bulk hosting site, it's some unrelated Antiques Shop outfit, likely because that begins with 'A' which is the first letter of the alphabet.
This actually caused a problem for Let's Encrypt because their tls-sni-01 challenge type assumed nobody would be crazy enough to answer queries for a random name with a certificate chosen by somebody else entirely. But that's exactly what Apache is doing here. The current tls-alpn-01 challenge was introduced to fix that - it asks for a reserved ALPN service instead of a spurious SNI server name.
you can configure the first default apache vhost to be something else other than a "customer" site, that's what we do at my hosting company. though it still leads to a certificate error. that used to matter, but nowadays we just automatically lets encrypt everything that we host.
Censys gets these defaults (you could probably measure a slight bias in their data towards alphabetically earlier names as a result, but I have never checked) for sites using Apache, and for other servers with a default they get that default (in nginx I believe you have to explicitly configure a default if you want one). If there is no default the site says you need to specify which name you wanted or too bad.
You'll see the same for various other providers that crawl the IPv4 Internet looking for services. My last job (it seems prescient now to have no job, very convenient in current situation to have no reason to go outside anyway) had me trying to fit some of this data to other service discovery information.
It seems that the server running on the other end doesn't properly match the certificate from the SNI if the domain sent by the browser is a FQDN (i.e. ends in a .)
The relevant RFC says not to send a trailing dot in SNI. Browsers should probably trim the dot out if present. Maybe they aren't doing so because it causes some unexpected compatibility mishap, maybe in reality it rarely causes any trouble so nobody got around to it.
> "HostName" contains the fully qualified DNS hostname of the server, as understood by the client. The hostname is represented as a byte string using UTF-8 encoding, without a trailing dot.
That's the page on a shared hosting service, not served by me. See the site history page (still in the same place that it was a couple of years ago when it came up on Hacker News).
Edit: Interesting,
https://jdebp.uk has the correct cert configured, whereas https://jdebp.uk. serves the cert as mentioned above.