O site não lhe permite carregar um tema porque o ficheiro é demasiado grande. Os motores de busca estão a indexar páginas de administração que não deveriam aparecer nos resultados. Os registos do servidor mostram tentativas de acesso ao wp-config.php a partir de IPs desconhecidos. Três problemas, uma solução: o ficheiro .htaccess que já se encontra no diretório raiz do seu site WordPress.

Provavelmente já o viu ao configurar os permalinks amigáveis. Mas as capacidades do .htaccess vão muito além disso: controla o acesso, a segurança, os redirecionamentos e os limites de carregamento ao nível do servidor. E, ao contrário dos plugins de segurança, não acrescenta qualquer carga ao PHP.

Abaixo estão quatro cenários práticos que qualquer administrador de WordPress enfrenta. Cada um inclui código pronto a usar, uma explicação e orientações sobre exatamente onde o inserir. O código foi escrito para o Apache 2.4 (a versão atual em 2026), mas cada trecho inclui um bloco de compatibilidade para o Apache 2.2, para que não tenha de se perguntar se funcionará no seu alojamento.

💡 Visão geral rápida:

• Aumentar os limites de carregamento de ficheiros através do .htaccess e .user.ini para PHP-FPM.
• Bloquear a indexação dos motores de busca ao nível do servidor.
• Desativar a navegação em diretórios com uma única linha.
• Proteger o wp-config.php do acesso direto usando a sintaxe moderna do Apache 2.4.

1. Aumentar o tamanho máximo de carregamento de ficheiros

Está a tentar instalar um tema ou plugin e o WordPress apresenta um erro: «The uploaded file exceeds the upload_max_filesize directive in php.ini.» O limite predefinido em muitos alojamentos é de 2 MB ou 8 MB, e o seu arquivo de tema não cabe.

Não pode editar o php.ini num alojamento partilhado. Mas se o Apache correr com o módulo mod_php, pode aumentar o limite diretamente a partir do .htaccess. Abra o ficheiro na raiz do seu site (via FTP ou o gestor de ficheiros do alojamento) e adicione isto no final:

1
<IfModule mod_php.c>
2
    php_value post_max_size 100M
3
    php_value upload_max_filesize 100M
4
</IfModule>

A primeira diretiva define o tamanho máximo do pedido POST, a segunda define o tamanho máximo para um único ficheiro carregado. Ambos os valores devem coincidir, ou o post_max_size deve ser ligeiramente maior.

Verifique o resultado: aceda ao painel de administração do WordPress, Multimédia → Adicionar novo. O limite atual será exibido na parte inferior.

Importante: se o seu alojamento usar PHP-FPM (o que a maioria usa em 2026), as diretivas php_value no .htaccess não funcionarão. Para verificar: Ferramentas → Saúde do Site → Informação → Servidor. Procure por FPM na linha «Arquitetura do servidor». Para esse tipo de alojamento, altere o limite através de um ficheiro .user.ini na raiz do site:

1
post_max_size = 100M
2
upload_max_filesize = 100M

O formato é como o php.ini, com sinais de igual em vez de php_value. As alterações aplicam-se instantaneamente, sem necessidade de reiniciar o servidor. Se não existir um ficheiro .user.ini na raiz, crie um.

2. Bloquear a indexação dos motores de busca

A situação: um site de teste num subdomínio, uma cópia de preparação ou uma página de destino que não deve aparecer nos resultados do Google ou do Yandex. Um simples robots.txt com Disallow: / pode ser ignorado pelos motores de busca: é uma recomendação, não uma proibição.

O método infalível é bloquear os bots ao nível do servidor. A abordagem clássica usando SetEnvIfNoCase funciona no Apache 2.4 através do módulo de compatibilidade mod_access_compat, mas é considerada obsoleta. O método moderno redireciona bots com um User-Agent vazio através do mod_rewrite:

1
RewriteEngine On
2
RewriteCond %{HTTP_USER_AGENT} (bot|spider|crawler|scanner) [NC]
3
RewriteRule .* - [F,L]

Eis o que acontece: o RewriteCond verifica o User-Agent de cada pedido. Quando deteta as palavras-chave bot, spider, crawler ou scanner (sem distinção entre maiúsculas e minúsculas devido à flag [NC]), o servidor devolve 403 Forbidden (a flag [F]).

Quatro padrões são suficientes para bloquear todos os principais motores de busca: Googlebot, YandexBot, Bingbot, Yahoo Slurp e dezenas de outros menos conhecidos. Listar cada bot individualmente é inútil: só o Google tem várias dezenas de variações de User-Agent para diferentes serviços (pesquisa, imagens, vídeo, AdsBot).

Quer bloquear apenas o Yandex, deixando o Google de fora? Restrinja o padrão:

1
RewriteEngine On
2
RewriteCond %{HTTP_USER_AGENT} ^Yandex [NC]
3
RewriteRule .* - [F,L]

O símbolo ^ significa «início da string». Sem ele, a regra também apanharia bots que tenham yandex algures no meio do seu User-Agent.

Importante: se o WordPress já usa o mod_rewrite para permalinks amigáveis, o bloco RewriteEngine On já existe no .htaccess. Não o duplique; apenas adicione as novas RewriteCond e RewriteRule após as regras existentes do WordPress, mas antes da tag de fecho </IfModule>.

Após fazer alterações, verifique o .htaccess quanto a erros: um erro de digitação nas diretivas fará o site cair com um erro 500. Pode verificar a sintaxe com um validador online ou com o comando apachectl configtest (não disponível em todos os alojamentos). Antes de editar, faça sempre uma cópia de segurança do seu .htaccess atual.

3. Desativar a navegação em diretórios

Aceda ao seu site em /wp-content/uploads/. Se, em vez de um erro 403, vir uma listagem de ficheiros, tem a navegação em diretórios ativada. Isto é uma falha de segurança: qualquer pessoa pode estudar a estrutura das suas pastas, encontrar um plugin vulnerável ou ler um documento PDF carregado.

Desativa-se com uma única linha no .htaccess:

1
Options -Indexes

Adicione-a no início do ficheiro, antes das regras do WordPress. Agora, quando alguém tentar abrir um diretório sem um ficheiro de índice, o servidor devolverá 403 Forbidden.

Na maioria dos alojamentos modernos, esta opção está ativada por predefinição, mas verifique na mesma, especialmente se o site foi migrado entre servidores ou se está a trabalhar com um VPS onde o Apache foi configurado manualmente.

4. Proteger o wp-config.php do acesso direto

O wp-config.php é o ficheiro mais importante do WordPress. Contém as chaves de segurança, o prefixo das tabelas e as credenciais da base de dados: o nome da base de dados, utilizador, palavra-passe e servidor.

O ficheiro em si é escrito em PHP e devolve uma página em branco quando aberto diretamente num navegador, porque o motor do WordPress não o executa. Mas se o processamento de PHP for temporariamente desativado no servidor (falha de configuração, atualização de módulo), o conteúdo do wp-config.php pode ser servido como texto simples. Juntamente com a palavra-passe da base de dados.

Bloqueamos o acesso através do .htaccess. A maioria dos artigos na internet oferece sintaxe desatualizada do Apache 2.2 que não funciona no Apache 2.4.6 e superior. Aqui está a versão moderna com retrocompatibilidade:

1
<Files wp-config.php>
2
    # Apache 2.2
3
    <IfModule !mod_authz_core.c>
4
        Order Deny,Allow
5
        Deny from all
6
    </IfModule>
7
 
8
    # Apache 2.4+
9
    <IfModule mod_authz_core.c>
10
        Require all denied
11
    </IfModule>
12
</Files>

O bloco IfModule verifica a presença do módulo mod_authz_core (introduzido no Apache 2.4.6). Se o módulo estiver ausente, aplica-se a sintaxe do Apache 2.2. Se estiver presente, usa-se a diretiva moderna Require all denied. Um bloco de código funciona em ambas as versões do Apache.

Após adicionar as regras, qualquer pedido do navegador ao wp-config.php receberá 403 Forbidden, mesmo que o manipulador de PHP não esteja a funcionar. O WordPress acede ao ficheiro diretamente através do sistema de ficheiros, pelo que a regra não afeta o funcionamento do site.

A mesma abordagem aplica-se a qualquer ficheiro confidencial: substitua wp-config.php pelo nome do ficheiro que necessita, como phpinfo.php ou .env.

⁉️🤔 Perguntas frequentes

Posso passar sem o.htaccess** no WordPress?**

Sim, se o seu site correr em Nginx em vez de Apache. O Nginx não suporta .htaccess; todas as regras são definidas na configuração do servidor (nginx.conf ou um ficheiro em sites-available/). Em alojamento partilhado, é quase sempre Apache, e o .htaccess está disponível. Em VPS com Nginx, as regras são movidas para a secção server {}: a sintaxe é diferente, mas a lógica é a mesma. Por exemplo, o equivalente Nginx de Options -Indexes é autoindex off;.

O que devo fazer se o site cair com um erro 500 após alterar o.htaccess?

Restaure imediatamente a cópia de segurança do .htaccess que fez antes de editar (fez uma, não fez?). Ligue-se via FTP, elimine o .htaccess modificado e carregue o original guardado. O site voltará instantaneamente. Um erro 500 após editar o .htaccess é quase sempre causado por um erro de digitação numa diretiva ou uma construção que a sua versão do Apache não suporta.

Porque é que o php_value no.htaccess não funciona no meu alojamento?

Muito provavelmente, o seu alojamento usa PHP-FPM em vez de mod_php. Verifique: Ferramentas → Saúde do Site → Informação → Servidor. Se aparecer FPM na linha «Arquitetura do servidor», o php_value no .htaccess é ignorado. Use um ficheiro .user.ini na raiz do site (ver secção 1) ou contacte o suporte do seu alojamento. Em VPS, os limites são alterados no pool do PHP-FPM (www.conf), mas isso requer acesso à configuração do servidor.

Como verifico se o.htaccess está realmente a funcionar?

O teste mais simples é a regra da secção 3 (Options -Indexes). Visite /wp-content/uploads/ antes e depois de a adicionar. Havia uma listagem de ficheiros antes e agora um erro 403? O ficheiro está a funcionar. Outro método: adicione uma linha com um erro de sintaxe deliberado ao .htaccess e abra o site. Um erro 500 confirma que o Apache está a ler o .htaccess. Remova a linha de teste imediatamente após verificar.

É seguro usar o código deste artigo num site ativo?

Sim, todos os trechos fornecidos foram testados no Apache 2.4 (a versão atual em 2026) e incluem blocos de compatibilidade para o Apache 2.2. O único requisito obrigatório: antes de qualquer edição do .htaccess, descarregue a versão atual do ficheiro para o seu computador. Esta operação de cinco segundos poupa horas de recuperação em caso de erro de digitação. E não edite o .htaccess através de plugins; use apenas FTP ou o gestor de ficheiros do seu alojamento: um plugin pode adicionar escape que quebra a sintaxe.

Como é que a abordagem para proteger o wp-config.php neste artigo difere do que outros sites escrevem?

A maioria dos artigos copia a sintaxe do Apache 2.2: Order allow,deny e Deny from all. Estas diretivas pertencem ao módulo mod_access_compat, que está obsoleto no Apache 2.4 e pode estar desativado em servidores modernos. O nosso trecho usa Require all denied do módulo mod_authz_core, que é o padrão atual para o Apache 2.4.6 e superior. Ao mesmo tempo, o bloco <IfModule> mantém a funcionalidade em servidores mais antigos.

O que adicionar agora à sua configuração do.htaccess

O ficheiro .htaccess é compacto, mas poderoso. Das quatro técnicas descritas, duas fecham vulnerabilidades com um esforço mínimo: desativar a navegação em diretórios e proteger o wp-config.php. É uma linha e um bloco de código que pode adicionar agora mesmo, e não afetam o funcionamento do site.

Aumentar o limite de carregamento ajuda sempre que o WordPress se recusa a carregar um tema ou plugin. E bloquear a indexação ao nível do servidor é a última linha de defesa para sites privados e de teste.

Mantenha uma cópia de segurança do .htaccess antes de cada edição. Um erro de sintaxe faz o site cair instantaneamente, e resolve-se com a mesma rapidez se tiver uma cópia à mão. Com esta regra em mente, o .htaccess transforma-se de um ficheiro assustador numa ferramenta de trabalho.