Video Sitemap Generator With Thumbnail, Title and Player Tags

The 4 things Google requires per video

For every video you list, 4 pieces of information are mandatory:

• <video:thumbnail_loc>: a crawlable image URL for the thumbnail.
• <video:title>: should match the visible title on the page.
• <video:description>: up to 2,048 characters. Longer descriptions are truncated at that limit.
• One of <video:content_loc> or <video:player_loc>: the raw media file, or the embeddable player URL. Supply either; supply both if you have both.

Here is a complete entry:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"
        xmlns:video="http://www.google.com/schemas/sitemap-video/1.1">
  <url>
    <loc>https://www.example.com/watch/demo</loc>
    <video:video>
      <video:thumbnail_loc>https://cdn.example.com/thumb.jpg</video:thumbnail_loc>
      <video:title>Product demo</video:title>
      <video:description>A 90-second walkthrough of the editor.</video:description>
      <video:content_loc>https://cdn.example.com/demo.mp4</video:content_loc>
    </video:video>
  </url>
</urlset>

Everything else in the video extension is optional: duration, publication date, view count, family-friendly flags, restrictions. Optional tags are only worth adding when the value is accurate. A <video:duration> that disagrees with the file is worse than no duration at all, which is why this tool emits the required set cleanly and stays out of the rest.

Columns are recognized by their shape

The documented order is page url | Title | thumbnail | Description | video file, but you do not have to honor it. Each column after the first is classified by what it looks like:

• A URL ending in an image extension (.jpg, .png, .webp, .avif, .svg and friends) becomes thumbnail_loc.
• A URL ending in a video extension (.mp4, .mov, .webm, .m3u8 and friends) becomes content_loc.
• Any other URL becomes player_loc. That is what an embed URL looks like, since embed endpoints rarely carry a file extension.
• The first plain text column becomes the title, the second becomes the description.

So all of these produce the same entry:

https://www.example.com/watch/demo | Product demo | https://cdn.example.com/thumb.jpg | A 90-second walkthrough | https://cdn.example.com/demo.mp4
https://www.example.com/watch/demo | https://cdn.example.com/thumb.jpg | Product demo | https://cdn.example.com/demo.mp4 | A 90-second walkthrough

Tabs behave like pipes, so a spreadsheet or CSV export pastes in as is. Relative media paths resolve against the Base URL, or against the page's own origin when no base is set. If you only supply a title and no description, the title is reused as the description, which is a stopgap, not a good description.

One url entry per page, not per video

This is the structural mistake that costs the most. A <url> element identifies a page, and the <loc> is the page a viewer watches the video on. If one page hosts 3 videos, you write one <url> with 3 <video:video> blocks nested under it, not 3 <url> entries with the same <loc>.

Repeating a <loc> is a duplicate-URL validation error, and this tool removes duplicate lines before generating anything, so a per-video paste quietly loses videos. Build multi-video pages by nesting the blocks yourself after export, or list one representative video per page and let the page markup carry the rest.

The corollary matters too: never point <loc> at the raw .mp4. The video file is not the landing page. <loc> is where a person lands, content_loc is what plays.

What happens when a required field is missing

Rather than emitting <video:thumbnail_loc></video:thumbnail_loc>, which invalidates the entry, incomplete lines come out like this:

  <url>
    <loc>https://www.example.com/watch/onboarding</loc>
    <!-- fill in before publishing: missing thumbnail_loc, content_loc or player_loc -->
  </url>

The file stays parseable, the URL is not dropped, and the fix is visible in place. Above the output, the tool lists the input line numbers of every incomplete entry so you can go back to the source rather than hunting through XML. Fill the gaps and regenerate, or delete those <url> blocks before you publish. Do not ship the comments.

The fields on this page

• URLs takes one page per line, plus the metadata columns described above. Lines starting with # are ignored, duplicate URLs are dropped, and unparseable lines are listed back with a reason.
• Sitemap type is preset to video. The same engine also produces standard XML, image, news, HTML, WordPress and visual output.
• Base URL resolves relative lines and supplies absolute locations for the sitemap index when the file has to split. Set it if you paste paths rather than full URLs.
• Last modified governs <lastmod> on the page entry. changefreq and priority are not emitted here at all, since Google ignores them.

The usual sitemap limits still apply: 50,000 URLs and 50 MB uncompressed per file, whichever comes first. Video entries are verbose, so the byte limit is the one you are likely to meet. The tool packs against both and generates a sitemap_index.xml when it splits.

Before you publish

3 checks that catch most of the failures that survive validation:

• The media must be fetchable. If robots.txt blocks your CDN path or your video directory, none of it gets processed. This is the single most common reason a valid video sitemap yields nothing.
• The video should be visible on the page. A video sitemap describes what a visitor sees. Entries pointing at pages where the player is hidden behind a tab, a login, or a lazy-loaded script that never runs for a crawler will not earn video results.
• Add the file to robots.txt and submit it in Search Console. Google retired the sitemap ping endpoint in 2023, so those are the 2 discovery paths that still work.

Keep the video sitemap alongside your standard sitemap rather than instead of it. BlazeHive automates SEO content end to end, but the media metadata has to come from whatever system actually stores your videos.