Um cliente me ligou no mês passado, meio assustado, depois de receber um email de seu provedor de hospedagem. O assunto não era bom: "Seu site está consumindo recursos excessivos." As opções eram fazer upgrade do plano ou migrar para um servidor melhor.
Seus gráficos de tráfego no GA4 estavam estáveis. Os mesmos visitantes do mês anterior. Então entrei nos logs de acesso para entender o que estava acontecendo.
Não era um DDoS. Bem, era tipo um DDoS. Feito por bots de IA.
A invasão de crawlers
Puxe o log de acesso bruto de qualquer site moderadamente popular agora e você os verá: GPTBot. ClaudeBot. PerplexityBot. Bytespider. Google-Extended. Meta-ExternalAgent. OAI-SearchBot. CCBot. Applebot-Extended. Cada um deles rastreando página após página, produto após produto, post após post, em um cronograma que ninguém consultou.
A matemática fica feia rapidamente. Cada uma dessas requisições dispara um bootstrap completo do WordPress: tema, widgets, construtores de página, plugins, tudo o que faz seu site WordPress funcionar. Consultas ao banco de dados disparam. CSS e JavaScript são montados. E então, depois que o servidor fez todo esse trabalho, a resposta sai: 80, 100, às vezes 200 kilobytes de HTML por página.
No final, o bot lê cerca de 5% disso.
Então você pagou pelo tempo de CPU, pela memória, pela conexão do banco de dados e pela largura de banda, apenas para enviar centenas, talvez milhares de kilobytes de markup do tema para um crawler que não queria.
"Apenas bloqueie-os" às vezes não funciona
O primeiro instinto de todo dev que percebe isso é recorrer a robots.txt, .htaccess ou regras de bot do Cloudflare, e bloquear tudo relacionado a bots de IA.
Problema resolvido, certo?
Não. Agora você também desapareceu das respostas que ChatGPT, Claude e Perplexity dão para pessoas buscando o que você vende. AI Overviews no Google? Desaparecidos. Citações em mecanismos de resposta? Desaparecidas.
Para a maioria dos sites que dependem de descoberta orgânica, esse é um resultado pior que a conta de hospedagem. Agora que o Google está matando o mecanismo de busca padrão, apenas bloquear bots de IA é o mesmo que matar seu site para visitantes orgânicos.
AEO - Answer Engine Optimization - é a nova linha de frente da busca. As empresas que estão ganhando nisso agora são aquelas cujo conteúdo realmente é ingerido pelos principais LLMs.
Além disso, se o time de marketing está trabalhando em AEO, você pode matar semanas ou meses de trabalho estratégico com uma única configuração. Tem que haver uma resposta melhor.
Deixe os bots entrarem. Sirva-os apenas o prato principal
Isso é o que ParseLess faz. Construí depois da ligação com aquele cliente e lancei no diretório WordPress algumas semanas depois para uso público.
A ideia é tão simples a ponto de ser quase constrangedora: quando um bot de IA atinge seu site WordPress, o plugin o detecta pelo User-Agent e serve o conteúdo como Markdown limpo em vez de HTML completo do tema. Mesmo conteúdo. Mesma URL. Visitantes humanos e Googlebot recebem o site normal. Nem sequer sabem que o plugin existe. Apenas os crawlers de IA recebem a versão leve. Para o bot de IA, isso é ouro.
Os números vêm de medir a mesma página do WordPress de duas maneiras. Primeiro como um navegador a vê: o documento HTML mais cada arquivo CSS, bundle JavaScript e imagem que o navegador precisa buscar para renderizar a página. Depois, como um bot a veria através do ParseLess: uma única resposta Markdown.
| Métrica | Página HTML completa | Resposta Markdown | Diferença | |---|---|---|---| | TTFB | 459 ms | 155 ms | ~3x mais rápido | | Requisições HTTP | 16 (1 doc + 15 assets) | 1 | 94% menos | | Peso total | ~484 KB (doc + CSS + JS + imagens) | ~6 KB | ~80x menor | | Consultas ao banco de dados | bootstrap completo | leitura de cache | 60–80% menos |
A primeira linha é aquela em que a maioria das pessoas se concentra, mas é a terceira linha que faz o dano real ao orçamento. Quando um crawler de IA atinge uma página HTML normal, ele não apenas baixa o HTML. O crawler puxa as folhas de estilo, os bundles JavaScript e cada vez mais as imagens também.
ParseLess reduz isso para uma requisição. Nenhuma busca de assets subsequente. Imagens se tornam links Markdown simples que o bot pode escolher buscar ou ignorar, em vez de serem baixadas automaticamente com a página.
Multiplique pelo tráfego de bot que você realmente está recebendo em um mês, e a matemática de largura de banda para de ser uma curiosidade.
Como fica na prática
Digamos que você tenha um site WordPress com 500 posts e/ou produtos. Digamos que os principais crawlers de IA (GPTBot, ClaudeBot, PerplexityBot, Bytespider, Google-Extended, etc.) atinjam a maioria dessas páginas ao longo de um mês. Considere números conservadores.
Antes do ParseLess: aproximadamente 500 páginas × 10 bots × ~484 KB = cerca de 2,4 GB de largura de banda, e 5.000 renders completos do WordPress com todas as suas requisições de assets em cascata.
Depois do ParseLess, com o cache aquecido: ~6 KB por resposta em média, leituras de transientes únicos em vez de bootstraps completos. Cerca de 30 MB de largura de banda total para o mesmo conjunto de crawls. Workers PHP-FPM liberados cerca de 3x mais rápido por requisição, o que significa que o mesmo servidor lida com mais tráfego de crawler concorrente antes de saturar.
É o mesmo conteúdo sendo entregue através de um tubo muito mais curto, e sem fazer a conta de hospedagem disparar.
O cliente cujo alerta de hospedagem desencadeou tudo isso economizou seu upgrade de servidor. Ele não perdeu AEO. Continuou sendo rastreado por cada modelo que importava. E os crawlers pararam de custar a ele dinheiro real.
Como funciona
ParseLess se conecta a template_redirect e executa a requisição através de uma verificação de User-Agent antes mesmo do WordPress decidir qual template carregar. Se o bot corresponder a um crawler de IA conhecido, a requisição é roteada para o conversor Markdown em vez do tema.
O conversor executa o filtro the_content, então tudo que Elementor, Divi, ACF ou blocos Gutenberg renderizam no conteúdo do post é capturado corretamente. Depois remove o markup de envolvimento e converte o que sobra para Markdown. Tabelas, listas aninhadas, blocos de código com linguagem preservada, imagens com texto alternativo, links, tudo é preservado. A saída é armazenada em um transiente com um TTL configurável.
Hits de bot subsequentes no mesmo post não executam a conversão. Recebem uma única leitura de cache e uma resposta em milissegundos.
O plugin respeita tudo que você esperaria que respeitasse. Posts marcados noindex em Yoast, Rank Math ou Genesis são excluídos. Posts privados, rascunhos, protegidos por senha e lixeira nunca são servidos. Todos os tipos de post públicos são incluídos por padrão, mas você pode restringi-los nas configurações.
Também há um endpoint /llms.txt na raiz do seu site. Opcional, desativado por padrão se você não quiser.
Desde a versão 0.5.0, ParseLess também publica um /botfood-sitemap.xml, um sitemap específico para IA listando a URL Markdown de cada post público. É anunciado em robots.txt automaticamente para que crawlers realmente o encontrem, e pode ser desativado se você preferir não expô-lo.
Sabendo que está realmente funcionando
A primeira pergunta que qualquer pessoa sensata faz depois de instalar um plugin como esse é: como sei que os bots estão realmente atingindo a versão Markdown e não ainda puxando HTML completo?
Então adicionei uma aba Analytics à página de configurações. O logging opcional registra cada requisição Markdown com o User-Agent do bot, URL do post, timestamp, bytes servidos e se a resposta veio do cache. O IP é armazenado como um hash SHA-256 com sal, nunca como o endereço bruto. Isso mantém os dados úteis para "com que frequência este bot me atingiu" sem arrastar o site para território GDPR ou LGPD evitável.
A aba Analytics oferece um gráfico de 30 dias de atividade de bot, uma análise por crawler, os principais URLs sendo buscados e uma lista de User-Agents desconhecidos que parecem bots mas não estão na lista de detecção. Se algo nessa lista "desconhecida" é claramente um crawler de IA — acontece regularmente, o espaço se move rápido — há um botão de um clique para adicioná-lo à lista de detecção.
Um widget de dashboard em wp-admin mostra os mesmos dados em forma resumida, para que você veja no momento em que faz login.
Se você não quer nada disso, deixe o logging desativado. O Markdown serving funciona bem sem ele. Mas se você está tentando justificar a instalação para um cliente, ou quer saber se o novo crawler que acabou de aparecer nos seus logs de acesso é realmente um bot LLM ou outra coisa, os dados estão lá.
Onde você verá os benefícios
Uma lista curta de quem realmente se beneficia disso:
Sites de e-commerce rodando WooCommerce, especialmente com muitas páginas de produtos. Bots de IA adoram rastrear catálogos de produtos, e páginas de produtos tendem a ser HTML-pesadas.
Sites de notícias e blogs de alto volume onde o conteúdo se atualiza mais rápido que o rastreamento consegue acompanhar, e os bots voltam frequentemente.
Sites construídos em construtores de página. Sites Elementor e Divi são os casos de uso de maior impacto porque suas cargas HTML são as mais pesadas no ecossistema WordPress.
Qualquer pessoa em hospedagem compartilhada ou VPS apertado que começou a receber avisos de recursos sem poder explicar o pico de tráfego.
Se você está em infraestrutura dedicada com margem, as economias ainda serão reais, mas você as sentirá mais na sua conta CDN do que na conta do servidor.
Qual é o custo
Nada. ParseLess é GPL, gratuito e está no diretório oficial do WordPress. Instale, ative, e bots de IA imediatamente começam a receber a versão leve. Nenhuma configuração necessária para que o comportamento padrão funcione.
As configurações ficam em Tools → ParseLess se quiser ajustar a lista de bots, o TTL do cache, os tipos de post ou as opções de frontmatter.
Adoraria ouvir de qualquer um que instale e meça seus próprios números — especialmente se as economias forem diferentes do que estou vendo. Configurações de servidor variam, e quanto mais dados eu tiver sobre o impacto no mundo real, melhor a próxima versão fica.
Se seu site é aquele sendo sinalizado pela hospedagem por uso de recursos e você não sabe por quê, os logs são geralmente a forma mais rápida de descobrir. Também ajudo com isso, mas na maioria das vezes a resposta está no log de acesso e você pode encontrá-la sozinho em vinte minutos.
De qualquer forma, pare de pagar para renderizar seu tema para robôs.