Do AI crawlers read video captions? 3 of 1,078 home pages served a caption file that opened

Do AI crawlers read video captions?

Nothing in this measurement says whether any crawler reads them, and that needs saying first because the question is usually asked as though a vendor had answered it. No vendor documentation read for this post claims that audio is transcribed or that caption files are collected during a crawl, and we observed no request from any AI crawler. What can be established is narrower and more useful: whether the text exists in a place a crawler could read it, because a crawler that wanted the words could only get them from a file the page names.

The mechanism is specified and it is small. The track element, in Mozilla's reference for it, "is used as a child of the media elements", audio and video, and it carries a kind attribute whose permitted values are subtitles, captions, descriptions, chapters and metadata. If kind is omitted the default is subtitles. The data it points at is WebVTT, a plain text format of timestamped cues in a .vtt file, which is the part that matters here: a WebVTT file is text over HTTP, so anything that can fetch a page can fetch the captions beside it. That is a sharp contrast with the media itself, and it is why this is worth counting rather than assuming.

The second route is markup rather than a file. Schema.org's VideoObject type defines a transcript property, documented as "If this MediaObject is an AudioObject or VideoObject, the transcript of that object", and a caption property documented as "The caption for this object". Those put the words in the page as structured data instead of in a separate file. Neither is listed as required.

There is a third route, which is simply writing the words on the page as prose, and it is the one this measurement cannot see. A paragraph summarising what a speaker said is indistinguishable from any other paragraph, which is a limit rather than a gap: it means every count below is a count of declared, machine-identifiable caption text, and a site doing the right thing in ordinary prose scores zero here while serving its readers perfectly well. The same boundary applied when we found that 80 of 37,019 inline graphics carried any SVG text: what is countable is what is labelled.

How many home pages put a video in front of the crawler?

246 of the 1,078. Of those, 201 carried a native element and no recognised embed, 32 carried an embed and no native element, and 13 carried both. The native side is much the larger: 917 video elements across 210 pages, and 18 audio elements across 9 pages. The embed side is 96 players, being 88 YouTube frames on 38 pages, 6 Vimeo frames on 5 pages and 2 Loom frames on 2 pages, counted by matching iframe sources against a list of eleven known player providers that also includes Wistia, Brightcove, Vidyard, Dailymotion, JW Player, Spotify, SoundCloud and Libsyn, none of which appeared.

The split matters because the two cases have different ceilings. A native video element can carry a track element as a child, so the caption file can live on the same site and be served by the same server. A third-party frame cannot: whatever captions YouTube holds for a video are inside YouTube, reachable through YouTube, and nothing in the delivered bytes of the embedding page points a crawler at them. For those 96 embeds the only in-page route left is the schema one, and the broader problem is familiar from the frames themselves, since a crawler reading an embedded document gets whatever that document holds, which in the web components case was 3,291 of 7,124 custom elements arriving with no text.

Google's own documentation is worth reading on this point because of what it does not say. Its page on video in Search states that "Google can find videos referenced by a video, embed, iframe, or object element" and that "We support structured data, video sitemaps, and the Open Graph protocol (OGP)". That is a complete account of discovery and metadata, and the page does not mention transcripts, captions or subtitles anywhere. A site owner following it learns how to get a video found and nothing about making its content legible as text. We are describing one page rather than Google's whole position, and the absence on that page is the point: the advice a reader is most likely to find is silent on the only mechanism that puts the speech in reach.

Distribution across the corpus strata is uneven in a way that fits the material. The SaaS stratum led on 38 of 118 pages carrying a player and education on 33 of 106, while the two strata built on hosted site builders were close to empty, with 4 of 54 in the Wix and Squarespace stratum and 5 of 42 in the no-code stratum. The densest was the SaaS marketing platform stratum at 19 of 38, which is exactly half. If you want to see what a crawler gets from one of your own pages rather than from this corpus, our crawler view tool shows the delivered bytes.

Most of that video has no speech to transcribe

This is the part that stops the headline being a scandal, and it came out of checking the attributes rather than the counts. Of the 917 video elements, 768 carried the muted attribute, 700 carried loop and 318 carried autoplay. 640 carried muted and loop together with no controls attribute at all. That combination is the decorative background pattern: a short clip that starts itself, repeats forever, has no sound and offers the reader no way to play or pause it. One site in the corpus carried 49 such elements on its home page and another carried 39.

Mozilla's reference for the video element defines controls as meaning "the browser will offer controls to allow the user to control video playback, including volume, seeking, and pause/resume playback", and muted as "the default audio mute setting contained in the video". It also notes that "Modern browsers block audio (or videos with an unmuted audio track) from autoplaying", which is why the pattern looks the way it does: a muted loop is what a designer has to write to get moving imagery behind a headline. There is no speech in it. Asking it for a transcript is asking the wrong question, and a measurement that counted those 640 as caption failures would be manufacturing a problem.

So the honest denominator is much smaller. 51 of the 917 video elements, spread across 33 pages, carried the controls attribute, which is the one mechanical signal in the markup that a reader is expected to press play and listen. Of those 51, three carried a caption or subtitle track and 48 did not. The three are on homarr.dev, loc.gov and italia.it. That is the finding stated at its narrowest and it is the version worth acting on: where the markup itself says a video is meant to be heard, a caption track is declared about six percent of the time.

The 18 audio elements deserve one line of their own, because they are the cleanest case in the whole run. Audio has no visual layer, so there is nothing decorative about it and nothing to see instead of listening. None of the 18 carried a controls attribute and none carried a track element of any kind. Whatever those nine pages are playing, the delivered bytes say nothing about what is in it, which puts it in the same position as the text we have found hidden by other means, such as the 121,312 of 1,269,054 words sitting behind a marker on 1,115 home pages. An absent transcript is not deception, but the effect on prose parity is the same: content a person gets and a crawler does not.

The 40 caption tracks, and the 29 that named no file

79 track elements appeared across 13 home pages. 40 of them, on 10 pages, declared a kind of captions or subtitles. The other 39 declared one of the remaining permitted kinds and sat on three pages, 36 of them on a single news site, and those are not caption claims so they are set aside here.

Checking whether each of the 40 actually named a file was an afterthought, and it turned out to be the measurement. 29 of the 40 carried no src attribute at all. On five pages the caption track is written as a bare element declaring a kind and nothing else: ten such elements on ikea.com, nine on affirm.com, seven on quartr.com, two on atlassian.com and one on italia.it. An element of that shape names no URL, so there is no file for a browser to fetch and none for a crawler to find. It satisfies a checklist and delivers no text. These are presumably placeholders waiting for a player script to fill them in, and on a page where a script does that at runtime the captions exist for a reader and still not in the delivered bytes, which is the same gap we measured when 27 of 404 home pages with no structured data in the HTML gained some once a browser ran the page.

That leaves 11 tracks, on five pages, carrying a src. They resolve to 10 distinct URLs, because one Stanford file is referenced twice. We fetched all ten as LantadBot on the same date. Four answered HTTP 200 with a body beginning WEBVTT. Six answered HTTP 404: four on mentraglass.com and two on maroc.ma. A caption track pointing at a 404 is worth exactly as much to a crawler as one pointing at nothing, and slightly worse to a reader, because the player will offer a captions button that produces no captions.

So the count that survives every check is three. Three of 1,078 home pages served a caption file that opened: homarr.dev, loc.gov and stanford.edu. On the markup side the picture is the same shape and has not moved: 42 VideoObject nodes on 21 pages, of which 2 carried a transcript property and none carried a caption property. The two are dynatrace.com and hsbc.com, which are the same two hosts that carried the only 2 transcripts among 43 nodes when this corpus was read on 23 September 2026. Twenty days and two readings apart, the same two sites are doing it and nobody else has started. Counting pages with any declared caption or transcript text by either route gives 11 of the 246 that carried a player, and one of those, dynatrace.com, declares a transcript while serving no player in its HTML at all. Where this leaves the broader markup question is covered in the structured data glossary entry.

What the four working caption files actually say

Opening them changes the answer again, and in both directions. The four files hold 124 cues and 976 words of caption text between them, and they are not four of the same thing.

loc.gov is the substantial one. Its file is 7,438 bytes, 99 cues and 856 of those 976 words, and it is a real transcript of a Library of Congress webcast: it opens with a music cue in square brackets, then names a speaker and carries that speech across the rest of the file. One home page in the corpus serves an AI crawler the better part of a thousand words of speech it would otherwise have no access to. Stanford serves two files, one of them hosted on a third-party content domain, and that one is also genuine speech at 1,443 bytes and 18 cues, opening on a sentence about generating millions of microscope images.

The other two are honest and almost empty. The homarr.dev file is 519 bytes and 6 cues, and what it contains is a description of what appears on screen rather than anything anybody says, beginning with an instrumental music cue and then narrating logos appearing and dashboard tiles being dragged. That is a correct use of the mechanism for a silent reel and it is good practice, and it is also not a transcript, because there is no speech to transcribe. The second Stanford file is 127 bytes and one cue, and the cue reads, in square brackets: No sound. A caption file whose entire content is a note that the video is silent is the most precise thing in this dataset.

Counting only files that hold transcribed speech, the answer to the headline question is two. Two home pages of 1,078 served an AI crawler the words spoken in their video. That number is small enough to be worth stating twice, and it should be read alongside the 640 decorative loops, because the two findings together say something more specific than a failure rate: home page video is overwhelmingly not a speech medium, and in the small set of cases where it is, the text almost never exists in a form a machine can collect.

The practical reading for a site owner is a short one. If your home page video is a muted background loop, there is nothing to fix and a caption file would be a fabrication. If somebody talks in it, the words are content you have already produced and are currently serving to nobody who cannot hear, and the mechanisms for fixing that are a .vtt file named in a src attribute, a transcript property, or a paragraph of prose, in descending order of machine legibility and ascending order of how easy they are to get right. A paragraph of prose will be read by everything, which is the same conclusion the table measurement reached when 87 tables on 1,079 home pages turned out to carry almost nothing a crawler would extract, and it is why the semantic HTML finding that 379 of 1,066 home pages declared no main landmark matters more than any single markup type. If the goal is specifically to be quoted in an answer, the AI Overviews guide sets out what gets lifted.

What this measurement does not say

It does not say that any AI crawler reads a caption file. We sent no request as GPTBot, ClaudeBot or PerplexityBot and observed no request from any of them. No vendor documentation read for this post claims that captions are collected, and none claims they are ignored. Everything above establishes whether the text is reachable, which is a precondition for being read and not evidence of it. Our methodology page states what a scan measures and what it refuses to conclude.

It does not see prose. A page that puts a speaker's words in a paragraph beside the player is doing the most robust possible thing and counts as zero in every figure here. The 13 pages where the visible text contained the word transcript are a weak upper bound on that and nothing more, because the word appears in product names and navigation as readily as in a link to an actual transcript. Treat the three and the two as counts of declared, machine-identifiable caption text, not as a count of sites that have failed their readers.

It does not run JavaScript. The requests were plain fetches and nothing executed, so a player that injects a track element, or captions, after load is invisible to this reading. That is the right view for the question being asked, because it is the view a non-rendering crawler gets, and we have measured that the gap is real but usually small: two of nine AI crawlers rendered JavaScript in an earlier reading. It does mean the 29 tracks with no src are better described as naming no file in the delivered bytes than as being permanently empty.

It is one URL per hostname and that URL is the home page. These are 1,419 front doors rather than 1,419 sites, no link was followed, and a site whose video library sits three clicks deep contributes whatever happens to be on its front page and nothing else. For a question about video this is a harder limit than usual, since a home page is where decorative video lives and a watch page is where speech lives. Nor is the population a sample of the web: it is two committed sampling frames, so no proportion here generalises beyond them, and 341 hostnames never delivered a page at all, which is its own finding given that 79 of 115 hostnames have refused a crawler their own robots.txt permits. What the figures do support is a reading of AI visibility on one date for one page each, which is what the research page collects and what our crawler identifies itself as while collecting it.