Self-hosted video contentUrl: should you use a CDN?

Serving video contentUrl from your own host instead of a CDN can slow delivery and indexing. See which videos self-host and why a CDN helps.

audited sites affected

What it means

The video's contentUrl points to a URL on your primary domain rather than a dedicated CDN host. According to the video indexing requirements, the content file should live at a stable non-expiring URL, and the handbook explicitly says not to block the CDN. When the file is served from the same host as your site, it can get caught in the same crawl-budget constraints and server-load patterns as your HTML pages.

Why it matters

This matters because Google indexes videos by checking that the contentUrl is accessible, stable, and not blocked—typically on a CDN domain. If the CDN domain is not verified in Search Console, Google may not index the video bytes correctly. It also affects AI agents that scrape for video content, since they expect to find the actual media file at the contentUrl rather than following redirects back to your origin. The handbook notes that contentUrl and embedUrl must not point at the watch page, and that the CDN must not be blocked.

How to fix it

Move the video file to a CDN host and update the VideoObject contentUrl to point at the CDN URL.
Verify the CDN domain in Search Console so Google can crawl it independently.
Ensure the CDN URL is stable and non-expiring (no short-lived tokens).
Check that robots.txt does not block the CDN domain, and that contentUrl differs from both <loc> and embedUrl.

When it's not a problem

If your site has a small video library, the CDN is already verified, and the origin server can serve the video bytes without blocking or expiring, this is not a blocker. The handbook marks it as a notice rather than a warning, so it is worth fixing but not urgent.

How common is it?

36 audited sites in our corpus currently show this issue. The breakdowns below show which platforms, gatekeepers, verticals and countries are most exposed.