Google and Yahoo accept undelayed meta refreshs as 301 redirects

Although the meta refresh often gets abused to trick visitors into popup hells by sneaky pages on low-life free hosts (poor man’s cloaking), search engines don’t treat every instance of the meta refresh as Webspam. Folks moving their free hosted stuff to their own domains rely on it to redirect to the new location:
<meta http-equiv=refresh content="0; url=" />

Yahoo clearly states how they treat a zero meta refresh, that is a redirect with a delay of zero seconds:

META Refresh: <meta http-equiv=”refresh” content=…> is recognized as a 301 if it specifies little or no delay or as a 302 if it specifies noticeable delay.

Google is in the process of rewriting their documentation, in the current version of their help documents the meta refresh is not (yet!) mentioned. The Google Mini treats all meta refreshs as 302:

A META tag that specifies http-equiv=”refresh” is handled as a 302 redirect.

but that’s handled differently on the Web. I’ve asked Google’s search evangelist Adam Lasnik and he said:

[The] best idea is to use 301/302s directly whenever possible; otherwise, next best is to do a metarefresh with 0 for a 301. I don’t believe we recommend or support any 302-alternative.

Thanks Adam! I’ll update the last meta refresh thread.

If you have the chance to do 301 redirects don’t mess with the meta refresh. Utilize this method only when there’s absolutely no other chance.

Full stop for search geeks. What follows is an explanation for not that experienced Webmasters in need to move their stuff away from greedy Web content funeral services, aka free hosts of any sort.

Ok, now that we know the major search engines accept an undelayed meta refresh as poor man’s 301 redirect, how should a page having this tag look like in order to act as a provisional permanent redirect? As plain and functional as possible:
<title>Moved to new URL:</title>
<meta http-equiv=refresh content="0; url=" />
<meta name="robots" content="noindex,follow" />
<h1>This page has been moved to</h1>
<p>If your browser doesn't redirect you to the new location please <a href=""><b>click here</b></a>, sorry for the hassles!</p>

As long as the server delivers the content above under the old URL sending a 200-OK, Google’s crawl stats should not list the URL under 404 errors. If it does appear under “Not found”, something went awfully bad, probably on the free host’s side. As long as you’ve control over the account, you must not delete the page because the search engines revisit it from time to time checking whether you still redirect with that URL or not.

[Excursus: When a search engine crawler fetches this page, the server returns a 200-OK because, well, it’s there. Acting as a 301/302 does not make it a standard redirect. That sounds confusing to some people, so here is the technical explanation. Server sided response codes like 200, 302, 301, 404 or 410 are sent by the Web server to the user agent in the HTTP header before the server delivers any page content to the user agent (Web browser, search engine crawler, …). The meta refresh OTOH is a client sided directive telling the user agent to disregard the page’s content and to fetch the given (new) URL to render it instead of the initially requested URL. The browser parses the redirect directive out of the file which was received with a HTTP response code 200 (OK). That’s why you don’t get a 302 or 301 when you use a server header checker.]

When a search engine crawler fetches the page above, that’s just the beginning of a pretty complex process. Search engines are large scaled systems which make use of asynchronous communication between tons of highly specialized programs. The crawler itself has nothing to do with indexing. Maybe it follows server sided redirects instantly, but that’s unlikely with meta refreshs because crawlers just fetch Web contents for unprocessed delivery to a data pool from where all sorts of processes like (vertical) indexers pull their fodder. Deleting a redirecting page in the search index might be done by process A running hourly, whilst process B instructing the crawler to fetch the redirect’s destination runs once a day, then the crawler may be swamped so that it delivers the new content a month later to process C which ran just five minutes before the content delivery and starts again not before next Monday if that’s not a bank holiday…

That means the old page may gets deindexed way before the new URL makes it in the search index. If you change anything during this period, you just confuse the pretty complex chain of processes what means that perhaps the search engine starts over by rolling back all transactions and refetching the redirecting page. Not good. Keep all kind of permanent redirects forever.

Actually, a zero meta refresh works like a 301 redirect because the engines (shall) treat is as a permanent redirect, but it’s not a native 301. In fact, due to so much abuse by spammers it might be considered less reliable than a server sided 301 sent in the HTTP header. Hence you want to express your intention clearly to the engines. You do that with several elements of the meta refresh’ing page:

  • The page title says that the resource was moved and tells the new location. Words like “moved” and “new URL” without surrounding gimmicks clear the message.
  • The zero (second) delay parameter shows that you don’t deliver visible content to (most) human visitors but switch their user agent right to the new URL.
  • The “noindex” robots meta tag telling the engines not to index the actual page’s contents is a signal that you don’t cheat. The “follow” value (referring to links in BODY) is just a fallback mechanismn to ensure that engines having troubles to understand the redirect at least follow and index the “click here” link.
  • The lack of indexable content and keywords makes clear that you don’t try to achieve SE rankings for anything except the new URL.
  • The H1 heading repeating the title tag’s content on the page, visible for users surfing with meta refresh = off, accelerates the message and helps the engines to figure out the seriousness of your intent.
  • The same goes for the text message with a clear call for action underlined with the URL introduced by other elements.

Meta refreshs like other client sided redirects (e.g. window.location = ""; in JavaScript) can be found in every spammer’s toolbox, so don’t leave the outdated content on the page and add a JavaScript redirect only to contentless pages like the sample above. Actually, you don’t need to do that, because the number of users surfing with meta-refresh=off is only a tiny fraction of your visitors, and using JavaScript redirects is way more risky (WRT picky search engines) than a zero meta refresh. Also, JavaScript redirects –if captured by a search engine– should count as 302 and you really don’t want to deal with all the disadvantages of soft redirects.

Another interesting question is whether removing the content from the outdated page makes a difference or not. Doing a mass search+replace to insert the meta tags (refresh and robots) with no further changes to the HTML source might seem attractive from a Webmaster’s perspective. It’s fault-prone however. Creating a list mapping outdated pages to their new locations to feed a quick+dirty desktop program generating the simple HTML code above is actually easier and eliminates a couple points of failure.

Finally: Make use of meta refreshs on free hosts only. Professional hosting firms let you do server sided redirects!

Share/bookmark this: del.icio.usGooglema.gnoliaMixxNetscaperedditSphinnSquidooStumbleUponYahoo MyWeb
Subscribe to      Entries Entries      Comments Comments      All Comments All Comments

25 Comments to "Google and Yahoo accept undelayed meta refreshs as 301 redirects"

  1. Richard Hearne on 4 September, 2007  #link

    One small issue with this will be ‘how long?’. Given that it can take many weeks (months even) for a 301 to be reflected in the SERPs, I wonder how long it will take for the refresh to take effect in the index?


  2. Sebastian on 4 September, 2007  #link

    Depends totally on PageRank which rules the crawl frequency. If the old site has enough PageRank to get crawled frequently, the redirecting pages will disappear quickly, usually before the new pages are indexed.

    To shorten the procedure it makes sense to link to the new locations a while before the move, and to submit an XML sitemap for the new site. Again, the optimal duration of “a while before” depends on the particular crawling schedule.

    I guess that with a toolbar PR GE 4 (main page) on a small or medium sized site which has not too many pages buried in deep link levels such a move could be finished within three or maximal four weeks, if the crawlers get steered properly by the Webmaster. That’s an example I’ve monitorred, however it’s imposible to adapt that in general because the duration of the move depends on site specific factors like PageRank flow and such.

    I don’t think the meta refresh is much slower than the native 301. And both the crawlers as well as the indexers work in lightning speed nowadays. Although Google has the best time to index, other engines may finish such a move faster because they don’t waste much time with assigning trust etcetera to the new server.

    Long story short, the answer is somewhere in between unknown and depends. ;)

  3. Oleg on 4 September, 2007  #link

    Fantastic. I am writing a script and wanted to know the answer to this very question. Thanks.

  4. Sebastian on 4 September, 2007  #link

    Glad you found it.

  5. Sergi on 4 September, 2007  #link

    Thanks for the confirmation.

    I had to use it lately, I didn’t know how Google would react and I set a 2 seconds delay.

    It takes less than 2 weeks for the old pages to disappear from Google’s SERPs.
    Yahoo! index still have a few of them.

  6. […] I’ve been asked the question time and time again! “Do I have to do a 301 redirect or can I do a Meta redirect? My IT guy says we can’t do a 301 redirect.” I recently came across this article from Sebastian’s Pamphlets; “Google and Yahoo accept undelayed meta refreshs as 301 redirects.” […]

  7. Tim Abracadabra on 6 September, 2007  #link

    Thank you for the definitive answer wrt “meta refresh” redirects. Personaly, I would have thought the noindex meta would be implied and that would be sufficient but you make a good point about about making your intentions clear. Very thorough.

    Getting Adam Lasnik’s input makes this already outstanding post good as gold.

    Thanks Again,


  8. Prometeo on 7 September, 2007  #link

    301 Weiterleitung vs. Meta Refresh…

    [Link juice blocked - post doesn’t link here]

  9. Ryan on 24 September, 2007  #link

    Sometimes you really do have no choice but to use meta refresh. . .such as with Yahoo! which prevents users from ANY access to the .htaccess file.

    Thanks for the info. I guess we don’t have to leave Yahoo! after all (although, I still wish we had not picked them when we started - avoid at all costs!!).


  10. […] Here’s why: Google and Yahoo accept undelayed meta refreshs as 301 redirects […]

  11. […] 307 redirect introduced in HTTP 1.1 too. For information on client sided redirects please refer to Meta Refresh - the poor man’s 301 redirect or read my other pamphlets on redirects, and stay away from JavaScript URL […]

  12. Rebecca on 18 December, 2007  #link

    Thank you! This was news to me and is about to make my life a lot easier! I’m going to tag it with!

  13. KEVIN on 15 January, 2008  #link

    Will a meta refresh cause a long delay: I am using the following and there is a 4-5 second delay the fist time you load the page:
    META HTTP-EQUIV=”Refresh” CONTENT=”0;URL=main/Main.action”
    There is just a white page. Then 5 seconds, then the page redirects and loads.

    Any Ideas?

  14. Sebastian on 16 January, 2008  #link

    Kevin, try it with an absolute URL:
    meta http-equiv=”refresh” content=”0; url=”

  15. […] sends visitors to your blog homepage directly to your new URL, and, as Sebastian’s Pamphlets says, is a search-engine safe method of […]

  16. Cirurgia Plastica on 3 May, 2009  #link

    Excellent article. I have 2 sites with pr 5 in geocities, and as everione knows, by the end of the year,geocities is closing. I hope that the meta refresh works and i dont loose the pr in my geocities sites

  17. […] Chodzą wieści, że Google umie czytać ten typ przekierowania z kodu HTML - ale na rewelacyjny przelew PageRank bym nie liczył. […]

  18. […] a comment Go to comments Yes, its true. You can 301 redirect using META HTML tag according to Sebastian. He says, Yahoo and Google accept it as 301 redirect. Though, it must be least preferred method. […]

  19. […] Prior to implementing this, I wanted to verify that Google would indeed see the meta refresh as a 301 redirect.  I had considered adding 301 redirect code, followed by a meta refresh. Upon some additional searching, I found an excellent article by SebastianX entitled, “Google and Yahoo accept undelayed meta refreshs as 301 redirects “. […]

  20. […] What I have done is use a meta redirect in the header with zero delay which is meant to act like a 301 redirect. […]

  21. moshxsoft on 17 September, 2010  #link

    thanks for this post
    is this method safe for google search engine?

  22. […] refreshes may be indexed as normal._(References: SEO Advice: 302 Redirects, Canonical URL Tags, Google + Yahoo! w/ Meta Refreshes)_How can the meta robots tag impact how search engines crawl, index and display content on a web […]

  23. […] that META Refresh is deprecated method, it is best option we have. Additionally, I found some posts which suggests that it works […]

  24. […] (References: SEO Advice: 302 Redirects, Canonical URL Tags, Google + Yahoo! w/ Meta Refreshes) […]

  25. […] I’ve been asked the question time and time again! “Do I have to do a 301 redirect or can I do a Meta redirect? My IT guy says we can’t do a 301 redirect.” I recently came across this article from Sebastian’s Pamphlets; “Google and Yahoo accept undelayed meta refreshs as 301 redirects.” […]

Leave a reply

[If you don't do the math, or the answer is wrong, you'd better have saved your comment before hitting submit. Here is why.]

Be nice and feel free to link out when a link adds value to your comment. More in my comment policy.