Limitar revisões de post no WordPress reduz o peso do banco de dados ao definir `WP_POST_REVISIONS` no wp-config.php. Segundo a documentação oficial do WordPress, o padrão é revisões ilimitadas. Cada edição salva uma cópia inteira do post, inflando a tabela wp_posts. Defina o limite antes que o banco cresça demais.
Limitar revisões de post no WordPress é o ato de fixar quantas cópias de cada edição o sistema guarda no banco de dados. Por padrão o WordPress salva uma revisão a cada alteração, sem teto, e isso acumula registros na tabela wp_posts que pesam no carregamento de telas administrativas e nos backups. A boa notícia é que a correção mora em uma única linha no wp-config.php, a constante WP_POST_REVISIONS. Neste guia de performance WordPress, você vai aprender a medir o problema, aplicar o limite certo e limpar o histórico antigo sem perder conteúdo publicado. É uma das otimizações de maior retorno por minuto de trabalho.
Diagnóstico rápido: Por que as revisões pesam no banco
Antes de limitar revisões de post no WordPress, entenda por que elas pesam: cada revisão é uma linha completa na tabela wp_posts, não um “diff” leve. Um post de 1.500 palavras editado 40 vezes gera 40 cópias quase idênticas do conteúdo inteiro. Em sites com anos de publicação, isso vira milhares de linhas órfãs.
Esse acúmulo deixa as queries do painel mais lentas e infla cada backup. A tabela abaixo resume o que ocupa espaço e o impacto real de cada item antes de você decidir limitar revisões de post no WordPress.
| Item no banco | Comportamento padrão | Impacto na performance |
|---|---|---|
| Revisões (revision) | Ilimitadas, 1 cópia por edição | Tabela wp_posts inflada; queries mais lentas |
| Autosaves | 1 a cada 60 segundos durante a edição | Crescimento contínuo enquanto o editor escreve |
| Auto-drafts | Criados ao abrir “novo post” | Lixo acumulado se o post nunca for salvo |
A consequência prática é um banco que cresce em silêncio. Ferramentas como WP-Optimize e o painel de banco de dados WordPress mostram o tamanho real antes da limpeza.
Quanto vale limitar revisões de post no WordPress
Limitar revisões de post no WordPress costuma encolher a tabela wp_posts em uma fração relevante quando há histórico longo de edições, porque cada revisão excluída libera 1 linha inteira. Na prática do suporte da FULL, a gente vê sites com mais linhas de revisão do que de conteúdo publicado.
O ganho não é mágico: aparece em bancos grandes, não em blogs recém-criados. O retorno principal é operacional. Backups ficam menores e mais rápidos, a replicação do banco trafega menos dados e o crawler do Google desperdiça menos esforço com URLs internas que nunca deveriam ser rastreadas, preservando o crawl budget. Para um site de conteúdo, controlar as revisões no WordPress é higiene de banco tão básica quanto ativar cache de página.
A constante wp_post_revisions: Os 3 valores possíveis
A constante WP_POST_REVISIONS aceita três tipos de valor no wp-config.php, e a escolha define todo o comportamento do histórico. Segundo a documentação oficial do WordPress, o padrão é true (revisões ilimitadas). Definir false desativa o recurso por completo, e um número inteiro fixa o teto por post. Entender a diferença evita o erro comum de desligar o que você só queria reduzir.
- Se o site é um blog ativo com vários autores → defina um número como
5, mantendo histórico útil sem inflar o banco. - Se a equipe edita pouco e prioriza performance máxima → use
3, suficiente para reverter um erro recente. - Se o site é institucional e raramente muda →
falsedesativa revisões, mas você perde o “desfazer” entre sessões. - Se há receio de perder versões → nunca use
0; ele se comporta como desativado e ainda confunde plugins de backup.
O valor false desativa também o autosave entre sessões, então a maioria dos sites de conteúdo se beneficia mais de um número como 5 do que de desligar tudo.
Passo a passo: Limitar revisões de post no WordPress
Limitar revisões de post no WordPress leva menos de cinco minutos e exige apenas acesso ao arquivo wp-config.php via FTP, gerenciador de arquivos da hospedagem ou WP-CLI. Faça um backup antes de editar o arquivo, porque um erro de sintaxe ali derruba o site inteiro com a tela branca da morte. Os passos abaixo cobrem a definição do limite e, opcionalmente, o ajuste do intervalo de autosave.
Passo 1: Abra o wp-config.php com segurança
Acesse o wp-config.php na raiz da instalação, geralmente em /public_html/, usando FTP ou o gerenciador de arquivos do painel da hospedagem. Baixe uma cópia local antes de qualquer alteração: esse arquivo guarda credenciais do banco e qualquer erro de digitação impede o WordPress de carregar. Trabalhe sempre sobre uma cópia de segurança.
Passo 2: Adicione a constante wp_post_revisions
Insira a linha acima do comentário / That's all, stop editing! /, nunca depois dele, ou o WordPress ignora a definição. Para limitar a 5 revisões por post, use:
define( 'WP_POST_REVISIONS', 5 );
Para desativar completamente, troque o número por false. Essa única linha é o que basta para limitar revisões de post no WordPress: o valor passa a valer para todas as novas edições imediatamente após salvar o arquivo.
Passo 3: Ajuste o intervalo de autosave (opcional)
O WordPress salva um rascunho automático a cada 60 segundos por padrão, controlado pela constante AUTOSAVE_INTERVAL. Em posts longos com edições demoradas, aumentar esse intervalo reduz a gravação no banco. Para salvar a cada 120 segundos, adicione:
define( 'AUTOSAVE_INTERVAL', 120 );
Passo 4: Limpe as revisões antigas já acumuladas
A constante limita o futuro, mas não apaga o passado. Para remover as revisões já gravadas, use o WP-Optimize em WP-Optimize > Database > Optimizations, conforme a documentação oficial da TeamUpdraft. Marque “Clean post revisions”, revise a prévia e execute. O WP-Optimize também agenda a limpeza para rodar semanalmente, automatizando a higiene do banco.
Quando ajustar a régua: Limite ideal por tipo de site
Não existe número universal para limitar revisões de post no WordPress: o limite certo varia de 2 a 10 conforme quantas mãos editam e quão crítico é o histórico. Um portal de notícias precisa de mais versões para auditoria; um site institucional estável precisa de quase nenhuma.
A régua abaixo orienta a decisão sem chute, e vale lembrar que a constante aceita ajuste a qualquer momento sem afetar o conteúdo publicado.
Em ambientes com WooCommerce e centenas de produtos, limitar revisões de post no WordPress exige mais cuidado: descrições de produto também geram revisões, e o crescimento da tabela wp_posts impacta consultas de catálogo. Nesses casos, um limite entre 3 e 5 combinado com limpeza agendada no WP-Optimize ou no Perfmatters mantém o banco enxuto sem sacrificar a capacidade de reverter um erro de preço ou descrição publicado por engano.
Ferramentas que automatizam o controle de revisões
Limitar revisões de post no WordPress via constante é o método mais limpo e direto, mas 4 plugins ajudam a medir e manter o resultado ao longo do tempo. O WP-Optimize limpa revisões, transients e tabelas órfãs com agendamento semanal, e o Perfmatters limita revisões direto no painel.
O WP Rocket foca em cache, mas seu módulo de banco oferece limpeza de revisões na mesma tela. O Perfmatters permite ainda desativar autosaves sem tocar no wp-config.php.
Para quem prefere não instalar plugin, o WP-CLI resolve via linha de comando: wp post delete $(wp post list --post_type=revision --format=ids) --force apaga todas as revisões existentes de uma vez. Cada ferramenta tem seu lugar, e na visão de quem opera 150 mil sites na FULL, combinar a constante no wp-config.php com uma limpeza agendada cobre os dois flancos: trava o crescimento futuro e elimina o acúmulo antigo. Compare opções no review de quando o WP-Optimize vale a pena.
Além das revisões: O que mais infla a tabela wp_posts
Limitar revisões de post no WordPress resolve metade do problema, mas a tabela wp_posts acumula outros tipos de registro que crescem em silêncio junto com as revisões. Autosaves, auto-drafts e posts na lixeira ocupam linhas com o mesmo peso de um conteúdo publicado, porque cada um é uma linha completa, não um ponteiro leve. Atacar só as revisões deixa esses vizinhos intactos.
Segundo a documentação oficial do WordPress, a constante EMPTY_TRASH_DAYS controla por quanto tempo um post fica na lixeira antes de ser apagado em definitivo, e o padrão de 30 dias mantém esse lixo no banco por um mês inteiro. Reduzir esse valor, ou usar 0 para desativar a lixeira, encolhe a wp_posts no mesmo movimento em que você limita as revisões.
Na prática do suporte da FULL, a gente vê que a higiene completa do banco combina três ajustes no wp-config.php: o teto de revisões, o intervalo de autosave e o prazo da lixeira. Tratar os três juntos evita o cenário comum de limpar revisões hoje e ver a wp_posts voltar a crescer por causa de auto-drafts abandonados e posts na lixeira que nunca são esvaziados.
Acelere todo o banco com o bundle da FULL
Limitar revisões é uma peça do quebra-cabeça de performance, e manter o site rápido exige o conjunto certo de plugins premium sem pagar por cada licença avulsa. O plano PRO da FULL custa R$849,90 e inclui 17 plugins, entre eles WP-Optimize, WP Rocket, Perfmatters e Rank Math PRO. Diluído nos 10 sites que o plano cobre, isso dá cerca de R$85 por site, com ativação em um clique e suporte em português. Conheça os planos em FULL.services/planos e pare de gerenciar licenças soltas.
Perguntas frequentes sobre limitar revisões de post no WordPress
Como limitar revisões de post no WordPress sem editar código?
Use o Perfmatters ou o WP-Optimize, que oferecem o controle de revisões direto no painel wp-admin. No Perfmatters, a opção fica em Options > WordPress e permite definir o limite numérico sem tocar no wp-config.php. É a rota recomendada para quem não tem acesso FTP ou receia quebrar o arquivo de configuração com um erro de sintaxe.
É possível limitar revisões sem perder o histórico já publicado?
Sim. A constante `WP_POST_REVISIONS` afeta apenas as edições futuras e nunca toca no conteúdo publicado: o post no ar permanece intacto. As revisões antigas continuam no banco até você limpá-las manualmente com o WP-Optimize. Definir o limite hoje não apaga nada retroativamente, então é seguro aplicar em qualquer site em produção.
Por que o WordPress salva revisões ilimitadas por padrão?
Porque a prioridade do núcleo do WordPress é nunca deixar o usuário perder trabalho. Sem teto, qualquer edição é reversível, mesmo de meses atrás. O preço dessa segurança é o crescimento da tabela wp_posts: cada revisão é uma linha completa. Por isso a documentação oficial deixa `WP_POST_REVISIONS` ajustável, equilibrando segurança e performance conforme o site.
Qual o número ideal de revisões para limitar no WordPress?
Ao limitar revisões de post no WordPress, um valor entre 3 e 5 equilibra bem segurança e peso do banco para a maioria dos sites de conteúdo. Blogs com vários autores e fluxo editorial podem usar 10. Sites institucionais estáveis funcionam com 2 ou até `false`. O número aceita ajuste a qualquer momento no wp-config.php, sem afetar posts já publicados, então comece com 5 e calibre.
Quando o autosave do WordPress vira um problema de banco?
O autosave grava um rascunho a cada 60 segundos por padrão, controlado por `AUTOSAVE_INTERVAL`. Em posts longos editados por uma hora, isso são dezenas de gravações no banco. O problema aparece em sites com muitos editores simultâneos. Aumentar o intervalo para 120 ou 160 segundos reduz a escrita sem risco real de perda de conteúdo durante a edição.
Próximos passos para um WordPress mais leve
Limitar revisões de post no WordPress é o tipo de ajuste de cinco minutos com retorno duradouro: uma linha no wp-config.php trava o crescimento da tabela wp_posts, e uma limpeza no WP-Optimize zera o acúmulo antigo. Combine o limite numérico com a limpeza agendada e o banco se mantém enxuto sozinho. Depois de resolver as revisões, o próximo gargalo costuma ser cache e otimização de imagens. Para continuar, o FULL Academy reúne tutoriais, guias e reviews de performance em um só lugar, e o guia acelere o WordPress encadeia os próximos passos na ordem certa.
Legenda: a constante WP_POST_REVISIONS definida acima da linha “stop editing” aplica o limite a todas as edições futuras.
















