06

SEO on-page

Capítulo 06 / 08

SEO de imagen

Las imágenes son la mitad del peso de página en la mayoría de los sitios y uno de los elementos on-page más subutilizados. El arreglo es mecánico: filenames descriptivos, formatos modernos, alt text real y lazy loading.

9 min de lecturaPublicado 6 may 2026
SEO de imagen

Las imágenes son responsables del 40–60% de los bytes descargados de una página de contenido típica, aparecen en Google Image Search, en los rich results de la SERP, en los previews OG y en respuestas de motores de IA con elementos visuales. También son uno de los elementos on-page más consistentemente subutilizados. La razón es aburrida pero solucionable: el SEO de imagen es trabajo mecánico que es fácil de saltarse durante un lanzamiento ocupado y casi nunca se limpia retroactivamente. La buena noticia es que las reglas son simples y la mayor parte del trabajo se puede templatizar.

La mayoría de los problemas de SEO de imagen en un sitio no son malas decisiones, son decisiones que faltan. Definir un default para filename, formato, alt text y comportamiento de carga resuelve el 90% de los issues de forma automática.

Las cinco palancas del SEO de imagen

  1. Filename. Descriptivo, alineado a la keyword, en kebab-case.
  2. Formato. WebP en la mayoría de los casos, AVIF cuando el ancho de banda es crítico, JPEG/PNG solo para legacy.
  3. Peso de archivo. Imágenes hero por debajo de 200 KB, imágenes de contenido por debajo de 100 KB, thumbnails por debajo de 30 KB.
  4. Alt text. Descripción real del contenido de la imagen, con la regla heroAlt = H1 para imágenes hero.
  5. Comportamiento de carga. Lazy load debajo del fold, eager load arriba del fold, reserva dimensiones para prevenir layout shift.

Filenames: la señal más barata que ignoras

IMG_4529.jpg es el default. También es una señal de ranking desperdiciada. Image search y los motores de IA leen el filename como uno de los indicadores más fuertes de qué muestra la imagen. Renombra a:

  • Descriptivo del contenido de la imagen.
  • Kebab-case, minúsculas, sin espacios.
  • Que contenga la keyword principal de la página cuando la imagen es el hero o un activo inline clave.
  • Libre de sufijos generados (-1, -final-final-v3) cuando se pueda.

Ejemplos: title-tags-hero.webp, jerarquia-de-headers-prueba-outline.webp, enlaces-internos-hub-and-spoke.webp. El filename no necesita ser una oración completa; 3–5 palabras es el sweet spot.

Elección de formato: WebP, AVIF, JPEG, PNG

FormatoWebP
Mejor paraDefault para todo en 2026: fotos, ilustraciones, screenshots
Trade-offs25-35% más chico que JPEG, soportado en cada navegador moderno, fácil de generar
FormatoAVIF
Mejor paraEscenarios donde el ancho de banda es crítico, hero images, thumbnails de video
Trade-offs20-30% más chico que WebP, codificación más lenta, requiere fallback en algunos navegadores legacy
FormatoJPEG
Mejor paraSolo compatibilidad legacy
Trade-offsArchivos más grandes, sin transparencia, soporte ubicuo
FormatoPNG
Mejor paraLogos, íconos con transparencia, screenshots que necesitan fidelidad pixel-perfect
Trade-offsSin pérdidas pero muy grandes; úsalo poco y solo cuando la transparencia o la fidelidad lo exija
FormatoSVG
Mejor paraLogos, íconos, ilustraciones, gráficas con contenido vectorial
Trade-offsEscala infinito, muy chico para contenido vectorial, no para fotos

El default en 2026 es WebP. Toma AVIF cuando el LCP sea tu cuello de botella y la CDN maneje el fallback. Toma SVG para cualquier logo o ícono. Toma JPEG/PNG solo cuando tengas razón específica.

Presupuestos de peso de archivo

El peso de archivo afecta el Largest Contentful Paint (LCP), el Core Web Vital más vigilado. Los presupuestos aproximados:

  • Hero images: por debajo de 200 KB, idealmente por debajo de 150 KB.
  • Imágenes de contenido inline: por debajo de 100 KB.
  • Thumbnails: por debajo de 30 KB.
  • Logos e íconos: por debajo de 10 KB (SVG suele lograrlo de forma trivial).

Los presupuestos no son reglas; son checkpoints. Un hero de 350 KB está bien si aterriza en 1.5 s en móvil por edge cache de la CDN; un hero de 50 KB está mal si aterriza en 4 s por un DNS mal configurado. Mide el LCP primero, después optimiza las imágenes que contribuyen.

Alt text: la regla heroAlt = H1 y más allá

El alt text sirve a tres audiencias: usuarios de lectores de pantalla, crawlers de motores de búsqueda y motores de IA que leen imágenes. La regla por defecto:

Para imágenes hero:el alt text equivale al H1 de la página palabra por palabra. El hero es la imagen que ancla el tema de la página; su alt refuerza de qué trata la página. Si el H1 es “Title tags”, el alt del hero es “Title tags”. Los acentos del H1 pueden escribirse en ASCII sin acento dentro del alt sin penalización (no es violación).

Para imágenes de contenido inline:describe lo que la imagen muestra de verdad. “Diagrama del patrón hub-and-spoke de enlaces internos”, no “Imagen de enlaces internos”. El alt debe ser el caption que le darías a un oyente de podcast que no ve la imagen.

Para imágenes decorativas: alt text vacío (alt=""), no faltante. Vacío le dice al lector de pantalla que se salte la imagen; faltante hace que lea el filename, lo que rara vez sirve.

Anti-patrones de alt text

  • Saturado de keywords. “title tags SEO mejores title tags 2026 guía” es spam, lo ignora Google y rompe a los lectores de pantalla.
  • Idéntico en muchas imágenes. 20 imágenes inline con alt “gráfica” no pasan información.
  • Empezar con “Imagen de...” o “Foto de...”. Los lectores de pantalla ya anuncian la imagen; el prefijo es redundante.
  • Pura descripción para gráficas e infografías con datos. Si la imagen carga datos, el alt debe resumir el dato, no describir el estilo visual.
  • Auto-generado por el CMS. El auto-alt casi siempre está mal: descripciones malas o el filename palabra por palabra.

Lazy loading y prevención de CLS

Dos atributos de performance que afectan el SEO directo:

  • Lazy loading: loading="lazy" en imágenes debajo del fold. El navegador difiere la carga hasta que el usuario hace scroll cerca. Ahorra ancho de banda, mejora LCP del contenido arriba del fold. No hagas lazy del hero: el elemento LCP debe cargarse en eager.
  • Atributos width y height: Configurar width y height en cada imagen le permite al navegador reservar el espacio del layout antes de que cargue la imagen. Sin ellos, el contenido salta cuando la imagen llega y dispara penalizaciones de Cumulative Layout Shift (CLS).

Los dos son mecánicos de implementar. Los frameworks modernos los configuran automáticamente cuando usas el componente de imagen del framework (next/image en Next.js, astro:assets en Astro). Las etiquetas <img> hechas a mano son donde estos atributos se olvidan.

Imágenes responsive con srcset

Un hero de 1600 px cargado en un teléfono de 360 px desperdicia ancho de banda y desacelera el LCP. La solución es srcset:

<img src="hero-1600.webp" srcset="hero-360.webp 360w, hero-768.webp 768w, hero-1200.webp 1200w, hero-1600.webp 1600w" sizes="100vw" alt="Title tags">

El navegador elige el tamaño correcto según el ancho de viewport y la densidad de píxeles. La mayoría de los frameworks generan las variantes de forma automática; si lo haces a mano, construye las variantes una vez al subir, no por request.

Schema de imagen (ImageObject)

Para imágenes que son centrales al tema de una página — fotos de producto, imágenes de gráfica, fotos de receta, imágenes hero en artículos insignia — los structured data con ImageObject pueden producir previews más ricos en SERP. No agregues schema ImageObject a cada imagen del sitio; es ruidoso y diluye la señal. Resérvalo para:

  • Imágenes de producto (ya cubiertas por Product schema).
  • Fotos de receta (cubiertas por Recipe schema).
  • Imágenes hero de artículo (cubiertas por la propiedad image del schema Article).
  • Infografías standalone donde la imagen es el contenido principal.

Para la mayoría de las páginas, la imagen la referencia el schema padre (Article, Product, Recipe) y un ImageObject separado es innecesario.

Cómo leen los motores de IA las imágenes de forma directa

Los motores de IA modernos (ChatGPT, Gemini, Claude) incluyen modelos de visión que leen el contenido de la imagen de forma directa. Es un cambio significativo respecto a hace pocos años, cuando el alt text y el filename eran las únicas señales de imagen que los motores de IA podían usar. Ahora:

  • Las gráficas se parsean visualmente. Una gráfica de barras con etiquetas de eje y valores la lee el modelo de visión, y los puntos de dato se extraen al entendimiento que el motor tiene de la página.
  • Los screenshots se transcriben. El texto dentro de un screenshot — etiquetas de UI, código, mensajes de error — se lee y se agrega al contenido de la página desde el punto de vista de la IA.
  • Los diagramas se interpretan semánticamente. Un flowchart de un proceso lo describe el modelo de visión en lenguaje natural, no solo lo etiqueta con el alt text.
  • Las imágenes hero contribuyen señal de tema. Una imagen hero que muestra de qué trata el artículo refuerza el tema para el motor de IA antes de leer body.

Implicaciones:

  • No pongas información crítica solo en texto de imagen. Repítela en el body para que sea inequívoca.
  • Las gráficas e infografías se ganan su lugar más que antes: los datos dentro ya son parte del entendimiento de la IA.
  • Una imagen hero limpia y on-topic es una pequeña pero real señal que los motores de IA pesan en retrieval.

Errores comunes de SEO de imagen

  • Filenames IMG_XXXX en producción. El default que nadie renombra.
  • JPEG/PNG cuando WebP serviría. 25–35% de penalización de tamaño sin beneficio.
  • Atributo alt faltante. Rompe lectores de pantalla; se lee el filename.
  • Lazy load del hero. Hunde LCP porque el elemento LCP espera para cargar.
  • Sin atributos width/height. Causa layout shift, daña el CLS.
  • Cargar la imagen de escritorio en móvil. Desperdicia ancho de banda, desacelera LCP. Usa srcset.
  • Hostear imágenes en otro dominio sin CDN. Agrega DNS lookup, desacelera todo.
  • Alt text idéntico en todo un artículo. No pasa información; los motores de IA y los lectores de pantalla penalizan ambos.

El veredicto

El SEO de imagen es mecánico, repetitivo y las reglas no cambian mucho año tras año. Usa filenames descriptivos en kebab-case que coincidan con la keyword de la página. Lanza WebP por default y AVIF cuando el ancho de banda importe más. Mantén las imágenes hero por debajo de 200 KB. Escribe alt text que describa la imagen a alguien que no la ve, con la regla heroAlt = H1 para el hero de la página. Configura width y height. Lazy load debajo del fold. Usa srcset para tamaño responsive. Los motores de IA ahora leen el contenido de la imagen de forma directa, lo que sube el valor de las gráficas y de un hero claro y baja el costo de hacer bien lo básico. Hazlo bien.

Preguntas frecuentes

Preguntas frecuentes

Respuestas rápidas a lo que nos preguntan antes de cada prueba.

El alt text es requerido en cada imagen que carga significado: fotos de producto, gráficas, diagramas, infografías, imágenes hero que anclan el tema de la página. El alt text debe estar vacío (alt=&quot;&quot;, no omitido) en imágenes puramente decorativas: líneas separadoras, texturas de fondo, íconos con etiqueta visible al lado. El movimiento equivocado es omitir el atributo alt del todo: rompe los lectores de pantalla, que terminan leyendo el filename.

Agenda una demo

Ve el OS en acción

Sesión de estrategia de 30 minutos con nuestro equipo de crecimiento. Te guiamos por la plataforma, analizamos tu performance SEO actual y te mostramos exactamente dónde están las oportunidades de crecimiento.

Sin compromisoAnálisis gratuito de tu sitioHabla con un estratega senior

Contexto rápido, después agendas

Tres preguntas para llegar preparados a la sesión. El calendario aparece al enviar.

Nunca compartimos tus datos. Una persona real te contesta.