Como Configurar Atualizações Automáticas do Núcleo do WordPress (WP_AUTO_UPDATE_CORE)

Desde o WordPress 3.7, a plataforma atualiza partes de si mesma automaticamente sem ninguém clicar em nada. A maioria dos proprietários de sites está vagamente ciente disso, mas poucos têm uma imagem clara de exatamente o que é atualizado, quando e como alterar o padrão. Este guia passa pelos quatro níveis de atualizações automáticas que o núcleo do WordPress suporta, o que cada nível realmente faz e qual é a escolha certa dependendo se você administra um único site, um portfólio de agência ou uma configuração de hospedagem gerenciada.

O que o WordPress atualiza automaticamente por padrão

Pronto para uso, toda instalação WordPress em 2026 faz o seguinte sem perguntar:

• Atualizações menores do núcleo. Ir de 6.5.1 para 6.5.2 acontece automaticamente, em segundo plano, no mesmo dia em que o lançamento é publicado. Esses lançamentos são correções de bugs e patches de segurança. Eles são explicitamente projetados para serem seguros para instalar sem testes.
• Atualizações de arquivos de tradução. Pacotes de idioma são atualizados automaticamente.
• Lançamentos de segurança do núcleo para branches mais antigas. Mesmo que seu site ainda esteja na 6.4 porque você não fez uma atualização principal, correções de segurança são portadas e aplicadas automaticamente.

O que não acontece automaticamente por padrão:

• Atualizações principais do núcleo. Ir de 6.5 para 6.6 requer um clique manual. O WordPress mostra o banner no admin mas não instala por conta própria.
• Atualizações de plugin e tema. Ambos podem ser habilitados por item via a UI admin (desde o WordPress 5.5), mas nenhum está ligado por padrão. Eles são um tópico separado e não são controlados por WP_AUTO_UPDATE_CORE.

A razão para essa divisão é boa engenharia: lançamentos menores são entregues sob uma política estrita de "sem alterações incompatíveis", então atualizá-los silenciosamente é genuinamente de baixo risco. Lançamentos principais ocasionalmente introduzem novas APIs ou alteram comportamento que temas e plugins podem depender, e mover silenciosamente uma versão principal em produção causou quebras suficientes historicamente que o projeto escolheu o padrão conservador.

Os quatro níveis de atualizações automáticas do núcleo

A constante WP_AUTO_UPDATE_CORE em wp-config.php controla tudo isso. Aceita quatro valores:

• true: Todas as atualizações do núcleo são instaladas automaticamente, tanto menores quanto principais. A opção agressiva.
• 'minor': O padrão se a constante não for definida. Apenas lançamentos menores e de segurança são instalados automaticamente. Lançamentos principais permanecem manuais.
• 'beta' e 'rc': Usados por sites que querem builds pré-lançamento. Realista apenas em um ambiente de staging ou teste, nunca em produção.
• false: Todas as atualizações automáticas do núcleo estão desabilitadas. O site não faz nada por conta própria. Você é responsável por cada patch, incluindo correções de segurança.

Definir qualquer uma destas é uma única linha em wp-config.php, em qualquer lugar acima do comentário /* That's all, stop editing! Happy publishing. */:

define('WP_AUTO_UPDATE_CORE', true);

ou

define('WP_AUTO_UPDATE_CORE', 'minor');

Salve o arquivo, sem reinício necessário. O WordPress verifica atualizações em um cronograma (duas vezes por dia por padrão) e aplica o que a configuração atual permite.

Qual configuração faz sentido para qual tipo de site?

A resposta honesta depende de três coisas: quanto teste acontece antes que um lançamento entre no ar, quem percebe quando algo quebra e quão boa é a história de backup.

Site de produção padrão, sem contrato dedicado de manutenção

Configuração recomendada: true (todas as atualizações automáticas).

A intuição de que "atualizações principais automáticas são perigosas" está em grande parte desatualizada. Atualizações principais do WordPress têm sido estáveis por anos, e a alternativa realista é "ninguém atualiza o site por seis meses porque não há contrato para isso, e um buraco de segurança conhecido permanece aberto". Um site WordPress sem manutenção é um resultado pior do que a auto atualização muito rara que quebra algo. Se um lançamento principal quebra o site, restaurar de um backup é mais rápido do que o tempo que você de outra forma gastaria perseguindo a atualização manual mais tarde. A automação é a vitória.

Hospedagem gerenciada (Raidboxes, Kinsta, WP Engine, Cloudways, SiteGround)

Configuração recomendada: o que o painel do host fizer, geralmente 'minor' no nível do WordPress.

A maioria dos hosts gerenciados executa seu próprio fluxo de atualização sobre o WordPress. Eles tiram um snapshot primeiro, instalam o lançamento principal em um clone de staging, executam um diff visual básico e só então aplicam à produção. Isso é significativamente mais seguro do que auto atualizações puras. Se você está nesse tipo de host, definir WP_AUTO_UPDATE_CORE como qualquer coisa diferente do padrão geralmente conflita com a própria lógica do host. Deixe em paz, deixe o host fazer o que faz, e verifique o painel do host para o histórico de atualização.

Portfólio de agência com contrato de manutenção

Configuração recomendada: 'minor' em produção, true em staging.

Se um contrato de manutenção especifica que você testa atualizações antes de elas irem ao ar, a agência é a rede de segurança. A produção ainda deve receber lançamentos menores e de segurança automaticamente (esses não são opcionais do ponto de vista de segurança), mas atualizações principais passam pelo fluxo de teste da agência. Ambientes de staging são o lugar certo para definir o valor mais agressivo, para que os testadores capturem quebras cedo.

Build personalizado do WordPress com forte personalização de tema ou plugin

Configuração recomendada: 'minor', mais um processo real de teste para atualizações principais.

Sites que foram fortemente personalizados (cabeçalhos reconstruídos, blocos Gutenberg personalizados, integrações estranhas com construtores de página, endpoints REST personalizados) são exatamente o caso em que uma atualização principal pode quebrar algo sutil. A configuração padrão 'minor' é o piso correto: não abra mão dos patches de segurança, mas trate os principais como uma tarefa separada com uma passagem de teste real.

Site de alta disponibilidade que absolutamente não pode quebrar

Configuração recomendada: false para o núcleo, mais um processo real de release.

Este é o único caso em que desligar atualizações automáticas do núcleo inteiramente faz sentido. Bancos, saúde, ambientes regulamentados onde cada alteração passa por um processo de release. Note que você aceita a responsabilidade total por aplicar patches de segurança manualmente em horas após um lançamento, em cada site. A maioria das equipes que escolhem essa configuração também tem monitoramento na lista de e-mails de segurança do WordPress e um pipeline de implantação que pode entregar patches no mesmo dia.

Como verificar se sua configuração está ativa

1. No admin do WordPress, vá para Ferramentas, Saúde do Site, Info.
2. Expanda a seção Constantes do WordPress.
3. Procure por WP_AUTO_UPDATE_CORE. Se mostra seu valor, a constante está sendo lida.
4. Para uma verificação mais profunda, olhe Atualizações na barra lateral admin. Atualizações automáticas recentes aparecem lá com timestamps.

Se o valor da constante não aparece em Saúde do Site, a causa mais provável é que foi definido depois que o arquivo já o definiu mais cedo (o primeiro define ganha, e o PHP emite uma notificação que você pode não ver), ou que você editou o wp-config.php errado.

O que pode dar errado com atualizações automáticas do núcleo

Três modos de falha são realistas e vale a pena conhecer:

• Atualização parcialmente falha. O download ou extração quebra no meio, frequentemente porque o host não tem espaço em disco suficiente, atingiu um limite de inodes, ou por causa de um problema temporário de rede. O WordPress deixa um arquivo .maintenance na raiz e o site mostra "Briefly unavailable for scheduled maintenance" para sempre. Correção: SFTP na raiz e exclua o arquivo .maintenance, depois execute novamente a atualização do admin.
• Atualização tem sucesso mas um plugin começa a lançar erros. Especialmente após uma atualização principal, um plugin sem manutenção pode quebrar contra novas APIs do núcleo. Correção: tenha um backup pronto, identifique o plugin quebrado pelo log de erros (ou desabilitando plugins um por um) e atualize o plugin ou o substitua.
• Atualização é silenciosamente pulada. Razões comuns: DISALLOW_FILE_MODS está definido em wp-config.php (que bloqueia todas as atualizações, automáticas ou não), permissões de arquivo no diretório do WordPress impedem o PHP de escrever, ou o site usa Git para controle de versão e o WordPress detecta o diretório .git e desabilita atualizações como medida de segurança. A página Saúde do Site geralmente sinaliza esses casos.

Auto atualizações e DISALLOW_FILE_MODS

As duas constantes interagem de uma maneira que pega as pessoas. DISALLOW_FILE_MODS (coberto em nossa base de conhecimento sob o tópico do editor de arquivo) bloqueia todas as modificações de arquivo do lado do WordPress, incluindo atualizações automáticas do núcleo. Se ambas as constantes estão definidas:

define('DISALLOW_FILE_MODS', true);
define('WP_AUTO_UPDATE_CORE', true);

O resultado é que DISALLOW_FILE_MODS ganha. O WordPress não fará auto atualização de nada. Isso raramente é o que as pessoas pretendem. Ou você quer um site bloqueado que se atualiza de fora (pipeline de implantação, WP CLI), caso em que DISALLOW_FILE_MODS = true está correto e WP_AUTO_UPDATE_CORE é irrelevante. Ou você quer que o site se atualize, caso em que DISALLOW_FILE_MODS não deveria estar definido.

E quanto a atualizações automáticas de plugin e tema?

Auto atualizações de plugin e tema são um mecanismo separado que chegou no WordPress 5.5. Elas são configuradas por item no admin (lista de Plugins, o link "Habilitar atualizações automáticas" em cada linha) ou globalmente via filtros. A recomendação geral: ligue auto atualizações para qualquer plugin onde você confie na disciplina de release do mantenedor, deixe-as desligadas para plugins que entregam alterações incompatíveis regularmente. Lançamentos principais do WooCommerce, em particular, frequentemente valem a pena segurar para uma atualização manual com um teste rápido.

Se você quer habilitar auto atualizações de plugin programaticamente para cada plugin, este filtro faz isso:

add_filter('auto_update_plugin', '__return_true');
add_filter('auto_update_theme', '__return_true');

Coloque isso em um pequeno must-use plugin sob wp-content/mu-plugins/ em vez de em functions.php, para que uma troca de tema não desligue isso.

Conclusão para atualizações do núcleo: para a maioria dos sites em 2026, a configuração padrão 'minor' é conservadora na direção errada. Ou defina WP_AUTO_UPDATE_CORE como true e deixe a plataforma se manter atualizada, ou se comprometa com um processo de manutenção real que lida com os principais manualmente em tempo razoável. O meio termo de "configurações padrão mais ninguém observando" é o que produz sites WordPress não corrigidos duas versões atrás, e esse é o estado real de alto risco.