Mistyping wwww. or httpwww. or the like doesn’t have to be an insurmountable navigational hurdle for your visitors. Catch all domains and redirect them to your canonical domain name to avoid losing traffic to typos.
Typing URLs or even copying them can be an error-prone operation. Take a break now to type ww. in your browser’s address field. How many suggestions from your browser history did it bring up where you’d dropped off one of the three w’s? It’s an easy mistake to make, and it’s an easy mistake for the web server you’re trying to reach to automatically correct.
It’s so easy to mistype a web address. I showed you earlier how to redirect .htm to .html (or .ph to .php) to avoid that last slippery letter from vanishing from the address. This time I’ll tackle http.example.com, ww.example.com, httpwww.example.com, and everything else you can imagine happening at the front of your domain name. This will be a slightly more complicated setup than the other scenario.
Ensure you can make changes to the DNS before proceeding to make changes on your server. For this method to work, you’ll need to assign a new wildcard sub-domain name under your domain. A wildcard domain matches everything in front of your domain name like bubbles.example.com or ww.example.com.
In your DNS administration interface (available through the website of your domain registrar), you must add a new entry *.example.com and give it the same IP address as your main website (www.example.com.) Remember to replace example.com with your actual domain name. Refer to your domain registrar for further assistance on how to do this with their admin interface. Once the wildcard domain is in place, you can proceed to make your server listen for this domain.
Configuration example for Nginx
In Nginx, you need to set up an entirely new server to listen for the new wildcard domain. Note that we’re not using the special “.example.com” notation, as we don’t only want to match “www.example.com” but rather “anything.example.com” The exact match “www.example.com” in the second server takes prescience.
server {
listen 80;
listen [::]:80;
server_name *.example.com example.com;
return 301 "${scheme}://www.example.com${request_uri}"
}
# Your actual existing server configuration follows
server {
listen 80;
server_name www.example.com;
# Your server configuration continues here …
}Same redirect server as above but integrate with Google Analytics:
server {
listen 80;
listen [::]:80;
server_name *.example.com example.com;
set $args "$args&utm_source=${host}&utm_medium=traffic_recovery&amo;utm_campaign=domain_wildcard";
return 301 "${scheme}://www.example.com${uri}?${args}";
}
# Your regular server configuration goes here …With Google Analytics you can find out which domain typos are common and whether to contact any referring websites to ask them to fix typos on their end. If you’re seeing thousands of requests to a particular misspelling, consider adding it to the server_name list to speed up Nginx. The Google Analytics integration as shown above sets the source to hostname the visitor tried accessing, medium to “traffic_recovery”, and campaign to “domain_wildcard”.
Configuration example for Apache
We’re going to use a separate virtual server in Apache as we did above for Nginx. Leave your current virtual server as-is but place the following example above it (Apache uses read-order to determine configuration priority.) Note the ServerName and ServerAlias settings in each of the virtual server block, and that the exact match of “www.example.com” takes prescience.
<VirtualHost *:80>
ServerName example.com
ServerAlias *.example.com
RewriteEngine On
RewriteCond %{HTTP_HOST} !^www.example.com [NC]
RewriteCond %{HTTP_HOST} !=""
RewriteRule "" "http://www.example.com%{REQUEST_URI}" [QSA,R=301,L]
</VirtualHost>
<VirtualHost *:80>
ServerName www.example.com
# Your normal server configuration follows …
</VirtualHost>Same redirect server as above but integrate with Google Analytics:
<VirtualHost *:80>
ServerName example.com
ServerAlias *.example.com
RewriteEngine On
RewriteCond %{HTTP_HOST} !^www.example.com [NC]
RewriteCond %{HTTP_HOST} !=""
RewriteRule "" "http://www.example.com%{REQUEST_URI}?utm_source=%{HTTP_HOST}&utm_medium=traffic_recovery&utm_campaign=domain_wildcard" [QSA,R=301,L]
</VirtualHost>
# Your normal server configuration goes here …P.S.: You may want to clean-up the REQUEST_URI variable first.
What about HTTPS?
The examples have all focused on HTTP (listener port 80) and not HTTPS (listener port 443.) With HTTPS there’s an added complication with certificate domain name requirements. A server’s certificate is usually issued to example.com and www.example.com. Meaning it’s only valid for those exact domain names. You need what’s called a wildcard certificate which is issued to *.example.com and example.com for the domain to be valid on any sub-domain. These certificates are usually six times — and possibly prohibitively — more expensive than regular domain certificates.
Visitors who reach mistake.example.com over HTTPS with a domain only valid for www.example.com will get a security warning from their browser. This is arguably a better behavior than letting your server maintain radio silence and not responding to the request at all. The browser will then put up the “site can’t be reached” error we’ve been trying to avoid. With a certificate security warning saying they’ve potentially reached the wrong server, visitors are now at least told they’ve gotten somewhere. The warning can even be dismissed and the visitor can choose to proceed to the server despite the warning.
For servers set up to use HTTP Strict Transport Security (HSTS), the behavior will be the same. Except visitors will not be given the option to ignore the warning and proceed anyway. Still, the error message from the browser will tell them there’s something wrong with the address and not that the address doesn’t exist. It will then suggest that they put the address through a search-engine for suggestions, or that they manually correct the address. Again, this is probably better than having the server not replying at all.
Ideally, you should have a valid wildcard certificate setup to avoid these problems and giving visitors the best experience.
With this added understanding, you can duplicate your existing HTTPS virtual server block in Apache or Nginx and include the configuration examples as shown above.