Cómo convertir todas las imágenes de un sitio sin dañar el SEO

Por fin consigues la aprobación para convertir todas las imágenes del sitio web a WebP. El equipo de operaciones prepara el script en un fin de semana, lo ejecuta el domingo por la noche, y el lunes por la mañana te despiertas con un ping de Slack: las impresiones de búsqueda de imágenes han caído un 73 por ciento y las páginas de producto de tres socios muestran iconos de imagen rota porque habían enlazado directamente tus recursos. Cinco años de posicionamiento acumulado en Image Search, perdidos en 14 horas. Este es el desastre que corre todo proyecto de «convertir todo ya», y casi siempre se puede evitar.

Convertir todas las imágenes de un sitio de JPG a WebP suena como un script de una línea. En la práctica, puede destrozar tu posicionamiento en la búsqueda de imágenes, romper enlaces directos en sitios de terceros y confundir tus propias plantillas si no tienes cuidado. Aquí tienes el plan de migración que consigue las mejoras de tamaño de archivo y LCP sin perder el valor SEO que ya tienes.

Antecedentes: cómo ve Google las URLs de imagen

Google Image Search clasifica URLs de imagen individuales. Si has pasado cinco años acumulando enlaces e impresiones en /wp-content/uploads/2021/hero-photo.jpg y lo reemplazas por /wp-content/uploads/2021/hero-photo.webp sin una redirección, empiezas desde cero en esa URL. Multiplica por 8,000 imágenes y acabas de renunciar a una fuente de tráfico importante.

Las URLs de imagen acumulan señales igual que las URLs de página: backlinks, tasa de clics, HTML circundante, autoridad de la página padre. Cambiar la URL descarta ese historial. Google acaba redescubriendo la nueva URL, pero la curva de recuperación es de aproximadamente 3 a 6 meses y rara vez alcanza el nivel original.

Por qué una conversión ingenua daña el SEO

Otros modos de fallo:

• Otros sitios han enlazado directamente tus JPG — eliminarlos genera errores 404 e imágenes rotas en páginas de terceros, lo que vincula el estado roto a tu dominio.
• Las tarjetas sociales (Twitter, Facebook, LinkedIn) guardan en caché la URL de imagen antigua. Cambiar la URL sin actualizar la metaetiqueta og:image provoca vistas previas obsoletas durante meses.
• Las firmas de correo y los enlaces en PDF que referenciaban el JPG antiguo siguen rompiéndose en silencio.
• Tus propias plantillas pueden concatenar rutas de archivo de formas que se rompen al cambiar las extensiones.

El patrón correcto: servir formatos modernos sin cambiar URLs

En lugar de reemplazar el archivo JPG, sirve tanto la versión JPG como la WebP desde la misma ubicación lógica y deja que el navegador elija. Tres implementaciones, de más fácil a más difícil:

Patrón A: Etiqueta Picture (recomendado para HTML nuevo)

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

Genera los archivos WebP y AVIF usando JPG a WebP y JPG a AVIF para comprobaciones puntuales, o sharp/cwebp en un script de compilación para lotes. La URL del JPG permanece igual — Google sigue viéndola, los enlaces directos siguen funcionando, las tarjetas sociales siguen resolviéndose.

Patrón B: Negociación de contenido del lado del servidor

Configura Nginx o Apache para inspeccionar la cabecera Accept. Si el navegador anuncia image/webp, sirve el archivo .webp desde la misma URL; en caso contrario, sirve el JPG. La URL nunca cambia en el HTML, el navegador solo recibe bytes diferentes.

map $http_accept $webp_suffix {
    default "";
    "~*webp" ".webp";
}
location ~* \.(jpe?g|png)$ {
    add_header Vary Accept;
    try_files $uri$webp_suffix $uri =404;
}

El inconveniente es que las cachés de CDN deben respetar la cabecera Vary, y no todas las CDN lo hacen correctamente.

Patrón C: CDN de imágenes

Servicios como Cloudflare Images, ImageKit y el optimizador de BunnyCDN detectan la compatibilidad del navegador y sirven el formato adecuado automáticamente. Tú subes JPG; los visitantes con navegadores compatibles con WebP reciben WebP. La URL sigue siendo la misma. El coste es una tarifa mensual y una dependencia de terceros.

Paso a paso: la secuencia de migración que funciona

1. Auditar: Enumera cada recurso de imagen, agrupa por directorio o tipo de entrada, cuenta el total de bytes. Un simple find . -name "*.jpg" -exec du -h {} + en la carpeta de subidas es suficiente para empezar.
2. Generar WebP/AVIF paralelos: Usa un script (sharp, cwebp o imagemin) para crear .webp junto a cada .jpg. Mantén el JPG intacto. Para conversiones puntuales o para verificar la salida del script, pasa una muestra por el convertidor de imágenes.
3. Actualizar plantillas HTML: Reemplaza las etiquetas <img> por <picture> en tu tema. La mayoría de temas de WordPress necesitan esto en 3 a 5 archivos de plantilla.
4. Verificar con Lighthouse: Antes/después en 10 páginas representativas. LCP debería bajar notablemente.
5. Enviar sitemap actualizado: Aunque las URLs no cambiaron, un envío de sitemap nuevo desencadena un recrawleo.
6. Monitorear: Impresiones de Image Search en Search Console, datos de campo de Core Web Vitals y registros de 404. Cualquier cosa rara en los primeros 14 días se puede arreglar.
7. Auditar enlaces directos y backlinks: Usa ahrefs para encontrar sitios externos que referencien tus URLs de imagen y confirma que ninguna devuelva 404.
8. Comunicarse con socios: Si debes cambiar URLs, avisa con antelación a los grandes referentes.

Si debes cambiar URLs

A veces una migración de CMS o un cambio de marca obliga a cambiar la URL. En ese caso:

1. Redirigir cada URL antigua a su equivalente nueva con un 301. El patrón /wp-content/uploads/(.+).jpg a /new-cdn/$1.webp funciona en Nginx, Apache o Cloudflare Workers.
2. Actualizar sitemaps XML. Envía las nuevas URLs del sitemap de imágenes en Search Console. Google descarta las URLs antiguas en unos 6 meses una vez que ve redirecciones consistentes.
3. Auditar enlaces directos. Usa ahrefs o un escaneo de registros del servidor para encontrar tus URLs de imagen más enlazadas y prioriza la cobertura de redirección allí.
4. Actualiza las metaetiquetas og:image. Vuelve a compartir las URL afectadas mediante el Depurador de uso compartido de Facebook y el Validador de tarjetas de Twitter para vaciar la caché.

Errores comunes y cómo solucionarlos

• Error: eliminar JPG después de generar WebP. Solución: conserva ambos archivos; el JPG sigue siendo la alternativa y el ancla SEO original.
• Error: omitir el encabezado Vary: Accept en la negociación de contenido. Solución: agrégalo explícitamente para que las CDN almacenen en caché correctamente según el formato.
• Error: cambiar la extensión en la URL durante la migración. Solución: mantén .jpg en HTML incluso cuando negocies WebP internamente.
• Error: olvidar la regeneración de miniaturas en WordPress. Solución: ejecuta Regenerate Thumbnails más un optimizador después de la conversión por lotes.
• Error: volver a comprimir JPG ya comprimidos a WebP. Solución: optimiza el JPG una vez primero, luego convierte.
• Error: no purgar la caché de la CDN después del despliegue. Solución: invalida las rutas relevantes para que los visitantes vean los bytes nuevos.

Ejemplos reales

Wirecutter implementó una migración a WebP basada en la etiqueta Picture en 2024 sin cambiar ninguna URL. El LCP de CrUX mejoró en 1.2 segundos en las páginas de reseñas; las impresiones de búsqueda de imágenes aumentaron un 6 por ciento durante 90 días.

Un sitio de comercio de moda mediano intentó el enfoque perezoso (renombrar JPG a WebP). El tráfico de búsqueda de imágenes cayó un 60 por ciento; las páginas de producto vieron una caída de ingresos del 4 por ciento hasta que las URL se redirigieron con 301. Seis meses de recuperación.

El equipo gráfico de The New York Times utiliza negociación de contenido detrás de su CDN Fastly. Las URL en artículos publicados hace 10 años aún se resuelven a formatos modernos optimizados hoy, sin pérdida de SEO.

Enfoques de migración comparados

Enfoque	Riesgo SEO	Esfuerzo de ingeniería	Costo recurrente	Compatibilidad del navegador
Etiqueta Picture	Ninguno	Media	Ninguno	Universal
Negociación de contenido	Ninguno	Medio-alto	Ninguno	Universal
CDN de imágenes	Bajo	Bajo	Mensual	Universal
Cambio de URL + 301	Recuperable	Media	Ninguno	Universal
Cambio de URL, sin redirección	Catastrófico	Bajo	Ninguno	Universal

srcset e imágenes responsivas: preocupación separada, misma auditoría

Si tu sitio aún no usa srcset, agregarlo al mismo tiempo que la conversión de formato aumenta el beneficio. El patrón:

<img srcset="hero-800.webp 800w,
             hero-1200.webp 1200w,
             hero-2400.webp 2400w"
     sizes="(max-width: 800px) 100vw, 1200px"
     src="hero-1200.jpg"
     alt="..."
     width="1200" height="600">

Genera los tres tamaños desde una sola fuente. Para un JPG fuente de 2,400 px, la variante de 800 px podría ser 60 KB y la variante de 2,400 px 280 KB como WebP.

Configuraciones de compresión para la migración

WebP con calidad 80 es el valor predeterminado seguro para contenido fotográfico. AVIF con calidad 70 es aproximadamente equivalente pero tarda más en codificarse (10 veces más lento que WebP en la mayoría del hardware). Para tu migración masiva, genera WebP para todo y AVIF solo para imágenes principales sobre el pliegue donde cada byte cuenta.

Usa comprimir JPG como verificación de cordura en los JPG originales antes de generar WebP: un original con calidad 95 re-comprimido a WebP con calidad 80 puede mostrar artefactos de doble compresión. Optimiza el JPG primero si tenía sobrecalidad, luego genera el WebP.

Errores comunes

• Regeneración de miniaturas en WordPress. Si tu tema genera múltiples tamaños al subir (miniatura, mediano, grande), necesitas versiones WebP de todos ellos. El plugin Regenerate Thumbnails más un plugin de optimización se encargan de esto.
• Invalidación de caché de CDN. Después de la migración, purga la caché de la CDN o espera la caducidad natural. De lo contrario, los visitantes obtendrán una mezcla de JPG antiguos y WebP nuevos.
• Cachés de service worker. Las PWA pueden haber almacenado en caché los JPG antiguos. Aumenta la versión de caché en tu service worker para forzar una actualización.
• Plantillas de correo electrónico. Outlook no renderiza WebP. Mantén alternativas JPG para cualquier imagen utilizada en correos de marketing.

Consejos avanzados

1. Usa un feature flag para implementar la negociación de contenido al 10 por ciento del tráfico primero, observa las métricas, luego expande.
2. Genera AVIF solo para imágenes principales; WebP es suficiente para imágenes de cuerpo y la codificación es 10 veces más rápida.
3. Agrega datos estructurados con schema.org/ImageObject en imágenes clave durante la migración; esto desencadena un nuevo rastreo.
4. Audita tu robots.txt para asegurarte de que las URL de imágenes no estén bloqueadas accidentalmente.
5. Envía un sitemap de imágenes explícitamente junto con tu sitemap principal.
6. Ejecuta image compare en pares representativos de antes/después para verificar que la calidad sea aceptable.
7. Prueba las URL antiguas con enlace directo con curl -A "Mozilla" desde fuera de tu red — confirma que siguen devolviendo 200.

Preguntas frecuentes

¿Me penalizará Google por servir WebP en una URL JPG?

No — la negociación de contenido es estándar. Solo asegúrate de que Vary: Accept esté configurado correctamente.

¿Cuánto tarda Search Console en reflejar la mejora de LCP?

Unos 28 días, coincidiendo con la ventana móvil de CrUX.

¿Necesito AVIF si ya tengo WebP?

Beneficio adicional marginal. AVIF ahorra otro 20 por ciento en imágenes principales; no vale la pena para imágenes de cuerpo.

¿Qué pasa con las imágenes incrustadas en PDFs y correos electrónicos?

Mantén JPG para esos — ni los PDF ni la mayoría de los clientes de correo renderizan WebP de forma fiable.

¿Afecta la migración por igual a móvil y escritorio?

El móvil obtiene mayores ganancias porque el ancho de banda es el cuello de botella. Las ganancias en escritorio son reales pero menores.

¿Puedo hacer esto en un hosting compartido?

Sí, pero puede que necesites una CDN de imágenes ya que el acceso al shell es limitado.

¿Cómo revierto si algo sale mal?

Revierte el cambio en la plantilla. Los JPG aún están presentes, por lo que el sitio vuelve al estado anterior a la migración al instante.

Validación tras el lanzamiento

Ejecuta image info en una muestra aleatoria de las imágenes servidas para confirmar que las dimensiones y el formato coinciden con lo esperado. Verifica que curl -H "Accept: image/webp" contra una URL de imagen devuelva bytes WebP, mientras que curl sin cabecera Accept devuelva JPG. Revisa tres páginas en la herramienta de Inspección de URL de Search Console para confirmar que Google ve las imágenes y las renderiza. Combínalo con el convertidor de imágenes para conversiones continuas.

Hecha correctamente, una migración de JPG a WebP en todo el sitio reduce el peso total de las imágenes entre un 30 y un 50 por ciento, mejora el LCP entre 0.5 y 2.0 segundos en datos de campo, y no pierde nada de valor de posicionamiento. Hecha mal — reemplazando archivos en su lugar con nuevas extensiones — puede llevar 6 meses recuperarse. El enfoque con la etiqueta picture es el camino más seguro; el enfoque de negociación de contenido es el más limpio; el enfoque de cambio de URL es el que requiere más atención.

Manejo de contenido subido por usuarios

Los sitios con contenido generado por usuarios (foros, marketplaces, plataformas sociales) tienen un problema especial: el pipeline de subida debe manejar cualquier formato que los usuarios envíen. Los usuarios de iPhone suben HEIC, los de Android suben JPG, los diseñadores suben PNG, los contribuyentes ocasionales suben BMP o TIFF. Construye un paso de normalización en el endpoint de subida que detecte el formato de origen y convierta a tu formato web canónico (normalmente JPG o WebP).

Para HEIC específicamente, enruta a través de HEIC a JPG en la recepción — la mayoría de los navegadores no renderizan HEIC y muchas CDNs no lo entienden. Para formatos RAW de fotógrafos (CR2, NEF, ARW), convierte mediante RAW a JPG. El paso de normalización también te da un lugar para eliminar los metadatos EXIF (GPS, número de serie de la cámara) que los usuarios probablemente no quieran publicar.

Temporización del sitemap durante la migración

Envía tu sitemap XML actualizado a Search Console justo después del lanzamiento, pero antes de que la caché de la CDN se purgue por completo. Esto señala a Google que el contenido ha cambiado y desencadena un rastreo, que descubre las etiquetas picture y los archivos WebP paralelos. Si envías el sitemap antes de que los archivos WebP estén desplegados, Googlebot puede almacenar en caché una respuesta de error y retrasar el redescubrimiento.

Para sitios muy grandes, divide el sitemap por tipo de contenido (publicaciones, productos, medios) y envíalos en lotes. Esto te permite monitorizar el progreso del rastreo por lote y detectar problemas a tiempo. El archivo de índice del sitemap en el nivel superior apunta a los sitemaps por tipo, y Search Console informa de las páginas indexadas por sitemap hijo.

Visibilidad en la búsqueda de imágenes durante la migración

Durante 7 a 14 días después del lanzamiento, espera que las impresiones y los clics en la Búsqueda de Imágenes fluctúen. Algunas URL antiguas pueden caer brevemente mientras Google las revalida con el nuevo contenido. Esto es normal y se recupera. La ventana de riesgo es de 30 a 90 días para la reindexación completa del contenido modificado. Si después de 30 días ves caídas persistentes en URL de imágenes específicas de alto valor, solicita manualmente la indexación a través de la herramienta de Inspección de URL en Search Console.

Monitoriza el recuento de "Imágenes indexadas" en Search Console semanalmente durante la migración. Caídas bruscas significan que las URL están dando 404 o siendo redirigidas incorrectamente. Subidas graduales significan que la migración se está absorbiendo con normalidad. La curva de recuperación, cuando se hace correctamente, parece una breve caída del 5 por ciento seguida de una subida constante hasta la nueva línea base (más alta) a medida que las mejoras de LCP surten efecto y Google recompensa las páginas más rápidas.

Coordinación del lanzamiento con las partes interesadas

Una migración de imágenes en todo el sitio afecta a infraestructura, contenido, diseño y SEO. Saltarse la conversación de coordinación produce sorpresas desagradables. Informa al equipo de SEO sobre la estrategia de URL antes de lanzar. Muestra al equipo de ingeniería la secuencia de despliegue. Explica a los editores de contenido cualquier cambio en el flujo de subida. Confirma con el equipo de analítica que el seguimiento de páginas vistas no se romperá (no debería, pero verifícalo).

Programa el lanzamiento para una ventana de bajo tráfico — viernes por la tarde o domingo por la mañana dependiendo de tu audiencia — y ten un plan de reversión listo. La reversión para una migración con etiqueta picture es simple: revierte el cambio en la plantilla. La reversión para una migración de negociación de contenido es igualmente limpia: elimina la regla de la cabecera Vary. La reversión para un cambio de URL es más difícil, que es una razón para evitar ese enfoque.

Aseguramiento de la calidad después del lanzamiento

Las primeras 48 horas después de la migración son cuando surgen los problemas. Ejecuta un rastreo automatizado del sitio (Screaming Frog, Sitebulb, o un script personalizado usando curl) que visite cada página y verifique que cada imagen devuelva 200 OK. Marca cualquier URL de imagen que devuelva 404 o 5xx. Cruza los datos con el informe de "Cobertura" de Search Console después de 7 días para detectar cualquier cosa que Googlebot haya visto de forma diferente.

Revisa 20 páginas representativas en tres dispositivos: un navegador de escritorio con las herramientas de desarrollo de Chrome, un teléfono Android de gama media y un iPhone. Verifica que se esté sirviendo el formato correcto (Chrome muestra el content-type en el panel de Red de DevTools), que la imagen coincida visualmente con la original, y que no haya cambios en el diseño o degradación visible. Este control de calidad de 30 minutos detecta los problemas que los rastreos automatizados pasan por alto.

Beneficios a largo plazo más allá del LCP

El beneficio principal de una migración a WebP en todo el sitio es la mejora del LCP, pero hay otras ganancias menores que merece la pena conocer. Los costes de ancho de banda de la CDN bajan entre un 30 y un 50 por ciento porque cada imagen servida es más pequeña. La CPU del servidor de origen baja porque menos solicitudes de imágenes necesitan trabajo de codificación. Los tickets de soporte al cliente sobre "sitio lento en móvil" bajan porque la experiencia lenta en móvil ha mejorado. Incluso la huella de carbono de tu hosting baja porque se mueven menos datos por la red.

Estos efectos se acumulan a lo largo del año. Un sitio con un millón de páginas vistas al mes y una migración exitosa ahorra aproximadamente entre $200 y $600 al mes en ancho de banda de CDN, además de una pequeña pero medible mejora en las tasas de conversión gracias a páginas más rápidas. En 12 meses, el proyecto se amortiza muchas veces incluso antes de contar el beneficio SEO.

Qué esperar a los 90 días del lanzamiento

La señal más clara de que la migración funcionó es el gráfico de Core Web Vitals de Search Console. A los 28 días, la ventana móvil de CrUX se ha actualizado por completo y tu puntuación LCP debería reflejar la nueva línea base. A los 60 días, los grupos de "necesita mejorar" o "deficiente" deberían haberse reducido notablemente. A los 90 días, la posición promedio de tus URL de imagen principales en la Búsqueda de imágenes de Search Console debería haber subido ligeramente, típicamente un aumento del 5 al 15 por ciento, a medida que Google recompensa las páginas más rápidas.

Si a los 90 días los números se mantienen planos, vuelve a verificar la implementación. La mayoría de los casos de "la migración no hizo nada" resultan ser reglas de negociación de contenido que no se propagaron a la CDN, o etiquetas picture que recurrieron a JPG para todos los navegadores porque la fuente WebP estaba mal formada. La herramienta información de la imagen ayuda a diagnosticar si los bytes realmente servidos son los que esperas.