Imágenes: formatos, peso y lo que afecta al SEO

Respuesta breve

Optimizar imágenes para SEO son dos trabajos, no uno: la experiencia de carga, donde una imagen mal servida es la causa habitual del LCP alto y de los desplazamientos de diseño; y la comprensión, donde el texto alternativo, el nombre del fichero y el contexto que las rodea permiten entender qué muestran. Comprimir por comprimir no es la palanca: la mayor parte del peso sobrante viene de servir dimensiones muy superiores a las que se pintan en pantalla.

Puntos clave

• El primer ahorro es dimensional: redimensionar antes que recomprimir.
• La imagen que forma el LCP nunca debe llevar carga diferida.
• width y height en el HTML evitan desplazamientos: cuestan nada y resuelven CLS.
• AVIF y WebP reducen bytes frente a JPEG, pero la elección depende del contenido y de la cadena de producción.
• El texto alternativo es primero accesibilidad; su valor descriptivo para buscadores es una consecuencia.
• Un plugin de optimización mal configurado puede empeorar el resultado y ocultar la causa.

El orden de los ahorros

1. RedimensionarAntes que recomprimir: el tamaño manda.
2. FormatoAVIF o WebP según contenido y cadena de producción.
3. Dimensioneswidth y height en el HTML: cuestan nada y resuelven CLS.
4. Carga diferidaA todas menos a la del LCP.
5. Texto alternativoLo que hay en la imagen, para quien no la ve.

Índice

1. Qué afecta de verdad
2. Elegir formato
3. El peso empieza en las dimensiones
4. Imágenes adaptables sin adivinar
5. Carga diferida y prioridad
6. Reservar espacio y evitar saltos
7. Texto alternativo, nombres y contexto
8. Aparecer en la búsqueda de imágenes
9. Automatizar sin perder el control
10. Errores frecuentes
11. Próximo paso

Qué afecta de verdad

Conviene separar lo que tiene efecto demostrable de lo que se repite por costumbre.

Tiene efecto: el tiempo que tarda en pintarse la imagen principal, porque suele ser el elemento que define el LCP; la estabilidad visual, porque una imagen sin dimensiones declaradas desplaza el contenido; la posibilidad de que el buscador comprenda de qué trata la imagen, mediante el alt, el nombre del fichero, el título de la página y el texto contiguo; y la accesibilidad, que es una obligación en sí misma.

No tiene el efecto que se le atribuye: repetir la palabra clave en el nombre de cada fichero, escribir un alt cargado de términos, comprimir hasta degradar visiblemente la imagen o convertirlo todo al formato de moda sin medir. Las políticas de spam de Google desaconsejan el relleno de palabras clave, y el alt no es una excepción.

La consecuencia práctica: el trabajo de imágenes es sobre todo trabajo de rendimiento, y se prioriza con el mismo método de medición que el resto de Core Web Vitals. Los umbrales vigentes son LCP 2,5 s, INP 200 ms y CLS 0,1 en el percentil 75, y las imágenes intervienen en dos de los tres. El tercero se trata aparte: qué mide INP realmente y cómo bajarlo rara vez depende del peso de una imagen.

Las políticas de spam de Google desaconsejan el relleno de palabras clave, y el alt no es una excepción.

Elegir formato

Google Images admite los formatos habituales de la web —entre ellos JPEG, PNG, WebP, AVIF, GIF y SVG—, de modo que la elección no es una cuestión de compatibilidad con el buscador sino de resultado visual y de peso.

Formatos de imagen: en qué contenido encaja cada uno y qué hay que tener en cuenta.

Formato	Encaja en	A tener en cuenta
AVIF	Fotografía y gradientes, máxima compresión	Codificación más lenta; conviene comprobar la salida
WebP	Uso general, con y sin pérdida	Compatibilidad muy amplia; buen valor por defecto
JPEG	Fotografía, alternativa universal	Sin transparencia; sigue siendo un fallback válido
PNG	Capturas, gráficos planos, transparencia	Pesado en fotografía; no lo uses para fotos
SVG	Iconos, logotipos, diagramas	Escala sin pérdida; sanea el fichero antes de servirlo

La forma segura de servir formatos modernos con alternativa es <picture> con varias fuentes, o la negociación por cabecera en el servidor o el CDN. Lo que no conviene es reemplazar el original sin conservar una copia: una recompresión agresiva es irreversible, y el día que cambie el diseño necesitarás partir de la imagen buena.

El peso empieza en las dimensiones

El error más caro y más común: subir la fotografía tal como sale de la cámara o del banco de imágenes, de varios miles de píxeles de ancho, y mostrarla en un contenedor de seiscientos. El navegador descarga todo y descarta la mayor parte. Ninguna compresión arregla eso, porque el problema no es la calidad sino la escala.

El procedimiento correcto, en este orden:

• Determina el ancho máximo real al que se pinta la imagen en el diseño, en el punto de ruptura más grande.
• Duplícalo para pantallas de alta densidad y usa eso como tamaño máximo generado.
• Genera el conjunto de tamaños intermedios que el diseño necesita, no una lista arbitraria.
• Comprime al nivel donde la degradación no sea perceptible en el uso real, comparando a tamaño de pantalla y no ampliado.

Para comprobar si tienes este problema, mide en el navegador la diferencia entre el tamaño intrínseco de cada imagen y el tamaño al que se muestra. Si el factor es mayor que dos en pantallas normales, hay bytes desperdiciados que ninguna otra optimización va a recuperar.

Imágenes adaptables sin adivinar

El par srcset y sizes permite que el navegador elija el fichero adecuado según el ancho de la ventana y la densidad de pantalla. La parte que casi siempre está mal es sizes: si declaras 100vw cuando la imagen ocupa la mitad del ancho, el navegador descargará una versión mayor de la necesaria y todo el trabajo previo se pierde.

sizes debe describir el ancho real que ocupará la imagen en cada punto de ruptura del diseño. Cuando la maquetación cambia, hay que actualizarlo. Es un valor que se desincroniza con facilidad y que conviene revisar cada vez que se rediseña una plantilla.

Un caso distinto es la dirección de arte: en móvil no quieres la misma foto reducida sino un recorte diferente. Eso no lo resuelve srcset, sino <picture> con media.

Carga diferida y prioridad

La carga diferida nativa con loading="lazy" evita descargar lo que está fuera de pantalla. Bien aplicada, es de las mejores relaciones entre esfuerzo y resultado. Mal aplicada, es una de las causas más frecuentes de LCP alto.

Las dos reglas:

• La imagen visible al cargar no lleva lazy. Si es la que define el LCP, diferirla retrasa su descubrimiento y empeora la métrica de forma directa.
• La imagen del LCP puede llevar fetchpriority="high" para que el navegador la trate como prioritaria frente a otros recursos que compiten.

El problema típico en gestores de contenido es que la opción es global: «carga diferida en todas las imágenes». Eso incluye la del encabezado. Comprueba en el HTML publicado si la primera imagen de cada plantilla lleva el atributo, y excluye la del hero. Cuando el diferido lo aplica un plugin y no la plantilla, la exclusión es un ajuste más y merece quedar documentado, en la línea de mantener una sola fuente por señal que plantea el SEO en WordPress sin sobrecargar de plugins.

Reservar espacio y evitar saltos

El CLS que provocan las imágenes tiene una solución barata y completa: declarar width y height en el HTML. El navegador calcula la proporción y reserva el hueco antes de descargar el fichero. No fuerza un tamaño fijo si el CSS define max-width: 100% y height: auto.

Con esa reserva hecha, los saltos que queden vienen de otro sitio: fuentes que cambian la geometría al cargar, avisos por encima del contenido o widgets que aparecen tarde. Revisa a varias anchuras.

Texto alternativo, nombres y contexto

El texto alternativo tiene una función principal: describir la imagen a quien no puede verla. Ese es también el criterio que produce un alt útil para los buscadores, así que no hay conflicto entre ambos objetivos.

• Describe lo que se ve y lo que aporta en ese contexto, en una frase.
• Una imagen puramente decorativa lleva alt="", no una descripción inventada. Un alt vacío es una decisión correcta, no un descuido.
• Si la imagen es un enlace, el alt describe el destino, no la ilustración.
• No repitas el pie de foto en el alt: quien usa un lector de pantalla oiría lo mismo dos veces.

El nombre del fichero ayuda de forma modesta: reforma-cocina-pamplona.jpg es mejor que IMG_4821.jpg, y ahí acaba el asunto. El contexto que rodea la imagen —el título, el encabezado próximo, el párrafo— pesa más que el propio fichero. En catálogos, además, las imágenes forman parte de la ficha y de la decisión de compra, y su tratamiento se decide junto con el resto de la arquitectura de categorías, productos y facetas.

Aparecer en la búsqueda de imágenes

Para que una imagen pueda mostrarse en resultados tiene que poder rastrearse e indexarse. Puntos que lo impiden con más frecuencia de lo que parece:

• El directorio de medios bloqueado en robots.txt, a veces heredado de una configuración antigua.
• Imágenes servidas solo por JavaScript sin un <img> en el HTML.
• URLs de imagen que cambian en cada despliegue, impidiendo acumular historial.
• Contenido incrustado desde un dominio distinto sin control sobre su rastreo.

Un sitemap de imágenes es opcional y solo aporta cuando el descubrimiento por HTML es difícil. Declarar en los datos estructurados una imagen que no está en la página incumple las políticas de Google; la revisión de qué datos estructurados siguen dando resultado recoge el resto de exigencias.

Automatizar sin perder el control

La generación de tamaños, la conversión y la entrega adaptada deben estar automatizadas. La cuestión es dónde vive esa automatización y si puedes auditarla.

Tres comprobaciones antes de dar por buena una capa de optimización, sea un plugin, un CDN de imágenes o un paso de compilación:

• Mira el HTML publicado, no la pantalla de ajustes. Comprueba qué URL se sirve, con qué formato, qué srcset y qué atributos.
• Comprueba el original. Si la herramienta sobrescribe los ficheros de partida, tendrás un problema el día que necesites otro recorte.
• Mide antes y después en las mismas condiciones. Una capa que añade su propia caché puede falsear la comparación si mezclas caché fría y caliente.

En cuatro láminas

HTML · el marcado de esta misma galería: <img src="lamina-960.webp" / srcset="lamina-480.webp 480w, / lamina-960.webp 960w, / lamina-1440.webp 1440w" / sizes="(min-width: 1024px) 34vw, 100vw" / width="1440" height="900" / alt="Lo que hay en la imagen" / loading="lazy" decoding="async">

1 imagen que nunca se difiere. La que forma el LCP: diferirla retrasa justo lo que se está midiendo.

4.000 px servidos en una columna de 600. Ninguna compresión lo arregla: el problema no es la calidad sino la escala. Se redimensiona antes de recomprimir.

Errores frecuentes

• Subir el original de varios miles de píxeles y confiar en que el CSS lo arregle.
• Aplicar carga diferida a la imagen del encabezado.
• Declarar sizes como 100vw en imágenes que ocupan media columna.
• Omitir width y height y después buscar el CLS en otro sitio.
• Rellenar el alt de palabras clave en lugar de describir la imagen.
• Poner alt descriptivo a imágenes decorativas y llenar de ruido la lectura asistida.
• Bloquear el directorio de medios en robots.txt y preguntarse por qué no aparecen las imágenes.

Preguntas habituales

¿Convierto todo a WebP y ya está?

El primer ahorro no es el formato, es el tamaño: una foto de 4.000 píxeles servida en una columna de 600 sigue pesando de más en cualquier formato. Se redimensiona antes de recomprimir. AVIF y WebP reducen bytes frente a JPEG, pero la elección depende del contenido y de lo que soporte la cadena de proceso.

¿Aplico carga diferida a todas las imágenes?

A todas menos a la del encabezado, que suele ser el elemento LCP: diferirla retrasa justo lo que se está midiendo. Es una de las optimizaciones que más veces empeora la métrica que pretendía mejorar, porque la regla se aplica en bloque sin mirar cuál es el elemento medido.

¿Qué escribo en el atributo alt?

Lo que hay en la imagen, para quien no puede verla. Es primero una cuestión de accesibilidad; su valor descriptivo para los buscadores es una consecuencia. Rellenarlo de palabras clave no ayuda y estorba a quien usa un lector de pantalla. Las imágenes decorativas llevan alt vacío, no una descripción.

¿Por qué no aparecen mis imágenes en Google?

Antes de buscar causas complicadas conviene mirar si el directorio de medios está bloqueado en robots.txt: es un clásico, y mientras lo esté no hay nada más que revisar. Después vienen el contexto que rodea a la imagen, el nombre del fichero y que la página que la contiene sea indexable.

Próximo paso

Toma tres plantillas representativas y lista, para cada imagen visible al cargar, su tamaño intrínseco, el tamaño mostrado, el formato, si lleva carga diferida y si tiene dimensiones declaradas. Corrige primero la imagen del LCP en cada plantilla y las que se sirven a más del doble de su tamaño útil. Ese par de cambios suele explicar la mayor parte del margen disponible.

Fuentes

• Google Search Central, prácticas recomendadas para imágenes — documentación oficial.
• web.dev, optimizar Largest Contentful Paint — documentación oficial.
• web.dev, optimizar Cumulative Layout Shift — documentación oficial.

Servicio relacionado

Si esto es lo que te está pasando, seo técnico es el trabajo que lo resuelve. Diagnóstico primero, prioridades después.

Ver seo técnico