Uma falha de health check num servidor de borda, um erro 500 que sumia antes de qualquer log, e um cliente que jurava que o site estava lento por culpa do WordPress. A história real que vou contar não está em nenhum manual de boas práticas. Pelo menos, não nos que você encontra online.
Era terça-feira, 2h34 da manhã. O alerta de pico de latência no cluster Kubernetes acordou o engenheiro de plantão. O time de SEO já estava em pânico: o Core Web Vitals de um site de notícias com 3 milhões de visitas diárias havia despencado. O LCP estava em 8 segundos. O INP, em state frustrating. Mas o mais intrigante foi a causa raiz: um .htaccess.
Sim, um arquivo de configuração do Apache, num setup Headless WordPress rodando em containers. Parece absurdo? Então me acompanhe no estudo de caso reverso que vai explodir sua cabeça e, de quebra, revelar o que a licença GPL realmente significa quando ninguém está olhando.
O Setup: Headless WP e o Gancho Esquecido
O ambiente era clássico: front-end em React (Next.js) consumindo a REST API do WordPress, com cache via Varnish e Redis. Tudo otimizado, pensado para escalar. A equipe de desenvolvimento seguiu o manual: utilizou ACF para campos personalizados, Yoast SEO para metadados, e WPGraphQL para consultas mais enxutas. O backend WordPress rodava em uma instância dedicada, com PHP 8.1 e NGINX. Porém, a arquitetura previa um balanceador de carga que fazia proxy reverso para um Apache legado — uma decisão de infraestrutura que ninguém questionou, porque funcionava há anos.
Foi aí que o .htaccess entrou em cena. Uma regra de RewriteRule criada para redirecionar URLs antigas de uma migração de 2018. Ninguém lembrava dela, ninguém sabia que existia. O arquivo estava oculto, com permissão 644, na raiz do volume compartilhado entre os pods. A regra era inofensiva? Não. Ela impunha uma regex mal escrita que, a cada requisição com parâmetros de busca (tipo ?s=fernando+de+noronha&page=2), disparava um loop de processamento no Apache. O Apache, então, consumia CPU a ponto de estourar a cota do container no Kubernetes, gerando evicções e reinicializações constantes.
O resultado? A REST API ficava intermitente, o cache do Redis era invalidado sem necessidade, e o Next.js, em modo stale-while-revalidate, servia dados desatualizados ou erros 500 disfarçados. O Core Web Vitals foi para o buraco. E o pior: ninguém desconfiava do .htaccess, porque a configuração oficial do WordPress (wp-config.php) ignorava override autorizado via AllowOverride None. Mas o Apache estava compilado com mod_rewrite ativo e, por um bug de configuração do balanceador, o AllowOverride All estava habilitado na diretiva de diretório específica. Um desastre.
O Diagnóstico Invisível
Ferramentas comuns de site audit (Lighthouse, GTmetrix, WebPageTest) não capturaram o problema, porque as requisições demoradas eram consideradas normais em picos de tráfego. O monitoramento de APM (New Relic, Datadog) mostrava picos de CPU no serviço Apache, mas atribuía a picos de tráfego legítimos. O time de infra achava que era malware ou ataque DDoS. A equipe de SEO caçava plugins pesados, scripts de terceiros, imagens não otimizadas. Mas ninguém olhou para o .htaccess.
Durante três dias, a página inicial levava 12 segundos para carregar. A taxa de rejeição subiu 45%. O cliente perdeu receita. Até que um desenvolvedor mais antigo, lembrando de um artigo do WordPress.org sobre segurança, resolveu forçar AllowOverride None no arquivo de configuração do Apache, dentro do container. O resultado: o servidor ficou offline por 5 minutos, mas depois se estabilizou. O erro desapareceu. E lá estava ele: um .htaccess com 14 regras, sendo 9 inúteis, 3 mal escritas e 1 quebrada.
O Gancho Perdido: A Metáfora do Carrinho de Melado
Lembra daquela história do carrinho de melado que, mesmo vazio, engrossava o trânsito? Pois é. O .htaccess era o gancho perdido. No ecossistema WordPress, especialmente em sites velhos ou com muitas migrações, os ganchos perdidos são como pedaços de um colar quebrado: você não vê, mas eles estão lá, enroscando em tudo. No caso, a regra antiga de redirecionamento se comportava como um hook residual, processando requisições desnecessárias, sem que nenhum script ativo o invocasse. Era um gancho morto.
E por que a licença GPL tem a ver com isso? Porque o .htaccess sequer era parte oficial do WordPress. Era um arquivo de configuração do servidor, mas que o ecossistema GPL permite qualquer customização. E o pior: o WordPress, por padrão, suporta .htaccess para reescrita de URL. Ou seja, a própria fundação do software permite que você enfie um monte de regras ruins. A cultura GPL incentiva a liberdade de modificar, mas também liberta a negligência.
Core Web Vitals e o Mito do Headless
Se você pensou que Headless WordPress resolve performance, está enganado. O Core Web Vitals não depende apenas do front-end. Ele depende da integridade do backend. Um simples redirecionamento mal feito pode causar tempo de resposta altíssimo, impactando o TTFB e, consequentemente, o LCP. No caso real, o TTFB normal era 200ms. Com o .htaccess quebrado, ele subia para 4 segundos em 30% das requisições. Isso é o suficiente para arruinar qualquer métrica.
E mais: o Google não perdoa. Seu site pode ter o melhor layout, as imagens mais otimizadas, o JavaScript mais enxuto, mas se o servidor demorar a responder, você será penalizado. O caso de estudo prova que focar apenas no front-end é cegueira.
Lições do Estudo de Caso Reverso
No fim, descobrimos a verdade: a equipe de desenvolvimento havia, dois anos antes, contratado um freelancer que “resolveu” um problema de redirecionamento adicionando regras no .htaccess. O freelancer seguiu a documentação do WordPress, que diz: “Se você não tem acesso ao Apache, pode usar o .htaccess”. O problema é que ninguém revisou o código. E o .htaccess ficou ali, adormecido, até que o volume de tráfego crescesse e ele se tornasse um funil de CPU.
A solução definitiva: migrar todas as regras de redirecionamento para o próprio WordPress, usando wp_redirect ou add_rewrite_rule. Ou, melhor ainda, usar um plugin de redirecionamento dedicado (e bem escrito). Nunca confie em .htaccess em ambientes Headless. E, acima de tudo, implemente monitoramento de TTFB por rota com alertas para desvios acima de 1 segundo. Se tivéssemos feito isso, teríamos encontrado o erro em 30 minutos, não em 3 dias.
O que o GPL Esconde?
A licença GPL permite que você modifique o WordPress, instale plugins, altere código. Mas ela também permite que você acumule débitos técnicos. O .htaccess não é oficial, mas é permitido. E aí mora o perigo. O ecossistema WordPress é tão aberto que você pode quebrá-lo de maneiras que nem os desenvolvedores principais imaginam. A verdadeira proteção não está na licença, mas na disciplina de engenharia: rejeitar configurações obscuras, auditar constantemente e matar os ganchos perdidos.
Então, da próxima vez que seu Core Web Vitals cair, não olhe só para as imagens ou o JavaScript. Olhe para os cantos escuros. Olhe para o .htaccess. E lembre-se: o WordPress pode ser livre, mas a liberdade tem um custo: a vigilância eterna.
— Baseado em fatos reais, de um engenheiro que quase enlouqueceu num sábado à noite.