
O WordPress 7.0, codinome Armstrong, foi lançado em 20 de maio de 2026. A versão traz um hub centralizado de recursos de inteligência artificial, um novo tema de administração, novos blocos, ferramentas de design aprimoradas e uma caixa de ferramentas para desenvolvedores. Como toda versão principal, a atualização exige preparação cuidadosa antes de ser aplicada em produção.
Este guia foi criado para criadores de sites, freelancers, gestores de sites e alunos WordPress que precisam de um roteiro técnico e aplicável. Você vai encontrar aqui uma matriz de risco por componente, um plano de atualização por tipo de site, checklist completo em três fases, comandos WP-CLI testados, alternativas de teste isolado com WordPress Playground e WordPress Beta Tester, roteiro para atualizar sites de clientes, plano de rollback e uma FAQ técnica com sete perguntas.
Versão atual deste checklist: o fluxo abaixo foi revisado para o WordPress 7.0.2, atualização de segurança publicada em 17 de julho de 2026. Em sites críticos, faça backup, reproduza a atualização em staging e valide login, formulários, pagamentos e tarefas agendadas antes de atualizar produção.
Se você ainda está na versão 7.0 ou 7.0.1, consulte o comunicado oficial de segurança. O WordPress recomenda atualização imediata para a versão corrigida.
Por que versões principais exigem atenção redobrada
Versões principais do WordPress, como a 7.0, alteram arquivos e pastas do núcleo do sistema. Diferente de atualizações de segurança menores, que costumam ser aplicadas automaticamente, versões principais exigem que o usuário clique em “Atualizar agora” na tela de Atualizações do painel. Isso acontece porque o impacto potencial sobre temas, plugins e personalizações é maior.
A documentação oficial do WordPress recomenda explicitamente fazer backup do banco de dados e dos arquivos antes de qualquer atualização. Essa recomendação aparece tanto na documentação de atualização do WordPress quanto na documentação da tela de Atualizações do painel.
Matriz de risco por componente
Antes de qualquer ação, avalie o risco de cada componente do seu site. A tabela abaixo classifica o nível de risco, o impacto potencial e a ação recomendada para cada área.
| Componente | Nível de risco | Impacto potencial | Ação recomendada |
|---|---|---|---|
| Core WordPress | Médio | Quebra de compatibilidade com hooks e funções depreciadas | Testar em staging antes de aplicar em produção |
| Tema ativo | Alto | Layout quebrado, erros fatais se o tema usar funções removidas | Verificar changelog do tema, testar em staging |
| Plugins | Alto | Conflitos, tela branca, funcionalidades quebradas | Atualizar todos os plugins antes do core, testar individualmente |
| Versão do PHP | Alto | Erros fatais se o PHP estiver abaixo do requisito mínimo | Confirmar versão do PHP compatível com WP 7.0 no servidor |
| Cache | Médio | Páginas desatualizadas, erros de CSS e JS após atualização | Limpar todos os caches após a atualização |
| Banco de dados | Médio | Tabelas desatualizadas podem causar comportamentos inesperados | Executar wp core update-db após atualizar o core |
| Integrações externas | Variável | APIs e webhooks podem parar de funcionar se dependerem de versão do core | Testar todas as integrações após atualização em staging |
Plano de atualização por tipo de site
Cada tipo de site tem um perfil de risco diferente. Um blog simples tolera mais experimentação do que uma loja WooCommerce com pedidos em andamento. Use a tabela abaixo para calibrar o nível de cuidado necessário.
| Tipo de site | Risco geral | Prioridade de backup | Ambiente de teste | Janela de manutenção recomendada |
|---|---|---|---|---|
| Blog simples | Baixo | Banco de dados e arquivos de tema | Opcional, mas recomendado | Qualquer horário de baixo tráfego |
| Site institucional | Médio | Banco de dados, arquivos, formulários e integrações | Staging recomendado | Fora do horário comercial |
| WooCommerce | Alto | Banco de dados completo, arquivos, pedidos, configurações de pagamento | Staging obrigatório | Madrugada ou domingo cedo |
| LMS (LearnDash, LifterLMS) | Alto | Banco de dados, progresso dos alunos, certificados, integrações | Staging obrigatório | Fora de períodos de aula ou provas |
| Site com plugins customizados | Muito alto | Backup completo, código-fonte dos plugins customizados | Staging obrigatório com revisão de código | Janela agendada com cliente, rollback planejado |
Checklist completo: antes, durante e depois da atualização
Fase 1: antes da atualização
- Confirmar a versão atual do PHP no servidor e verificar se ela é compatível com o WordPress 7.0.
- Fazer backup completo do banco de dados.
- Fazer backup completo dos arquivos do site, incluindo wp-content.
- Armazenar o backup em local externo ao servidor (Google Drive, S3, repositório Git).
- Anotar a versão atual do WordPress, de todos os plugins e do tema ativo.
- Verificar se todos os plugins têm atualização disponível e se foram testados com WP 7.0.
- Verificar o changelog do tema ativo para compatibilidade com WP 7.0.
- Desativar plugins de cache antes de iniciar a atualização.
- Ativar o modo de manutenção ou avisar usuários sobre a janela de atualização.
- Testar o site em ambiente de staging com a versão 7.0 antes de aplicar em produção.
- Verificar se há personalizações diretas em arquivos do core (prática não recomendada, mas comum em sites legados).
- Confirmar que o servidor tem espaço em disco suficiente para o processo de atualização.
Fase 2: durante a atualização
- Não fechar o navegador ou interromper a conexão durante o processo de atualização via painel.
- Acompanhar mensagens de erro ou avisos exibidos na tela de atualização.
- Após atualizar o core, executar a atualização do banco de dados.
- Atualizar plugins um a um se o site for crítico, ou todos de uma vez se já foram testados em staging.
- Atualizar o tema ativo após os plugins.
- Verificar se o arquivo wp-config.php e o .htaccess não foram sobrescritos.
Fase 3: depois da atualização
- Limpar todos os caches: plugin de cache, CDN, cache do servidor e cache do navegador.
- Testar o frontend do site em diferentes dispositivos e navegadores.
- Testar formulários de contato e fluxos de conversão.
- Testar o processo de compra completo se o site tiver WooCommerce.
- Verificar o painel de administração em busca de avisos ou erros.
- Verificar o log de erros do PHP no servidor.
- Confirmar que integrações externas (CRM, e-mail marketing, gateways de pagamento) continuam funcionando.
- Reativar plugins de cache com as configurações corretas.
- Documentar a atualização com data, versões anteriores e versões atuais.
Fluxo de atualização via painel do WordPress
O fluxo mais comum para a maioria dos usuários é via painel. Siga os passos abaixo na ordem indicada.
- Acesse o painel em Painel > Atualizações.
- Leia o aviso sobre backup exibido na tela. Confirme que o backup foi feito.
- Clique em Atualizar agora na seção do WordPress core.
- Aguarde a conclusão do processo. O WordPress exibirá uma tela de progresso.
- Após a conclusão, o WordPress pode exibir uma tela de boas-vindas com as novidades da versão.
- Volte para Painel > Atualizações e atualize os plugins disponíveis.
- Atualize o tema ativo se houver atualização disponível.
- Acesse Ferramentas > Atualizar Banco de Dados se o WordPress solicitar.
A documentação oficial confirma que versões principais exigem o clique manual em “Atualizar agora” e que o processo afeta os arquivos e pastas do núcleo do WordPress. Consulte a documentação oficial de atualização para detalhes adicionais.
Fluxo técnico via WP-CLI
O WP-CLI é a interface de linha de comando oficial do WordPress. Ele permite automatizar e auditar cada etapa da atualização com precisão. Todos os comandos abaixo devem ser testados primeiro em ambiente de staging. Confirme que o backup está feito antes de executar qualquer comando em produção.
Consulte a documentação oficial dos comandos em wp core update e wp core update-db.
# AVISO: teste em staging primeiro. Confirme backup antes de executar em producao.
# 1. Verificar a versao atual do WordPress
wp core version
# 2. Verificar se ha atualizacao disponivel para o core
wp core check-update
# 3. Fazer backup do banco de dados antes de atualizar
wp db export backup-antes-wp7.sql
# 4. Atualizar o core do WordPress para a versao mais recente
wp core update
# 5. Atualizar o banco de dados apos atualizar o core
wp core update-db
# 6. Para multisite, atualizar o banco de dados de toda a rede
wp core update-db --network
# 7. Atualizar todos os plugins
wp plugin update --all
# 8. Atualizar todos os temas
wp theme update --all
# 9. Verificar a versao apos a atualizacao
wp core versionSe o WP-CLI exibir um erro relacionado a core_updater.lock, significa que outra atualização está em andamento ou que um processo anterior foi interrompido. Nesse caso, remova o lock manualmente com cuidado ou aguarde alguns minutos e tente novamente.
# AVISO: execute apenas se tiver certeza de que nao ha atualizacao em andamento.
# Verificar se o lock existe
wp option get core_updater.lock
# Remover o lock se necessario
wp option delete core_updater.lockTestando com WordPress Playground e WordPress Beta Tester
WordPress Playground
O WordPress Playground executa o WordPress diretamente no navegador, sem necessidade de servidor ou hospedagem. É útil para testar blocos, plugins e comportamentos gerais da versão 7.0 de forma completamente isolada. Nenhuma alteração feita no Playground afeta seu site real.
Use o Playground para:
- Explorar o novo hub de IA e o novo tema de administração do WP 7.0.
- Testar se um plugin específico funciona na versão 7.0 antes de atualizar o site real.
- Demonstrar funcionalidades para clientes sem risco.
- Aprender sobre novos blocos e ferramentas de design da versão 7.0.
WordPress Beta Tester
O plugin WordPress Beta Tester permite instalar versões Nightly, Beta ou Release Candidate do WordPress diretamente pelo atualizador nativo do painel. Ele é indicado para ambientes de staging ou desenvolvimento, nunca para produção.
A própria página do plugin alerta para fazer backup antes de testar. Use o Beta Tester em um ambiente de staging que seja uma cópia fiel do seu site de produção para identificar conflitos com seus plugins e tema antes do lançamento oficial de uma versão.
Roteiro para freelancers: atualizando sites de clientes
Freelancers e agências que gerenciam múltiplos sites de clientes precisam de um processo padronizado. Improvisar a cada atualização aumenta o risco de erros e prejudica a relação com o cliente. Siga o roteiro abaixo.
Antes de contatar o cliente
- Audite todos os plugins e temas do site do cliente e verifique se há versões compatíveis com WP 7.0 disponíveis.
- Identifique plugins abandonados (sem atualização há mais de 12 meses) e avalie alternativas.
- Verifique se o site tem personalizações em arquivos do core ou em arquivos de tema pai.
- Prepare um ambiente de staging com cópia exata do site do cliente.
- Execute a atualização no staging e documente todos os problemas encontrados.
Comunicação com o cliente
- Informe o cliente sobre a atualização com antecedência mínima de 48 horas.
- Explique em linguagem não técnica o que será feito e qual é o risco.
- Defina uma janela de manutenção com horário de início e término estimado.
- Confirme por escrito (e-mail ou mensagem) que o cliente aprova a atualização.
- Informe o cliente sobre o plano de rollback caso algo dê errado.
Durante e após a atualização
- Execute a atualização seguindo o checklist das três fases descrito neste guia.
- Documente cada etapa com capturas de tela ou log de comandos WP-CLI.
- Envie ao cliente um relatório pós-atualização com versões anteriores, versões atuais e status de cada componente.
- Monitore o site por 24 a 48 horas após a atualização para identificar problemas tardios.
Plano de rollback e contingência
Mesmo com toda a preparação, problemas podem ocorrer. Ter um plano de rollback definido antes de iniciar a atualização é tão importante quanto o próprio processo de atualização.
Rollback via restauração de backup
A forma mais confiável de rollback é restaurar o backup completo feito antes da atualização. O processo varia conforme o plugin de backup ou o painel de hospedagem utilizado, mas o princípio é o mesmo: restaurar os arquivos e o banco de dados para o estado anterior.
# AVISO: execute apenas em caso de necessidade real de rollback.
# Confirme que o backup esta disponivel e integro antes de prosseguir.
# 1. Restaurar o banco de dados a partir do backup exportado antes da atualizacao
wp db import backup-antes-wp7.sql
# 2. Verificar a versao apos restauracao
wp core version
# 3. Limpar caches apos restauracao
wp cache flushRollback manual do core via WP-CLI
Se o problema for apenas no core e o banco de dados estiver íntegro, é possível fazer o downgrade do core para a versão anterior. Substitua 6.8 pela versão que estava instalada antes da atualização.
Atenção: o downgrade do core sem restaurar o banco de dados pode causar inconsistências. Prefira sempre restaurar o backup completo.
Plano de contingência por cenário
| Cenário | Sintoma | Ação imediata |
|---|---|---|
| Tela branca após atualização | Site exibe página em branco ou erro 500 | Ativar WP_DEBUG, verificar log de erros do PHP, desativar plugins via FTP ou WP-CLI |
| Painel inacessível | Erro ao acessar wp-admin | Verificar log de erros, restaurar backup, contatar suporte da hospedagem |
| Plugin incompatível | Funcionalidade específica parou de funcionar | Desativar o plugin problemático, buscar atualização do desenvolvedor ou alternativa |
| Layout quebrado no frontend | CSS ou JS não carregam corretamente | Limpar todos os caches, verificar conflitos de scripts, checar console do navegador |
| Erro no banco de dados | Mensagem de erro de tabela ou coluna inexistente | Executar wp core update-db, verificar integridade do banco com wp db check |
Erros comuns ao atualizar para versões principais
- Atualizar sem backup: o erro mais grave e o mais comum. Sem backup, não há rollback confiável.
- Atualizar diretamente em produção sem testar em staging: especialmente crítico para sites WooCommerce e LMS.
- Ignorar a versão do PHP: versões antigas do PHP podem ser incompatíveis com o WordPress 7.0 e causar erros fatais.
- Não atualizar plugins antes do core: plugins desatualizados têm maior chance de conflito com o novo core.
- Esquecer de limpar o cache após a atualização: causa problemas visuais e funcionais que parecem bugs do core mas são apenas cache desatualizado.
- Modificar arquivos do core diretamente: essas modificações são sobrescritas a cada atualização. Use hooks, filtros e plugins para personalizações.
- Não executar wp core update-db após atualizar o core: o banco de dados pode ficar com estrutura desatualizada.
- Usar plugins abandonados: plugins sem manutenção ativa são um risco de segurança e compatibilidade em qualquer atualização.
FAQ técnica
1. O WordPress 7.0 atualiza automaticamente ou preciso clicar manualmente?
Versões principais como a 7.0 exigem que o usuário clique em “Atualizar agora” na tela de Atualizações do painel. Atualizações automáticas são aplicadas por padrão apenas para versões de segurança menores. Você pode configurar atualizações automáticas para versões principais via wp-config.php ou via filtro, mas isso não é recomendado para sites críticos sem um processo de teste automatizado.
2. Qual versão mínima do PHP é necessária para o WordPress 7.0?
Verifique os requisitos oficiais na página de requisitos do WordPress antes de atualizar. O WordPress historicamente aumenta os requisitos mínimos de PHP a cada versão principal. Confirme a versão do PHP instalada no seu servidor e atualize se necessário antes de atualizar o core.
3. Posso atualizar plugins e temas ao mesmo tempo que o core?
Tecnicamente é possível, mas não é recomendado para sites críticos. Atualizar tudo ao mesmo tempo dificulta a identificação da causa de um problema caso algo dê errado. A ordem recomendada é: backup, atualização do core, atualização do banco de dados, atualização dos plugins, atualização do tema.
4. O WordPress Playground pode substituir um ambiente de staging real?
Não completamente. O WordPress Playground é excelente para testes rápidos e exploração de funcionalidades, mas não replica o ambiente real do seu servidor, seus dados de produção, seus plugins configurados e suas integrações externas. Para sites críticos, um ambiente de staging com cópia fiel do site de produção continua sendo indispensável.
5. O que fazer se um plugin essencial não tiver atualização compatível com WP 7.0?
Primeiro, verifique o repositório oficial do plugin e o fórum de suporte para saber se há uma atualização em desenvolvimento. Se o plugin for abandonado, avalie alternativas compatíveis. Se não houver alternativa imediata, adie a atualização do core até que o plugin seja atualizado ou substituído. Nunca atualize o core sabendo que um plugin crítico é incompatível sem ter um plano de contingência.
6. Como verificar o log de erros do PHP após a atualização?
O local do log de erros do PHP varia conforme a hospedagem. Em muitos servidores cPanel, o log fica em ~/public_html/error_log. Você também pode ativar o modo de depuração do WordPress adicionando as linhas abaixo ao wp-config.php temporariamente, apenas em ambiente de staging ou desenvolvimento.
Adicione ao wp-config.php: define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false );. O log será gravado em wp-content/debug.log. Remova ou desative essas linhas em produção após o diagnóstico.
7. Como atualizar uma rede multisite para o WordPress 7.0?
Em uma instalação multisite, o processo de atualização do core é o mesmo, mas a atualização do banco de dados deve ser executada com o parâmetro --network via WP-CLI: wp core update-db --network. Isso garante que todas as tabelas de todos os subsites da rede sejam atualizadas. Via painel, acesse a tela de Atualizações na área de administração da rede.
Resumo do fluxo completo de atualização
| Etapa | Via painel | Via WP-CLI | Obrigatório |
|---|---|---|---|
| Backup do banco de dados | Plugin de backup ou painel da hospedagem | wp db export backup.sql | Sim |
| Backup dos arquivos | Plugin de backup ou painel da hospedagem | Compactar wp-content via SSH | Sim |
| Testar em staging | Clonar site para subdomínio de staging | Clonar via WP-CLI ou rsync | Recomendado |
| Atualizar core | Painel > Atualizações > Atualizar agora | wp core update | Sim |
| Atualizar banco de dados | Ferramentas > Atualizar Banco de Dados | wp core update-db | Sim |
| Atualizar plugins | Painel > Atualizações ou Plugins | wp plugin update –all | Sim |
| Atualizar tema | Painel > Atualizações ou Temas | wp theme update –all | Sim |
| Limpar cache | Plugin de cache > Limpar tudo | wp cache flush | Sim |
| Testar frontend e backend | Navegação manual no site | wp site list, wp post list | Sim |
Recursos oficiais para consulta
- Documentação oficial de atualização do WordPress
- Documentação da tela de Atualizações do painel
- Documentação de gerenciamento de plugins
- Referência do comando wp core update
- Referência do comando wp core update-db
- WordPress Playground
- Plugin WordPress Beta Tester
- Documentação da versão WordPress 7.0
- Post oficial de lançamento do WordPress 7.0 Armstrong
Atualizar para o WordPress 7.0 é um processo seguro quando feito com preparação adequada. O risco real não está na atualização em si, mas na falta de backup, na ausência de testes em staging e na pressa de aplicar mudanças em produção sem validação. Siga o checklist, use as ferramentas certas e documente cada etapa. Seu site e seus clientes vão agradecer.