Como auditar SEO técnico e performance em arquiteturas legadas WordPress

Leitura executiva

Principais conclusões

• O gargalo oculto de TTFB no WordPress geralmente está no banco de dados. Consultas Autoload na tabela `wp_options` forçam o servidor a carregar MBs de dados inúteis a cada carregamento de página.
• Plugins de SEO nativos criam Sitemaps que, por padrão, incluem taxonomias inúteis (Tags, Arquivos de Autor, Arquivos de Data), desperdiçando o orçamento de rastreamento (Crawl Budget).
• Instalar 'Plugins de Performance' sobre código ruim é tapar o sol com a peneira. O verdadeiro diagnóstico de LCP e INP exige limpar requisições síncronas de CSS e JS injetados globalmente por plugins de uso isolado.
• O WooCommerce cria nativamente parâmetros de ordenação e paginação nas URLs (ex: `?orderby=price`) que, se não contidos no `robots.txt` e Canonical Tags, duplicam o conteúdo massivamente.

Quando o tráfego cresce, mas as oportunidades não aparecem, a Diretoria exige respostas. Em ecossistemas baseados em WordPress e WooCommerce, a resposta raramente é um problema de design. Quase sempre, a resposta é um colapso infraestrutural silencioso.

O WordPress é um monólito. Sua flexibilidade vem do fato de que tudo é dinâmico (PHP conectado ao MySQL). No entanto, quando um portal de conteúdo ou e-commerce escala para centenas de milhares de sessões, essa dinamicidade torna-se um passivo.

Para auditar um site de forma orientada a evidências, devemos abandonar a prática amadora de apenas jogar a URL no Google PageSpeed Insights. É preciso ir à raiz: o banco de dados, o roteamento e os gargalos de recursos.

Este é o protocolo cirúrgico para auditar grandes instalações WordPress.

---

1. O Assassino Silencioso do TTFB: A Tabela wp_options

O diagnóstico de TTFB (Time to First Byte) mede quanto tempo o seu servidor PHP leva para processar o código e cuspir o primeiro pedaço de HTML.

No WordPress, o maior inimigo do TTFB é a tabela wp_options. Por padrão, muitos plugins e o próprio núcleo salvam configurações com uma flag chamada autoload=yes. Isso significa que, toda vez que um usuário carrega qualquer página do site, o WordPress carrega todas essas opções na memória do servidor.

Se você tem um plugin de marketing que salva dados temporários pesados no wp_options com o autoload ativado (ou plugins antigos que foram deletados, mas deixaram seus dados lá), o seu servidor pode estar carregando 5 Megabytes de lixo invisível a cada requisição.

Ação de Engenharia

• Use o acesso via SSH/MySQL para executar uma query pesando o Autoload:

  SELECT SUM(LENGTH(option_value)) as autoload_size FROM wp_options WHERE autoload = 'yes';
  

• O ideal é manter esse valor abaixo de 800 KB. Se estiver em vários Megabytes, identifique as linhas ofensoras, revise a necessidade do plugin ou mude a flag para no.

---

2. A Epidemia de Plugin Bloat e o Desastre do INP

O ecossistema confia excessivamente em plugins. Um site B2B médio hoje tem entre 30 e 50 plugins instalados.

O problema arquitetural: a grande maioria dos desenvolvedores de plugins do WordPress injeta o CSS e o JavaScript do seu plugin em todas as páginas do site, mesmo que a funcionalidade só seja usada na página de Contato.

Isso cria um acúmulo de arquivos estáticos bloqueantes. Quando o navegador do cliente tenta montar a interface visual humana, ele congela. É a principal causa de reprovação no Core Web Vitals, especificamente na métrica INP.

Auditoria de Bloat

• Inspecione a aba Network e conte quantas requisições JS e CSS estão ocorrendo.
• Utilize ganchos (hooks) nativos como wp_dequeue_script e wp_dequeue_style dentro do arquivo functions.php do seu tema para forçar o descarregamento de scripts de formulários ou sliders em páginas onde eles não existem.

---

3. Buracos Negros no Crawl Budget (Taxonomias Nativas)

O WordPress não foi feito para e-commerce (WooCommerce é uma adaptação) e nem para diretórios complexos. Ele foi feito para Blogs de 2005.

Isso significa que o núcleo nativo gera URLs dinâmicas compulsivamente:

• /author/admin/ (Arquivos de Autor)
• /2026/07/ (Arquivos de Data)
• /tag/seo/ (Páginas de Tag)

Para o Googlebot, essas páginas muitas vezes listam o mesmo conteúdo que a página principal da categoria, criando um abismo de conteúdo duplicado e desperdiçando o orçamento de rastreamento (Crawl Budget). Se você tem 100 posts, mas 50 tags, o Google está lendo o dobro de URLs sem necessidade.

Se o seu modelo for de e-commerce, as paginações e filtros do WooCommerce (ex: ?min_price=10&max_price=50) multiplicam as URLs ao infinito.

Selando o Vazamento (Revenue Leak)

1. Audite os Sitemaps: Seu sitemap não deve ter URLs de autores, datas ou tags que não correspondam à estratégia principal. Desligue isso no seu plugin de SEO (Yoast, RankMath) imediatamente.
2. Robots.txt Focado: Bloqueie o rastreamento de parâmetros de filtro do WooCommerce (ex: Disallow: /*?orderby=* e Disallow: /*?filter_*).
3. Canonicalização Férrea: Todo conteúdo listado via parâmetros deve apontar sua Canonical Tag para a coleção principal limpa.

---

Conclusão: Engenharia sobre Plugins

Oditório de performance e SEO em WordPress deve parar de focar em "qual o melhor plugin de cache" e começar a investigar como transformar problemas técnicos de banco de dados em impacto financeiro.

Um Redis Object Cache bem configurado e um banco de dados limpo recuperam mais velocidade do que qualquer otimizador de imagens frontal. Estimar a receita em risco forçará o seu time de tecnologia a entender que em arquiteturas legadas como o WordPress, menos código em execução no servidor significa mais dinheiro fluindo pelo checkout.

Respostas diretas

Perguntas frequentes

Por que meu site WordPress é lento no mobile, mesmo com pontuação alta no Lighthouse no desktop?

A pontuação no Desktop disfarça a quantidade de JavaScript que a CPU precisa processar. No celular (dispositivo com CPU mais fraca), o acúmulo de scripts do tema e de plugins de marketing resulta em um INP (Interaction to Next Paint) terrível. A solução é auditar e desenfileirar (dequeue) scripts bloqueantes.

Como descubro se o banco de dados do meu WordPress está destruindo meu TTFB?

Instale ferramentas como Query Monitor para identificar requisições lentas. Especificamente, verifique o tamanho da sua tabela `wp_options` no PHPMyAdmin. Se o tamanho total das linhas com `autoload=yes` ultrapassar 1 MB, seu TTFB já está severamente comprometido.

Posso resolver a performance do WooCommerce apenas trocando para uma hospedagem mais cara?

Mais RAM e CPU mascaram o problema temporariamente, mas não o resolvem. Um código PHP ruim escalará mal independente da máquina. Você deve corrigir as consultas SQL ineficientes e implementar Redis/Memcached no nível de objetos, não apenas aumentar o servidor.