SEOAly

You are here: Home / On-Site SEO / w3 Total Cache & Canonical URL Issues

w3 Total Cache & Canonical URL Issues

By

Lightbulb Moment

Photo By: shuttermonkey

If you follow me on Twitter, you may have noticed a tweet from me a while back lamenting a conflict between a caching plugin and the 301 redirect from non-www to www (or vice versa – whichever is the preferred URL for a given site).  From time to time I check to make sure that the non-www URLs of pages on my site are being properly redirected to the www URLs.

Some time after I started using the w3 Total Cache plugin, that stopped happening.  I was not bursting with fruit flavor, but hey…what are ya gonna do?  It’s a free plugin.  And one that, to that point, had served me very well.  After tweeting about the issue, one of the plugin’s developers responded that it was an issue they were aware of and that it would hopefully be resolved in a future release.

I was happy to hear that, but in the interim and despite how much I liked the w3 Total Cache plugin, I decided to stop using it.  Instead I went back to using WP Super Cache, which did not interfere with the 301 redirect.  When the latest version of w3 Total Cache was released, I tried it again…hoping the issue had been resolved.  Much to my dismay, it hadn’t.  So, back to WP Super Cache I went.  Again.

While I believe certain features of w3 Total Cache – like browser caching, object caching and built in minify functions, make it the better caching plugin, as an SEO the idea of my site having www/non-www canonical issues really stuck in my craw.  Since that’s an issue I always advise site owners to resolve to help mitigate potential link equity issues, I can’t in good conscience not practice what I preach.

That said, I’m a stubborn geek.  And I wanted to find a way to use what I believe to be a superior plugin without having my site continue to suffer from www/non-www canonical URL issues.  I’ve found a solution that is working.  So, I thought I’d share it with you.  DISCLAIMER: DO NOT do this unless you know what you’re doing and know how to fix any problems that may occur as a result of modifying your .htaccess file.  I will not be held responsible if you bork your site.  Consider this your warning!

All I had to do was place the following code at the beginning of my .htaccess file (before # BEGIN WordPress and # BEGIN W3TC Browser Cache):

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_HOST} ^domain\.com$ [NC]
RewriteRule ^(.*)$ http://www.domain.com/$1 [R=301,L]
</IfModule>

I realize this is the standard code for a 301 redirect, but it had not appeared in my .htaccess file before and the non-www URLs had still always 301 redirected to www URLs – I assume as a basic function of WordPress itself.  That is until the w3 Total Cache plugin was installed, which suggests that it is conflict between a built in function of WordPress and the w3 Total Cache plugin.  Some of you code wonks out there probably know the answer.  I do not profess to be a code wonk, so I can only speculate.

This will only work for sites running on Apache and obviously you need to replace”domain” with YOUR domain.  DUH!  And if I have to tell you to be sure to change .com to .net, .info, .whatever if your domain isn’t a .com, you should stop reading now.  No, seriously…just stop.  This is not the post for you.

Also, if you don’t know what an .htaccess file is and where to find it, as well as what type of server your site runs on (Windows vs. Linux) and whether it’s running Apache, well…you probably would have/should have stopped reading already.  If you didn’t, sorry I wasted your time.  File this in the “for future reference” folder.

So, if you’ve got a WordPress site hosted on an Apache server and you’ve been having trouble with www vs. non-www canonical URL issues because of w3 Total Cache, I hope this solves your problem.  I’ve used this solution on several sites now without a hitch.  If you implement it and it works for you, please come back to let me know.  Good luck!

And remember…DON’T EVEN TRY THIS UNLESS YOU KNOW WHAT YOU’RE DOING! Seriously.  As you were.  :)

NOTE:  The solution provided above will redirect non-www URLs to www URLs (my personal preference).  If you want to do the opposite, Meg Geddes was nice enough to provide her advice below.  Thanks, Meg!

About Alysson

I'm Alysson (a.k.a. "SEOAly") and I've been an active part of the search marketing industry since 2006. I offer affordable small business website design and search engine optimization services. I'm also a contributing author for several industry publications, including: Search Engine Journal, Search Engine People, Viral Conversations and Directory Journal.

Comments

  1. Meg Geddes says

    I redirect www issues in .htaccess as a matter of course; it’s the surest way.

    If you wish to redirect www to non-www (my personal choice in most cases) do this:

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

    And if you wish to force a trailing slash on the end of URLs that do not have a suffix, you can add:

    # Force trailing slash
    RewriteEngine On
    RewriteBase /
    RewriteCond %{REQUEST_FILENAME} !-f
    #RewriteCond %{REQUEST_FILENAME} !\.(jpg|jpeg|gif|png|css|js|pl|txt|xml)$
    RewriteCond %{REQUEST_URI} !(.*)/$
    RewriteRule ^(.*)$ http://example.com/$1/ [QSA,L,R=301]

    These are tried and true and work for me, your mileage may vary, yada yada yada. ALWAYS download a backup of your .htaccess file (and rename it with the date) before you do anything, so you can restore it if you fumble.

    Finally, I highly recommend you install the Firefox plugin HTTP Live Headers to check your work.

    • Meg Geddes says

      Opps, you probly don’t need this line; I have it commented out anyway

      #RewriteCond %{REQUEST_FILENAME} !\.(jpg|jpeg|gif|png|css|js|pl|txt|xml)$

      • Alysson says

        Thanks for the additional info, Meg! I’m sure many will find this very helpful. :) And great tip about installing the Live HTTP Headers Firefox plugin. I definitely should have mentioned that.

        For those who prefer a web-based solution for checking to make sure a new 301 redirect is working properly, check out the “Advanced” tool from SEO Browser. A nice, quick solution that provides a great snapshot of how the search engines see your site.

    • Alysson says

      If memory serves, I first noticed the problem beginning with version 9.1 (though it may have started earlier and I failed to identify it). The fix I implemented above was first used with version 9.2. I have not yet attempted to remove the 301 redirect code from the .htaccess file since the 9.2.1 or 9.2.2 updates have been released.

  3. Phil says

    Hi,

    Thanks for this great post. I was astounded that w3 total cache removed the native function of wordpress to automatically canonicalise urls. I only found this by chance by using the woorank website analysis tool.

    Don’t get me wrong, it is a great plugin and really performs admirably for increasing page speed, but this is an issue that needs to be addressed or at least warned about by the w3 total cache developers.

    Your solution will suffice, as this is how I am used to canonicalising the htaccess and was something that I was considering performing. I just wanted to check to see if this was a common problem and it appears to be.

    Cheers

    • Alysson says

      Hi, Phil. I’ve been using W3 Total Cache for some time and I know this issue didn’t used to occur. Luckily I found a solution that will work until the plugin’s issues are resolved on the developer’s end. I agree with you that it is a great plugin…but also wholeheartedly agree that this issue should be included in their FAQ section so people are aware of it from the get-go and can implement a solution of their own.

      Thanks for stopping by and I’m glad you found the post useful! :)

Subscribe via email!