BlogFindings
Meta refresh redirect: 14 of 1,069 home pages used one, and 10 served under 100 words first
Lantad fetched the home page of all 1,419 hostnames in this repository's two committed corpus seed files on 7 November 2026 as LantadBot/1.0, with HTTP redirects followed and no JavaScript executed. 1,069 answered with HTTP 200 and an HTML content type. 14 of those 1,069 carried a meta refresh pragma in the initial HTML, which moves a client without any HTTP status code to say so. 13 named a URL, 12 of the 13 fired instantly, and 10 of the 14 handed a crawler fewer than 100 words of prose before the refresh. Two handed it none at all.
A meta refresh is the other kind. The response is an ordinary HTTP 200 with an ordinary HTML body, and the instruction to go somewhere else sits inside the document as a pragma directive on a meta element. Nothing in the headers mentions it. Lantad fetched the home page of all 1,419 hostnames in this repository's two committed corpus seed files on 7 November 2026, every request sent as LantadBot with HTTP redirects followed and no JavaScript executed, and 1,069 of them answered with HTTP 200 and an HTML content type. 14 of those 1,069 carried a meta refresh. That is a small number, and the reason it is worth 14 named sites rather than a percentage is what sat on the pages themselves: 10 of the 14 gave a crawler fewer than 100 words of prose before the directive, and two gave it none.
In short
- A meta refresh redirect is a redirect that leaves no trace in the response: the status line still reads 200 and the move is a pragma inside the HTML. Lantad measured 14 of the 1,069 corpus home pages that answered with HTTP 200 and an HTML content type on 7 November 2026 carrying one.
- Following it is optional under the HTML Living Standard. Section 4.2.5.3 lists the steps a user agent must perform on a refresh pragma, and one of the permitted options is to do nothing, so a client that ignores the directive is conforming rather than broken.
- Google's documentation states that Google Search interprets instant meta refresh redirects as permanent redirects and delayed ones as temporary. The crawler documentation OpenAI, Anthropic and Perplexity published, all three read at source on 7 November 2026, says nothing about meta refresh, JavaScript rendering or HTML level redirects at all.
- 10 of the 14 sites served under 100 words of prose before the refresh on 7 November 2026, and irishrail.ie and rbc.com served zero. A client that does not act on the pragma reads what is there, which on those two pages is nothing.
- All 14 sat in the eight industry strata, with finance carrying 5 of its 127 sites. The ten platform strata, which between them hold 392 sites built on Framer, Webflow, Wix, Squarespace, Shopify, WordPress, Bubble and static documentation stacks, returned 0.
| Site | Delay | Target named in the content attribute | Words of prose served first |
|---|---|---|---|
| irishrail.ie | 0s | /en-ie | 0 |
| rbc.com | 0s | https://www.rbc.com/about-rbc.html | 0 |
| amsterdamumc.nl | 0s | /web/show | 1 |
| kdca.go.kr | 0s | /kdca/index.do | 1 |
| bb.com.br | 0s | /site | 1 |
| sciencespo.fr | 0s | ./fr | 5 |
| southwest.com | 0s | /html/errors/javascript_disabled.html | 7 |
| contpaqi.com | 0s | https://www.contpaqi.com/ | 10 |
| sbi.co.in | 5s | https://sbi.bank.in/ | 39 |
| op.fi | 0s | /c/portal/no-javascript | 78 |
| mercadolivre.com.br | 0s | /gz/webdevice/config with noscript=true | 1,048 |
| navyfederal.org | 0s | https://web.navyfederal.org/safe-browsing.php | 1,319 |
| slack.com | 0s | /?nojsmode=1 | 1,861 |
| thehill.com | 900s | no URL, so the page reloads itself | 3,214 |
What a meta refresh redirect is, and why it carries no HTTP status
The directive is defined in the HTML Living Standard under section 4.2.5.3, Pragma directives, in the state the specification calls refresh. The URL for that section is html.spec.whatwg.org/multipage/semantics.html#attr-meta-http-equiv-refresh, written here as plain text because the host is not on this site's registered outbound list. The content attribute must hold either a bare non-negative integer, which the specification says is a number of seconds before the page is to be reloaded, or an integer followed by a separator and a URL clause. The URL is resolved against the document, and processing stops if it fails to parse or if its scheme is javascript.
Two properties of that definition decide everything else in this post. The first is that it is a property of the document rather than of the response, so the transport layer carries no sign of it. A monitoring tool that reads status codes sees HTTP 200. A tool that records response headers finds no Location. The move is only visible to something that parses the HTML and then chooses to act on what it found, which is a different and later decision from fetching the page.
The second is that acting on it is optional. The specification tells a user agent to perform one or more of a short list of steps once the refresh comes due: navigate to the URL, or offer the user an interface that navigates there when selected, or do nothing. Doing nothing is in the specification. A client that parses the pragma, understands it perfectly and declines to follow it is conforming, which is not true of a client that ignores a 301. That asymmetry is the whole reason a meta refresh behaves differently for an AI crawler than a server-side redirect does, and it is why the two cannot be reasoned about together.
Google's own guidance treats the mechanism as a fallback rather than a fault. The redirects documentation for Google Search states that if server-side redirects are not possible to implement on your platform, meta refresh redirects may be a viable alternative, and it recommends JavaScript redirects only where neither a server-side nor a meta refresh redirect can be done. So this is not a deprecated tag anybody is being told to remove. It is a documented third choice, and the question this post asks is what happens to it on the way to an answer engine.
Flow: Client requests the home page (HTTP redirect) to Server answers 301 with Location; Client requests the home page (meta refresh) to Server answers 200 with HTML; Server answers 301 with Location to Every client follows it; Every client follows it to Client reads the real page; Server answers 200 with HTML to Client parses the refresh pragma; Client parses the refresh pragma to Spec allows navigate or do nothing; Spec allows navigate or do nothing (navigate) to Client reads the real page; Spec allows navigate or do nothing (do nothing) to Client keeps the stub it was sent.
Do AI crawlers follow a meta refresh redirect?
This is the question a site owner needs answered, and the honest answer is that for the AI crawlers it is not published. Lantad has not observed GPTBot, ClaudeBot or PerplexityBot resolving a refresh pragma, this post does not claim to have, and the measurement above is of the site side rather than the crawler side. What can be established is what each operator commits to in writing, so that is what was checked, by opening each page at source on 7 November 2026.
Google is the one that documents it. The redirects guidance quoted above differentiates between two kinds of meta refresh redirect, instant and delayed, and states that Google Search interprets instant ones as permanent redirects and delayed ones as temporary redirects. Instant means it triggers as soon as the page is loaded in a browser, delayed means after an arbitrary number of seconds set by the site owner. That distinction lands directly on the measurement: 12 of the 13 corpus pages that named a URL used a zero second delay, and sbi.co.in used five seconds, which puts it on the temporary side of Google's own split.
The three AI vendors document nothing. OpenAI's crawler page describes GPTBot, OAI-SearchBot, ChatGPT-User and OAI-AdsBot, publishes user agent strings and IP address files, and explains that robots.txt changes take about 24 hours to affect search results. It contains no sentence about JavaScript rendering, meta refresh or HTML level redirects. Anthropic's crawler article covers ClaudeBot, Claude-User and Claude-SearchBot, says Crawl-delay is supported and that IP based blocking is not a reliable opt out, and carries the update marker "Updated this week" with no specific date. It is silent on the same three subjects. Perplexity's bots guide documents PerplexityBot and Perplexity-User, including that the user fetcher generally ignores robots.txt because a person asked for the page, and is silent as well.
That silence is consistent with what these pages leave out elsewhere. Lantad has reported that 2 of 9 operators say either way whether they render JavaScript, and the HEAD request measurement found that OpenAI's and Google's crawler documentation name no HTTP request method at all. The documentation is written to tell you how to block a crawler, not how it parses a document. So a site that depends on a refresh pragma to reach its own content is depending on behaviour that three of the four operators have never described, and the specification allows all of them to skip.
| Operator documentation | Mentions meta refresh | Mentions JavaScript rendering | What it does commit to |
|---|---|---|---|
| Google Search redirects guidance | Yes | Yes, as a third option | Instant read as permanent, delayed as temporary |
| OpenAI crawler page | No | No | Four tokens, IP files, robots.txt in about 24 hours |
| Anthropic crawler article | No | No | Three tokens, Crawl-delay, no IP based opt out |
| Perplexity bots guide | No | No | Two tokens, IP ranges, user fetches ignore robots.txt |
How many home pages send one, and what a crawler reads first
14 of 1,069. The denominator is the home pages that answered LantadBot with HTTP 200 and an HTML content type on 7 November 2026, out of the 1,419 hostnames in the corpus seed files, and the detector parsed every meta element on each page and compared its http-equiv attribute case-insensitively rather than pattern matching the raw tag, so a tag written with its attributes in an unusual order is still counted. The pass was run twice and returned the same 14 both times.
The interesting half is not the count but the prose underneath it. For each page the words of readable text in the initial HTML were counted with script, style, noscript, template and SVG content removed along with HTML comments, which is the same thing prose parity measures when it compares what a crawler receives against what a browser renders. Ten of the 14 came in under 100 words. irishrail.ie and rbc.com served zero: the entire response is a head, a refresh pragma and nothing a reader could read. amsterdamumc.nl, kdca.go.kr and bb.com.br served one word each, and amsterdamumc.nl titled that document "redirect", which is an accurate description of a page that is not meant to be read.
Four pages are the other shape. thehill.com served 3,214 words, slack.com 1,861, navyfederal.org 1,319 and mercadolivre.com.br 1,048. On those the refresh is not carrying the content: the content is already there, and a client that ignores the pragma still gets the article or the marketing page. That split matters for how the finding should be read. A meta refresh is not in itself a visibility problem, and saying so would be the easier post to write. It becomes one when the page holding it is a stub, and 10 of these 14 are stubs.
The distribution across the corpus strata is lopsided in a way worth stating. All 14 sit in the eight industry strata and none in the ten platform strata, which between them hold 392 sites built on Framer, Webflow, Wix, Squarespace, Shopify, WordPress, Bubble and static documentation stacks. Finance carried 5 of its 127 sites, the heaviest of any stratum: bb.com.br, navyfederal.org, rbc.com, op.fi and sbi.co.in. Travel carried 2 of 130, healthcare 2 of 123, software as a service 2 of 130, and education, news and ecommerce one each. Government, at 129 sites, carried none. This is the same pattern the HEAD request measurement found: the divergences cluster in the strata that build and operate their own stacks, and are absent from the ones where a platform vendor decides what the response looks like.
Four sites pointed the crawler at a URL that says no JavaScript
Four of the 14 targets name the absence of JavaScript in the URL itself, and reading them in order explains what the pragma is doing on those sites. slack.com points at /?nojsmode=1. southwest.com points at /html/errors/javascript_disabled.html. mercadolivre.com.br points at a path under /gz/webdevice/config carrying noscript=true. op.fi points at /c/portal/no-javascript. These are no-JavaScript fallback routes, and the refresh is how the server moves a client that has not run any script onto them, because a response cannot know whether script will execute and a pragma that fires on parse is the only signal available before it does.
For a browser that outcome is reasonable. For a client that does not execute JavaScript, and Common Crawl is the published example of one operating at scale, the fallback is the only route available, and what it leads to is then the whole of what the site said. On southwest.com it leads to a page titled "JavaScript Required" holding 90 words, fetched as LantadBot on 7 November 2026. That is the destination: a site that sells flights, reached through its own documented redirect, answering with an error notice. op.fi is starker. Its target returned HTTP 200 with a body of zero bytes on the same date, so a client that follows the directive correctly ends on nothing at all.
The other two do not degrade. Following slack.com's target returned the same 1,861 words as the home page itself, so the refresh changes nothing a crawler would notice. mercadolivre.com.br's target resolved back to its own home page carrying 1,046 words, two fewer than the first fetch, and the refresh pragma was present again on arrival. navyfederal.org behaves the same way: following its target at web.navyfederal.org resolved to the www home page, which served the same 1,319 words and the same refresh pointing at the same place. Two of the 13 destinations therefore repeat the instruction that sent the client there, which is a loop a client either breaks by its own rule or rides until a limit stops it.
None of this is detectable from the status line, which is the point of the section. Each of these responses is an HTTP 200. A reachability check passes. A redirect audit that reads Location headers finds nothing, exactly as a soft 404 passes a status check while telling a crawler that a missing page exists. The failure is one layer up, in what the 200 contains, which is where the AI Visibility Score puts the majority of the points a site loses.
LantadBot against southwest.com and op.fi, 7 November 2026
- GET https://www.southwest.com/ 200, 7 words of prose
- meta http-equiv=refresh content=0;url=/html/errors/javascript_disabled.html parsed from the HTML
- GET /html/errors/javascript_disabled.html 200, 90 words
- title: JavaScript Required the destination
- GET https://www.op.fi/ 200, 78 words of prose
- meta http-equiv=refresh content=0; URL=/c/portal/no-javascript parsed from the HTML
- GET /c/portal/no-javascript 200, body of 0 bytes
What a crawler gains by following the refresh, and loses by not
Because every target was fetched as well, the cost of ignoring the pragma can be stated per site rather than argued in general. On eight of the 13 pages that named a URL, following the directive turned a stub into a document. irishrail.ie went from 0 words to 785 at /en-ie. rbc.com went from 0 to 671 at its about page. kdca.go.kr went from 1 word to 1,165. amsterdamumc.nl went from 1 to 482, bb.com.br from 1 to 212, sciencespo.fr from 5 to 622, contpaqi.com from 10 to 2,289, and sbi.co.in from 39 words to 3,137 at sbi.bank.in, the largest gain measured.
Those are the numbers that make the directive load-bearing. A client that follows it reads the site. A client that does not, and the specification permits that, reads a page with nothing on it and has no way to report that anything is missing, because nothing in the response said anything was. The site has not been blocked and no rule in robots.txt is involved. It has simply described its content in a place a client is allowed to disregard, which is a different failure from the ones a robots.txt tester is built to find.
The remaining five divide into cases already covered. slack.com, navyfederal.org and mercadolivre.com.br serve their prose on the first page, so nothing is at stake. southwest.com and op.fi lead somewhere worse than where they started. thehill.com names no URL, so there is nothing to follow: its content attribute is the bare integer 900, which under the specification means reload this page in 900 seconds, and the 3,214 words were already delivered. Counting it among redirects would be the easy error here, and it is worth separating because it is the one case in the 14 where the pragma is doing what the bare-integer form was designed for.
A reader checking their own site should keep the two mechanisms apart. An HTTP redirect is consumed by every client before parsing, and its one real cost is latency, which Lantad measured when a redirect took half the wait on 184 of 379 home pages. A meta refresh is consumed only by a client that parses and then elects to act. If the content lives behind one, the content lives behind an optional step, and that is true however correct the markup is.
| Site | Words served first | Words at the target | What the target is |
|---|---|---|---|
| sbi.co.in | 39 | 3,137 | sbi.bank.in, a different hostname |
| contpaqi.com | 10 | 2,289 | The www home page |
| kdca.go.kr | 1 | 1,165 | An application path |
| irishrail.ie | 0 | 785 | The locale home page |
| rbc.com | 0 | 671 | The about page |
| sciencespo.fr | 5 | 622 | The locale home page |
| amsterdamumc.nl | 1 | 482 | A locale home page |
| bb.com.br | 1 | 212 | A site path |
| southwest.com | 7 | 90 | A JavaScript Required error page |
| op.fi | 78 | 0 | A 200 with an empty body |
| slack.com | 1,861 | 1,861 | The same page with a query string |
| navyfederal.org | 1,319 | 1,319 | Back to the home page, refresh repeated |
| mercadolivre.com.br | 1,048 | 1,046 | Back to the home page, refresh repeated |
This is not bot defence, and one site demonstrated the difference
A finding about crawlers receiving a degraded page invites the assumption that the degradation is aimed at them. On this measurement it is not, and the check that rules it out is simple enough to repeat: each of the 14 home pages was fetched again on 7 November 2026 with a desktop Chrome user agent string, and the two responses compared. 13 of the 14 carried the identical refresh pragma to both clients. The server is not deciding anything about who is asking, which is what you would expect given what the pragma is for. A response cannot detect script support, so the fallback has to be sent to everyone and then undone by whoever can run script.
The fourteenth is the exception that shows what bot handling actually looks like. thehill.com answered the desktop Chrome string with HTTP 403 and a seven word page reading "Access to this page has been denied", while answering LantadBot with HTTP 200 and 3,214 words, on the same date and within the same minute. That is a deliberate decision about a client, it runs the opposite way to the usual complaint, and it is a reminder that a user agent is a claim rather than an identity: the string that got the content here was the one naming a bot.
So the ten stub pages are not hostile. They are a rendering strategy whose last step is optional for the client that matters. That distinction decides what a site owner should do about it, because a blocking decision is reversed in robots.txt and a rendering decision is reversed in the response. Lantad has measured the second problem from several directions: JavaScript supplied 7.6 percent of the prose and all of it on 11 of 271 pages, and content that loads on scroll never loads for a crawler that does not scroll. A refresh pragma in front of an empty document belongs with those rather than with crawler access questions.
One related check is worth doing at the same time. Where a refresh points at a different URL, the page that holds the pragma and the page that holds the content are two addresses for one thing, and that is the condition in which 305 of 313 home pages answered at more than one live URL. A canonical link on the stub pointing at the destination is what resolves it, and on this corpus 163 of 1,069 home pages declared no canonical at all.
As LantadBot/1.0
- HTTP 200
- 3,214 words of prose
- meta refresh content=900, no URL
- Title: The Hill, covering Congress and politics
As a desktop Chrome string
- HTTP 403
- 7 words of prose
- No refresh pragma present
- Title: Access to this page has been denied
What to check on your own site
The check is cheap and does not need a tool. Request your own home page with curl and no JavaScript engine, read the body, and answer two questions in order. Does it contain a meta element whose http-equiv attribute is refresh, and if it does, how many words of prose arrived with it? A page carrying a refresh and a full document is fine. A page carrying a refresh and 11 words is a page whose content is behind a step the HTML Living Standard allows a client to skip, and nothing in the status code will tell you so. What GPTBot sees answers the same question against the raw HTML if you would rather not run the request yourself.
If you find one, the fix is ordered by what the pragma is there for. Where it exists because server-side redirects were hard to configure, Google's redirects guidance is explicit that a server-side redirect is the first choice and the meta refresh the fallback, so moving it into a 301 removes the optional step entirely and costs nothing in behaviour. Where it exists as a no-JavaScript fallback, as it does on four of these sites, the question is what the fallback route serves: a target that answers with an error notice or an empty body is worse than no fallback, because it converts a thin page into a confident wrong one.
Where the destination is genuinely a different address, add a canonical link on the stub pointing at it, and check that the target does not repeat the pragma that sent the client there. Two of the 13 targets measured here did. And if the content attribute is a bare integer with no URL, as on thehill.com, nothing needs doing: that is a reload interval and not a redirect at all, which is worth confirming before treating it as one.
The general lesson is the one this blog keeps arriving at from different mechanisms. The response status says whether a server answered. It says nothing about whether the answer contained the page, and the gap between those two is where most generative engine optimization work actually sits. The methodology sets out how Lantad separates the two, and the research page carries the running corpus measurements this post draws its denominator from.
- Does the initial HTML carry a refresh pragma at all 5 pts Parse every meta element rather than matching a tag pattern, because attribute order varies. 14 of 1,069 corpus home pages carried one on 7 November 2026.
- How many words of prose arrived with it 5 pts Ten of the 14 served under 100 words, and irishrail.ie and rbc.com served zero. A full document plus a refresh is not a problem.
- Is the content attribute a bare integer 3 pts A bare integer is a reload interval, not a redirect. thehill.com used 900 and had already served 3,214 words.
- Does the target serve the real page 4 pts southwest.com led to a 90 word JavaScript Required page and op.fi to a 200 with an empty body, both on 7 November 2026.
- Does the target repeat the same pragma 2 pts navyfederal.org and mercadolivre.com.br both sent the client back to a page carrying the instruction again.
- Is there a canonical link on the stub 3 pts Where the refresh crosses to another URL, two addresses serve one document until a canonical resolves which is which.
- Could a server-side redirect replace it 4 pts Google's redirects guidance names the server-side redirect first and the meta refresh as the alternative where that is not possible.
Lantad
Published .
An HTTP redirect announces itself. The server answers with a 301, a 302 or a 307, puts the new address in a Location header, and every client that reads the status line knows the page moved before it has parsed a single byte of content. RFC 9110 defines that machinery, and Lantad has measured how much of the web leans on it: 878 of 1,322 home pages answered with a redirect when asked for the bare hostname.
Common questions
Do AI crawlers follow a meta refresh redirect?
It is not published, and this post does not claim to have observed it. The crawler documentation OpenAI, Anthropic and Perplexity publish, all three read at source on 7 November 2026, says nothing about meta refresh, JavaScript rendering or HTML level redirects. Google is the exception: its redirects guidance states that Google Search interprets instant meta refresh redirects as permanent and delayed ones as temporary. The HTML Living Standard permits a client to do nothing with the pragma, so a crawler that ignores it is conforming.
Is a meta refresh bad for AI visibility?
Only when the page holding it is a stub. On 7 November 2026 four of the 14 corpus pages carrying one had already served their prose, between 1,048 and 3,214 words, so a client ignoring the pragma lost nothing. The other ten served under 100 words, and on those the content is reachable only by acting on an optional directive.
How do I tell a meta refresh from an HTTP redirect?
Read the status line. An HTTP redirect answers 301, 302, 307 or 308 and names the new address in a Location header, so it is settled before the body is parsed. A meta refresh answers 200 with an ordinary HTML body and hides the instruction in a meta element, which is why monitoring that reads status codes and headers shows nothing unusual on all 14 of the sites measured here.
What does a bare number in a meta refresh content attribute mean?
It is a reload, not a redirect. The HTML Living Standard says a bare non-negative integer is the number of seconds before the page is to be reloaded, with no new address involved. thehill.com was the one case of this in the corpus on 7 November 2026, with a content value of 900, and it had already served 3,214 words of prose.
See what AI can read on your site
Run a free scan and get a graded report of exactly what AI crawlers can and cannot read, with ranked fixes.
AI crawler
An AI crawler is an automated bot, such as GPTBot, ClaudeBot, or PerplexityBot, that fetches web pages so an AI system can read, train on, or cite what those pages contain.
Prose Parity
Prose Parity is Lantad's metric for the share of a page's rendered, human-visible text that is present in the raw HTML an AI crawler receives, where 100% means a crawler sees everything a human visitor sees.
Do AI crawlers follow redirects? 878 of 1,322 home pages answered with one
Lantad asked all 1,419 hostnames in this repository's two committed corpus seed files for robots.txt on 11 October 2026, then requested the home page of the 1,324 that permitted LantadBot with automatic redirect following switched off, and walked every Location header by hand. 878 of the 1,322 that answered were reached only through at least one HTTP redirect. 1,031 redirect responses carried five different status codes, 62 chains mixed a permanent code with a temporary one, and 14 of the readable home pages moved themselves again in the markup, four of those from inside a noscript element.
Soft 404: 125 of 1,094 sites answered a URL that does not exist with HTTP 200
Lantad asked all 1,419 hostnames in this repository's committed corpus for a path that cannot exist on 20 September 2026. 1,094 answered both that request and their own home page. 936 returned 404, 125 returned HTTP 200, and on a second nonexistent path of a different shape 111 of those 125 returned 200 again.
Client side rendering: JavaScript supplied 7.6 percent of the prose, and all of it on 11 of 271 pages
Lantad loaded the home page of 392 hostnames twice on 20 September 2026, from the same browser at the same moment, changing one thing between the two loads: whether JavaScript was allowed to run. On the 271 pages that answered HTTP 200 both times, the unrendered document held 173,138 words and the rendered one held 187,422. The average is undramatic and the distribution is not: 100 pages were word for word identical, and 11 returned nothing readable at all until the bundle ran.
AI crawler 405 error: 13 of 1,099 sites answered a HEAD request with 405 while GET returned 200
Lantad sent a HEAD request and then a GET to the home page of all 1,419 hostnames in this repository's two committed corpus seed files on 6 November 2026, as LantadBot/1.0 with redirects followed and no JavaScript executed. 1,099 answered the GET with HTTP 200. 1,054 of those answered the HEAD with 200 as well, 45 answered it with something else, and 13 answered it with 405 Method Not Allowed, which RFC 9110 section 9.1 forbids by requiring every general-purpose server to support GET and HEAD. 16 hosts refused HEAD with a 405 in all, 15 of the 16 reproduced it on a second read, and 14 of the 16 sent the same 405 to a desktop browser user agent, so this is server configuration rather than bot defence.
