Atualizar WordPress sozinho ou contratar: quando cada um faz sentido

Existe uma frase que aparece com frequência nos fóruns de suporte do WordPress: “atualizei e o site sumiu”. Às vezes é um plugin. Às vezes é o core. Às vezes é a combinação dos dois com uma versão de PHP que a hospedagem atualizou silenciosamente. O resultado é sempre o mesmo: site fora do ar, cliente sem resposta, e alguém tentando descobrir o que fazer às onze da noite.

A pergunta “atualizar WordPress sozinho ou contratar?” não tem uma resposta única. Ela tem uma resposta que depende de variáveis concretas: o tamanho do site, a complexidade do ambiente, o que está em jogo se algo quebrar, e se você sabe o que fazer quando der errado.

Este artigo não vai te dizer que atualizar sozinho é sempre perigoso — porque não é. Nem vai dizer que contratar é sempre necessário — porque também não é. Vai te dar os critérios reais para tomar essa decisão de forma informada.

O que significa “atualizar o WordPress”

Antes de decidir como fazer, é importante entender o que está sendo atualizado. “Atualizar o WordPress” é, na prática, três processos distintos que ocorrem no mesmo ecossistema mas têm riscos e consequências diferentes.

Core do WordPress é o núcleo da plataforma — os arquivos que fazem o CMS funcionar. O WordPress lança dois tipos de atualização de core: atualizações de segurança menores (como 6.5.1, 6.5.2) e atualizações de versão maior (como 6.5 para 6.6). Atualizações menores de segurança são aplicadas automaticamente por padrão e raramente causam problemas. Atualizações de versão maior introduzem mudanças mais amplas e têm maior potencial de conflito com plugins ou temas.

Plugins são extensões que adicionam funcionalidade ao site. Um site WordPress médio tem entre 15 e 30 plugins ativos. Cada plugin tem seu próprio ciclo de desenvolvimento e release. Uma atualização de plugin pode introduzir incompatibilidade com outro plugin, com o tema ativo ou com a versão atual do PHP. É aqui que a maioria dos problemas de atualização acontece.

Temas controlam a aparência e, em muitos casos, também a estrutura do site. Atualizar um tema quando existem customizações feitas diretamente nos arquivos do tema (sem usar tema filho) apaga essas customizações. É um dos erros mais comuns e mais difíceis de reverter sem backup.

O White Paper de Segurança do WordPress (WordPress.org, 2024) documenta que a equipe de segurança do WordPress mantém um processo rigoroso de revisão para atualizações de versões menores, tornando-as seguras para aplicação automática. O mesmo não se aplica ao ecossistema de plugins e temas de terceiros, que operam sob ciclos de desenvolvimento independentes e onde a maioria dos problemas de compatibilidade se concentra.

Por que a atualização é obrigatória — não opcional

Antes de entrar no “como” e no “quem”, é necessário estabelecer um ponto que não é negociável: a atualização não é opcional.

A classificação A06:2021 do OWASP Top 10 — “Componentes Vulneráveis e Desatualizados” — lista o uso de software sem as atualizações de segurança aplicadas como um dos dez principais riscos de segurança em aplicações web. Isso não é teoria: bots varrem a internet continuamente buscando instalações WordPress com versões específicas de plugins que possuem CVEs (Common Vulnerabilities and Exposures) conhecidos. A janela entre a publicação de uma vulnerabilidade e o início da exploração ativa costuma ser de horas, não dias.

O NIST SP 800-40, guia de gerenciamento de patches do Instituto Nacional de Padrões e Tecnologia dos Estados Unidos, define o patch management como “manutenção preventiva essencial para o negócio” — não como tarefa técnica opcional. O documento recomenda explicitamente a criação de estratégias que incluam automação para atualizações críticas e grupos de prioridade baseados na importância dos ativos.

Um estudo sobre vulnerabilidades em CMS desatualizados constatou que, enquanto o core do WordPress costuma estar atualizado na maioria dos sites de maior porte, os plugins estão frequentemente defasados — e é justamente nos plugins que 70% dos exploits graves têm origem.

Manter o WordPress desatualizado não é uma decisão de risco calculado. É uma exposição passiva a vetores de ataque bem documentados. A questão não é se atualizar — é como e quem faz isso de forma segura.

Quando atualizar WordPress sozinho faz sentido

Atualizar sozinho é viável e seguro quando algumas condições estão presentes. Se você tem todas elas, pode fazer a manutenção sem depender de terceiros.

Você sabe fazer backup e restaurá-lo

Essa é a condição mais importante. Um especialista em WordPress com mais de uma década de experiência resumiu bem: “Se você não sabe como restaurar um backup, não deve atualizar um site em produção.”

Não basta ter backup configurado. É necessário saber verificar se o backup foi concluído com sucesso, saber onde ele está armazenado, e ter executado ao menos uma restauração de teste para confirmar que o processo funciona. Backup que nunca foi testado é backup que talvez não exista de verdade.

O site é simples e o ambiente está documentado

Um site institucional com tema padrão do WordPress, cinco a dez plugins amplamente utilizados (sem personalizações complexas), sem WooCommerce, sem integrações de terceiros via API e sem customizações no tema funciona bem com atualizações diretas pelo painel, precedidas de backup.

A complexidade do ambiente determina o risco. Quanto mais plugins, integrações, customizações e dependências, maior a superfície de possível conflito.

Você tem ambiente de staging disponível

Ambiente de staging é uma cópia do site em produção, rodando em outro endereço, onde as atualizações são aplicadas primeiro. Se algo quebrar no staging, você encontra e resolve antes que o problema afete o site real.

A documentação oficial do WooCommerce, por exemplo, recomenda explicitamente testar atualizações em ambiente local ou de staging antes da produção — especialmente para e-commerces, onde uma atualização que quebra o checkout tem impacto financeiro imediato. Qualquer site que gera receita ou leads diretamente deveria seguir o mesmo fluxo.

O site não é crítico para o negócio em tempo real

Se o site ficar fora do ar por duas horas enquanto você resolve um conflito de plugin, qual é o impacto real? Para um blog pessoal ou um site de portfólio, o impacto é baixo. Para uma loja WooCommerce com pedidos em andamento, um sistema de agendamento ou um site que é a principal fonte de leads da empresa, duas horas fora do ar têm custo mensurável.

O Google Search Console e o Search Engine Journal documentam que períodos breves de indisponibilidade com status 503 não prejudicam o ranking de busca — desde que sejam planejados, infrequentes e de curta duração (janelas de 10 a 15 minutos). Mas o impacto não é só no SEO: é na experiência de quem tenta acessar o site e encontra erro.

Quando contratar faz mais sentido

Há cenários em que a tentativa de fazer sozinho tem custo maior do que contratar. Não por falta de capacidade técnica, mas por falta do tempo, do contexto ou das ferramentas certas.

O site tem WooCommerce com pedidos ativos

WooCommerce adiciona uma camada de complexidade que vai além dos plugins padrão. Uma atualização que cause conflito no meio do dia pode interromper checkouts, gerar erros nos pedidos em andamento ou corromper o carrinho de sessão de clientes que estavam em processo de compra. A documentação oficial do WooCommerce tem um fluxo de atualização específico que inclui backup do banco de dados separado, modo de manutenção ativo durante a atualização, e validação completa do fluxo de compra após cada atualização.

Fazer isso corretamente em ambiente de produção sem experiência com WooCommerce é arriscado. O custo de uma hora de receita perdida em uma loja com vendas regulares supera o custo de um mês de manutenção profissional.

Existem customizações fora de plugins ou tema filho

Customizações feitas diretamente em arquivos de plugin ou nos arquivos do tema (sem tema filho) são perdidas quando esses componentes são atualizados. Se o site tem funcionalidades que dependem de código personalizado nesses arquivos, cada atualização pode apagar partes do comportamento do site.

Identificar quais customizações existem, documentá-las e protegê-las durante o processo de atualização requer conhecimento técnico específico sobre como o WordPress gerencia esses arquivos.

Você já teve problemas com atualizações antes

Se o histórico do site inclui quebras causadas por atualização — mesmo que resolvidas — isso é um sinal de que o ambiente tem fragilidades que uma atualização futura pode voltar a ativar. Ambientes com plugins em conflito latente, temas mal construídos ou versões de PHP no limite da compatibilidade são candidatos a problemas recorrentes.

Um serviço de manutenção de site WordPress inclui diagnóstico do ambiente antes das atualizações, o que permite identificar conflitos potenciais antes de aplicar as mudanças.

Você não tem tempo para acompanhar

A manutenção pode consumir até 90% dos custos totais do ciclo de vida de um software, segundo estudo publicado pela NAUN sobre impacto da qualidade do software. No contexto do WordPress, isso se traduz em horas dedicadas a monitorar notificações de atualização, fazer backup, aplicar atualizações, testar o site depois, e resolver qualquer problema que apareça.

Para quem tem isso como parte do trabalho, é viável. Para um dono de negócio que usa o WordPress como ferramenta para outras atividades, esse tempo tem custo de oportunidade real. Cada hora resolvendo conflito de plugin é uma hora a menos no negócio.

Plugins com histórico de atualizações problemáticas

Alguns plugins são conhecidos por causar problemas em atualizações — especialmente page builders pesados (Elementor, Divi, Beaver Builder) e plugins de e-commerce com muitas dependências. Não é necessariamente falha desses plugins: é a complexidade de um ecossistema onde dezenas de componentes de diferentes desenvolvedores precisam coexistir.

Quem faz manutenção profissional reconhece esses padrões e sabe quando segurar uma atualização de plugin até que o ecossistema ao redor esteja preparado para recebê-la. O NIST SP 800-40 recomenda explicitamente a criação de grupos de prioridade para patches e a preparação para problemas inevitáveis através de resiliência organizacional — o que, traduzido para WordPress, significa backup verificado e processo de rollback documentado antes de cada atualização.

O processo correto de atualização — independente de quem faz

Seja você ou um especialista fazendo a atualização, o processo correto não muda. O que muda é quem executa cada etapa e com qual ferramenta.

1. Backup completo verificado Backup de todos os arquivos e do banco de dados, armazenado fora do servidor. Não apenas “iniciado” — concluído e verificado. Em ambientes de e-commerce, o banco de dados precisa de backup separado porque é onde os pedidos vivem.

2. Verificação do ambiente antes de atualizar Quais plugins têm atualizações pendentes? Algum deles tem relatos recentes de incompatibilidade com a versão atual do WordPress ou com outros plugins do site? A versão de PHP do servidor é compatível com a nova versão do plugin ou do core?

A documentação do Plugin Handbook do WordPress Developer enfatiza que problemas de compatibilidade raramente surgem do core — surgem da interação entre componentes de terceiros que não foram testados juntos.

3. Aplicar atualizações em sequência, não todas de uma vez Atualizar core, plugins e tema ao mesmo tempo impossibilita identificar qual componente causou um problema se algo quebrar. A sequência recomendada é: core primeiro, depois plugins (um de cada vez, ou em grupos pequenos), depois tema.

4. Testar o site depois de cada atualização Não apenas “ver se abre”. Testar as funcionalidades críticas: formulários de contato, processo de compra em e-commerces, áreas de membros, integrações com sistemas externos, e o painel administrativo. Um site que carrega mas tem o checkout quebrado parece normal na visualização superficial.

5. Monitorar nas horas seguintes Alguns conflitos não aparecem imediatamente — aparecem quando um cron job roda, quando um cache expira ou quando uma condição específica é atingida. Monitorar o site por algumas horas após a atualização reduz o risco de um problema passar despercebido até que um cliente reporte.

A diferença real entre atualização automática e manutenção profissional

O WordPress tem suporte nativo a atualizações automáticas. Para atualizações menores de segurança do core, isso é seguro e recomendado — é exatamente o que o White Paper de Segurança do WordPress descreve como o mecanismo mais eficiente para fechar vulnerabilidades críticas rapidamente.

O problema é quando “atualização automática” é confundida com “manutenção está feita”.

Estudos sobre o processo de manutenção de software mostram que a avaliação automatizada captura menos da metade dos problemas reais de um site. Automação resolve o que é programável: aplicar a atualização quando ela está disponível. Não resolve o que requer julgamento: identificar que um plugin específico tem um conflito com o tema ativo que vai se manifestar apenas em determinada condição, ou que uma versão de PHP na hospedagem vai se tornar incompatível com a próxima atualização do core.

A supervisão manual combinada com automação é o modelo que cobre os dois lados. A automação cuida das atualizações de segurança urgentes que não podem esperar. A supervisão humana cuida das atualizações que exigem avaliação de contexto.

Isso é, essencialmente, o que a manutenção profissional oferece que o painel do WordPress não oferece: não é só a execução da atualização, é o julgamento antes dela.

Quanto tempo leva e qual o custo real de fazer sozinho

Quando alguém decide fazer a manutenção do próprio WordPress, raramente calcula o tempo real envolvido. A percepção é que “atualizar plugins leva cinco minutos”. A realidade, feita corretamente, é diferente.

Fazer backup verificado, verificar compatibilidade dos componentes, aplicar atualizações em sequência, testar as funcionalidades críticas do site e monitorar nas horas seguintes leva entre 1 e 3 horas em um site de complexidade média, toda vez. Se isso é feito mensalmente — frequência mínima para um site em produção — são 12 a 36 horas por ano dedicadas a uma atividade que não é o negócio principal.

Para quem tem esse tempo disponível e quer aprender o processo, faz todo sentido. Para quem tem outras prioridades, a equação muda quando se calcula o custo da hora dedicada versus o custo de um serviço de manutenção mensal.

O segundo custo a considerar é o custo do erro. Uma atualização que quebra o site e leva horas para resolver — ou que exige contratar alguém em caráter de urgência para recuperar — tem custo que não estava no plano original. Leia sobre o custo real de deixar o WordPress sem manutenção adequada para entender o quadro completo.

Checklist: atualizar sozinho ou contratar?

Use as perguntas abaixo para avaliar sua situação específica. Quanto mais “sim” você responder na coluna A, mais seguro é fazer sozinho. Quanto mais “sim” na coluna B, mais sentido faz contratar.

Coluna A — Favor de fazer sozinho

Sei fazer backup e já testei a restauração com sucesso
Tenho ambiente de staging configurado
O site não tem WooCommerce ou integrações críticas
Todas as customizações estão em tema filho e em plugins próprios
Tenho tempo disponível para acompanhar o processo sem pressa
Sei diagnosticar conflito de plugin via FTP ou gerenciador de arquivos

Coluna B — Favor de contratar

Não sei onde o backup está armazenado ou se está funcionando
O site gera receita ou leads diretamente e cada hora fora do ar tem custo
Existe WooCommerce com pedidos ativos
Há customizações em arquivos de plugin ou tema sem uso de tema filho
O site já teve problemas causados por atualização antes
Não tenho tempo para acompanhar o processo com cuidado
O site tem mais de 20 plugins ativos com integrações entre eles

Não existe resposta certa universal. Existe a resposta certa para o seu site, neste momento.

Quando contratar não é “gastar” — é proteger um ativo

Existe uma resistência comum a pagar por manutenção de algo que “já está funcionando”. A lógica parece razoável: por que pagar mensalmente por algo que não está quebrado?

O problema com essa lógica é que ela trata o site como um objeto estático, quando na prática é um sistema que interaje com um ecossistema em constante mudança: novas versões de plugins, novas versões de PHP nos servidores de hospedagem, novos vetores de ataque documentados nos CVEs, mudanças no Google que impactam SEO técnico.

O custo de não fazer manutenção no WordPress não é abstrato. É o site fora do ar quando um cliente tenta acessar. É a queda de posição no Google quando o site passa a carregar lento por banco de dados inflado. É o e-mail corporativo que começa a cair no spam porque o servidor foi incluído em blacklist depois de uma invasão silenciosa.

Manutenção profissional não é um serviço de recuperação — é o que evita que você precise de recuperação. Há uma diferença importante entre os dois, e ela fica clara para quem já passou pela experiência de reconstruir um site após uma invasão ou perder dados por falta de backup verificado.

O papel do histórico do site nessa decisão

Um detalhe que frequentemente é ignorado na decisão de atualizar sozinho ou contratar é o histórico específico do site.

Sites que foram migrados de hospedagem sem processo estruturado podem ter configurações de banco de dados inconsistentes que se manifestam durante atualizações. Sites que tiveram plugins desinstalados sem limpeza adequada acumulam resíduos no banco que criam conflitos imprevisíveis. Sites que foram hackeados e “limpos” de forma superficial podem ter backdoors que ainda estão ativos e que são reativados quando o ecossistema muda.

Se você tem um site com histórico de lentidão não resolvida, com comportamento inconsistente ou que já passou por invasão, o processo de atualização segura precisa começar com diagnóstico — não com o botão “Atualizar tudo”.

Perguntas frequentes

Posso ativar as atualizações automáticas e não me preocupar?

Atualizações automáticas do core para versões menores de segurança são seguras e recomendadas — é exatamente para isso que foram projetadas. Mas ativar atualização automática para todos os plugins em um site com múltiplas integrações é um risco diferente: uma atualização de plugin pode introduzir incompatibilidade que quebra uma funcionalidade crítica sem que ninguém perceba até um cliente reportar. A automação resolve urgência de segurança; não substitui avaliação de compatibilidade.

O que faço se uma atualização quebrar o site?

Primeiro: não entre em pânico e não tente resolver “clicando em coisas”. Se você tem backup recente, o caminho mais seguro é restaurar para o estado anterior ao problema e então diagnosticar a causa em ambiente controlado. Se não tem backup, o caminho é mais complicado — geralmente requer acesso ao servidor via FTP para desativar o plugin problemático diretamente nos arquivos. Se o site está completamente inacessível, incluindo o painel administrativo, é hora de chamar alguém com acesso ao servidor.

Qual a frequência ideal para atualizar o WordPress?

Atualizações de segurança do core devem ser aplicadas imediatamente quando disponíveis (ou deixadas para aplicação automática). Atualizações de plugins devem ser monitoradas semanalmente e aplicadas quando estão disponíveis, seguindo o processo correto. Atualizações de versão maior do core podem ser aplicadas assim que a versão estiver estável — geralmente uma a duas semanas após o lançamento, quando os plugins mais populares já lançaram atualizações de compatibilidade.

Existe risco em não atualizar plugins por um tempo?

Sim, e o risco cresce com o tempo. A janela entre a publicação de uma vulnerabilidade em um plugin e o início da exploração ativa por bots é pequena. Plugins com CVEs conhecidos em versões antigas são alvos de varredura automatizada. Não atualizar não é “manter o que funciona” — é acumular exposição passiva a vetores documentados.

Tema filho é obrigatório antes de atualizar o tema?

Não é obrigatório para a atualização funcionar. É obrigatório para que suas customizações sobrevivam à atualização. Se o tema tem customizações feitas diretamente nos arquivos (functions.php modificado, arquivos de template alterados), atualizar o tema apaga essas customizações. Com tema filho, as customizações ficam num arquivo separado que a atualização não toca.

Minha hospedagem oferece atualização automática do WordPress. Isso substitui a manutenção?

Algumas hospedagens oferecem atualização automática do core do WordPress como feature. Isso resolve apenas uma parte do problema — o core. Plugins, temas, banco de dados, compatibilidade de PHP, backups verificados e monitoramento de segurança ficam fora do escopo desse serviço. É uma camada de proteção, não uma solução completa de manutenção.

Quanto custa um serviço de manutenção WordPress?

O investimento varia conforme o tamanho e a complexidade do site, a frequência de atualizações e o nível de suporte incluído. Em geral, planos de manutenção para sites de pequeno e médio porte no Brasil começam em valores que, quando divididos pelo tempo que você deixa de gastar com manutenção manual, representam custo por hora menor do que a maioria das atividades profissionais. O critério mais relevante não é o preço absoluto — é comparar com o custo de uma hora do seu tempo e com o custo de uma eventual recuperação de emergência.

Conclusão

A decisão de atualizar WordPress sozinho ou contratar não é sobre capacidade técnica — é sobre contexto. Qual é a complexidade do seu ambiente? Qual é o impacto se algo quebrar? Você tem o processo correto — backup, sequência, teste — implementado ou atualiza esperando que dê certo?

Para sites simples com proprietários que entendem o processo e têm tempo para executá-lo corretamente, fazer sozinho funciona bem. Para sites que geram receita, têm integrações complexas, ou onde o tempo dedicado à manutenção tem custo de oportunidade real, contratar é a decisão que faz mais sentido economicamente — não por luxo, mas por cálculo objetivo.

Se você está avaliando essa decisão para o seu site, o ponto de partida é um diagnóstico honesto do ambiente atual: o que tem, como está, e o que acontece se der errado. O serviço de manutenção de site WordPress começa exatamente por aí — diagnóstico completo nas primeiras 48 horas, com relatório do que foi encontrado antes de qualquer ação.

Fontes e referências

OWASP Top 10 — A06:2021: Vulnerable and Outdated Components. Classificação de componentes vulneráveis e desatualizados como um dos dez principais riscos em aplicações web. Disponível em: owasp.org
NIST SP 800-40 Rev. 4 — Guide to Enterprise Patch Management Planning. Definição de patch management como manutenção preventiva e recomendações para estratégia de atualização. National Institute of Standards and Technology. Disponível em: nvlpubs.nist.gov
WordPress Security White Paper (WordPress.org, 2024). Documentação do processo de atualização automática de versões menores e do trabalho da equipe de segurança. Disponível em: wordpress.org/about/security
WordPress Plugin Handbook — Developer Documentation. Boas práticas de desenvolvimento de plugins com foco em compatibilidade e segurança. Disponível em: developer.wordpress.org
WooCommerce — Documentação Oficial de Atualização. Fluxo recomendado para atualizações em ambiente de e-commerce, incluindo uso de staging e modo de manutenção. Disponível em: woocommerce.com/document/updating-woocommerce
NAUN — Impact of Software Quality on the Maintenance Process. Análise de como a qualidade do software afeta os custos de manutenção, com a indicação de que manutenção pode consumir até 90% dos custos totais do ciclo de vida.
Search Engine Journal — HTTP 503 Status Code and SEO Impact. Documentação sobre o impacto de períodos de indisponibilidade planejados no ranking de busca.
Cloudflare — WAF Managed Rules. Proteção de aplicações via Web Application Firewall como camada de defesa durante janelas de atualização.
Bytebase — Best Practices for MySQL Schema Migration. Recomendações para mudanças rastreáveis e compatíveis com versões anteriores em banco de dados.
NDSS Symposium — Studying Reasons for Lacking Updates in WordPress. Análise dos motivos pelos quais sites WordPress permanecem desatualizados e o comportamento de exploração que isso gera.