SEO per video: la pagina, il markup e il file

Se hai già deciso di pubblicare un video su una pagina del tuo sito, la domanda che conta non è più se ne valga la pena, ma come fare in modo che Google lo legga, lo indicizzi e lo mostri nei risultati giusti. Questo articolo tratta esattamente questo: l'implementazione tecnica per un video ospitato su una tua pagina, sia esso caricato su un player self-hosted oppure incorporato tramite embed di YouTube o Vimeo.

Non troverai qui una discussione sul ritorno dell'investimento nel video marketing né una panoramica della ricerca visiva in generale: sono temi affrontati altrove. Qui ci si concentra su cinque elementi tecnici che decidono se un video viene letto correttamente da un motore di ricerca: il markup VideoObject campo per campo, la sitemap video, la struttura in capitoli e key moments, la trascrizione come testo indicizzabile, e la scelta tra embed e player self-hosted, con il suo effetto reale sui Core Web Vitals.

Il markup VideoObject campo per campo

Lo schema VideoObject dichiara esplicitamente a un motore di ricerca "questo è un video, ed ecco i suoi dati". Senza di esso, il crawler deve dedurre le informazioni dal player o dal contesto della pagina, con risultati incerti. I campi che contano sono pochi, ma vanno compilati con precisione, non riempiti a caso per soddisfare un validatore.

Un campo a parte è hasPart, usato per dichiarare i singoli capitoli come oggetti Clip: ci si torna nella sezione dedicata, perché è lì che rende davvero il lavoro utile. Evita invece di aggiungere campi come interactionStatistic solo perché esistono in documentazione: un numero di visualizzazioni non aggiornato o inventato è peggio di nessun valore, perché introduce un dato verificabile e falso in un markup altrimenti coerente.

• name è il titolo del video in sé, non il titolo della pagina che lo ospita: possono essere diversi se il video tratta un aspetto più specifico.
• description è un riassunto autonomo del contenuto del video, non una frase generica copiata dal meta della pagina: deve avere senso anche letto isolato, fuori contesto.
• thumbnailUrl deve puntare a un'immagine reale e rappresentativa, non a un frame nero o a un placeholder. Per essere idonei al formato con miniatura grande nei risultati, serve un'immagine sufficientemente larga: un file troppo piccolo o compresso in modo aggressivo esclude il video da quel trattamento visivo.
• uploadDate va in formato ISO 8601 (es. 2026-03-14) e deve corrispondere alla data reale di pubblicazione, non a una data aggiornata ogni volta che tocchi la pagina: farlo sistematicamente è un segnale di manipolazione rilevabile confrontando la data dichiarata con la cronologia di scansione.
• duration usa anch'essa ISO 8601, ma per gli intervalli: un video di quattro minuti e tredici secondi diventa PT4M13S. Un valore mancante o palesemente sbagliato è uno dei motivi più comuni di scarto silenzioso del rich result.
• contentUrl ed embedUrl non sono intercambiabili: contentUrl punta al file video scaricabile direttamente, embedUrl a un player che lo incorpora, come l'iframe di YouTube. Serve almeno uno dei due; per un video self-hosted userai quasi sempre contentUrl.

La sitemap video: quando serve davvero

Una sitemap video dedicata non è obbligatoria per ogni sito che pubblica video: si investe spesso tempo a costruire e mantenere un file XML quando il markup VideoObject sulla pagina, da solo, avrebbe già fatto il lavoro.

Se pubblichi un video per pagina, con un markup VideoObject completo su una pagina già ben collegata e presente in una sitemap standard, una sitemap video dedicata aggiunge manutenzione senza un beneficio proporzionato. Quando la usi, richiede comunque gli stessi dati del markup — thumbnail_loc, title, description, content_loc o player_loc — e non lo sostituisce: lo affianca.

• Quando hai una libreria ampia di video su molte pagine e vuoi accelerarne la scoperta invece di aspettare il crawling normale.
• Quando alcune pagine con video non sono facilmente raggiungibili dalla struttura di link interni, ad esempio un archivio poco collegato.
• Quando vuoi dichiarare metadati non già chiari dal markup on-page, come una scadenza (expiration_date) per contenuti temporanei o eventi.
• Quando aggiorni spesso il catalogo e vuoi un canale di segnalazione più diretto del solo ricrawling.

Capitoli e key moments: la struttura che Google può leggere

I "momenti salienti" nei risultati di ricerca, le miniature cliccabili che portano a un punto preciso del video, nascono da una struttura esplicita che il motore di ricerca può interpretare, non da un video semplicemente ben montato.

Ci sono due strade, spesso complementari. La prima, tipica di YouTube, è indicare i timestamp direttamente nella descrizione, con un formato riconosciuto dalla piattaforma: righe che iniziano con un minutaggio (00:00, 01:15, 04:30) seguito da un'etichetta breve. YouTube trasforma automaticamente questi timestamp in capitoli navigabili, a patto che il primo inizi a 00:00 e ce ne siano almeno tre.

La seconda strada, valida sia per YouTube sia per un video self-hosted, è il markup strutturato: hasPart accetta un elenco di oggetti Clip, ciascuno con un proprio name, uno startOffset e un endOffset in secondi, e opzionalmente un url che punta al momento esatto — per un self-hosted, tipicamente con un frammento come #t=90 se il player lo supporta. È l'approccio da preferire quando il video è sul tuo dominio, perché non dipende da una piattaforma terza.

In entrambi i casi, l'errore più comune è usare etichette generiche: "Capitolo 1", "Parte 2" ripetute identiche su decine di video. Un'etichetta come "Come impostare il tag canonical su pagine paginate" comunica esattamente cosa aspettarsi da quel segmento; un'etichetta generica non aggiunge informazione, anche se tecnicamente valida.

La trascrizione: il testo che rende il video indicizzabile

Un file video, da solo, non contiene testo che un motore di ricerca possa leggere direttamente: la comprensione del contenuto passa dal testo che lo circonda in pagina, non dal flusso audio o video in sé. È qui che la trascrizione smette di essere un accessorio per l'accessibilità e diventa lo strumento principale con cui il contenuto entra nell'indice come testo pertinente per una query.

Una trascrizione ben fatta dà a una pagina con un solo video incorporato la stessa profondità testuale di un articolo scritto da zero, senza inventare contenuto che il video non tratta. Se il video segue una struttura in capitoli, vale la pena rispecchiarla nella trascrizione con sottotitoli interni corrispondenti ai key moments: rinforza sia la leggibilità sia la coerenza tra le fonti sulla stessa pagina.

• I file di sottotitoli (WebVTT o SRT), collegati al player tramite l'elemento track, servono soprattutto per l'accessibilità e la fruizione durante la visione: sincronizzati al fotogramma, ma non pensati per essere letti come testo continuo.
• La trascrizione completa, pubblicata come testo visibile in pagina — anche dentro un blocco richiudibile, purché presente nel markup e non caricato solo al click — è ciò che un crawler tratta come un normale paragrafo, comprendendolo semanticamente.

Embed YouTube o player self-hosted? Il costo reale sul Core Web Vitals

Questa è la decisione tecnica che pesa di più, e viene quasi sempre sottovalutata perché sembra una scelta di comodità più che di prestazioni.

Un embed YouTube standard, con il classico iframe verso youtube.com/embed/, non carica solo un video: carica l'intera infrastruttura del player, con il relativo JavaScript, prima ancora che l'utente clicchi play. Se quel riquadro è sopra la piega ed è l'elemento più grande visibile al caricamento, diventa spesso l'elemento che determina il Largest Contentful Paint: il browser attende che l'iframe di terze parti si stabilizzi prima di considerare la pagina dipinta in modo significativo, e quel tempo non è sotto il tuo controllo diretto.

Un player self-hosted, basato sull'elemento nativo video con un attributo poster che punta a un'immagine ottimizzata, ribalta questo equilibrio: l'anteprima è un asset che scegli tu, comprimibile in WebP o AVIF, dimensionato per il viewport e persino precaricabile con un link rel="preload". Il file video, con preload="metadata" invece di preload="auto", non viene scaricato per intero finché l'utente non avvia la riproduzione: il browser recupera solo le informazioni minime necessarie a renderizzare il player.

La tecnica che concilia i due mondi, quando l'embed resta la scelta giusta per banda o funzionalità del player, è il pattern della "facciata": mostri un'immagine statica dell'anteprima, stilizzata come un player con un pulsante di riproduzione sovrapposto, e carichi l'iframe reale solo al clic dell'utente. Il costo in LCP e peso di rete iniziale diventa quello di una singola immagine, non quello dell'intera infrastruttura del player, mentre l'esperienza resta quella di un video normale.

Il compromesso da tenere presente è che un player self-hosted sposta su di te la responsabilità della banda, dell'adattamento della qualità in base alla connessione e dei sottotitoli automatici, cose che una piattaforma come YouTube gestisce da sola. Non è una scelta giusta in assoluto, ma un bilanciamento da fare pagina per pagina, in base a quanto quella specifica pagina dipende dalla velocità di caricamento per convertire o posizionarsi.

Errori che invalidano il lavoro fatto fin qui

Alcuni problemi ricorrono più spesso di altri e vanificano un markup altrimenti corretto.

• Un player senza dimensioni dichiarate (width e height o un aspect-ratio nel CSS) causa uno spostamento del layout quando si carica e occupa uno spazio diverso da quello riservato inizialmente; un video senza thumbnailUrl, inoltre, priva il rich result dell'immagine necessaria.
• Una sitemap video che elenca ancora pagine da cui il video è stato rimosso è peggio di nessuna sitemap: manda un segnale di dati non affidabili su tutto il file, non solo sulla voce sbagliata.
• Un player con dimensioni non responsive, che trabocca dal contenitore su schermo mobile, danneggia l'esperienza proprio nel contesto in cui avviene la maggior parte delle impressioni video.
• Autoplay con audio, bloccato dalla maggior parte dei browser mobili e comunque fastidioso quando permesso, spesso maschera un problema di caricamento più profondo: il video sembra partire ma sta ancora scaricando dati in background.

Come ottenere il carosello video nella SERP italiana

Comparire nel carosello video non dipende da un singolo interruttore, ma dalla somma coerente di tutto quanto descritto sopra, più alcune condizioni di base facili da dare per scontate.

La pagina deve essere indicizzabile senza ambiguità: nessun blocco in robots.txt sulla risorsa o sulla pagina, nessun tag noindex dimenticato da una versione precedente, e un accesso in HTTPS, ormai uno standard minimo più che un requisito specifico per il video. Il video deve essere il contenuto principale della pagina, non un elemento decorativo rispetto a un testo che parla d'altro: un video pertinente ma sepolto in fondo, dopo contenuti non correlati, comunica un segnale di rilevanza più debole rispetto a una pagina costruita attorno a quel video.

La coerenza tra i dati dichiarati e la realtà del video conta più di quanto sembri: una durata nel markup diversa da quella reale, o una miniatura che mostra un fotogramma diverso da quello che l'utente vede aprendo il video, sono discrepanze rilevabili confrontando il markup con il file effettivo, e minano la fiducia in tutti gli altri dati dichiarati sulla stessa pagina.

Poiché la maggior parte delle impressioni sui risultati video avviene da mobile, un player che si carica lentamente o rompe il layout su schermo piccolo pesa doppio: come problema di esperienza utente e come segnale che la pagina non è ottimizzata per il contesto in cui quel rich result verrebbe mostrato. Infine, per query in italiano, avere titolo, descrizione e trascrizione scritti in italiano naturale, non tradotti meccanicamente da una versione inglese, resta il modo più diretto per allineare il markup con l'intento reale di chi cerca in quella lingua. Nessuno di questi elementi garantisce da solo la comparsa nel carosello: insieme, tolgono i motivi più comuni per cui un video tecnicamente pubblicato non ci arriva mai.