Por qué la carpeta uploads de WordPress ocupa tanto espacio

La carpeta uploads de WordPress ocupa tanto porque WordPress nunca guarda un solo archivo por imagen. Cada subida genera un conjunto fijo de copias redimensionadas junto al original: siete de ellas para una foto del tamaño típico de una cámara, antes de que ningún tema o plugin añada más. No hay nada corrupto; simplemente estás viendo la multiplicación que ocurre en cada una de las subidas. La solución es dejar de generar los tamaños que nunca sirves y luego regenerar para que las copias antiguas se eliminen del disco.

Haz las cuentas

Sube un JPEG de 4000×3000 y mira dentro de /wp-content/uploads/2026/07/. No encontrarás un solo archivo. Encontrarás estos:

• photo.jpg — el original, sin tocar
• photo-scaled.jpg — una copia de 2560px que WordPress sirve en lugar del original
• photo-150x150.jpg — thumbnail
• photo-300x225.jpg — medium
• photo-768x576.jpg — medium_large
• photo-1024x768.jpg — large
• photo-1536x1152.jpg — el medium_large a 2×
• photo-2048x1536.jpg — el large a 2×

Eso es el original más siete derivados, solo del núcleo. Una subida de 3 MB puede acabar ocupando 5–6 MB en disco antes de que se ejecute un solo plugin. Ahora añade un tema que registra cuatro tamaños propios y WooCommerce (tres más), y una subida se convierte en catorce o quince archivos. Multiplícalo por una biblioteca de unos cuantos miles de imágenes y el tamaño de la carpeta deja de ser un misterio.

Si quieres el número exacto para tus propias dimensiones y tamaños registrados, la calculadora de almacenamiento de imágenes hace la multiplicación por ti.

Por qué ocurre

Cuando subes una imagen, wp_generate_attachment_metadata() llama a wp_create_image_subsizes(), que recorre cada tamaño devuelto por get_intermediate_image_sizes() y escribe un archivo por cada uno para el que el original sea lo bastante grande. El núcleo registra thumbnail, medium, medium_large, large, además de los tamaños retina 1536x1536 y 2048x2048 añadidos en WP 5.3. Cualquier tema o plugin que llame a add_image_size() se suma a ese mismo bucle, de forma permanente, en cada subida futura.

El archivo -scaled proviene de un mecanismo aparte: el filtro big_image_size_threshold, por defecto 2560px. Cualquier imagen más ancha recibe una copia escalada que pasa a ser la imagen “completa” servida, mientras el original permanece en disco. Así que una subida grande conserva tanto el original gigante como la versión de 2560px.

Puedes ver exactamente lo que tu configuración genera para una imagen concreta con el inspector de tamaños de imagen.

Cómo solucionarlo, en orden

1. Mide antes de tocar nada. Adivinar es perder el tiempo. Desde la raíz del sitio:

du -sh wp-content/uploads
find wp-content/uploads -type f \( -name '*.jpg' -o -name '*.webp' -o -name '*.png' \) | wc -l
du -ah wp-content/uploads | sort -rh | head -20

2. Cancela el registro de los tamaños que no sirves. La mayoría de los temas nunca muestran los tamaños 1536 y 2048, y muchos nunca usan medium_large. Quítalos:

// functions.php — stop generating sizes this site never outputs
add_action( 'init', function () {
    remove_image_size( '1536x1536' );
    remove_image_size( '2048x2048' );
} );

// Drop medium_large too, if your theme doesn't use the 768px size
add_filter( 'intermediate_image_sizes_advanced', function ( $sizes ) {
    unset( $sizes['medium_large'] );
    return $sizes;
} );

3. Regenera para eliminar las copias antiguas. Cancelar el registro solo detiene la generación futura: los archivos que ya están en disco se quedan hasta que regeneras:

wp media regenerate --yes

Las versiones recientes de WP-CLI eliminan sobre la marcha los archivos de tamaños que ya no están registrados. Si en cambio usas el plugin Regenerate Thumbnails, marca su opción “delete unregistered sizes”; sin esa casilla marcada, los archivos antiguos permanecen.

4. Caza los archivos huérfanos. Cambiar de tema nunca limpia los tamaños que registró el tema anterior. Eliminar entradas tampoco siempre borra sus derivados. Después del paso 3, si du -sh sigue muy por encima de lo que predice la calculadora, tienes huérfanos: archivos en disco a los que ningún adjunto hace referencia.

Qué no hacer

No desactives las imágenes escaladas para “ahorrar espacio”. El archivo -scaled es más pequeño que tu original. Desactivar big_image_size_threshold no elimina nada: solo hace que WordPress sirva el original completo de varios megabytes a cada visitante. Eso es una decisión de ancho de banda y de calidad, no una limpieza de almacenamiento, y por lo general empeora el peso de la página. La herramienta para desactivar imágenes escaladas explica cuándo es realmente la decisión correcta; reducir tu carpeta uploads no es uno de esos casos.

No elimines archivos directamente de uploads por SFTP. La lista de subtamaños de cada adjunto vive en su _wp_attachment_metadata. Borrar archivos a mano deja referencias rotas, y la regeneración no puede reconstruir un tamaño si has eliminado el original del que deriva. Borra el original y esa imagen desaparece para siempre.

No pongas thumbnail/medium/large a 0 en Ajustes → Medios esperando que la carpeta se encoja. Poner un tamaño a cero detiene la generación futura pero no toca nada de lo que ya está en disco, y la interfaz no puede llegar a medium_large, 1536, 2048 ni a ningún tamaño de tema o plugin: esos no están ahí.

No culpes a la base de datos. Una carpeta uploads pesada son archivos de imagen, casi nunca la base de datos. Optimizar las tablas no moverá esa cifra.

¿Sigues atascado?

Si la carpeta sigue siendo más grande de lo esperado después de regenerar, pasa tus dimensiones de imagen reales y tus tamaños registrados por la calculadora de almacenamiento y compara su cifra con du -sh wp-content/uploads. Una diferencia grande significa archivos huérfanos de un tema antiguo o de entradas eliminadas: no es el núcleo, y no es algo que vaya a arreglar más regeneración. Una diferencia pequeña significa que las cuentas son sencillamente lo que son: siete y pico archivos por subida, funcionando exactamente como está diseñado.