As @Stephen suggested in comments, hi
is the username part when the username:password
is specified as part of the URL (See RFC 1738) in Basic HTTP Authentication.
If that's the case, it shouldn't get picked up by search engines
That depends if other sites have (maliciously) linked to the URL in this format.
hi@
is not actually sent as part of the Host:
HTTP request header, so you can't match it with the HTTP_HOST
server variable in Apache .htaccess
. Compliant user-agents will strip this from the URL and create a base64 encoded Authorization:
header with this information before making the request.
If you are not using HTTP Authentication then you could potentially redirect/block any request that contains something in the Authorization
HTTP request header. For example, you can try the following at the top of your .htaccess
file (not at the end):
RewriteCond %{HTTP:Authorization} !^$
RewriteRule (.*) https://example.com/$1 [R=301,L]
Although this is a little risky, as it is dependent on the user-agent not sending the Authorization
header again in the second request in order to avoid a redirect loop. Although this shouldn't be a problem for "real users" in this instance, as they shouldn't be "logged in" anyway. Googlebot should be shown the URL less the login credentials (although will possibly experience a redirect loop and not actually see your real content - but will avoid the duplicate content issue). If you were genuinely using HTTP Authentication on your site then this would certainly result in a redirect loop if the user had "logged in".
Alternatively, serve a 410 Gone instead for such requests (I wouldn't think you're getting much SEO value from these URLs anyway):
RewriteCond %{HTTP:Authorization} !^$
RewriteRule ^ - [G]
UPDATE: As @StephenOstermiller suggested in comments, the technically correct response is probably to return a 401 Unauthorized
instead. This has the added benefit of logging the user out (if they really were logged in), so the Authorization
header would not be sent in subsequent requests. And Google should not return any 4xx response in the SERPs. For example, similar to above:
RewriteCond %{HTTP:Authorization} !^$
RewriteRule ^ - [R=401]
It's worth noting that it's unlikely that any of this will affect real users following such links, as it seems that modern browsers tend to strip this information entirely before making the request (for reasons of security). It is removed from the visible URL and no Authorization
header is actually sent. This appears to have been removed from IE a long time ago apparently. And also seems to be the case in my tests on Chrome 64 (and Opera). The following Chrome bug report backs this up and suggests this feature has been removed - the bug report is closed with a status of "WontFix".
The following ServerFault question has much discussion in comments about whether this URL format "works" (strangely, some users state that this does work in Chrome - although these comments are possibly outdated):
UPDATE: Note that RFC 3986 (which updates RFC 1738 - linked above) formerly deprecates the use of "username:password" in the URL
Use of the format "user:password" in the userinfo field is deprecated.
hi@
isn't part of the host.hi
is the name of the logged in user.