Video schema: 21 of the 270 home pages showing a video declared one

What is video schema, and what does it tell an AI crawler?

Two documents define it and they want different things from you.

schema.org, at release 30.1 dated 2026-09-16, defines VideoObject as a media object with eight properties of its own, and one of them is the whole subject of this post. The vocabulary defines transcript as "If this MediaObject is an AudioObject or VideoObject, the transcript of that object", typed as plain Text. There is also a caption property, an embeddedTextCaption property, and the inherited machinery for naming a duration, an upload date, a thumbnail and the address of the file. The vocabulary, in other words, already has a field whose entire purpose is to put the words spoken in a video into the page as text.

Google's video structured data documentation, carrying Last updated 2026-09-08 UTC, asks for three properties and none of them is that one. It requires name, "The title of the video"; thumbnailUrl, "A URL pointing to the video's unique thumbnail image file"; and uploadDate, "The date and time the video was first published, in ISO 8601 format". Its recommended list runs to contentUrl, description, duration, embedUrl, expires, hasPart, ineligibleRegion, interactionStatistic, publication and regionsAllowed. The string transcript appears zero times in the page as served on 23 September 2026. The same is true of Google's video SEO best practices page, dated 2025-12-18 UTC, which states that Google can find videos referenced by a video, embed, iframe or object element, and never mentions a transcript either.

That gap matters here more than it does for search. A thumbnail and an upload date are enough to build a video result in a list of blue links, because a person clicks through and watches. An answer engine has nothing to click through with. The only part of a video that can survive into a generated answer is text somebody wrote down, which makes transcript the one property on this type that does the job this site measures, and the only one nobody is asked for. It is the same shape of finding as the FAQ measurement published earlier today, where 298 of 1,277 answers were not in the page the crawler was served: the markup exists, the vocabulary supports the honest version of it, and the published requirements stop short of asking for the part a machine can use.

How many home pages showed a crawler a video

270 of the 1,084 home pages read carried at least one of four signals: an HTML video element, an iframe pointing at a recognised video host, an og:video meta property, or a VideoObject node. That is 24.9 percent, so a quarter of these home pages show a crawler a video. The markup that would describe one is a different story, and it sits inside the same body of structured data this corpus has been measured for repeatedly, most recently in finding that 103 of 385 pages with JSON-LD named no organization.

The mechanisms are not evenly used. 216 sites served 1,178 video elements between them, which is the great majority of the video on these pages. What is in those files was not measured and cannot be from the markup: 1,110 of the 1,178 sit on a page carrying no caption track at all, so the element is usually the only thing declaring that a video is there. 54 sites served 134 player iframes. The addresses inside those iframes named YouTube 101 times, Vimeo 16, Wistia 16, Loom twice and Brightcove once, which sums to 136 rather than 134 because two elements named the same player in both a src and a lazy loading data-src attribute. Four pages declared an og:video property and not one declared a twitter:player.

One number here should be read carefully rather than quoted. 351 of the 1,178 video elements carried a src attribute of their own. The rest either name their file in a child source element or are filled in by a script after the page loads, and this scan did not separate those two cases, because a source element is also how a responsive image is written and counting them together would have produced a figure that means nothing. What can be said is narrower and still useful: on 148 of the 216 sites carrying a video element, not one of those elements named a file directly in the markup. That is the same class of dependency this blog measured when it found that JavaScript supplied 7.6 percent of the prose and all of it on 11 of 271 pages, and it is worth knowing about before you assume a crawler saw what you see.

The scanner's own user agent was used throughout and robots.txt was read first on every host, which is why 10 hostnames were left alone entirely. The 293 that answered with something other than HTML are a real limit on this sample rather than a footnote: 209 of them, 71 percent, returned 403, which is bot defence rather than a broken site, and this is the same population that produced the finding that 79 of 115 sites refused a crawler their robots.txt allows.

The 21 sites that declared it, and what their 43 nodes carried

21 sites carried video schema, 43 nodes between them. The distribution of quality inside those 43 is the surprise, and it runs the opposite way to most structured data findings on this site.

Every one of the 43 carried name, thumbnailUrl and uploadDate. All three required properties, on all 43 nodes, with no exceptions. 32 carried a description, with a median length of 153 characters. 30 declared a duration, 26 gave a contentUrl and 26 gave an embedUrl. Compare that against the defect rates this corpus normally produces, where 117 of 612 home pages with JSON-LD carried a defect, or against the product markup measured yesterday where 22 of 42 nodes carried no manufacturer identifier. Video markup in this corpus is not written badly. It is simply not written. The people who do it are following the documentation closely, and there are 21 of them.

Where it appears is as lopsided as how often. Nine of the 21 are SaaS companies, out of 48 SaaS sites that showed a video at all. Three are finance, one is government, one is news and one is travel. Not one of the 33 education sites showing a video declared the markup, and not one of the 17 healthcare sites did either, which are the two categories most likely to be publishing a lecture or a patient explainer, the two kinds of video whose content is almost entirely speech. Among the platform strata the count is near zero throughout: no Webflow site, no Framer site and no Shopify storefront in this corpus declared it.

The detail that changes what the markup is for came out of crossing the two measurements. Of the 21 sites declaring a VideoObject, 14 served no video element and no recognised player iframe anywhere in the HTML the crawler received. unesco.org, foxnews.com, docker.com, twilio.com, dynatrace.com and nine others describe a video in their JSON-LD and then build the player in the browser. For those 14 the schema is not a description of something the crawler can also see. It is the only evidence in the delivered bytes that a video exists on the page at all, which makes it more load bearing than its authors probably intended.

What text a crawler actually got from the video

This is the part the whole run was built to answer, and the answer is short.

Two of the 43 nodes carried a transcript. dynatrace.com carried 918 characters of one on a node named "Understand your business like never before with Dynatrace", and hsbc.com carried 4,985 characters on a node named "HSBC Culture of Innovation". Not one node carried a caption property. Across 1,084 home pages, 270 of them showing video, the total quantity of spoken video content written into machine readable text was two nodes and roughly 5,900 characters, and 4,985 of those characters belong to one bank.

The obvious objection is that captions are the proper mechanism and schema is not. The objection is right about the mechanism and wrong about the outcome. 14 sites served 53 track elements of kind captions, subtitles or descriptions. The track element, on a page last modified 24 April 2026, lets an author "specify a timed text track (or time-based data) that can be displayed in parallel with the media element", and those tracks are WebVTT files living at their own URLs. So the caption text is not in the home page either. A crawler that reads the HTML and stops there sees a filename. Thirteen of those 14 track-carrying sites are inside the 270, and the fourteenth carries a track with no video element or player iframe in its markup at all. Between the two mechanisms, 15 of the 270 sites with video wrote the words down anywhere a machine could reach them, and only two put them in the page itself.

What is left is titles. 102 of the 134 player iframes carried a title attribute and 32 did not, which means roughly a quarter of the embedded players on these pages are anonymous even to a screen reader. The 32 descriptions on VideoObject nodes have a median length of 153 characters, roughly a sentence and a half. The word transcript appears in the visible text of 11 of the 1,084 home pages and 5 of the 270 with video, so a link to a transcript elsewhere on the site is about as rare as the markup. Set against the prose parity question this scanner exists to answer, video is the cleanest example in the corpus of content that is present for a person and absent for a machine, and it does not show up in a syntax check the way 22 of 385 pages carrying microdata did, because there is no defect to find. There is nothing there to be wrong.

The pages with video were not the text-poor ones

The tidy version of this story would be that sites put their message in a video instead of writing it, and the crawler gets a blank page. That is not what the corpus shows, and the measurement is worth publishing precisely because it cuts against the pitch.

The 270 home pages carrying video held a median 1,254 visible words. The 814 without held a median 892. Pages with video carried about 40 percent more readable prose than pages without, and only 9 of the 270 fell below 200 words, against the 17 near-empty home pages counted when this blog measured that 17 of 380 home pages sent a crawler zero words. Video on these sites is decoration and demonstration layered over a page that already says what it does. The loss is not that the page is empty. The loss is the specific content that only exists as speech, and nothing in this measurement tells you how much of that there is, because measuring it would mean watching 1,178 videos.

What the crawler vendors say about any of this is close to nothing, and that absence is checkable. Anthropic's crawler documentation, dated 7 April 2026, names ClaudeBot, Claude-User and Claude-SearchBot and contains the strings video and transcript zero times each in the bytes it serves. OpenAI's crawler page names GPTBot, OAI-SearchBot, OAI-AdsBot and ChatGPT-User, and the four occurrences of video and three of transcript in its served bytes are all navigation links to unrelated API guides rather than statements about the crawlers. Neither vendor documents a media pipeline, a transcription step or a file type list, which is consistent with the position this site has taken since it started publishing the registry of crawler tokens it evaluates: what an engine does after the fetch is not observable from the page, so this post claims nothing about it. What is observable is what left the server, and for 268 of the 270 pages, what left the server said nothing about what the video says.

What to check on your own site

Five checks, in the order they cost you the least, and every one of them runs against the HTML your server sends rather than the page your browser assembles. Fetch the page with curl or with what GPTBot sees and read the response, because on 148 of the 216 sites here the video element in the markup named no file at all.

First, find out whether your video is in the response. If the player is built by a script, a crawler gets no signal that a video exists unless you also declared it, which is the position 14 of the 21 markup-carrying sites in this corpus are in without necessarily knowing it. Second, if you write a VideoObject, write name, thumbnailUrl and uploadDate, because those are the three Google requires and every one of the 43 nodes found here managed it. Third, write a description longer than the 153 character median, since that is the sentence an answer engine has to work with if it has anything at all.

Fourth, and this is the one almost nobody does, put the transcript in the markup. The property exists, it is typed as text, and two sites in 1,419 used it. If your video carries an argument, a demonstration or a spoken explanation that is not written anywhere else on the page, then that argument currently reaches no machine. Publishing the transcript as visible prose beside the player is better still, because it needs no vocabulary and no parser, and it is the version that survives whatever any given engine decides to support. Fifth, give every player iframe a title attribute, which 32 of the 134 here do not have.

None of this is an AI visibility score and none of it is a ranking claim. It is the difference between a page that mentions a video and a page that says what is in it, measured on one day across one corpus, using the same method as the rest of this repository's crawlability research. The corpus is an editorial frame rather than a random sample of the web, one page per site, one network location and one moment, so read the ratios and not the decimal places.