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.

  • 2
    Why are you switching back to www.example.org? There is nothing you can do with that domain that you can't do with example.org. They're just domains, and A records. – gparent Nov 22 '12 at 21:07
  • @gparent - not entirely true. Yes they're just A records at a DNS level, but there's other effects to www or not. For example, it always drives me made that the SE networks don't run off www just because, well, it annoys me. Also they ran into issues with creating a cookiless domain - as cookies cascade into subdomains, the only way to create a cookiless domain is to either use www. and then say, static.. Otherwise if it's just example.com the same cookies go to static.example.com which isn't always what you want. And then there's grandma who types www infront of everything... – Mark Henderson Nov 22 '12 at 23:52
  • "Not annoy you" is not something you can do with DNS. That would require some sort of brainwashing or advanced surgery. I'm glad you mentioned other actual issues, but they can all be solved or work around without using www, which is what caused my interrogation in the first place. Sadly Anthony didn't comment further. – gparent Nov 27 '12 at 19:56

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.


Your best bet is to have some sort of server-side logic, so when the request comes into example.com, check the referrer. If the referrer is www.example.com then don't do the redirect straight back to www.example.com, send them somewhere else, or just display the site for them, send them to a subfolder on www.example.com or whatever.

Also if you log these requests, you can get some good stats on how many users are coming from your www and still getting a redirect. Eventually that number should die down fairly low.

Also, remember to add your expiry headers to these 301's - then you won't have the issue that's described in the FireFox bug you linked to.


Change the redirect of www.example.com -> example.com to www.example.com -> temp.example.com, and of course make sure that the temp address works as an alias for the website.

Have that running for a few weeks or months. (And be sure to expiry headers on that 301!) Give it enough time until you think that most people's browsers have learned the new redirect to temp.example.com and forgotten the old one that goes to example.com.

At that time you can redirect example.com -> www.example.com, without creating a loop. (Except for those few who still have a cache of the old redirect: too bad).

At the same time, turn off the redirect to temp, but keep that alias working for a while longer. When you notice that there are few or no accesses to temp, you can shut down temp.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.