Or is this a basic issue withe the way the google bot trawls the web (ie it is not being banned/blocked when perhaps it should.
Does this happen with other (possibly) more friendly search engines?
I’ve not seen this reported
and just tested a live domain that is well reported as domain.com (I admit I detest Google’s bots so use another well known search engine DuckDuck) but the mail.domain.com is not indexed. Of course it is an Nginx site and I am pretty certain that there is no mailto link provided on the website as bait
Yes, I confirm that mail.domain.tld does show the same content as domain.tld and www.domain.tld; also it will get indexed by Google and the ranking will be affected due to duplicate content unless the canonical tag is specified in the HTML.
See:
This appears to be the only available workaround for websites hosted on Virtualmin with Apache. Virtualmin with Nginx, I don’t know.
mail.domain.tld could show any content, even the standard Virtualmin under construction page. Anything BUT the content that is being displayed at domain.tld and www.domain.tld
maye a mandatory htaccess redirect to the root domain ie mail.domain.com 301 → domain/com excpet if it is a /well-know/ folder thing for lets encypt.
Yeah, this is a bug-like. mail should redirect to the actual domain automatically. mail exists for the purpose of being able to get a Let’s Encrypt certificate for it, but it shouldn’t be serving up web pages.
This is already possible. Everything in Virtualmin is configurable. But, if you want a Let’s Encrypt cert for mail.domain.tld, it needs to be able to serve files from .well-known on that domain, so an alias has to exist.
@Jamie and @Ilia should the mail alias get a redirect to www or domain.tld maybe? (Obviously excluding .well-known)
I agree, we should redirect it to the main domain, not www though. But what about the other aliases? There are quite a few, like mail, autoconfig, and autodiscover and perhaps other.
This is an example of an issue that is conceptually very simple but quite difficult to implement cleanly. ):–(
Personally, since I don’t use “mail.domain.com” for referencing mail or anything else within my install, one of the first things I do after a fresh VM install is go into the Server Templates and remove the alias for “mail” from the configuration block of Apache.
Not personally fan of extra pre-configured aliases besides “www” since I like having control over how aliases are used. I disable “admin” and “webmail” option too for the same reason.
I get the point in why this was setup as @Joe explains, and agree with the thread on perhaps making this a redirect to “www” or the “naked domain”.
That could be done via a “.htaccess” file at the root of your website if using Apache.
When I write code, I often setup a sub-domain “sandbox.domain.com”, then in my code I do conditional redirects to either “https://domain.com” or “https://sandbox.domain.com”. To do this, you detect the “host” requested, then conduct the redirect accordingly.
Ofcourse, this could be added within the VirtualHost configuration as well, though even as a short term solution redirecting “mail.domain.com” to “domain.com” could be handled by a “.htaccess” file.
You would add the logic to the “.htaccess” file of “domain.com”.
*** We also use the above method to redirect “www.domain.com” to “domain.com” for SEO optimization as “www” is also an alias just like “mail” is by default ***
In theory, if you implement the redirects in an upcoming release, wouldn’t it be as easy as “disable” then “enable” the “Apache” feature for the changes to take effect?