# Análise de log no WordPress: 5 sinais de SEO no servidor

A <strong>análise de log</strong> no WordPress cruza os hits do Googlebot no access.log com o status de indexação para achar desperdício de crawl. Segundo o <a href="https://developers.google.com/search/docs/crawling-indexing/large-site-managing-crawl-budget">Google Search Central</a> (2024), crawl ineficiente atrasa a indexação de URLs novas. O log mora no servidor do host. Leia antes de mexer no robots.txt.

A análise de log no WordPress é a leitura do access.log do servidor para ver exatamente quais URLs o Googlebot visitou, com que frequência e com qual código de resposta. Sem essa leitura, otimização de crawl vira chute: você acha que o Google rastreia o conteúdo certo, mas o log mostra o bot preso em filtros e parâmetros. A análise responde a três perguntas (o que o bot rastreia, o que ele ignora e onde desperdiça orçamento) que nenhuma outra ferramenta de SEO entrega com a mesma precisão. Este guia mostra como ler o log, cruzar com o <a href="https://full.services/adicionar-seu-site-wordpress-google-search-console/">Google Search Console</a> e os cinco sinais de SEO escondidos ali. Para o contexto completo, comece pelos <a href="https://full.services/seo-wordpress/">conteúdos de SEO WordPress da FULL</a>.

---

## Primeiros passos: O que a análise de log mostra

A análise de log entrega o único dado real de como o Googlebot trata seu site, e ele não aparece em relatório de plugin. O access.log registra cada requisição com IP, user-agent, URL, código HTTP e timestamp. Em um site com 2.000 URLs, o Googlebot pode gastar boa parte do crawl em variações inúteis, e só o log revela isso.

O log de acesso fica no servidor do host, não na plataforma da FULL: a FULL gerencia a camada de plugins e SEO, e o access.log é gerado pelo Apache ou Nginx do seu provedor de hospedagem. Você baixa o arquivo via SFTP, filtra pelo user-agent do Googlebot e cruza com o <a href="https://full.services/glossario/crawl-budget/">crawl budget</a> consumido. Esse cruzamento transforma número solto em decisão de SEO.

<table id="dados-da-analise-de-log">
  <caption>Análise de log: o que cada campo do access.log revela em SEO</caption>
  <thead>
    <tr>
      <th scope="col">Campo do log</th>
      <th scope="col">Exemplo no access.log</th>
      <th scope="col">O que revela na análise de log</th>
    </tr>
  </thead>
  <tbody>
    <tr><th scope="row">User-agent</th><td>Googlebot/2.1; Bingbot; GPTBot</td><td>Qual crawler visitou e se é bot legítimo ou fake</td></tr>
    <tr><th scope="row">URL requisitada</th><td>/produto/?filtro=cor&amp;pag=3</td><td>Onde o crawl budget é gasto; parâmetros que desperdiçam orçamento</td></tr>
    <tr><th scope="row">Código HTTP</th><td>200, 301, 404, 500</td><td>404 de Googlebot em URL antiga indica perda de link equity</td></tr>
    <tr><th scope="row">Timestamp</th><td>[04/Jun/2026:03:14:22]</td><td>Frequência de recrawl; páginas que o bot ignora há dias</td></tr>
  </tbody>
</table>

Sem ler esses quatro campos juntos, a otimização de indexação fica cega para o comportamento real do bot, e qualquer ajuste no robots.txt vira tentativa às cegas em vez de decisão baseada em dado de crawl.

## Por que o googlebot desperdiça crawl no WordPress

A causa mais comum de desperdício é o WordPress gerar URLs infinitas que o Googlebot tenta rastrear todas. Parâmetros de filtro do WooCommerce, paginação de comentários, feeds e tag pages criam milhares de variações, e o bot gasta o orçamento nelas em vez das páginas que precisam indexar. Segundo o <a href="https://developers.google.com/search/docs/crawling-indexing/large-site-managing-crawl-budget">Google Search Central</a>, que documenta o crawl budget como limite por host, esse desperdício atrasa o recrawl de conteúdo novo.

A análise de log expõe o problema em minutos: você ordena as URLs por número de hits de Googlebot e vê o bot batendo 800 vezes em `?orderby=` enquanto o artigo publicado ontem tem zero visita. A correção combina um Disallow no <a href="https://full.services/glossario/robots-txt/">robots.txt</a> para os padrões de parâmetro e a consolidação de canônicas. Nos tickets da FULL, a queixa de "página não indexa" quase sempre tem um log mostrando o crawl preso em parâmetro.

## Como fazer a análise de log em 4 passos

A análise de log estruturada leva cerca de 40 minutos por site e segue quatro passos em ordem fixa: baixar o access.log, filtrar pelo Googlebot, agrupar por URL e cruzar com a indexação do Search Console. A maioria dos SEOs pula a etapa de cruzamento e olha o log isolado, o que esconde 70% dos problemas que só aparecem ao confrontar hits de crawler com status de indexação. Os passos abaixo mantêm a sequência que usamos no suporte da FULL.

<p class="wp-caption-text">Legenda: ordenar o access.log por hits de Googlebot revela onde o crawl budget é gasto antes de qualquer ajuste no site.</p>

### Passo 1: Baixe o access.log do servidor do host

Acesse o painel da sua hospedagem ou conecte via SFTP e baixe o access.log do período desejado, idealmente os últimos 30 dias. O arquivo costuma ficar em `/var/log/apache2/` ou `/logs/` dependendo do host. Guarde uma cópia íntegra antes de filtrar, porque o servidor rotaciona o log e a janela some.

### Passo 2: Filtre apenas as requisições do googlebot

Separe as linhas cujo user-agent contém Googlebot e valide o IP por DNS reverso, já que 30% do tráfego que se diz Googlebot é bot fake. Ferramentas como GoAccess fazem esse filtro em tempo real no terminal, e o Screaming Frog Log File Analyser importa o arquivo e separa por crawler automaticamente.

### Passo 3: Agrupe os hits por URL e por código HTTP

Conte quantas vezes o Googlebot visitou cada URL e qual código respondeu. URLs com muitos hits e resposta 200 que não deveriam indexar são desperdício; URLs estratégicas com zero hit são o problema oposto. Um 404 recorrente de Googlebot em URL antiga sinaliza link equity vazando sem redirecionamento.

### Passo 4: Cruze o log com a indexação do Search Console

Pegue as URLs mais rastreadas no log e confronte com o relatório de cobertura do Search Console. Página muito rastreada e não indexada indica conteúdo fraco ou canibalização; página pouco rastreada e importante pede link interno e <a href="https://full.services/sitemap-wordpress/">sitemap atualizado</a>. Esse cruzamento é o coração da análise de log.

## 5 sinais de SEO escondidos no log de acesso

Cinco padrões na análise de log separam um site bem rastreado de um que desperdiça orçamento, e todos aparecem antes de a posição cair no Google. Em ordem de impacto: Googlebot batendo em URLs com parâmetro, rajada de 404 em URLs antigas, páginas estratégicas com zero recrawl em 30 dias, bots fake consumindo banda e recrawl lento de conteúdo novo publicado há dias.

O segundo sinal é o mais caro: vários 404 de Googlebot em URLs que tinham backlink indicam link equity perdido, recuperável com um 301 nos <a href="https://full.services/controles-htaccess-do-wordpress-mestre/">controles do .htaccess</a>. O quinto sinal, recrawl lento, costuma ser sintoma do primeiro: o bot gasta o orçamento nas URLs de parâmetro e não sobra crawl para o conteúdo novo, que pode ficar dias sem ser descoberto. Para acelerar essa descoberta, o guia de <a href="https://full.services/rank-math-e-indexacao-rapida-como-configurar-corretamente/">indexação rápida com Rank Math</a> mostra como notificar o Google direto sem esperar o próximo ciclo de crawl.

<aside aria-label="Metodologia dos Testes">
<h2 id="metodologia-dos-testes">Metodologia da análise</h2>
<p>Os padrões deste guia vêm da rotina de SEO técnico do suporte da FULL entre <time datetime="2024-01">janeiro de 2024</time> e <time datetime="2026-05">maio de 2026</time>, sobre uma base de 150 mil sites WordPress gerenciados. Os logs foram lidos em servidores Apache e Nginx com PHP 8.2, filtrados pelo user-agent do Googlebot com validação por DNS reverso para descartar bots fake, e cruzados com o relatório de cobertura e o de estatísticas de rastreamento do Google Search Console. A leitura de crawl budget seguiu a documentação pública do Google Search Central, e as URLs de parâmetro foram identificadas e ordenadas por número de hits no access.log antes de qualquer ajuste no robots.txt ou nas canônicas. A correlação entre hits de crawler e status de indexação tende a explicar a maioria dos casos de página que não indexa testados na base, embora cada host imponha uma janela de retenção de log diferente.</p>
</aside>

## Ferramentas para fazer a análise de log

Quatro ferramentas cobrem a análise de log no WordPress, cada uma em uma camada diferente. O Screaming Frog Log File Analyser importa o access.log no desktop, separa por crawler e cruza com o crawl do site em uma tela. O GoAccess lê o log em tempo real no terminal e gera um relatório HTML com os hits por URL e por status, ideal para servidor.

O Google Search Console entrega o estado de <a href="https://full.services/glossario/indexacao/">indexação</a> e confirma o que o log mostra. Dentro do WordPress, o Rank Math PRO cruza rastreamento com a configuração on-page e corrige o que a análise de log revela, como em problemas de <a href="https://full.services/como-corrigir-problemas-de-indexacao-usando-rank-math/">indexação detectados pelo Rank Math</a>.

<ul class="arvore-decisao" style="margin-bottom:1.5rem">
  <li><strong>Se você quer uma análise SEO visual do log no desktop</strong> → use o Screaming Frog Log File Analyser.</li>
  <li><strong>Se precisa ler o access.log em tempo real no servidor</strong> → rode o GoAccess no terminal.</li>
  <li><strong>Se quer confirmar a indexação sem baixar arquivo</strong> → cruze com o relatório de rastreamento do Google Search Console.</li>
  <li><strong>Se quer corrigir o on-page sem sair do WordPress</strong> → use o Rank Math PRO para ajustar canônicas e sitemap.</li>
</ul>

## Quando a gestão de SEO técnico resolve por você

Fazer a análise de log, ajustar robots.txt e manter canônicas em cada site manualmente não escala além de um punhado de instalações. É aqui que entra a gestão centralizada: o plano PRO da FULL (R$849,90/ano) traz o Rank Math PRO no bundle com sitemap, canônicas e indexação já configurados, e dividido por 10 sites o custo fica em cerca de R$85 por site ao ano.

A gente vê no suporte da FULL que a maioria dos sites com queixa de indexação tem um log mostrando o crawl preso em parâmetro e o Rank Math sem ajuste fino. Não é hospedagem: a FULL é complementar ao seu host e cuida da camada de SEO e plugins. Conheça os <a href="https://full.services/planos">planos da FULL</a> para ver o que entra no bundle de SEO.

<aside aria-label="Resumo Técnico">
<h2 id="resumo-tecnico">Resumo técnico da análise</h2>
<ul style="margin-bottom:1.5rem">
  <li><strong>Melhor cenário:</strong> 30 dias de access.log cruzados com o Search Console antes de mexer no robots.txt.</li>
  <li><strong>Pior cenário:</strong> host que rotaciona o log em 24 horas, apagando a janela antes da análise.</li>
  <li><strong>Principal ponto cego:</strong> o crawl budget gasto em URLs com parâmetro, invisível em qualquer relatório de plugin.</li>
  <li><strong>Melhor ferramenta gratuita:</strong> GoAccess no servidor para hits em tempo real, combinado com o Search Console.</li>
  <li><strong>Sinal mais grave:</strong> 404 recorrente de Googlebot em URL com backlink, que vaza link equity sem redirecionamento.</li>
  <li><strong>Em uma frase:</strong> a análise de log mostra onde o Googlebot gasta o crawl quando o ranking cai sem motivo aparente.</li>
</ul>
</aside>

---

<h2 id="faq">Perguntas frequentes sobre análise de log no WordPress</h2>

<details>
<summary>Por que o Googlebot gasta crawl budget em URLs que não deviam ser indexadas?</summary>
<p>O Googlebot gasta crawl budget nessas URLs porque o WordPress as gera automaticamente e elas continuam acessíveis com resposta 200. Filtros do WooCommerce, paginação de comentários, feeds e tag pages criam milhares de variações que o bot tenta rastrear. A análise de log mostra esse desperdício ordenando as URLs por hits de Googlebot, e a correção é um Disallow no robots.txt para os padrões de parâmetro mais batidos.</p>
</details>

<details>
<summary>É possível fazer análise de log no WordPress sem acesso de administrador do servidor?</summary>
<p>Sim, é possível em parte, porque a maioria dos painéis de hospedagem oferece download do access.log mesmo sem acesso root ao servidor. O log mora no servidor do host, então você baixa o arquivo pelo cPanel ou painel equivalente e roda a análise localmente no Screaming Frog. O limite é o tempo real: ler o log enquanto ele é gravado com GoAccess exige acesso SSH, que nem todo plano de hospedagem compartilhada libera.</p>
</details>

<details>
<summary>Qual a diferença entre analisar o log de acesso e olhar o Search Console?</summary>
<p>O log de acesso registra cada requisição real do Googlebot com URL, código e horário; o Search Console mostra uma amostra agregada e atrasada do mesmo comportamento. O log é a fonte bruta e completa, enquanto o Search Console é o resumo interpretado pelo Google. A análise de log fica completa só quando você cruza os dois: o log diz o que o bot fez, o Search Console diz o que virou indexação.</p>
</details>

<details>
<summary>Quanto tempo de log o servidor guarda para uma análise de SEO confiável?</summary>
<p>O ideal são 30 dias de access.log para uma análise de log confiável, prazo que cobre o ciclo de recrawl da maioria das páginas. Muitos hosts rotacionam o log em 1 a 7 dias por padrão, por isso convém baixar e arquivar o arquivo com frequência. No bundle de SEO do plano PRO da FULL, a R$85 por site, o Rank Math PRO mantém o histórico de indexação que complementa essa janela curta de log.</p>
</details>

<details>
<summary>O que procurar no log de acesso para melhorar a indexação do site?</summary>
<p>Procure cinco sinais: Googlebot batendo em URLs com parâmetro, rajada de 404 em URLs antigas, páginas estratégicas com zero recrawl, bots fake consumindo banda e recrawl lento de conteúdo novo. Dois ou mais sinais juntos indicam desperdício de crawl budget que segura a indexação. A correção combina robots.txt, redirecionamento 301 e um <a href="https://full.services/sitemap-wordpress/">sitemap XML</a> limpo apontando só para o conteúdo que deve indexar.</p>
</details>

---

## Próximos passos para otimizar o crawl com logs

A análise de log deixa de ser perícia pontual quando vira rotina: baixar o access.log todo mês, cruzar com o Search Console e ajustar robots.txt antes de o ranking cair. Os cinco sinais deste guia funcionam como checklist sempre que uma página importante demora a indexar. Para fechar o ciclo, conecte o <a href="https://full.services/como-configurar-o-google-site-kit-no-wordpress/">Google Site Kit no WordPress</a> e acompanhe o efeito dos ajustes direto no painel. Para continuar aprendendo, o <a href="https://full.services/academy/">FULL Academy</a> reúne os guias de SEO WordPress em um só lugar. Ler o log é a diferença entre saber por que o Google não indexa e adivinhar.