Pourquoi Google exige-t-il l'URL du fichier vidéo dans les données structurées ?

Quelle est la différence entre contentURL et embedURL ?

La contentURL pointe directement vers le fichier vidéo lui-même (MP4, WebM, etc.), tandis que l'embedURL désigne l'URL de la page où la vidéo peut être visionnée via un lecteur embarqué. Google fait ici la distinction entre accès au média brut et accès via une interface de lecture.

Cette nuance est capitale : sans contentURL, Google ne peut pas crawler le fichier source, analyser sa durée réelle, extraire des frames pour générer des vignettes automatiques ou vérifier la correspondance entre métadonnées déclarées et contenu effectif.

Pourquoi Google insiste-t-il autant sur cette propriété ?

Le moteur ne se contente plus des métadonnées déclaratives. Il veut vérifier par lui-même ce que contient la vidéo, notamment pour éviter le spam vidéo et les descriptions trompeuses qui ont pollué les résultats enrichis pendant des années.

En accédant au fichier brut, Google peut croiser les informations : durée annoncée vs durée réelle, miniature déclarée vs frames extraites, description vs contenu visuel détecté par ses modèles de vision par ordinateur.

Cette exigence s'applique-t-elle à tous les types de vidéos ?

Officiellement, oui — dès lors que vous voulez être éligible aux résultats enrichis vidéo. Si vous publiez uniquement une vidéo YouTube embarquée sans fichier source accessible, vous ne respectez pas cette consigne stricto sensu.

Toutefois, dans la pratique, beaucoup de sites obtiennent des rich snippets vidéo avec uniquement embedURL renseigné. Ce qui signifie soit que Google fait preuve de souplesse, soit qu'il privilégie certaines plateformes tierces (YouTube, Vimeo) dont il connaît déjà le contenu.

• La contentURL est l'URL directe du fichier vidéo (MP4, WebM, etc.)
• Sans elle, Google ne peut pas analyser le contenu réel de la vidéo
• Cette propriété est distincte de embedURL qui pointe vers le lecteur
• L'exigence vise à limiter le spam et vérifier la cohérence des métadonnées
• Les vidéos hébergées sur des plateformes tierces posent un cas particulier

Cette déclaration est-elle cohérente avec ce qu'on observe sur le terrain ?

Partiellement. Des tests montrent que des vidéos sans contentURL obtiennent quand même des résultats enrichis, surtout quand elles proviennent de YouTube ou Vimeo. Google semble appliquer une tolérance différenciée selon la source.

Cela dit, pour les sites qui hébergent leurs propres vidéos, l'absence de contentURL réduit drastiquement les chances d'éligibilité. La déclaration de Danielle Marshak reflète donc probablement la politique officielle stricte, mais pas forcément l'implémentation algorithmique réelle qui intègre des exceptions non documentées. [A vérifier]

Quels problèmes techniques cette exigence soulève-t-elle ?

Premier souci : exposer l'URL directe du fichier vidéo facilite le téléchargement et le vol de contenu. Beaucoup d'éditeurs utilisent des systèmes de streaming avec URLs signées temporairement — difficile de fournir une contentURL stable à Google.

Deuxième problème : les vidéos hébergées derrière un CDN avec URLs dynamiques ou des tokens d'authentification. Googlebot doit pouvoir accéder au fichier sans restriction, ce qui complique les architectures sécurisées. Résultat : tension entre SEO et protection du contenu.

Cette recommandation concerne-t-elle aussi les vidéos courtes type Shorts ou Reels ?

Google ne précise rien à ce sujet — et c'est gênant. Les formats courts verticaux explosent, mais la documentation officielle reste floue sur leur traitement spécifique dans les données structurées.

En pratique, beaucoup de sites utilisent le même schéma VideoObject pour tous types de vidéos, courtes ou longues. Mais rien ne dit si Google applique les mêmes critères d'éligibilité aux Shorts qu'aux vidéos traditionnelles. [A vérifier]

Que faut-il modifier concrètement dans vos données structurées ?

Ajoutez la propriété contentURL dans chaque objet VideoObject, pointant vers le fichier vidéo réel. Si vous hébergez vos vidéos, assurez-vous que l'URL est directement accessible par Googlebot, sans authentification ni redirection.

Si vos vidéos sont sur YouTube ou Vimeo, récupérez l'URL du fichier source si possible — sinon, privilégiez au minimum embedURL et thumbnailURL bien renseignées, même si cela ne respecte pas strictement la consigne de Google.

Comment vérifier que Googlebot peut accéder à vos fichiers vidéo ?

Utilisez l'outil d'inspection d'URL dans la Search Console pour tester une page contenant une vidéo. Vérifiez dans la section "Vidéo détectée" que Google a bien identifié la contentURL et qu'aucune erreur d'accès n'est signalée.

Contrôlez aussi vos logs serveur : Googlebot doit télécharger effectivement le fichier vidéo, pas seulement la page HTML. Si vous ne voyez aucune requête vers les fichiers MP4/WebM, c'est que Google ne crawle pas vos vidéos.

Quelles erreurs éviter absolument ?

Ne pointez pas contentURL vers une page HTML ou un player JavaScript — il faut l'URL brute du média. Ne bloquez pas l'accès Googlebot aux ressources vidéo via robots.txt ou via des headers restrictifs.

Évitez les URLs signées avec expiration courte : si le token expire avant le passage de Googlebot, l'accès échouera et votre vidéo ne sera pas indexée correctement. Préférez des URLs stables ou avec expiration longue (plusieurs jours minimum).

• Ajouter la propriété contentURL dans tous les objets VideoObject
• Pointer vers le fichier vidéo réel (MP4, WebM, etc.), pas vers une page ou un player
• Vérifier que Googlebot peut accéder au fichier sans authentification ni restriction
• Tester avec l'outil d'inspection d'URL dans la Search Console
• Surveiller les logs serveur pour confirmer le crawl des fichiers vidéo
• Éviter les URLs signées avec expiration courte
• Ne pas bloquer les ressources vidéo dans robots.txt