SEO delle immagini

In breve — La SEO delle immagini consiste nel far lavorare le immagini delle tue pagine per la ricerca: farle comparire in Google Immagini e caricarle rapidamente, così non rallentano la pagina. Le basi: usa un nome file descrittivo, scrivi un buon testo alternativo, comprimi le immagini per evitare file enormi, scegli un formato moderno come WebP e non impostare il caricamento lazy dell’immagine grande in cima alla pagina. Nulla di tutto ciò offre un aumento magico del ranking: aiuta semplicemente le immagini a farsi trovare e mantiene veloci le pagine.

Che cos’è la SEO delle immagini

Quando inserisci un’immagine in una pagina web, i motori di ricerca possono farne due usi importanti. Possono mostrarla nella ricerca immagini (Google Immagini, Bing Immagini, Google Lens), portando persone alla tua pagina. Inoltre leggono l’immagine come parte della pagina, soprattutto attraverso il suo testo alternativo, per capire di che cosa parla la pagina.

Il problema è che un motore di ricerca non può «vedere» una foto come la vedi tu. Si affida agli indizi che fornisci: il nome file, il testo alternativo, le parole intorno all’immagine e il file stesso. La SEO delle immagini consiste nel dare indizi utili e nell’assicurarsi che l’immagine non rallenti la pagina fino a renderla lentissima.

Le poche cose che contano

• Usa un formato adeguato e comprimilo. WebP e AVIF sono formati moderni che rendono i file molto più piccoli dei vecchi JPEG senza peggiorarne l’aspetto. File più piccoli significano pagine più veloci. Le pagine più veloci aiutano il ranking, non per il formato in sé ma perché la velocità conta.
• Dai al file un nome descrittivo. golden-retriever-puppy.jpg dice a Google più di IMG_0042.jpg. Fallo per le immagini nuove: non tornare a rinominare tutte quelle vecchie, come spiego nella scheda Avanzata.
• Scrivi un buon testo alternativo. È la breve descrizione dell’immagine. È l’elemento principale che aiuta l’immagine a comparire nella ricerca immagini ed è richiesto anche per l’accessibilità. Lo tratto integralmente nella guida separata al testo alternativo.
• Non applicare il lazy loading all’immagine grande in cima. Il «lazy loading» ritarda il caricamento delle immagini finché non ti avvicini con lo scroll: è ottimo per le immagini più in basso, ma è sfavorevole per l’immagine principale in alto, quella rispetto alla quale Google misura la velocità della pagina.
• Quando puoi, usa un’immagine unica. Le foto stock vanno bene per la ricerca normale, ma la stessa foto stock può comparire su mille altri siti, quindi è più difficile distinguersi nella ricerca immagini.

L’errore più comune

Usare WebP o AVIF non offre alcun «boost» SEO. Molti pensano che cambiare formato farà salire il ranking. Non è così: Google lo ha detto direttamente. I formati moderni rendono le pagine più veloci, ed è la velocità ad aiutare davvero. Lo stesso vale per i nomi file: sono utili per le immagini nuove, ma rinominare tutta la libreria può fare più danni che altro.

Vuoi la versione precisa, con le citazioni esatte di Google, i compromessi tra formati, i dati strutturati, le sitemap per immagini, Discover e le regole del lazy loading? Passa alla scheda Avanzata.

In breve — La SEO delle immagini ha due obiettivi distinti: (1) posizionarsi nella ricerca immagini (Google Immagini / Lens / Bing), grazie a testo alternativo, nomi file, contesto della pagina e unicità; (2) ottenere prestazioni della pagina, perché le immagini sono spesso l’elemento LCP. Google indicizza <img> (anche dentro <picture>), non gli sfondi CSS, e supporta BMP, GIF, JPEG, PNG, WebP, SVG, AVIF. WebP e AVIF non offrono alcun aumento diretto del ranking (Mueller): il vantaggio è la velocità → Core Web Vitals. Non rinominare in massa i file esistenti. Il loading="lazy" nativo è sicuro sotto la piega, ma mai sull’immagine LCP, che deve avere fetchpriority="high". Dal maggio 2025, fai riferimento alla stessa immagine usando lo stesso URL ovunque. I dati strutturati (ImageObject, array di immagini Product/Article) sbloccano risultati avanzati; le sitemap per immagini aiutano ancora la scoperta. Il testo alternativo ha una guida approfondita dedicata.

La SEO delle immagini svolge due lavori, non uno

È l’inquadramento a cui torno più spesso e che quasi ogni «checklist di SEO per immagini» tende a confondere. Gli obiettivi sono due e richiedono attività diverse:

1. Posizionarsi nella ricerca immagini. Fare trovare le immagini in Google Immagini, Bing Immagini e Google Lens per query specifiche sulle immagini. Dipende dal testo alternativo, dai nomi file, dal testo che circonda l’immagine, dai dati strutturati e dalla sua unicità.
2. Prestazioni della pagina. Le immagini sono quasi sempre l’elemento più pesante di una pagina: la documentazione di Google dice che sono “often the largest contributor to overall page size.” (traduzione) «spesso il contributo maggiore alle dimensioni complessive della pagina». Per questo sono spesso la causa di un Largest Contentful Paint (LCP) lento, che alimenta i Core Web Vitals, a loro volta un segnale di ranking nella ricerca web.

Tieni separati questi due aspetti e l’argomento diventa molto più chiaro. Testo alternativo e nomi file servono soprattutto alla ricerca immagini. Formato, compressione e strategia di caricamento riguardano le prestazioni. Entrambi contano, ma non sono la stessa leva.

E il volume è reale: la ricerca per immagini e visiva è una parte significativa di tutta l’attività di ricerca, e Google Lens è cresciuto rapidamente. Le immagini ottimizzate non sono solo una difesa: sono una fonte di traffico.

Come Google scopre e indicizza le immagini

Alcuni meccanismi determinano se le tue immagini entrano effettivamente nell’indice:

• Viene indicizzato solo l’HTML <img>. Google: “Google parses the HTML <img> elements (even when they’re enclosed in other elements such as <picture> elements) in your pages to index images, but doesn’t index CSS images.” (traduzione) «Google analizza gli elementi HTML <img> (anche quando sono racchiusi in altri elementi come <picture>) nelle pagine per indicizzare le immagini, ma non indicizza le immagini CSS». Se un’immagine vive solo in un background-image CSS, è invisibile alla ricerca immagini. Metti in un <img> tutto ciò che vuoi far trovare.
• Fornisci sempre un src di fallback. Quando usi srcset o <picture>, mantieni anche un semplice src: “some browsers and crawlers don’t understand” (traduzione) «alcuni browser e crawler non comprendono gli attributi responsive»; il src è la rete di sicurezza su cui Google fa affidamento.
• Formati supportati: BMP, GIF, JPEG, PNG, WebP, SVG e AVIF (il supporto AVIF è arrivato nell’agosto 2024). L’estensione deve corrispondere al tipo effettivo del file.
• Il contesto conta anche accanto al markup. Il markup supportato fa scoprire un’immagine; sono il testo circostante della pagina, le didascalie, i titoli e gli altri metadati che Google combina con l’immagine per capire di che cosa si tratta una volta trovata.
• Coerenza dell’URL (aggiornamento di maggio 2025). Google ora raccomanda di fare riferimento alla stessa immagine con lo stesso URL ogni volta che compare. Un portavoce di Google l’ha formulato così: “We updated the Google Image SEO best practices to clarify that URLs for images should be referenced consistently for easier crawling on larger websites.” (traduzione) «abbiamo aggiornato le best practice per la SEO di Google Immagini per chiarire che gli URL delle immagini devono essere referenziati in modo coerente, così da facilitare il crawling dei siti più grandi». È una questione di efficienza del crawling: stessa immagine, stesso URL, così Google può memorizzarla e riutilizzarla invece di recuperare la stessa foto attraverso percorsi CDN o stringhe di query diverse.

Formati dei file: sceglili per la velocità, non per un aumento SEO

Ecco il mito da eliminare subito: i formati «di nuova generazione» non offrono alcun aumento diretto del ranking. Mueller ha confermato che non c’è alcun “SEO boost” (traduzione) «vantaggio SEO» per AVIF e la stessa logica vale per WebP: “WebP images are fine for Image Search,” (traduzione) «le immagini WebP vanno bene per la ricerca immagini», ma “fine” (traduzione) «vanno bene» non significa “better.” (traduzione) «sono migliori». Google non ti premia per il contenitore.

I formati moderni riducono i file, rendono la pagina più veloce e aiutano i Core Web Vitals: è un vantaggio indiretto. Scegli quindi in base ai meriti:

• AVIF — la compressione migliore (spesso oltre il 50% più piccolo del JPEG). Usalo quando il supporto dei browser è coperto, con fallback.
• WebP — dal 25 al 35% più piccolo del JPEG, con supporto dei browser quasi universale. Oggi è il default sicuro per le fotografie.
• JPEG — fallback universale per le fotografie.
• PNG — quando servono trasparenza o grafiche con bordi netti.
• SVG — loghi e icone (vettoriale, scala all’infinito, dimensioni minime).
• GIF — evitalo per tutto ciò che non è banale; usa invece video oppure WebP/AVIF animati.

L’implementazione pulita è <picture> con elementi <source> per i formati moderni e un fallback <img src>: i browser più vecchi degradano con eleganza e Google mantiene un src da indicizzare.

Nomi file: descrittivi per le immagini nuove, niente rinomina in massa delle vecchie

I nomi file sono un segnale reale, anche se secondario. La best practice di Google è usare nomi brevi e descrittivi: “the filename can give Google clues about the subject matter of the image” (traduzione) «il nome file può fornire a Google indizi sul soggetto dell’immagine»; quindi golden-retriever-puppy.jpg è meglio di IMG00023.JPG, mentre un nome generico come image1.jpg è un’occasione persa.

Ma qui c’è la sfumatura che crea problemi: non tornare a rinominare i file esistenti. Mueller ha chiarito che rinominare in massa “is going to take a lot of time for Google’s systems to see” (traduzione) «i sistemi di Google impiegheranno molto tempo a rilevare le nuove immagini» e che l’effetto è “minimal… maybe no visible effect at all” (traduzione) «minimo, forse senza alcun effetto visibile» se il testo alternativo e il contesto circostante sono già buoni. Gary Illyes ha descritto la perdita di segnali causata dalle migrazioni degli URL delle immagini come “in line with web search results, which is a few weeks.” (traduzione) «in linea con i risultati della ricerca web, quindi qualche settimana». Quindi: nomi descrittivi per le immagini nuove, sì; un progetto di rinomina dell’intero sito per un vantaggio marginale e settimane di cambiamenti, no.

Testo alternativo (versione breve)

Non ripeterò qui la trattazione completa, perché il testo alternativo ha una guida approfondita dedicata. Il punto centrale: è il dato più importante dell’immagine, ma il suo vero ritorno riguarda ricerca immagini e accessibilità, non il ranking web. Google lo legge insieme alla visione artificiale e al contesto della pagina: scrivi per il contesto, non riempire il testo di parole chiave e usa alt="" per le immagini puramente decorative. Le regole complete, le citazioni e il flusso di audit sono nella guida al testo alternativo.

Compressione, lazy loading e Core Web Vitals

Poiché le immagini determinano spesso il tuo LCP, è qui che SEO delle immagini e Core Web Vitals si sovrappongono di più:

• Comprimi tutto. Ridimensiona le immagini alle dimensioni di visualizzazione e comprimile. Per la maggior parte delle pagine è la leva prestazionale più importante.
• Il lazy loading nativo è sicuro, sotto la piega. loading="lazy" su <img> è approvato da Google e può essere sottoposto a crawling. Le implementazioni che si rompono sono quelle JavaScript che nascondono l’URL reale in data-src e non espongono mai un src: rischiano di non essere indicizzate. Usa il loading="lazy" nativo o IntersectionObserver e assicurati che le immagini si carichino quando diventano visibili, non dopo un clic o uno swipe (“Google Search does not interact with your page” (traduzione) «Google Search non interagisce con la pagina»).
• Non applicare mai il lazy loading all’immagine LCP. È la regola che viene infranta più spesso. La tua immagine più grande sopra la piega, di solito l’hero, deve caricarsi subito: loading="eager" e fetchpriority="high", non lazy. Applicare il lazy loading all’immagine LCP può aggiungere centinaia di millisecondi all’LCP senza motivo.

Immagini responsive

Usa srcset + sizes (risoluzioni diverse per viewport diverse) e <picture> (art direction / cambio di formato). Tieni distinti due punti:

• Includi sempre un src di fallback. Come sopra: crawler e browser vecchi ne hanno bisogno.
• Ogni candidato deve essere raggiungibile. Qualunque regola di accesso si applichi al tuo src di fallback — non bloccato, non dietro autenticazione, non un URL morto — vale anche per ogni candidato srcset/<picture>. Un candidato non scopribile non aiuta, anche quando il fallback funziona.
• Mantieni coerenti gli URL con la pagina. L’URL dell’immagine nella sitemap per immagini deve essere lo stesso URL usato effettivamente dalla pagina. Non fornire un URL diverso per mobile e desktop: Google è un crawler mobile-first e URL divergenti causano una perdita temporanea del traffico immagini mentre Google ricostruisce la cronologia del ranking per i nuovi URL.

Dati strutturati per le immagini

I dati strutturati sono ciò che sblocca risultati avanzati e badge relativi alle immagini:

• ImageObject con una proprietà license rende le immagini idonee al badge licenziabile in Google Immagini. I campi richiesti sono contentUrl e almeno uno tra creator, creditText, copyrightNotice o license; aggiungi license + acquireLicensePage per il badge stesso.
• I dati strutturati Product e Article vogliono un array di immagini con più proporzioni, comunemente 16:9, 4:3 e 1:1. La proprietà image è obbligatoria per i risultati avanzati che contengono immagini.
• Controllo delle miniature. La scelta della miniatura da parte di Google è automatica, ma puoi influenzarla attraverso lo schema primaryImageOfPage, la proprietà image dell’entità principale o il meta tag og:image: Google usa sia il markup schema.org sia og:image per le miniature in Ricerca e Discover.

Il markup idoneo non garantisce la visualizzazione: Google decide comunque, pagina per pagina, se mostrare davvero il badge, il trattamento dell’array di immagini o la miniatura che i tuoi dati strutturati rendono possibile.

È anche il punto in cui la SEO delle immagini si sovrappone al tema più ampio dei dati strutturati: il markup che alimenta i risultati avanzati di prodotto, articolo e immagine è lo stesso meccanismo.

Sitemap per immagini

Le sitemap per immagini sono uno strumento di scoperta, particolarmente utile per immagini ospitate su CDN, gallerie grandi e siti ricchi di JavaScript, dove le immagini potrebbero non essere trovate dal crawling normale. Due note spesso trascurate: Google ora supporta solo <image:image> e <image:loc> (ha deprecato <image:caption>, <image:title>, <image:geo_location> e <image:license> il 6 maggio 2022, anche se Bing li usa ancora, quindi conservali se servi una sola sitemap a entrambi). Le sitemap per immagini sono anche l’unico punto in cui sono consentiti URL cross-domain in <image:loc>, utile per l’hosting su CDN (verifica il dominio CDN in Search Console). I dettagli tecnici sono nell’articolo sulle sitemap per immagini. Nulla di tutto ciò è una promessa: una sitemap può aiutare Google a scoprire immagini che altrimenti perderebbe, ma inviarla non garantisce crawling, indicizzazione o ranking.

Discover e immagini grandi

Per ottenere anteprime di grande formato in Discover e sulle superfici Google, aggiungi <meta name="robots" content="max-image-preview:large"> e utilizza immagini ampie: almeno 1 200px di larghezza, ad alta risoluzione e, idealmente, in formato 16:9. Lo studio di caso pubblicato da Google ha documentato incrementi effettivi del CTR dopo l’attivazione delle anteprime grandi (il blog culinario ha registrato +79% di CTR da Discover; il sito di notizie +30% di CTR e +332% di clic nell’arco di sei mesi). Si tratta fra le pochissime modifiche alle immagini il cui vantaggio può essere misurato direttamente.

Immagini stock contro immagini uniche

Vale la pena citare chiaramente la posizione di Mueller: la fotografia stock “doesn’t matter for web search directly,” (traduzione) «non conta direttamente per la ricerca web» ma “for image search, if it’s the same image as used in many places, it’ll be harder.” (traduzione) «per la ricerca immagini, se la stessa immagine è usata in molti posti, sarà più difficile». E, separatamente: “uniqueness isn’t equivalent to higher quality” (traduzione) «l’unicità non equivale a una qualità superiore»: scattare personalmente la foto non la fa posizionare automaticamente meglio. Quindi: usa liberamente immagini stock se ti interessa solo il ranking web; usa immagini uniche quando conta la visibilità nella ricerca immagini, perché una foto irripetibile non ha concorrenti diretti.

In evoluzione: etichettatura delle immagini generate dall’IA (C2PA / IPTC)

È un punto da segnalare perché è nuovo e la maggior parte delle guide lo trascura: Google legge i campi copyright IPTC, che possono apparire come credito di attribuzione in Google Immagini e offrire visibilità gratuita al brand, e usa i metadati IPTC / C2PA per identificare le immagini generate dall’IA, mostrando un’etichetta «generata dall’IA» nella funzione «Informazioni su questa immagine». Gli EXIF della fotocamera (ISO, apertura, GPS) non hanno un effetto documentato sul ranking: rimuovili per le prestazioni, ma conserva i campi copyright. Questo spazio è ancora in evoluzione.

Dove andare dopo

Questo hub è la mappa. Ecco gli approfondimenti e gli argomenti adiacenti:

• Testo alternativo — la trattazione completa dell’attributo alt: perché riguarda ricerca immagini, non ricerca web; accessibilità e aspetti legali; regole di scrittura; immagini decorative; testo di ancoraggio per immagini collegate e audit su larga scala. È l’unico sottoargomento abbastanza ampio da meritare un articolo dedicato.
• Ranking in Google Immagini — l’approfondimento sulla visibilità specifica in Google Immagini e Lens: requisiti di indicizzazione, immagini licenziabili e miti che le pagine meglio posizionate continuano a ripetere.
• Formati delle immagini — JPEG contro PNG, WebP e AVIF: a cosa serve davvero ciascun formato e perché il semplice cambio di formato non è un fattore di ranking.
• Core Web Vitals — la metà prestazionale della SEO delle immagini vive qui. Compressione, LCP e fetchpriority sono davvero lavoro sui Core Web Vitals con un cappello da immagini.
• Dati strutturati — ImageObject, array di immagini Product/Article e controllo delle miniature con og:image fanno parte della storia più ampia dei dati strutturati.
• Sitemap per immagini — i meccanismi di scoperta, i tag deprecati da Google ma mantenuti da Bing e gli URL CDN cross-domain.

Riepilogo IA

Una sintesi della versione Avanzata:

• La SEO delle immagini svolge due lavori: (1) posizionamento nella ricerca immagini (Google Immagini / Lens / Bing), guidato da testo alternativo, nomi file, contesto della pagina e unicità; (2) prestazioni della pagina, perché le immagini sono di solito l’elemento LCP da cui dipendono i Core Web Vitals.
• Meccanismi di scoperta: Google indicizza <img> (anche dentro <picture>), non gli sfondi CSS; mantieni sempre un src di fallback; i formati supportati sono BMP, GIF, JPEG, PNG, WebP, SVG e AVIF.
• I formati non danno un aumento diretto del ranking (Mueller, su AVIF; WebP «va bene»). Il vantaggio è la velocità. Scegli AVIF/WebP per la compressione, PNG per la trasparenza e SVG per le icone.
• Nomi file: i nomi descrittivi aiutano le immagini nuove; non rinominare in massa quelle esistenti (effetto minimo o nullo, settimane di assestamento — Mueller; perdita del segnale di circa «qualche settimana» — Illyes).
• Testo alternativo: aiuta soprattutto la ricerca immagini, non il ranking web, ed è trattato nel suo articolo.
• Lazy loading: loading="lazy" nativo è sicuro sotto la piega; JavaScript che nasconde l’URL in data-src è rischioso; non applicare mai il lazy loading all’immagine LCP e usa fetchpriority="high".
• Coerenza degli URL (maggio 2025): fai riferimento alla stessa immagine usando lo stesso URL ovunque; fai coincidere gli URL mobile e desktop.
• Dati strutturati: ImageObject + license = badge licenziabile; Product/Article vogliono array di immagini con più proporzioni; primaryImageOfPage / og:image influenzano le miniature.
• Sitemap per immagini: aiutano la scoperta (CDN, gallerie grandi, siti JS); Google ha mantenuto solo <image:image> / <image:loc> e ha deprecato il resto nel maggio 2022, mentre Bing li usa ancora.
• Discover: max-image-preview:large + immagini da 1 200px / 16:9; esiste un aumento documentato del CTR.
• Stock contro unicità: la stock va bene per la ricerca web, ma è più difficile nella ricerca immagini; unicità ≠ qualità superiore. L’etichettatura delle immagini IA tramite C2PA/IPTC è in evoluzione; gli EXIF non incidono sul ranking.

Documentazione ufficiale

Documentazione primaria dei motori di ricerca.

Google

• Best practice di Google Immagini — il riferimento principale: scoperta tramite <img>, formati supportati, nomi file descrittivi, testo alternativo, immagini responsive, coerenza degli URL, selezione dell’immagine preferita e rinuncia al collegamento inline.
• Sitemap per immagini — tag <image:image> / <image:loc> supportati, URL cross-domain per CDN e limite di 1 000 immagini per URL.
• Dati strutturati per la licenza delle immagini — ImageObject, campi obbligatori e consigliati e badge licenziabile.
• Dati strutturati Article — array di immagini e proporzioni consigliate (16:9, 4:3, 1:1).
• Dati strutturati Product snippet — consigli per le immagini dei prodotti.
• Correggere i contenuti caricati con lazy loading — loading="lazy" nativo / IntersectionObserver e motivo per cui il caricamento attivato dall’interazione nasconde i contenuti a Google.
• Meta tag robots — max-image-preview — come sbloccare le anteprime grandi in Ricerca e Discover.
• Case study sulle immagini grandi — dati CTR di Google sull’attivazione delle anteprime grandi.
• Impedire che le immagini compaiano nella ricerca — robots.txt (Googlebot-Image), X-Robots-Tag: noindex e strumento per le rimozioni.
• Best practice per l’indicizzazione mobile-first — far coincidere URL delle immagini, testo alternativo e nomi file tra mobile e desktop.

Bing / Microsoft

• Partecipare all’ecosistema Bing Image Search — scoperta delle immagini in Bing e metadati utilizzati (nota: Bing usa ancora i tag delle sitemap per immagini deprecati da Google).
• Bing Visual Search — ricerca visiva a livello di oggetto e fattori che aiutano Bing ad abbinare le immagini.

Citazioni dalla fonte

Dichiarazioni ufficiali di Google. Quando una pagina espone il testo, il link approfondito porta direttamente al passaggio citato.

Documentazione Google — scoperta e nomi file

• “Google parses the HTML <img> elements (even when they’re enclosed in other elements such as <picture> elements) in your pages to index images, but doesn’t index CSS images.” (traduzione) «Google analizza gli elementi HTML <img> (anche quando sono racchiusi in altri elementi come <picture>) nelle pagine per indicizzare le immagini, ma non indicizza le immagini CSS» Vai alla citazione
• “The filename can give Google clues about the subject matter of the image.” (traduzione) «il nome file può fornire a Google indizi sul soggetto dell’immagine» Vai alla citazione

Portavoce di Google — coerenza degli URL (maggio 2025)

• “We updated the Google Image SEO best practices to clarify that URLs for images should be referenced consistently for easier crawling on larger websites.” (traduzione) «abbiamo aggiornato le best practice per la SEO di Google Immagini per chiarire che gli URL delle immagini devono essere referenziati in modo coerente, così da facilitare il crawling dei siti più grandi» Copertura

John Mueller, Google — i formati non danno un aumento SEO

• Su AVIF: non c’è alcun “SEO boost” (traduzione) «vantaggio SEO» per l’uso di file AVIF; il vantaggio è indiretto, attraverso la velocità della pagina. Copertura
• Su WebP: “WebP images are fine for Image Search.” (traduzione) «le immagini WebP vanno bene per la ricerca immagini» Copertura

John Mueller, Google — non rinominare i file in massa

• “If you change all of the filenames across the website, then it’s going to take a lot of time for Google’s systems to see” (traduzione) «se cambi tutti i nomi file del sito, i sistemi di Google impiegheranno molto tempo a rilevare le nuove immagini»; l’effetto sarà “minimal effect, maybe no visible effect at all” (traduzione) «effetto minimo, forse nessun effetto visibile» se il testo alternativo e il contesto circostante sono già presenti. Copertura di SEJ

John Mueller, Google — immagini stock contro immagini uniche

• La fotografia stock “doesn’t matter for web search directly,” (traduzione) «non conta direttamente per la ricerca web» ma “for image search, if it’s the same image as used in many places, it’ll be harder.” (traduzione) «per la ricerca immagini, se la stessa immagine è usata in molti posti, sarà più difficile» Copertura
• “Uniqueness isn’t equivalent to higher quality” (traduzione) «l’unicità non equivale a una qualità superiore»: scattare personalmente una foto non fa necessariamente posizionare meglio la pagina o l’immagine. Copertura

John Mueller, Google — immagini trasmesse in streaming

• Incorporare immagini tramite streaming è “a great way to prevent your images from being found through search engines” (traduzione) «un ottimo modo per impedire che le immagini vengano trovate tramite i motori di ricerca», cioè non è compatibile con una buona SEO. Copertura

Gary Illyes, Google — perdita di segnali durante la migrazione

• La perdita di segnali causata dalle migrazioni degli URL delle immagini è “in line with web search results, which is a few weeks.” (traduzione) «in linea con i risultati della ricerca web, quindi qualche settimana» Copertura

Cheat sheet della SEO delle immagini

I fattori: che cosa fanno e best practice

Dati rapidi

• Formati supportati: BMP, GIF, JPEG, PNG, WebP, SVG, AVIF (AVIF dall’agosto 2024).
• Google indicizza <img> (anche dentro <picture>), non background-image CSS.
• Nessun aumento diretto del ranking per WebP/AVIF: il vantaggio è velocità → Core Web Vitals.
• EXIF (ISO/apertura/GPS): nessun effetto sul ranking; i campi copyright IPTC possono comparire come credito.
• C2PA/IPTC: utilizzati per etichettare le immagini generate dall’IA in Google («Informazioni su questa immagine»), un ambito in evoluzione.

Il modello mentale

La SEO delle immagini svolge due lavori, non uno. Quasi ogni «checklist di SEO per immagini» li confonde, ed è proprio questa confusione a diffondere i miti: «rinomina i file!» e «passa a WebP per il ranking!». Dividi il tema nei due obiettivi reali e ogni consiglio troverà da solo il posto giusto:

1. Posizionarsi nella ricerca immagini. Fare trovare le immagini in Google Immagini, Bing Immagini e Google Lens per query specifiche sulle immagini. Le leve sono il testo alternativo, i nomi file, il testo intorno all’immagine, i dati strutturati e la sua unicità. Nulla di questo incide sulla velocità di caricamento della pagina.

2. Prestazioni della pagina. Le immagini sono quasi sempre l’elemento più pesante di una pagina e per questo sono spesso la causa di un Largest Contentful Paint (LCP) lento; l’LCP alimenta i Core Web Vitals, un segnale di ranking nella ricerca web. Le leve sono formato, compressione e strategia di caricamento. Nulla di questo determina se l’immagine compare in Google Immagini.

Perché la separazione conta nella pratica:

• Elimina il mito del formato. WebP e AVIF non fanno posizionare più in alto nella ricerca immagini: non è questo il loro scopo. Sono una leva del gruppo prestazioni (file più piccoli → LCP più veloce → Core Web Vitals), non una leva del gruppo ricerca immagini. Aspettarsi un aumento del ranking da un cambio di formato significa applicare uno strumento prestazionale a un problema di ricerca immagini.
• Elimina il mito della rinomina in massa. I nomi file sono un segnale del gruppo ricerca immagini, per di più secondario. Rinominare tutta la libreria esistente non incide affatto sul gruppo prestazioni, e secondo Mueller il ritorno nella ricerca immagini è «minimo… forse non visibile» se testo alternativo e contesto sono già solidi: settimane di cambiamenti per un piccolo vantaggio in uno solo dei due gruppi.
• Spiega dove usare il lazy loading. loading="lazy" è una scelta del gruppo prestazioni (rimanda le immagini fuori schermo per aiutare il caricamento) e ha un’unica eccezione netta all’incrocio dei due gruppi: l’immagine LCP. Applicare il lazy loading proprio a quella peggiora il gruppo prestazioni senza alcun vantaggio per il gruppo ricerca immagini.
• Spiega perché testo alternativo e compressione non sono consigli intercambiabili. Il testo alternativo è quasi interamente una leva del gruppo ricerca immagini (oltre che dell’accessibilità); la compressione è quasi interamente una leva del gruppo prestazioni. Una pagina può avere un testo alternativo perfetto e comunque un LCP pessimo, oppure un’immagine LCP velocissima ma senza testo alternativo e senza visibilità nella ricerca immagini. Correggere una cosa non corregge l’altra.

Usa questa separazione come diagnosi: quando un’immagine «non funziona», decidi prima quale dei due lavori sta fallendo. Non compare in Google Immagini? Controlla testo alternativo, nome file e unicità. La pagina è lenta? Controlla formato, compressione e scelte di lazy loading. Cercare di risolvere un problema di ricerca immagini con una leva prestazionale, o viceversa, è lo spreco più comune su questo tema.

I KPI permanenti: visibilità nella ricerca immagini e velocità della pagina generata dalle immagini

Poiché la SEO delle immagini svolge due lavori, anche i controlli di salute si dividono allo stesso modo: un gruppo per la visibilità nella ricerca immagini e uno per il lato prestazionale/Core Web Vitals.

Impression e clic dalla ricerca immagini (Search Console)

• Metrica — Impression e clic provenienti specificamente da Google Immagini, monitorati nel tempo come quota del traffico totale della Ricerca.
• Che cosa indica — Se testo alternativo, nomi file, contesto della pagina e unicità dell’immagine stanno davvero generando visibilità nella ricerca immagini, il primo dei due lavori. Una quota Immagini stabile o in calo mentre il traffico complessivo cresce segnala che il lato ricerca immagini viene trascurato rispetto al lato ricerca web.
• Come recuperarla — Search Console → rapporto Risultati di ricerca → filtro Tipo di ricerca: Immagine. Confronta impression, clic, CTR e posizione con il filtro Web predefinito per le stesse pagine e lo stesso intervallo di date.
• Benchmark / intervallo realistico — Non esiste una quota obiettivo universale: un sito ricco di immagini (ricette, fotografie di prodotti, siti stock/portfolio) dovrebbe aspettarsi una quota Immagini significativamente maggiore rispetto a un blog B2B ricco di testo. Stabilisci la tua baseline al primo controllo e osserva l’andamento, invece di inseguire un numero fisso.
• Cadenza — Ogni trimestre come controllo ricorrente; ricontrolla entro poche settimane da qualsiasi modifica su larga scala alle immagini (rinomina in massa, migrazione CDN, nuovo passaggio sul testo alternativo): la valutazione di Illyes sulla perdita di segnali durante una migrazione colloca il riassestamento in «qualche settimana».

Percentuale di superamento dei Core Web Vitals, filtrata sui template ricchi di immagini

• Metrica — La quota di caricamenti di pagina da utenti reali che supera LCP (e i CWV nel complesso), limitatamente ai template in cui l’elemento LCP è normalmente un’immagine (pagine prodotto, immagini hero degli articoli, gallerie).
• Che cosa indica — Se la metà prestazionale della SEO delle immagini — compressione, scelta del formato e lazy loading corretto — regge davvero in condizioni reali. È la prova dei dati sul campo che la regola di non applicare mai il lazy loading all’immagine LCP e le scelte di formato/compressione stanno funzionando.
• Come recuperarla — PageSpeed Insights oppure il rapporto Core Web Vitals in Search Console (basato su CrUX), segmentato per template/gruppo di pagine e non sulle medie dell’intero sito, che possono nascondere un template molto lento dietro altri che funzionano bene.
• Benchmark / intervallo realistico — La soglia LCP «buona» pubblicata da Google è di 2,5 secondi o meno al 75° percentile: è un numero reale e documentato, non una stima. Usalo come linea di superamento/fallimento; non esiste un numero «tipico» onesto oltre questa soglia perché dipende interamente dal peso delle immagini e dall’hosting.
• Cadenza — I dati sul campo CrUX coprono una finestra mobile di 28 giorni, quindi controllali ogni mese; ricontrolla subito dopo qualsiasi modifica al formato delle immagini, alla pipeline di compressione o all’implementazione del lazy loading.

Risorse che meritano il tuo tempo

I miei articoli correlati

• SEO delle immagini: 12 consigli pratici per aumentare il traffico organico — la guida di Ahrefs alla SEO delle immagini (nomi file, testo alternativo, formati, compressione, sitemap, immagini responsive, schema, lazy loading, CDN).
• Guida introduttiva alla SEO tecnica — il posto delle immagini e dei Core Web Vitals nel quadro più ampio della SEO tecnica.
• Problemi di SEO JavaScript e buone pratiche — il lato del rendering e gli attributi alt vuoti lasciati dai framework JavaScript.
• Studio di Ahrefs sugli audit dei siti — lo studio su oltre 1M di domini in cui gli attributi alt mancanti erano il problema tecnico più comune (80,4% dei siti).

I miei interventi

• “Image SEO” (webinar Visme, 2021) — il mio intervento dedicato all’ottimizzazione delle immagini per la ricerca.

Ufficiale

• Le best practice di Google Immagini — il riferimento canonico per tutto ciò che riguarda questa pagina.
• Il case study di Google sulle immagini grandi — dati reali sull’aumento del CTR ottenuto attivando anteprime grandi.

Dal settore

• Google sui nomi file delle immagini e un sorprendente errore SEO (Search Engine Journal) — il consiglio di Mueller nella sessione registrata: rinominare in massa ha un effetto «minimo, forse non visibile» se il testo alternativo è già buono.
• Google mostra come usare il testo alternativo per la SEO (Search Engine Journal) — Mueller sul testo alternativo come segnale soprattutto per la ricerca immagini, non come fattore diretto del ranking web.
• Google aggiorna le best practice per la SEO delle immagini: coerenza degli URL (Search Engine Land) — la copertura dell’aggiornamento di maggio 2025 che chiarisce la regola dello stesso URL per la stessa immagine.
• Google usa Schema.org e og:image per le miniature (Search Engine Land) — l’aggiornamento di marzo 2026 sui segnali per scegliere l’immagine preferita in Ricerca e Discover.
• API Fetch Priority (web.dev) — la guida canonica a fetchpriority="high" sulle immagini LCP, il riferimento dietro alla regola «non applicare mai il lazy loading all’hero».
• Parliamo di SEO delle immagini (podcast Search Off the Record di Google, ottobre 2022) — Lizzi Sassman e John Mueller discutono direttamente di nomi delle immagini, testo alternativo e frequenza del crawling.
• SEO delle immagini: IA multimodale (Search Engine Land) — come la comprensione visiva basata sull’IA sta cambiando l’ottimizzazione per la ricerca immagini.
• Migrazioni delle immagini e perdita dei segnali (GSQI) — Gary Illyes sulla perdita di segnali di circa «qualche settimana» quando cambiano gli URL delle immagini.

Mettiti alla prova: SEO delle immagini

Cinque domande rapide sui miti e sui meccanismi trattati in questo hub. Scegli una risposta per ciascuna, poi controlla.

Cronologia modifiche