Higienização de WordPress: Pastas, Banco e Filas

“Eu já excluí os plugins e os temas que não usamos mais. O site está no ar e funcionando, a home carrega normalmente. Pra que contratar profissional?”

Esse tipo de questionamento chega o tempo todo quando estou em determinadas reuniões com clientes (e é comum para médias e pequenas empresas).

Isto é, ao não necessitar mais de determinados recursos (addons, plugins, trocas de temas, etc.), o cliente ou responsável pela gestão do site WordPress acessa o painel administrativo, desativa e exclui o que acha que deve.

Na visão do cliente, se a home e demais páginas abrem normalmente após estas exclusões, é normal que ele compreenda que a desinstalação foi efetivada com sucesso e que está tudo bem e devidamente limpo!

O problema é que partir desta premissa pode gerar vulnerabilidades sérias, ou até mesmo virar uma bomba relógio que a qualquer momento pode quebrar completamente o seu site e o acesso de seus potenciais compradores ao seu conteúdo.

Se você está acostumado a excluir plugins, temas, etc. somente no painel WordPress (mesmo clicando no “limpar tudo” do seu plugin de cache), sua instalação provavelmente vai conter lixo residual destes recursos em diferentes locais (e quantidades) do seu servidor.

Desativar e excluir um plugin somente no painel pode fazer com que ele seja de fato retirado da lista visível; apagar uma pasta residual em wp-content (e.g.) pode sumir com restos de código do PHP, mas isto não é tudo.

No cenário nacional de PMEs, é muito comum ver sites que até funcionam, páginas carregam, cliques para WhatsApp iniciam chat e formulários são submetidos como se tudo estivesse bem.

Mas por trás destas instalações, um verdadeiro show de horrores faz com que o site fique lento; recursos de processamento travem quando mais precisamos deles, erros de timeout ou falta de memória (de forma “aleatória”) quebrem coisas sem que tenhamos de fato compreensão clara do que está acontecendo.

Este é justamente o contexto de pequenas e médias empresas que, comumente tem seus sistemas gerenciados ao longo do tempo por estagiários, freelancers, múltiplas agências de marketing, ou até mesmo por funcionários qualificados mas que não tinham a preocupação de executar protocolos corretos e seguir documentação.

Desta forma, acredito que seja relevante pensarmos:

Quais problemas estão acontecendo e gerando falhas intermitentes ou perdas de performance?

Como eu posso estruturar uma rotina de inspeção e limpeza do meu site WordPress pra evitar problemas?

Então, se você quer jogar um jogo profissional em manutenção de back-end destes sistemas web, é preciso ir um pouco mais à fundo.

Vem comigo e vamos detalhar estes aspectos juntos!

NOTA TÉCNICA: Todas as informações contidas aqui retratam a minha experiência e o meu método de trabalho, você é o total responsável por alterações no seu site ou no site de seus clientes. Nos responsabilizamos exclusivamente em parcerias formalizadas por contratos. Em dúvida, visite o Aviso Legal.

O Site no Ar Não é o Mesmo que o Site Limpo

Funcionar é o mínimo que esperamos de um site, e ele pode sim funcionar, mesmo com diversos problemas em diferentes blocos do sistema. Pense em um carro, que pode ainda pode te levar ao escritório, mas está desalinhado, desbalanceado, com óleo saturado, fluido de freio com nível baixo, pneu careca, motor barulhento, etc. Acho que agora você me entendeu bem!

Mas, quando falamos de Higienização de WordPress, é outra métrica: aqui nos preocupamos com o que ainda ocupa disco, memória (banco de dados), agendamento de tarefas (wp-cron.php), etc.

E tudo isto precisa ser considerado, mesmo quando fazemos uma “simples” desinstalação de recurso ou troca de tema.

O Core (o programa WordPress em si) não varre uploads, não dropa tabela de e-commerce e não cancela job de RSS só porque você clicou em excluir no painel administrativo.

A documentação oficial de plugins pede o contrário da intuição do painel. Desativar serve para cache e permalink; desinstalar é o momento de apagar option e tabela. Todavia, muitos plugins pulam essa segunda etapa, outras vezes o operador só desativa e deixa a pasta no diretório public_html.

Logo, como profissionais, temos trabalho a fazer!

Onde o Resíduo Fica Depois da Desinstalação

Basicamente temos três camadas diferentes a serem analisadas. Três “custos” diferentes.

Estamos sempre nos embasando no protocolo L0 a L7, que é uma documentação interna desenvolvida ao longo dos anos de experiência. Veja bem, temos:

• Disco: pastas em wp-content e uploads, cópias WebP, logs, .wpress, CSS de tema antigo. Estas não executam PHP sozinhas. Mas inflam backup, migração e cota.
• Banco: wp_options (tabela de configurações), tabelas wp_wc_*, wp_tve_*, wp_smush_*. Option com autoload (carregamento automático a cada request) entra na memória em toda página, mesmo sem o plugin: problema!
• Fila: WP-Cron e Action Scheduler (biblioteca de tarefas em segundo plano, comum em plugins como WooCommerce e SMTP). O hook tenta rodar, o código já não está mais lá, só que o job continua na tabela.

E ainda temos um quarto detalhe chato: rewrite no .htaccess (regras do servidor Apache/LiteSpeed). No caso do nosso próprio site, por exemplo, o plugin Smush já tinha sido excluído mas a regra ainda mandava JPEG antigo para WebP numa pasta absolutamente órfã.

Isto é, pasta morta não “processa” (não consome recursos computacionais), mas autoload morto processa sim: o PHP lê aquele blob em cada hit.

Por isso frases como: “apaguei o plugin” e “o banco ficou mais leve” quase nunca coincidem.

Agora, nada melhor do que dados reais de situação real: um estudo de caso do nosso próprio site.

Recentemente fizemos a troca completa da nossa stack de front-end, saindo do construtor de páginas Elementor Pro (um inferno) para um tema nosso (ASC Theme), totalmente personalizado e desenvolvido para ser leve, responsivo, rápido e SEO friendly (usando o básico muito bem feito: CSS e Vite JS).

Fizemos inclusive um outro estudo de caso sobre análise de impactos práticos da transição, se quiser saber mais sobre isto, clique aqui.

Logo, após a troca de temas, é claro que iríamos rodar uma rotina de inspeção mais profunda. E isto que segue é o que encontramos e o que fizemos a respeito.

Estudo de Caso: Inspeção no Nosso Próprio Site

Data da inspeção: 31 de agosto de 2026, realizada no nosso site live (em funcionamento e acesso público https://felipecferreira.com.br/).

Método: WP-CLI, listagem de disco e cruzamento com plugins ativos. Não é auditoria de cliente nem laboratório PageSpeed, foi coisa feita dentro de casa.

Este recorte importa: Já tínhamos reduzido camadas de front-end na migração do Elementor para o tema ASC. Este texto cobre o que ainda restava em disco e banco depois de desinstalações antigas.

A pasta wp-content/plugins/ estava limpa: as 11 pastas batiam com os plugins ativos.

O lixo não estava “no plugin visível”, estava no lado que o painel não lista.

Disco: o que a Desinstalação Não Levou

O All-in-One não era “pasta fantasma de plugin apagado”. Era pior: ferramenta ligada por hábito, com arquivo de migração que a gente não restauraria por ali.

A hospedagem já guarda backup de conta. Mesmo assim o disco carregava 6,8 GB no live e outros 6,8 GB no staging velho.

O Smush WebP é o caso de ensino. Originais JPEG e PNG das capas atuais continuavam em uploads.

A pasta paralela só servia conversão antiga. Imagens de 2026 já saíam em JPEG; a regra órfã ainda interceptava as antigas.

Cruzamos WebP sem original: 377 arquivos. Não estavam na biblioteca de mídia nem no post_content das amostras. Lixo de mídia que ninguém publica mais, ainda no disco.

Nenhum visitante “via Smush”. O servidor ainda obedecia Smush.

Banco: Autoload Morto em Todo Request

Aqui o número muda de “cota de disco” para “custo por page view”.

No wp_options, somamos options cujo nome ainda citava Smush, Astra, ShortPixel, WooCommerce, UAG/Spectra, Feedzy, Thrive, iThemes ou AI1WM.

224 options mortas em autoload. 271 KB.

O autoload total do site era 786 options e 482 KB. Mais da metade do payload que o WordPress lê em toda request era configuração de plugin que já não existe.

A documentação de otimização do WordPress sugere manter autoload abaixo de 800 KB. Nós estávamos “dentro” do teto e, mesmo assim, 56% era lixo. Teto não é higiene.

Astra já não é o tema. astra-settings ainda embarcava 261 KB em cada hit.

Objetos PHP gravados como texto (Astra_Builder_Header, ShortPixel\Notices\NoticeModel) apareceram até num search-replace posterior. Sem o plugin, aquilo não pinta o site e continua sendo lido.

Tabelas inteiras também restaram:

• cerca de 20 wp_wc_* e 14 wp_woocommerce_*;
• 9 tabelas wp_tve_leads_* (Thrive Leads);
• wp_smush_dir_images.

Conteúdo residual no wp_posts: 1 produto Woo publicado e 1 grupo Thrive publicado. Não é loja. É fóssil de teste.

WP-Cron nativo daqueles plugins estava vazio. A sujeira tinha mudado de endereço.

Fila: Jobs de Plugin que Já Não Existe

O Action Scheduler ainda é necessário. O WP Mail SMTP usa essas quatro tabelas. Não se dropa o scheduler porque o Woo saiu.

O que se dropa (com backup e lista) são hooks órfãos:

• 655 feedzy_cron;
• 623 task_feedzy_cleanup_logs;
• dezenas de wrappers Woo (wc_admin_daily, tracker, rate limits).

Feedzy não está instalado. A fila ainda pedia Feedzy mais de mil vezes. Isso é manutenção invisível: worker que acorda, não acha o callback, registra falha, tenta de novo.

O painel de plugins estava honesto. A tabela de actions mentia por omissão.

O que Mudou Depois da Limpeza

A inspeção e a limpeza aconteceram no mesmo dia, 31 de agosto de 2026, em duas janelas.

De manhã saíram disco e rewrite. À noite saíram option, tabela, post fóssil e job órfão.

Método igual ao before: WP-CLI no live, LENGTH(option_value) no autoload, SHOW TABLES e contagem por hook no Action Scheduler. Sem plugin de “otimizar banco”. Sem TTFB nesta janela.

O disco não foi deletado. Foi para quarentena em pasta privada da conta. A cota da hospedagem ainda carrega esses 6,9 GB até a gente confirmar que nada quebrou.

O que o visitante deixa de carregar é o autoload. 482 KB foram a 209,5 KB. Os 271 KB mortos foram a zero.

As 44 tabelas saíram depois de confirmar zero pedido, zero cliente, zero item Woo e zero contato Thrive.

Na fila, apagamos o hook, não a biblioteca. Restam as quatro tabelas wp_actionscheduler_* e os jobs wp_mail_smtp_*.

Depois do product e do grupo Thrive, ainda achamos três CPTs irmãos do mesmo dia (janeiro de 2024). Conteúdo vazio, 0 conversão, URL em 404.

Havia também 15 termos Woo, dois deles ainda apontando para o product já apagado. Esses também saíram. Sem URL pública.

O staging velho foi recriado por cima, a partir do live já limpo. blog_public do staging ficou 0.

Home, Sobre e Biblioteca responderam HTTP 200 depois da limpeza.

O site abria antes. O que mudou foi o que o WordPress ainda lia sem ninguém ver.

O que Essa Medição Não Cobre

Não medimos TTFB (tempo até o primeiro byte) antes nem depois de apagar o autoload. Sem esse par, não dá para dizer que a página “ficou mais rápida”.

Também não generalizamos para “todo site WordPress tem 6,8 GB”. Este é o nosso histórico: loja de teste, tema Astra, Smush, ShortPixel, Spectra, Feedzy, Thrive e All-in-One ao longo dos anos.

O aprendizado que eu levo para consultoria é outro. Se a gente, com stack curto, SSH, WP-CLI e tema próprio, ainda encontra isso, o site que troca de prestador sem inventário acumula a mesma dívida sem ninguém nomeá-la.

Autoload, Tabela e Fila Não São o Mesmo Problema

Tratar tudo como “otimizar banco” gera dois erros. Ou você tem medo e não mexe. Ou você dropa tabela que o SMTP ainda usa.

• Autoload morto: prioridade alta. Entra em toda request. No nosso caso, 261 KB de Astra sozinho.
• Tabela Woo/Thrive vazia de negócio: prioridade média. Disco de MySQL e backup. Confirmar que não há pedido, cliente ou lead com valor jurídico.
• Job órfão: prioridade alta operacional. Acorda PHP à toa. Apagar a action, não a biblioteca.
• Pasta em uploads: prioridade de cota e backup. Confirmar URL no HTML, na biblioteca e no .htaccess antes de mover.

Desinstalar pelo painel não é o mesmo que uninstall.php bem escrito. A documentação de Uninstall Methods do WordPress deixa isso explícito. O mercado, na prática, ignora.

Nós recomendamos inventário com evidência (lista, tamanho, autoload, hook), não “plugin de limpeza com um clique” em produção sem backup.

O que Recomendamos na Prática

Esta é recomendação nossa, ok? Não é regra gravada no Core.

1. Tratar desinstalação como mudança de produção. Backup primeiro. Depois conferir pasta, option, tabela, cron e .htaccess.
2. Separar desativar de apagar. Desativar para teste. Apagar só com rotina de higienização.
3. Medir autoload. Soma de LENGTH(option_value) nas linhas com autoload ligado. No nosso site, o número útil não foi “482 KB totais”. Foi “271 KB mortos”. Depois da limpeza, o total foi a 209,5 KB e o morto foi a zero.
4. Não dropar Action Scheduler por causa de Woo. Filtrar hook. SMTP e outros plugins sérios ainda dependem da fila.
5. Não apagar uploads/2024 porque o nome lembra plugin. Capa, PDF e fonte do site vivem aí. Nós movemos só pastas nominais de ferramenta (smush, astra, woocommerce_uploads), com quarentena, não rm direto.
6. Staging velho é clone de lixo. O nosso staging obsoleto repetia os 6,8 GB. Recriar a partir do live limpo custa menos do que “higienizar o clone antigo”.
7. Quando a agência troca, pedir inventário. Plugins ativos, MU-plugins, drop-ins, autoload acima de N KB, tabelas que não são Core, jobs recorrentes. Sem isso, você herda a dívida e a conta de disco.

Para o leigo: você não precisa virar DBA. Você precisa de alguém que liste antes de apagar. O clique de “otimizar banco” de plugin genérico mistura transient (cache temporário, em geral regenerável) com option de loja e com fila de e-mail.

Em dúvida, não executa no live. Homologa. A gente faz assim no nosso.

Conclusão: Manutenção é Inventário, Não Só Update

Update de Core, tema e plugin é higiene sanitária. Higienização de WordPress é higiene de resíduo: pasta, option, tabela, rewrite e fila.

No nosso site, em 31 de agosto de 2026, a tela de plugins estava correta e o disco ainda guardava 6,8 GB de .wpress inúteis. O autoload ainda lia 271 KB de Astra, Smush, Woo e afins. A fila ainda chamava Feedzy mais de mil vezes.

Na mesma data, depois da limpeza, o autoload foi a 209,5 KB, o morto foi a zero, as 44 tabelas saíram e a fila órfã zerou. O disco órfão foi para quarentena (6,9 GB), não para a lixeira.

Nada disso “quebrava” a home. Tudo isso inflava backup, worker e memória. E tudo isso é o tipo de coisa que o cliente leigo nunca vê, porque o prestador anterior já tinha “limpo o plugin”.

A pergunta útil não é se o site abre. É o que ainda está ligado quando ninguém está olhando o painel.

Perguntas frequentes

Desinstalar o Plugin Já Limpa o Banco?

Não. O WordPress só limpa option e tabela se o plugin implementou desinstalação de verdade. Muitos não implementam. Outros deixam dado de propósito.

Autoload Alto Sempre Significa Site Lento?

Não. A documentação cita um teto perto de 800 KB. O nosso total era 482 KB e mesmo assim 56% era lixo. Depois da limpeza, o total foi a 209,5 KB e o morto foi a zero. O número que importa continua sendo o que ainda deveria existir.

Posso Apagar a Pasta de Uploads do Plugin na Mão?

Só depois de conferir URL no HTML, mídia e .htaccess, e se o arquivo é a única cópia da imagem. Nós quarentenamos, não apagamos na hora. Capa e PDF não são pasta de plugin.

Action Scheduler é Lixo do WooCommerce?

As tabelas, não necessariamente. Hooks com nome de Woo ou Feedzy, depois da desinstalação, sim. SMTP ainda usa o mesmo scheduler. Inventário por hook, não drop cego.

Por que Vocês Publicam Número do Próprio Site?

Porque E-E-A-T pede experiência observada, não caso anônimo inflado. Os dados são do nosso domínio. Não usamos base de cliente neste texto.

Referências

WordPress Developer Resources: Uninstall Methods, Optimization (opções com autoload).