Use of noarchive

I understand that with the noarchive meat tag, the SEs won’t cache pages. What does that mean from a practical standpoint?

Are there times when you should use it and times when you should not? I haven’t been able to find much beyond the cache concept, and again, maybe in my ignorance, I don’t even understand what that means in this context. Any help explaining the practical concepts surrounding noarchive would be greatly appreciated. Thanks

See if this is any help:

Thanks Ralph. I had actually run across that site but on a different page. It appears to me that I want to noarchive any indexed page on my site and have done so but will spend some more time on that site to make sure I understand it more thoroughly. Thanks for the heads up. If after reading all that I have more questions, I’ll be back. :slight_smile:

Google does create a cached version of your web page but it does not show cached link to that page. this means, Google knows about the latest version of the page it won’t show it to the user (unless you are using cache command).

I have read most of what I can find and there aren’t many definitive answers out there that I have found. It seems the sentiment runs about 4 to 1 against caching but I’m not really sure why you would want to cache pages. So given that, I think in my case I will definitely switch to noarchive.

So if I start with the premise that caching is a bad thing, I would appreciate it if anyone can share some insight into the practical side of this such as to when caching is actually a good thing and why?


Caching allows Google to give a preview of your page, and it also means that people can access the content (and links etc) even if your site goes offline for any reason. There have been times when a site has been temporarily down but I’ve been able to find what I needed from Google’s cached version. Sometimes I’ve been able to bypass oversensitive corporate security settings by going to a cached version of the page.

Why would you not want Google to cache the page?

Thanks so much for the input. When you ask the question “Why would you not want Google to cache the page”, I guess I don’t know. That’s why I posted this in the first place. I don’t really understand the pros and cons of caching, which again is why I posted this.

I went out to Google and did a specific search and my main page showed up in a cached version since I didn’t have noarchive set previously. The page had changed and the cached version was several days old. I don’t want to show older versions of pages.

My site is updated frequently so timing of page delivery is important to me. It is for that reason I suppose that I was thinking I didn’t want them cached.

And when you say you can bypass “oversensitive” corporate security settings, that concerns me. Is that for Google to decide or the oversensitive corporation. The pages are theirs, not Google’s. Unless I’m not understanding that at all.

No, that was nothing to do with Google really. We have various filters on our web server at work, that sometimes block pages for no apparent reason. At one time (although they have now fixed this), there was a gaping hole in the system where it often allowed you to look at a cached version of the page, although that didn’t usually work if there was anything seriously dodgy on there. But that was a problem because of our dodgy security settings, not because Google was doing anything devious or underhand.


So does it sound reasonable that if I have frequent changes to the site and always want current pages displayed that I would prefer not to use caching? Is that a valid reason for that?

I doubt that more than a handful of people use the cache option rather than the main site unless there’s a problem with the main site. It’s up to you, but I doubt you would be getting any noticeable number of people looking at Google’s cached version so I don’t see the point.

This is a slightly different issue, but if it’s important to you that people only access the latest version of your pages, you might want to look at this article.