Blog » Allowing WWW and Domain Only Access to WordPress Site

Allowing WWW and Domain Only Access to WordPress Site

Say you have a client who’s come to you to build them a new website; great, congratulations. You do some research and find out that the links on their old site all pointed at the raw domain (no www preceeding it). You’ve also decided that based on their needs, the new site should be set up on the WordPress platform.

Easy peasy, right? Well not so fast there… Let’s say you built the new site, took it live and everyone on the Internet can see the new site BUT your client. More accurately, your client can’t see the site when they are at work but can from any other location. Hmmm…

Doing a little bit of research, you discover that the client is running a Windows network at their offices using Active Directory (AD) to control access to files and other resources on their network. Digging a little deeper you discover that the name of the Windows network is their public domain name. As a result, any computer hooked up to their network will always see the IP address of the domain name pointing at the active Domain Controller (DC) not the website you worked so hard on.

The the client tells you: “Oh yeah, from our network we’ve always used www.domain.com as the way to get to website.” Ooops, that is going to be a problem as most recent versions of WordPress all force inbound traffic to mapped domains that are NOT the domain defined in the General Settings via a 301 redirect. In most cases, this is the correct thing to do to ensure that you don’t get penalized for duplicate content (since you’d be able to access the same content at domain.com/page-title/ as you would at www.domain.com/page-title/). However, given that you NEED to allow your clients to access the site via a URL that is something OTHER THAN domain.com, you can do one of a number of things.

  • You could change the WordPress Address/Site Address value on the General Settings tab to use the www version. The problem with this option is that you’ll end up taking a hit with the search engines while they re-index the whole site as they will be getting 301 redirects on every page in their index that they try and reach. This process, and the associated drop in Search Engine Results Page (SERP) rankings while the search engines sort it out make this a less than ideal solution.
  • You could redesign the client’s Windows network to use a more appropriate name for the AD domain. This is even LESS feasible than the above as in most cases, changing the primary AD domain in a Windows Network is no small feat.
  • Lastly, you can disable WordPress’ natural inclination to 301 redirect page going to the “wrong” domain. However, in doing this, won’t we risk a duplicate content penalty you ask? If I can show you how to easily prevent this penalty from being applied, this is the best solution as it minimizes negative impact on the client and prevents loss of SEO “mojo”.

Sometime ago, Google (and the other search engines) realized that this type of problem is common and that there needed to be a way to allow for this. This lead to the creation of the CANONICAL link tag. By inserting a link in the header of a page that points at the TRUE AND ORIGINAL source of the content, no duplicate content penalty will be applied.

The best way around this is to insert a line in your theme’s function.php file that will turn off the redirect behavior in your WordPress installation.

<?php
// MJGMod - per: http://www.velvetblues.com/web-development-blog/turn-off-wordpress-homepage-url-redirection
///     added following line to prevent the 301 redirect to enforce canonicalization
remove_filter('template_redirect','redirect_canonical');
?>

That coupled with the default canonical linking added into WordPress back in the early v2.x days, you get the perfect solution.

Well, almost. There are another few “problems” that come up in a default WordPress install.

The first is that when adding content to WordPress (text/html/media) it stores the links to this content using the full, absolute patch that is constructed using the General Setting domain to construct it. The better choice would have been to link to these relative to the root of the website so that unless you move the site deeper in the directory structure of the website, it will work regardless of the domain name. The easiest way to do this (especially if you aren’t comfortable with MySQL commands) is to use a plug-in like Velvet Blues Update URLs..

The next major problem that you’ll find is that if you are using the WordPress menu system (and why not other than it’s clunky HTML rendering) you’ll find that it too constructs full absolute URLs to the target page using the domain name defined on the General Settings tab. The best way to get around this, IMHO, is to create a simple little filter like the following to strip the http://domain.com from the hyperlink.

<?php
// MJGMod - filter to modify the menu links
function mjg_make_relative_links( $menu ) {
    $output = str_replace(site_url(), "", $menu);
       return $output;
}
add_filter( 'wp_nav_menu_items', 'mjg_make_relative_links', 10, 1 );
 
?>

Of course, if you want the resulting links to be using links relative to the site’s current directory (rather than relative to the root), you can change the first line of the function as follows:

 $output = str_replace(site_url() . "/", "", $menu);

 

So, with a little bit of ingenuity, and a few lines of code, it is possible to set up a WordPress site that will accept traffic to the domain name (e.g. domain.com) and to the www version of it (www.domain.com) without sacrificing SEO “mojo” or taking a duplicate content penalty.

Michael Gibbs
Stalk Me...
Latest posts by Michael Gibbs (see all)