Meta refresh: how Google reads an HTML page redirect

A meta refresh is a redirect written into a page's HTML as a <meta http-equiv="refresh"> element, not sent by the server. Google treats an instant one, with zero seconds' delay, as permanent and a delayed one as temporary. Among the ways to redirect, it is the fallback when the server cannot be changed.

What a meta refresh is

A meta refresh tells the browser to load another address once the page has arrived. The instruction sits in the page's <head>, and its content attribute holds two things: a number of seconds to wait, and the address to go to. Google's documentation on redirects, last updated on 2026-04-14 and checked on 2026-10-09, gives this example of an instant one:

<meta http-equiv="refresh" content="0; url=https://example.com/newlocation">

The same instruction can travel as an HTTP response header named Refresh, which Google lists as the equivalent and which a server-side script can set:

Refresh: 0; url=https://www.example.com/newlocation

The difference from an ordinary redirect is where the decision is made. A 301 or 302 is answered by the server before any page is sent. A meta refresh sends a page with a success status, and the redirect happens only when the browser reads it.

Instant and delayed

Google draws one line, and it falls at zero seconds. Its documentation names the two cases:

So the number in the content attribute does more than set a pause. A delay of five seconds, which a site might add to show a short "we have moved" message, turns a permanent move into a temporary one in Google's reading, and the old address stays in results. The 302 redirect page covers what a temporary signal means for search.

When a meta refresh is the right tool

A meta refresh is right when you cannot make the server answer with a redirect. Google puts it plainly: "If server-side redirects aren't possible to implement on your platform, meta refresh redirects may be a viable alternative." The W3C's accessibility technique H76 says the same from the reader's side: "Redirects are preferably implemented on the server side… but authors do not always have control over server-side technologies."

The typical cases are hosted platforms that let you edit pages but not server rules, static file hosting without redirect settings, and an old page left in place on a server nobody can reconfigure any more.

Google ranks the methods by how likely it is to interpret them correctly, and puts server-side redirects first and JavaScript redirects after meta refresh. If a server rule is available, it is the better choice.

Use zero seconds

Use an instant meta refresh unless there is a reason to show the page. Google reads it as permanent, and the W3C technique gives an accessibility reason as well: "It is important that the time-out is set to zero, to avoid that content is displayed before the new page is loaded."

A delay also causes trouble for people using screen readers. The W3C's failure F41 describes it: "If the time interval is too short, and there is no way to turn auto-refresh off, people who are blind will not have enough time to make their screen readers read the page before the page refreshes unexpectedly." A page that moves people on after a pause should instead offer a plain link and let them follow it.

Meta refresh compared with a 301

The two redirects reach the same address by different routes, and the route matters to crawlers, browsers and anyone measuring the move.

Both are read as permanent, so search treats them alike when they work. The server redirect is still the sturdier one: it covers images and documents as well as pages, and it does not depend on anything reading the HTML before acting on it.

Keeping the old page in place

A meta refresh lives inside the old page, so the old page has to stay. A server redirect can outlive the content it replaced, because the rule sits in the server's configuration; a meta refresh disappears the moment the file that carries it is deleted, and the old address starts answering with an error instead of sending people on.

That makes these pages easy to lose in a clean-up. Mark them as redirect pages wherever your site keeps its list of content, keep them out of navigation and internal links, and point every link you control at the new address directly. A visitor who arrives through an old bookmark still gets moved on; nobody else should need the detour.

If the server later becomes configurable, replace each meta refresh with a server redirect and remove the old page only after the new rule answers.

Checking a meta refresh

A meta refresh does not show up as a redirect in the response headers, which is why it is easy to miss. Request the old address and look at what comes back: a 200 status and a page whose <head> holds the refresh element, or a Refresh header. A trace that reads page content counts a meta refresh as a hop of its own, alongside server redirects; the kinds of hop and what each costs are covered under redirect tracing.

Check the delay as well as the target. A refresh with a delay other than zero is the most common reason a move meant to be permanent is read as temporary.

FAQ