Immagini Open Graph: dimensioni, formati e perché la tua non appare

Lo standard 1200×630 e perché

Lo standard di fatto og:image la dimensione è 1200×630 pixel, un rapporto d’aspetto di circa 1.91:1. Questo numero non è una tradizione arbitraria: è vicino al rapporto d’aspetto più ampio usato dalla maggior parte delle schede di anteprima dei link su Facebook, LinkedIn, Slack e Discord. Un’immagine di 1200×630 riempie quindi la scheda senza che la piattaforma debba aggiungere bande o ritagliarla in modo significativo.

Le immagini più piccole tecnicamente funzionano ma vengono ingrandite dalla piattaforma per riempire la scheda, ammorbidendo i dettagli e apparendo peggiori di una progettata apposta. Molte piattaforme documentano un minimo intorno a 200×200 per accettare un’anteprima, ma è un limite inferiore, non un obiettivo: scendere sensibilmente sotto 1200×630 rinuncia alla qualità senza vantaggi.

Di Twitter/X summary_large_image scheda usa la stessa immagine 1200×630 e lo stesso rapporto d’aspetto, quindi una sola immagine di solito serve per entrambi og:image e twitter:image senza richiedere un’esportazione separata.

Area sicura: cosa resiste davvero al ritaglio

Anche con il rapporto d’aspetto corretto, le piattaforme ritagliano la scheda in modi leggermente diversi a seconda del contesto: un post nel feed, un’anteprima di link in un messaggio privato e un modulo di “link condivisi” nella barra laterale non mostrano sempre lo stesso ritaglio della stessa immagine. Testo o logo a filo del bordo possono essere tagliati in un contesto anche se sembravano corretti nell’anteprima della tua scheda del browser.

Per sicurezza mantieni contenuti essenziali, come titolo, logo o viso, nel 90% interno circa, con margine del 5–10% per bordo. Sfondi, sfumature e decorazioni possono arrivare al vivo; solo ciò che tutti devono vedere resta interno. Un rettangolo guida rientrato di circa 60px per lato su 1200×630 dà un’area pratica ragionevole.

Formato: JPG o PNG e perché non WebP

Per il file immagine effettivo, JPG e PNG sono le scelte sicure. Il supporto WebP per og:image in particolare ha un supporto incoerente tra i crawler e i bot che generano anteprime dei link: alcuni lo supportano, altri non mostrano alcuna anteprima senza segnalare errori quando ricevono un WebP. Poiché il problema è silenzioso, è facile pubblicare un’anteprima non funzionante senza accorgersene finché qualcuno non lo fa notare.

È un requisito di compatibilità più restrittivo rispetto a mostrare WebP in un browser, cosa che quasi tutti i browser attuali gestiscono senza problemi: vedi il nostro Confronto tra WebP, PNG e JPG per il caso generale. I crawler delle anteprime dei link sono una popolazione di client diversa e più conservativa rispetto ai browser degli utenti, e il loro supporto WebP è in ritardo. Usa JPG per anteprime fotografiche, con file più piccoli a qualità visiva equivalente, e PNG quando l’immagine contiene colori uniformi, testo o richiede la conservazione della trasparenza in alcuni contesti; la trasparenza stessa è però irrilevante per un’immagine OG, perché viene sempre mostrata sullo sfondo usato dalla scheda della piattaforma.

GIF è tecnicamente accettato dalla maggior parte delle piattaforme come immagine statica, ma non è una scelta sensata per un’anteprima fotografica o ricca di design; qui non c’è un motivo pratico per preferirlo a JPG o PNG.

L’URL deve essere assoluto

<meta property="og:image" content="/og-image.jpg" /> sembra ragionevole e funziona quando visualizzi direttamente la pagina in un browser, perché il browser risolve il percorso relativo rispetto all’URL della pagina corrente. I crawler che generano anteprime dei link spesso non eseguono la stessa risoluzione in modo affidabile o usano una base sbagliata: il risultato pratico è un’immagine non funzionante o del tutto assente su alcune piattaforme, mentre funziona su altre, rendendo difficile diagnosticare il problema dalle sole segnalazioni degli utenti.

Scrivi sempre l’URL completo e assoluto, inclusi protocollo e dominio:

<meta property="og:image" content="https://example.com/og-image.jpg" />

Nell’API Metadata di Next.js, questo significa impostare metadataBase nel layout principale, così i percorsi relativi delle immagini dichiarati nei metadati delle pagine vengono risolti automaticamente in URL assoluti durante la build, oppure scrivendo l’URL completo direttamente nei openGraph.images voce come fa questo sito.

Cache: perché un’immagine corretta mostra ancora la vecchia anteprima

È la causa più comune in assoluto di «l’ho corretto, ma viene ancora mostrato male». Le piattaforme memorizzano in cache i dati Open Graph estratti, immagine inclusa, per ogni URL, e quella cache non scade solo perché hai pubblicato un nuovo file. Ricaricare la pagina personalmente, anche in una finestra privata, non rivela nulla su ciò che la cache della piattaforma contiene ancora.

Ogni piattaforma principale ha un proprio strumento per forzare una nuova lettura:

• Facebook / Meta: Sharing Debugger (developers.facebook.com/tools/debug/): incolla l’URL e fai clic su «Scrape Again». Questo cancella anche la cache usata dalle anteprime dei link di Instagram e WhatsApp, che condividono il crawler di Meta.
• X/Twitter: Card Validator è stato storicamente usato a questo scopo; la disponibilità è cambiata nel tempo, quindi se non è raggiungibile, aggiungere all’URL una stringa di query di versione innocua, come descritto sotto, è un’alternativa più affidabile.
• LinkedIn: Post Inspector (linkedin.com/post-inspector/): incolla l’URL per forzare un nuovo recupero.
• Slack, Discord, iMessage: nessuno strumento di debug pubblico. In genere questi servizi fanno scadere la propria cache dopo un certo tempo secondo i propri tempi oppure la aggiornano quando l’URL cambia anche leggermente.

Quando uno strumento di debug specifico della piattaforma non è disponibile o fa esso stesso i capricci, la soluzione universale è cambiare l’URL visto dalla piattaforma, aggiungendo una stringa di query di versione come ?v=2 al link condiviso o all’URL dell’immagine stessa obbliga ogni piattaforma a trattarlo come una risorsa mai vista e a recuperarlo di nuovo, invece di servire una voce vecchia della cache.

Peso del file e altri limiti

La maggior parte delle piattaforme documenta un limite di peso di pochi megabyte: quello di Facebook è storicamente intorno a 8MB e anche piattaforme senza un numero esplicito tendono a scadere o rifiutare anteprime di file insolitamente grandi. Poiché un JPG o PNG 1200×630 ben compresso per questi contenuti è solitamente molto sotto 500KB, raggiungere il limite significa quasi sempre un’esportazione non ottimizzata: una grande foto ridotta nel markup ma non ricodificata a dimensioni minori oppure una fotografia esportata PNG anziché JPG. Consulta la nostra guida alla riduzione del peso dei file immagine per il metodo generale di riduzione di un’esportazione senza perdita visibile di qualità.

Leggibilità del testo in miniatura

Un’immagine OG viene solitamente mostrata molto più piccola dei suoi 1200×630 pixel nativi: un’anteprima Slack o una scheda in un feed mobile può avere una larghezza di poche centinaia di pixel. Qualsiasi testo incorporato nell’immagine deve resistere a quella riduzione. Come indicazione pratica, il testo corrente sotto circa 40px alla larghezza nativa di 1200px tende a diventare illeggibile quando viene ridotto per i posizionamenti tipici dei feed; i titoli che devono restare leggibili nelle miniature richiedono solitamente dimensioni molto maggiori, più vicine a 60–80px o oltre, in grassetto e con forte contrasto sullo sfondo.

Questo è anche un motivo per mantenere semplice l’immagine stessa. Una composizione affollata con più elementi di testo in competizione può risultare leggibile a dimensioni originali, ma diventare rumore visivo alla scala di una scheda; un unico titolo chiaro su uno sfondo ad alto contrasto resta leggibile su tutte le superfici in cui compare l’immagine.

twitter:card richiede una dichiarazione propria

Impostazione og:image non è automaticamente sufficiente per un’anteprima con immagine grande su X/Twitter. Il sistema di schede di Twitter legge il proprio twitter:card meta tag per scegliere lo stile della scheda; senza di esso, alcuni client Twitter usano una scheda più piccola con miniatura anche se è presente un perfettamente valido og:image è presente.

Dichiaralo esplicitamente:

<meta name="twitter:card" content="summary_large_image" />

Twitter utilizzerà come alternativa og:image per l’immagine effettiva se twitter:image non è impostato separatamente, quindi in genere non devi duplicare l’URL dell’immagine; la dichiarazione del tipo di scheda non è però facoltativa se vuoi la disposizione con immagine grande.

Un rapido ordine di diagnosi

1. Conferma che l’URL dell’immagine sia assoluto, non relativo, e si apra direttamente nel browser.
2. Conferma che il formato sia JPG o PNG, non WebP.
3. Conferma che le dimensioni siano 1200×630 o vicine.
4. Conferma twitter:card è impostato se è proprio l’anteprima Twitter/X a essere sbagliata.
5. Esegui il debugger della piattaforma per forzare una nuova lettura prima di presumere che la correzione non abbia funzionato.
6. Se non è disponibile un debugger, incrementa una versione nella stringa di query dell’URL per invalidare la cache.

Domande frequenti