As atualizações do WordPress são essenciais para manter a segurança, mas são também uma das maiores fontes de ansiedade para as agências web. Pedimos a Sébastien Cavaillé, Product Marketing Manager na OVHcloud, que explicasse como as Smart Automatic Updates foram pensadas para resolver esta questão.
Todas as agências que gerem sites WordPress estão familiarizadas com a tensão entre a necessidade de atualizações e a falta de tempo ou de recursos para as realizar. Por um lado, as atualizações não podem esperar: de acordo com o mais recente relatório anual da Patchstack, especialista em segurança WordPress, verificaram-se 11 334 novas vulnerabilidades em 2025, 91% das quais em plugins, 9% em temas e apenas seis no núcleo do WordPress. E os atacantes não perdem tempo: cerca de metade das vulnerabilidades de alto impacto são exploradas nas 24 horas seguintes à sua divulgação. Um plugin desatualizado é um dos pontos de entrada mais comuns para os atacantes e, quanto mais se adia a atualização, mais tempo o site permanece exposto.
Mas, por outro lado, cada atualização acarreta um risco: um plugin incompatível, um tema que deixa de ser apresentado corretamente, uma página que subitamente apresenta um erro. Para evitar correr esse risco às cegas, muitas agências verificam cada site manualmente. Isso consome uma quantidade considerável de tempo quando se gerem dezenas ou até centenas de sites. E quando o tempo escasseia, as atualizações são adiadas, por vezes durante semanas ou meses.
Para superar esta situação, as equipas da OVHcloud desenvolveram as Smart Automatic Updates, uma funcionalidade incluída no Managed Hosting for WordPress. Para compreender melhor a questão, falámos com Sébastien, que trabalhou no projeto.
Como surgiu a ideia para o projeto?
Surgiu diretamente dos nossos clientes. Na nossa plataforma de alojamento partilhado, alojamos cerca de 6 milhões de sites, e 80% deles funcionam com WordPress. Isso proporciona muito feedback, e uma necessidade era mencionada de forma constante: as pessoas sabem que têm de manter os seus sites atualizados, mas muitas já passaram por uma atualização que correu mal e não têm tempo para verificar cada site manualmente.
As atualizações automáticas tradicionais resolvem o problema de segurança, mas criam outro, porque muitas vezes se descobre que um site tem problemas quando um cliente liga. Por isso, queríamos uma automatização que verificasse antes de agir.
Uma história em particular ficou-nos na memória. Um programador web freelancer geria uma agência unipessoal e tratava sozinho de dezenas de sites WordPress para os seus clientes. Foi divulgada uma vulnerabilidade num plugin usado em muitos desses sites, e o programador web simplesmente não teve tempo para os atualizar a todos antes de um ataque. Em pouco tempo, 36 dos sites dos seus clientes foram pirateados e estavam a redirecionar os visitantes para sites maliciosos.
Repor os sites foi uma coisa. A parte mais difícil foi enfrentar os clientes. Cada um deles tinha-lhe confiado a gestão do seu site e cada um deles descobriu que os visitantes tinham sido redirecionados para páginas perigosas. Para um freelancer cujo negócio depende da reputação e do boca a boca, esse tipo de dano à credibilidade demora muito mais tempo a reparar do que os próprios sites.
Desde então, ele mudou os sites dos clientes para o Managed Hosting for WordPress e delegou em nós a tarefa de os manter atualizados. Esta história representa exatamente o tipo de situação que queríamos evitar: não porque o programador tenha feito algo de errado, mas porque ninguém consegue manter manualmente dezenas de sites atualizados, semana após semana.
Como são testadas as atualizações do WordPress?
O princípio é nunca testar uma atualização diretamente no site publicado.
Quais são as quatro fases de teste?
Todos os dias, verificamos se há novas atualizações disponíveis. Cada atualização é então testada em quatro fases.
Em primeiro lugar, fazemos um instantâneo do site tal como está hoje. Um rastreador começa na página inicial e segue os links de forma recursiva: se a página inicial tiver um link para a página A, que tem uma ligação para a página B, que tem uma ligação para a página C, então a página C também é analisada. Analisamos até 50 páginas por site. Para cada página, registamos o código de estado HTTP devolvido pelo servidor, que indica se a página carrega normalmente ou se apresenta um erro, juntamente com uma captura de ecrã da página completa com uma resolução de 1920×1080.
De seguida, clonamos o site para um ambiente de teste isolado. É nesse clone, e apenas nesse clone, que aplicamos as atualizações ao WordPress, aos temas e aos plugins.
Em terceiro lugar, analisamos o clone exatamente da mesma forma que o site original, com as mesmas páginas, os mesmos códigos de estado HTTP e as mesmas capturas de ecrã.
Por fim, comparamos os dois. Essa comparação confirma se a atualização pode ser aplicada à produção.
O que torna uma atualização válida?
Têm de ser cumpridas três condições:
- Os códigos de estado HTTP são idênticos. Se uma página que antes funcionava passar a apresentar um erro, a atualização é bloqueada.
- As capturas de ecrã correspondem, com uma pequena tolerância para diferenças visuais.
- Todas as atualizações de temas e plugins foram instaladas sem erros.
Por definição, a comparação visual é muito rigorosa. Um pixel é considerado diferente quando se dá uma alteração de qualquer um dos seus valores de vermelho, verde ou azul, mesmo que seja apenas uma unidade. Não existe a menor tolerância de cor. O que toleramos é uma pequena proporção de pixels alterados: até 5% da página. Portanto, o limiar mede a percentagem da página que sofreu alterações, e não a percentagem de alteração de cada pixel.
Antes de fazer cada captura de ecrã, aguardamos também alguns segundos, para permitir que as animações de carregamento e efeitos semelhantes terminem.
Como se evitam falsos alarmes?
Muitos sites têm carrosséis, animações ou conteúdos que mudam constantemente. Esse foi um dos problemas mais interessantes que tivemos de resolver. Nos primeiros testes, ficámos surpreendidos com a quantidade de atualizações que estavam a ser sinalizadas como falhas, apesar de nada parecer errado quando verificávamos os sites manualmente. Quando analisávamos as capturas de ecrã, os culpados eram quase sempre os mesmos: sliders da página inicial que tinham avançado para a imagem seguinte, contadores regressivos em sites de eventos, widgets de «publicações mais recentes» ou feeds de redes sociais incorporados que tinham sido atualizados entre duas capturas. As atualizações estavam em ordem; as páginas estavam simplesmente ativas.
A solução foi fazer várias capturas de ecrã de cada página com alguns segundos de intervalo. Se a página mudar por si própria entre duas capturas de ecrã, o sistema sinaliza-a como dinâmica e exclui-a da comparação visual. No entanto, estas páginas não ficam sem verificação: os seus códigos de estado HTTP continuam a ser comparados, pelo que uma página dinâmica que comece a apresentar um erro continuará a bloquear a atualização. Assim que adicionámos esse passo, os falsos alarmes reduziram-se drasticamente e pudemos voltar a confiar na comparação visual.
Até onde vai a análise?
Concentrámo-nos no que é mais importante: as páginas que os seus visitantes realmente veem. Na prática, isso abrange o núcleo da maioria dos sites: a página inicial, as secções principais e as páginas mais importantes pelas quais os visitantes navegam.
As páginas que não podem ser alcançadas a partir da homepage, mesmo que indiretamente, não fazem parte da análise. Isso é intencional: se nenhum link conduz a uma página, os visitantes também não conseguem aceder a ela ao navegar no site, pelo que não é aí que uma atualização com problemas os afetaria.
Aplica-se a mesma lógica a áreas protegidas por início de sessão, como contas de cliente ou o painel de gestão. Cada site gere a autenticação à sua maneira, por isso optámos por nos concentrar nas páginas públicas, onde podemos realizar verificações fiáveis e consistentes em grande escala.
A ideia não é substituir a perícia de uma agência, mas sim assumir as verificações repetitivas que seriam feitas manualmente, site após site. Isso liberta tempo para o trabalho que só as agências podem fazer.
Quando um teste é bem-sucedido ou falha
O que acontece quando a validação falha?
Nada acontece no site publicado, e é precisamente esse o objetivo. Se não se cumprir algum critério, as atualizações não são aplicadas. O site continua a funcionar exatamente como antes.
O cliente recebe então um e-mail a explicar por que razão a validação falhou. Há quatro causas possíveis:
- Os plugins ou os temas não puderam ser totalmente atualizados no site de teste.
- A página inicial apresentou um erro 4xx ou ficou inacessível, pelo que o teste não pôde ser realizado.
- As respostas HTTP diferem entre o site original e o clone.
- As capturas de ecrã diferem entre os dois.
O e-mail também dá acesso ao site clonado, onde as atualizações foram aplicadas. A agência pode ver o problema, corrigi-lo diretamente no clone e, de seguida, acionar a atualização de produção assim que tudo estiver em ordem.
Quisemos ser firmes neste ponto: a automatização trata do trabalho repetitivo, mas nunca toma uma decisão arriscada em nome da agência. Em caso de dúvida, o controlo recai sempre sobre um humano.
Como é que uma atualização validada entra em produção?
Assim que se dá a sua validação, a atualização é logo aplicada à produção e o cliente é notificado.
Não existe uma reversão automática, uma vez que a atualização já foi testada antes de entrar em produção. Porém, se surgir um problema posteriormente, o cliente pode restaurar um backup com um só clique a partir da Área de Cliente OVHcloud. Os backups são feitos site a site, em vez de para todo o plano de alojamento, pelo que uma agência pode restaurar o site de um cliente sem tocar em nenhum dos outros.
É possível excluir plugins das atualizações?
Não, e é uma escolha deliberada. Quando alguém quer excluir um plugin, é geralmente porque teme que uma atualização crie problemas no site. Garantir que não há problemas é precisamente o nosso trabalho.
Alguns casos requerem um tratamento especial, e nós encarregamo-nos disso. Tomemos o exemplo do WooCommerce: se um site utilizar tanto o WooCommerce como uma extensão WooCommerce premium cuja licença tenha expirado, a extensão premium deixa de receber atualizações. Atualizar apenas o WooCommerce poderia, então, causar falhas no site, já que uma versão recente do WooCommerce não é compatível com uma versão desatualizada da extensão. Nessa situação, não atualizamos o WooCommerce. Sempre que as Smart Automatic Updates revelam casos como este, também nos encarregamos deles.
E no que se refere aos plugins e temas premium?
A regra é simples: se pode clicar em «Atualizar» para um plugin ou tema no seu painel de gestão WordPress, nós tratamos da respetiva atualização. Se não puder (por exemplo, porque uma licença expirou), não o fazemos. Nesse caso, informamos na Área de Cliente OVHcloud que o plugin tem de ser atualizado, para que a atualização não passe despercebida.
O que muda para as agências?
Mencionaria três aspetos.
Primeiro, a segurança. As atualizações deixam de se acumular porque ninguém teve tempo de as verificar. Cada site é mantido atualizado de forma regular, o que encurta a janela durante a qual uma vulnerabilidade conhecida permanece aberta.
Segundo, a tranquilidade. As agências já não têm de se questionar se uma atualização causou alguma falha no site. Ou a atualização foi validada e aplicada, ou a produção permaneceu intacta e foi-lhes comunicado exatamente porquê. E, se algo correr mal, o site de cada cliente pode ser restaurado individualmente com um único clique, sem afetar todos os outros.
Terceiro, a poupança de tempo. Uma agência disse-nos que a manutenção dos seus sites lhe ocupa até 30% do tempo. As Smart Automatic Updates assumem as verificações repetitivas, para que as agências possam dedicar mais tempo ao que traz mais valor aos seus clientes.
As Smart Automatic Updates estão incluídas em todos os nossos planos Managed Hosting for WordPress, pelo que cada atualização WordPress é testada antes de chegar aos sites dos seus clientes. Saiba mais sobre como apoiamos agências e freelancers na gestão dos seus sites WordPress, ou leia porque concebemos desta forma o alojamento WordPress gerido.
A documentação do Managed Hosting for WordPress cobre a configuração e o processo de atualização com mais pormenores.