About six months ago, I decided it would be best to put my website on the naked domain, let’s just say ‘example.com’. I did what all the instructions websites have told me with adding a 301 redirect from www.example.com to example.com.
Now I wish to undue using the naked domain and establish my website under www.example.com. After reading various questions both on this site and sites like yes-www.org, I realized that I will be better off in the long term using ‘www.’ for my main website. This is especially true now, since the website is growing larger and must be splintered into separate sites (e.g. news.example.com, research.example.com, community.example.com, etc.). With the new domain structure, the main content should be listed on www.example.com.
The problem is, removing the old 301 redirect for www.example.com to example.com and adding one from example.com to www.example.com will result in an infinite loop of redirects for those who still have the site in their cache!
Sadly, this is a large site, with tens of thousands of viewers per day and cannot be undone in an automated fashion.
The only thing I can think of doing, is setting up my main website on a domain, “www1.example.com,” doing a redirect from example.com to www1.example.com, and somehow, in time, migrate back to www.example.com? How could I do this, though if redirects really do seem permanent?
In summary, I wish to find an automated way to go back to using www.example.com instead of the naked domain, example.com, and I really don’t know how this will be possible to do again.
Disclaimer: I’m the author of http://www.yes-www.org/ and I’m glad you like it.
You’ve correctly identified a serious issue here, that of client-side and possibly even proxy caching of the 301 response. (Fortunately, search engines will pick up any change pretty quickly, so there’s little to worry about there.)
On caching, RFC 2616 has this to say:
A response received with a status code of 200, 203, 206, 300, 301 or 410 MAY be stored by a cache and used in reply to a subsequent request, subject to the expiration mechanism, unless a cache-control directive prohibits caching.
Interestingly, browsers vary as to whether they actually cache 301 responses. Regardless of what you end up doing, you are almost certainly going to have some users who will need to clear out their browser cache.
With all that in mind, this is how I would approach the problem:
- At no time would I use a third subdomain, as my colleagues here have recommended. I don’t see any reason it should be necessary, and a subset of your users are sure to notice and wonder if something is wrong.
- I would first change the existing 301 redirects from www to non-www to a 302 redirect. 302 is not cacheable by default. This I would leave in place for a period of time, perhaps 30 days, to allow search engines and the majority of your regular visitors to see it.
- At the end of that time, I would change the web site to use www, remove the 302 redirect, and place a 301 redirect from non-www to www.
While there will probably always be a user or two who will have to clear their cache to regain access to the site, regardless of what method you use, the number should be minimal, as users’ caches aren’t infinite, and even if they don’t visit your site in the interim, they’ll almost certainly visit many other sites which will likely push your old 301 out of cache due to its age and lack of use.
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.