.htaccess padrão do WordPress: código e como restaurar

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/ funcionem em vez de darem 404. É assim:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Essas regras vêm do código que o WordPress usa para gerar o bloco e coincidem com o próprio guia de .htaccess do WordPress. O WordPress também escreve três linhas de comentário logo depois de # BEGIN WordPress, avisando que edições entre os marcadores serão sobrescritas. Elas não mudam o funcionamento das regras.

Em uma instalação em subpasta, o WordPress coloca o caminho da subpasta tanto em RewriteBase quanto na última regra, por exemplo RewriteBase /blog/ e RewriteRule . /blog/index.php [L]. Redes multisite usam um bloco diferente, e o WordPress não escreve esse arquivo automaticamente para elas.

Resumo

• O WordPress gera esse bloco no Apache e no LiteSpeed quando tem acesso de escrita e os links permanentes amigáveis estão ativos. Abrir Configurações > Links Permanentes já basta.
• Se o arquivo estiver ausente ou corrompido, os links permanentes retornam 404 enquanto a home continua carregando, porque a home não precisa das regras de rewrite.
• Coloque tudo o que você ou um plugin adicionar acima de # BEGIN WordPress, nunca dentro dos marcadores. O WordPress substitui tudo entre eles quando atualiza o arquivo.

O que cada linha faz

RewriteEngine On ativa o módulo mod_rewrite do Apache para esse diretório; sem ela, as regras abaixo não fazem nada.

RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}] não altera a URL (é isso que o - significa) e copia o cabeçalho Authorization da requisição para uma variável do servidor. O WordPress lê essa variável para obter um nome de usuário e uma senha enviados no cabeçalho, como uma senha de aplicativo.

RewriteBase / define o prefixo de caminho que o Apache usa nas URLs reescritas. O WordPress o ajusta conforme o local do site, então uma instalação em subpasta recebe RewriteBase /blog/.

RewriteRule ^index\.php$ - [L] é uma proteção: 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 condições precisam ser verdadeiras para a regra final disparar, então 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 o que passou por essas duas condições é enviado para index.php, e o WordPress decide qual post, página ou arquivo essa URL significa.

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

O WordPress atualiza suas regras de rewrite toda vez que a tela Configurações > Links Permanentes carrega, então basta abri-la e você não precisa clicar em Salvar Alterações. Se o .htaccess estiver ausente, o WordPress o cria, desde que a pasta tenha permissão de escrita e os links permanentes amigáveis estejam ativos. Se o arquivo existir e tiver permissão de escrita, o WordPress substitui o bloco entre os marcadores.

Isso não resolve o problema nestes casos:

• O arquivo ou a pasta dele não têm permissão de escrita para o usuário com que o PHP é executado. A tela mostra um erro dizendo que o arquivo .htaccess não tem permissão de escrita, junto com as regras para colar. Em algumas hospedagens, o PHP roda com um usuário de sistema diferente do dono dos seus envios por FTP, então permissões que parecem corretas em um cliente FTP ainda podem bloquear o WordPress.
• Você está no nginx. O guia de nginx do WordPress diz que o nginx não tem um arquivo de configuração por diretório como o .htaccess e que o WordPress não pode alterar a configuração do servidor. O roteamento equivalente é uma diretiva try_files na configuração do servidor, que um administrador precisa editar.
• AllowOverride está em None para o diretório do seu site na configuração principal do Apache. A documentação do Apache diz (citação no original): “This means .htaccess files are completely ignored unless you explicitly enable them for a directory.” Ou seja, os arquivos .htaccess são completamente ignorados, a menos que você os ative explicitamente para um diretório. O WordPress pode escrever um arquivo perfeito e ele continuará sem efeito. As regras de rewrite precisam de AllowOverride FileInfo (ou All), o que talvez sua hospedagem precise alterar.
• Seus links permanentes estão em Simples. URLs simples não precisam de regras de rewrite, então o WordPress não cria o arquivo para elas.

Como restaurá-lo manualmente

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

1. Tente primeiro a solução de um clique. Abra Configurações > Links Permanentes no wp-admin e clique em Salvar Alterações sem mudar nada. Se o WordPress puder escrever o arquivo, isso o regenera. Se não puder, a tela mostra o erro e as regras de que você precisa.

2. Se isso não resolver, crie o arquivo manualmente. Conecte-se via FTP/SFTP ou pelo gerenciador de arquivos da sua hospedagem e vá até a pasta raiz do site, normalmente a que contém wp-admin. Verifique se .htaccess existe. O nome começa com um ponto, então 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 as regras que o WordPress mostrou ou o bloco padrão do início deste guia. Em uma instalação em subpasta, ajuste RewriteBase e a última regra.
• Salve e recarregue o link permanente de um post para confirmar que funciona.

Se ainda der 404, o .htaccess pode estar sendo ignorado. Verifique AllowOverride com sua hospedagem, pois o Apache ignora um arquivo correto quando essa opção está desativada.

Suas próprias regras versus o bloco do WordPress

Um plugin ou uma edição manual pode adicionar regras próprias, como redirecionamentos, proteção contra hotlinking ou cabeçalhos de cache. Mantenha essas regras fora do bloco do WordPress e acima dele, para que rodem antes da regra final que captura o restante das requisições:

# 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
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
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 se perde na próxima vez que o WordPress atualiza o arquivo, e carregar a tela de Links Permanentes já basta para isso. As linhas antes e depois dos marcadores são mantidas. Para redirecionamentos especificamente, veja regras de redirecionamento .htaccess do WordPress feitas corretamente para saber onde elas devem ficar e como evitar loops.

Um 500 Internal Server Error logo depois de editar o arquivo aponta para o que você acabou de mudar. A documentação do Apache diz que o log de erros provavelmente indicará uma diretiva não permitida ou um erro de sintaxe. Regras copiadas de um tutorial antigo podem causar isso: Order é um comando inválido no Apache 2.4, a menos que mod_access_compat esteja carregado. Desfaça a edição para recuperar o site e depois leia o log de erros.

Além do bloco padrão

O bloco padrão só cuida do roteamento de links permanentes e do cabeçalho Authorization. Para reforçar o acesso a arquivos sensíveis, como bloquear a execução de PHP em /uploads ou negar requisições diretas a wp-config.php, veja regras de segurança .htaccess do WordPress que realmente ajudam. Se os links permanentes dão 404 por outro motivo, como uma estrutura errada, uma camada de cache servindo regras antigas ou um conflito de multisite em subdiretório, 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 no arquivo .htaccess da raiz do site. Ele passa o cabeçalho Authorization para o PHP e envia para index.php qualquer requisição que não seja um arquivo ou pasta real.

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

Por que todos os meus posts dão 404, exceto a home? Um arquivo .htaccess ausente ou corrompido no Apache produz esse padrão. O servidor encontra a home sem regras de rewrite. Qualquer outro link permanente precisa dessas regras para chegar a index.php, então sem elas o Apache procura um arquivo que não existe e retorna 404.

O WordPress recria o .htaccess automaticamente? Sim, no Apache ou LiteSpeed com mod_rewrite, se os links permanentes amigáveis estiverem ativos e o WordPress puder escrever ali. Abrir Configurações > Links Permanentes já basta. Um arquivo ausente precisa de uma pasta com permissão de escrita, e um arquivo existente precisa ter permissão de escrita. Caso contrário, a tela mostra um erro, junto com as regras para colar manualmente.

Por que o nginx não tem um arquivo .htaccess do WordPress? O nginx não tem um arquivo de configuração por diretório como o .htaccess do Apache. O mesmo roteamento é escrito como uma regra try_files na configuração do servidor nginx, que um administrador precisa editar porque o WordPress não pode alterá-la.

Por que meu .htaccess quebrou depois que salvei os links permanentes? Verifique se uma regra personalizada foi colocada dentro dos marcadores # BEGIN WordPress e # END WordPress. O WordPress substitui tudo entre eles quando atualiza o arquivo, então essa regra se perde. Mantenha as regras personalizadas acima dos marcadores.

Fontes

• WordPress Advanced Administration: .htaccess
• WordPress Advanced Administration: Nginx
• Código-fonte do WordPress: class-wp-rewrite.php, options-permalink.php, misc.php, load.php, user.php, vars.php
• Apache HTTP Server 2.4: .htaccess files, mod_rewrite, Upgrading to 2.4

---

Reconstrua um .htaccess limpo e correto, com o bloco padrão de links permanentes e as regras de segurança ou redirecionamento de que você realmente precisa, usando o gerador gratuito de .htaccess do WordPress.