Como atualizar o WordPress com segurança (sem quebrar o site)

Atualizado em 19/06/2026

Existe um paradoxo no WordPress: você precisa atualizar para se manter seguro, mas é justamente atualizar de qualquer jeito que mais quebra sites por aí. A solução não é fugir das atualizações — é fazê-las com método. Com backup, um ambiente de teste e a ordem certa, atualizar deixa de ser uma aposta e vira uma rotina previsível.

Por que atualizar é essencial

Antes de falar do "como", vale fixar o "porquê" — porque é ele que justifica todo o cuidado:

• Segurança. A maioria das invasões de WordPress explora falhas já conhecidas e corrigidas em plugins, temas e no núcleo. Quando uma correção é publicada, a falha vira pública também — quem não atualiza fica exposto a algo que o invasor já sabe como explorar.
• Correções de bugs. Atualizações resolvem erros e comportamentos estranhos, deixando o site mais estável.
• Compatibilidade. Versões novas acompanham mudanças do PHP e dos navegadores. Ficar para trás, cedo ou tarde, gera incompatibilidade e mais trabalho.

Por que atualizações às vezes quebram o site

Entender as causas ajuda a prevenir. Quando uma atualização derruba o site, costuma ser por um destes motivos:

• Incompatibilidade entre tema e plugin. A nova versão de um deles deixa de conversar com o outro, ou dois plugins passam a conflitar.
• Versão do PHP. Plugins e temas modernos exigem versões mais recentes do PHP. Se a hospedagem está com uma versão antiga, a atualização pode falhar — e o contrário também acontece, com código velho que quebra em PHP novo.
• Código customizado. Ajustes feitos no tema, em um plugin ou via snippets podem parar de funcionar quando a base muda — sobretudo se foram feitos sem boas práticas (como editar o tema em vez de usar um tema-filho).

O processo seguro de atualização, passo a passo

Esta é a sequência que eu sigo. Vale para um site simples e, com ainda mais rigor, para uma loja WooCommerce:

1. Backup completo antes de tudo. Arquivos e banco de dados, guardados fora do servidor. Sem backup recente, não comece. Veja como fazer backup de WordPress do jeito certo.
2. Teste em homologação (staging). Aplique as atualizações primeiro em uma cópia do site. Se algo quebrar, quebra ali — não na produção, na frente dos seus visitantes.
3. Atualize na ordem certa. Primeiro o núcleo do WordPress, depois os temas e, por fim, os plugins. Plugins críticos (pagamento, checkout, segurança) atualize um a um, testando entre cada um, para isolar imediatamente o que causar problema.
4. Teste as páginas-chave e o checkout. Abra a home, páginas internas, formulários e — em loja — o fluxo completo de compra. O que não foi testado é o que costuma estar quebrado.
5. Tenha um plano de retorno (rollback). Se algo der errado em produção, saiba exatamente como voltar: restaurar o backup ou reverter a versão do componente. Decidir isso antes evita o desespero depois.

Atualizar pela linha de comando (WP-CLI)

O painel resolve, mas para fazer a mesma coisa de forma rápida, repetível e fácil de registrar, o WP-CLI é imbatível — e funciona mesmo quando o wp-admin está pesado ou inacessível. A sequência segue a mesma ordem segura (núcleo, temas, plugins), sempre depois do backup e, idealmente, primeiro em staging:

# Antes de tudo: backup do banco (a rede de segurança)
wp db export backup-pre-update-$(date +%F).sql

# 1) Núcleo do WordPress
wp core update
wp core update-db          # aplica migrações de banco, se houver

# 2) Temas
wp theme update --all

# 3) Plugins — todos de uma vez...
wp plugin update --all

# ...ou um a um para isolar o que quebrar (plugins críticos)
wp plugin update woocommerce
wp plugin update nome-do-plugin --version=1.2.3   # fixa/reverte versão

# Sanidade: confere se os arquivos do núcleo batem com os oficiais
wp core verify-checksums

Se algo quebrar em produção, o WP-CLI também acelera o resgate: wp plugin deactivate nome-do-plugin desliga o culpado sem precisar de FTP, e você ganha tempo para investigar com calma. Para o roteiro completo de emergência, veja site fora do ar.

Atualizações automáticas: quando ativar e quando desativar

O WordPress permite automatizar atualizações, mas automático nem sempre é sinônimo de seguro:

• Ative para versões menores do núcleo (correções de segurança e bugs): o risco é baixo e a proteção, importante.
• Pense duas vezes antes de automatizar versões maiores, temas e plugins críticos — eles merecem teste em staging antes de subir.
• Desative o automático em sites onde uma quebra custa caro (lojas, sistemas com muitas integrações) e prefira o controle manual com homologação.

O controle fino fica no wp-config.php. Você pode desligar só as versões maiores do núcleo (mantendo as correções de segurança automáticas) ou desligar todo o motor de atualização automática:

// wp-config.php — antes da linha "/* That's all, stop editing! */"

// Mantém só atualizações MENORES do núcleo (segurança); desliga as maiores
define('WP_AUTO_UPDATE_CORE', 'minor');

// Ou desliga QUALQUER atualização automática de núcleo
define('WP_AUTO_UPDATE_CORE', false);

// Desliga TODO o motor de atualização automática (núcleo, plugins e temas)
define('AUTOMATIC_UPDATER_DISABLED', true);

Tipo de atualização, risco e recomendação

Nem toda atualização carrega o mesmo risco. Saber classificar o que está na sua frente define quanto cuidado aplicar:

Versões maiores e menores: a diferença que muda o risco

O WordPress usa numeração em que o salto importa. Uma atualização de 6.5.1 para 6.5.2 é uma versão menor: traz correções pontuais, com baixo risco. Já de 6.5 para 6.6 é uma versão maior: muda mais coisas por baixo e tem maior chance de incompatibilidade. Regra prática: versões menores podem seguir um fluxo mais ágil; versões maiores sempre passam por teste em ambiente de homologação antes da produção.

Atenção redobrada à versão do PHP

O PHP é a linguagem que roda o WordPress, e a versão dele importa muito. Versões antigas de PHP deixam de receber correções de segurança e podem ser incompatíveis com temas e plugins novos. Antes de uma atualização grande, vale conferir qual versão a hospedagem está usando e se ela é compatível. Mudar a versão do PHP também é uma atualização — e, como qualquer outra, deve ser testada em staging antes, porque pode quebrar código mais antigo.

Checklist final antes de clicar em "atualizar"

• Backup recente de arquivos e banco, fora do servidor, com restauração já testada.
• Ambiente de homologação pronto para receber as atualizações primeiro.
• Ordem definida: núcleo, depois temas, depois plugins (os críticos, um a um).
• Lista das páginas e fluxos a testar — incluindo o checkout, se houver loja.
• Plano de retorno claro: como reverter se algo der errado.
• Versão do PHP conferida e compatível com o que será atualizado.

Se isso parece muita coisa para fazer a cada atualização, é porque é mesmo — e é exatamente por isso que existe a manutenção. Em um plano de manutenção mensal, todo esse processo já é rotina, e você não precisa pensar nele. Se já está com o site quebrado depois de atualizar, vá direto para site fora do ar.