Meta refresh redirect: replace it with an HTTP 301

What it means

The page uses a <meta http-equiv="refresh"> tag to forward visitors to another URL, either immediately or after a timed delay. Google recommends an HTTP 301 as the correct mechanism for permanent moves and treats a meta refresh as a weaker canonicalization signal.

Why it matters

Meta-refresh redirects create three problems. Link-equity transfer is not guaranteed the way it is with a 301, so pages carrying inbound link value are at risk. Crawler deduplication is impaired — some crawlers index both the source and destination URL before resolving the refresh, producing duplicate-content signals a 301 would eliminate. And a non-zero-delay refresh fails WCAG 2.1 Success Criterion 2.2.1 (Timing Adjustable): users on screen readers, with cognitive disabilities, or on slow connections cannot control or cancel it.

How to fix it

1. Replace the meta refresh with a server-side HTTP 301 to the destination — e.g. return 301 https://example.com/new-page; in Nginx, res.redirect(301, '/new-page') in Express, or Redirect 301 /old /new in Apache.
2. Remove the <meta http-equiv="refresh"> line from the HTML.
3. If the move is temporary (a campaign or maintenance page), use a 302 instead of a 301.
4. On static hosts with no server-side redirect mechanism, a zero-second meta refresh is a last resort — but plan a migration to a host that supports proper redirects.

When it's not a problem

A zero-second meta refresh (content="0; url=...") is sometimes unavoidable on static hosting that offers no server-side redirect, and Google treats it similarly (though not identically) to a 301. On a print- or email-only landing page that is noindex and receives no inbound links the SEO impact is minimal — but the WCAG accessibility concern still applies regardless of indexing intent.

How common is it?

61 audited sites in our corpus currently show this issue. The breakdowns below show which platforms, gatekeepers, verticals and countries are most exposed.