WP Canonical URLs – the server is redirecting the request in a way that will never complete
Posted on December 31, 2008
Filed Under The WorldWideWeb | 5 Comments
WordPress Canonical URLs – infinite loop issue

After you install WordPress on your server you might be greeted with this message in your browser when you try to open the page.
“Firefox has detected that the server is redirecting the request for this address in a way that will never complete.”
Or this one in Safari:
“Too many redirects occurred trying to open this document.”
I do run into this issue with WordPress from time to time or better from one provider/hosting package to another. In some cases the canonical URL feature in WordPress does compete with a server setting or a line in the .htaccess file. (The .htaccess file might not be editable in the hosting package you have.)
The competing redirects lead to the browser giving up – and they can’t/won’t show you your site.
What is a canonical URL?
For instance, say your (WordPress) blog is hosted on
http://www.yourdomain.com/blog/
You can likely access the home page of your blog via these alternative URLs:
http://yourdomain.com/blog/
http://www.yourdomain.com/blog/
http://yourdomain.com/blog/index.php
http://www.yourdomain.com/blog/?paged=1
http://yourdomain.com/blog/?paged=1
…
That might not sound like a problem to you but it is one for search engines. A search engine crawler does not know that the content of all the above URIs is identical. As per definition they could/should all return unique content upon request.
Now in the concept of back links being important for search engine rankings and Page Rank you want to make sure you concentrate all the juice on one URL not many – otherwise different documents of your site would compete against each other.
Now the WordPress versions from 2.3 onwards (if I’m right) does take care of this “issue” and automatically redirects the requests to the one URL defined in the permalink settings. And that’s a great great improvement.
However in some cases as described above the feature does compete against server settings of your provider or redirect rules set in the .htaccess file in the root folder of your domain or subdomain.
How to disable the canonical URLs in WordPress?
As multiple URLs for one piece of content is one issue but an installation of WordPress not working at all quite another one you might consider disabling this functionality – at least for the time being.
Thanks to Mark Jaquith who did work on the Canonical URL feature for WordPress here is a very quick way to disable them via a WordPress Plugin.
Just download the file here (right click and choose save file) and then upload it to the …./wp-content/plugins folder of your WordPress installation. Go to the Plugins Page and activate it – now your WordPress pages should load with no issue at all.
Comments
5 Responses to “WP Canonical URLs – the server is redirecting the request in a way that will never complete”
Leave a Reply



The plug-in stopped the problem, although it raised an error on activation.
Fortunately, I had accounts on two different hosting providers. My blogs on Host A worked correctly after upgrading to 2.7.1. The failed blog was on Host B. I checked, and realized that the blogs on Host A did not have .htaccess files.
So I removed this file (.htaccess) from my blog on Host B, and it is working again.
Hope this helps someone.
What if the timeout is soo bad you can’t even log into WordPress to do step 3:
Go to the Plugins Page and activate it.
How can I activate a plug-in if it times-out & I can’t even log in? The issues is the .htaccess file uses rewrite, rewriting all requests to port 83, and that is the only way PHP will work on this linux vhost server.
Thank you, it was of great usefulness
Really appreciate this, helped me without having to mess with the htaccess file which I could not find.
For us, it was as simple as going to the blog settings, and changing the default URL, which in our case, was set to the non-www version of the site. This caused us a good chuckle when we found this. After this was reset, the connections were perfect.