Arquivo .htaccess padrão do WordPress: o que contém e como restaurá-lo

O arquivo .htaccess padrão do WordPress é o pequeno bloco RewriteEngine que o próprio software escreve no .htaccess da raiz do seu site para que links permanentes como /2026/10/nome-do-post/ sejam resolvidos em vez de darem 404. É assim:

# 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 WordPress

Esse é o bloco exato, reproduzido do guia oficial do WordPress sobre o Apache HTTP Server e da lógica de rewrite documentada na página do HelpHub sobre links permanentes amigáveis. Se o seu RewriteBase não for / — por exemplo, porque o WordPress está instalado em uma subpasta — ele vai corresponder a esse caminho em vez disso, e isso também é normal e gerado pelo próprio WordPress.

Resumo

• O WordPress gera esse bloco automaticamente, só no Apache e no LiteSpeed, sempre que o arquivo tem permissão de escrita e você salva Configurações > Links Permanentes.
• Se o arquivo estiver ausente ou corrompido, todos os links permanentes exceto a home retornam 404, porque só a home pode ser encontrada sem as regras de rewrite.
• Qualquer coisa que você ou um plugin adicionar deve ficar acima de # BEGIN WordPress, nunca dentro dos marcadores — o WordPress sobrescreve tudo entre eles a cada vez que os links permanentes são salvos.

Precisa reconstruir o arquivo com o seu caminho real e alguma regra extra? O gerador de .htaccess do WordPress monta um correto direto no seu navegador.

O que cada linha faz

RewriteEngine On ativa o módulo mod_rewrite do Apache para esse diretório; sem ela, todo o resto fica inerte.

RewriteBase / diz ao Apache que os caminhos reescritos são relativos à raiz do site. O WordPress ajusta isso conforme onde o site realmente vive — uma instalação em subpasta recebe RewriteBase /blog/, não /.

RewriteRule ^index\.php$ - [L] é uma guarda sem efeito: se a requisição já é index.php, o rewrite para e a requisição passa sem alteração.

As duas linhas RewriteCond são a lógica real. %{REQUEST_FILENAME} !-f e !-d perguntam “essa requisição NÃO corresponde a um arquivo real, e NÃO corresponde a um diretório real?”. As duas precisam ser verdadeiras para a regra final disparar — assim uma imagem real, um CSS ou um PDF enviado são servidos diretamente e nunca passam pelo roteamento do WordPress.

RewriteRule . /index.php [L] é o que faz os links permanentes funcionarem: tudo que sobreviveu às duas condições anteriores — ou seja, não é um arquivo ou pasta real — é enviado para index.php, e o roteamento do próprio WordPress (WP_Query, tags de rewrite) decide qual post, página ou arquivo essa URL realmente significa.

Quando o WordPress recria esse arquivo, e quando não consegue

O WordPress tenta escrever o .htaccess por conta própria sempre que você abre Configurações > Links Permanentes e clica em Salvar Alterações, mesmo que nada tenha mudado na tela. Esse salvamento dispara flush_rewrite_rules(), que tenta abrir .htaccess para escrita e inserir o bloco atual entre os marcadores.

Essa tentativa falha silenciosamente, deixando o arquivo ausente ou desatualizado, quando:

• O arquivo ou sua pasta pai não têm permissão de escrita para o usuário com que o PHP é executado. Em muitas hospedagens compartilhadas, o PHP roda com um usuário de sistema diferente daquele que enviou os arquivos por FTP, então permissões que parecem corretas em um cliente FTP ainda bloqueiam a escrita do WordPress.
• Você está no nginx. .htaccess é um mecanismo exclusivo do Apache e do LiteSpeed (a documentação do Apache sobre AllowOverride explica por quê: o nginx não tem um arquivo de configuração por diretório que ele releia a cada requisição). O equivalente no nginx é uma diretiva try_files dentro do bloco server, editável apenas por quem tem acesso ao servidor; o WordPress nunca pode escrevê-la por você.
• AllowOverride está em None para o diretório do seu site na configuração principal do Apache. É essa configuração que permite que um .htaccess sobrescreva qualquer coisa; a documentação do Apache é explícita: com AllowOverride None, “os arquivos .htaccess são completamente ignorados” — o WordPress pode escrever um arquivo perfeito e ele continuará sem efeito até essa configuração ser alterada no nível do servidor.
• O arquivo foi apagado ou nunca existiu e algo no salvamento não disparou uma regeneração — o mais comum é que os links permanentes já estavam na mesma estrutura, então o WordPress não viu nenhuma mudança para reescrever.

Como restaurá-lo manualmente

Se posts e páginas dão 404 enquanto a home continua funcionando, essa é a assinatura de um .htaccess ausente ou quebrado. Resolva em duas etapas.

1. Tente primeiro a solução de um clique. Vá em Configurações > Links Permanentes no painel do WordPress e clique em Salvar Alterações sem mudar nada. Se o arquivo tiver permissão de escrita, isso por si só o regenera e resolve.

2. Se isso não resolver, crie o arquivo manualmente. Conecte-se via FTP/SFTP ou o gerenciador de arquivos do seu host, vá até a pasta onde o WordPress está instalado (a que contém wp-config.php) e verifique se .htaccess existe — é um arquivo oculto, alguns gerenciadores de arquivos o escondem por padrão; ative “mostrar arquivos ocultos”.

• Se estiver ausente, crie um novo arquivo com o nome exato .htaccess (sem .txt, nada antes do ponto).
• Cole o bloco padrão mostrado acima, ajustando RewriteBase se o WordPress estiver em uma subpasta.
• Salve e recarregue o link permanente de um post para confirmar que funciona.

Se ainda der 404 depois disso, a causa deixou de ser “o .htaccess está ausente” e passou a ser “o .htaccess está sendo ignorado” — pergunte ao seu host sobre AllowOverride, porque um arquivo correto em um diretório onde o Apache tem ordem de ignorá-lo se comporta exatamente como a ausência de arquivo.

Suas próprias regras versus o bloco do WordPress

Um plugin ou uma edição manual pode adicionar regras próprias — redirecionamentos, proteção contra hotlinking, cabeçalhos de cache. Isso é um bloco distinto e separado do que o WordPress gera, e os dois nunca deveriam se sobrepor:

# Regras que você ou um plugin adicionaram — ACIMA dos marcadores do WordPress
<FilesMatch "\.(jpg|jpeg|png|gif)$">
    # exemplo: proteção contra hotlinking, regras de cache, etc.
</FilesMatch>

# 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 WordPress

Qualquer coisa colocada entre # BEGIN WordPress e # END WordPress é apagada silenciosamente na próxima vez que alguém salvar a tela de Links Permanentes, porque o WordPress trata todo esse trecho como seu e o reescreve inteiro. Essa é a causa mais comum de “minha regra personalizada desapareceu” — ela nunca foi removida de propósito, apenas estava dentro de um bloco que o WordPress considera seu. Para redirecionamentos especificamente, veja regras de redirecionamento .htaccess do WordPress feitas corretamente para saber onde elas devem ficar e como evitar loops.

Também é a causa mais comum de um 500 Internal Server Error repentino logo após editar o arquivo: uma regra copiada de um fórum escrito para outra versão do Apache (sintaxe Order/Deny da 2.2 misturada com a sintaxe Require da 2.4) quebra a interpretação de todo o arquivo, inclusive o bloco do WordPress abaixo, e o site inteiro cai — não só a parte que você tocou.

Além do bloco padrão

O bloco padrão só cuida do roteamento de links permanentes. Se você também quer reforçar o acesso a arquivos sensíveis ou adicionar as poucas regras .htaccess que realmente reduzem a superfície de ataque — bloquear a execução de PHP em /uploads, negar requisições diretas a wp-config.php —, veja regras de segurança .htaccess do WordPress que realmente ajudam. E se os links permanentes dão 404 por outro motivo — estrutura de links permanentes errada, uma camada de cache servindo regras antigas, conflitos de multisite em subdiretórios —, links permanentes do WordPress que não funcionam percorre as outras causas.

Perguntas frequentes

O que é o arquivo .htaccess padrão do WordPress? É o bloco RewriteEngine que o WordPress escreve entre # BEGIN WordPress e # END WordPress para que os links permanentes sejam resolvidos em index.php em vez de darem 404.

Qual é o código exato do .htaccess padrão do WordPress? RewriteEngine On, RewriteBase /, uma regra de passagem para index.php, duas condições verificando que a requisição não é um arquivo ou diretório real, e uma regra final enviando todo o resto para index.php. O bloco completo está reproduzido no início deste guia.

Por que todos os meus posts dão 404, exceto a home? A home pode ser encontrada sem nenhuma regra de rewrite; qualquer outro link permanente precisa delas. Um .htaccess ausente ou corrompido no Apache produz exatamente esse padrão.

O WordPress recria o .htaccess automaticamente? Só se o arquivo tiver permissão de escrita — salvar novamente Configurações > Links Permanentes dispara isso. Se o arquivo não tiver permissão de escrita, estiver ausente em um host que não o gera automaticamente, ou AllowOverride estiver desativado, o WordPress não pode corrigir isso por você e você precisa criar ou corrigir o arquivo manualmente.

Por que o nginx não tem um arquivo .htaccess do WordPress? .htaccess só funciona no Apache e no LiteSpeed. O nginx não tem arquivo de configuração por diretório e ignora .htaccess completamente; o mesmo roteamento é escrito como uma regra try_files no bloco server do nginx.

Por que meu .htaccess quebrou depois que salvei os links permanentes? Uma regra personalizada foi colocada dentro dos marcadores # BEGIN WordPress / # END WordPress em vez de acima deles, e o WordPress sobrescreveu todo esse trecho no próximo salvamento dos links permanentes.

---

Reconstrua um .htaccess limpo e correto — bloco de links permanentes padrão mais qualquer regra de segurança ou redirecionamento que você realmente precise — com o gerador gratuito de .htaccess do WordPress.