Manutenção de WordPress: o que fazer, com que frequência e por quê
O site foi lançado, ficou bonito, e ninguém mais mexeu. Um ano depois, o painel acumula avisos de atualização, um plugin de formulário parou de mandar o contato para o CRM e ninguém percebeu, e o provedor avisa que a versão do PHP vai sair de suporte. Nada disso quebrou o site de uma vez. Foi acumulando. Este guia mostra o que entra na manutenção de um site WordPress, com que frequência cada coisa precisa acontecer, onde está o risco de verdade e quando faz sentido cuidar disso dentro de casa ou terceirizar.
O que entra na manutenção
Manutenção não é só clicar em “atualizar”. É um conjunto de tarefas com frequências diferentes. A tabela abaixo é a rotina que recomendamos para um site de empresa; site com loja, área logada ou muitas integrações pede um ritmo mais apertado.
| Tarefa | Frequência | O que evita |
|---|---|---|
| Atualizar plugins, tema e núcleo, testando antes | Semanal (e na hora, para falha crítica) | Invasão por falha conhecida; atualização grande demais de uma vez |
| Backup completo guardado fora do servidor | Diário, com teste de restauração mensal | Perder o site junto com o servidor, ou descobrir que o backup não volta |
| Monitorar disponibilidade e certificado | Contínuo | Site fora do ar ou certificado vencido sem ninguém saber |
| Varredura de segurança e revisão de usuários | Mensal | Acesso de quem saiu do time; arquivo alterado sem autorização |
| Conferir formulários, eventos e conversões | Mensal e depois de toda atualização | Contato que não chega no CRM; mídia otimizando sem conversão |
| Velocidade e Core Web Vitals | Mensal | Site que foi ficando lento a cada plugin novo |
| Versão do PHP e do servidor | Semestral | Rodar em versão sem correção de segurança |
| Limpeza: plugins sem uso, rascunhos, revisões, spam | Trimestral | Superfície de ataque maior e banco inchado |
Por que o plugin é o ponto fraco
O núcleo do WordPress é revisado por um time grande e recebeu poucas falhas: seis em 2025. O problema está em volta dele. Das 11.334 falhas novas encontradas no ecossistema naquele ano, 91% estavam em plugins e 9% em temas, e o total cresceu 42% em relação a 2024[1].
Dois números do mesmo levantamento explicam por que a manutenção precisa de ritmo. Em 46% dos casos, a correção não estava pronta quando a falha se tornou pública. E a mediana até a primeira tentativa de exploração foi de cinco horas[1]. Quem atualiza uma vez por mês passa semanas exposto a falhas que já têm ataque automatizado circulando.
Isso não quer dizer que plugin é ruim. Quer dizer que cada plugin instalado é um fornecedor a mais, com um código a mais para manter. Menos plugins, e plugins de quem publica correção rápido, reduzem o trabalho e o risco ao mesmo tempo.
O que o WordPress já atualiza sozinho
Desde a versão 3.7, o WordPress instala sozinho as versões menores do núcleo, que trazem correção de manutenção e de segurança. Desde a 5.6, instalações novas também recebem sozinhas as versões principais. Plugins e temas só atualizam automaticamente em casos especiais, quando o time de segurança do WordPress decide forçar uma correção crítica[2].
Desde a versão 5.5, dá para ligar a atualização automática plugin por plugin, no próprio painel[3]. Vale para os plugins simples e bem mantidos. Para os que mexem em formulário, loja, cache ou integração com CRM, a atualização automática pode quebrar algo em silêncio. Nesses, a regra é atualizar numa cópia do site, testar o que importa e só depois publicar.
O PHP também envelhece
O WordPress roda em PHP, e cada versão do PHP tem data para parar de receber correção de segurança. Hoje, a 8.2 recebe correção só até 31 de dezembro de 2026, e a 8.3 até 31 de dezembro de 2027. As versões anteriores à 8.2 já estão fora de suporte[4]. Trocar a versão do PHP é tarefa de manutenção: precisa de teste, porque plugin antigo pode não rodar na versão nova.
Modo manutenção não é manutenção
Muita gente chega a este assunto procurando o modo manutenção do WordPress, a tela que avisa o visitante de que o site está em ajuste. Ele é útil na hora de uma mudança grande, mas não substitui a rotina. Site bem mantido quase nunca precisa sair do ar para atualizar, porque o teste acontece numa cópia antes.
Fazer dentro de casa ou terceirizar
| Caminho | Quando faz sentido | Onde costuma falhar |
|---|---|---|
| Alguém do time cuida | Site simples, poucos plugins, pessoa com tempo e método | Vira tarefa de “quando der”; ninguém testa formulário e medição depois de atualizar |
| Hospedagem gerenciada | Quer atualização de núcleo, backup e cache resolvidos pela infraestrutura | Cuida do servidor, não do que o site faz: formulário, integração e conversão ficam de fora |
| Manutenção contratada | Site gera negócio, tem integrações e medição que não podem parar | Contrato só por chamado, que age depois que quebrou, em vez de rotina preventiva |
O ponto de decisão não é técnico. É quanto custa, para a empresa, uma semana com o formulário sem entregar contato ou com a conversão sem chegar na mídia. Se a resposta é “muito”, a manutenção precisa de dono, rotina e prazo de resposta combinados.
Onde os dados moram
Quem precisa entrar
- 1 Faça o inventário. Liste plugins, tema, versão do PHP e o que cada plugin faz. Remova o que não é usado.
- 2 Monte uma cópia de teste do site, com a mesma versão de tudo, fechada para o Google.
- 3 Configure backup diário fora do servidor e restaure um backup de teste para provar que ele funciona.
- 4 Defina a rotina semanal: atualizar na cópia, testar a lista do que não pode quebrar e só então publicar.
- 5 Escreva a lista do que conferir depois de atualizar: envio de cada formulário, chegada no CRM, eventos no GA4, conversões da mídia, páginas principais abrindo.
- 6 Ligue o monitoramento de disponibilidade, certificado e segurança, com alerta para uma pessoa, não para uma caixa de e-mail genérica.
- 7 Registre cada mudança com data, o que foi atualizado e o resultado do teste. É o que permite achar a causa quando algo quebra.
Os erros que mais vemos
- Atualizar tudo de uma vez, direto no site no ar. Quando algo quebra, não dá para saber qual das vinte atualizações causou.
- Backup no mesmo servidor do site. Se o servidor cai ou é invadido, o backup vai junto.
- Nunca testar a restauração. Backup que nunca foi restaurado é uma aposta.
- Não conferir a medição depois de atualizar. O site abre normal, e a conversão parou de chegar no Google Ads. Ninguém vê por semanas.
- Plugin demais. Cada um é mais código para atualizar e mais uma porta. Muitos fazem a mesma coisa que outro já instalado.
- Contrato só por chamado. Quem só age quando algo quebra não faz a rotina que evita que quebre.
FAQ
Perguntas frequentes sobre manutenção de WordPress
As dúvidas de quem cuida de um site WordPress de empresa, ou está pensando em terceirizar esse cuidado.
Manutenção que também cuida da medição
Quando cuidamos de um site, a rotina inclui o que a maioria dos contratos deixa de fora: depois de cada atualização, conferimos se o formulário ainda entrega o contato no CRM com a origem e se as conversões continuam chegando na mídia. É o que evita descobrir o problema no fim do mês, olhando o número de leads. Se você quer saber como o seu site está hoje, comece pelo Diagnóstico grátis do site. E, se o site vai ser refeito, vale ler antes o que entra no custo de um site, inclusive o mensal.
Referências
- [1] Patchstack. State of WordPress Security in 2026 (dados de 2025). https://patchstack.com/whitepaper/state-of-wordpress-security-in-2026/
- [2] WordPress Developer Resources. Upgrading WordPress: automatic background updates. https://developer.wordpress.org/advanced-administration/upgrade/upgrading/
- [3] WordPress.org. Version 5.5: auto-updates for plugins and themes (11/08/2020). https://wordpress.org/documentation/wordpress-version/version-5-5/
- [4] PHP.net. Supported versions (consultado em setembro de 2026). https://www.php.net/supported-versions.php
