I know this question is debatable for the whole eternity, and most likely nobody knows the real philosophy of this problem. But I'm trying to solve the problem about 301 and 302 response headers in order to redirect correctly a canonical URL from non-www to www and do it SEO-efficient.

At the moment I'm using the following method to redirect my canonical URL from non-www to www

#RewriteCond %{HTTP_HOST} !^(www\.shangri\.us)?$
#RewriteRule (.*) http://www.shangri.us/$1 [R=301,L]

But using this code I get the following message in my PageSpeed report:

To speed up page load times for visitors of your site, remove as many landing page redirections as possible, and make any required redirections cacheable if possible.

  • http://shangri.us/ is a non-cacheable redirect to http://www.shangri.us/

So I'm trying to fix the PageSpeed advice about cacheable redirects (http://goo.gl/AWI0g4)

I've read that I need to use 302 response header in this case. I know the difference between permanent and temporal redirects (301/302), but I have a big dilemma about how to implement this on my site.

Although I don't want to use my root domain at all, I'm afraid of using 302 temporal redirect, because some people say it isn't the best way for SEO matters, but... aaaaaah I'm gonna go insane :(

  • If you update all your internal linking to point to the canonical urls without having to redirect, then won't this circumvent the issue in question? I'd definitely not change 301's to 302's just to appease a small check in a page speed check, as this could result in a duplicate page becoming indexed, as 302's urls can stay in the index. – Max Jul 25 '14 at 4:37
  • The point here is to achieve that "cacheable redirect" – Frondor Jul 25 '14 at 5:06
  • 1
    See this related question: webmasters.stackexchange.com/questions/51253/… – dan Jul 25 '14 at 6:38
  • Hi Dan, I've already read that question before, but that doesn't explain me what to do in my case. – Frondor Jul 25 '14 at 6:42
  • @Frondor You might take another look at that. See the caching guide there if you want to cache redirections via the server. – dan Jul 26 '14 at 1:42

The type of redirect you are using is not the problem. 301 redirects are cacheable. In fact they are extremely hard to cache bust. 301 means "permanent" and browsers are very likely to cache 301 redirects with no way with the server to undo one that is already cached.

302 redirects are generally not cached by default unless other headers indicate that they can be cached.

The problem must be related to the other HTTP headers that you are sending. Here is guide to cache headers. In summary you should pay attention to these headers to make the redirects cacheable:

  • cache-control - "public" or not present
  • expires - A date in the future, or not present when using 301 redirects
  • etag - Not present
  • vary - Not present
  • pragma - Not present

If you want to see your headers, I suggest using the command line tool curl:

curl --head http://shangri.us/

Indeed I see that you have set the cache-control header to private: Cache-Control: private, max-age=0, no-store, no-cache, must-revalidate, post-check=0, pre-check=0 and the expires header to a date in the past: Expires: Thu, 01 Jan 1970 00:00:01 GMT. You need to remove those headers for that redirect.


What is the purpose of the redirect?

The 301 Canonical

The purpose of your redirect is to assure a canonical domain name. As such, the appropriate HTTP response is a 301. By default, many browsers will cache this indefinitely unless you specify a Cache-Control header.

The 302 Confusion

In the Google reference you provide, they are talking about landing pages specific to mobile sites. Here they are encouraging the use of a 302 with both Expires and Cache-Control headers. They also recommend adding Vary: User-Agent to allow for different caches for different user agents.

In other documents, they mention both 301 and 302. Fortunately, SEO Rountable cleared this up:

I asked Maile Ohye and Matt Cutts of Google if this was indeed on purpose and Maile said it was 100% on purpose and not a mistake. Matt Cutts said the reason was because you may want to change it in the future and they didn't want it to be a permanent thing.

So apparently, the recommendation to use 302 for mobile redirects is to permit future changes while still have some level of caching.

Many mobile providers use transparent caching proxies for web content. So this strategy makes sense if you want to permit future changes.

This is consistent with Google's goal to give a positive user experience. They don't want search results being redirected to defunct mobile specific domains -- especially as many sites are switching to responsive design and using a single domain to serve all content.


As @Stephen points out, you are sending cache controls that override the default cache periods for a 301. Likely your CMS is sending out these headers and it may not be an easy fix because.

Since your canonical URL is www.domain.com, I am not sure I would worry about this too much unless you see a lot of redirects in your access logs. Don't overly focus on every PageSpeed recommendation. Put them into context of your site and evaluate the cost-benefit of trying to address it.

In fact, I've seen some PageSpeed recommendations actually hurt real-world site performance or compromise user-experience. If your goal is SEO, having an engaging site is far more important than have one that is 100ms faster.

Your Answer

