Lighthouse SEO: cada aviso do PageSpeed Insights, o que significa e como corrigir

Como a categoria SEO funciona

O Lighthouse abre uma única URL num Chrome simulado e roda uma lista fixa de checagens. Na categoria SEO, elas aparecem em dois grupos: Rastreamento e indexação e Práticas recomendadas para conteúdo. O resto fica em Auditorias aprovadas, Não aplicável e Outros itens para verificação manual.

As mensagens deste artigo saem do arquivo de tradução pro português do Brasil do próprio Lighthouse (versão 13.5.0, de 17/09/2026). É de lá que o relatório em português tira os textos. Junto vai o título em inglês, que é o da documentação.

Três jeitos de rodar:

1. PageSpeed Insights: abra pagespeed.web.dev, cole a URL e desça até o círculo SEO.
2. Chrome DevTools: F12, aba Lighthouse, marque só SEO e clique em Analyze page load.
3. Linha de comando, com o Chrome instalado na máquina:

npx lighthouse https://seusite.com.br/ --only-categories=seo --locale=pt-BR --view

Quanto cada aviso pesa

No código do Lighthouse, a auditoria de indexação tem peso de cerca de 4, calculado pra ela valer pelo menos 31% da nota, e as outras nove valem 1 cada. A manual vale zero. Auditoria marcada como Não aplicável sai da conta. Na prática: uma página indexável que falha num único aviso comum fica com 92; uma página com noindex fica com uns 69 mesmo que todo o resto esteja certo.

As auditorias que saíram

Muito tutorial ainda fala de avisos que não existem mais na categoria. Pelo changelog oficial do Lighthouse:

• Lighthouse 12.0 (abril de 2024) reorganizou a categoria "pra refletir as prioridades da busca do Google em 2024". Saíram plugins ("O documento usa plug-ins") e tap-targets ("As áreas de toque não estão dimensionadas corretamente"), este substituído pela auditoria target-size em Acessibilidade. viewport e font-size foram pra Boas práticas.
• Lighthouse 13.0 (outubro de 2025) removeu de vez a auditoria font-size ("O documento não usa tamanhos de fonte legíveis").

A página-índice de SEO na documentação do Chrome ainda lista plugins e tap-targets. Ela está desatualizada: a configuração atual do Lighthouse não tem nenhuma das duas.

1. A página está bloqueada para indexação

Mensagem: "A página está bloqueada para indexação" (em inglês, Page is blocked from indexing). Quando passa: "A página não está bloqueada para indexação".

O que confere: três fontes de bloqueio. A meta tag robots com noindex ou none, o cabeçalho X-Robots-Tag com os mesmos valores e uma regra do robots.txt que bloqueie a URL. Uma data vencida em unavailable_after também conta.

O detalhe que confunde: o aviso só falha quando todos os robôs que ele testa estão bloqueados (as regras gerais, o Googlebot, o bingbot, o DuckDuckBot e o robô do archive.org). Um <meta name="googlebot" content="noindex"> sozinho não reprova; aparece só um alerta, em inglês, dizendo quais robôs estão bloqueados.

Por que importa: é o único aviso que tira a página do Google por inteiro. Corrija antes de qualquer outro.

Como corrigir: primeiro, confirme que a página deve mesmo aparecer na busca. Login e carrinho costumam ter noindex de propósito. Se for por engano, procure nos três lugares:

curl -sI https://seusite.com.br/pagina | grep -i x-robots-tag
curl -s https://seusite.com.br/pagina | grep -io '<meta[^>]*robots[^>]*>'
curl -s https://seusite.com.br/robots.txt

Tire o noindex da meta tag, a configuração do servidor que manda o X-Robots-Tag e o Disallow que cobre a URL. No WordPress, a causa clássica é a opção "Evitar que mecanismos de busca indexem este site", que fica em Configurações › Leitura. Os outros casos comuns estão em noindex sem querer.

Como conferir: rode o Lighthouse de novo ou use o verificador de noindex, que olha a meta tag e o cabeçalho de uma vez.

2. Código de status HTTP com falha

Mensagem: "A página tem uma falha no código de status HTTP" (Page has unsuccessful HTTP status code). O número aparece ao lado do título.

O que confere: se o documento principal respondeu com um código entre 400 e 599. Redirect (3xx) não reprova; o Lighthouse segue o redirect e avalia a página onde chegou.

Por que importa: página que responde 404 ou 500 não entra no índice. Se a URL testada é uma página de erro, o aviso está certo.

Como corrigir: veja o código que o servidor devolve:

curl -s -o /dev/null -w "%{http_code}\n" https://seusite.com.br/pagina

Um 404 numa página que existe costuma ser rota que o servidor não conhece, comum em site de página única hospedado como arquivos estáticos. Um 403 ou 429 pode ser o firewall barrando o teste.

Como conferir: o curl acima tem que devolver 200. Se a URL antiga mudou de lugar, ela deve dar 301 pra nova, como em redirect 301 ou 302.

3. robots.txt não é válido

Mensagem: "robots.txt não é válido" (robots.txt is not valid). Ao lado, "1 erro encontrado" ou "A solicitação para robots.txt retornou o status HTTP: 500", por exemplo.

O que confere: o arquivo da raiz do domínio, linha por linha. As mensagens de erro da tabela ficam em inglês:

Se o arquivo responde 5xx ou 429, o aviso falha. Se responde 404 (o site não tem robots.txt), a auditoria vira Não aplicável e não pesa na nota.

Por que importa: a documentação do Lighthouse avisa que, com 5xx no robots.txt, os buscadores podem parar de rastrear o site inteiro. Erro de sintaxe pode fazer uma regra ser ignorada.

Como corrigir: um arquivo mínimo e válido:

User-agent: *
Disallow: /admin/
Disallow: /*.pdf$

Sitemap: https://seusite.com.br/sitemap.xml

Mantenha o arquivo abaixo de 500 KiB, usando padrões em vez de listar URL por URL. O gerador de robots.txt monta um sem erro.

Como conferir: curl -sI https://seusite.com.br/robots.txt tem que mostrar 200 e, no corpo, o texto do arquivo, não uma página HTML. No Search Console, Configurações › robots.txt mostra a versão que o Google buscou e os problemas que ele achou. Regras que bloqueiam demais estão em robots.txt bloqueando o Google.

4. Os links não são rastreáveis

Mensagem: "Os links não são rastreáveis" (Links are not crawlable). A tabela lista cada elemento na coluna "Link não rastreável".

O que confere: os elementos <a> da página. Reprova:

• href="javascript:void(0)" e variações como javascript:void 0 (outros javascript:, como javascript:abrir(), não reprovam aqui);
• <a> sem href mas com target, rel, download ou outro atributo que só existe junto com href;
• links file:;
• href que não forma uma URL válida;
• <a> sem href mas com evento de clique, o "link" que só funciona por JavaScript.

Não reprova: href="" e href="#", que viram o endereço da própria página, mailto:, <a> com atributo role ou name, <a id="secao"> usado como âncora e <a> sem href e sem clique, que o HTML trata como espaço reservado.

Por que importa: o Google diz que, em geral, só segue links que são um elemento <a> com href. Menu ou paginação feitos com onclick escondem páginas do robô, que passa a depender só do sitemap pra achar essas URLs.

Como corrigir: se leva pra outra página, é <a href> com o endereço real. Se só faz uma ação na tela, é <button>:

<!-- reprova -->
<a href="javascript:void(0)" onclick="abrir('/planos')">Planos</a>
<a onclick="router.push('/blog')">Blog</a>

<!-- passa -->
<a href="/planos">Planos</a>
<button type="button" onclick="abrirMenu()">Menu</button>

Os componentes Link do Next.js e do React Router já geram <a href>.

Como conferir: pra listar os links com javascript: ou href vazio de uma página (nem todos reprovam no Lighthouse, mas nenhum leva o robô a outra página):

curl -s https://seusite.com.br/ | grep -io '<a [^>]*href="\(javascript:[^"]*\|\)"'

5. O documento não tem um elemento title

Mensagem: "O documento não tem um elemento <title>" (Document doesn't have a <title> element). Essa auditoria é a mesma da categoria Acessibilidade e aparece nas duas.

O que confere: se existe um <title> com texto. Não confere tamanho, nem se o título se repete em outras páginas.

Por que importa: o título é a principal fonte do link azul no resultado. Sem ele, o Google monta um a partir do H1, do og:title ou de links que apontam pra página, e você perde o controle do que aparece.

Como corrigir: um título por página, descritivo e diferente dos outros:

<head>
  <title>Tênis de corrida masculino | Loja Exemplo</title>
</head>

Como conferir: curl -s https://seusite.com.br/ | grep -io '<title>[^<]*'. Por que o Google às vezes troca o título que você escreveu está em título e descrição errados no Google.

6. O documento não tem uma metadescrição

Mensagem: "O documento não tem uma metadescrição" (Document does not have a meta description). Se a tag existe mas está vazia, aparece também "O campo de texto da descrição está vazio."

O que confere: só se existe <meta name="description"> com algum texto. Não olha tamanho, qualidade nem repetição.

Por que importa (pouco, mas importa): o Google monta o trecho do resultado principalmente com o conteúdo da página e usa a metadescrição quando ela descreve melhor. Sem ela, você não tem nem a chance. Não existe limite de tamanho na tag; o trecho é cortado conforme a largura da tela.

Como corrigir:

<meta name="description" content="Tênis de corrida masculino com amortecimento, do 38 ao 45. Frete grátis acima de R$ 199 e troca em 30 dias.">

Uma por página. Em sites grandes, dá pra gerar a partir dos dados de cada página (preço, autor, data), desde que fique legível.

Como conferir: o verificador de title e meta description mostra os dois e o tamanho de cada um.

7. Os links não têm texto descritivo

Mensagem: "Os links não têm texto descritivo" (Links do not have descriptive text), com "1 link encontrado" ou "3 links encontrados" ao lado.

O que confere: se o texto do link é exatamente uma expressão genérica de uma lista fixa. Em português, a lista do Lighthouse tem só seis: "clique aqui", "ir", "mais", "mais informação", "mais informações" e "veja mais". Maiúsculas não importam. A lista usada é a do idioma do link, tirado do atributo lang mais próximo, normalmente o <html lang="pt-BR">. Se a página não tem lang, ele confere as listas de todos os idiomas, e "click here" ou "more" também reprovam.

O que fica de fora: links com rel="nofollow", javascript:, mailto:, âncoras pra mesma página e qualquer texto fora da lista. "Saiba mais" e "leia mais" não estão na lista em português e passam, embora sejam tão genéricos quanto "veja mais". Link sem texto nenhum também não é pego aqui.

Por que importa: o Google usa o texto âncora pra entender a página de destino e recomenda evitar textos como "Clique aqui". Num link de imagem, quem faz esse papel é o alt.

Como corrigir: diga pra onde o link leva:

<!-- reprova -->
Confira a tabela de medidas <a href="/medidas">clique aqui</a>.

<!-- passa -->
Antes de comprar, veja a <a href="/medidas">tabela de medidas dos tênis</a>.

Como conferir: a tabela do aviso mostra o destino e o texto de cada link.

8. Os elementos de imagem não têm atributos alt

Mensagem: "Os elementos de imagem não têm atributos [alt]" (Image elements do not have [alt] attributes). Também é uma auditoria de Acessibilidade reaproveitada.

O que confere: se cada <img> tem alt. Imagem decorativa com alt="" passa, porque o vazio diz de propósito que ela não informa nada.

Por que importa: o Google usa o texto alternativo, junto com visão computacional e o conteúdo da página, pra entender a imagem. Em imagem com link, o alt vira o texto âncora.

Como corrigir: descreva a imagem no contexto, sem lista de palavras-chave:

<img src="tenis-azul.jpg" alt="Tênis de corrida azul-marinho com sola branca, visto de lado">
<img src="divisor.svg" alt="">

Como conferir: a tabela lista cada imagem sem alt.

9. O documento não tem um hreflang válido

Mensagem: "O documento não tem um hreflang válido" (Document doesn't have a valid hreflang). Embaixo de cada link aparece o motivo: "Código de idioma inesperado" ou "Valor de href relativo".

O que confere: só os <link rel="alternate" hreflang> do <head> e do cabeçalho Link. Duas coisas: se o código de idioma existe e se o endereço é completo, começando com http:// ou https://. Página sem hreflang passa.

Não confere o código de região, se as versões apontam umas pras outras, se a página aponta pra ela mesma nem o hreflang do sitemap. O Google exige tudo isso: cada versão lista a si mesma e todas as outras, e se X aponta pra Y, Y precisa apontar de volta.

Como corrigir: o mesmo bloco em todas as versões, com URLs completas:

<link rel="alternate" hreflang="pt-BR" href="https://seusite.com.br/" />
<link rel="alternate" hreflang="pt-PT" href="https://seusite.pt/" />
<link rel="alternate" hreflang="en" href="https://seusite.com/" />
<link rel="alternate" hreflang="x-default" href="https://seusite.com/" />

Erros que o Google cita: só a região sem o idioma, UK no lugar de en-GB e be (que é bielorrusso) pra Bélgica.

Como conferir: abra cada versão e confira os links de volta.

10. O documento não tem um rel=canonical válido

Mensagem: "O documento não tem um rel=canonical válido" (Document does not have a valid rel=canonical). O motivo vem junto, e é aí que está a informação útil:

Página sem canonical não reprova: a auditoria vira Não aplicável.

Por que importa: pro Google, o canonical é um sinal forte de qual URL deve aparecer.

Como corrigir: um só, absoluto, no <head>, apontando pra própria página:

<link rel="canonical" href="https://seusite.com.br/tenis-de-corrida" />

Como conferir: o verificador de canonical mostra pra onde cada página aponta e se é o domínio certo.

11. Os dados estruturados são válidos (manual)

Mensagem: "Os dados estruturados são válidos" (Structured data is valid), em "Outros itens para verificação manual".

O que confere: nada. É um lembrete, com peso zero. O texto manda usar a "Ferramenta de teste de dados estruturados", que o Google não indica mais nas páginas atuais de dados estruturados.

Como fazer a checagem: o Google recomenda o Teste de pesquisa aprimorada pra ver se a marcação gera resultado com destaque, e o formato JSON-LD. Pra validar o Schema.org em geral, use o validador do Schema.org ou o verificador de dados estruturados. O passo a passo está em dados estruturados.

Nota 100 de SEO não quer dizer que a página rankeia

A própria descrição da categoria, no relatório, diz que há muitos outros fatores não avaliados pelo Lighthouse que podem afetar a classificação. A nota 100 diz uma coisa só: essa URL, nesse momento, não tem nenhum dos 10 problemas básicos da lista. Ela não mede conteúdo, links de outros sites nem se o Google já indexou a página.

E várias auditorias são frouxas: a metadescrição passa com uma palavra, o título passa repetido no site inteiro, o canonical passa se nem existir.

O que o Lighthouse não confere

• O sitemap. Nenhuma auditoria lê o sitemap.xml. URL quebrada, com noindex ou redirecionada dentro dele não aparece. Use o validador de sitemap e o guia de sitemap XML.
• Canonical pro domínio errado. A documentação do Chrome ainda diz que o aviso falha quando o canonical aponta pra outro domínio, mas o código da versão 13 não tem essa checagem. Um site inteiro com canonical pro .vercel.app tira 100. O caso está em canonical apontando pro vercel.app.
• Soft 404. Uma página "Produto não encontrado" que responde 200 passa no código de status. O Google pode tratar como erro. Veja soft 404.
• Robôs de IA. A auditoria de indexação testa as regras gerais, o Googlebot, o bingbot, o DuckDuckBot e o robô do archive.org. Um robots.txt ou firewall que bloqueia os robôs do ChatGPT, do Claude, do Perplexity ou o Google-Extended do Gemini não muda a nota. O verificador de robôs de IA confere isso.
• Conteúdo que só existe depois do JavaScript. O Lighthouse roda num Chrome completo. Robôs que não rodam JavaScript podem ver uma página vazia que, no relatório, está perfeita.
• O site inteiro. É uma URL por teste, então ele também não vê títulos repetidos nem dez páginas com canonical pra uma só. A home com 100 não diz nada sobre as páginas de produto.
• O que muda depois. O relatório é uma foto. O próximo deploy pode pôr um noindex na home, e ninguém vai rodar o PageSpeed de novo pra ver.

Tabela resumo

A varredura grátis da Varrida confere o que o Lighthouse deixa de fora (sitemap, canonical pro domínio errado, soft 404, robôs de IA) em várias páginas de uma vez.