Video SEO

Video SEO is the practice of describing a video in text and markup a machine can read — a title, a description, a thumbnail, a playable file URL and a page whose purpose is that video — so that a system which cannot watch it can still decide it answers a question. The footage is not what gets indexed. The metadata is.

That single fact organises the whole discipline. Every recurring video SEO problem is a case of a machine being unable to find, fetch or interpret one of those text fields.

What Google asks for

Google's video documentation describes the same object twice, in two carriers.

As VideoObject structured data on the page: name, description, thumbnailUrl, embedUrl (the player), contentUrl (the file), plus optional expires and regional fields (regionsAllowed or ineligibleRegion). As a video sitemap entry: <loc> for the watch page, <video:player_loc>, <video:content_loc>, <video:thumbnail_loc>, <video:title>, <video:description>, with optional <video:expiration_date> and <video:restriction>.

The two are interchangeable in content and complementary in practice. The documentation adds a rule that catches most implementations: information provided in structured data must be consistent with the actual video content and other metadata on the page. Two titles that disagree is not a partial signal; it is a reason to trust neither. See schema markup for the general form and XML sitemaps for the other carrier.

The technical constraints that silently disqualify a video

These are stated in Google's documentation and are the usual causes of a video that "looks fine" and never appears:

• The file must be a supported type. Google lists 3GP, 3G2, ASF, AVI, DivX, M2V, M3U, M3U8, M4V, MKV, MOV, MP4, MPEG, OGV, QVT, RAM, RM, VOB, WebM, WMV and XAP.
• Data URLs are not supported. An inlined video is not a fetchable resource.
• The URL must be stable. Google notes that some CDNs use quickly expiring URLs, that a thumbnail URL which changes too often may stop videos being indexed, and that video files should be available at stable URLs as well — the crawler arrives after the visitor, and a short-lived signed URL is gone by then.
• The player must be a real element. The video has to be embedded in a <video>, <embed>, <iframe> or <object> element; fragment identifiers are not supported for loading a video.
• The thumbnail must be reachable. Minimum 60x30 pixels, larger preferred, in one of BMP, GIF, JPEG, PNG, WebP, SVG or AVIF, at a stable URL Googlebot can fetch.

Each of these is a fetch-time failure, which is why they are invisible in a browser. See crawling and indexing.

Page shape: one video, one page

Google's guidance for video eligibility is to create a dedicated watch page for each video, "if it makes sense for your business" — a watch page being one whose main purpose is to show users a single video. A page carrying six videos gives the indexer no way to decide which one the page is about, so it often decides the page is about none of them.

This is the same constraint that governs passage-level retrieval generally: an addressable unit needs one subject. A gallery is a navigation page; a watch page is the indexable unit.

Key moments are marked up in one of two ways. Clip structured data specifies exact start and end times with labels, giving you control over how each segment is named. SeekToAction instead declares how your URLs encode a timestamp and lets Google derive the moments. Use Clip when the segment labels matter; use SeekToAction when timestamped URLs already exist.

Why an assistant almost never cites the video itself

A retrieval system fetches documents and extracts passages. It does not decode video. So a video with a title, a description and nothing else contributes roughly two sentences of quotable text, no matter how much substance is in the recording.

The lever is the transcript. A full, on-page transcript turns forty minutes of speech into text that can be chunked, embedded and quoted, and it does so on a page that already has the video's structured data attached. The transcript is the part that gets cited; the video is the part that gets watched. Publishing one without the other means picking which audience you serve.

Two practical notes follow. First, a transcript that is a single undivided wall of text is poor retrieval material — give it headings at topic boundaries, so each section is liftable and correct on its own. Second, restate figures and names in the transcript body rather than leaving them as on-screen graphics, because nothing that exists only in the pixels exists at all.

Failure modes

1. Metadata that disagrees with the page. Structured-data title and on-page <h1> differing is a consistency failure Google explicitly warns against.
2. Expiring media URLs. An invisible cause of non-indexing: the page works in a browser and fails at crawl time.
3. Client-side player injection. If the <iframe> is added by script after load, a fetcher may never see a video on the page.
4. A gallery instead of a watch page. Many videos on one URL leaves no single subject.
5. No transcript. Guarantees the content is unquotable regardless of how well the video ranks.
6. A thumbnail behind auth or generated in-browser. It fails the stable-URL requirement even though humans see it.

Frequently asked questions

What is indexed — the video or the text about it?

The text. Title, description, thumbnail URL, player URL and file URL are what make a video retrievable.

Structured data or sitemap?

Either carries the same fields; structured data is easier to keep consistent with the page.

Why would a working video not get indexed?

Common causes are an unstable or expiring file URL, an unsupported file type, or a player injected after load.

How do I get quoted rather than just watched?

Publish a sectioned transcript on the watch page — it is the only text form of the spoken content.