Erros 404 em elementos estáticos tornam a navegação lenta

Quando acede a um endereço que não existe no WordPress, este devolve um erro 404 de "página não encontrada" com o design do seu próprio tema, o que é lógico, uma vez que mantém um fluxo de navegação familiar para o visitante.

O problema pode surgir quando uma página chama uma imagem, CSS ou JavaScript inexistente e a configuração do servidor envia também esse pedido para o WordPress. Não acontece em todos os servidores: confirme primeiro que processo gera a resposta 404.

Convém perceber a diferença de custo. Numa configuração que serve recursos estáticos diretamente, um ficheiro existente não precisa de iniciar o PHP; o tempo real depende do servidor e da rede. Um ficheiro que não existe cai no encaminhamento do WordPress, que arranca a aplicação inteira, carrega os plugins, consulta a base de dados e compõe a página 404 do seu tema. Num caso real medido nos nossos servidores, cada um desses 404 devolvia 28 KB de página renderizada, enquanto o mesmo erro servido pelo servidor web ocupava 796 bytes.

Se o próprio modelo 404 voltar a pedir o recurso inexistente, cada erro pode gerar pedidos adicionais. Para os relacionar com uma sobrecarga, verifique que coincidem em hora e caminho com o aumento de processos ou do tempo de resposta.

Como detetá-lo

O consumo elevado de CPU e vários processos PHP sobre index.php são indícios, não a causa confirmada. Para verificar a relação, reveja o registo de acessos no cPanel em Metrics → Raw Access.

Procure nele o mesmo URL repetido muitas vezes. Exemplo baseado no caso, com endereço e domínio de documentação:

192.0.2.10 - - [09/Aug/2026:22:36:03 +0200] "GET /wp-content/plugins/popup-maker/dist/packages/block-library-style.css?ver=7424eb959f91acb8bbb2 HTTP/1.1" 404 28113 "-" "WordPress/6.8.7; https://www.omeudominio.com"

Há dois detalhes que denunciam o problema:

• O IP coincide com o do servidor e o agente declara WordPress. Nesse caso concreto era um pedido interno; noutro registo é preciso confrontar ambos os dados antes de o afirmar.
• O código é 404 e o tamanho era de dezenas de kilobytes. Essa medição era compatível com a página renderizada pelo tema, mas deve verificar a sua própria resposta.

Nesse caso concreto, o site pedia a si próprio o mesmo CSS inexistente cerca de seis vezes por minuto, de forma ininterrupta durante semanas, e chegava a esgotar o limite de CPU da conta.

A solução: não deixar o WordPress gerir esses 404

A solução principal é eliminar a referência ao conteúdo inexistente. Se tiver confirmado que esses pedidos entram no WordPress, a regra seguinte funciona como rede de segurança e faz com que o servidor responda antes para as extensões indicadas.

Antes de o alterar, descarregue uma cópia do .htaccess atual para o poder restaurar se o site devolver um erro 500. Para desativar a gestão dos erros 404 em ficheiros estáticos, acrescente depois o seguinte bloco:

# BEGIN 404 ESTATICOS
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} \.(gif|jpe?g|png|webp|avif|svg|ico|css|js|map|woff2?|ttf|eot)$ [NC]
RewriteRule ^ - [R=404,L]
</IfModule>
# END 404 ESTATICOS

As duas primeiras condições deixam passar qualquer ficheiro ou diretório que exista, de modo que a regra só atua sobre o que falta. A terceira limita a regra a extensões de conteúdo estático e normalmente deixa de fora os endereços do site que não têm extensão. Vale a pena incluir os tipos de letra (woff, woff2, ttf, eot) e os mapas de código (map), que estão entre os que mais 404 silenciosos geram num tema.

Onde colocar o bloco

Procure no ficheiro a linha # BEGIN WordPress e cole o bloco imediatamente acima. Deixe-o fora de qualquer bloco que um plugin gira automaticamente.

O motivo de ficar acima de # BEGIN WordPress é que esse bloco é precisamente o que envia para index.php tudo o que não existe em disco. Se o colocar depois, o WordPress já terá ficado com o pedido.

Não o coloque à frente das regras do LiteSpeed Cache: poderia intercetar um URL que o plugin precisa de reescrever. Como os blocos variam consoante a instalação, teste uma imagem otimizada existente e um URL inventado antes de manter a alteração.

Verifique também que ErrorDocument 404 não aponta para PHP. Se usar ErrorDocument 404 /404.shtml, verifique que esse ficheiro existe, é estático e não volta a passar pelo WordPress.

Verificar que funciona

Depois de guardar o ficheiro, abra estes três endereços no seu navegador, substituindo omeudominio.com pelo seu.

1. O seu site, para excluir uma gralha

https://omeudominio.com/

Deve carregar normalmente. Se aparecer um 500 ou um ecrã em branco logo após a alteração, restaure a cópia e consulte o registo. Pode haver uma gralha, uma diretiva não permitida ou uma interação com outras regras; o código por si só não distingue a causa.

2. Um ficheiro estático que não existe, com um nome inventado

https://omeudominio.com/esto-no-existe.css

Deve responder com o código 404 e uma página leve servida sem carregar o design do WordPress. O seu aspeto exato depende da configuração do servidor e de ErrorDocument.

Se, pelo contrário, aparecer a página de "não encontrado" com o design do seu tema, o menu e o rodapé, reveja a ordem da regra e ErrorDocument: pode ser este último a enviar o erro novamente para o PHP.

3. Uma página do seu site que não existe

https://omeudominio.com/esta-pagina-no-existe/

Aqui deve continuar a ver o 404 do seu tema, com o design habitual. A regra só interceta endereços inexistentes que terminam numa das extensões indicadas. Se a sua aplicação utilizar rotas virtuais com essas extensões, acrescente uma exclusão específica e teste-as antes de manter a regra.

Isto é uma rede de segurança, não a correção

O bloco torna o erro mais barato, mas a chamada ao ficheiro em falta continua a acontecer. Procure a origem no separador Rede das ferramentas de programador do navegador, que lhe dirá que recurso está a ser pedido e a partir de onde.

O separador Iniciador e o registo permitem saber que página ou componente pediu o recurso. Reinstale um plugin apenas se tiver confirmado que o ficheiro deveria pertencer a esse pacote; se a referência vier de uma cache, limpe essa cache depois de a corrigir.

Se quiser aprofundar o desempenho da sua instalação, tem o guia de otimização do WordPress e o do LiteSpeed Cache.

No teste de um URL inexistente, use também parâmetros de consulta e maiúsculas na extensão. Verifique qualquer endpoint virtual que termine em .js, .css ou numa extensão incluída antes de implementar: a regra não o consegue distinguir de um ficheiro inexistente. Compare o código HTTP e a carga antes e depois, mantendo a correção da referência como tarefa principal.