VideoObject Schema

TL;DR — VideoObject schemaVideoObject schema (schema.org/VideoObject) marks up video content for Google's video rich results — thumbnail, duration, and key moments — surfacing on main search, the Video tab, Google Images, and Google Discover. It also covers the related Clip (key moments) and BroadcastEvent (LIVE badge) types on the same guide. is code you add to a page with a video that labels the video’s details for search engines — “this is the title,” “this is the thumbnail,” “this is how long it is,” “it was uploaded on this date.” Adding it correctly makes the video eligible for the richer listings you see on Google: a thumbnail and duration in the main results, in the Video tab, in Images, and in Discover. It does not guarantee those extras show up, and Google still has to be able to find and indexStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. the video itself.

What VideoObject schema is

When you look at a page with a video on it, you can tell the title from the runtime from the thumbnail just by looking. A search engine sees a page of HTML and a video player and has to work out which video is the main one and what it’s about. VideoObject schema spells it out in code, using the shared schema.org vocabulary — it tags the video’s name (title), its thumbnailUrl, the uploadDate, and usually a description, duration, and the URLs where the video file and its embed live.

It’s almost always written as JSON-LDJSON-LD (JavaScript Object Notation for Linked Data) is a script-based structured data format, typically paired with the schema.org vocabulary to describe page content for search engines and AI systems. Google recommends it over Microdata and RDFa because it's the easiest format to implement and maintain at scale — but all three work, and structured data isn't a ranking signal. — a small block of code that sits in the page without changing how the page looks.

Why it’s worth doing

The payoff is video rich resultsRich results (formerly 'rich snippets') are enhanced search listings — stars, images, prices, breadcrumbs, video thumbnails, and more — that Google and Bing build from structured data. They're a display feature, not a ranking factor, and eligibility never guarantees they'll show., and the surprising part is how many places they show up. Google’s own docs say videos can appear on the main search results page, in Video mode, in Google Images, and in Google DiscoverGoogle Discover is a personalized, mobile-first content feed built into the Google app, Chrome's mobile New Tab page, and google.com that surfaces articles and videos based on a user's interests and activity — not a response to a search query. There's nothing to 'rank' for in the traditional sense; eligibility is governed by Discover's content policies plus the same helpful-content, image, and page-experience signals Google Search already uses.. Most people assume video schema only helps in the “videos” section — it’s actually four surfaces. A thumbnail and a runtime next to your result stand out and can earn more clicks than a plain blue link.

The three things you always need

To be eligible for any video rich result, Google requires just three properties:

• name — the video’s title.
• thumbnailUrl — a URL to a representative thumbnail image.
• uploadDate — the date the video was first published.

Everything else — the description, the duration (so Google can show “4:12”), the contentUrl and embedUrl — is recommended, not required, but adding them makes for a much richer, more reliable result.

Two features you’ll hear about

• Key moments are the little chapter links (“Intro,” “Ingredients,” “Assembly”) that let searchers jump into the middle of a video. You can add these — there are two different ways, covered in the Advanced tab.
• The LIVE badge — that red “LIVE” label on livestreams — is added with a related bit of markup called BroadcastEvent. Also in Advanced.

The thing most people get wrong

The single most common miss is leaving out uploadDate, or writing it in a sloppy date format. It’s one of only three required fields, so skipping it means no rich result at all. And remember: even perfect markup only makes the video eligible — Google still decides whether to show it, and it has to be able to crawl and index the actual video.

Want the full version — the recommended properties, the two ways to do key moments, the LIVE badge, and the common mistakes? Switch to the Advanced tab.

TL;DR — schema.org/VideoObject markup (usually JSON-LDJSON-LD (JavaScript Object Notation for Linked Data) is a script-based structured data format, typically paired with the schema.org vocabulary to describe page content for search engines and AI systems. Google recommends it over Microdata and RDFa because it's the easiest format to implement and maintain at scale — but all three work, and structured data isn't a ranking signal.) makes a video eligible for video rich resultsRich results (formerly 'rich snippets') are enhanced search listings — stars, images, prices, breadcrumbs, video thumbnails, and more — that Google and Bing build from structured data. They're a display feature, not a ranking factor, and eligibility never guarantees they'll show. across four Google surfaces — main search, the Video tab, Google Images, and Google DiscoverGoogle Discover is a personalized, mobile-first content feed built into the Google app, Chrome's mobile New Tab page, and google.com that surfaces articles and videos based on a user's interests and activity — not a response to a search query. There's nothing to 'rank' for in the traditional sense; eligibility is governed by Discover's content policies plus the same helpful-content, image, and page-experience signals Google Search already uses.. Required: name, thumbnailUrl, uploadDate. Recommended: contentUrl, description, duration, embedUrl, expires, interactionStatistic, and regionsAllowed/ineligibleRegion. Key moments have two mechanisms — automatic via SeekToAction/potentialAction (if your URLs accept a timestamp parameter Google can infer) or manual via Clip (name, startOffset, and url required per chapter; endOffset recommended). The LIVE badge is BroadcastEvent (isLiveBroadcast, startDate, endDate) used alongside VideoObject, documented on the same page — not a separate system. The most common miss is omitting uploadDate or using an inconsistent date format. Valid markup only earns eligibility; Google still decides whether to show it, and the video has to be crawlable and indexable. This is one of the two highest-payoff types in the cluster alongside Recipe — worth doing properly.

What VideoObject schema does — one markup, four surfaces

Most guides flatten VideoObject into “get a thumbnail in search.” The reach is wider than that, and it’s worth leading with because it changes the ROI calculation. Google’s own framing: “Videos can appear in several different places on Google, including the main search results page, Video mode, Google Images, and Google Discover.” That’s four distinct surfaces from one block of markup — which is why I rank this, with Recipe, as one of the two genuinely high-payoff types in the whole structured-data cluster. (It’s no coincidence the two overlap: many Recipe pages embed a cooking video via the recipe’s video property, and that video is itself a VideoObject.)

The vocabulary is schema.org/VideoObject, and Google’s Video guide covers three related types on a single page: VideoObject itself, Clip (key moments), and BroadcastEvent (the LIVE badge). Worth knowing: there is no separate “media-clip” doc page — the URL you might guess at returns a 404. Clip and segment markup for video is folded into the same Video guide as VideoObject, so don’t go hunting for a dedicated page that doesn’t exist.

Required vs. recommended properties

Required — the minimum for any video rich result:

Recommended — add as many as apply; they make the result richer and more reliable:

Provide either contentUrl or embedUrl (both is better) so Google has a way to reach the actual video — a thumbnail with no reachable video is a common reason a result never appears. The three URLs that come up here are not interchangeable: contentUrl is the video file’s actual content bytes (Google’s own docs call it the most effective way for Google to fetch the video); embedUrl is the player, not the file; and neither one is the watch page URL — the page the video is embedded on. A common mistake is pointing contentUrl at the watch page instead of the raw media file.

TIP Check whether the VideoObject exists in the HTML at all

This result is deliberately narrow: no VideoObject JSON-LD was found in the raw response. It does not validate every property or prove what Google rendered.

Run the watch page through my Video SEO Checker to separate missing markup from thumbnail, key-moment, and embed-loading problems. Video SEO Checker Free

1. Confirm a VideoObject block is present in the raw HTML rather than only after client-side rendering.
2. Check thumbnailUrl and either contentUrl or embedUrl independently from the schema-presence result.
3. Validate the complete rendered object in Google’s Rich Results Test before release.

Tap to enlarge

Key moments: SeekToAction vs. Clip

Key moments are the chapter-style deep links under a video result that jump the viewer to a specific timestamp. There are two mechanisms, and confusing them is the single biggest source of implementation trouble on this type.

1. Automatic — SeekToAction / potentialAction. You tell Google, via a potentialAction of type SeekToAction, the URL pattern your player uses to jump to a timestamp (the startOffset-input placeholder). If your video URLs already accept a timestamp parameter, Google can infer the key moments itself from your on-page chapter structure. Use this when your URL structureURL structure is how the parts of a web address — scheme, domain, path, query string, and fragment — are organized and formatted. It mostly affects crawling, usability, and how engines understand a page, not rankings directly. supports timestamps and you’re happy letting Google pick the moments.

{
  "@context": "https://schema.org",
  "@type": "VideoObject",
  "name": "How to tie a bowline knot",
  "thumbnailUrl": "https://example.com/thumbs/bowline.jpg",
  "uploadDate": "2026-05-01T08:00:00-05:00",
  "description": "A step-by-step guide to tying a bowline.",
  "duration": "PT4M12S",
  "contentUrl": "https://example.com/video/bowline.mp4",
  "embedUrl": "https://example.com/embed/bowline",
  "potentialAction": {
    "@type": "SeekToAction",
    "target": "https://example.com/watch/bowline?t={seek_to_second_number}",
    "startOffset-input": "required name=seek_to_second_number"
  }
}

2. Manual — Clip markup. You define each chapter explicitly as a Clip. Google’s Clip table splits this the same way as VideoObject itself: required — name, startOffset (in seconds), and a url that deep-links to that moment; recommended — endOffset (in seconds), so the clip has a defined end as well as a start. Use this when you want to supply your own labels and timestamps rather than the moments Google’s automatic detection would otherwise pick.

{
  "@context": "https://schema.org",
  "@type": "VideoObject",
  "name": "How to tie a bowline knot",
  "thumbnailUrl": "https://example.com/thumbs/bowline.jpg",
  "uploadDate": "2026-05-01T08:00:00-05:00",
  "hasPart": [
    {
      "@type": "Clip",
      "name": "Make the loop",
      "startOffset": 30,
      "endOffset": 75,
      "url": "https://example.com/watch/bowline?t=30"
    },
    {
      "@type": "Clip",
      "name": "Thread the tail",
      "startOffset": 75,
      "endOffset": 130,
      "url": "https://example.com/watch/bowline?t=75"
    }
  ]
}

Which to use? Automatic SeekToAction is less work if your URLs already support timestamp parameters and you trust Google to pick the moments. Manual Clip is the right call when you want to name and bound each chapter yourself. Don’t stack both mechanisms for the same purpose on the same video — pick one. The decision tree in the Resources group walks this fork.

LIVE badges with BroadcastEvent

For livestreams, the red LIVE badge is enabled by adding a BroadcastEvent to your VideoObject via the publication property. It is not a separate, unrelated schema type — it’s documented on the same Video guide and layered onto the VideoObject you already have. BroadcastEvent as a whole isn’t required for a plain video rich result, but once you add it for the LIVE badge, Google’s Clip-style table treats isLiveBroadcast, startDate, and endDate as required together:

• isLiveBroadcast: true
• startDate — when the broadcast starts or is scheduled to start. A startDate in the future signals a scheduled broadcast; in the past or present, it signals the stream has actually started.
• endDate — when it ends or is expected to end. Google is explicit that once the stream has actually finished, you must update endDate to a real value — an endDate in the future signals a scheduled end, in the past or present it signals the stream has ended. If you don’t know the end time up front, an approximate endDate is fine to start; just correct it once the stream actually wraps.

Nesting startDate/endDate this way lets Google infer three lifecycle states — scheduled, live, ended — from the same two fields, which is also why a stale endDate (not corrected after the stream stops) is the main way a lingering LIVE badge happens. None of this guarantees the badge appears at any particular time; it only supplies the timing Google’s systems use to decide.

{
  "@context": "https://schema.org",
  "@type": "VideoObject",
  "name": "Launch livestream 2026",
  "thumbnailUrl": "https://example.com/thumbs/launch.jpg",
  "uploadDate": "2026-06-30T09:00:00-05:00",
  "publication": {
    "@type": "BroadcastEvent",
    "isLiveBroadcast": true,
    "startDate": "2026-07-01T14:00:00-05:00",
    "endDate": "2026-07-01T15:30:00-05:00"
  }
}

You also need to call Google’s Indexing APIThe Google Indexing API lets site owners notify Google directly when a URL is added, updated, or removed. Google officially supports it only for pages with JobPosting or BroadcastEvent (livestream) structured data — not for general content. for livestream videos so the LIVE badge appears and disappears in a timely way — the badge is time-sensitive in a way a normal on-demand video isn’t.

Common implementation mistakes

• Omitting uploadDate or using a sloppy date format. It’s one of only three required fields. Use a consistent ISO 8601 value (a full date-time with offset is safest). This is the single most common miss on the type.
• A thumbnail with no reachable video. Provide contentUrl and/or embedUrl so Google can actually fetch the video the thumbnail represents.
• Marking up a video that Google can’t crawl or indexStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed.. Structured dataStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding. can’t rescue a video hidden behind a login, blocked in robots.txtA plain-text file at the root of a host that tells crawlers which URLs they may and may not request. It controls crawling, not indexing — a blocked URL can still be indexed if it's linked from elsewhere., or loaded in a way the crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. can’t see. Markup describes the video; it doesn’t make it accessible.
• Stacking both key-moment mechanisms. Pick automatic SeekToAction or manual Clip for a given video, not both.
• Forgetting to close out a livestream. Set endDate and update the markup once the stream ends, or the LIVE badge can linger.
• Treating valid markup as a guaranteed result. As with every rich-result type, valid VideoObject markup only makes the page eligible — Google’s systems still decide whether to show it.

Where this sits, and video SEO more broadly

VideoObject is the structured-data layer for video, and it lives here alongside its siblings — Recipe (whose pages so often embed a cooking video) and Article (where a video is embedded inside a written piece, and the VideoObject describes that embed). But the markup is only one slice of getting video to perform in search: hosting, sitemapsA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing., thumbnails, transcripts, page speed around the player, and how you embed all matter too. Those broader video SEO topics sit outside this structured-data article — this page is deliberately scoped to the schema itself.

For where VideoObject fits in the wider structured-data picture, see the Schema Markup and Structured Data hubs this article nests under.

AI summary

A condensed take on the Advanced version:

• What it is: schema.org/VideoObject markup (usually JSON-LDJSON-LD (JavaScript Object Notation for Linked Data) is a script-based structured data format, typically paired with the schema.org vocabulary to describe page content for search engines and AI systems. Google recommends it over Microdata and RDFa because it's the easiest format to implement and maintain at scale — but all three work, and structured data isn't a ranking signal.) that labels a page’s video — title, thumbnail, upload date, duration, and the video/embed URLs — so search engines can produce video rich resultsRich results (formerly 'rich snippets') are enhanced search listings — stars, images, prices, breadcrumbs, video thumbnails, and more — that Google and Bing build from structured data. They're a display feature, not a ranking factor, and eligibility never guarantees they'll show..
• Four surfaces, not one: the same markup can surface on the main search results page, the Video tab, Google Images, and Google DiscoverGoogle Discover is a personalized, mobile-first content feed built into the Google app, Chrome's mobile New Tab page, and google.com that surfaces articles and videos based on a user's interests and activity — not a response to a search query. There's nothing to 'rank' for in the traditional sense; eligibility is governed by Discover's content policies plus the same helpful-content, image, and page-experience signals Google Search already uses.. This breadth is why it’s one of the two highest-payoff types in the cluster (with Recipe).
• Required: name, thumbnailUrl, uploadDate. Recommended: contentUrl, description, duration, embedUrl, expires, interactionStatistic, regionsAllowed/ineligibleRegion. Supply contentUrl and/or embedUrl so Google can reach the video.
• Key moments — two mechanisms: (1) automatic via SeekToAction/ potentialAction if your URLs accept a timestamp parameter Google can infer; (2) manual via Clip (name, startOffset, url required; endOffset recommended, per chapter) when you want publisher-specified labels and timestamps instead of Google’s automatic picks. Use one mechanism, not both, for a given video.
• URL roles: contentUrl (video bytes) and embedUrl (the player) are not the watch page URL — provide at least one so Google can reach the actual video.
• LIVE badge: BroadcastEvent (isLiveBroadcast, startDate, endDate — required together once you add BroadcastEvent at all) added to VideoObject via publication — documented on the same Video guide, not a separate system. startDate/endDate in the future signal scheduled/expected times; in the past or present they signal the stream has actually started/ended — update endDate once it really ends. Livestreams also need the Indexing APIThe Google Indexing API lets site owners notify Google directly when a URL is added, updated, or removed. Google officially supports it only for pages with JobPosting or BroadcastEvent (livestream) structured data — not for general content. for timely badge updates.
• No media-clip doc page: the guessable /media-clip URL is a 404 — Clip markup is folded into the single Video guide alongside VideoObject and BroadcastEvent.
• Most common miss: omitting uploadDate or writing it in an inconsistent date format — it’s one of only three required fields.
• Eligibility ≠ display: valid markup + a crawlable, indexable video + Google deciding it’s worth showing. Markup only makes you eligible.
• Scope: VideoObject is the schema layer only; broader video SEO (hosting, sitemapsA sitemap is a file that lists the pages, images, videos, and other files on your site so search engines can discover them. It helps discovery, but submitting a sitemap doesn't guarantee crawling or indexing., thumbnails, embeds) is a separate topic.

Official documentation

Primary-source documentation from the search engines.

Google — Video structured dataStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding.

• Video (VideoObject, Clip, BroadcastEvent) structured data — the single authoritative guide covering all three types: VideoObject required/recommended properties, key moments (SeekToAction and Clip), and the BroadcastEvent LIVE badge. Note there is no separate media-clip page — Clip markup lives here.
• Video SEO best practices — the separate indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed.-requirements guide (watch page, video placement, stable asset URLs) that structured-data eligibility depends on.
• Search gallery (rich result types) — where video rich resultsRich results (formerly 'rich snippets') are enhanced search listings — stars, images, prices, breadcrumbs, video thumbnails, and more — that Google and Bing build from structured data. They're a display feature, not a ranking factor, and eligibility never guarantees they'll show. sit among Google’s supported enhancements.
• Rich Results Test — validate the markup and check video rich-result eligibility.
• Video indexing report (Search Console) — how Google reports whether it indexed your videos, and why some aren’t indexed.

Bing / Microsoft

• Marking up your site with structured data — Bing’s general structured-data support (schema.orgSchema markup is code that uses the schema.org vocabulary to label what your content means so search engines can understand it and show rich results. It's most often written in JSON-LD, and it's not a direct ranking factor., JSON-LDJSON-LD (JavaScript Object Notation for Linked Data) is a script-based structured data format, typically paired with the schema.org vocabulary to describe page content for search engines and AI systems. Google recommends it over Microdata and RDFa because it's the easiest format to implement and maintain at scale — but all three work, and structured data isn't a ranking signal. recommended).

Quotes from the source

On-the-record statements from Google. Where a source page exposes the text, the link is a deep link that jumps to the quoted passage.

Google docs — the multi-surface reach

• “Videos can appear in several different places on Google, including the main search results page, Video mode, Google Images, and Google DiscoverGoogle Discover is a personalized, mobile-first content feed built into the Google app, Chrome's mobile New Tab page, and google.com that surfaces articles and videos based on a user's interests and activity — not a response to a search query. There's nothing to 'rank' for in the traditional sense; eligibility is governed by Discover's content policies plus the same helpful-content, image, and page-experience signals Google Search already uses..” Jump to quote

That single sentence is the reason to prioritize this type: four surfaces, one block of markup. Most guides only mention the Video tab.

VideoObject schema cheat sheet

Where video rich resultsRich results (formerly 'rich snippets') are enhanced search listings — stars, images, prices, breadcrumbs, video thumbnails, and more — that Google and Bing build from structured data. They're a display feature, not a ranking factor, and eligibility never guarantees they'll show. can appear

Main search results · Video tab · Google Images · Google DiscoverGoogle Discover is a personalized, mobile-first content feed built into the Google app, Chrome's mobile New Tab page, and google.com that surfaces articles and videos based on a user's interests and activity — not a response to a search query. There's nothing to 'rank' for in the traditional sense; eligibility is governed by Discover's content policies plus the same helpful-content, image, and page-experience signals Google Search already uses. — four surfaces from one block of markup.

Required vs. recommended (VideoObject)

Provide contentUrl and/or embedUrl so Google can reach the actual video — contentUrl is the video’s bytes, embedUrl is the player, and neither is the watch page URL.

Key moments — the two mechanisms compared

Pick one mechanism per video — don’t stack both.

LIVE badge (BroadcastEvent, via publication)

• isLiveBroadcast: true · startDate · endDate — required together once you add BroadcastEvent at all.
• startDate/endDate in the future = scheduled/expected; in the past or present = actually started/ended.
• Layered onto VideoObject, same guide — not a separate schema.
• Call the Indexing APIThe Google Indexing API lets site owners notify Google directly when a URL is added, updated, or removed. Google officially supports it only for pages with JobPosting or BroadcastEvent (livestream) structured data — not for general content. for timely badge updates; set endDate to a real value once the stream actually ends (an approximate endDate beforehand is fine).

Fast facts

• Format: JSON-LDJSON-LD (JavaScript Object Notation for Linked Data) is a script-based structured data format, typically paired with the schema.org vocabulary to describe page content for search engines and AI systems. Google recommends it over Microdata and RDFa because it's the easiest format to implement and maintain at scale — but all three work, and structured data isn't a ranking signal. (recommended).
• No separate media-clip doc page — Clip is folded into the Video guide (/media-clip is a 404).
• Most common miss: omitting uploadDate or a sloppy date format.
• Valid markup = eligible, not guaranteed; the video must be crawlable/indexable.

Key moments: automatic SeekToAction or manual Clip?

If you want the chapter-style timestamps under your video result, there are two ways to do it. Work down the questions to find the right one for your setup.

Rule of thumb: automatic SeekToAction is less work if your URLs already support timestamps and you trust Google to choose the moments; manual Clip is the right call when you want to author each chapter’s label and timestamps yourself. Never stack both mechanisms on the same video.

VideoObject mistakes to avoid

Concrete implementation mistakes on VideoObject, drawn from the common-mistakes list in the Advanced tab — why each is wrong and what to do instead.

Omitting uploadDate, or using a sloppy date format. Why it’s wrong: uploadDate is one of only three required properties (with name and thumbnailUrl). Skip it, or write it inconsistently, and the video isn’t eligible for a rich result at all — it’s the single most common miss on this type. What to do instead: always include uploadDate as a full ISO 8601 date-time value (a date-time with a timezone offset is the safest format).

Shipping a thumbnail with no reachable video. Why it’s wrong: a thumbnailUrl with no way for Google to fetch the actual video file is a thumbnail pointing at nothing — a common reason a result never appears. What to do instead: provide contentUrl and/or embedUrl (both is better) so Google has a real path to the video.

Marking up a video Google can’t crawl or indexStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed.. Why it’s wrong: structured dataStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding. describes a video, it doesn’t make one accessible — markup can’t rescue a video that’s behind a login, blocked in robots.txtA plain-text file at the root of a host that tells crawlers which URLs they may and may not request. It controls crawling, not indexing — a blocked URL can still be indexed if it's linked from elsewhere., or loaded in a way the crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. can’t see. What to do instead: confirm the video itself is crawlable and indexable before worrying about the schema; check the Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. Video indexing reportA Google Search Console report showing how many of your indexed pages contain a video Google found, how many of those videos Google actually indexed, and the reasons blocking the rest. It only covers indexed pages and only appears once Google detects videos on the property. to see what Google actually indexed.

Stacking both key-moment mechanisms on one video. Why it’s wrong: adding both automatic SeekToAction and manual Clip markup to the same video is redundant and contradicts the “pick one” guidance — it invites conflicting signals about where the chapters are. What to do instead: choose SeekToAction (if your URLs already accept a timestamp parameter and you’re fine letting Google infer chapters) or Clip (if you want to name and bound each chapter yourself) — never both for the same purpose.

Forgetting to close out a livestream. Why it’s wrong: leaving endDate unset, or stale, after a stream ends can make the LIVE badge linger on a video that’s no longer live. What to do instead: update endDate on the BroadcastEvent as soon as the stream ends, and call the Indexing APIThe Google Indexing API lets site owners notify Google directly when a URL is added, updated, or removed. Google officially supports it only for pages with JobPosting or BroadcastEvent (livestream) structured data — not for general content. so the badge change propagates promptly.

Treating valid markup as a guaranteed result. Why it’s wrong: as with every rich-result type, syntactically valid VideoObject markup only makes the page eligible — Google’s systems still decide whether to actually show the rich result. What to do instead: validate the markup, then judge success by what actually shows in search over time, not by the markup passing a test alone.

Confirming a VideoObject change actually took effect

Pass/fail checks for after you add or edit VideoObject (or Clip/BroadcastEvent) markup on a page.

Markup validates and shows as eligible

Test to run: Paste the page URL into Google’s Rich Results Test. Expected result: The test detects a VideoObject item, reports it as eligible for video rich resultsRich results (formerly 'rich snippets') are enhanced search listings — stars, images, prices, breadcrumbs, video thumbnails, and more — that Google and Bing build from structured data. They're a display feature, not a ranking factor, and eligibility never guarantees they'll show., and shows no errors on name, thumbnailUrl, or uploadDate. Failure interpretation: A missing-field error on one of the three required properties means the rich result can’t show at all; a warning on a recommended property (like duration or embedUrl) won’t block eligibility but weakens the result. Monitoring window: Immediate — the test parses the live page’s markup on request. Rollback trigger: Any required-field error persisting after you’ve re-checked the JSON-LDJSON-LD (JavaScript Object Notation for Linked Data) is a script-based structured data format, typically paired with the schema.org vocabulary to describe page content for search engines and AI systems. Google recommends it over Microdata and RDFa because it's the easiest format to implement and maintain at scale — but all three work, and structured data isn't a ranking signal. for typos or a bad date format.

Key-moments mechanism resolves correctly

Test to run: In the same Rich ResultsRich results (formerly 'rich snippets') are enhanced search listings — stars, images, prices, breadcrumbs, video thumbnails, and more — that Google and Bing build from structured data. They're a display feature, not a ranking factor, and eligibility never guarantees they'll show. Test result, check whether SeekToAction or Clip (whichever you implemented) is parsed without errors, and that you haven’t accidentally shipped both. Expected result: Exactly one key-moments mechanism is detected and validates clean. Failure interpretation: Both mechanisms present, or the chosen one throwing an error, means the chapter timestamps likely won’t show under the result. Monitoring window: Immediate, at validation time. Rollback trigger: The test flags both SeekToAction and Clip on the same video — remove one.

Google actually indexed the video

Structured-data eligibility imports Google’s separate video-indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. requirements — a syntactically valid VideoObject doesn’t by itself prove the watch page, the video, or its assets are indexed. Check each layer rather than treating one Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. status as the whole answer:

• Watch page indexed. The page the video is embedded on has to be indexed on its own merits first — Google’s guidance is explicit that an indexed watch page still doesn’t guarantee the video itself gets indexed.
• Video is the main content, not hidden. The video needs to be embedded directly on the watch page (not just linked to) and not hidden behind other elements or a paywall without paywall structured dataStructured data is a standardized way of labeling page content (using the schema.org vocabulary in JSON-LD, Microdata, or RDFa) so search engines can understand its meaning. It's not a direct ranking factor — its value is rich results and entity understanding..
• Assets are fetchable at stable URLs. The thumbnail and, if provided, the contentUrl/embedUrl targets need to resolve at stable URLs Google can repeatedly fetch — frequently-changing CDN URLs are a known cause of videos falling out of the index.

Test to run: Check the Video indexing report in Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance. for the URL (or the property covering it). Expected result: The video is listed as indexed, not flagged under a non-indexed reason (e.g. crawl or robots blocking). Failure interpretation: A “not indexed” status means the rich result can’t appear regardless of how clean the markup is — the video itself, not the schema, is the blocker. Work through the three layers above in order (watch page, then video placement, then asset fetchability) rather than guessing. Monitoring window: Allow Search Console a few days to a couple of weeks to reflect a newly-published or newly-fixed video, since indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. reports lag live crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor.. Rollback trigger: The video stays non-indexed after a reasonable wait and a robots.txtA plain-text file at the root of a host that tells crawlers which URLs they may and may not request. It controls crawling, not indexing — a blocked URL can still be indexed if it's linked from elsewhere./crawlabilityCrawlability is how well search engine crawlers can discover, access, and fetch a site's pages. A crawlability issue is any technical condition — blocked access, broken links, server failures, or bloated URL inventory — that stops pages from reaching the index. check — investigate the video’s accessibilityWeb accessibility means designing sites so people with disabilities can use them, per the W3C's WCAG guidelines. It overlaps with SEO in specific, checkable ways — alt text, heading structure, descriptive link text, captions, and page speed all serve both audiences — but Google has said accessibility itself is not a ranking factor, and most WCAG success criteria (keyboard focus order, ARIA live regions, form labels) have no SEO effect at all., not the schema.

LIVE badge appears and clears on schedule

Test to run: For a livestream using BroadcastEvent, watch the search result during the live window, then again after endDate has passed. Expected result: The LIVE badge shows while the stream is live and disappears promptly after endDate is updated and the Indexing API has been called. Failure interpretation: A badge that lingers after the stream ends usually means endDate wasn’t updated, or the Indexing API wasn’t called to propagate the change. Monitoring window: Check within a few hours of the stream ending, since the badge is time-sensitive in a way an on-demand video isn’t. Rollback trigger: The badge is still showing well after endDate has passed — re-check the BroadcastEvent values and re-submit via the Indexing API.

Test yourself: VideoObject Schema

Five quick questions on schema.orgSchema markup is code that uses the schema.org vocabulary to label what your content means so search engines can understand it and show rich results. It's most often written in JSON-LD, and it's not a direct ranking factor./VideoObject, the surfaces it reaches, key moments, and the LIVE badge. Pick an answer for each, then check.

VideoObject Schema

VideoObject schema (schema.org/VideoObject) marks up video content for Google's video rich results — thumbnail, duration, and key moments — surfacing on main search, the Video tab, Google Images, and Google Discover. It also covers the related Clip (key moments) and BroadcastEvent (LIVE badge) types on the same guide.

Related: Schema Markup, Structured Data, Rich Results, Product Schema

VideoObject Schema

VideoObject schema is the schema.orgSchema markup is code that uses the schema.org vocabulary to label what your content means so search engines can understand it and show rich results. It's most often written in JSON-LD, and it's not a direct ranking factor./VideoObject structured-data vocabulary you add to a page that hosts or embeds a video — usually as JSON-LDJSON-LD (JavaScript Object Notation for Linked Data) is a script-based structured data format, typically paired with the schema.org vocabulary to describe page content for search engines and AI systems. Google recommends it over Microdata and RDFa because it's the easiest format to implement and maintain at scale — but all three work, and structured data isn't a ranking signal. — so search engines can read the video’s name, thumbnailUrl, uploadDate, description, duration, contentUrl, and embedUrl. Google uses it to make the video eligible for video rich resultsRich results (formerly 'rich snippets') are enhanced search listings — stars, images, prices, breadcrumbs, video thumbnails, and more — that Google and Bing build from structured data. They're a display feature, not a ranking factor, and eligibility never guarantees they'll show. across multiple surfaces: the main search results page, the Video tab, Google Images, and Google DiscoverGoogle Discover is a personalized, mobile-first content feed built into the Google app, Chrome's mobile New Tab page, and google.com that surfaces articles and videos based on a user's interests and activity — not a response to a search query. There's nothing to 'rank' for in the traditional sense; eligibility is governed by Discover's content policies plus the same helpful-content, image, and page-experience signals Google Search already uses..

The same Google guide covers two companion types. Clip (or automatic SeekToAction markup) enables key moments — the chapter-style timestamps that let searchers jump into the middle of a video. BroadcastEvent (with isLiveBroadcast, startDate, and endDate) enables the LIVE badge on livestreams.

The three required properties are name, thumbnailUrl, and uploadDate; everything else — contentUrl, description, duration, embedUrl, expires, interactionStatistic, and region eligibility — is recommended. As with every rich-result type, valid markup only makes the page eligible; Google still decides whether to show the enhancement, and the video itself must be crawlable and indexable.

Related: Schema Markup, Structured Data, Rich Results, Product Schema

Changelog