O htaccess WordPress é o arquivo de configuração do Apache que controla permalinks, redirects e regras de segurança da instalação. Ele fica na raiz do site, é regenerado automaticamente quando os links permanentes são salvos e cada linha é interpretada a cada request, o que o torna poderoso e, se mal configurado, custoso em performance.
Se você gerencia um WordPress em escala, já sabe o tamanho do estrago que um erro nesse arquivo causa. Uma linha errada derruba o site com erro 500, quebra permalinks no meio de uma campanha ou some com regras de segurança durante uma migração de servidor. Neste guia, vamos mostrar o código padrão, como editar com segurança e o passo a passo para você aprender a migrar o .htaccess do WordPress sem perder nada pelo caminho.
O arquivo .htaccess WordPress é um arquivo de configuração distribuído do servidor Apache. Ele permite aplicar diretrizes específicas a um diretório e seus subdiretórios sem mexer na configuração global do servidor. No contexto do WordPress, ele é o responsável por traduzir as URLs amigáveis em chamadas ao index.php.
Na prática, o WordPress depende do mod_rewrite do Apache para fazer os permalinks funcionarem. Quando você acessa /sobre-nos/ em vez de ?page_id=2, é uma regra do htaccess WordPress que faz essa tradução. Além dos permalinks, o arquivo também controla redirecionamentos, páginas de erro personalizadas, compressão, cache de navegador e bloqueios de segurança.
Mesmo com toda a evolução de stacks e CDNs, o Apache continua dominante. Segundo os dados de uso do Apache na web da W3Techs, ele roda em cerca de um terço de todos os sites com servidor web conhecido. Em muitos ambientes WordPress, principalmente em hospedagem compartilhada e VPS, o Apache segue ditando as regras de reescrita, segurança e cache pelo htaccess.
O ponto técnico que poucos consideram é o custo. Quando o Apache está com AllowOverride All, ele lê o arquivo .htaccess a cada requisição, percorrendo toda a árvore de diretórios até a raiz. Isso significa que, em um site com tráfego alto, cada request paga um pequeno pedágio de I/O e parsing. Em projetos enterprise, é comum mover essas regras para o bloco VirtualHost e desabilitar o override para ganhar performance.
Ainda assim, na maioria dos cenários WordPress você não tem acesso à configuração do Apache. O htaccess WordPress é o único ponto de controle disponível. Por isso, dominar esse arquivo é o que separa quem apenas mantém o site no ar de quem realmente controla a infraestrutura.
O arquivo fica na raiz da instalação, normalmente em /public_html/.htaccess ou no diretório onde está o index.php do WordPress. Como o nome começa com ponto, ele é tratado como arquivo oculto no Linux e não aparece em listagens comuns.
Para visualizar o htaccess WordPress, você precisa ativar a exibição de arquivos ocultos:
ls -la no diretório raiz para listar todos os arquivos, inclusive os que começam com ponto.Um detalhe importante: o WordPress regenera o arquivo sempre que você salva os permalinks em Configurações → Links Permanentes, desde que o arquivo tenha permissão de escrita. Por isso, qualquer regra customizada deve ficar fora do bloco padrão do WordPress, ou ela será apagada na próxima regeneração.
O bloco padrão gerado pelo WordPress é simples e está documentado na documentação oficial do htaccess no WordPress. Ele fica delimitado por comentários para que o core saiba o que pode reescrever:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPressLinha a linha, é assim que o htaccess WordPress padrão funciona:
mod_rewrite.index.php, que o WordPress usa para montar a página correta.Em uma rede Multisite, o bloco é diferente. Para subdiretório, o WordPress adiciona regras que tratam /wp-admin/ e arquivos de mídia por site. Para subdomínio, as regras de reescrita assumem que cada site responde em um host próprio. Nunca copie o bloco de uma instalação simples para um Multisite, porque a estrutura de URLs não vai bater.
Editar o arquivo é trivial. Editar sem derrubar o site exige método. Antes de qualquer alteração, faça backup, porque um caractere fora do lugar gera erro 500 e tira o site do ar inteiro. Esse é o passo a passo que usamos aqui na Apiki em ambientes de produção:
.htaccess ou rode cp .htaccess .htaccess.bak via SSH antes de tocar em qualquer coisa.nano ou vim.# BEGIN WordPress e # END WordPress para não perdê-las na próxima regeneração de permalinks.apachectl configtest para verificar se a configuração do Apache não tem erros antes de recarregar.Se o site quebrar, a recuperação é direta: restaure o backup ou renomeie o arquivo para .htaccess_old. Sem o arquivo, o WordPress volta a funcionar com URLs padrão, e você recupera o bloco salvando os permalinks de novo.
Esta é a parte que mais gera dor de cabeça. Migrar o WordPress sem quebrar permalinks, redirects e regras de segurança exige checar o destino antes de copiar qualquer coisa. Veja também nossas considerações ao migrar o WordPress para outro servidor para o quadro completo. Para a parte do htaccess, siga este checklist:
mod_rewrite, mod_headers e mod_deflate estão habilitados. Se uma diretiva depende de um módulo ausente, ela é ignorada ou gera erro 500.RewriteBase precisa refletir o novo caminho.curl -I ou um navegador anônimo para validar que páginas internas, redirects e área administrativa respondem corretamente.A documentação do projeto sobre o guia de configuração do servidor web no WordPress aprofunda os detalhes de quando o htaccess deve ou não estar presente. Na maioria das migrações, o problema não é o arquivo em si, mas um módulo ausente no destino ou um RewriteBase apontando para o caminho antigo.
Estas são as diretivas que mais aparecem em sites WordPress de produção, com o módulo Apache exigido e o impacto aproximado em performance:
| Diretiva | Função no WordPress | Módulo Apache exigido | Impacto em performance |
|---|---|---|---|
| RewriteRule . /index.php [L] | Habilita permalinks amigáveis (/postagem em vez de ?p=123) | mod_rewrite | Adiciona ~1-3ms por request |
| Header set Strict-Transport-Security | Força HTTPS em todos os subdomínios por 1 ano | mod_headers | Zero overhead após o primeiro request |
| <Files wp-config.php> deny from all | Bloqueia leitura direta do arquivo com credenciais do banco | core Apache | Zero overhead |
| AddOutputFilterByType DEFLATE text/html | Compressão Gzip de HTML, CSS e JS antes da entrega | mod_deflate | Reduz payload em 60-80%, custa ~5ms de CPU |
| ExpiresByType image/jpg “access 1 year” | Define cache de navegador para imagens estáticas | mod_expires | Reduz requests subsequentes em até 90% |
O htaccess WordPress é uma das primeiras camadas de hardening de um site. Estas regras de segurança devem ficar fora do bloco padrão e cobrem os vetores mais explorados. Você encontra a referência completa na documentação oficial do Apache para arquivos .htaccess.
Bloquear acesso ao wp-config.php:
<Files wp-config.php>
Order Allow,Deny
Deny from all
</Files>Desabilitar a listagem de diretórios, evitando que o conteúdo de pastas sem index seja exposto:
Options -IndexesBloquear execução de PHP na pasta de uploads, mitigando uploads maliciosos. Crie um .htaccess dentro de /wp-content/uploads/ com:
<Files *.php>
Order Allow,Deny
Deny from all
</Files>Forçar HTTPS e ativar HSTS, garantindo que todo tráfego use conexão criptografada:
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"Em ambientes com múltiplos editores publicando conteúdo, essas regras evitam que um plugin comprometido ou um upload errado vire uma porta de entrada. Vale revisar essa configuração sempre que migrar de servidor, porque é justamente nesse momento que as regras costumam se perder.
Não obrigatoriamente. O WordPress funciona sem o arquivo usando URLs padrão como ?p=123. O htaccess WordPress se torna necessário quando você usa permalinks amigáveis em servidores Apache, ou quando adiciona regras de redirect, cache e segurança. Em servidores Nginx, a configuração equivalente vive em outro arquivo.
Se o arquivo desaparecer, acesse Configurações → Links Permanentes no painel e clique em salvar. Desde que o WordPress tenha permissão de escrita na raiz, ele recria o bloco padrão automaticamente. Caso não tenha permissão, crie um arquivo vazio chamado .htaccess com permissão 644 e repita o salvamento dos permalinks.
Com AllowOverride All, o Apache lê e interpreta o arquivo a cada requisição, somando de 1 a 3 milissegundos por request percorrendo a árvore de diretórios. Em troca, diretivas como mod_deflate e mod_expires reduzem payload e requests, gerando ganho líquido. O problema aparece quando há regras redundantes ou arquivos em várias subpastas.
Não. O htaccess é exclusivo do Apache. O Nginx não lê esse arquivo e usa configuração centralizada nos blocos server e location. Ao migrar de Apache para Nginx, suas regras de reescrita e segurança precisam ser convertidas para a sintaxe do Nginx, não copiadas direto.
Plugins de SEO e segurança permitem editar o arquivo pelo painel, o que é prático, mas arriscado. Um erro de sintaxe derruba o site inteiro com erro 500 e, sem acesso a FTP ou SSH, você fica sem como reverter pelo próprio painel. Para edições em produção, recomendamos sempre acesso direto ao servidor com backup prévio.
Apague o conteúdo do arquivo ou renomeie-o para .htaccess_old, depois acesse Configurações → Links Permanentes e salve. O WordPress vai gerar um novo bloco padrão com as regras de reescrita corretas para o ambiente atual. Lembre-se de readicionar manualmente quaisquer regras de segurança customizadas que você tinha antes.
O htaccess WordPress é pequeno, mas concentra um poder enorme sobre permalinks, redirects, cache e segurança. Aprender a ler o código padrão, editar com backup e validar a sintaxe é o que evita aquele erro 500 no pior momento possível. E quando o assunto é migração, o segredo está em checar os módulos do servidor de destino antes de copiar o arquivo e em forçar a regeneração dos permalinks logo depois.
Em hospedagem WordPress gerenciada da Apiki, regras de htaccess são versionadas, testadas em staging e aplicadas com rollback automático. Assim, sua equipe publica e migra sem depender de tentativa e erro em produção, e sem aquela ligação de emergência quando o site cai. Se você gerencia WordPress em escala e quer previsibilidade na infraestrutura, fale com o nosso time e conheça o nosso WP Host.
