1

There's this weird issue that's been keeping me wondering what's happening. I apologize for the lack of specificity, but I need to abide to a strict NDA policy. So here goes my question:

Is there any way to pinpoint the source of redirection that's occurring when accessing a no-more-existing subdomain of a website that I'm managing?

Basically, http://oldsubdomain.example.com is being redirected to http://example.com. Moreover, Google doesn't allow me to remove it (through Search Console) from their search database specifically because of this redirection.

Despite the fact that the subdomain - which used to be in place many years ago - was deleted at some point a few years back and hasn't been used ever since, Google still seems to have it cached. However, the title, as well as the description of the search result snippet are identical to the main domain name result, i.e. by googling for http://oldsubdomain.example.com, I'm getting exactly the same result as when searching http://example.com.

Yes, I did search and couldn't find any directives in .htaccess that may cause such redirection, I also made sure (by checking under cPanel subdomain settings) that the subdomain doesn't exist. There are also no DNS records related to that obsolete subdomain in Cloudflare.

To sum it all up, how could I see exactly what is causing the redirection? I just want to disable it so that I can ask Google to remove the http://oldsubdomain.example.com search result.

  • 3
    You need to check DNS again. Without DNS records there can be no way that it resolves to your server. Maybe there is a wildcard DNS record? – Stephen Ostermiller Mar 15 '18 at 13:48
  • Is it an Apache name-based virtual host? httpd.apache.org/docs/current/vhosts/name-based.html#using – Fabian Mar 15 '18 at 20:51
  • 1
    What type of redirect are you seeing? I assume you mean an external HTTP redirect - what status code are you seeing? Are you using a CMS of some kind? For instance, WordPress will automatically canonicalise the host (with an external redirect). Silly question, but are you sure Cloudflare is your authoritative DNS provider? – MrWhite Mar 19 '18 at 15:12
  • @StephenOstermiller you are absolutely correct! Wildcard DNS record in place :( which I totally overlooked! – GeekRider Mar 21 '18 at 14:30
  • @MrWhite the reason for the redirection is clear now, please see my answer below. – GeekRider Mar 21 '18 at 14:34
2

In any case, I tried to deny access to http://oldsubdomain.example.com through a .htaccess directive:

RewriteRule ^oldsubdomain.example.com - [F]

To my surprise, for some reason the directive is ignored. The reason as to why it doesn't work is still puzzling me. And by "doesn't work", I mean the redirection still occurs, as if the directive didn't exist.

The RewriteRule pattern matches the URL-path only, not the host. To match the host you need to use a RewriteCond directive and check against the HTTP_HOST server variable.

For example:

RewriteCond %{HTTP_HOST} ^oldsubdomain\. [NC]
RewriteRule ^ - [F]

However, it may be preferable to return a "410 Gone", instead of a "403 Forbidden" in order to get this removed from Google. In which case, simply change [F] to [G] in the RewriteRule flags.

I basically have a DNS-based *.example.com wildcard redirect directive which was pointing to the root domain.

Since you didn't appear to be aware of this wildcard subdomain, are you actually using it? Can I link to anything.example.com and be redirected?

2

I must apologize for asking this question before making absolutely sure I'm not overlooking such an important thing as the wildcard subdomain redirect under the DNS settings! And I'm talking about the hosting's DNS, not Cloudflare's.

Now everything's crystal clear: I basically have a DNS-based *.example.com wildcard redirect directive which was pointing to the root domain. Hence, the requests to oldsubdomain (or any other one, for that matter) being forwarded to the homepage.

In any case, I tried to deny access to http://oldsubdomain.example.com through a .htaccess directive:

RewriteRule ^oldsubdomain.example.com - [F]

To my surprise, for some reason the directive is ignored. The reason as to why it doesn't work is still puzzling me. And by "doesn't work", I mean the redirection still occurs, as if the directive didn't exist.

Now if only I knew how to exclude specifically oldsubdomain from the DNS wildcard, so that I can still deny access to it without having to re-create it.

Any ideas? :)

  • 1
    You can't match the hostname with the RewriteRule directive. Your directive never matches, so is indeed "ignored". I've added an answer to address this, rather than comment, in order to explain it better. – MrWhite Mar 21 '18 at 15:47
1

I ended up asking the hosting provider to help me by adding a specific A-type DNS record, i.e. oldsubdomain.example.com, but they declined any responsibility, considering the fact that the website is using Cloudflare's services. Based on the response of the hosting representative, I went ahead and created a new A-type DNS record within the Cloudflare's DNS section, that points to the null 0.0.0.0 IP address, thus causing any potential HTTP request to oldsubdomain.example.com to fail immediately, especially since the non-existent oldsubdomain serves absolutely no purpose to the website.

I'm not sure whether my approach is the best long-term solution to my initial problem, but at least it works perfectly - as I was able to successfully perform a URL removal request under the Google Search Console - and it doesn't seem to cause any issues.

Thank you all for your useful input!

-1

If you want to see which URL is redirect to your website, you can use the PHP parameter HTTP_Referer which tells you which URL sent you the traffic.

Note: HTTP_Referer only works on http domains and not https domains, as https does not pass referer data.

  • 3
    The OP isn't trying to get the URL from which the request originates (ie. the HTTP Referer). They already know there appears to be a redirect from http://oldsubdomain.example.com, but they are trying to find where in their code base this might be occurring. (Aside: "https does not pass referer data" - this statement is not true (or incomplete at best). By default, the browser does not pass the Referer when navigating from HTTPS to HTTP, but otherwise "HTTPS does pass the Referer".) – MrWhite Mar 19 '18 at 1:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.