Meta Refresh Redirect

A meta refresh redirect is a client-side HTML instruction placed inside the <head> of a webpage that tells the browser to automatically navigate to a different URL after a specified number of seconds. It uses the <meta> element with the http-equiv attribute set to "refresh" and a content attribute that defines both the delay time and the destination URL.

For example, this tag redirects to https://example.com/new-page after 5 seconds:

<meta http-equiv="refresh" content="5; url=https://example.com/new-page">

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

How the Meta Refresh Code Works

Every meta refresh tag sits inside the <head> section of an HTML document. The browser parses it before rendering visible page content, which is why the tag should be placed as high in the <head> as possible — ideally right after the opening <head> tag.

The Three Components of the Tag

1. <meta> element — identifies this as document-level metadata, not visible content.
2. http-equiv="refresh" attribute — tells the browser to treat this tag as if the server sent a Refresh HTTP header. It is the mechanism that bridges HTML and HTTP-level behavior.
3. content attribute — contains two pieces of information separated by a semicolon:

• A number representing the delay in seconds (0 for immediate).
• A url= parameter specifying the destination URL.

Common Syntax Errors

The most frequent implementation mistake is omitting the semicolon between the time integer and the URL string. When that semicolon is missing, the browser misinterprets the entire content value as a single command and the redirect fails silently. Another error is placing the <meta> tag inside the <body> instead of the <head>, which causes the browser to render page content before parsing the redirect directive — creating a jarring user experience.

Launch your affiliate program today

Set up advanced tracking in minutes. No credit card required.

Request demo Start 30-days free trial

Instant vs. Delayed Meta Refresh Redirects

The timing distinction matters: an instant (0-second) refresh passes stronger canonical signals than a delayed one, which Google may treat as a soft 404 if it cannot confirm the redirect intent.

What Visitors See

The user experience of a meta refresh redirect depends entirely on the delay value:

• 0-second redirect: The original page may flash briefly or not appear at all. In some browsers, the back button can behave unpredictably because the redirecting page never fully renders.
• Delayed redirect (1+ seconds): The visitor sees the original page for the specified number of seconds.

Some browsers allow users to disable meta refresh behavior entirely in their settings. When disabled, a delayed redirect never fires, and the visitor remains stuck on the original page unless a manual fallback link is provided. This is one reason why relying on meta refresh for critical navigation is risky.

Join our newsletter

Be the first to know about new features and product updates.

Email address

Subscribe

When to Use Meta Refresh (and When Not To)

Appropriate Use Cases

1. No server access. If you cannot modify .htaccess, Nginx configs, or server-side routing — for example, on a static HTML site hosted on a CDN with no edge-function support — a meta refresh is a functional fallback.
2. Single-file redirects in a directory. When you need to redirect one HTML file among many and cannot apply a directory-wide server rule.
3. CMS limitations. Some content management systems periodically overwrite .htaccess files, making server-side redirects fragile. A meta refresh embedded in the page itself survives those overwrites.
4. Temporary transition pages. Displaying a brief message before forwarding a user — such as a “Thank you, you’ll be redirected to your download” page — though JavaScript-based solutions are now preferred even for this.

When to Avoid Meta Refresh

• Permanent URL migrations. Use a 301 (permanent) or 308 (permanent, preserves HTTP method) server-side redirect instead. These pass link equity reliably and are processed faster by search engines.
• Site-wide redirects. Managing dozens of meta refresh tags across a site is error-prone and creates a poor crawling experience.
• Security-sensitive contexts. Meta refresh redirects can be exploited by spammers to deceive users and search engines. Overuse can cause search engines to flag a site as spam.
• Any situation where server-side redirects are available. Google’s own hierarchy is clear: server-side redirects first, meta refresh second, JavaScript redirects third.

Meta Refresh vs. Server-Side Redirects (301, 302, 307, 308)

What Does a 307 or 308 Redirect Mean?

A 307 (Temporary Redirect) and 308 (Permanent Redirect) are HTTP-status-code redirects that preserve the original request method. If a browser sends a POST request to /old-page and the server responds with a 307, the browser repeats the POST to the new URL. A 302 or 301, by contrast, may change the method to GET. Meta refresh redirects always result in a GET request to the destination URL, regardless of how the original page was accessed. This is another reason server-side redirects are preferred for form submissions and API endpoints.

SEO Implications

Crawling and Indexing

Search engines parse meta refresh tags during HTML rendering, which adds a step compared to server-side redirects that are processed at the HTTP level. Google has confirmed that instant (0-second) meta refresh redirects function similarly to permanent redirects, while delayed ones are treated as temporary signals. However, Google also acknowledges that it can make mistakes: a meta refresh may be interpreted as a soft 404 if the search engine cannot confirm the redirect intent, causing the original URL to remain in the index alongside the destination.

Link Equity

Meta refresh redirects do not pass link equity as reliably as 301 redirects. For affiliate marketers and site owners tracking referral traffic, this uncertainty can mean lost ranking signals for the destination page.

Spam Association

Meta refresh redirects have historically been used by spammers to funnel users to unrelated pages while showing search engines different content. As a result, sites that use meta refresh extensively may be scrutinized more closely by search quality algorithms. If your site audit flags a “meta refresh redirect” as a critical issue — as Ahrefs and Sitebulb do — it is worth replacing it with a server-side alternative wherever possible.

Best Practices Summary

1. Use server-side redirects (301/308 for permanent, 302/307 for temporary) as the default choice.
2. If meta refresh is unavoidable, use a 0-second delay to maximize the chance of correct interpretation.
3. Update internal links to point directly to the destination URL — do not link to pages that redirect.
4. Set a canonical tag on the destination page to reinforce the intended canonical URL.
5. Limit meta refresh usage to a small percentage of total site URLs.

Relevance to Affiliate Marketing and Affiliate Software

Redirecting Affiliate Links

Affiliate programs rely on redirects to track clicks, attribute conversions, and route users through offer pages. These are fast, reliable, and pass referral data without interruption.

A meta refresh redirect might appear in an affiliate workflow when:

• An advertiser migrates a landing page but cannot configure server redirects on the old URL. A 0-second meta refresh on the old page ensures visitors still reach the current offer.
• A publisher hosts a static HTML review page and needs to forward visitors to an updated merchant URL without access to server configuration.
• An affiliate program manager inherits a legacy site where old redirects were implemented via meta refresh and needs to audit and replace them systematically.

Practical Workflow: Replacing a Meta Refresh with a Server-Side Redirect

1. Audit: Run a site crawl (using Ahrefs, Sitebulb, or Screaming Frog) to identify all pages with meta refresh tags.
2. Map: For each redirecting URL, note the destination and the delay value.
3. Prioritize: Replace instant refreshes first — they signal permanent moves and affect indexing.
4. Implement: Add 301 redirects at the server level (.htaccess for Apache, nginx.conf for Nginx, or your CMS redirect manager).
5. Update internal links: Find every internal link pointing to the old URL and change the href to the new destination.
6. Verify: Test each redirect with a tool like Redirect Tracker to confirm the HTTP status code and final destination.
7. Monitor: Check Google Search Console for any indexing anomalies on the old URLs over the following weeks.

Limitations for Affiliate Stakeholders

• Tracking reliability: Meta refresh redirects can strip or alter referral parameters in some browser configurations, potentially breaking conversion attribution.
• Speed: A delayed redirect adds friction to the click-to-offer journey, which can reduce conversion rates — particularly on mobile devices where page-load expectations are sub-3-second.
• Compliance: Some affiliate networks explicitly require server-side redirects and may flag meta refresh implementations during compliance reviews.

Why Am I Being Redirected to Another Website?

If you land on a page and are automatically sent to a different URL, you are likely encountering one of these scenarios:

1. A meta refresh tag on the original page with a short or zero-second delay.
2. A server-side redirect (301/302/307/308) configured by the site owner — this is the most common and generally legitimate case.
3. A JavaScript redirect executing after the page loads.
4. A malicious redirect injected via compromised code, a rogue ad script, or browser malware.

To check which type you are experiencing, open your browser’s developer tools (F12), go to the Network tab, and look at the status code of the first request. A 301 or 302 confirms a server-side redirect. If the page loads with a 200 status and then navigates, you are seeing a client-side redirect — either meta refresh or JavaScript.