Meta refresh redirect
meta_refreshShort answer
The page uses <meta http-equiv="refresh" content="0; url=…"> to send visitors elsewhere. Google does follow it and treats an instant meta refresh as a permanent redirect, but it is slower, the page still has to be fetched and parsed, and a delayed refresh is treated as temporary. Use a server-side 301.
Why it matters
A meta refresh is a page that says "go somewhere else" after loading. Visitors see a flash of the old page; crawlers must download the HTML before learning the destination; and because the response is 200, nothing at the HTTP level tells caches, CDNs or tools that the URL moved. A 301 does all of that in one response.
How Glimana detects it
The crawler looks for a meta http-equiv="refresh" tag with a URL in a 200 response.
How to fix it
- Find the affected pages in Glimana. Open Issues › Meta refresh redirect. Every affected page is a row; open one to see the evidence Glimana recorded for it (the measured value, the offending element or the target URL). The same list sits on the task card under Tasks, and the page's own detail view under Pages shows its full signals.
-
Apply the fix on your platform.
Create the redirect in Redirection or your SEO plugin's redirect manager and delete the meta tag from the page or theme.
Online Store → Navigation → URL redirects. Remove any
<meta http-equiv="refresh">from the template.Return
301 Location: …from the server or application for the old path. -
Publish and clear caches. Save and publish, then make sure the crawler will see the new version: WordPress — clear the page cache in your cache plugin and purge the CDN; Shopify — theme and content changes go live on save, but purge any CDN in front of the store; custom code — deploy and purge the edge cache. Check in a private window or with
curl -s https://your-domain/page | grep -i '<title\|canonical\|robots'that the live HTML has changed; Glimana reads what the server sends, not what your browser has cached. - Verify in Glimana. Open the task under Tasks and click Mark as done. The affected pages are queued for a verification crawl within a few hours, and the task closes when the URL returns a 3xx or no longer contains a refresh tag. If the check still fails, the task returns to New with a note; when it passes, the task is listed under Resolved technical issues on Impact reports. To check sooner, use Re-crawl affected pages on the issue.
How the fix is verified
Re-crawl; the task closes when the URL returns a 3xx or no longer contains a refresh tag.