Search Console video indexing fails on embedded Vimeo videos for a short list of named reasons, and every reason points at exactly one thing on your page. Read the reason string in the report, fix that one thing, then move to the next. Order matters, because two of the reasons cannot clear until the page itself qualifies. A video being plainly visible to you counts for nothing here. Google is checking whether the page exists to play that video, whether the player is drawn at a real size the moment the page loads, whether the thumbnail can be fetched, and whether that thumbnail belongs to this video alone.
Table of Contents
The reason strings the report actually uses
The video indexing report has a fixed vocabulary. These are the reasons that turn up on pages carrying a Vimeo embed:
- Video isn’t on a watch page. The page is about something else and the video is supporting cast.
- Cannot determine video position and size. The player was not in the page when Google loaded it.
- No thumbnail URL provided. You did not specify one and Google could not generate one.
- Video not found on host service. The video ID or URL on your page no longer resolves at Vimeo.
- The thumbnail family, which is a set of six: unsupported format, invalid size, blocked by robots.txt, transparent, could not be reached, and could not be crawled because your host was at capacity.
Here is where a lot of published advice sends people off a cliff. Vimeo’s own help article, updated in November 2025, tells you to look for the words “Video outside the viewport”. The video indexing report does not contain those words. It says “Cannot determine video position and size”. You meet the first phrasing in URL Inspection and the second in the report. Two screens inside the same product use two different names for one failure. People burn afternoons scrolling for a row that was never going to appear.
Fix them in this order
1. Confirm the page itself is indexed
The report only covers indexed pages. If Google has not indexed the page, or has chosen a different URL as the canonical, the page never enters the report and the video has no route in. URL Inspection tells you which of those you have. A duplicate page carrying the same embed is not fatal on its own, because the video can still be indexed from whichever version Google picked as canonical. Find out which URL that is before you change anything at all.
2. Decide honestly whether it is a watch page
This is the reason that forces a structural change rather than a settings tweak. A watch page is a page whose main purpose is showing a user one video. Google publishes the counter examples, and they are uncomfortably familiar: a blog post where the video supports the text, a product page with a 360 degree video of the product, a category page listing several videos of equal prominence, a review page with a trailer embedded in it. If your page is on that list, no amount of CSS will rescue it.
Vimeo’s recommendation is to build a dedicated playback page for each video and link the article to it. Google says the same thing in its own words. One video, with a title and description written for that video and not much else competing with it. There is a side effect worth knowing about before you groan at the extra work: Vimeo notes that Google may then show your article page in results rather than the bare playback page, so the page you actually care about is still the one people land on.
3. Load the player at its real size and position
Google’s requirement is that the player is present in the page when the page loads, and that it is not hidden behind other elements. Vimeo puts numbers on what prominent means. The whole player has to sit inside the renderable area and be visible on load, and it has to fill at least a third of the page width. A player sitting three screens down a long article fails that even though every human reader will scroll to it. Google’s guidance also says outright that loading the video must not depend on the user swiping or clicking.
4. Give the video a thumbnail you control
“No thumbnail URL provided” means Google could not find one and could not make one either. Supply it yourself, through thumbnailUrl in VideoObject structured data, through video:thumbnail_loc in a video sitemap, or through og:video:image in Open Graph tags. The specifications are unforgiving in a very boring way:
- Supported formats are BMP, GIF, JPEG, PNG, WebP, SVG and AVIF.
- Minimum 60 by 30 pixels. Larger is better.
- Reachable by Googlebot and Googlebot Images, with no robots.txt rule and no login standing in front of it.
- At least 80% of the pixels must have an alpha value above 250, which is a polite way of saying a transparent PNG gets rejected.
- The URL has to stay put. Fast expiring CDN URLs are a documented cause of this exact failure.
If you specify the thumbnail in more than one place, use the identical URL in all of them. Contradicting yourself across a sitemap and your structured data produces the same error as supplying nothing.
5. Make every video’s URLs unique
This one breaks when the same clip is embedded across several pages. If Google finds more than one URL it believes is the same video, it merges them and may take the title from one source and the thumbnail from another, which produces results that look scrambled for no obvious reason. Reusing a single thumbnail image across a batch of videos causes the same mess running the other way, with genuinely different videos collapsing into one. Every video needs its own video URL and its own thumbnail URL, and the URL in your VideoObject has to match the one in your HTML tag and your sitemap.
The lazy loading tradeoff nobody warns you about
Facade embeds are the standard performance advice. You render a static image where the player will go, and the real iframe only loads when someone clicks it. Every page speed audit you have ever read recommends this. You were expecting me to say Google carved out an exception for a technique it spent years asking for. It did the opposite. Read Google’s own explanation of “Cannot determine video position and size”, which describes a page carrying an image where the player will appear that must be clicked to start playback. That is the facade pattern, described precisely, listed as a failure.
So the performance fix and the indexing fix pull in opposite directions, and there is no clever trick that satisfies both. What there is, is the option to stop applying one rule to every page. Load the real player on watch pages, where video results are the entire point. Keep the facade on article pages where the video is illustration, and accept that it will not be indexed from there, because under the watch page rule it was never going to be.
What you can and cannot declare when Vimeo hosts the file
VideoObject has two URL properties that get mixed up constantly. embedUrl is the player, which for a Vimeo embed is the player.vimeo.com address in your iframe’s src attribute. contentUrl is the address of the actual video bytes. For a Vimeo hosted video you generally cannot publish a stable public contentUrl, and that is not a failing on your part.
What it costs you is the extras rather than indexing itself. Google needs to fetch the file to build video previews and to detect key moments automatically, and both of those need a crawlable contentUrl on a stable URL. Without one they are off the table and the video can still be indexed perfectly well. If the report shows N/A where the video URL should be, supplying embedUrl fills that row.
How long this takes, and what an indexed video is actually worth
Fix validation in Search Console typically runs up to about two weeks and sometimes considerably longer. Vimeo warns separately that after you move or resize an embed it can take Google several weeks to discover and fully analyse it. Vimeo also says the quiet part out loud, which I respect them for: making a video prominent and fully within the viewport does not guarantee Google will index it.
Then there is the ceiling, worth knowing before you rebuild your architecture around it. Indexing is eligibility. Everything after that is ordinary ranking. Google also indexes one video per page however many you put there, and the report counts pages rather than videos, so its totals were never a count of your library.
| Video isn’t on a watch page | Build a dedicated playback page for that video and link your article to it |
| Cannot determine video position and size | Drop the click to load facade on that page and render the real iframe at full size, high in the page |
| No thumbnail URL provided | Add thumbnailUrl to your VideoObject and use the same URL everywhere else you declare it |
| Thumbnail blocked or unreachable | Unblock it in robots.txt and host it somewhere with a URL that does not expire |
| Video not found on host service | Check the video still exists on Vimeo at that ID and is not set to private |
| Nothing appears in the report at all | The page is not indexed or is not the canonical. Start with URL Inspection |
