Por que a pasta de uploads do seu WordPress está tão grande

A pasta de uploads do seu WordPress está grande porque o WordPress nunca armazena um único arquivo por imagem. Cada upload dispara um conjunto fixo de cópias redimensionadas junto com o original — sete delas para uma foto de câmera de tamanho comum, antes de qualquer tema ou plugin adicionar mais. Não há nada corrompido; você está apenas vendo a multiplicação que acontece em cada upload. A solução é parar de gerar os tamanhos que você nunca serve e depois regenerar, para que as cópias antigas sejam apagadas do disco.

Faça as contas

Envie um JPEG de 4000×3000 e olhe dentro de /wp-content/uploads/2026/07/. Você não vai encontrar um único arquivo. Vai encontrar estes:

• photo.jpg — o original, intacto
• photo-scaled.jpg — uma cópia de 2560px que o WordPress serve no lugar do original
• photo-150x150.jpg — thumbnail
• photo-300x225.jpg — medium
• photo-768x576.jpg — medium_large
• photo-1024x768.jpg — large
• photo-1536x1152.jpg — o medium_large em 2×
• photo-2048x1536.jpg — o large em 2×

Isso é o original mais sete derivados, só do core. Um upload de 3 MB pode acabar ocupando 5–6 MB no disco antes de um único plugin rodar. Agora acrescente um tema que registra quatro tamanhos próprios e o WooCommerce (mais três), e um upload vira catorze ou quinze arquivos. Multiplique por uma biblioteca de alguns milhares de imagens e o tamanho da pasta deixa de ser um mistério.

Se você quer o número exato para as suas próprias dimensões e tamanhos registrados, a calculadora de armazenamento de imagens faz a multiplicação para você.

Por que isso acontece

Quando você faz o upload, wp_generate_attachment_metadata() chama wp_create_image_subsizes(), que percorre cada tamanho retornado por get_intermediate_image_sizes() e grava um arquivo para cada um que o original seja grande o suficiente para produzir. O core registra thumbnail, medium, medium_large, large, além dos tamanhos retina 1536x1536 e 2048x2048 adicionados no WP 5.3. Qualquer tema ou plugin que chame add_image_size() acrescenta a esse mesmo loop — de forma permanente, para todos os uploads futuros.

O arquivo -scaled vem de um mecanismo separado: o filtro big_image_size_threshold, com padrão de 2560px. Qualquer imagem mais larga que isso ganha uma cópia redimensionada que passa a ser a imagem “full” servida, enquanto o original permanece no disco. Ou seja, um upload grande mantém tanto o original gigante quanto a versão de 2560px.

Você pode ver exatamente o que a sua configuração gera para uma imagem específica com o inspetor de tamanhos de imagem.

Como resolver, na ordem

1. Meça antes de mexer em qualquer coisa. Chutar desperdiça tempo. A partir da raiz do site:

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. Cancele o registro dos tamanhos que você não serve. A maioria dos temas nunca exibe os tamanhos 1536 e 2048, e muitos nunca usam o medium_large. Remova-os:

// 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. Regenere para apagar as cópias antigas. Cancelar o registro só impede a geração futura — os arquivos que já estão no disco permanecem até você regenerar:

wp media regenerate --yes

As versões recentes do WP-CLI apagam os arquivos dos tamanhos que não estão mais registrados à medida que avançam. Se você usa o plugin Regenerate Thumbnails, marque a opção “delete unregistered sizes” — sem essa caixa marcada, os arquivos antigos permanecem.

4. Cace arquivos órfãos. Trocar de tema nunca limpa os tamanhos que o tema antigo registrou. Apagar posts nem sempre remove os derivados deles também. Depois do passo 3, se o du -sh ainda estiver bem acima do que a calculadora prevê, você tem órfãos — arquivos no disco que nenhum anexo referencia.

O que não fazer

Não desative as imagens scaled para “economizar espaço”. O arquivo -scaled é menor que o seu original. Desligar o big_image_size_threshold não apaga nada — só faz o WordPress servir o original de vários megabytes inteiro para cada visitante. Isso é uma decisão de banda e qualidade, não uma limpeza de armazenamento, e normalmente piora o peso da página. A ferramenta disable-scaled-images explica quando essa é de fato a escolha certa; encolher a sua pasta de uploads não é um desses casos.

Não apague arquivos direto da pasta uploads pelo SFTP. A lista de subtamanhos de cada anexo fica no seu _wp_attachment_metadata. Apagar arquivos na mão deixa referências quebradas, e a regeneração não consegue reconstruir um tamanho se você removeu o original do qual ele deriva. Apague o original e aquela imagem se foi para sempre.

Não defina thumbnail/medium/large como 0 em Configurações → Mídia esperando que a pasta encolha. Zerar um tamanho impede a geração futura, mas não toca em nada que já está no disco, e a interface não alcança medium_large, 1536, 2048 ou qualquer tamanho de tema/plugin — esses não estão lá.

Não culpe o banco de dados. Uma pasta uploads pesada é composta de arquivos de imagem, praticamente nunca do banco. Otimizar tabelas não vai mudar o número.

Ainda travado?

Se a pasta continua maior do que o esperado depois de regenerar, passe as dimensões reais das suas imagens e os tamanhos registrados pela calculadora de armazenamento e compare o valor dela com o du -sh wp-content/uploads. Uma diferença grande significa arquivos órfãos de um tema antigo ou de posts apagados — não é o core, e não é algo que mais uma regeneração vá resolver. Uma diferença pequena significa que a matemática é simplesmente essa: mais de sete arquivos por upload, funcionando exatamente como foi projetado.