BlogFindings
Do AI crawlers read tables? 87 on 1,079 home pages, and 2 carried a caption
Lantad's own component library says a table is the shape an AI crawler extracts most reliably, and a post in August checked that against five stored pages and found three tables. This run checked it against the whole corpus: 1,419 hostnames asked for robots.txt and then the home page as LantadBot on 23 September 2026, 1,079 pages read as raw bytes with no JavaScript, 38 of them carrying a table at all.
In August that claim was checked against the only pages this scanner had stored at the time, and the result was three table elements across five real pages, all three of them navigation boxes. Five pages cannot settle anything, and the post said so. This run asked the same question of the whole corpus: all 1,419 hostnames in the two committed seed files, each asked for robots.txt and then for its home page once, as LantadBot, on 23 September 2026, with no JavaScript executed. 1,079 of them answered HTTP 200 with HTML. The answer at that scale is not the one the question expects, because the interesting number is not what the tables contain. It is how few of them exist.
In short
- Asking whether AI crawlers read tables assumes there are tables to read: of the 1,079 home pages Lantad read as LantadBot on 23 September 2026, 1,041 carried no table element at all and 38 carried one.
- Those 38 pages held 87 table elements between them, and the text inside them came to 5,354 words against 1,374,580 words of visible text on the same pages, which is 0.39 percent of everything a text-only client could read.
- Two of the 87 tables carried a caption element, on dollyglot.com and metlife.com, and the MetLife one sits on a table that contains no cells at all.
- 41 of the 87 tables carried no th element anywhere, and of the 216 th elements in the corpus 100 carried a scope attribute, so fewer than half of the header cells state which direction they head.
- The same 1,079 pages carried 109,439 list items across 21,101 unordered lists, which is 1,258 list items for every table element: these sites enumerate constantly and express almost none of it as tabular data.
| What was counted | Figure | Against |
|---|---|---|
| Home pages read | 1,079 | of 1,419 hostnames asked |
| Pages carrying at least one table | 38 | 3.5 percent of the 1,079 |
| Table elements in total | 87 | median of 1 per page that had any |
| Tables carrying a caption element | 2 | dollyglot.com and metlife.com |
| Tables with no th element at all | 41 | of the 87 |
| Words of text inside tables | 5,354 | of 1,374,580 visible words, 0.39 percent |
| List items on the same pages | 109,439 | 1,258 for every table element |
Do AI crawlers read tables?
The question has two halves and only one of them is answerable from the outside. Whether a given crawler parses a table element into rows and columns, or flattens it into a run of text, is a property of software this scan never touched, and no AI crawler vendor documents it. Nothing in this post claims otherwise. What a scan of the delivered bytes can establish is the other half, which is whether there is anything tabular on the page to parse in the first place, and that half turns out to carry the weight.
1,041 of the 1,079 home pages carried no table element whatsoever. 38 carried at least one, which is 3.5 percent of the corpus. Those 38 pages held 87 tables between them, unevenly: 20 pages had exactly one, 7 had two, and 11 had three or more, with jalan.net carrying 17 and rbi.org.in carrying 7.
The share of readable text involved is the figure that settles the scale of it. Counting visible words over the served HTML with script, style, noscript, template and comment content removed and tags stripped, the 1,079 pages held 1,374,580 words. 5,354 of those words sat inside a table element. That is 0.39 percent, roughly one word in every 257. Whatever an answer engine does with table markup, on these pages it is doing it to a rounding error.
This is a different failure from the ones this blog usually counts, and worth separating from them. When 141 of 382 home pages carried no structured data in the raw HTML, the finding was that a described mechanism was going unused. When 17 of 380 home pages sent a crawler zero words, the finding was that the prose never arrived. Here the prose arrives in quantity, 1.37 million words of it, and the sites simply do not use the tabular shape to express any of it. Nothing is broken. A choice was made, at scale, by almost everybody, and the effect on prose parity is nil because the words are present either way. The effect is on structure, which is the part an extractor has to reconstruct rather than read.
What 1,079 home pages served a crawler
The denominator matters more than usual here, because a rate of 3.5 percent invites the objection that the missing pages were the ones with the tables. The funnel is therefore stated in full, and the pattern in the refusals is stated too.
1,419 hostnames were asked. Each was asked for https://host/robots.txt first, and the reply was evaluated with the scanner's own parser in core/src/robots.ts rather than a purpose-built one, so the crawl obeys the same rules the product ships. 11 hostnames carry an explicit Disallow covering the site root for LantadBot and were left alone: coralvilleanimalhospital.com, botcity.dev, amsterdam.nl, wa.gov, helsinki.fi, sciencedirect.com, scielo.org, theregister.com, sap.com, gmarket.co.kr and instacart.com. A further 36 answered robots.txt with HTTP 503, and the scanner's robotsPolicyFromStatus treats a failing robots.txt as disallow-all until it recovers, so those 36 were not fetched either. That is a decision recorded in the code and not a finding about those sites, and it is the conservative direction: it costs this run 36 pages rather than risking a fetch a crawler should not make. The terms are set out on the scanner's bot page.
Of the 1,372 hostnames that remained, 33 returned no status at all, and 260 answered with something other than HTTP 200 and an HTML content type. 215 of those 260 answered 403, 16 answered 503, 10 answered 202, 6 answered 429 and 4 answered 404, with the remainder split across 401, 405, 406, 451, 498, 500, 508 and one host that answered 200 with a content type that was not HTML. The 403s are the familiar shape: a site refusing an unrecognised user agent on sight, which this blog has measured directly when 92 of 1,056 sites refused GPTBot their robots.txt. Those 293 absent hostnames are not missing at random, because a site that refuses an unknown crawler is likelier to refuse other automation, so every rate below is a statement about the 1,079 that answered.
1,079 pages is the denominator for everything else in this post. The same seed files, the same user agent and the same refusal pattern produced the denominators in the recent runs on images and iframes, which is deliberate: a corpus that moves between posts cannot be compared across them. The full method for a single scan is on the methodology page, and you can watch the same request run against one host with what GPTBot sees.
Flow: 1,419 hostnames to Ask robots.txt as LantadBot; Ask robots.txt as LantadBot (11 disallow, 36 robots 503) to 47 not fetched; Ask robots.txt as LantadBot to 1,372 home pages requested; 1,372 home pages requested to 33 no status; 1,372 home pages requested (215 answered 403) to 260 not 200 HTML; 1,372 home pages requested to 1,079 read as raw bytes; 1,079 read as raw bytes (87 table elements) to 38 carried a table.
Eighty-seven tables, and two of them carried a caption
The 87 tables that do exist were counted for the parts of table markup that make a grid machine-readable rather than merely rectangular, and the parts are not a matter of taste. The WHATWG HTML Living Standard, at html.spec.whatwg.org/multipage/tables.html, carries them in section 4.9 on tabular data, last updated 22 September 2026. It states plainly that "Tables must not be used as layout aids", defines the caption element as representing "the title of the table that is its parent", and makes scope an enumerated attribute that declares whether a header cell governs its row or its column.
46 of the 87 tables carried at least one th element and 41 carried none at all. On 10 of the 38 pages, not one table on the page had a header cell anywhere. That is the shape the W3C's own tables tutorial addresses first, since it states that header cells must be marked up with th and data cells with td, and that the point of doing so is that "headers and data cells can be programmatically determined by software". A grid of td elements renders identically and declares nothing about which values are labels.
Of the 216 th elements in the whole corpus, 100 carried a scope attribute, so 116 did not. MDN's table reference, last modified 24 April 2026, is careful about what that costs: scope "is redundant in simple contexts, because scope is inferred", and the reason to write it is that "some assistive technologies may fail to draw correct inferences". So 116 bare th elements is not 116 defects, and this post will not call them that. It is 116 places where a consumer has to infer rather than read, on a shape that is already rare.
The caption count is the one that does not admit a defence. Two of the 87 tables carry a caption element. One is on dollyglot.com, whose single table carries 7 th elements, all 7 with a scope attribute, and a caption: the best-formed table found in the corpus. The other is on metlife.com, and that table contains no cells at all, so the corpus holds one captioned table with data in it. Both pages were re-requested by hand the same day and both confirmed. 33 of the 87 tables carried a thead, 49 were grids of at least two rows with at least two cells in a row, and 34 were a single row, which is a shape that is usually layout rather than data even when nothing declares it so. Only 3 tables in the entire corpus said as much, carrying role="presentation" or role="none".
| Feature of the markup | Tables | Share of the 87 |
|---|---|---|
| At least two rows and two cells in a row | 49 | 56.3 percent |
| At least one th element | 46 | 52.9 percent |
| No th element anywhere | 41 | 47.1 percent |
| A thead element | 33 | 37.9 percent |
| A single row only | 34 | 39.1 percent |
| Declared presentational (role none) | 3 | 3.4 percent |
| A caption element | 2 | 2.3 percent |
The web enumerates in lists, not in tables
The August post on five pages noted that those pages held 1,127 list items and three tables, and suggested the sites were not short of enumerated content but expressed none of it as a grid. At 1,079 pages that reading holds, and the ratio is starker than the small sample implied. The corpus carries 109,439 list items across 21,101 unordered lists, 303 ordered lists and 216 definition lists, and 887 of the 1,079 pages carry at least one. That is 1,258 list items for every table element in the corpus, and 887 pages using one shape against 38 using the other.
A second comparison makes the point about effort rather than habit. 628 of the 1,079 pages carry at least one JSON-LD block, 1,181 blocks in total. Publishing structured data is the more demanding thing to do: it means choosing a vocabulary, writing markup nobody sees, and keeping it true as the page changes, which is why 298 of 1,277 FAQ answers turned out not to be on the page when this blog counted them. Adding a th element to a grid already on the page is close to free. Sixteen times as many pages do the expensive thing.
Where the tables are is a platform story rather than a sector one, which is the same pattern the image run found. The categories with any meaningful table presence are single page app startups at 7 of 44 pages, SaaS marketing at 3 of 37 and ecommerce at 5 of 66. Five whole strata carried no table at all across 203 pages between them: Webflow with 42 pages, Wix and Squarespace with 54, Bubble and no-code with 42, WordPress small business with 36 and local media with 29. A visual site builder has no table primitive a marketing user will reach for, and the output shows it. Teams that hand-write their markup, or use a component library that ships one, are the only ones producing grids, which argues for reading a stack guide rather than a generic checklist.
One site cuts the other way hard enough to name. trustmrr.com served 3 tables holding 510 cells, and 2,516 of its 3,546 visible words sat inside them, which is 71 percent of the readable page. It is the only page in the corpus where tables carry the substance, and it carries no caption on any of the three. At the other end, 3 pages carried tables holding no text whatsoever: nfz.gov.pl, cnbc.com and amazon.com. A table with no words in it is markup a crawler must walk through to find nothing, which is the same cost pattern as the iframes that held 50 words between 17 of them.
What to check on your own page, and what this run did not measure
The practical reading is narrow, because the honest conclusion of a supply-side count is a supply-side instruction. If your page presents values against criteria, pricing tiers, specifications, opening hours, fare classes, then a grid with th elements and a caption costs one afternoon and makes the relationship between label and value explicit in the bytes rather than implicit in the layout. If it does not, this post is not an argument for inventing tables, and a list is a perfectly good shape for a list. The failure mode worth avoiding is the one the spec names directly: a table used as a layout aid adds structure that means nothing and has to be walked anyway.
Lantad's own extractor makes a decision here that is worth knowing before you act on any of this, and it is a decision rather than a finding. In core/src/extract.ts, MAIN_BLOCK_TAGS holds h1 through h6, p and li, and it does not hold td or th. Table cells appear in BLOCK_BOUNDARY_TAGS, so they end a block without starting one that counts as main content. The consequence was measured in August and published: a two column table outside main or article yielded a word count of zero while the same facts as list items yielded five. That is this scanner's rule, not the web's, and a site whose data lives in tables outside its main element is scored accordingly. Anyone reading an AI visibility number from any vendor is reading that vendor's extraction decisions as much as their own page.
Four things this run did not measure, stated because the title asks a question the method cannot fully answer. No AI crawler fetched anything here: every request came from LantadBot, so nothing is claimed about what GPTBot, ClaudeBot or PerplexityBot do with a table element, and no vendor documents it. No JavaScript was executed, so a table injected after load was not seen and all 87 counts are floors, the same limit that applied when JavaScript supplied 7.6 percent of the prose on 271 pages. Only the home page was read on each host, and a home page is the least likely page on a site to carry a specification grid, so the 3.5 percent is a statement about home pages and not about whole sites: a pricing or docs page would very likely score higher, as the run on pricing pages suggests. And the corpus is an editorial sampling frame rather than a random draw, so every rate here supports a statement about these 1,419 hostnames and nothing wider, which is the standing caveat on the crawlability study.
What the run does establish is that the premise under the original code comment is thinner than it reads. A table may well be the shape an answer engine extracts most reliably. On the home pages of 1,079 real sites it is also the shape almost nobody sends, which means the reliability is mostly theoretical, and the answer engine is reconstructing relationships from lists and layout instead. If you want to see what your own file says before you change anything, the robots.txt tester and the guidance on getting cited by ChatGPT are the places this site sends people next.
- Header cells are th, not styled td 41 of the 87 tables in this corpus carried no th anywhere, which leaves nothing declaring which values are labels.
- A caption element names the table 2 of 87 carried one. The spec defines caption as the title of the table, and it is the cheapest context a grid can carry.
- scope says row or column 100 of 216 th elements carried it. MDN calls it redundant in simple tables and useful where inference fails.
- No table used for layout The standard states that tables must not be used as layout aids. 3 tables in the corpus declared themselves presentational.
- The grid is in the HTML, not built by script This run executed no JavaScript, so a table assembled client side is invisible to the same extent it is invisible to a crawler that does not render.
Lantad
Published .
Every comparison published on this site arrives as a grid because a code comment says it should. The file that defines the figures, site/src/lib/visual.ts, renders a table as semantic table markup rather than as an image "because a table is the shape an AI crawler extracts most reliably". That is a design decision rather than a measurement, and read the other way it is a claim about everybody else's pages. If the table is the most reliably extracted shape, the pages an answer engine reads should contain some.
Common questions
Do AI crawlers read HTML tables?
No vendor documents it, so this post makes no claim either way. What Lantad measured on 23 September 2026 is the supply side: of 1,079 home pages read as LantadBot, 38 carried a table element and the text inside all 87 of them came to 0.39 percent of the visible words on those pages. Whatever a crawler does with table markup, on these pages there is very little of it to do.
Should I convert my lists into tables so AI can read them better?
Only where the content is genuinely tabular, meaning values set against criteria. A list is the correct shape for a list, and the HTML standard's rule that tables must not be used as layout aids applies just as much to a table built to impress an extractor. The corpus carried 109,439 list items and 87 tables, and most of those list items are in the right shape already.
What makes a table machine-readable rather than just rectangular?
Three things the specification names: th elements marking header cells so software can tell labels from values, a scope attribute where the direction of a header is not obvious, and a caption element naming what the table is. In this corpus 46 of 87 tables had a th, 100 of 216 th elements had a scope, and 2 tables had a caption.
Why did only 1,079 of 1,419 sites count toward these figures?
11 hostnames disallow LantadBot at the site root and 36 answered robots.txt with HTTP 503, which the scanner treats as disallow-all, so 47 were never fetched. Of the rest, 33 returned no status and 260 answered with something other than HTTP 200 and HTML, 215 of those being a 403. Sites that refuse an unknown crawler are not missing at random, so every rate here describes the 1,079 that answered.
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.
Three table elements on five real pages, and all three were navigation
Lantad's own component library states that a table is the shape an AI crawler extracts most reliably, so the claim was checked against the pages this scanner has actually stored. Counted with an HTML parser on 21 August 2026 over five real pages captured on 15 July 2026, the whole set holds three table elements, all three on one page, all three navigation boxes, and none of the five pages carries a single caption element.
Structured data for AI (schema markup)
Structured data is schema.org markup, usually written as JSON-LD, that labels a page's facts in a machine-readable format so AI systems can extract and attribute them without having to interpret the surrounding prose.
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.
Do AI crawlers read images? 52,077 on 1,006 home pages, and 18,171 carried an empty alt
Lantad asked all 1,419 hostnames in this repository's committed corpus for robots.txt on 23 September 2026 and read each home page with no JavaScript executed. 1,076 answered HTTP 200 with HTML and carried 52,077 image elements between them. 18,171 of those declared an empty alt, 1,935 carried no alt attribute at all, and on 73 pages not one image on the page described itself.
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.
Answer Engine Optimization (AEO)
Answer Engine Optimization (AEO) is the practice of making a page readable, allowed, and structured enough that AI answer engines can use it as a source when they compose an answer.
