Video Sitemap Optimization Guide

A video sitemap is a specialized XML file that tells Google where your video content lives and gives it the metadata it needs to understand that content without having to parse a player embed. It is not a substitute for a general XML sitemap, and most sites do not need one at all. This guide covers when a video sitemap is actually worth building, which elements are required today, and which older elements and endpoints Google has quietly retired.

A general XML sitemap, the kind that lists every crawlable URL on your site, is a separate topic with its own submission and validation mechanics; that ground is covered in a dedicated sitemap guide and isn’t repeated here. This post is specifically about the <video:video> extension elements you add to a sitemap entry when a page’s primary content is video.

When you actually need a video sitemap

Google can discover and index video content through a regular XML sitemap, through VideoObject structured data, or through a dedicated video sitemap. A video sitemap earns its keep when video is a primary, indexable asset on a page, not decoration. Google’s own guidance is direct on this point: don’t list videos that are unrelated to the content of the host page.

Practical rule of thumb:

Situation	Video sitemap needed?
Product page with a single hero demo video that explains the product	Yes, if you want video-specific search features
Blog post embedding a YouTube video as illustration	Usually no, YouTube already indexes it
Video library / streaming platform with hundreds of unique videos	Yes
Autoplay background video with no informational value	No, don't include it at all
Page with 3 unrelated stock videos bolted on for "engagement"	No, this violates host-page relevance and can hurt rather than help

If the video isn’t the reason someone would land on that page, it doesn’t belong in the sitemap entry for that page.

There’s also a multiplicity question worth addressing up front: a single page can have more than one <video:video> entry if it genuinely hosts multiple distinct videos (a lesson page with three separate demo clips, for example). What you shouldn’t do is create one <video:video> entry per page for a video that’s actually repeated site-wide, like a shared brand intro or an autoplay background loop that appears identically on hundreds of URLs. That pattern reads as low-value duplication rather than genuine per-page video content, and it dilutes the signal the sitemap is supposed to send.

Required elements

Per Google’s current video sitemap documentation, each <video:video> entry needs:

• <video:thumbnail_loc>: a URL to the thumbnail image
• <video:title>: the video’s title
• <video:description>: up to 2,048 characters
• Either <video:content_loc> or <video:player_loc>: at least one is mandatory

Google explicitly recommends content_loc as the most reliable way for it to fetch and process the video file directly, when you’re able to provide it.

Skipping any of these isn’t a stylistic choice Google tolerates silently: a video entry missing thumbnail_loc, for example, surfaces in Search Console’s Video indexing report as a “No thumbnail URL provided” error and blocks that entry from being indexed at all, not just from earning rich-result treatment.

Useful optional elements include <video:duration> (1 to 28,800 seconds), <video:expiration_date>, <video:publication_date>, <video:family_friendly>, and <video:tag>. None of these are required, but duration and publication_date are worth adding when available since they feed directly into how the video is displayed in search results.

One protocol limit that trips people up: only HTTP and FTP URLs are supported in content_loc. Streaming protocols are not supported, so if your video is served exclusively through a streaming manifest, you’ll need to rely on player_loc instead.

Content URL vs. player URL

content_loc points straight at the raw video file (an .mp4, for example) so Googlebot can fetch and process it directly. player_loc points at a page or embed that plays the video through a player, similar to an iframe embed.

Use content_loc when you host the actual file and can serve it directly. Use player_loc when the video is hosted by a third-party platform (a video CMS, a streaming provider) and you only control the embed. If you can supply both, Google recommends including content_loc; it’s the more direct signal and doesn’t depend on Google being able to interact with a player interface.

A common real-world constraint: many teams embed video through YouTube, Vimeo, or a dedicated video hosting platform specifically because self-hosting large video files is expensive on bandwidth and storage. In that case content_loc usually isn’t available to you at all, since you don’t control the raw file URL, and player_loc pointing at the embed is the correct and only option. That’s not a lesser setup, it’s simply a different one, and Google’s documentation treats it as fully valid.

Elements Google has deprecated

Several video sitemap tags and attributes were retired on August 6, 2022. Google announced this in a Search Central blog post covering multiple sitemap extension cleanups: <video:category>, <video:gallery_loc>, <video:price>, <video:tvshow>, and the autoplay and allow_embed attributes of <video:player_loc> were all dropped from active use (Spring cleaning: some sitemap extension tags are going away). <video:platform> and its is_live value were not part of this deprecation and remain supported.

If you still have these tags in an existing video sitemap, there’s no penalty for leaving them in during a transition, they’re simply ignored. But there’s no reason to keep generating them going forward, and any content management system or sitemap plugin that’s still outputting video:category or video:price as if they were required is working from outdated documentation.

The ping endpoint is gone

For years, the standard advice was to “ping” Google after updating a sitemap by hitting a URL like google.com/ping?sitemap=.... Google retired this endpoint. The announcement came in June 2023, framed as part of a broader move away from manual ping-based notification (Sitemaps ping endpoint is going away). If your workflow still pings that endpoint after every sitemap update, the request no longer does anything, it’s a dead call, not an error, just a wasted step.

The correct way to get a sitemap (video or otherwise) discovered and re-crawled:

1. Reference it in your robots.txt file with a Sitemap: directive.
2. Submit it directly in Google Search Console under Sitemaps.
3. Let Google’s normal crawl schedule pick up changes; there’s no reliable way to force an immediate re-crawl through the sitemap alone.

Validating and monitoring your video sitemap

Once a video sitemap is submitted, don’t treat it as fire-and-forget. Two checks are worth doing on an ongoing basis:

• Search Console coverage. After submitting the sitemap under Sitemaps in Search Console, check back for processing errors. A sitemap can be syntactically valid XML and still get individual video entries rejected for missing required fields or unreachable thumbnail URLs. The Video indexing report names these failures directly, with “No thumbnail URL provided,” a thumbnail smaller than Google’s stated minimum (60×30 pixels, with larger sizes preferred and no fixed upper bound), and missing title or description values among the most common rejection reasons.
• Spot-check indexing. Use the URL Inspection tool on a handful of video pages to confirm Google can actually see and render the video content, not just the sitemap entry describing it. A sitemap listing a video is a hint, not a guarantee of indexing.

If videos aren’t appearing in search results despite a clean sitemap, the sitemap is rarely the actual problem. More often it’s one of: the thumbnail URL returning a 404 or a low-resolution placeholder, the video being blocked by robots.txt or a noindex on the host page, or the video simply not being unique or valuable enough relative to competing content on the same topic to earn a video-specific placement.

It’s also worth remembering that a video sitemap doesn’t need to be a separate physical file forever. Many sites generate it dynamically alongside their standard sitemap index, and any CMS or e-commerce platform with a video library feature should be checked to confirm it’s actually outputting current elements rather than a plugin default written years ago. Auditing an existing video sitemap for stale or deprecated fields takes a few minutes and is worth doing at least once a year, especially after a CMS or plugin upgrade.

How this relates to VideoObject schema

A video sitemap and VideoObject structured data (JSON-LD) are not interchangeable, and using one doesn’t make the other optional. The sitemap tells Google a video exists and where to find it. The schema markup on the page itself describes that video in structured detail (thumbnail, upload date, duration, and so on) in a format search engines can parse without guessing at page layout. Sites that want full eligibility for video-rich search results generally need both: the sitemap for discovery, the schema for the descriptive detail that powers rich results. The field-by-field schema implementation is a separate topic from sitemap mechanics and isn’t duplicated here.

Does a video sitemap actually improve click-through rate?

It’s tempting to attach a specific multiplier to video thumbnails in search results (“videos get 2-3x the clicks”), but that kind of precise figure isn’t something Google publishes and it varies enormously by query, industry, and how competitive the result page already is. What can be said honestly: a rich, relevant video thumbnail in search results is a more visually distinct result than a plain blue link, and distinct results generally earn more attention on a results page. Treat the sitemap and schema work as making your video content properly eligible for that kind of placement, not as a guaranteed traffic multiplier.

Common mistakes

• Thumbnail dimensions too small or the wrong aspect ratio. Google doesn’t publish a hard minimum, but low-resolution or heavily cropped thumbnails tend to get skipped in favor of a competitor’s cleaner image when a rich result slot is limited.
• Sitemap entry pointing at a page, not the actual video. content_loc needs to resolve to the video file or a valid streaming manifest reference through player_loc, not to the HTML page that happens to embed it.
• Reusing one generic description across every video entry. A templated, non-specific <video:description> gives Google (and users, if it surfaces in a snippet) nothing to differentiate one video from another on the same site.
• Forgetting to remove entries for deleted or unpublished videos. A sitemap that still lists videos returning 404s signals poor maintenance and can drag down trust in the rest of the sitemap’s entries.
• Treating the video sitemap as a ranking lever on its own. It’s a discovery and metadata mechanism. It doesn’t substitute for the video actually being useful, well-produced, and relevant to the page it lives on.

Implementation checklist

• Confirm the video is actually central to the page before including it (host-page relevance)
• Include all four required elements: thumbnailloc, title, description, and contentloc or playerloc
• Use contentloc when you control direct file hosting; fall back to playerloc for third-party-hosted embeds
• Drop deprecated tags (category, galleryloc, price, tvshow) from new sitemap generation
• Stop pinging the retired ping endpoint; submit through robots.txt and Search Console instead
• Pair the sitemap with VideoObject schema on the page for full rich-result eligibility
• Keep sitemap file size within the standard 50,000 URL / 50MB XML sitemap limits that apply to sitemaps generally

A video sitemap is a narrow, mechanical piece of technical SEO. Get the required fields right, drop the tags Google no longer uses, and stop routing requests to an endpoint that’s been retired, and there’s not much else to it.