Problemas con miniaturas en WordPress: Regenerar miniaturas sin dejar el sitio caído

Qué está realmente roto (y qué no)

“Las miniaturas están rotas” es un síntoma, no un diagnóstico. La renderización de imágenes en WordPress es una canalización: subir original → generar tamaños intermedios → almacenar metadatos en la base de datos → servir el archivo correcto vía tema y srcset → opcionalmente reescribir vía CDN/plugin de offload → opcionalmente cachear en múltiples capas.

Modos de fallo comunes en miniaturas

• Archivos intermedios ausentes: los archivos redimensionados nunca se generaron, fueron eliminados o ahora residen en un backend de almacenamiento distinto.
• Rutas/URLs incorrectas: la base de datos apunta a un patrón de URL y el sistema de archivos contiene otro, o una reescritura del CDN está mal configurada.
• Desajuste de metadatos: los archivos redimensionados existen, pero wp_postmeta contiene tamaños obsoletos o dimensiones antiguas.
• Permisos/propiedad: WordPress puede leer los originales pero no puede escribir nuevos tamaños en wp-content/uploads.
• Fallos de procesamiento de imagen: errores de ImageMagick/GD, límites de memoria, restricciones de policy, o timeouts bajo carga.
• La caché miente: las miniaturas están arregladas, pero los usuarios siguen viendo 404s antiguos o HTML obsoleto con srcset viejos.

Regenerar miniaturas sólo arregla una categoría: tamaños intermedios faltantes + desajuste de metadatos. No arregla una reescritura del CDN rota, un bloque de ubicación de Nginx mal o una política de bucket S3 que niega lecturas.

Una idea parafraseada a menudo atribuida a gente de confiabilidad como Werner Vogels encaja aquí: Todo falla; diseña para que la recuperación sea rutinaria, no un acto heroico. Esa es la postura que quieres: regeneración rutinaria, acotada y observable.

Guía rápida de diagnóstico

Si sólo tienes 10 minutos antes de que alguien empiece una “sala de guerra”, haz esto en orden. Buscas el cuello de botella: almacenamiento, CPU, trabajadores PHP o caché/CDN.

1) Confirma qué está fallando: 404, tamaño incorrecto o error de procesamiento

• Si el navegador muestra 404s para nombres redimensionados (por ejemplo, image-300x200.jpg), probablemente necesites regeneración o alinear filesystem/offload.
• Si ves 200 OK pero estirado/cortado mal, suele ser metadatos obsoletos o un tema solicitando un tamaño que no existe.
• Si las subidas en admin fallan o la regeneración lanza errores, suele ser ImageMagick/GD, límites de PHP o permisos.

2) Revisa la forma de la carga del servidor: CPU vs I/O vs saturación de PHP-FPM

• CPU alta: el procesamiento de imágenes consume CPU; arregla el batching y la elección de herramienta (ImageMagick vs GD) y aplica límites.
• Alta espera de I/O de disco: el almacenamiento es el cuello de botella; reduce el ritmo, mueve directorios temporales o regenera fuera del host principal.
• PHP-FPM al máximo: tu regeneración está robando workers a tráfico en vivo; aíslala (usuario CLI, pool separado o ventana cron).

3) Verifica backend de almacenamiento y reescritura de URL

• Si externalizas a almacenamiento compatible con S3, confirma que los tamaños intermedios se almacenan y sirven, no sólo los originales.
• Si usas un CDN, confirma que no esté cacheando respuestas 404 para archivos redimensionados.

Luego elige la remediación menos riesgosa: regenerar en lotes controlados, precalentar cachés y purgar sólo lo necesario. El tiempo de inactividad es para migraciones de base de datos y pánico existencial, no para miniaturas.

Hechos interesantes y contexto histórico

Cosas cortas y concretas que explican por qué las miniaturas en WordPress pueden sentirse como una fotocopiadora encantada:

1. WordPress almacena metadatos de tamaño por attachment en wp_postmeta (el blob _wp_attachment_metadata), así que “arreglar archivos” sin actualizar metadatos puede seguir sirviendo srcset incorrectos.
2. Los tamaños intermedios se nombran por convención (p. ej., -300x200) lo que facilita el diagnóstico de 404—pero también hace que los miss de CDN sean muy persistentes.
3. Históricamente, muchos hosts compilaron PHP sólo con GD, así que la salida de imagen de algunos sitios cambia sutilmente cuando ImageMagick aparece (nitidez, perfiles de color, manejo de alpha).
4. Las imágenes responsivas de WordPress (srcset) llegaron al core años después de que los temas aprendieran “tamaños hard-coded”, por lo que los temas heredados suelen solicitar tamaños que no coinciden con los registrados.
5. La orientación EXIF es una fuente recurrente de problemas: los móviles rotan en metadata; algunos procesadores la aplican de forma distinta, así que las imágenes regeneradas pueden “dar la vuelta” respecto a las antiguas.
6. Los plugins de offload a almacenamiento de objetos cambiaron el sentido de “archivo existe”, porque la verdad ahora está dividida entre disco local, bucket remoto y reglas de reescritura en la base de datos.
7. Algunos CDNs cachean 404s por defecto; después de regenerar miniaturas, los usuarios siguen viendo imágenes faltantes hasta que purgas esas entradas negativas.
8. ImageMagick tiene historial de seguridad (las restricciones en policy son comunes), así que los hosts suelen distribuirlo con límites conservadores que rompen imágenes grandes durante la regeneración.
9. WordPress puede generar múltiples tamaños por cada subida, lo que significa que una regeneración “simple” puede multiplicar escrituras en disco rápidamente, especialmente con tamaños retina/extra de plugins.

Elige tu enfoque de regeneración (y el radio de impacto)

Opción A: regeneración con WP-CLI (recomendado para producción)

WP-CLI es aburrido en el mejor sentido: es scriptable, se puede batchear y puedes ejecutarlo con un usuario de baja prioridad y límites estrictos. También es más fácil de observar y detener.

Úsalo cuando: controles la shell, puedas programar ventanas fuera de pico y quieras un flujo reproducible.

Opción B: plugins desde el admin de WordPress (aceptable para sitios pequeños)

Los plugins que regeneran miniaturas desde wp-admin están bien hasta que no lo están. Se ejecutan dentro de los mismos workers de PHP-FPM que atienden a los usuarios y son más sensibles a timeouts. También son más difíciles de limitar con precisión.

Úsalo cuando: la biblioteca de medios sea pequeña, el tráfico sea bajo y no tengas acceso a shell.

Opción C: cola de trabajos en background (mejor para alta escala y multi-host)

Si ejecutas WordPress como una aplicación real—con workers, colas y pools separados—la generación de miniaturas pertenece ahí. Puedes limitar la tasa, reintentar y mantener la latencia web limpia.

Úsalo cuando: tengas múltiples servidores de aplicación, alto tráfico y ya estés operando workers.

Qué debes evitar

• Regenerar todo de una vez en un solo host a mitad del día.
• Purgar a ciegas toda la caché del CDN “por si acaso.” Eso es un DDoS autoinfligido contra tu origin.
• Cambiar tamaños de imagen y regenerar antes de verificar el uso por parte del tema. Generarás gigabytes de tamaños que nadie solicita.

Broma #1: Regenerar miniaturas es como ir al gimnasio—ir demasiado fuerte el primer día sólo prueba que aún puedes sentir dolor.

Tareas prácticas con comandos: qué ejecutar, qué significa y qué hacer después

Estas son tareas seguras para producción que puedes ejecutar mientras el sitio sigue en línea. La idea es medir, decidir y proceder en pasos controlados. Asumiré un host Linux típico con WordPress instalado en /var/www/html. Ajusta las rutas a tu entorno.

Tarea 1: Confirma que WordPress ve correctamente el directorio uploads

cr0x@server:~$ cd /var/www/html && wp option get upload_path
...output...

Qué significa la salida: Salida vacía suele significar el valor por defecto (wp-content/uploads). Un valor no vacío indica que WordPress usa una ruta personalizada.

Decisión: Si es personalizada, valida que la ruta existe y sea escribible; la regeneración la seguirá.

Tarea 2: Comprueba el editor de imagen activo (ImageMagick vs GD)

cr0x@server:~$ cd /var/www/html && wp eval 'print_r(wp_get_image_editor("wp-content/uploads/".date("Y")."/".date("m")."/test.jpg"));'
...output...

Qué significa la salida: Verás un objeto editor (por ejemplo, Imagick) o un error si el archivo de prueba no existe o el procesamiento falla.

Decisión: Si Imagick falla por policy/recursos, cambia a GD temporalmente o arregla los límites de ImageMagick antes de regenerar a escala.

Tarea 3: Verifica espacio en disco antes de generar miles de archivos

cr0x@server:~$ df -h /var/www/html/wp-content/uploads
...output...

Qué significa la salida: Te importa el espacio disponible y el tipo de sistema de archivos. Poco espacio libre significa que la regeneración tendrá éxito parcial y luego fallará—dejando un desorden.

Decisión: Si el espacio es justo, haz una de estas cosas: aumenta disco, regenera en un volumen más grande o reduce los tamaños generados.

Tarea 4: Estima el tamaño y número de archivos en uploads (impacto I/O)

cr0x@server:~$ du -sh /var/www/html/wp-content/uploads && find /var/www/html/wp-content/uploads -type f | wc -l
...output...

Qué significa la salida: El tamaño total + número de archivos da una pista de cuánto tardará un escaneo/regeneración y cuánta presión pondrás sobre inodos/capas de caché.

Decisión: Cuentas enormes te empujan hacia batching, ventanas fuera de pico y estrategia cuidadosa de caché.

Tarea 5: Identifica la variante específica de miniatura faltante desde logs

cr0x@server:~$ sudo tail -n 50 /var/log/nginx/access.log
...output...

Qué significa la salida: Busca GET /wp-content/uploads/...-300x200.jpg con estado 404 (o 403).

Decisión: Si los 404s son consistentes para ciertos tamaños, confirma que esos tamaños estén registrados en WordPress y/o en los metadatos.

Tarea 6: Confirma que el archivo realmente no existe en disco

cr0x@server:~$ ls -lah /var/www/html/wp-content/uploads/2025/11 | head
...output...

Qué significa la salida: Si ves originales pero no las variantes -WxH esperadas, es probablemente un problema de generación/metadatos.

Decisión: Procede a inspeccionar metadatos y a la regeneración controlada.

Tarea 7: Inspecciona metadatos del attachment para una imagen rota conocida

cr0x@server:~$ cd /var/www/html && wp post list --post_type=attachment --posts_per_page=5 --orderby=date --order=DESC
...output...

Qué significa la salida: Obtendrás IDs de attachments. Elige uno que muestre miniaturas rotas.

Decisión: Usa el ID para imprimir metadatos a continuación.

cr0x@server:~$ cd /var/www/html && wp post meta get 12345 _wp_attachment_metadata
...output...

Qué significa la salida: Verás datos serializados o estilo JSON; dentro hay entradas sizes con nombres de archivo y dimensiones.

Decisión: Si los metadatos referencian tamaños que faltan en disco, la regeneración está justificada. Si los metadatos no tienen tamaños, la generación probablemente falló originalmente.

Tarea 8: Ver qué tamaños de imagen cree WordPress que debe generar

cr0x@server:~$ cd /var/www/html && wp eval 'global $_wp_additional_image_sizes; print_r(array_merge(get_intermediate_image_sizes(), array_keys((array)$_wp_additional_image_sizes)));'
...output...

Qué significa la salida: Una lista de nombres de tamaño: thumbnail, medium, large, además de tamaños definidos por tema/plugin.

Decisión: Si ves una lista larga de tamaños personalizados que nadie usa, considera desactivarlos antes de regenerar para evitar trabajo inútil y crecimiento de almacenamiento.

Tarea 9: Regeneración en seco para un attachment único

cr0x@server:~$ cd /var/www/html && wp media regenerate 12345 --yes
...output...

Qué significa la salida: Informará tamaños generados o errores. Los errores suelen mencionar memoria, policy de ImageMagick o permisos.

Decisión: Si una imagen falla, no inicies una regeneración masiva. Arregla la causa del fallo primero; si no, sólo fabricarás un incidente más largo.

Tarea 10: Ejecuta regeneración masiva en lotes acotados (protege producción)

Primero, genera una lista de IDs de attachments y pásala en trozos. Esto te da un botón de parada y hace que el progreso sea medible.

cr0x@server:~$ cd /var/www/html && wp post list --post_type=attachment --field=ID --posts_per_page=1000 --orderby=ID --order=ASC > /tmp/attachment-ids.txt
...output...

Qué significa la salida: Un archivo de IDs. La ausencia de salida es normal; comprueba el tamaño del archivo si dudas.

Decisión: Si la lista es enorme, ejecutarás lotes durante horas/días con throttling.

cr0x@server:~$ split -l 200 /tmp/attachment-ids.txt /tmp/ids-batch-
...output...

Qué significa la salida: Crea archivos como /tmp/ids-batch-aa, cada uno con 200 IDs.

Decisión: El tamaño del lote es un mando de throttling. Lotes pequeños significan carga más baja y reversión más sencilla.

cr0x@server:~$ cd /var/www/html && time xargs -a /tmp/ids-batch-aa -n 1 wp media regenerate --yes
...output...

Qué significa la salida: Verás progreso por ID y el tiempo real. Si es lento, tu cuello de botella probablemente sea CPU o almacenamiento.

Decisión: Si la latencia sube o la carga se incrementa, pausa entre lotes, reduce tamaño de lote o ejecuta sólo fuera de pico. No seas valiente; sé consistente.

Tarea 11: Limita prioridad de CPU e I/O para la regeneración

cr0x@server:~$ cd /var/www/html && sudo nice -n 15 sudo ionice -c2 -n7 xargs -a /tmp/ids-batch-ab -n 1 wp media regenerate --yes
...output...

Qué significa la salida: Mismo output de WP-CLI, pero el SO deprioriza el proceso respecto al tráfico web.

Decisión: Si compartes la máquina con tráfico en vivo, usa esto por defecto. Si tienes workers dedicados, puedes relajarlo.

Tarea 12: Vigila la saturación de PHP-FPM mientras corre la regeneración

cr0x@server:~$ sudo ss -s
...output...

Qué significa la salida: Conexiones establecidas altas o un pico en estados TCP pueden indicar sobrecarga. Empareja esto con FPM status si está habilitado.

Decisión: Si las cuentas de conexión suben y la latencia de páginas empeora, reduce el ritmo de regeneración o aísla a un host/pool separado.

Tarea 13: Verifica que los archivos regenerados existen y los metadatos se actualizaron

cr0x@server:~$ ls -lah /var/www/html/wp-content/uploads/2025/11 | grep -- '-300x' | head
...output...

Qué significa la salida: La presencia de nuevas variantes redimensionadas indica que la generación de archivos tuvo éxito.

Decisión: Si los archivos existen pero el front-end sigue sirviendo URLs antiguas, estás en territorio de caché/HTML: purga selectivamente y asegúrate de que srcset se reconstruya.

cr0x@server:~$ cd /var/www/html && wp post meta get 12345 _wp_attachment_metadata | head
...output...

Qué significa la salida: Deberías ver entradas de tamaño actualizadas. Si no, la regeneración pudo haber escrito archivos pero fallado al persistir metadatos.

Decisión: Investiga permisos de escritura en la base de datos, rarezas del object cache o errores en la salida de WP-CLI.

Tarea 14: Confirma que la capa HTTP sirve el archivo regenerado (no un 404 cacheado)

cr0x@server:~$ curl -I https://example.com/wp-content/uploads/2025/11/image-300x200.jpg
...output...

Qué significa la salida: Te importan el estado HTTP, los headers de caché y posiblemente un header del CDN indicando HIT/MISS.

Decisión: Si sigue siendo 404 pero el archivo existe en el origin, tu CDN o reglas de reescritura están mintiendo. Purga la ruta específica y verifica el origin directamente.

Tarea 15: Detecta rápido errores de ImageMagick policy o memoria

cr0x@server:~$ cd /var/www/html && wp media regenerate 12345 --yes --debug
...output...

Qué significa la salida: El debug suele mostrar errores subyacentes como “not authorized” (policy.xml) o agotamiento de memoria.

Decisión: Si ImageMagick está bloqueado por policy, arregla policy/limits o fuerza GD; no sigas reintentando a ciegas.

Tarea 16: Si hay offload a almacenamiento de objetos, verifica miniaturas remotas

cr0x@server:~$ aws s3 ls s3://my-media-bucket/wp-content/uploads/2025/11/ | head
...output...

Qué significa la salida: Deberías ver variantes redimensionadas junto a los originales. Si sólo ves originales, tu plugin de offload puede no estar subiendo los tamaños intermedios.

Decisión: Arregla la configuración de offload y vuelve a ejecutar la regeneración (o re-sincroniza) para que las nuevas variantes también se suban.

Broma #2: Si regeneras miniaturas un viernes por la tarde, no eres un tomador de riesgos—eres un entusiasta del fin de semana.

Tres micro-historias corporativas desde las trincheras de las miniaturas

1) El incidente causado por una suposición equivocada

El sitio era una instalación de WordPress orientada al marketing con un catálogo modesto y muchas landing pages. Alguien cambió los tamaños de imagen del tema para “mejorar el rendimiento”. El equipo asumió que WordPress generaría perezosamente los nuevos tamaños bajo demanda cuando se solicitasen. Eso no es cómo funciona: WordPress genera tamaños intermedios en el momento de la subida, y la regeneración es una acción deliberada.

En pocas horas, el tema empezó a solicitar un nombre de tamaño que no existía para medios antiguos. El HTML incluía srcset apuntando a variantes -768x512 que nunca se crearon. El CDN, haciendo su trabajo un poco demasiado bien, cacheó un montón de respuestas 404. Los usuarios no sólo vieron imágenes faltantes; las vieron de forma consistente.

La primera respuesta fue “purgar todo”. Eso provocó una estampida hacia el origin, que ya estaba ocupado con un intento de regeneración por plugin desde wp-admin. Los workers de PHP-FPM ahora estaban divididos entre usuarios reales y procesamiento de imágenes. La generación de páginas se ralentizó, los timeouts aumentaron y de repente esto fue “una caída”, no “un problema de medios”.

La solución fue dolorosamente poco glamorosa: detener la regeneración por plugin, identificar los tamaños faltantes, regenerar en lotes por CLI con baja prioridad, purgar sólo las rutas de caché negativas y dejar que las cachés se calienten de forma natural. La lección: la suposición no sólo era errónea—creó una reacción en cadena entre CDN, origin y pools de PHP.

2) La optimización que salió mal

Otro equipo intentó ser listo. Movieron uploads a almacenamiento en red para que todos los app servers leyeran los mismos archivos. La promesa era “no más rsync, no más drift.” Funcionó para servir originales estáticos. La regeneración de miniaturas fue otra historia.

La regeneración implica muchas escrituras y metadatos. Cada attachment se convierte en múltiples escrituras, además de stats y escaneos de directorios. El NAS funcionaba bien con lecturas constantes pero se vio bombardeado por muchas escrituras pequeñas y operaciones de metadatos. El iowait se disparó, los procesos PHP se acumularon y la capa web empezó a comportarse como si estuviera limitada por CPU cuando no lo estaba.

“Optimizaron” aumentando la concurrencia: ejecutaron múltiples procesos de regeneración en paralelo. Eso convirtió al NAS en el único cuello de botella compartido y transformó un trabajo lento en un incidente lento. Al mismo tiempo, las copias de seguridad empezaron a perder su ventana porque el sistema de almacenamiento estaba ocupado procesando una tormenta de operaciones de archivo pequeñas.

El enfoque final fue ejecutar la regeneración en un host worker separado con almacenamiento local rápido y luego sincronizar los resultados en olas controladas. Menos elegante que la idea original, pero mantuvo la latencia de producción aceptable. Moral: escalar concurrencia sin entender el comportamiento del almacenamiento es sólo una manera ruidosa de encontrar nuevos límites.

3) La práctica aburrida pero correcta que salvó el día

Esta no entró en ningún currículum, precisamente por eso funcionó. Un equipo tenía la práctica estándar: antes de cualquier cambio de tema o plugin de manejo de medios, ejecutaban una pequeña regeneración canaria sobre un subconjunto de attachments y registraban tiempo por imagen y pico de carga.

Cuando migraron de GD a ImageMagick (por calidad), su canario inmediatamente sacó a la luz fallos en PNGs grandes debido a límites conservadores de ImageMagick. Aún no había impacto en clientes, porque no habían tocado el comportamiento en producción. Ajustaron límites y memoria de PHP en una ventana de cambio controlada, volvieron a ejecutar el canario y sólo entonces procedieron.

Después, cuando necesitaron una regeneración completa tras añadir nuevos tamaños para diseño responsivo, ya tenían un tamaño de lote seguro, un throttle conocido y un runbook con “condiciones de parada”. Lo hicieron durante dos noches con un registro de progreso simple y sin drama.

La práctica “aburrida” fue medir primero y cambiar una variable a la vez. No impresiona en una demo de sprint, pero evita la clase de fallos en cascada que convierten una tarea de medios en una actualización ejecutiva.

Listas de verificación / plan paso a paso (sin downtime)

Paso 0: Decide qué significa “arreglado”

• ¿Faltan miniaturas (404), están incorrectas (distorsionadas) o son obsoletas (recorte antiguo)?
• ¿El problema es global o limitado a años/meses específicos en uploads?
• ¿Hay almacenamiento de objetos/CDN involucrado?

Paso 1: Estabiliza producción antes de tocar la regeneración

• Congela cambios en tema y plugins hasta que la regeneración termine.
• Si el sitio ya está degradado, detén cualquier plugin de regeneración desde el dashboard primero.
• Confirma que tienes margen de espacio en disco y copias de seguridad funcionales de base de datos + manifiesto de uploads.

Paso 2: Regeneración canaria

1. Elige 10 attachments: mezcla JPEG/PNG, antiguo/nuevo, grande/pequeño.
2. Regenera esos IDs vía WP-CLI.
3. Verifica que los archivos existan y que el front-end sirva los tamaños correctos.
4. Mide tiempo por imagen y vigila CPU/iowait.

Paso 3: Elige el modelo de ejecución

• Host único + bajo tráfico: ejecuta lotes con nice/ionice, pausa entre lotes.
• Multi-host o alto tráfico: ejecuta en un worker dedicado o escala temporalmente y aísla el procesamiento.
• Offload a S3: confirma que los tamaños intermedios se suben y sirven; la regeneración local puede no ser suficiente.

Paso 4: Ejecuta lotes con condiciones de parada explícitas

Las condiciones de parada deben escribirse antes de empezar:

• La latencia de respuesta de página aumenta más allá de tu tolerancia normal.
• CPU o iowait cruzan un umbral que sabes que correlaciona con impacto de usuario.
• La tasa de error en WP-CLI supera un pequeño porcentaje (los fallos de procesamiento suelen repetirse).
• El espacio en disco cae por debajo de un margen seguro.

Paso 5: Estrategia de caché: purga selectiva, precalentamiento deliberado

• Purga sólo las rutas de miniaturas que devolvían 404 o contenido obsoleto.
• Prefiere permitir que las cachés se rellenen de forma natural; evita purgas completas del sitio.
• Si tu CDN cachea 404s, purga explícitamente esos objetos después de regenerar.

Paso 6: Verificación post-ejecución

• Muestra muestreos en tipos de contenido: posts, páginas de producto, rejillas de categoría, resultados de búsqueda.
• Comprueba corrección de srcset (los tamaños existen y son accesibles).
• Confirma que el almacenamiento de objetos contiene los tamaños generados si sirves desde él.
• Confirma que las copias de seguridad y los umbrales de monitorización vuelven a la línea base.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: miniaturas 404, pero los originales cargan

Causa raíz: tamaños intermedios ausentes, o metadatos que referencian tamaños no presentes (común tras cambios de tamaño en el tema o generaciones previas fallidas).

Solución: regenera miniaturas en lotes vía WP-CLI; verifica permisos de disco; purga entradas 404 en CDN para las rutas afectadas.

2) Síntoma: las miniaturas existen en disco, pero siguen 404 vía HTTP

Causa raíz: configuración del servidor web niega acceso, document root incorrecto o reescrituras de offload/CDN apuntan a otro lugar.

Solución: valida reglas de Nginx/Apache para /wp-content/uploads; comprueba symlinks; verifica mapping del origin en el CDN.

3) Síntoma: las imágenes se ven estiradas o recortadas mal tras regenerar

Causa raíz: el tema solicita un nombre de tamaño que ahora está registrado de forma distinta; o dimensiones hard-coded entran en conflicto con los tamaños generados.

Solución: audita los tamaños registrados y el uso en el tema; regenera sólo una vez que los tamaños estén finalizados; actualiza plantillas para usar funciones y nombres de tamaño adecuados.

4) Síntoma: la regeneración falla con errores de memoria

Causa raíz: memory_limit de PHP demasiado bajo para imágenes grandes; límites de recursos de ImageMagick demasiado conservadores.

Solución: aumenta límites de memoria apropiadamente, reduce tamaño de lote y prueba de nuevo con imágenes canarias; considera usar GD temporalmente para formatos problemáticos.

5) Síntoma: el sitio se ralentiza durante la regeneración incluso con batching

Causa raíz: cuello de botella compartido: I/O de disco, operaciones de metadata en almacenamiento en red o contención de workers PHP-FPM.

Solución: aplica nice/ionice; mueve la regeneración a un host worker dedicado; ejecuta fuera de pico; reduce concurrencia a un único proceso.

6) Síntoma: sólo algunos años/meses están rotos

Causa raíz: migración parcial, rsync que omitió carpetas antiguas o permisos distintos en directorios viejos.

Solución: verifica propiedad de directorios recursivamente; confirma que todas las rutas de uploads existen; regenera rangos dirigidos primero.

7) Síntoma: srcset incluye tamaños que no existen

Causa raíz: metadatos de attachment obsoletos; o un plugin añadió tamaños y luego los quitó, dejando metadatos antiguos.

Solución: regenera attachments para refrescar metadatos; asegura que la lista de tamaños sea estable; limpia caches de página para que el HTML actualizado se propague.

8) Síntoma: las miniaturas existen, pero el CDN sirve una imagen rota antigua

Causa raíz: el CDN cacheó la respuesta rota, a veces incluyendo el 404 o una versión obsoleta del objeto.

Solución: purga objetos específicos (no todo); si hay versionado disponible, cambia la clave de caché vía query-string/nombres de archivo versionados.

FAQ

1) ¿Tengo que dejar WordPress fuera de línea para regenerar miniaturas?

No. Debes tratar la regeneración como un trabajo en background por lotes. Usa WP-CLI, limita su ritmo y vigila la carga. El tiempo de inactividad es opcional; el caos no lo es.

2) ¿Por qué WordPress no generó automáticamente los nuevos tamaños de miniatura?

WordPress genera tamaños intermedios cuando se sube la imagen. Si cambias los tamaños registrados más tarde (cambio de tema, ajustes), los attachments antiguos no reciben esos nuevos tamaños a menos que regeneres.

3) ¿Cuál es más seguro: ImageMagick o GD?

ImageMagick suele producir mejores resultados y soporta más operaciones, pero también es más propenso a chocar con límites de policy/recursos en entornos alojados. GD es más simple y a veces más predecible bajo restricciones estrictas. En producción, “más seguro” significa “funciona con tus imágenes más grandes reales bajo carga”. Prueba con un canario antes de elegir.

4) ¿Puedo regenerar sólo los tamaños faltantes en vez de todo?

Sí, pero depende de tus herramientas y de cuánto estén rotos los metadatos. Un compromiso común es regenerar sólo attachments de un rango de fechas o sólo ciertos tipos de post, y luego ampliar. Si no puedes detectar tamaños faltantes de forma fiable, regenera todo lentamente.

5) ¿Por qué las miniaturas están correctas en wp-admin pero mal en el front-end?

wp-admin a menudo muestra un solo tamaño o usa un marcado distinto al de tu tema. El front-end usa srcset, tamaños personalizados y capas de caché. Si el HTML está cacheado, puede seguir referenciando nombres de archivo antiguos incluso después de regenerar.

6) ¿Qué pasa si mis uploads están externalizados a almacenamiento compatible con S3?

La regeneración en el host de la app puede sólo crear tamaños intermedios localmente. Debes asegurar que tu plugin de offload suba las nuevas variantes y que las URLs reescriban al bucket/CDN correctamente. Verifica existencia remota, no sólo local.

7) ¿Cómo evito saturar los workers de PHP-FPM?

No regeneres vía wp-admin en un sitio ocupado. Usa WP-CLI con nice/ionice, mantén baja la concurrencia y ejecuta en ventanas fuera de pico. Si puedes, usa un host worker dedicado para que los workers web queden para peticiones web.

8) ¿Debería purgar toda la caché del CDN después de regenerar?

Casi nunca. Purga sólo lo que cambió o lo que estaba cacheado incorrectamente (especialmente 404s cacheados). Una purga completa obliga todo el tráfico a volver al origin y puede crear un nuevo incidente que no tenga que ver con miniaturas.

9) ¿Por qué la regeneración a veces cambia la apariencia de la imagen?

Las librerías de procesamiento manejan nitidez, perfiles de color y orientación EXIF de forma distinta. Además, es posible que la configuración de recorte del tema haya cambiado. Espera algunas diferencias—verifica los contenidos más visibles antes de hacer la ejecución completa.

10) ¿Puedo ejecutar varios procesos de regeneración en paralelo para terminar más rápido?

Puedes, pero probablemente no deberías en almacenamiento compartido o en un origin único. La regeneración paralela es una forma fácil de convertir una tarea larga en una breve caída. Si quieres velocidad, añade workers dedicados y mide primero el comportamiento del almacenamiento.

Conclusión: próximos pasos que puedes ejecutar hoy

Las miniaturas rotas rara vez son “sólo miniaturas”. Son tu sistema indicando dónde es frágil: suposiciones de almacenamiento, deriva de metadatos, comportamiento del CDN y trabajo en background compitiendo con tráfico en vivo.

Haz esto a continuación:

1. Ejecuta la guía rápida de diagnóstico e identifica si tratas con archivos faltantes, metadatos obsoletos o reenvío/caché/offload mal configurado.
2. Regenera canarias: 10 attachments vía WP-CLI y confirma comportamiento en filesystem y HTTP.
3. Genera una lista de IDs de attachments y ejecuta lotes acotados con nice/ionice, con condiciones de parada explícitas.
4. Purga de forma precisa (especialmente 404s cacheados) y deja que las cachés se calienten en lugar de detonar todo el CDN.
5. Anota lo aprendido: tamaño de lote seguro, segundos promedio por imagen y los modos de fallo que encontraste. Tu yo del futuro te lo agradecerá con desgana.

Si tratas la regeneración como trabajo de producción—observable, limitado, reversible—no necesitarás tiempo de inactividad. Sólo necesitarás paciencia y la madurez para no “acelerarlo” haciendo que suene más fuerte.