Google dislikes spending precious resources indexing web content on your site that is of no consequence to itself or its users. Inconsequential web content can be present in the form of duplicated pages and irrelevant or repetitive and/or thin text. Even worse, it is a waste of Google’s crawl budget on your site and such content will delay the indexing of legitimate content. In this case, however, the offense is greater than usual because we are dealing with unlimited duplicate versions of a website triggered by improperly installed DNS wildcards; I none to fondly call them zombie sub-domains.

DNS wildcards are used in a variety of ways but in this case I am focusing on the desirable redirect from a non-existent or miss-typed sub-domain to the appropriate URL (e.g. the root of the TLD).

Figure 1.0 demonstrates how it would work properly if you want to redirect incorrect URLs to your main site (my preference):

Here is where it can go ALL WRONG:

In Figure 2.0 each zombie sub-domain creates another unique path to the same content that is meant to be found ONLY on www.xyzname.com resulting in nightmarish hordes of duplicate content and wasted indexing for Google.

A Live Example

The following is a live example of a website with the DNS wildcard issue. The site in question is Houzz.com (the 177^th most trafficked site in the US) which I have a great deal of respect for and for whom I hope this issue will be promptly fixed by their in-house team; it is usually a matter of a simple update to their server settings (outlined later).

In this case a Google search of “site:houzz.com -www” revealed a herd of zombie sub-domains equating to 253,000 results of which likely a large number are composed of duplicate pages.

As you can see, even a prominent site can fall prey. This results in wasting untold bandwidth and artificially creating duplicate content for Google.

Is your site suffering in the bandwidth sucking maw of zombie sub-domains?

See if your site has incorrect DNS wildcards now:

1. In the URL field of your web browser enter the following syntax minus the quotes and replacing the domain (shown as “marketinghigh”) with your own and then press enter: “seohelp.marketinghigh.com”.
2. What you want to see is a report stating the webpage is not available. If, however, you see the home page of your top level domain (in this case marketinghigh.com) with the zombie sub-domain still intact in the address bar then you will know you have to get this fixed.

Perhaps your site did have this issue at one point but no longer does. If that is the case, you can find out if they are still indexed in Google by following these steps:

1. Run a search for your domain within Google using this syntax minus the quotes and with your own domain name: “site:marketinghigh.com -www”
2. If your site does not have a DNS wildcard issue Google will respond with “Your search – site:marketinghigh.com -www – did not match any documents.”

Is It the Fault of Your Hosting Company?

Hosting providers are not SEOs and I imagine few have the time or interest to keep up to date with the latest search engine nuances that could affect their users. As a result, I don’t suggest giving your hosting provider a hard time here. If the situation presents itself you could let them know of the issue or even send them to this post so they know of it; but that is as far as I would go.

The fact is there has been enough divergence in the usage of DNS wildcards that such official discussion documents like RFC4592 were created to rehash the standard definition; which may explain why such errors still exist on sites as impressive as Houzz. The sad reality is that zombie sub-domains are so prevalent my team at StepForth has to include DNS wildcard checks in all website audits we conduct to ensure our clients are not zombie sub-domain victims.

If you are curious just how many other sites suffer from zombie sub-domains then try this Google search on for size minus the quotes: “inurl:wwww intitle:home”. This will show any sites that have “wwww” in the URL (where someone has accidentally linked to the site with an extra “w” in the “www” subdomain) and where the title of the page has “home” in it. There are a LOT of perfectly fine pages showing in this result but it doesn’t take long to find unwitting victims.

How to Avoid Your Own Zombie Sub-domain Apocalypse

I need to be clear that I speak and understand just enough server configuration bafflegab to be deadly dangerous which is why I pass on my instructions to more qualified server managers to make the necessary changes. With that in mind I tapped the mind of my awesome in-house programmer/zombie-killer to provide you with the following code that should be placed in your site’s root folder .htaccess file (just back-up your original htaccess first!!):

RewriteEngine on
RewriteBase /

RewriteCond %{HTTP_HOST} xyzname\.com$ [NC]
RewriteCond %{HTTP_HOST} !^www\.xyzname\.com$ [NC]
#301 redirect to www.xyzname.com
RewriteRule (.*) http://www.xyzname.com/$1 [R=301,L]

Once you have this correctly setup you can test it by trying to visit any of the zombie URLs to see if you are redirected to your site and the zombie portion of the URL is no longer shown. After that I suggest testing the 301 redirect command is being properly communicated by your server by using a server header checker. The result of the header should be something along the lines of “301 Moved Permanently”.

IIS Note: unfortunately it seems Windows IIS servers are out of luck and a 301 redirected wildcard sub-domain is not possible at this time. If anyone knows of a way around this please feel free to let me know.

The Benefits

If your site has suffered at the hands of a fearsome horde of zombie sub-domains and you have beheaded them using this tutorial then congratulations! The benefits of implementing this fix range from simply saving a ton of wasted bandwidth and server resources to the diverse potential benefits of eliminating a huge swath of duplicate content.