Lingue

Tag Open Graph: non un fattore di posizionamento, ma un elemento SEO da curare

Cosa sono i tag Open Graph, perché non sono un fattore di posizionamento di Google, come Google usa og:title, og:image e og:site_name, quali dimensioni di og:image documentano le piattaforme, come funzionano ripiego e cache e come forzare una nuova scansione.

Prima pubblicazione: 2 lug 2026 · Ultimo aggiornamento: 13 ago 2026 · Advanced
Lingue
AIScritto daAI v2

I tag Open Graph (OG) sono elementi <meta> nella tua head, dal protocollo Open Graph (ogp.me, creato da Facebook), che descrivono la tua pagina come un oggetto condivisibile. Le quattro proprietà richieste sono og:title, og:type, og:image, og:url; aggiungi og:description, og:site_name, og:locale e og:image:alt. Il loro compito principale è la card di anteprima del link che le persone vedono quando il tuo URL viene condiviso su Facebook, LinkedIn, Slack, Discord, WhatsApp e iMessage — quindi sono una leva per il CTR, non un fattore di ranking. Ma Google li legge: og:title è elencato tra le fonti che può usare per il titolo nei risultati di ricerca (aggiunto ad agosto 2024), og:image è uno degli input documentati per la selezione automatica delle miniature di Google per Search e Discover, e og:site_name è un input a priorità più bassa per il nome del sito mostrato nei risultati — nessuno di questi garantisce che il tuo valore venga usato così com'è. Spina pratica: og:image richiede un URL assoluto e una descrizione alt documentata; ogni piattaforma pubblica le proprie indicazioni sulle dimensioni (LinkedIn: 1200×627 min, 1,91:1; Google Discover: almeno 1200px di larghezza, 16:9) piuttosto che una cifra universale, anche se 1200×630 (1,91:1) è la convenzione cross-platform di lunga data; i tag mancanti causano un'anteprima non controllata (non vuota); ogni piattaforma memorizza nella cache lo scraping, quindi modificare i tag non risolve i link già condivisi — forza un nuovo scraping con Facebook Sharing Debugger o LinkedIn Post Inspector. La maggior parte dei crawler social non esegue JavaScript, quindi i tag devono essere nell'HTML renderizzato dal server.

TL;DR — I tag Open Graph sono elementi <meta> nel <head> definiti dal protocollo Open Graph (ogp.me, creato da Facebook) che descrivono la tua pagina come un oggetto condivisibile. Obbligatori: og:title, og:type, og:image, og:url; comuni opzionali: og:description, og:site_name, og:locale e og:image:alt. Le proprietà ripetute formano array, con il primo tag preferito in caso di conflitti. Non sono un fattore di ranking — sono il livello di aspetto per le anteprime dei link nelle app social/chat (Facebook, LinkedIn, Slack, Discord, WhatsApp, iMessage). La gestione da parte dei motori di ricerca è separata e non dovrebbe essere dedotta dalla validità di Open Graph. Il protocollo stesso non impone dimensioni in pixel per og:image — ogni piattaforma pubblica le proprie specifiche (LinkedIn, Google Discover) — quindi fornisci un og:image con URL assoluto dimensionato per le piattaforme che supporti; sappi che i tag mancanti producono un’anteprima non controllata, non vuota; e ricorda che ogni piattaforma memorizza nella cache lo scraping — modificare i tag non corregge i link già condivisi, quindi forza un nuovo scraping. La maggior parte dei crawler social non esegue JavaScript, quindi i tag devono essere nell’HTML renderizzato lato server.

Evidence for this claim The Open Graph protocol defines og:title, og:type, og:image, and og:url as basic metadata for representing a page as a graph object. Scope: Open Graph protocol vocabulary; platform rendering can vary. Confidence: high · Verified: Open Graph protocol Evidence for this claim Meta's sharing crawler uses server-rendered Open Graph metadata and provides Sharing Debugger tools to inspect and refresh scraped information. Scope: Meta/Facebook sharing behavior, distinct from search ranking. Confidence: high · Verified: Meta for Developers: Webmasters sharing guide

Cosa sono realmente i tag Open Graph

I tag Open Graph sono elementi <meta> nel <head> della tua pagina, definiti dal protocollo Open Graph — una specifica creata da Facebook e pubblicata su ogp.me. La premessa del protocollo è che una pagina web può essere trasformata in un ricco “oggetto” con un vocabolario piccolo e coerente di proprietà, così qualsiasi piattaforma può costruire la stessa anteprima dagli stessi tag. L’explainer degli sviluppatori di Google spiega chiaramente l’origine: il protocollo Open Graph “fornisce a Facebook i metadati necessari per consentire alle pagine web di avere la stessa funzionalità di altri oggetti di Facebook,” secondo l’articolo di web.dev sulla scoperta sociale.

La specifica indica quattro proprietà come obbligatorie — og:title, og:type, og:image, e og:url — e quelle che aggiungerai quasi sempre sono og:description, og:site_name e og:locale, oltre a sotto-proprietà strutturate come og:image:width, og:image:height e og:image:alt (la guida della stessa specifica: una pagina che specifica og:image dovrebbe specificare anche og:image:alt).

I tag ripetuti e le proprietà strutturate seguono regole specifiche. Il protocollo consente di ripetere una proprietà radice per descrivere più oggetti (ad esempio, diverse immagini candidate) — quando i consumatori vedono valori in conflitto per la stessa proprietà, il primo tag nell’ordine del documento vince. Una sotto-proprietà strutturata come og:image:width si applica al tag og:image immediatamente precedente, non a ogni immagine nella pagina, quindi mantieni raggruppati nell’ordine del sorgente l’og:image di ogni immagine e le sue sotto-proprietà strutturate. Questo è un comportamento a livello di protocollo di ogp.me stesso, non una peculiarità della piattaforma.

Il concetto da ricordare è che Open Graph controlla il livello di presentazione nelle piattaforme social e di messaggistica, analogo alla presentazione nella SERP gestita con il tag del titolo e la meta descrizione. L’obiettivo è lo stesso: controllare come si presenta la pagina, ma su una superficie diversa.

I tag Open Graph principali, uno per uno

L’explainer di web.dev di Google fornisce lo scopo di ogni tag in una riga ciascuno: og:title è “il titolo della pagina web,” og:description è “la descrizione della pagina web,” og:image è l‘“URL di un’immagine allegata al post condiviso,” og:url è “l’URL canonico della pagina web,” e og:type è “una stringa che indica il tipo di pagina web” (web.dev). In pratica:

  • og:title — il titolo della card. Mantienilo più o meno a ciò che appare sulle card mobili/desktop; usa il titolo grezzo senza aggiungere il nome del sito. Questo è separato dall’elemento HTML <title>, anche se Google può attingere a entrambi per il titolo link (vedi sotto).
  • og:description — la descrizione della card. Una o due frasi; il testo più lungo viene troncato sulla maggior parte delle piattaforme.
  • og:image — la miniatura, e la proprietà che fa o distrugge la card. Deve essere un URL assoluto (https://…) — un percorso relativo viene ignorato silenziosamente dai crawler. Aggiungi og:image:width/og:image:height così le piattaforme possono disporre la card prima che l’immagine finisca di caricarsi, e og:image:alt con una descrizione reale — il protocollo stesso lo raccomanda ogni volta che specifichi og:image.
  • og:url — l’URL canonico per la pagina (allinealo con il tuo rel=canonical così le condivisioni si consolidano su un unico indirizzo).
  • og:type — dichiara il tipo di oggetto. website è il default (ed è come viene trattata qualsiasi pagina non marcata); article sblocca proprietà extra come article:author, article:published_time e article:section; ci sono anche i tipi profile, book, video.* e music.*. Questo conta per le funzionalità delle piattaforme, non direttamente per la SEO.
  • og:site_name e og:locale — la coppia opzionale ma utile. og:site_name nomina il brand dietro la pagina; og:locale (default en_US) serve solo quando il contenuto non è in inglese americano.

I tag Open Graph sono un fattore di ranking? No — ma ecco cosa ne fa Google

Non esiste una fonte ufficiale di Google che affermi che i tag OG influenzino il posizionamento. Controllano la presentazione, non la posizione — la stessa categoria in cui John Mueller colloca la meta descrizione: “primarily used as a snippet in the search results page. And that’s not something that we would use for ranking” (traduzione) «usata principalmente come snippet nella pagina dei risultati di ricerca. Non è qualcosa che useremmo per il posizionamento» (tramite Search Engine Journal). Nessun rappresentante di Google ha rilasciato una dichiarazione equivalente specifica su Open Graph. La prova disponibile è quindi il meccanismo documentato: in tre casi confermati Google legge i tag OG come possibili segnali per la presentazione. Un markup valido resta un possibile input, non garantisce una particolare visualizzazione, un determinato ritaglio né risultati di traffico o posizionamento. Considera questi casi come ciò che è documentato, non come un elenco esaustivo di tutti gli usi possibili.

Dal 26 agosto 2024, la documentazione di Google elenca “Content in og:title meta tags” tra le fonti che può usare per generare automaticamente il titolo link — il titolo cliccabile nei risultati. La riga del changelog è diretta: “Google Search can use content within og:title meta tags to automatically generate title links” (traduzione) «Google Search può usare il contenuto dei tag meta og:title per generare automaticamente i titoli link» (changelog di Search Central). È una delle circa nove fonti che Google combina (documentazione sui titoli link) — non una garanzia che il tuo og:title venga usato testualmente.

og:image come fonte della miniatura dell’immagine

La guida di Google alle buone pratiche SEO per le immagini contiene una sezione intitolata «Specificare un’immagine preferita tramite i metadati». Indica due fonti con cui influenzare la scelta dell’immagine per la Ricerca: primaryImageOfPage di schema.org, o un’immagine associata all’entità principale, oppure “the og:image meta tag.” (traduzione) «il tag meta og:image». Google precisa che “Google’s selection of an image preview is completely automated” (traduzione) «la selezione di un’anteprima immagine da parte di Google è completamente automatizzata» e invita a “avoid using a generic image (for example, your site logo) or an image with text in the schema.org markup or og:image meta tag.” (traduzione) «evitare immagini generiche, come il logo del sito, o immagini contenenti testo nel markup schema.org o nel tag meta og:image». Il documento su Discover offre le stesse due opzioni e aggiunge indicazioni concrete: almeno 1200 px di larghezza, più di 300 000 pixel totali e rapporto 16:9; l’esempio è 1280×720. Il rapporto differisce dalla convenzione 1,91:1 delle schede social, quindi una sola immagine preparata per la condivisione non costituisce automaticamente il ritaglio preferito di Discover.

La stampa di settore (Search Engine Land, Search Engine Journal, Search Engine Roundtable) ha trattato questa documentazione su Images/Discover come nuova intorno all’inizio di marzo 2026 e ha riportato che il ruolo di og:image ora si estende anche agli AI Overviews. Non ho potuto confermare direttamente una menzione degli AI Overviews nelle pagine Images o Discover di Google — nessuna delle due pagine menziona attualmente AI Overviews o “AI surfaces” — quindi tratta il ruolo per Search/Discover come fatto documentato e l’estensione agli AI Overviews come riportata da terze parti, non qualcosa che i documenti ufficiali di Google affermano esplicitamente. In ogni caso, si tratta di selezione, non di ranking: og:image è uno dei tanti input, senza garanzia di visualizzazione esatta.

og:site_name come fonte del nome del sito

Per il nome del sito mostrato accanto ai risultati, Google afferma che il sistema “will also consider content in og:site_name, <title>, heading elements, and other text on a home page. However, WebSite structured data is most important” (traduzione) «considererà anche il contenuto di og:site_name, <title>, delle intestazioni e di altro testo nella pagina iniziale. Tuttavia, i dati strutturati WebSite sono l’elemento più importante» (documentazione sui nomi dei siti). og:site_name è quindi un segnale secondario rispetto al markup Schema WebSite. Per le pagine video esiste un quarto punto di contatto: Google supporta OGP e legge og:video:image per le miniature, secondo la documentazione SEO per i video.

Mettendo tutto insieme, il titolo onesto è: Google legge i tuoi tag OG, ma solo per aiutare a decidere come appare il tuo risultato — mai dove si posiziona.

Come le piattaforme social e le app di chat usano i tag OG

Il compito principale e quotidiano dei tag OG è la card di anteprima del link. Facebook, LinkedIn, Slack, Discord, WhatsApp, iMessage e Telegram li leggono tutti per costruire la card mostrata prima di un clic.

X/Twitter è il caso particolare. Secondo Google, le Twitter Card sono “an extension to the Open Graph Protocol applicable for Twitter” (traduzione) «un’estensione del protocollo Open Graph applicabile a Twitter» (web.dev). X controlla prima twitter:card e gli altri tag twitter:*, poi usa come ripiego le singole proprietà OG. Se twitter:card manca del tutto, può comunque costruire una scheda dai dati OG, usando come impostazione predefinita il tipo semplice summary. Il vecchio Twitter Card Validator è stato ritirato intorno al 2022; non esiste più un validatore ufficiale specifico per X, quindi gli strumenti OG di terze parti ne svolgono la funzione pratica.

Dimensioni e formato consigliati per og:image

Il protocollo Open Graph stesso non imposta dimensioni in pixel o rapporto d’aspetto per og:image — ogp.me definisce solo le proprietà strutturate (og:image:width, og:image:height, og:image:type, og:image:alt), non una dimensione richiesta. Il dimensionamento è una decisione per singolo consumatore, e i consumatori non sono tutti d’accordo:

  • LinkedIn documenta il proprio minimo direttamente: 1200 × 627px, rapporto 1,91:1; le immagini più strette di ~401px vengono renderizzate solo come miniatura piccola.
  • Google Discover documenta almeno 1200px di larghezza, più di 300 000 pixel totali, rapporto 16:9 (esempio fornito: 1280×720) per i metadati dell’immagine preferita — un rapporto notevolmente diverso dalla convenzione per le card social qui sotto.
  • La documentazione attuale di condivisione di Facebook richiede immagini “larghe almeno 1080 pixel” senza fissare un rapporto universale; rimanda a una guida separata sulle best practice per i dettagli.

Data questa varietà, 1200 × 630px (circa 1,91:1) rimane il default pratico multipiattaforma che la maggior parte degli implementatori usa — è vicino al minimo di LinkedIn stesso e viene renderizzato in modo accettabile (anche se non sempre perfetto al pixel) su Facebook, Slack, Discord, WhatsApp e iMessage, e X lo mostra come card a immagine grande. Trattalo come una convenzione sensata, non come una regola imposta da una singola specifica — se una piattaforma specifica è molto importante per te, controlla la documentazione attuale di quella piattaforma piuttosto che assumere che questa cifra sia garantita corretta lì.

Due cose che sono regole ferree, non convenzioni:

  • URL assoluto obbligatorio. og:image deve puntare a un URL completo https://…; un percorso relativo viene ignorato dai crawler.
  • Niente loghi generici o immagini ricche di testo se vuoi anche che l’immagine sia idonea per la selezione delle miniature di Google — Google avverte esplicitamente contro entrambi, e contro rapporti di aspetto estremi. Imposta anche og:image:alt con una descrizione reale.

Cosa succede quando i tag Open Graph mancano

Un mito comune è che “niente tag OG” significhi “link di testo semplice, senza immagine”. Non è così — le piattaforme fanno fallback, non si svuotano. Facebook riempie i vuoti con il <title> della pagina, la meta description e la prima immagine utile nel contenuto; LinkedIn si comporta in modo simile e tratta le immagini più strette di ~401px come solo miniatura. Quindi il rischio reale di omettere i tag OG è un’anteprima non controllata e peggiore — un’immagine casuale nel corpo, un <title> troncato — non un’anteprima mancante. Se ti interessa come appare una pagina quando viene condivisa (e per qualsiasi cosa promuoveresti, dovrebbe interessarti), imposta i tag piuttosto che lasciare che ogni piattaforma indovini.

Perché i tuoi tag OG aggiornati non vengono mostrati — caching e re-scraping

Questo è il punto dolente pratico numero uno. Facebook, LinkedIn e Slack mettono in cache i dati OG scrapati, quindi modificare i tag non aggiorna retroattivamente i link già condivisi. I documenti per webmaster di Facebook confermano un meccanismo specifico che vale la pena conoscere: “le immagini vengono memorizzate nella cache in base all’URL e non verranno aggiornate se l’URL non cambia” — quindi se stai risolvendo un’immagine bloccata, cambiare il nome del file og:image (non solo il suo contenuto) può forzare un nuovo fetch. Non ho una fonte di prima parte per quanto esattamente la cache di ogni piattaforma viva prima di scadere da sola, quindi non trattare alcuna durata specifica che vedi citata altrove come una garanzia documentata — forza un re-scrape per piattaforma invece di aspettare che passi:

  • Facebook Sharing Debugger (developers.facebook.com/tools/debug) — incolla l’URL e usa “Scrape Again” per attivare un nuovo fetch.
  • LinkedIn Post Inspector — ri-fetch e anteprima della card; se l’immagine ancora non viene caricata, controlla che non sia bloccata o dietro autenticazione.
  • X/Twitter — nessun validatore ufficiale dal ~2022. Poiché X fa fallback sui tag OG, un debugger OG generico più una nuova condivisione è la via pratica.

Poiché i crawler mettono in cache e i contenuti cambiano, i tag OG non sono davvero “imposta e dimentica”: dopo un aggiornamento significativo di contenuto o immagine su una pagina di alto valore, fai un re-scrape.

Insidie di implementazione: JavaScript, limiti di byte, URL assoluti

Il più grande si ricollega direttamente al rendering: la maggior parte dei crawler delle piattaforme social non esegue JavaScript. I tag OG iniettati lato client — ad esempio, da React dopo l’idratazione — sono invisibili per loro; il crawler vede un <head> vuoto. I tag devono essere presenti nell’HTML raw, renderizzato lato server. Questa è la stessa distinzione crawl-vs-render che colpisce i siti pesanti in JavaScript altrove (vedi JavaScript SEO). Slack è stato segnalato (non documentato in una specifica ufficiale) per recuperare solo un numero limitato di byte dall’inizio di una pagina, quindi come margine di sicurezza metti i tuoi tag OG all’inizio di <head> piuttosto che dopo un grande script inline o blocco di stile. E, ancora una volta perché è il killer silenzioso: og:image deve essere un URL assoluto.

Bing, Microsoft e Open Graph

Bing è molto meno documentato qui di Google. Il Markup Validator di Bing (in Bing Webmaster Tools) elenca Open Graph tra i formati di markup strutturato che riconosce, insieme a schema.org, Microdata, Microformats e RDFa, e le linee guida di migrazione di Bing segnalano i metadati OG come qualcosa da mantenere aggiornato durante uno spostamento — ma Bing non ha pubblicato specifiche in stile Google su se o come i dati OG alimentano i suoi snippet o miniature. In pratica, il consumatore più forte dell’ecosistema Microsoft dei tag OG è LinkedIn (di proprietà Microsoft), che legge og:title, og:description, og:image e og:url per costruire le sue card di condivisione. Non sopravvalutare un meccanismo di Bing che non è documentato.

Miti comuni su Open Graph, sfatati

  • “OG tags are a Google ranking factor.” (traduzione) «I tag OG sono un fattore di posizionamento di Google.» No: nessuna fonte ufficiale lo afferma. Influenzano l’aspetto (fonti per titolo-link, miniatura immagine, nome del sito), non la posizione.
  • “OG is only for Facebook, irrelevant to real SEO.” (traduzione) «OG serve solo a Facebook e non ha alcuna rilevanza per la SEO.» È un’idea superata. I documenti di Google elencano og:title (titoli-link, aggiunto ago 2024), og:image (un input per la selezione delle immagini in Search/Discover) e og:site_name (un input di priorità inferiore per il nome del sito) come tre funzionalità di aspetto separate per cui legge i tag OG — anche se “AI Overviews” specificamente è un report della stampa di settore, non un’affermazione sulle stesse pagine Images/Discover di Google al momento di questo controllo.
  • “No OG tags means a plain, image-less link.” (traduzione) «Senza tag OG il link sarà solo testo e non avrà un’immagine.» No: le piattaforme usano come ripiego <title>/meta description/prima immagine, dando un’anteprima non controllata, non vuota.
  • “Updating og:image instantly fixes every already-shared link.” (traduzione) «Aggiornare og:image corregge subito tutti i link già condivisi.» No: Facebook/LinkedIn/Slack memorizzano nella cache lo scrape; devi forzare un nuovo scrape, e la cache CDN può ritardarlo ulteriormente.
  • “Use the Twitter Card Validator to fix X previews.” (traduzione) «Usa il Twitter Card Validator per correggere le anteprime di X.» Lo strumento è stato ritirato intorno al 2022; oggi non esiste un validatore ufficiale di X.
  • “Any image size/URL works for og:image.” (traduzione) «Con og:image funzionano qualsiasi dimensione e qualsiasi URL.» No: deve essere un URL assoluto, e Google mette in guardia contro loghi generici, testo nell’immagine e proporzioni estreme per la propria selezione di miniature.

Dove andare dopo

Questa pagina è un approfondimento sotto l’hub Meta Tags for SEO, la mappa del cluster on-page di quali elementi head contano davvero. Open Graph è il livello di aspetto social/chat — i suoi fratelli sul lato aspetto SERP sono il title tag (che Google può trarre dal tuo og:title) e la meta description (l’analogo più vicino: non un fattore di ranking, tutto incentrato sul clic). Per il lato immagine e nome del sito, OG si sovrappone a schema markup — Google tratta og:image e primaryImageOfPage dello schema come fonti alternative di miniature. E poiché la maggior parte dei crawler social non esegue JavaScript, l’intero argomento è a valle di rendering e JavaScript SEO.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.