Formati immagine per la SEO: JPEG vs. PNG vs. WebP vs. AVIF

In breve — Un formato immagine è il tipo di file in cui salvi una foto: JPEG, PNG, WebP, AVIF e alcuni altri. Passare a un formato «moderno» come WebP o AVIF non migliorerà il tuo ranking: Google lo ha dichiarato direttamente. Ciò che fa è ridurre le dimensioni del file, facendo caricare più velocemente la pagina; ed è la velocità ad aiutare davvero. Scegli quindi il formato adatto all’immagine: WebP per la maggior parte delle foto, PNG per loghi e screenshot che richiedono bordi netti o trasparenza, SVG per le icone.

Che cos’è un formato immagine

Quando salvi una foto, la salvi come qualcosa: un .jpg, un .png, un .webp. Questo è il formato. Ogni formato memorizza l’immagine in modo leggermente diverso, e la scelta modifica tre aspetti che ti interessano:

• Quanto è grande il file (un file più piccolo si carica più velocemente).
• Se può avere uno sfondo trasparente (un logo che si adatta a qualsiasi colore).
• Se può essere animato (come una vecchia GIF).

I motori di ricerca sanno leggere tutti i formati comuni, quindi non ne scegli uno per «fare contento Google». Scegli quello che mantiene il file piccolo senza peggiorare l’aspetto dell’immagine.

I formati, in parole semplici

• JPEG — il classico formato per le foto. Funziona ovunque. Ottimo per le fotografie, ma non supporta la trasparenza.
• PNG — ideale per loghi, screenshot e tutto ciò che ha bordi netti o testo, e può avere uno sfondo trasparente. Per le foto, però, i file sono più grandi di quelli JPEG.
• WebP — un formato moderno che rende le foto sensibilmente più piccole di JPEG e supporta anche la trasparenza. Ora funziona praticamente in ogni browser. È la scelta quotidiana più sicura.
• AVIF — il più nuovo e il più piccolo del gruppo (spesso la metà delle dimensioni di un JPEG). Una piccola percentuale di visitatori non riesce ancora a visualizzarlo, quindi va abbinato a un fallback JPEG.
• SVG — per loghi e icone. È disegnato con la matematica, non con i pixel, quindi resta perfettamente nitido a qualsiasi dimensione e il file è piccolo.
• GIF — il vecchio formato per le animazioni. Oggi è in gran parte superato, ma resta il modo più compatibile in assoluto per mostrare un’animazione semplice.

L’errore che commette la maggior parte delle persone

Usare WebP o AVIF non offre alcun «boost» di ranking. Si sente dire «usa WebP per la SEO» e si presume che il formato, da solo, migliori la posizione nei risultati. Non è così: John Mueller di Google lo ha detto chiaramente più di una volta. Il vantaggio è dato da file più piccoli → pagine più veloci → punteggi di velocità migliori, ed è quella velocità ad aiutare. Se hai cambiato formato ma la pagina non è diventata effettivamente più veloce, non c’è alcun guadagno SEO da riscuotere.

La semplice abitudine sicura è questa: usa WebP per le foto, conserva PNG per loghi e screenshot, usa SVG per le icone e non perdere il sonno per AVIF a meno che tu non stia cercando di eliminare ogni ultimo kilobyte (in quel caso, aggiungi un fallback JPEG).

Vuoi il confronto completo — la tabella di compressione/trasparenza/animazione/supporto dei browser per tutti e sei i formati, le citazioni esatte di Google e un albero decisionale per scegliere quale formato usare e quando? Passa alla scheda Avanzata.

In breve — Il formato immagine non è un fattore di ranking. John Mueller di Google ha confermato che per AVIF non esiste alcun vantaggio SEO, mentre WebP è solo «fine for Image Search» — un linguaggio deliberatamente neutro, non «migliore». La vera catena è: formato → dimensioni del file → velocità della pagina → Largest Contentful Paint / Core Web Vitals → i segnali di esperienza della pagina effettivamente usati dai sistemi di ranking. Il formato si trova diversi passaggi prima. Scegli in base al tipo di contenuto, non secondo la regola «vince il più nuovo»: WebP è il default sicuro per le foto (supporto ~96%, ~25–35% più piccolo di JPEG e con trasparenza alpha anche in modalità lossy — cosa che JPEG non può fare); AVIF comprime più a fondo (~50% più piccolo di JPEG, supporto ~94% nel 2026), ma richiede molta CPU per la codifica e non ha il rendering progressivo; PNG per trasparenza e grafica/testo con bordi netti; SVG per loghi, icone e diagrammi; GIF solo come fallback universale per le animazioni. Servi i formati moderni tramite <picture> (AVIF → WebP → JPEG/PNG src): il fallback src è l’URL che Google indicizza. Questa è l’analisi approfondita dei formati; l’implementazione di LCP/fetchpriority/lazy-loading si trova in Image Optimization.

“fine for Image Search”

Il formato immagine influisce davvero sulla SEO?

Parti dal chiarimento del mito, perché è il motivo per cui la maggior parte delle persone arriva su questa pagina.

Il formato non è un fattore di ranking. John Mueller lo ha detto in almeno tre modi diversi e indipendenti nel tempo, e il filo conduttore è sempre lo stesso: il formato non è un segnale, lo è la velocità che consente di ottenere. Dopo l’annuncio di Google dell’agosto 2024 secondo cui AVIF era ora supportato nella Ricerca, Mueller ha confermato che non esiste alcun «SEO boost» nell’usare AVIF rispetto ad altri formati supportati (la copertura di Search Engine Roundtable): il vantaggio è la riduzione delle dimensioni del file, che può aiutare la velocità della pagina, non una preferenza di ranking per il contenitore. Anni prima, parlando di WebP, era stato altrettanto prudente: “WebP images are fine for Image Search” (SE Roundtable) — «fine», non «migliore» o «preferito». E quando le immagini WebP hanno iniziato a comparire nel report «Crawled – currently not indexed» di Search Console, Mueller ha chiarito che si trattava di una particolarità generale dei report sulle immagini (le immagini non vengono indicizzate come pagine HTML), non di uno svantaggio specifico di WebP: “he doesn’t believe the phenomenon is limited to WebP images” (il resoconto di Search Engine Journal).

“doesn’t believe the phenomenon is limited to WebP images”

La documentazione primaria di Google sulla SEO delle immagini lo conferma anche per omissione: elenca i formati supportati, rimanda a PageSpeed Insights per le prestazioni e non collega mai la scelta del formato a un fattore di ranking. L’assenza di quel collegamento è già una prova.

È lo stesso chiarimento del mito che faccio a livello hub in Image SEO e nella guida all’implementazione, Image Optimization, e vale la pena formularlo con precisione. Non dire «il formato non conta». Di’: «il formato non conta direttamente: conta interamente attraverso la catena velocità e Core Web Vitals».

“format doesn’t matter directly — it matters entirely through the speed and Core Web Vitals chain.”

La vera catena: formato → dimensioni del file → velocità → Core Web Vitals

Ecco la sequenza causale, esplicitata, perché comprimerla è esattamente il modo in cui il mito si diffonde:

1. La scelta del formato modifica le dimensioni del file. È la singola leva più importante sul peso dell’immagine.
2. I file più piccoli si caricano più velocemente. La documentazione di Google sulle immagini nota che sono «often the largest contributor to overall page size, which can make pages slow and expensive to load.»
3. I caricamenti più rapidi migliorano il Largest Contentful Paint (LCP). L’immagine hero è di solito l’elemento LCP, quindi il suo peso sposta direttamente la metrica. (Ne parlo in profondità nella mia guida al Largest Contentful Paint, nella parte dedicata al perché l’LCP è di solito un’immagine.)
4. L’LCP alimenta i Core Web Vitals, che sono parte dei segnali di esperienza della pagina usati dai sistemi di ranking di Google.

“often the largest contributor to overall page size, which can make pages slow and expensive to load.”

Il formato si trova all’inizio di quella catena, diversi passaggi prima di qualsiasi elemento vicino al ranking. È proprio per questo che non è un fattore di ranking autonomo: tra l’uno e l’altro devono andare bene troppe cose e, se la pagina non diventa davvero più veloce, nulla cambia a valle.

Il confronto tra i sei formati

La maggior parte delle «guide del 2026» concorrenti copre solo JPEG/PNG/WebP/AVIF e riporta in silenzio numeri sbagliati sul supporto dei browser (ho visto AVIF citato al «~74%», un dato vecchio di anni). Ecco la matrice completa dei sei formati con i dati attuali.

JPEG — il fallback universale per le fotografie

Solo lossy, nessuna trasparenza, nessuna animazione e supportato letteralmente ovunque. JPEG è ancora il fallback corretto alla fine di un elemento <picture> ed è una scelta perfettamente valida per le fotografie quando non le converti in un formato moderno. Il suo punto debole è insito nel funzionamento della compressione lossy: secondo il Chrome team di Google su web.dev, “lossy compression may be less effective with imagery containing sharp edges such as line art, similarly stark details, or text.” È esattamente per questo che JPEG è la scelta sbagliata per loghi, screenshot e grafica ricca di testo: gli artefatti si vedono.

“lossy compression may be less effective with imagery containing sharp edges such as line art, similarly stark details, or text.”

PNG — lossless, trasparenza, grafica e screenshot

Solo lossless con trasparenza alpha completa. PNG è la scelta giusta quando servono bordi nitidi (loghi, screenshot dell’interfaccia, testo nelle immagini) o uno sfondo trasparente e non vuoi affrontare la complessità dei fallback dei formati moderni. Il compromesso è che, per le fotografie, PNG produce file inutilmente enormi senza un guadagno visibile di qualità rispetto a un JPEG/WebP ben regolato: la losslessness è un costo che stai pagando inutilmente su una foto. APNG esiste per le PNG animate, ma è un’estensione distinta e meno supportata, non qualcosa su cui fare affidamento.

WebP — il moderno default sicuro

WebP è il primo formato che sceglierei per la maggior parte delle foto sul web. Il Chrome team di Google spiega chiaramente il motivo: “WebP often has better compression than JPEG, PNG, or GIF, offering both lossy and lossless compression.” E supera il principale limite di JPEG: “WebP also supports alpha channel transparency even when using lossy compression — a feature the JPEG codec doesn’t offer.” Il supporto non è un problema: web.dev lo definisce “a widely supported format that works on all modern browsers” (~96% globale nel 2026). È circa il 25–35% più piccolo di JPEG a qualità simile e WebP lossless è circa il 26% più piccolo di PNG. Se devi convertire una sola cosa, converti le tue foto in WebP.

“WebP also supports alpha channel transparency even when using lossy compression — a feature the JPEG codec doesn’t offer.”

AVIF — la compressione migliore, con compromessi reali

AVIF vince sulla compressione pura. Secondo web.dev, “AVIF supports both lossy and lossless compression, and tests have shown greater than 50% savings when compared to JPEG in some cases,” oltre a “Wide Color Gamut (WCG) and High Dynamic Range (HDR) features.” Nel 2026 il suo supporto browser è intorno al ~94% globale: Chrome (dal 2020), Firefox (2021), Safari (16.4+, dal 2023) ed Edge (121+, gennaio 2024) lo visualizzano tutti. È quindi pronto per la produzione, con un fallback.

“AVIF supports both lossy and lossless compression, and tests have shown greater than 50% savings when compared to JPEG in some cases,”

“Wide Color Gamut (WCG) and High Dynamic Range (HDR) features.”

Ma «compressione migliore» non è l’unica variabile, e parlare onestamente dei costi di AVIF è ciò che distingue una guida utile da un articolo superficiale:

• La codifica richiede molta CPU. AVIF è lento da produrre, un aspetto importante per librerie multimediali grandi e pipeline CMS che ricodificano migliaia di risorse.
• Nessun rendering progressivo. Secondo MDN, un AVIF deve essere scaricato completamente prima di essere visualizzato, a differenza di un JPEG progressivo che prima mostra una versione a bassa risoluzione. Su una connessione lenta può sembrare peggiore nonostante il file più piccolo.
• Gli strumenti per AVIF animati sono immaturi. Il formato supporta l’animazione (a volte chiamata AVIS) e Chrome, Edge e Safari 16.4+ possono riprodurla, ma nel 2026 Firefox non può ancora farlo e gli strumenti di produzione sono meno maturi di quelli per le animazioni GIF/WebP.

SVG — grafica vettoriale, icone, loghi e diagrammi

SVG è un animale diverso: è vettoriale, descritto con la matematica invece che con una griglia di pixel, quindi si ridimensiona a qualsiasi grandezza senza alcuna perdita di qualità e resta piccolo per le forme semplici. La regola pratica di web.dev è questa: gli SVG sono “most useful in cases where the image’s contents are line art, diagrams and charts, and other cases where there aren’t fine photographic details.” Loghi, icone e diagrammi appartengono a SVG, senza discussioni. Non usarlo per le fotografie: non è stato progettato per loro.

“most useful in cases where the image’s contents are line art, diagrams and charts, and other cases where there aren’t fine photographic details.”

C’è un elemento che rende SVG davvero diverso dagli altri cinque formati qui presenti: è XML, non dati di pixel, e secondo il riferimento ufficiale di MDN un file SVG può contenere script e riferimenti a risorse esterne; MDN nota esplicitamente che “there are additional restrictions when SVG is used” come semplice immagine (tramite <img> o CSS background-image) rispetto all’inserimento inline o tramite <iframe>/<object>. Questa restrizione esiste perché un SVG caricato nel modo ordinario delle «immagini» è isolato dall’esecuzione di script o dal recupero di risorse esterne, proprio per chiudere una via XSS. Se accetti upload SVG dagli utenti (una libreria di icone o un modulo per caricare loghi), sanificali prima di servirli: rimuovi i tag <script> e i riferimenti esterni, come faresti con qualsiasi altro markup fornito dagli utenti, non come faresti con un JPEG.

“there are additional restrictions when SVG is used”

GIF — animazione legacy, quando è ancora la scelta giusta

GIF usa una compressione LZW lossless limitata a una tavolozza di 256 colori, con una trasparenza solo binaria (on/off). È il formato storico per le animazioni e, per qualsiasi cosa non banale, è stato superato da WebP/AVIF animati (o, meglio ancora, da un vero video). Il suo unico vantaggio rimasto è la compatibilità universale: se ti serve un’animazione semplice che funzioni ovunque senza alcuna logica di fallback, GIF resta la scelta dal minimo comune denomatore. Altrimenti, scegli WebP animato.

Qualunque formato di animazione usi, considera la semantica separatamente dalla scelta del formato: una GIF o immagine animata in loop che trasmette informazioni deve avere un alt text che descriva ciò che mostra, proprio come un’immagine statica, mentre un loop puramente decorativo va contrassegnato come tale anziché essere letto come contenuto da uno screen reader. Nessuno dei due aspetti riguarda la compatibilità del formato: valgono sia che tu distribuisca GIF, WebP animato o AVIF animato.

Quale formato dovresti usare davvero?

Abbina il formato al contenuto, non a «quale sia il più nuovo». La scheda dell’albero decisionale lo illustra in forma di flusso, ma la versione breve è questa:

• Fotografie → WebP (default sicuro), oppure AVIF con un fallback JPEG quando vuoi la massima compressione.
• Loghi, icone, diagrammi, line art → SVG.
• Screenshot, grafica con bordi netti o testo, tutto ciò che richiede trasparenza senza la complessità dei fallback → PNG (o WebP lossless).
• Animazione semplice → WebP/AVIF animato dove supportato; GIF solo come fallback universale. (Per qualcosa di più ricco, usa un video.)

Una precisazione onesta su tutte le percentuali di compressione di questo articolo: sono valori rappresentativi dei test di web.dev e caniuse, non una garanzia per le tue immagini. Il risparmio dipende dal contenuto dell’immagine sorgente (una foto ricca di dettagli si comprime in modo diverso da una grafica a colori piatti) e dalle impostazioni dell’encoder che usi. Considera «WebP è ~25–35% più piccolo» e «AVIF è ~50% più piccolo» come un’aspettativa di partenza, poi confronta le tue codifiche con le impostazioni di qualità che distribuirai davvero: è l’unico modo per sapere quanto ti offre un determinato cambio di formato sulle tue pagine.

Implementare i formati moderni in sicurezza — il fallback <picture>

Non servire i formati moderni da soli: servili con dei fallback. Il modello pulito è un elemento <picture> che propone prima AVIF, poi WebP e termina con un semplice <img src> che punta a un JPEG o PNG:

<picture>
  <source srcset="hero.avif" type="image/avif" />
  <source srcset="hero.webp" type="image/webp" />
  <img src="hero.jpg" alt="Descriptive alt text" width="1200" height="800" />
</picture>

Il browser sceglie il primo formato che comprende; i browser più vecchi e alcuni crawler passano al src. Due cose da ricordare: quel fallback src è l’URL che Google indicizza davvero per la ricerca di immagini (Google analizza l’<img> anche quando è annidato in <picture>, ma non indicizza background-image CSS), e qui la scelta del formato lascia il posto al lavoro di implementazione più ampio: dimensionamento, impostazioni di compressione, srcset/sizes, lazy loading e fetchpriority sull’immagine LCP. Questa guida completa non viene duplicata qui: si trova in Image Optimization, mentre la gestione responsive (srcset, sizes, art direction) si trova in Responsive Images.

Cosa supportano ufficialmente Google e Bing

L’elenco dei formati supportati da Google e la svolta AVIF dell’agosto 2024

L’elenco supportato da Google Search è esplicito: “Google Search supports images referenced in the src attribute of img in the following file formats: BMP, GIF, JPEG, PNG, WebP, SVG, and AVIF” (oltre ai Data URI Base64). AVIF è l’aggiunta più recente e la data è importante: Google non supportava affatto AVIF nella Ricerca fino al 30 agosto 2024, quando ha annunciato che “AVIF is now a supported file type in Google Search” e che “you don’t need to do anything special to have your AVIF files indexed.” Prima di quella data AVIF non era nell’elenco e, secondo la copertura di terze parti, l’uso di miniature AVIF poteva perfino far interrompere del tutto a Google l’indicizzazione dei video. È una linea temporale recente e verificabile: qualsiasi guida concorrente scritta prima della metà del 2024 e mai aggiornata fornisce indicazioni obsolete sulla sicurezza di AVIF.

“AVIF is now a supported file type in Google Search”

“you don’t need to do anything special to have your AVIF files indexed.”

Nota il modo in cui Google ha formulato l’annuncio: semplicemente “ora possiamo elaborare questo tipo di file”, mai come il lancio di un segnale di ranking. È lo stesso framing non legato al ranking del resto dell’elenco dei formati, ed è per questo che il titolo di Search Engine Journal “Google’s New Support For AVIF Images May Boost SEO” è un buon esempio da trattare con cautela: il corpo instrada correttamente il «boost» interamente attraverso dimensioni del file → Core Web Vitals, ma il titolo mostra esattamente come il mito formato=ranking venga amplificato dalla stampa di settore in buona fede.

“we can now process this file type,“

Le indicazioni pubbliche (limitate) di Bing

Bing non pubblica una guida di confronto tra formati come quella di Google. Le sue linee guida generali per i webmaster considerano la velocità della pagina, compreso il peso delle immagini, ma non esiste una pagina tecnica di Bing che dica «usa WebP/AVIF», e non ne inventerò una. Bing indicizza e mostra senza problemi immagini JPEG/PNG/WebP/GIF in Bing Images; in genere si presume che il supporto del crawler ai formati moderni segua quello dei browser basati su Chromium, ma, a differenza di Google, non è documentato separatamente. È la stessa lacuna onesta che segnalo in Image Optimization: dichiarata chiaramente invece di essere nascosta.

Miti comuni sui formati immagine e la SEO

• «Passare a WebP/AVIF migliora il ranking». No: Mueller lo ha detto direttamente, nessun vantaggio SEO per AVIF; WebP è «fine», non «migliore». Il beneficio è indiretto, tramite dimensioni del file → velocità → Core Web Vitals.
• «AVIF è sempre il migliore perché comprime meglio». Esagerato. AVIF richiede molta CPU per la codifica, non ha rendering progressivo e non è stato supportato da Google Search fino all’agosto 2024. La compressione migliore non è l’unica variabile.
• «PNG è sempre la scelta sicura e di alta qualità». Falso come regola generale. PNG è adatto a grafica/trasparenza/testo, ma produce file gonfi per le fotografie, peggiorando la velocità senza un guadagno visibile.
• «Non serve più un fallback: il supporto è praticamente universale». È quasi vero per WebP; per AVIF vale ancora la pena usare un fallback <picture> per via del divario reale (anche se piccolo) di circa il 6%, oltre ai casi limite di crawler e dispositivi vecchi. Google raccomanda esplicitamente questo modello di fallback.
• «Google penalizza i formati vecchi come JPEG/PNG». Falso: JPEG, PNG, GIF e BMP restano pienamente supportati. Non c’è una penalizzazione, solo un’opportunità di velocità persa rispetto ai formati moderni.
• «AVIF non può essere animato / WebP non supporta la trasparenza». Entrambe false. WebP supporta la trasparenza alpha anche in modalità lossy; AVIF supporta le animazioni (Safari 16.4+, Chrome, Edge, anche se nel 2026 non ancora Firefox).
• «AVIF non è pronto: è ancora un mondo solo WebP». Obsoleto. AVIF ha un supporto globale di circa ~94% ed è indicizzabile da Google Search dall’agosto 2024. Trattalo come pronto per la produzione con fallback, non come sperimentale.

“Switching to WebP/AVIF boosts rankings.”

“AVIF is always best because it compresses best.”

“PNG is always the safe, high-quality choice.”

“You don’t need a fallback anymore — support is basically universal.”

“Google penalizes older formats like JPEG/PNG.”

“AVIF can’t animate / WebP can’t do transparency.”

“AVIF isn’t ready — it’s still a WebP-only world.”

Dove si colloca questo articolo

Questo articolo è l’analisi approfondita del confronto tra formati all’interno del cluster Image SEO: è la sede canonica della matrice a sei formati e del chiarimento del mito sul ranking. I due articoli fratelli svolgono i compiti adjacenti: Image Optimization è la guida pratica all’implementazione (LCP, fetchpriority, lazy loading, compressione, dimensionamento), mentre Responsive Images copre la meccanica di srcset/sizes/<picture> per servire l’immagine della dimensione giusta in base al dispositivo. Il vantaggio prestazionale di scegliere correttamente il formato è davvero una storia di Core Web Vitals con un’immagine al posto del cappello.

Riepilogo AI

Una sintesi della versione Avanzata:

• Il formato non è un fattore di ranking. John Mueller ha confermato che AVIF non offre alcun vantaggio SEO e che WebP è solo “fine for Image Search”: formulazione neutra, non «migliore». La documentazione di Google sulle immagini non collega mai il formato al ranking.
• La vera catena: formato → dimensioni del file → velocità della pagina → LCP / Core Web Vitals → segnali di esperienza della pagina. Il formato si trova diversi passaggi prima: ecco perché non è un fattore di ranking autonomo.
• Dati sui sei formati (2026): JPEG (lossy, nessuna trasparenza, fallback universale); PNG (lossless, alpha completa, grafica/screenshot); WebP (entrambe le compressioni, alpha anche in modalità lossy, supporto ~96%, ~25–35% più piccolo di JPEG: il default sicuro); AVIF (migliore compressione, ~50% più piccolo di JPEG, supporto ~94%, ma codifica che richiede molta CPU, nessun rendering progressivo, animazioni non ancora in Firefox); SVG (vettoriale: loghi/icone/diagrammi); GIF (animazione legacy a 256 colori, solo fallback universale).
• Scegli in base al tipo di contenuto: foto → WebP (oppure AVIF + fallback); loghi/icone → SVG; screenshot/trasparenza/testo → PNG o WebP lossless; animazione semplice → WebP/AVIF animato, GIF come fallback universale.
• Servi con fallback: <picture> (AVIF → WebP → JPEG/PNG src). Il fallback src è l’URL che Google indicizza; Google indicizza <img> (anche dentro <picture>), non gli sfondi CSS.
• Supporto ufficiale: Google supporta BMP, GIF, JPEG, PNG, WebP, SVG, AVIF; AVIF è stato aggiunto il 30 agosto 2024 (prima poteva interrompere l’indicizzazione dei video). Bing non ha una guida di confronto tra formati: non inventarne una.
• Miti sfatati: formato ≠ vantaggio di ranking; AVIF ≠ sempre migliore; PNG ≠ sempre sicuro; «non serve un fallback» ≠ vero per AVIF; i formati vecchi non vengono penalizzati; WebP supporta la trasparenza e AVIF le animazioni.
• Ambito: questa è l’analisi approfondita dei formati; la guida pratica LCP/fetchpriority/ lazy loading si trova in Image Optimization, mentre la meccanica responsive è in Responsive Images.

Documentazione ufficiale

Documentazione e materiale di riferimento da fonti primarie.

Google

• Best practice per Google Immagini — l’elenco dei formati supportati (BMP, GIF, JPEG, PNG, WebP, SVG, AVIF), la regola di indicizzazione <img> rispetto allo sfondo CSS e la nota sulla corrispondenza tra estensione e tipo di file. Non contiene alcuna affermazione sul ranking basata sul formato.
• Supporto di AVIF in Google Search (30 agosto 2024) — l’annuncio che AVIF è ora supportato in Search, Immagini, Discover e News, senza bisogno di un’implementazione speciale.
• Prestazioni delle immagini (web.dev, Chrome team di Google) — la meccanica dei formati: compressione WebP/AVIF, alpha in modalità lossy, WCG/HDR, distinzione lossy/lossless e motivo per cui JPEG fatica con bordi netti e testo.

Riferimento (base per l’accuratezza)

• Guida ai tipi e ai formati dei file immagine (MDN Web Docs) — la specifica rigorosa formato per formato: tipi MIME, compressione, trasparenza, animazione, supporto del rendering progressivo e casi d’uso.
• caniuse.com — AVIF e caniuse.com — WebP — le tabelle, aggiornate, del supporto browser versione per versione e della percentuale globale. Ricontrollale prima di citare qualsiasi valore di supporto: cambiano continuamente.

Bing / Microsoft

• Linee guida per i webmaster di Bing — indicazioni generali sulla velocità delle pagine; Bing non pubblica una pagina tecnica specifica sul confronto tra formati.

Citazioni dalla fonte

Dichiarazioni pubbliche di Google. Quando una pagina rende disponibile il testo, il link profondo porta direttamente al passaggio citato.

Documentazione Google — formati supportati e inquadramento delle prestazioni

• “Google Search supports images referenced in the src attribute of img in the following file formats: BMP, GIF, JPEG, PNG, WebP, SVG, and AVIF.” Vai alla citazione
• “images are often the largest contributor to overall page size, which can make pages slow and expensive to load.” Vai alla citazione

web.dev (Chrome team di Google) — meccanica dei formati

• WebP: “WebP often has better compression than JPEG, PNG, or GIF, offering both lossy and lossless compression.” Vai alla citazione
• Vantaggio di trasparenza di WebP: “WebP also supports alpha channel transparency even when using lossy compression—a feature the JPEG codec doesn’t offer.”
• AVIF: “AVIF supports both lossy and lossless compression, and tests have shown greater than 50% savings when compared to JPEG in some cases.”
• Punto debole di JPEG: “lossy compression may be less effective with imagery containing sharp edges such as line art, similarly stark details, or text.”
• Uso ideale di SVG: “Because SVG is a vector image format, they’re most useful in cases where the image’s contents are line art, diagrams and charts, and other cases where there aren’t fine photographic details.”

Blog Google Search Central — supporto AVIF (30 agosto 2024)

• “We’re happy to announce that AVIF is now a supported file type in Google Search, for Google Images as well as any place that uses images in Google Search.” Annuncio
• “You don’t need to do anything special to have your AVIF files indexed by Google.”

John Mueller, Google — il formato non offre alcun vantaggio di ranking

• Su AVIF: non c’è alcun «SEO boost» nell’usare file AVIF; il vantaggio è la riduzione delle dimensioni del file, che può aiutare la velocità della pagina, non una preferenza di ranking. Copertura
• Su WebP: “WebP images are fine for Image Search” — «fine», deliberatamente non «migliore». Copertura
• Sul report «Crawled – currently not indexed» di WebP: è una particolarità generale dei report sulle immagini (le immagini non vengono indicizzate come pagine HTML) e Mueller “doesn’t believe the phenomenon is limited to WebP images.” Copertura SEJ

Quale formato dovrei usare?

Procedi dall’alto verso il basso. Abbina il formato a ciò che è l’immagine, poi aggiungi un fallback se hai scelto un formato moderno.

1. È un logo, un’icona, un diagramma o una line art? → SVG. Si ridimensiona senza perdita di qualità e resta piccolo. Fine.

2. Deve essere animata? → WebP o AVIF animato dove supportato, con GIF come fallback universale per i loop semplici. Per qualcosa di più ricco di un breve loop, usa un video (MP4/WebM), non un formato immagine. Fine.

3. È una fotografia? → WebP è il default sicuro (supporto ~96%, senza fallback strettamente necessario). → Vuoi la massima compressione e puoi aggiungere un fallback? AVIF → WebP → JPEG tramite <picture>. → Ti serve un singolo file universale senza logica di fallback? JPEG.

4. È uno screenshot o una grafica con bordi netti, testo o trasparenza? → PNG (oppure WebP lossless). Gli artefatti lossy di JPEG rovinano bordi netti e testo; PNG li mantiene nitidi e supporta la trasparenza completa.

5. Hai scelto AVIF o WebP per una foto? → Avvolgila in <picture> con i formati inferiori come elementi <source> e un fallback <img src> JPEG/PNG. Quel src è l’URL che Google indicizza.

Riferimento rapido in base alla risposta

Modelli mentali

1. La catena causale — formato → dimensioni del file → velocità → Core Web Vitals. Il formato si trova all’inizio di una catena di quattro passaggi, non alla fine del ranking: la scelta del formato modifica le dimensioni del file → i file più piccoli si caricano più velocemente → caricamenti più rapidi migliorano il Largest Contentful Paint (LCP) → l’LCP alimenta i Core Web Vitals, che sono parte dei segnali di esperienza della pagina usati dai sistemi di ranking. Ridurre tutto a «il formato influenza il ranking» è esattamente il modo in cui il mito si diffonde: il formato è diversi passaggi a monte e, se la pagina non diventa davvero più veloce, nulla cambia a valle. Usa questo modello quando sei tentato di attribuire a un cambio di formato il merito di uno spostamento nel ranking: chiediti quale collegamento della catena si è verificato davvero.

2. Scegli in base al tipo di contenuto, non secondo la regola «vince il più nuovo». Il formato più recente non è automaticamente quello giusto: abbina il formato a ciò che l’immagine è:

• Fotografie → WebP (default sicuro), oppure AVIF con un fallback JPEG per la massima compressione.
• Loghi, icone, diagrammi, line art → SVG.
• Screenshot, bordi netti, testo nelle immagini, trasparenza senza la complessità dei fallback → PNG (oppure WebP lossless).
• Animazione semplice → WebP/AVIF animato dove supportato, GIF solo come fallback universale (animazione più ricca → video).

Passare un’immagine attraverso questo modello prima di ricorrere a «usa AVIF, è il più nuovo» aiuta a intercettare i casi in cui i costi reali di AVIF — codifica che richiede molta CPU, nessun rendering progressivo e nessun supporto in Google Search fino all’agosto 2024 — superano il suo vantaggio in termini di compressione.

Scheda rapida dei formati immagine

I sei formati a colpo d’occhio (2026)

Il modello di fallback <picture>

<picture>
  <source srcset="photo.avif" type="image/avif" />
  <source srcset="photo.webp" type="image/webp" />
  <img src="photo.jpg" alt="…" width="1200" height="800" />
</picture>

Fatti rapidi

• Nessun vantaggio diretto di ranking per WebP/AVIF: il beneficio è velocità → Core Web Vitals.
• Google supporta BMP, GIF, JPEG, PNG, WebP, SVG, AVIF; AVIF è stato aggiunto il 30 agosto 2024.
• Google indicizza <img> (anche dentro <picture>), non background-image CSS.
• Il fallback <img src> è l’URL che Google indicizza.
• WebP supporta la trasparenza alpha anche in modalità lossy; JPEG non può supportare affatto la trasparenza.
• Compromessi di AVIF: codifica che richiede molta CPU, nessun rendering progressivo, animazione non supportata da Firefox (2026).
• SVG è vettoriale: non usarlo mai per le fotografie; non usare mai JPEG per loghi/testo.

Checklist per la scelta del formato

Un rapido controllo per verificare che ogni immagine sia nel formato giusto e venga servita in sicurezza:

• Le fotografie sono WebP (o AVIF con un fallback), non PNG o JPEG sovradimensionati.
• Loghi, icone e diagrammi sono SVG, non raster.
• Screenshot e grafiche con testo nelle immagini sono PNG o WebP lossless, non JPEG (i cui artefatti sfocano bordi netti e testo).
• Tutto ciò che richiede trasparenza usa PNG, WebP o AVIF: mai JPEG.
• I formati moderni (AVIF/WebP) vengono serviti tramite <picture> con un fallback JPEG/PNG <img src>.
• Ogni immagine si trova in un <img> (o <picture>), non in un CSS background-image, se vuoi che compaia nella ricerca immagini.
• Le estensioni dei file corrispondono al tipo effettivo di file (attenzione dopo una conversione in batch a .webp/.avif).
• Nessun formato è stato scelto per ottenere un vantaggio di ranking: l’obiettivo è file più piccoli → LCP più veloce, verificato con un test reale della velocità della pagina, non l’etichetta del formato.
• Le animazioni usano WebP/AVIF animato (o video); GIF solo quando serve la compatibilità universale senza fallback.
• Le ipotesi sul supporto browser sono state ricontrollate su caniuse se stai eliminando un fallback.

Errori da evitare con i formati immagine

Passare a WebP/AVIF aspettandosi un vantaggio di ranking. Perché è sbagliato: John Mueller ha confermato che AVIF non offre alcun vantaggio SEO e che WebP è solo “fine for Image Search”, una formulazione deliberatamente neutra, non «migliore». Il formato non è un segnale di ranking; lo è la velocità che consente. Cosa fare invece: converti per ottenere il vantaggio su dimensioni del file e Core Web Vitals e verifica il risultato con un test reale della velocità della pagina, non con l’etichetta del formato.

Trattare AVIF come sempre migliore perché comprime di più. Perché è sbagliato: la compressione migliore non è l’unica variabile. AVIF richiede molta CPU per la codifica, non ha rendering progressivo (l’immagine deve essere scaricata completamente prima di essere visualizzata) e nel 2026 gli strumenti per AVIF animati non sono ancora supportati da Firefox. Cosa fare invece: usa AVIF con un fallback <picture> quando stai cercando la massima compressione e puoi sostenere il costo della codifica; altrimenti WebP è il default quotidiano più sicuro.

Supporre che PNG sia sempre la scelta sicura e di alta qualità. Perché è sbagliato: PNG è solo lossless, quindi usarlo per le fotografie produce file inutilmente gonfi senza alcun guadagno visibile rispetto a un JPEG/WebP ben regolato: un costo di velocità reale e evitabile. Cosa fare invece: riserva PNG a trasparenza e grafica/screenshot/testo con bordi netti; usa WebP o JPEG per le foto.

Eliminare il fallback perché «ormai il supporto è praticamente universale». Perché è sbagliato: è quasi vero per WebP (~96%), ma AVIF è ancora intorno al ~94% di supporto globale e alcuni dispositivi vecchi e crawler non lo visualizzano: è un divario reale, seppur piccolo. Cosa fare invece: servi i formati moderni tramite un elemento <picture> che termina con un fallback JPEG/PNG <img src>; quel fallback è anche l’URL che Google indicizza.

Credere che i formati vecchi come JPEG o PNG vengano penalizzati. Perché è sbagliato: JPEG, PNG, GIF e BMP restano pienamente supportati da Google Search; non c’è alcuna penalizzazione per usarli, solo un’opportunità di velocità persa rispetto a un file più piccolo in un formato moderno. Cosa fare invece: converti quando il vantaggio sulle dimensioni del file giustifica lo sforzo, ma non trattare il fatto di restare su JPEG/PNG come un rischio di conformità.

Supporre che WebP non supporti la trasparenza o che AVIF non possa essere animato. Perché è sbagliato: entrambe le affermazioni sono false. WebP supporta la trasparenza del canale alpha anche in modalità lossy, cosa che JPEG non può fare affatto, e AVIF supporta l’animazione in Chrome, Edge e Safari 16.4+ (solo non ancora in Firefox). Cosa fare invece: controlla le capacità effettive di ciascun formato (nella tabella dei sei formati della scheda Avanzata) invece di presumere in base all’età del formato.

Considerare AVIF «ancora sperimentale» nel 2026. Perché è sbagliato: è un’idea obsoleta. AVIF è indicizzabile da Google Search dal 30 agosto 2024 e ha un supporto browser globale intorno al ~94%. Cosa fare invece: considera AVIF pronto per la produzione con un fallback, non qualcosa da evitare del tutto.

Mettiti alla prova: formati immagine

Cinque domande rapide sulla scelta dei formati immagine per la SEO. Scegli una risposta per ciascuna, poi controlla.

Risorse che meritano il tuo tempo

I miei articoli correlati

• Image SEO: 12 Actionable Tips for More Organic Traffic — la mia guida Ahrefs dedicata alla SEO delle immagini (formati, compressione, nomi dei file, alt text, sitemap, immagini responsive, dati strutturati, lazy loading).
• Largest Contentful Paint (LCP) — perché l’elemento LCP è di solito un’immagine e come le dimensioni del file determinate dal formato alimentano l’LCP. La catena prestazionale su cui si basa il chiarimento del mito di questo articolo.
• The Beginner’s Guide to Technical SEO — il posto in cui immagini e Core Web Vitals si collocano nel quadro tecnico più ampio.

I miei interventi

• «Image SEO» (webinar Visme, 2021) — il mio intervento dedicato all’ottimizzazione delle immagini per la ricerca, compresi formati e compressione.

“Image SEO”

Ufficiale

• Best practice per Google Immagini — elenco dei formati supportati e meccanica dell’indicizzazione.
• Supporto di AVIF in Google Search (agosto 2024) — l’annuncio del supporto AVIF.
• web.dev — Prestazioni delle immagini (Chrome team di Google) — il riferimento sulla meccanica dei formati alla base della tabella comparativa.

Dal settore

• Image file type and format guide (MDN Web Docs) — la tabella di specifiche più rigorosa sul web per i diversi formati; è la base di accuratezza del confronto tra i sei formati.
• caniuse.com — AVIF / caniuse.com — WebP — tabelle aggiornate, versione per versione, del supporto browser con le percentuali globali correnti.
• Google’s New Support For AVIF Images May Boost SEO (Search Engine Journal, Roger Montti) — utile come caso di studio su come l’inquadramento «formato = vantaggio di ranking» venga amplificato; il corpo instrada correttamente il beneficio attraverso i Core Web Vitals.
• Google’s John Mueller Clarifies WebP Image Indexing Confusion (Search Engine Journal) — perché le immagini WebP compaiono come «Crawled – currently not indexed» e perché non è un problema specifico di WebP.
• Google Search Now Supports AVIF Images (Search Engine Roundtable) — copertura della svolta AVIF e del punto di Mueller sul «no SEO boost».
• AVIF vs. WebP: 4 Key Differences and How to Choose (Cloudinary) — un solido confronto AVIF-WebP orientato all’implementazione.
• r/TechSEO — la community per il debugging dei formati immagine e delle prestazioni.

Cronologia modifiche