Formatos de imagen para SEO: JPEG vs. PNG vs. WebP vs. AVIF
Análisis profundo de la comparación de formatos para el SEO de imágenes: compresión, transparencia, animación y compatibilidad de navegadores en 2026 para JPEG, PNG, WebP, AVIF, SVG y GIF, además del mito desmontado: el formato no mejora el posicionamiento, solo la velocidad.
Idiomas
La elección del formato de imagen (JPEG, PNG, WebP, AVIF, SVG, GIF) no tiene peso directo en el posicionamiento: John Mueller, de Google, ha confirmado que no existe ninguna mejora de SEO por usar WebP o AVIF frente a JPEG/PNG. La ganancia es enteramente indirecta: el formato adecuado reduce el tamaño del archivo, los archivos más pequeños cargan más rápido, las cargas más rápidas mejoran Largest Contentful Paint y Core Web Vitals, y eso es lo que usan realmente los sistemas de posicionamiento. Por tanto, el formato importa enteramente a través de la cadena de velocidad, no por sí mismo. Elige según el tipo de contenido: WebP es la opción moderna segura para fotos (~96 % de compatibilidad, ~25–35 % más pequeño que JPEG); AVIF comprime más (~50 % más pequeño que JPEG, ~94 % de compatibilidad en 2026), pero cuesta más codificar y no tiene renderizado progresivo; PNG para transparencia y gráficos de bordes nítidos; SVG para logotipos e iconos; GIF solo como fallback universal de animación. Sirve los formatos modernos con un fallback <picture>: ese src de fallback es la URL que indexa Google. Este es el análisis profundo de formatos; la guía de implementación está en Image Optimization.
Evidence for this claim Google Search supports BMP, GIF, JPEG, PNG, WebP, SVG, and AVIF image formats when the extension matches the format. Scope: Current Google Images supported-format list. Confidence: high · Verified: Google Search Central: Supported image formats Evidence for this claim Format choice should reflect image characteristics and browser support; modern formats can improve compression but require deliberate encoding and fallbacks where needed. Scope: Current Chrome/web.dev image format guidance. Confidence: high · Verified: web.dev: Choose the right image formatTL;DR — Un formato de imagen es el tipo de archivo en el que guardas una imagen: JPEG, PNG, WebP, AVIF y algunos más. Cambiar a un formato «moderno» como WebP o AVIF no mejorará tu posicionamiento; Google lo ha dicho directamente. Lo que sí hace es reducir el tamaño del archivo, lo que acelera la carga de la página, y es la velocidad la que realmente ayuda. Elige el formato que encaje con la imagen: WebP para la mayoría de las fotos, PNG para logotipos y capturas que necesiten bordes nítidos o transparencia, y SVG para iconos.
Qué es un formato de imagen
Cuando guardas una imagen, la guardas como algo: un .jpg, un .png o un
.webp. Ese es el formato. Cada uno almacena la imagen de una manera ligeramente distinta, y la elección cambia tres aspectos que te importan:
- El tamaño del archivo (un archivo más pequeño carga más rápido).
- Si puede tener un fondo transparente (un logotipo que se coloca sobre cualquier color).
- Si puede tener animación (como un GIF antiguo).
Los motores de búsqueda pueden leer todos los formatos habituales, así que no estás eligiendo uno para «complacer a Google». Estás eligiendo el que mantiene pequeño el archivo sin que la imagen se vea peor.
Los formatos, en términos sencillos
- JPEG: el formato clásico para fotos. Funciona en todas partes. Es bueno para fotografías, pero no admite transparencia.
- PNG: excelente para logotipos, capturas y cualquier imagen con bordes o texto nítidos, y puede tener un fondo transparente. Para fotografías, sus archivos son más grandes que los JPEG.
- WebP: un formato moderno que hace que las fotos sean notablemente más pequeñas que en JPEG y que también admite transparencia. Ahora funciona prácticamente en todos los navegadores. Es la opción segura para el día a día.
- AVIF: el más nuevo y el que genera archivos más pequeños (a menudo la mitad que un JPEG). Una pequeña parte de los visitantes todavía no puede verlo, así que debes combinarlo con una copia JPEG.
- SVG: para logotipos e iconos. Se dibuja con matemáticas, no con píxeles, por lo que conserva una nitidez perfecta en cualquier tamaño y el archivo es pequeño.
- GIF: el antiguo formato de animación. Hoy está bastante desfasado, pero sigue siendo la forma más compatible de mostrar una animación sencilla.
El error que más gente comete
No existe ninguna «mejora» de posicionamiento por usar WebP o AVIF. La gente oye «usa WebP para SEO» y supone que el formato en sí la hace subir en los resultados. No es así: John Mueller, de Google, lo ha dicho claramente más de una vez. El beneficio son archivos más pequeños → páginas más rápidas → mejores puntuaciones de velocidad, y esa velocidad es la que ayuda. Si cambiaste de formato pero la página no se volvió realmente más rápida, no hay ninguna ganancia de SEO que recoger.
El hábito seguro más sencillo: usa WebP para tus fotos, conserva PNG para logotipos y capturas, usa SVG para iconos y no te preocupes demasiado por AVIF salvo que estés exprimiendo hasta el último kilobyte (en cuyo caso, añade un fallback JPEG).
¿Quieres la comparación completa —la tabla de compresión, transparencia, animación y compatibilidad de los seis formatos, las citas exactas de Google y un árbol de decisión para saber qué formato usar en cada caso—? Cambia a la pestaña Avanzado.
Evidence for this claim Google Search supports BMP, GIF, JPEG, PNG, WebP, SVG, and AVIF image formats when the extension matches the format. Scope: Current Google Images supported-format list. Confidence: high · Verified: Google Search Central: Supported image formats Evidence for this claim Format choice should reflect image characteristics and browser support; modern formats can improve compression but require deliberate encoding and fallbacks where needed. Scope: Current Chrome/web.dev image format guidance. Confidence: high · Verified: web.dev: Choose the right image formatTL;DR — El formato de imagen no es un factor de posicionamiento. John Mueller, de Google, ha confirmado que no existe ninguna mejora de SEO por usar AVIF, y que WebP solo es “fine for Image Search”; es un lenguaje deliberadamente neutro, no significa «mejor». La cadena real es: formato → tamaño del archivo → velocidad de la página → Largest Contentful Paint / Core Web Vitals → las señales de experiencia de página que usan realmente los sistemas de posicionamiento. El formato está varios pasos antes. Elige por tipo de contenido, no porque «lo nuevo siempre gana»: WebP es la opción segura para fotos (~96 % de compatibilidad, ~25–35 % más pequeño que JPEG y admite transparencia alfa incluso en modo con pérdida; JPEG no); AVIF comprime más (~50 % más pequeño que JPEG, ~94 % de compatibilidad en 2026), pero exige más CPU para codificar y no tiene renderizado progresivo; PNG para transparencia y gráficos o texto con bordes nítidos; SVG para logotipos, iconos y diagramas; GIF solo como fallback universal para animaciones. Sirve los formatos modernos mediante
<picture>(AVIF → WebP → JPEG/PNGsrc): elsrcde fallback es la URL que indexa Google. Este es el análisis profundo de formatos; la implementación de LCP/fetchpriority/carga diferida está en Image Optimization.
¿Afecta realmente el formato de imagen al SEO?
Empieza desmontando el mito, porque es la razón por la que la mayoría de la gente llega a esta página.
El formato no es un factor de posicionamiento. John Mueller lo ha dicho al menos de tres formas distintas y en momentos independientes, pero el hilo conductor siempre es el mismo: el formato no es una señal; lo es la velocidad que permite. Tras el anuncio de Google de agosto de 2024 de que AVIF ya era compatible con Search, Mueller confirmó que no hay ninguna «mejora de SEO» por usar AVIF frente a otros formatos compatibles (la cobertura de Search Engine Roundtable); el beneficio es reducir el tamaño del archivo, lo que puede ayudar a la velocidad de la página, no crear una preferencia de posicionamiento por el contenedor. Años antes, con WebP, eligió sus palabras con el mismo cuidado: “WebP images are fine for Image Search” (traducción) «Las imágenes WebP sirven perfectamente para la búsqueda de imágenes» (SE Roundtable); dijo que sirven, no que sean mejores ni preferidas. Y cuando las imágenes WebP empezaron a aparecer en el informe «Rastreada: actualmente sin indexar» de Search Console, Mueller aclaró que se trata de una peculiaridad general de los informes de imágenes (las imágenes no se indexan como páginas HTML), no de una desventaja específica de WebP: “he doesn’t believe the phenomenon is limited to WebP images” (traducción) «no cree que el fenómeno se limite a las imágenes WebP» (el artículo de Search Engine Journal).
El documento principal de Google sobre SEO de imágenes también lo confirma por omisión: enumera los formatos compatibles, te dirige a PageSpeed Insights para el rendimiento y nunca relaciona la elección del formato con un factor de posicionamiento. Esa ausencia es una prueba en sí misma.
Este es el mismo mito que desmonto en el nivel central de Image SEO y en la guía de implementación, Image Optimization, y merece expresarse con precisión. No digas «el formato no importa». Di «el formato no importa directamente: importa por completo a través de la cadena de velocidad y Core Web Vitals».
La cadena real: formato → tamaño del archivo → velocidad → Core Web Vitals
Esta es la secuencia causal, paso a paso, porque precisamente colapsarla es lo que propaga el mito:
- La elección del formato cambia el tamaño del archivo. Es la palanca individual más importante sobre el peso de una imagen.
- Los archivos más pequeños cargan más rápido. El propio documento de imágenes de Google señala que las imágenes son “often the largest contributor to overall page size, which can make pages slow and expensive to load.” (traducción) «a menudo el mayor componente del tamaño total de una página, lo que puede hacer que las páginas sean lentas y costosas de cargar».
- Las cargas más rápidas mejoran Largest Contentful Paint (LCP). La imagen principal suele ser el elemento LCP, así que su peso mueve directamente la métrica. (Lo explico a fondo en mi guía sobre Largest Contentful Paint, en la parte que explica por qué LCP suele ser una imagen).
- LCP alimenta Core Web Vitals, que sí forma parte de las señales de experiencia de página que usan los sistemas de posicionamiento de Google.
El formato está al principio de esa cadena, varios pasos antes de cualquier aspecto relacionado con el posicionamiento. Esa es precisamente la razón por la que no es un factor de posicionamiento por sí solo: entre ambos puntos tienen que salir bien demasiadas cosas, y si la página no se vuelve realmente más rápida, nada cambia después.
Comparación de los seis formatos
La mayoría de las «guías de 2026» de la competencia solo cubren JPEG/PNG/WebP/AVIF y presentan discretamente mal las cifras de compatibilidad de los navegadores (he visto citar AVIF en «~74 %», una cifra desactualizada desde hace años). Aquí tienes la matriz completa de seis formatos con cifras actuales.
| Formato | Compresión | Transparencia | Animación | Compatibilidad de navegadores (2026) | Uso habitual |
|---|---|---|---|---|---|
| JPEG | Solo con pérdida | No | No | Universal | Fotografías; el fallback universal |
| PNG | Solo sin pérdida | Sí (alfa completa) | No (APNG es una extensión independiente y menos compatible) | Universal | Capturas, logotipos, gráficos de bordes nítidos, texto en imágenes y cualquier caso que necesite transparencia sin el riesgo de un formato moderno |
| WebP | Con y sin pérdida | Sí (alfa incluso en modo con pérdida) | Sí | ~96 % global; universal desde ~2020 | Opción moderna segura para fotos; ~25–35 % más pequeño que JPEG; WebP sin pérdida ~26 % más pequeño que PNG |
| AVIF | Con y sin pérdida | Sí | Sí (Chrome/Edge/Safari 16.4+; todavía no Firefox) | ~94 % global | Máxima compresión con fallback; ~50 % más pequeño que JPEG; admite HDR / gama cromática amplia |
| SVG | N/A (vectorial, no rasterizado) | Sí | Sí (mediante CSS/SMIL/JS) | Universal | Logotipos, iconos, diagramas y arte lineal: escala sin perder calidad |
| GIF | Sin pérdida (LZW), máximo 256 colores | Sí (solo binaria, sin alfa parcial) | Sí | Universal | Animaciones sencillas heredadas; el fallback de animación más compatible |
JPEG: el fallback fotográfico universal
Solo con pérdida, sin transparencia ni animación, y compatible literalmente en todas partes. JPEG sigue siendo el fallback correcto al final de un elemento <picture> y una opción perfectamente válida para fotografías cuando no las conviertes a un formato moderno. Su punto débil está incorporado en el funcionamiento de la compresión con pérdida: según el equipo de Chrome de Google en web.dev, “lossy compression may be less effective with imagery containing sharp edges such as line art, similarly stark details, or text.” (traducción) «la compresión con pérdida puede ser menos eficaz con imágenes que contengan bordes definidos, como ilustraciones lineales, detalles igualmente marcados o texto». Precisamente por eso JPEG es una mala elección para logotipos, capturas y gráficos con mucho texto: se ven los artefactos.
PNG: sin pérdida, transparencia, gráficos y capturas
Sin pérdida y con transparencia alfa completa. PNG es adecuado cuando necesitas bordes nítidos (logotipos, capturas de interfaz, texto en imágenes) o un fondo transparente y no quieres asumir la complejidad de los fallbacks de los formatos modernos. El coste: para las fotografías, PNG produce archivos innecesariamente enormes sin una mejora visible de calidad frente a un JPEG/WebP bien ajustado; estás pagando la ausencia de pérdida para nada en una foto. (APNG sí existe para PNG animado, pero es una extensión distinta y menos compatible; no conviene apoyarse en ella.)
WebP: la opción moderna segura
WebP es el formato que elegiría primero para la mayoría de las fotos web. El equipo de Chrome de Google explica directamente por qué: “WebP often has better compression than JPEG, PNG, or GIF, offering both lossy and lossless compression.” (traducción) «WebP suele comprimir mejor que JPEG, PNG o GIF y ofrece compresión tanto con pérdida como sin pérdida». También elimina la principal limitación de JPEG: “WebP also supports alpha channel transparency even when using lossy compression — a feature the JPEG codec doesn’t offer.” (traducción) «WebP también admite transparencia mediante canal alfa incluso con compresión con pérdida, una función que el códec JPEG no ofrece». La compatibilidad no supone un problema: web.dev lo llama “a widely supported format that works on all modern browsers” (traducción) «un formato ampliamente compatible que funciona en todos los navegadores modernos» (~96 % global en 2026). Es aproximadamente un 25–35 % más pequeño que JPEG con una calidad similar, y WebP sin pérdida ocupa ~26 % menos que PNG. Si vas a convertir una sola cosa, convierte tus fotos a WebP.
AVIF: la mejor compresión, con costes reales
AVIF gana en compresión bruta. Según web.dev, “AVIF supports both lossy and lossless compression, and tests have shown greater than 50% savings when compared to JPEG in some cases,” (traducción) «AVIF admite compresión con y sin pérdida, y las pruebas han mostrado ahorros superiores al 50 % frente a JPEG en algunos casos», además de ofrecer “Wide Color Gamut (WCG) and High Dynamic Range (HDR) features.” (traducción) «funciones de amplia gama de colores (WCG) y alto rango dinámico (HDR)». En 2026, su compatibilidad de navegadores ronda el ~94 % global: Chrome (desde 2020), Firefox (2021), Safari (16.4+, desde 2023) y Edge (121+, enero de 2024) lo muestran. Está listo para producción, con un fallback.
Pero «la mejor compresión» no es la única variable, y ser sincero sobre los costes de AVIF es lo que separa una guía útil de una lista superficial:
- La codificación exige mucha CPU. AVIF tarda en producirse, algo importante para grandes bibliotecas multimedia y pipelines de CMS que vuelven a codificar miles de recursos.
- No hay renderizado progresivo. Según MDN, un AVIF debe descargarse por completo antes de mostrarse, a diferencia de un JPEG progresivo que primero pinta una versión de baja resolución. En una conexión lenta puede sentirse peor pese a que el archivo sea más pequeño.
- Las herramientas para AVIF animado aún están inmaduras. El formato admite animación (a veces llamada AVIS), y Chrome, Edge y Safari 16.4+ pueden reproducirla, pero Firefox todavía no puede hacerlo en 2026, y las herramientas de producción van por detrás de las de GIF/WebP animados.
SVG: gráficos vectoriales, iconos, logotipos y diagramas
SVG es distinto: es vectorial, se describe con matemáticas en lugar de una cuadrícula de píxeles, así que escala a cualquier tamaño sin perder calidad y sigue siendo pequeño para formas sencillas. La regla práctica de web.dev es que los SVG son “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.” (traducción) «especialmente útiles cuando la imagen contiene ilustraciones lineales, diagramas, gráficos u otros elementos sin detalles fotográficos finos». Los logotipos, iconos y diagramas pertenecen a SVG, sin más. No lo uses para fotografías: no está diseñado para ellas.
Hay algo que hace que SVG sea realmente distinto de los otros cinco formatos: es XML, no datos de píxeles, y según la referencia de MDN un archivo SVG puede contener scripts y referenciar recursos externos. MDN señala específicamente que “there are additional restrictions when SVG is used” (traducción) «se aplican restricciones adicionales cuando se usa SVG» como una imagen normal (mediante <img> o CSS background-image) frente a su inserción en línea o mediante un <iframe>/<object>. Esa restricción existe porque un SVG cargado como una «imagen» normal está aislado para impedir que ejecute scripts o recupere recursos externos, precisamente para cerrar un vector XSS. Si aceptas cargas SVG de usuarios (una biblioteca de iconos o un formulario para subir logotipos), sanitízalas antes de servirlas: elimina las etiquetas <script> y las referencias externas, igual que tratarías cualquier otro marcado proporcionado por un usuario, no como tratarías un JPEG.
GIF: animación heredada, cuando sigue siendo la opción correcta
GIF usa compresión LZW sin pérdida, limitada a una paleta de 256 colores, con transparencia únicamente binaria (activada o desactivada). Es el formato histórico de animación y, para cualquier cosa no trivial, ha sido sustituido por WebP/AVIF animados (o, mejor aún, vídeo). Su única ventaja restante es la compatibilidad universal: si necesitas que una animación sencilla se reproduzca en todas partes sin ninguna lógica de fallback, GIF sigue siendo el mínimo común denominador. En los demás casos, elige WebP animado.
Uses el formato de animación que uses, trata la semántica por separado de la decisión de formato: un GIF o una imagen animada en bucle que transmita información necesita texto alternativo que describa lo que muestra, igual que una imagen estática, y un bucle puramente decorativo debe marcarse como tal en lugar de leerse como contenido mediante un lector de pantalla. Ninguna de esas dos cuestiones depende de la compatibilidad del formato: se aplican tanto si sirves GIF como WebP o AVIF animados.
¿Qué formato deberías usar realmente?
Haz coincidir el formato con el contenido, no con «cuál es el más nuevo». La pestaña del árbol de decisión lo explica como un flujo, pero esta es la versión breve:
- Fotografías → WebP (opción segura) o AVIF con fallback JPEG si quieres la máxima compresión.
- Logotipos, iconos, diagramas y arte lineal → SVG.
- Capturas, gráficos con bordes o texto nítidos y cualquier imagen que necesite transparencia sin la complejidad de un fallback → PNG (o WebP sin pérdida).
- Animación sencilla → WebP/AVIF animado cuando sea compatible; GIF solo como fallback universal. (Para cualquier cosa más rica, usa vídeo.)
Una salvedad honesta sobre todos los porcentajes de compresión de este artículo: son cifras representativas de las pruebas de web.dev y caniuse, no una garantía para tus imágenes. El ahorro depende del contenido de la imagen original (una foto recargada se comprime de forma distinta que un gráfico de color plano) y de los ajustes del codificador que uses. Trata «WebP es ~25–35 % más pequeño» y «AVIF es ~50 % más pequeño» como una expectativa inicial y compara después tus propias codificaciones con los ajustes de calidad que realmente vayas a publicar: es la única forma de saber qué consigue un cambio de formato concreto en tus páginas.
Implementación segura de formatos modernos: el fallback de <picture>
No sirvas formatos modernos solos: sírvelos con fallbacks. El patrón limpio es un elemento <picture> que ofrece primero AVIF, después WebP y termina en un <img src> normal que apunte 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>El navegador elige el primer formato que entiende; los navegadores antiguos y algunos rastreadores llegan al src. Hay dos cosas que conviene interiorizar: ese src de fallback es la URL que Google indexa realmente para la búsqueda de imágenes (Google analiza el <img> incluso cuando está dentro de <picture>, pero no indexa background-image de CSS), y aquí es donde la elección del formato da paso al trabajo de implementación más amplio: dimensiones, ajustes de compresión, srcset/sizes, carga diferida y fetchpriority en la imagen LCP. Esa guía completa no se duplica aquí: está en Image Optimization, y la mecánica de servicio adaptativo (srcset, sizes y dirección artística) está en Responsive Images.
Compatibilidad oficial de Google y Bing
Lista de formatos compatibles de Google y el hito de AVIF de agosto de 2024
La lista de formatos compatibles de Google Search es explícita: “Google Search supports images referenced in the src attribute of img in the following file formats: BMP, GIF, JPEG, PNG, WebP, SVG, and AVIF” (traducción) «Google Search admite imágenes referenciadas en el atributo src de img en los formatos BMP, GIF, JPEG, PNG, WebP, SVG y AVIF» (además de los URI de datos Base64). AVIF es la incorporación más reciente, y la fecha importa: Google no admitió AVIF en Search en absoluto hasta el 30 de agosto de 2024, cuando anunció que “AVIF is now a supported file type in Google Search” (traducción) «AVIF es ahora un tipo de archivo compatible con Google Search» y que “you don’t need to do anything special to have your AVIF files indexed.” (traducción) «no necesitas hacer nada especial para que se indexen tus archivos AVIF». Antes de esa fecha, AVIF no estaba en la lista y, según la cobertura de terceros, usar miniaturas AVIF podía incluso hacer que Google cancelara por completo la indexación de vídeos. Es una línea temporal realmente reciente y fechable: cualquier guía de la competencia escrita antes de mediados de 2024 y nunca actualizada ofrece consejos obsoletos sobre la seguridad de AVIF.
Observa cómo presentó Google el anuncio: únicamente como “we can now process this file type,” (traducción) «ahora podemos procesar este tipo de archivo», nunca como el lanzamiento de una señal de posicionamiento. Es el mismo encuadre no relacionado con el posicionamiento que aparece en el resto de la lista de formatos, y por eso el titular de Search Engine Journal «El nuevo soporte de Google para imágenes AVIF podría mejorar el SEO» es un buen ejemplo de advertencia: el cuerpo dirige correctamente la «mejora» por completo a través de tamaño del archivo → Core Web Vitals, pero el titular es exactamente la forma en que la prensa del sector, aunque tenga buenas intenciones, amplifica el mito de que formato equivale a posicionamiento.
La orientación pública (limitada) de Bing
Bing no publica un documento comparativo formato por formato como el de Google. Sus directrices generales para webmasters consideran la velocidad de la página —incluido el peso de las imágenes—, pero no existe una página técnica específica de Bing que diga «usa WebP/AVIF», y no voy a inventarla. Bing indexa y muestra imágenes JPEG/PNG/WebP/GIF en Bing Images sin problemas; en general se supone que la compatibilidad de su rastreador con los formatos modernos sigue la de los navegadores cercanos a Chromium, pero, a diferencia de Google, no está documentada por separado. Este es el mismo vacío honesto que señalo en Image Optimization: lo expreso claramente en lugar de ocultarlo.
Mitos comunes sobre formatos de imagen y SEO
- «Cambiar a WebP/AVIF mejora el posicionamiento». No: Mueller lo ha dicho directamente: no hay mejora de SEO por AVIF; WebP está «fine», no es «better». El beneficio es indirecto, mediante tamaño del archivo → velocidad → Core Web Vitals.
- «AVIF siempre es mejor porque comprime mejor». Es una exageración. AVIF exige mucha CPU para codificar, no tiene renderizado progresivo y Google Search no lo admitió hasta agosto de 2024. La mejor compresión no es la única variable.
- «PNG siempre es la opción segura y de alta calidad». Falso como regla general. PNG es adecuado para gráficos, transparencia y texto, pero genera archivos enormes para fotografías y perjudica la velocidad de carga sin una ganancia visible.
- «Ya no necesitas un fallback: la compatibilidad es prácticamente universal». Es mayormente cierto para WebP, pero sigue mereciendo la pena usar un fallback
<picture>para AVIF por la brecha real (aunque pequeña) de ~6 %, además de los casos límite de rastreadores y dispositivos antiguos. Google recomienda explícitamente el patrón con fallback. - “Google penalizes older formats like JPEG/PNG.” (traducción) «Google penaliza formatos antiguos como JPEG/PNG». Falso: JPEG, PNG, GIF y BMP siguen siendo totalmente compatibles. No hay penalización, solo una oportunidad de velocidad perdida frente a los formatos modernos.
- «AVIF no puede animarse / WebP no admite transparencia». Ambas afirmaciones son falsas. WebP admite transparencia alfa incluso en modo con pérdida; AVIF admite animación (Safari 16.4+, Chrome y Edge, aunque Firefox todavía no en 2026).
- «AVIF no está listo: seguimos en un mundo solo de WebP». Desactualizado. AVIF ronda el ~94 % de compatibilidad global y Google Search puede indexarlo desde agosto de 2024. Trátalo como listo para producción con fallback, no como experimental.
Dónde encaja esto
Este artículo es el análisis profundo de comparación de formatos dentro del clúster de Image SEO: es el hogar canónico de la matriz de seis formatos y del desmontaje del mito de posicionamiento. Sus dos artículos hermanos cubren las tareas adyacentes:
Image Optimization es la guía de implementación (LCP, fetchpriority, carga diferida, compresión y dimensiones), y Responsive Images cubre la mecánica de srcset/sizes/<picture> para servir el tamaño adecuado según el dispositivo. El beneficio de rendimiento de elegir bien el formato es, en realidad, una historia de Core Web Vitals con una imagen como protagonista.
Resumen de IA
Una versión condensada del contenido Advanced:
- El formato no es un factor de posicionamiento. John Mueller ha confirmado que AVIF no ofrece ninguna mejora de SEO, y que WebP solo es “fine for Image Search”: un lenguaje neutro, no «better». El propio documento de imágenes de Google nunca relaciona el formato con el posicionamiento.
- La cadena real: formato → tamaño del archivo → velocidad de la página → LCP / Core Web Vitals → señales de experiencia de página. El formato está varios pasos antes; por eso no es un factor de posicionamiento por sí mismo.
- Datos de los seis formatos (2026): JPEG (con pérdida, sin transparencia, fallback universal); PNG (sin pérdida, alfa completa, gráficos/capturas); WebP (ambos tipos de compresión, alfa incluso con pérdida, ~96 % de compatibilidad, ~25–35 % más pequeño que JPEG: la opción segura); AVIF (mejor compresión, ~50 % más pequeño que JPEG, ~94 % de compatibilidad, pero exige mucha CPU, no tiene renderizado progresivo y todavía no anima en Firefox); SVG (vectorial: logotipos/iconos/diagramas); GIF (animación heredada de 256 colores, solo fallback universal).
- Elige por tipo de contenido: fotos → WebP (o AVIF + fallback); logotipos/iconos → SVG; capturas/transparencia/texto → PNG o WebP sin pérdida; animación sencilla → WebP/AVIF animado, GIF como fallback universal.
- Sirve con fallbacks:
<picture>(AVIF → WebP → JPEG/PNGsrc). El fallbacksrces la URL que indexa Google; Google indexa<img>(también dentro de<picture>), no los fondos CSS. - Compatibilidad oficial: Google admite BMP, GIF, JPEG, PNG, WebP, SVG y AVIF; AVIF se añadió el 30 de agosto de 2024 (antes podía romper la indexación de vídeos). Bing no tiene un documento comparativo de formatos: no inventes uno.
- Mitos desmontados: el formato ≠ mejora de posicionamiento; AVIF ≠ siempre mejor; PNG ≠ siempre seguro; «no hace falta fallback» ≠ cierto para AVIF; los formatos antiguos no reciben penalización; WebP admite transparencia y AVIF admite animación.
- Alcance: este es el análisis profundo de formatos; la guía de implementación de LCP/
fetchpriority/carga diferida está en Image Optimization, y la mecánica responsive en Responsive Images.
Documentación oficial
Documentación de fuentes primarias y material de referencia.
- Buenas prácticas de Google Imágenes: la lista de formatos compatibles (BMP, GIF, JPEG, PNG, WebP, SVG y AVIF), la regla de indexación
<img>frente a fondos CSS y la nota de que la extensión debe coincidir con el tipo de archivo. No afirma que el formato afecte al posicionamiento. - Compatibilidad con AVIF en Google Search (30 de agosto de 2024): el anuncio de que AVIF ya es compatible con Search, Images, Discover y News, sin necesidad de una implementación especial.
- Rendimiento de imágenes (web.dev, equipo de Google Chrome): la mecánica de formatos WebP/AVIF, alfa en compresión con pérdida, WCG/HDR, la división entre compresión con y sin pérdida y la razón por la que JPEG tiene problemas con bordes o texto nítidos.
Referencia (columna vertebral de precisión)
- Guía de tipos y formatos de archivos de imagen (MDN Web Docs): la especificación rigurosa formato por formato sobre tipos MIME, compresión, transparencia, animación, compatibilidad con renderizado progresivo y casos de uso.
- caniuse.com — AVIF y caniuse.com — WebP: tablas de compatibilidad por versión y de porcentajes globales actuales. Vuelve a comprobarlas antes de citar una cifra, porque cambian continuamente.
Bing / Microsoft
- Directrices para webmasters de Bing: orientación general sobre la velocidad de las páginas; Bing no publica una página técnica específica de comparación de formatos.
Citas de la fuente
Declaraciones de Google registradas públicamente. Cuando una página expone el texto, el enlace profundo salta al pasaje citado.
Documentos de Google: formatos compatibles y marco de rendimiento
- “Google Search supports images referenced in the
srcattribute ofimgin the following file formats: BMP, GIF, JPEG, PNG, WebP, SVG, and AVIF.” (traducción) «La Búsqueda de Google admite imágenes referenciadas en el atributosrcdeimgen los siguientes formatos: BMP, GIF, JPEG, PNG, WebP, SVG y AVIF». Saltar a la cita - “images are often the largest contributor to overall page size, which can make pages slow and expensive to load.” (traducción) «las imágenes suelen ser el mayor componente del tamaño total de una página, lo que puede hacer que las páginas sean lentas y costosas de cargar». Saltar a la cita
web.dev (equipo de Google Chrome): mecánica de formatos
- WebP: “WebP often has better compression than JPEG, PNG, or GIF, offering both lossy and lossless compression.” (traducción) «WebP suele comprimir mejor que JPEG, PNG o GIF y ofrece compresión tanto con pérdida como sin pérdida». Saltar a la cita
- Ventaja de transparencia de WebP: “WebP also supports alpha channel transparency even when using lossy compression—a feature the JPEG codec doesn’t offer.” (traducción) «WebP también admite transparencia mediante canal alfa incluso con compresión con pérdida, una función que el códec JPEG no ofrece».
- AVIF: “AVIF supports both lossy and lossless compression, and tests have shown greater than 50% savings when compared to JPEG in some cases.” (traducción) «AVIF admite compresión con y sin pérdida, y las pruebas han mostrado ahorros superiores al 50 % frente a JPEG en algunos casos».
- Punto débil de JPEG: “lossy compression may be less effective with imagery containing sharp edges such as line art, similarly stark details, or text.” (traducción) «la compresión con pérdida puede ser menos eficaz con imágenes que contengan bordes definidos, como ilustraciones lineales, detalles igualmente marcados o texto».
- Uso ideal de 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.” (traducción) «Como SVG es un formato vectorial, resulta especialmente útil cuando la imagen contiene ilustraciones lineales, diagramas, gráficos u otros elementos sin detalles fotográficos finos».
Blog de Google Search Central: compatibilidad con AVIF (30 de agosto de 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.” (traducción) «Nos complace anunciar que AVIF ya es un tipo de archivo compatible con la Búsqueda de Google, tanto para Google Imágenes como para cualquier lugar de la Búsqueda de Google que use imágenes». Anuncio
- “You don’t need to do anything special to have your AVIF files indexed by Google.” (traducción) «No tienes que hacer nada especial para que Google indexe tus archivos AVIF».
John Mueller, Google: el formato no mejora el posicionamiento
- Sobre AVIF: no existe ninguna «mejora de SEO» por usar archivos AVIF; el beneficio es reducir el tamaño del archivo, lo que puede ayudar a la velocidad de la página, no crear una preferencia de posicionamiento. Cobertura
- Sobre WebP: “WebP images are fine for Image Search” (traducción) «Las imágenes WebP sirven perfectamente para la búsqueda de imágenes»; dijo que sirven, no que sean mejores. Cobertura
- Sobre el informe «Rastreada: actualmente sin indexar» de WebP: es una peculiaridad general de los informes de imágenes (las imágenes no se indexan como páginas HTML), y Mueller afirmó que “he doesn’t believe the phenomenon is limited to WebP images.” (traducción) «no cree que el fenómeno se limite a las imágenes WebP». Cobertura de SEJ
¿Qué formato debería usar?
Trabaja de arriba abajo. Haz coincidir el formato con lo que es la imagen y añade después un fallback si elegiste una opción moderna.
1. ¿Es un logotipo, icono, diagrama o arte lineal? → SVG. El vector escala sin perder calidad y sigue siendo pequeño. Detente aquí.
2. ¿Necesita animación? → WebP o AVIF animado cuando sean compatibles, con GIF como fallback universal para bucles sencillos. Para algo más rico que un bucle corto, usa vídeo (MP4/WebM), no un formato de imagen. Detente aquí.
3. ¿Es una fotografía?
→ WebP es la opción segura (~96 % de compatibilidad; no necesita fallback estrictamente).
→ ¿Quieres la máxima compresión y puedes añadir un fallback? AVIF → WebP → JPEG mediante <picture>.
→ ¿Necesitas un único archivo universal sin lógica de fallback? JPEG.
4. ¿Es una captura o un gráfico con bordes nítidos, texto o transparencia? → PNG (o WebP sin pérdida). Los artefactos con pérdida de JPEG destrozan los bordes nítidos y el texto; PNG los mantiene claros y admite transparencia completa.
5. ¿Elegiste AVIF o WebP para una foto?
→ Envuélvelo en <picture> con formatos inferiores como elementos <source> y un fallback <img src> JPEG/PNG. Ese src es la URL que indexa Google.
Referencia rápida por respuesta
| Si la imagen es… | Usa | ¿Fallback? |
|---|---|---|
| Logotipo / icono / diagrama / arte lineal | SVG | No hace falta |
| Fotografía (predeterminado) | WebP | Opcional (casi universal) |
| Fotografía (máxima compresión) | AVIF | Sí: primero WebP y después JPEG |
| Fotografía (un único archivo universal) | JPEG | Es el fallback |
| Captura / bordes nítidos / texto / transparencia | PNG o WebP sin pérdida | No hace falta para PNG |
| Animación sencilla | WebP/AVIF animado | GIF (universal) |
| Animación rica | Vídeo (MP4/WebM) | — |
Modelos mentales
1. La cadena causal: formato → tamaño del archivo → velocidad → Core Web Vitals. El formato está al principio de una cadena de cuatro pasos, no al final del posicionamiento: la elección del formato cambia el tamaño del archivo → los archivos más pequeños cargan más rápido → las cargas más rápidas mejoran Largest Contentful Paint (LCP) → LCP alimenta Core Web Vitals, que sí forma parte de las señales de experiencia de página que usan los sistemas de posicionamiento. Reducirlo a «el formato afecta al posicionamiento» es exactamente lo que propaga el mito: el formato está varios pasos antes y, si la página no se vuelve realmente más rápida, nada cambia después. Usa este modelo cuando sientas la tentación de atribuir un cambio de posicionamiento al cambio de formato en sí: pregunta qué eslabón de la cadena ocurrió realmente.
2. Elige por tipo de contenido, no porque «lo nuevo siempre gana». El formato más reciente no es automáticamente el adecuado: haz coincidir el formato con lo que es la imagen:
- Fotografías → WebP (opción segura) o AVIF con fallback JPEG para máxima compresión.
- Logotipos, iconos, diagramas y arte lineal → SVG.
- Capturas, bordes nítidos, texto en imágenes y transparencia sin complejidad de fallback → PNG (o WebP sin pérdida).
- Animación sencilla → WebP/AVIF animado cuando sea compatible; GIF solo como fallback universal (animación más rica → vídeo).
Pasar una imagen por este modelo antes de recurrir a «usa AVIF sin más, es lo más nuevo» permite detectar los casos en los que los costes reales de AVIF —codificación exigente para la CPU, ausencia de renderizado progresivo y falta de compatibilidad con Google Search hasta agosto de 2024— pesan más que su ventaja de compresión.
Chuleta de formatos de imagen
Los seis formatos de un vistazo (2026)
| Formato | Compresión | Transparencia | Animación | Compatibilidad | Úsalo para |
|---|---|---|---|---|---|
| JPEG | Con pérdida | No | No | Universal | Fotos; el fallback |
| PNG | Sin pérdida | Sí (alfa) | No | Universal | Capturas, logotipos, texto y transparencia |
| WebP | Ambas | Sí (incluso con pérdida) | Sí | ~96 % | Predeterminado para fotos; ~25–35 % < JPEG |
| AVIF | Ambas | Sí | Sí (no Firefox) | ~94 % | Máxima compresión + fallback; ~50 % < JPEG |
| SVG | Vectorial | Sí | Sí | Universal | Logotipos, iconos y diagramas |
| GIF | Sin pérdida, 256 colores | Solo binaria | Sí | Universal | Animación sencilla heredada |
El patrón de 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>Datos rápidos
- No hay una mejora directa de posicionamiento por WebP/AVIF: el beneficio es velocidad → Core Web Vitals.
- Google admite BMP, GIF, JPEG, PNG, WebP, SVG y AVIF; AVIF se añadió el 30 de agosto de 2024.
- Google indexa
<img>(también dentro de<picture>), nobackground-imagede CSS. - El fallback
<img src>es la URL que indexa Google. - WebP admite transparencia alfa incluso en modo con pérdida; JPEG no puede tener transparencia.
- Costes de AVIF: codificación exigente para la CPU, sin renderizado progresivo y animación todavía no compatible con Firefox (2026).
- SVG es vectorial: nunca lo uses para fotografías y nunca uses JPEG para logotipos o texto.
Lista de comprobación para elegir formato
Una comprobación rápida para confirmar que cada imagen tiene el formato correcto y se sirve de forma segura:
- Las fotografías son WebP (o AVIF con fallback), no PNG o JPEG sobredimensionados.
- Los logotipos, iconos y diagramas son SVG, no rasterizados.
- Las capturas y los gráficos con texto en la imagen son PNG o WebP sin pérdida, no JPEG (cuyos artefactos difuminan los bordes y el texto nítidos).
- Todo lo que necesite transparencia usa PNG, WebP o AVIF: nunca JPEG.
- Los formatos modernos (AVIF/WebP) se sirven mediante
<picture>con un fallback<img src>JPEG/PNG. - Cada imagen está dentro de un
<img>(o<picture>), no en unbackground-imagede CSS, si quieres que aparezca en la búsqueda de imágenes. - Las extensiones coinciden con el tipo de archivo real (vigílalo después de una conversión por lotes a
.webp/.avif). - No se eligió ningún formato para mejorar el posicionamiento: el objetivo es un archivo más pequeño → un LCP más rápido, verificado mediante una prueba real de velocidad de página, no mediante la etiqueta del formato.
- Las animaciones usan WebP/AVIF animado (o vídeo); GIF solo cuando se necesita compatibilidad universal sin fallback.
- Las suposiciones sobre compatibilidad se han vuelto a comprobar en caniuse si vas a prescindir de un fallback.
Errores que debes evitar con los formatos de imagen
Cambiar a WebP/AVIF esperando una mejora de posicionamiento. Por qué es incorrecto: John Mueller ha confirmado que AVIF no ofrece ninguna mejora de SEO, y que WebP solo es “fine for Image Search”, un lenguaje deliberadamente neutro, no «better». El formato no es una señal de posicionamiento; lo es la velocidad que permite. Qué hacer: convierte para obtener la ganancia de tamaño de archivo y Core Web Vitals, y verifica la mejora mediante una prueba real de velocidad de página, no mediante la etiqueta del formato.
Tratar AVIF como la mejor opción en todos los casos porque comprime más.
Por qué es incorrecto: la mejor compresión no es la única variable. AVIF exige mucha CPU para codificar, no tiene renderizado progresivo (la imagen debe descargarse por completo antes de mostrarse) y las herramientas para AVIF animado todavía no son compatibles con Firefox en 2026.
Qué hacer: usa AVIF con un fallback <picture> cuando busques la máxima compresión y puedas asumir el coste de codificación; en los demás casos, WebP es la opción diaria más segura.
Suponer que PNG siempre es la opción segura y de alta calidad. Por qué es incorrecto: PNG solo comprime sin pérdida, así que usarlo para fotografías produce archivos innecesariamente voluminosos sin una ganancia visible de calidad frente a un JPEG/WebP bien ajustado: un coste de velocidad real y evitable. Qué hacer: reserva PNG para transparencia y gráficos, capturas o texto con bordes nítidos; usa WebP o JPEG para fotos.
Eliminar el fallback porque «la compatibilidad ya es prácticamente universal».
Por qué es incorrecto: es casi cierto para WebP (~96 %), pero AVIF aún ronda el ~94 % de compatibilidad global y algunos dispositivos antiguos y rastreadores no lo muestran: existe una brecha real, aunque pequeña.
Qué hacer: sirve los formatos modernos mediante un elemento <picture> que termine en un fallback <img src> JPEG/PNG; ese fallback también es la URL que indexa Google.
Creer que los formatos antiguos como JPEG o PNG reciben una penalización. Por qué es incorrecto: JPEG, PNG, GIF y BMP siguen siendo totalmente compatibles con Google Search; no hay ninguna penalización por usarlos, solo una oportunidad de velocidad perdida frente a un archivo moderno más pequeño. Qué hacer: convierte cuando el beneficio de tamaño justifique el esfuerzo, pero no trates seguir usando JPEG/PNG como un riesgo de cumplimiento.
Suponer que WebP no admite transparencia o que AVIF no puede animarse. Por qué es incorrecto: ambas afirmaciones son falsas. WebP admite transparencia alfa incluso en modo con pérdida, algo que JPEG no puede hacer en absoluto, y AVIF admite animación en Chrome, Edge y Safari 16.4+ (pero todavía no en Firefox). Qué hacer: comprueba la capacidad real de cada formato (en la tabla de seis formatos de la pestaña Advanced) en lugar de suponerla por la antigüedad del formato.
Descartar AVIF por ser «todavía experimental» en 2026. Por qué es incorrecto: está desactualizado. AVIF se puede indexar en Google Search desde el 30 de agosto de 2024 y ronda el ~94 % de compatibilidad global. Qué hacer: trata AVIF como listo para producción con fallback, no como algo que deba evitarse por completo.
Ponte a prueba: formatos de imagen
Cinco preguntas rápidas sobre cómo elegir formatos de imagen para SEO. Elige una respuesta en cada una y compruébala después.
Recursos que merecen tu tiempo
Mis artículos relacionados
- SEO de imágenes: 12 consejos prácticos para conseguir más tráfico orgánico: mi guía de SEO de imágenes para Ahrefs (formatos, compresión, nombres de archivo, texto alternativo, sitemaps, imágenes adaptables, schema y carga diferida).
- Largest Contentful Paint (LCP): por qué el elemento LCP suele ser una imagen y cómo el tamaño del archivo impulsado por el formato alimenta la cadena de rendimiento en la que se basa el desmontaje del mito de este artículo.
- Guía para principiantes sobre SEO técnico: dónde encajan las imágenes y Core Web Vitals en el panorama más amplio del SEO técnico.
Mis charlas
- «Image SEO» (webinar de Visme, 2021): mi charla dedicada a optimizar imágenes para la búsqueda, incluidos formatos y compresión.
Oficial
- Buenas prácticas de Google Imágenes: la lista de formatos compatibles y la mecánica de indexación.
- Compatibilidad con AVIF en Google Search (agosto de 2024): el anuncio de compatibilidad con AVIF.
- web.dev — Rendimiento de imágenes (equipo de Google Chrome): la referencia sobre la mecánica de formatos que respalda la tabla comparativa.
Del sector
- Guía de tipos y formatos de archivos de imagen (MDN Web Docs): la tabla formato por formato más rigurosa de la web; la columna vertebral de precisión de la comparación de seis formatos.
- caniuse.com — AVIF / caniuse.com — WebP: tablas activas de compatibilidad por versión y porcentajes globales actuales.
- El nuevo soporte de Google para imágenes AVIF podría mejorar el SEO (Search Engine Journal, Roger Montti): un caso útil de cómo se amplifica el encuadre «formato = mejora de posicionamiento»; el cuerpo dirige correctamente el beneficio a través de Core Web Vitals.
- John Mueller, de Google, aclara la confusión sobre la indexación de imágenes WebP (Search Engine Journal): por qué las imágenes WebP aparecen como «Rastreada: actualmente sin indexar» y por qué no es un problema específico de WebP.
- La Búsqueda de Google ya admite imágenes AVIF (Search Engine Roundtable): cobertura del hito de AVIF y del punto de Mueller sobre que no ofrece ninguna mejora de SEO.
- AVIF frente a WebP: cuatro diferencias clave y cómo elegir (Cloudinary): una comparación de AVIF y WebP orientada a la implementación.
- r/TechSEO: la comunidad para depurar formatos de imagen y rendimiento.
Registro de cambios
Actualizado el 22 ago 2026.
Resumen editorial y detalles registrados del cambio.Detalles del cambio
-
Los detalles del cambio están disponibles actualmente en inglés.
La comparación completa no está disponible: no se archivó una instantánea anterior para esta revisión.
Actualizado el 10 ago 2026.
Resumen editorial y detalles registrados del cambio.Detalles del cambio
-
Los detalles del cambio están disponibles actualmente en inglés.
-
Los detalles del cambio están disponibles actualmente en inglés.
-
Los detalles del cambio están disponibles actualmente en inglés.
La comparación completa no está disponible: no se archivó una instantánea anterior para esta revisión.
Actualizado el 18 jul 2026.
Resumen editorial y detalles registrados del cambio.Detalles del cambio
-
Los detalles del cambio están disponibles actualmente en inglés.
-
Los detalles del cambio están disponibles actualmente en inglés.
-
Los detalles del cambio están disponibles actualmente en inglés.
La comparación completa no está disponible: no se archivó una instantánea anterior para esta revisión.