A KapsuleHost serve todos os sítios com um servidor web de alto desempenho que não lê .htaccess, pelo que as regras que adicionar a esse ficheiro não têm qualquer efeito: este guia explica o que isso significa para um sítio WordPress e mostra a definição do KPanel que faz cada tarefa em vez disso.
Se mudou de um alojamento cPanel partilhado, .htaccess era provavelmente onde colocava redireccionamentos, a imposição de HTTPS, páginas de erro personalizadas e bloqueios de bots. Todas essas funcionalidades continuam a funcionar na KapsuleHost. Simplesmente são configuradas no KPanel em vez de num ficheiro de texto, e, porque são aplicadas ao nível do servidor, são mais rápidas e não podem danificar o seu sítio com um erro de digitação.
Porque é que o .htaccess Aqui Não Faz Nada
.htaccess é um ficheiro de configuração por directório para o servidor web Apache. O Apache volta a lê-lo em cada pedido, o que o torna prático, mas também é o que o torna lento.
A KapsuleHost não utiliza o Apache. O seu sítio é servido por um servidor web orientado a eventos que carrega a sua configuração uma única vez no arranque, o que explica em grande parte porque é que os sítios aqui respondem mais depressa sob carga. Esse servidor não tem equivalente a um ficheiro de substituição por directório, pelo que nunca abre o .htaccess.
Adicionar regras ao .htaccess num sítio da KapsuleHost falha silenciosamente. Não surge nenhum erro, não há qualquer aviso, e o ficheiro permanece exactamente onde o deixou. As regras simplesmente nunca são executadas. Se estiver a seguir um tutorial de WordPress que diz "adicione isto ao seu .htaccess", procure antes o equivalente no KPanel na tabela abaixo.
A boa notícia é o inverso da habitual história de terror do .htaccess: um erro de sintaxe no ficheiro não pode aqui derrubar o seu sítio, porque nada o interpreta.
O Que Continua a Funcionar Sem Ele
Permalinks. A razão mais comum para um sítio WordPress precisar do .htaccess no Apache são os permalinks amigáveis. Na KapsuleHost, a reescrita está integrada na configuração do servidor do seu sítio, pelo que o /2026/07/my-post/ é resolvido através do WordPress sem qualquer bloco .htaccess. Se os permalinks estiverem a devolver erros 404, a causa é outra: consulte Resolver Problemas de Permalinks do WordPress.
O WordPress a escrever no ficheiro. O WordPress e alguns plugins continuam a escrever blocos # BEGIN/# END no .htaccess porque partem do princípio de que estão a correr sobre Apache. Isso é inofensivo. O ficheiro é real, pode ser editado, e vai vê-lo no gestor de ficheiros. Simplesmente não tem leitor.
Plugins de segurança que relatam "reforço aplicado". Os plugins que afirmam ter protegido xmlrpc.php ou wp-config.php editando o .htaccess não protegeram, de facto, nada nesta plataforma. Utilize o separador Segurança do próprio sítio, que aplica as regras equivalentes ao nível do servidor.
Equivalentes no KPanel para Regras Comuns do .htaccess
Todas estas definições estão no próprio sítio: Websites, depois o seu sítio, depois o separador indicado.
| O que teria escrito no .htaccess | Onde se encontra no KPanel |
|---|---|
RewriteCond %{HTTPS} off para forçar HTTPS | Definições, depois Forçar HTTPS em Behavior |
Redirect 301 /old /new | Definições, depois Redirecionamentos |
ErrorDocument 404 /404.html | Definições, depois Páginas de erro |
AuthType Basic para proteger uma pasta com palavra-passe | Definições, depois Proteção por palavra-passe |
Require not ip 203.0.113.4 para bloquear um endereço | WordPress, depois Segurança |
RewriteCond %{HTTP_USER_AGENT} (BadBot) para bloquear motores de indexação | Desempenho, depois Rastreadores |
DirectoryIndex index.php index.html | Definições, depois Índice de directório em Serving |
mod_deflate / mod_expires para compressão e cache | Já activo. Os cabeçalhos de compressão e de cache são definidos ao nível do servidor |
Duas destas funcionalidades fazem mais do que a versão em .htaccess alguma vez conseguiria. Os redireccionamentos suportam caminhos exactos, prefixos com barra final e caracteres universais como /blog/*, e o KPanel verifica o redireccionamento ao vivo depois de guardar. As páginas de erro são servidas com o seu verdadeiro código de estado, pelo que uma página 404 personalizada continua a ser um verdadeiro 404 para os motores de busca, em vez de um 200 com um pedido de desculpas.
Localizar e Ler o Ficheiro
Pode ainda assim querer ver o .htaccess, normalmente para perceber o que um plugin escreveu nele ou para copiar regras antes de as recriar no KPanel.
A partir do separador WordPress
- Inicie sessão no KPanel e clique em Websites na barra lateral esquerda.
- Clique no sítio pretendido.
- Abra o separador WordPress e depois a secção wp-config.
- Desloque-se até ao painel
.htaccess. O conteúdo é apresentado apenas para leitura, com um botão Edit caso precise de o alterar.
A partir do gestor de ficheiros
- Abra o sítio, depois Definições, depois Gestor de Ficheiros.
- Clique em Mostrar Ocultos na barra de ferramentas. Os ficheiros que começam com um ponto estão ocultos por defeito, pelo que o
.htaccessnão aparecerá até fazer isto. - Clique em
.htaccesspara o abrir no editor integrado.
O ficheiro encontra-se na raiz do seu sítio, junto a wp-config.php e wp-content. O detalhe completo sobre o editor e os respectivos controlos de permissões está em Utilizar o Gestor de Ficheiros.
Faça uma cópia de segurança antes de editar qualquer coisa na raiz do sítio, mesmo um ficheiro que não esteja a ser lido. Não custa nada e significa que um único clique o repõe tudo. Consulte Fazer uma Cópia de Segurança.
O Bloco Predefinido do WordPress
Para referência, este é o bloco que o WordPress escreve para si próprio. Num alojamento Apache, controla os permalinks. Na KapsuleHost está inactivo, e eliminá-lo não vai causar qualquer problema:
# 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
Deixe-o no lugar se mais tarde puder mudar o sítio para um alojamento Apache. De qualquer forma, o WordPress volta a reescrevê-lo da próxima vez que guardar as definições de permalinks.
Se Estiver a Migrar Regras
Quando trouxer um sítio do cPanel, abra o antigo .htaccess antes de cancelar o alojamento antigo e percorra-o linha a linha:
- Redireccionamentos. Recrie cada
RedirectouRewriteRuleem Definições, depois Redirecionamentos. Uma linha por regra. Escolha 301 para uma mudança permanente, 302 se a alteração puder ser revertida. - Imposição de HTTPS. Elimine-a. Active antes a opção Forçar HTTPS nas Definições do sítio.
- Bloqueios de IP. Recrie-os em WordPress, depois Segurança, no painel de bloqueio de IP.
- Cabeçalhos de cache e compressão. Elimine-os. São geridos automaticamente, e regras antigas de
mod_expiresde um alojamento anterior são uma causa comum de comportamentos de cache confusos. - Qualquer coisa escrita por um plugin. Ignore-a. Reinstale o plugin no novo sítio e deixe-o fazer a sua própria configuração.
A sua migração preserva o próprio ficheiro, pelo que nada se perde enquanto percorre a lista. Explicação completa da migração: Migrar um Website do cPanel.
Resolução de Problemas
"Adicionei um redireccionamento ao .htaccess e nada aconteceu." Era de esperar. Adicione-o em Definições, depois Redirecionamentos. A coluna Status aí indica se o redireccionamento foi verificado ao vivo.
"Um plugin diz que o meu sítio está reforçado, mas um scanner discorda." O plugin escreveu regras em .htaccess que não estão a ser lidas. Verifique o separador Segurança do sítio para ver as proteções que estão genuinamente aplicadas.
"O .htaccess do meu alojamento antigo tinha regras que não compreendo." Não as copie às cegas. Abra um pedido de suporte com o ficheiro em anexo e diremos quais têm um equivalente na KapsuleHost e quais apenas compensavam um alojamento Apache partilhado.
"Os permalinks estão avariados." Aqui, isto não é um problema de .htaccess. Consulte Resolver Problemas de Permalinks do WordPress, ou limpe as regras de reescrita a partir do separador WordPress do sítio, depois Ações Rápidas, depois Limpar Rewrites.