Vale a pena atualizar o WordPress?

Sim: atualizar o WordPress vale a pena, e adiar só parece barato até ao dia em que um salto cobre várias major versions, um PHP fora de suporte e um plugin abandonado ao mesmo tempo. O núcleo, os plugins e o tema formam um sistema; atualizar só uma peça deixa as outras a ditar o risco.

Este guia cobre o porquê (segurança, compatibilidade, funcionalidades), o que corre mal sem manutenção, e um fluxo seguro com backup, staging e testes. Sem listas genéricas de «marketing digital» e sem fingir que um único clique no painel resolve uma loja WooCommerce custom.

#O que muda quando atualiza o WordPress

Cada release do núcleo traz uma combinação variável de:

1. Correções de segurança (CVE e hardening).
2. Correções de bugs reportados no Trac.
3. Melhorias de performance e de APIs internas.
4. Funcionalidades novas (blocos, editor, APIs) que temas e plugins passam a assumir.

As minor (por exemplo 6.7.1 para 6.7.2) focam-se em patches. As major mudam comportamento e expectativas de código. Por isso «atualizar WordPress» não é um gesto único: é decidir, por tipo de release e por tipo de site, se corre automático, se passa por staging, ou se agenda uma janela com rollback pronto.

A documentação oficial de atualização em wordpress.org descreve o mecanismo; o seu trabalho é o processo à volta.

#Por que atualizar WordPress é sobretudo segurança

Sites WordPress desatualizados são alvos de scanners que procuram versões conhecidas de núcleo e de plugins. Segundo a W3Techs, o WordPress corre em 40,0% de todos os sites (consultado a 14 de outubro de 2026), por isso os scanners têm muitos alvos. Não precisa de ser famoso: o tráfego de bots chega na mesma. Um patch no núcleo fecha uma porta; um plugin de formulário ou de cache com CVE aberto deixa outra.

Sinais de que a manutenção falhou:

• Aviso no Painel de «atualizações disponíveis» há semanas ou meses.
• PHP na versão que o host já marca como fim de vida.
• Plugins «não testados com a sua versão do WordPress» e sem commits recentes.
• Utilizadores admin partilhados ou passwords antigas (a atualização não corrige isto sozinha).

Atualizar não substitui hardening (HTTPS, permissões, least privilege, 2FA no admin). Complementa. Sem patches, o resto da higiene perde eficácia porque o atacante usa um buraco já documentado.

#Onde estão realmente as vulnerabilidades do WordPress

O relatório anual da Patchstack sobre 2024, State of WordPress Security in 2025, contabiliza 7966 vulnerabilidades novas no ecossistema WordPress nesse ano. A distribuição mostra onde está o risco:

O mesmo relatório indica que 33% das vulnerabilidades não tinham correção no momento da divulgação pública, muitas delas em plugins abandonados que provavelmente nunca serão corrigidos, e que é comum uma vulnerabilidade começar a ser explorada poucas horas depois de se tornar pública.

Duas conclusões práticas. Primeira: atualizar só o núcleo não chega, porque quase todo o risco está nas extensões. Segunda: um plugin sem versões novas há muito tempo não é «estável», é um candidato a ficar com uma vulnerabilidade por corrigir. Verificar a data da última versão de cada plugin faz parte da manutenção tanto como carregar em «Atualizar».

#Que versões do WordPress recebem correções de segurança

A página de segurança do WordPress.org (About security) indica que oficialmente só a versão mais recente do WordPress tem suporte. A equipa de segurança leva as correções a ramos antigos por cortesia, para que os sites que ainda não passaram para a última versão major recebam os patches críticos através das atualizações automáticas.

Dois exemplos com data mostram como funciona:

• WordPress 6.4.3 (30 de janeiro de 2024) corrigiu um bypass de envio de ficheiros PHP através do instalador de plugins (exigia privilégios de administrador) e uma vulnerabilidade de execução remota de código via cadeias POP. Trouxe também 5 correções do núcleo e 16 do editor de blocos, e os patches foram levados a todos os ramos a partir da 4.1 (anúncio oficial).
• WordPress 6.5.5 (24 de junho de 2024) corrigiu duas vulnerabilidades XSS (na HTML API e no bloco Template Part) e um problema de path traversal em sites alojados em Windows (anúncio oficial).

Os dois anúncios lembram que, nos sites com atualizações automáticas em segundo plano, o processo começa sozinho. É o argumento mais forte para nunca desligar as atualizações minor: o patch chega mesmo que ninguém entre no painel.

#Que ganhos de performance trazem as atualizações WordPress

Releases recentes do núcleo melhoraram queries, cache interno e o editor de blocos. Isso pode reduzir trabalho no servidor e tempo de edição. Não espere que uma major sozinha transforme um tema com 40 plugins e imagens sem srcset num Lighthouse perfeito.

O ganho prático de estar em dia:

• Plugins modernos assumem APIs actuais; deixa de precisar de shims e forks.
• O hosting recomenda um PHP mais recente, que de facto acelera.
• Ferramentas de blocos e padrões do núcleo substituem plugins de UI que só existiam para preencher lacunas antigas.

Se o site é lento, atualizar é necessário mas raramente suficiente. Continue a medir TTFB, LCP e o peso de scripts de terceiros depois do deploy.

#O que acontece se não atualizar o WordPress

Cenários típicos em produção:

1. Compromisso - malware, spam SEO, redirect para phishing, backdoors em wp-content.
2. Quebra em cadeia - um plugin novo exige núcleo recente; instala o plugin e o admin parte.
3. Host força PHP - o fornecedor sobe a versão de PHP; código legado do tema rebenta sem aviso útil.
4. Custo de catch-up - em vez de uma tarde de staging, precisa de auditoria, limpeza e reescrita de custom code.

Adiar «só mais um mês» acumula dívida. O dia do salto grande chega na mesma; só fica mais caro.

#Como atualizar WordPress em segurança passo a passo

#1. Backup com restauro testado

Backup de ficheiros e base de dados, com um restore testado pelo menos uma vez no trimestre. Plugins como UpdraftPlus ou o snapshot do host servem; o critério não é o logótipo, é saber restaurar. Guarde uma cópia fora do mesmo disco do site.

#2. Testar primeiro num staging ou clone

Copie produção para um ambiente com a mesma versão de PHP. Atualize ali primeiro. Em lojas: teste login, adicionar ao carrinho, checkout, cupões, webhooks de pagamento, e-mails transacionais. Em sites de conteúdo: login, guardar rascunho, formulários, pesquisa, páginas com builders.

#3. Em que ordem atualizar núcleo, plugins e tema

Sequência habitual:

1. Backup.
2. Atualizar plugins e tema que bloqueiam o núcleo (se o changelog o exigir).
3. Atualizar o núcleo.
4. Atualizar o resto dos plugins.
5. Smoke tests.
6. Só então limpar caches (página, objeto, CDN).

Se um plugin crítico não tem versão compatível, não force o núcleo em produção. Isole o problema: substitua o plugin, encontre um fork mantido, ou adianta o custom até haver caminho.

#4. Quando ativar os auto-updates

O WordPress permite auto-updates de minor do núcleo. Em blogs e sites institucionais simples, isso reduz a janela de exposição. Em WooCommerce com regras de envio custom, page builders e ERP, prefira janelas manuais ou CI que promove de staging.

Pode deixar auto-update ligado em plugins de baixo risco e manter manuais os que tocam pagamentos, memberships e cache.

#5. Testes de regressão visual

Em sites críticos para o negócio, uma vista de olhos rápida não chega. Ferramentas de regressão visual como Percy ou BackstopJS comparam capturas de ecrã antes e depois da atualização e apanham alterações de layout que passam despercebidas: um botão deslocado alguns píxeis, uma margem diferente, uma cor alterada. Isto pesa sobretudo depois de atualizar temas ou page builders como Elementor, Divi ou WPBakery, que controlam o aspeto de cada página. Atualize também os plugins um de cada vez, e não com «Atualizar todos»: se algo partir, sabe exatamente qual foi.

#O que faz o WordPress quando a atualização de um plugin falha

Há algumas versões que o núcleo tem duas redes de segurança para atualizações de extensões. Convém saber o que cobrem e o que não cobrem, porque nenhuma substitui o backup.

WordPress 6.3: reposição após uma atualização manual falhada. Segundo a nota de desenvolvimento da 6.3, antes de atualizar um plugin ou tema o WordPress move a versão instalada para wp-content/upgrade-temp-backup/plugins/ ou wp-content/upgrade-temp-backup/themes/. Se a instalação do pacote falhar (pacote vazio, impossibilidade de limpar ou criar a pasta de destino), a versão anterior volta ao seu lugar. Se a atualização correr bem, a cópia é apagada. Esta função não deteta um erro fatal de PHP que apareça depois de uma instalação bem-sucedida, e a pasta não serve para voltar atrás mais tarde.

WordPress 6.6: reversão das atualizações automáticas de plugins. O guia de campo da 6.6 inclui a reversão automática das atualizações automáticas de plugins quando é detetado um erro fatal de PHP. A proposta de integração descreve o mecanismo: depois da atualização, o WordPress faz um pedido loopback à página inicial; se detetar um erro fatal, repõe a versão anterior do plugin e avisa o email de administração. Durante as atualizações automáticas o site fica em modo de manutenção, e o plugin revertido volta a ser tentado na verificação seguinte.

A limitação importante é o próprio pedido loopback. Se o servidor o bloquear (por exemplo, uma regra de firewall ou autenticação HTTP), a proposta diz que isso é tratado como erro fatal e a atualização é revertida. Um plugin que parte apenas o checkout ou uma página interna também passa despercebido, porque a verificação é feita contra a página inicial. Por isso as lojas continuam a precisar de testar o checkout manualmente.

#Como configurar as atualizações automáticas do WordPress

A documentação oficial (Upgrading WordPress) explica que as atualizações automáticas em segundo plano chegaram com o WordPress 3.7 e distingue quatro tipos: núcleo (desenvolvimento, minor e major), plugins, temas e ficheiros de tradução. As atualizações minor do núcleo e as traduções estão ativas por omissão. Desde o WordPress 5.6, as instalações novas recebem também as versões major automaticamente, a não ser que seja detetado um checkout de controlo de versões. Plugins e temas só se atualizam sozinhos em casos especiais decididos pela API do WordPress.org, ou quando o administrador o ativa.

Esse interruptor por plugin e por tema chegou com o WordPress 5.5, lançado a 11 de agosto de 2020: desde então ativa ou desativa as atualizações automáticas de cada extensão nos mesmos ecrãs de Plugins e Temas (anúncio da 5.5).

Para fixar a política em código, o wp-config.php aceita estas constantes:

// Só atualizações minor do núcleo (segurança e manutenção)
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

// true: desenvolvimento, minor e major; false: nenhuma das três
// define( 'WP_AUTO_UPDATE_CORE', true );

// Desativa todas as atualizações automáticas (não recomendado)
// define( 'AUTOMATIC_UPDATER_DISABLED', true );

Para um controlo mais fino existem os filtros auto_update_plugin e auto_update_theme, e para o núcleo allow_major_auto_core_updates e allow_minor_auto_core_updates. Desligar tudo com AUTOMATIC_UPDATER_DISABLED corta o site dos patches que a equipa de segurança distribui precisamente por essa via.

#Como testar núcleo, PHP e plugins como uma só release

Ignorar o núcleo e atualizar plugins (ou o contrário) cria combinações que ninguém testou. Regra prática: trate o conjunto «núcleo + PHP + extensões activas» como uma release sua. Documente as versões depois de cada janela bem-sucedida (um simples ficheiro no repo ou uma nota no painel do projeto).

Plugins abandonados: se a última atualização tem anos e o autor não responde, o custo de o manter «porque ainda funciona» é o risco de um CVE sem patch. Plano B antes da crise: alternativa, custom mínimo, ou remover a funcionalidade.

#Como alinhar PHP e hosting com atualizações WordPress

O WordPress declara requisitos e recomendações de PHP por versão. Correr um núcleo recente em PHP 7.4 (ou pior) deixa-o sem suporte de segurança do runtime. Alinhe:

1. Confirme a versão de PHP no staging.
2. Corra a suite de smoke tests.
3. Suba PHP e WordPress na mesma janela quando o gap é grande.

Pedidos «não atualizem nada» ao hosting só empurram a fatura para o dia em que o certificado TLS ou a imagem do servidor muda à mesma.

A página de requisitos do WordPress recomenda PHP 8.3 ou superior, MySQL 8.0 ou MariaDB 10.11 ou superior, e HTTPS. O mínimo técnico é mais baixo: a API de versões do WordPress.org oferece o WordPress 7.1.3 com PHP 7.4 como mínimo. O facto de o WordPress arrancar em PHP 7.4 não torna esse PHP seguro. O calendário oficial do PHP (versões suportadas e ramos sem suporte) é este:

Em outubro de 2026 isto significa que o PHP 8.1 já não recebe patches e que o PHP 8.2 só os recebe até ao fim do ano. Um site que hoje corre em 8.2 deve planear já a passagem para 8.3 ou 8.4 em staging.

#O que verificar depois de atualizar o WordPress

• Painel carrega sem notices fatais.
• Front: home, um single, uma página chave de conversão.
• Formulários e login.
• Se WooCommerce: produto variável, carrinho, checkout em modo teste.
• Cron e e-mails (um pedido de recuperação de password ou um pedido de teste).
• Caches limpos; CDN a servir HTML fresco nas URLs críticas.
• Registo da versão do núcleo e dos plugins críticos.

#Quando pode adiar uma atualização WordPress

Esperar horas ou um ou dois dias após uma major para ler o release post e issues iniciais é razoável em sites de faturação alta. Esperar meses não é estratégia: é negligência com prazo.

Sites em modo arquivo ou campanha congelada ainda precisam de patches de segurança; «não vamos publicar conteúdo» não desliga os bots.

#Como atualizar WordPress em multisite e para clientes

Em multisite, uma atualização do núcleo afecta toda a rede. Teste num site de staging da rede, confirme themes network-activated e só depois promova. Um plugin «must-use» desatualizado parte todos os sites de uma vez.

Clientes que pedem congelar atualizações durante uma campanha: aceite uma janela curta e escrita (datas de início e fim), não um congelamento indefinido. Durante o freeze, monitorize avisos de segurança do núcleo e dos plugins de pagamento; se sair um CVE crítico, a campanha não justifica deixar a loja aberta a exploradores conhecidos.

Agências com dezenas de sites: um inventário (versão do núcleo, PHP, plugins críticos) e um calendário mensal batem o modelo «só quando o cliente reclama». O custo amortizado de staging partilhado é menor que uma limpeza de malware num fim de semana.

#O que acrescentaram as versões recentes do WordPress

Quem fica várias versões atrás não perde só patches. Algumas mudanças com data e fonte oficial:

• WordPress 6.5 (2024) acrescentou suporte para imagens AVIF: pode carregá-las, editá-las, redimensioná-las e guardá-las se a biblioteca de imagem do servidor (Imagick ou GD) o suportar, e o Site Health indica se está disponível (nota de desenvolvimento).
• WordPress 6.6 (16 de julho de 2024) introduziu a reversão automática das atualizações automáticas de plugins descrita acima.
• WordPress 6.8 (2025) ativou o carregamento especulativo no frontend: o núcleo faz prefetch dos URLs com eagerness conservadora, exceto para utilizadores com sessão iniciada ou sites sem ligações permanentes amigáveis, e o comportamento ajusta-se com o filtro wp_speculation_rules_configuration (nota de desenvolvimento).
• WordPress 6.9 (dezembro de 2025) introduziu a Abilities API, um registo onde o núcleo e os plugins declaram que ações podem executar, com esquemas e verificação de permissões.

Os plugins modernos começam a depender destas APIs. Um site preso a uma versão antiga acaba por não conseguir atualizar esses plugins e perde também as correções de segurança deles.

#Como a falta de atualizações afeta o SEO

A Google confirmou que a experiência de página, incluindo a velocidade, faz parte dos sinais de ranking. Versões antigas do WordPress em PHP desatualizado são mais lentas, o que se reflete nas Core Web Vitals, sobretudo LCP (Largest Contentful Paint) e INP (Interaction to Next Paint).

Um site comprometido por falta de atualizações pode ainda ser marcado como comprometido nos resultados da Google, o que faz cair a taxa de cliques. Os browsers mostram avisos de segurança quando detetam malware e afastam os visitantes antes de verem o conteúdo. Páginas de spam SEO injetadas aos milhares podem levar a uma ação manual da Google, e a recuperação exige limpeza completa, um pedido de reconsideração e semanas ou meses de espera.

#Que ferramentas ajudam a atualizar vários sites WordPress

Para agências e equipas com muitos sites, estas ferramentas centralizam a gestão de atualizações:

• ManageWP gere atualizações de dezenas ou centenas de sites a partir de um painel, com backup automático antes de cada atualização e verificação visual depois.
• MainWP é uma alternativa autoalojada que corre como plugin numa instalação WordPress central e controla as atualizações de todos os sites ligados.
• InfiniteWP oferece funcionalidades semelhantes, pensadas para agências com grandes volumes de sites.

Permitem agendar atualizações, aplicá-las de forma seletiva, gerar relatórios para clientes e reverter alterações quando algo corre mal.

#Conclusão

Vale a pena atualizar: reduz a superfície de ataque, mantém compatibilidade com o ecossistema e evita saltos traumáticos. O custo controlado é backup + staging + checklist. O custo não controlado é limpeza pós-hack ou reescrita de tema sob pressão.

Se preferir atualizações testadas em staging antes de tocarem na produção, o desenvolvedor WordPress pode encaixar núcleo, plugins e PHP no mesmo fluxo de manutenção, em vez de cliques isolados no painel quando já há avisos a vermelho.