Um cliente me ligou numa quinta à tarde, em pânico. A loja WooCommerce dele parecia normal, mas ninguém conseguia comprar nada. Uma atualização automática de plugin tinha rodado, dois plugins entraram em conflito e o checkout parou de funcionar sem avisar ninguém. Nenhum alerta. Nenhum backup que eles soubessem usar de verdade. Com o cliente em outro fuso horário, levou quase quatro horas pra alguém perceber, e eles só descobriram quando um comprador mandou e-mail. Pela média de vendas daquele horário, essas quatro horas custaram uns CAD$400.
Eles rodavam aquela loja fazia quatro anos sem plano de manutenção nenhum. "Sempre funcionou sozinho", foi a explicação.
Manutenção de WordPress é assim: quando está bem feita, ninguém nota. Só dá pra notar quando falta.
O que é manutenção de verdade em 2026
O WordPress roda em cerca de 40% de todos os sites, segundo a W3Techs, e isso faz dele o alvo padrão dos robôs que varrem a internet atrás de falha conhecida. Eles não olham o tamanho do seu site. A Patchstack contou 11.334 vulnerabilidades novas no ecossistema WordPress em 2025, 91% delas em plugins. Nas falhas mais atacadas, a mediana ponderada entre a divulgação e o primeiro ataque foi de cinco horas. O plugin que você ia atualizar semana que vem pode ser alvo de alguém hoje à tarde.
Na prática, manutenção é três coisas: manter pequena a superfície de ataque, garantir que dá pra recuperar o site quando algo der errado e impedir a perda lenta de performance que se acumula quando ninguém está olhando.
A versão abstrata só vai até certo ponto. Aqui está como a falha apareceu de verdade.
Cinco jeitos de um site WordPress quebrar de verdade
Quatro destes aconteceram em sites em que eu trabalhei. O quinto eu consegui evitar até agora, e os números acima explicam por que eu não conto com isso. Cada um tem um post próprio com a correção completa; aqui vai a versão curta e a rotina que teria pegado o problema.
Uma atualização quebra o site pela metade
Num time com que trabalhei, um estagiário rodou uma atualização agendada de plugin. A versão nova do plugin não era compatível com a versão antiga de PHP que o servidor usava, então deu erro fatal no meio da renderização de algumas páginas. O site não caiu, e isso piorou tudo. As páginas carregavam com o layout quebrado, e a gente levou quase um dia pra ligar aquele HTML torto a um erro fatal de PHP vindo de um único plugin.
A solução não foi arrumar um estagiário melhor. A gente passou pra um fluxo de CI/CD: toda atualização vai primeiro pro staging, é testada, alguém lê os logs e só depois ela chega na produção. Esse fluxo teria pegado o problema antes de qualquer visitante ver. A ordem de recuperação que eu uso quando uma atualização derruba o site está em site WordPress fora do ar depois de atualizar.
O checkout quebra e o site continua no ar
É a história do começo deste post. O conflito em si era um problema comum de plugin. O que custou dinheiro foram as quatro horas, e um monitor de uptime não teria encurtado esse tempo, porque o site ficou no ar o tempo todo. Todas as páginas carregavam. Só a parte que recebe dinheiro estava quebrada.
O monitor que importa numa loja vigia pedido, não página: um alerta quando os pedidos param num horário em que normalmente entram, ou uma compra de teste agendada passando pelo checkout de verdade. O passo a passo do diagnóstico está em checkout do WooCommerce não funciona.
Uma vulnerabilidade de plugin é explorada
Nunca tive um site de cliente invadido por plugin. Com uma mediana de cinco horas nas piores falhas, isso é resultado da rotina, e só se mantém enquanto a rotina se mantém.
Nem toda atualização tem a mesma urgência. Correção de segurança em plugin que qualquer pessoa acessa sem login, como formulário, upload de arquivo ou qualquer coisa que exponha um endpoint REST, pula a fila semanal e passa pelo staging no mesmo dia. Atualização de funcionalidade num plugin que só o admin usa pode esperar o ciclo normal. O post sobre o wp2shell mostra como é o tipo rápido na prática.
Pagamentos falham em silêncio, lá no fundo
Em 2024 fui chamado por uma loja canadense de produtos regulados porque as renovações de assinatura viviam falhando, e fazia mais de seis meses que era assim. Os desenvolvedores anteriores respondiam com correções cada vez mais elaboradas, e cada camada que eles acrescentavam ficava entre o gateway de pagamento e o WooCommerce sem encostar na causa de verdade. O gateway dizia que os pedidos estavam pagos. O WooCommerce dizia outra coisa.
Seis meses é quanto uma falha dura quando ninguém compara os dois logs. Conferir o log de webhooks do gateway com o do WooCommerce numa rotina fixa, em vez de esperar reclamação de cliente, transforma meses em dias. O diagnóstico completo está em falhas de webhook de assinatura no WooCommerce.
O site vai ficando lento devagar
Numa loja, o banco de dados tinha enchido aos poucos de transients expirados, aqueles valores de cache temporário que os plugins criam e muitas vezes nunca apagam. Nenhum dia era visivelmente pior que o anterior, então ninguém percebeu nada. Limpar isso deixou o site carregando em menos de dois segundos, e mesmo assim ainda sobraram problemas de assets e de cache pra resolver.
Lentidão gradual nunca dispara alerta. Por isso ela precisa de um lembrete na agenda. O resto do trabalho de performance está no guia de velocidade do WordPress.
A rotina que pega cada um desses
Atualizações: staging, testes, logs e só depois produção
A maioria das atualizações de plugin corrige falha de segurança, e pular essas atualizações é deixar vulnerabilidade conhecida rodando num servidor público. Atualizar direto na produção é a outra metade do mesmo erro. O fluxo da primeira história é o método inteiro: atualize no staging, teste as páginas e o checkout, leia o log de erros do PHP, confira se a versão de PHP do servidor é suportada pelo plugin novo e só então suba pra produção. Em atualização grande (versão nova do WordPress, WooCommerce, o framework do tema), espere uma semana e deixe os outros acharem os conflitos primeiro.
Na parte de segurança: Wordfence como firewall de aplicação, com o WAF da Cloudflare na frente. Autenticação em dois fatores em todas as contas de admin, sem exceção. Se alguém na sua empresa torce o nariz pro 2FA, é porque não sabe como é a alternativa.
Backups: o teste do incêndio
Quase todo site WordPress tem algum backup configurado. Quase nenhum desses backups foi testado.
Backup que nunca foi restaurado é um arquivo largado em algum lugar que você torce pra funcionar no dia em que precisar. O backup da sua hospedagem é rede de proteção pros problemas de infraestrutura deles, não pros seus. Se você apagar uma tabela do banco por engano, ele pode não ajudar, e algumas hospedagens só guardam cópias de 24 a 48 horas.
O que eu recomendo: backup automático diário num lugar externo (Amazon S3, Backblaze B2 ou até Dropbox pra sites menores), com o UpdraftPlus ou uma ferramenta parecida. E uma vez por ano, restaure de verdade um desses backups num ambiente de staging. Trate como simulado de incêndio. Se não der pra levantar o site do zero, o seu processo de backup tem um problema que você quer descobrir agora, e não no meio de uma crise.
Performance: o problema da sujeira acumulada
O banco de dados vai enchendo de coisas que faziam sentido na época. Revisões de posts de 2019. Comentário de spam que ninguém limpou. Milhares de transients expirados, como os da última história. Nada disso quebra o site na hora, mas cada consulta ao banco fica um pouco mais lenta.
O limite prático de revisões por post: 5. Não existe cenário em que você precise de 200 versões salvas de uma página. Configure com uma linha no wp-config.php ou com um plugin como o WP Optimize, e rode uma limpeza do banco todo mês. Leva uns dois minutos.
O limite do faça você mesmo
Algumas tarefas de manutenção dá pra tocar sem ajuda profissional: a limpeza mensal, as atualizações de plugin no staging, o monitoramento de uptime com uma ferramenta gratuita tipo UptimeRobot. Se você é técnico e o site é institucional, isso provavelmente basta.
Se o site fatura, a conta muda. A pergunta deixa de ser "eu consigo fazer isso sozinho?" e vira "quanto me custam quatro horas de checkout quebrado, comparado com uma mensalidade de manutenção?". Pra loja da primeira história, a resposta foi CAD$400 numa tarde.
A outra coisa que muda é a resolução de conflitos. Quando uma atualização quebra algo que não é óbvio, achar a causa exige saber o que mudou, em que ordem e por quê. O erro fatal de PHP da primeira história levou quase um dia pra ser encontrado por um time que conhecia bem WordPress. Quem faz isso sozinho pela primeira vez pode perder bem mais que isso, e esse é o principal argumento pra ter manutenção e suporte WordPress num site que fatura.
O cronograma prático de manutenção
Toda semana: aplicar as atualizações no staging, testar as páginas principais e o checkout, ler o log de erros e subir pra produção. Correção de segurança em plugin acessível sem login não espera o dia da semana.
Todo mês: limpeza do banco (revisões, transients expirados, spam), comparar o log de webhooks do gateway com o do WooCommerce se você vende assinatura, e conferir se o staging ainda bate com a produção.
O tempo todo: monitor de uptime pro site e alerta de pedidos pra loja.
Uma vez por ano: restaurar um backup no staging. Revisar as contas de usuário e tirar o acesso de quem não precisa mais. Olhar os logs dos scans de segurança atrás de qualquer coisa que tenha passado batido.
É isso. Nada disso é complicado. Só precisa acontecer no calendário, que é justamente a parte que a maioria dos sites pula.
Quando foi a última vez que alguém leu o seu log de erros?
Quer alguém cuidando da manutenção gerenciada de WordPress pra você parar de pensar nisso? Me conta o que está rodando e eu digo como a rotina deveria ser.