: Non-cachable Canonical redirect of www to non-www 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

@Kevin317

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.

PageSpeed

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 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.

Vote Up Vote Down

@Megan663

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 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.

Vote Up Vote Down