O relatório de um analisador de SEO é uma lista de hipóteses ordenadas por prioridade, não um veredito sobre o seu site.
Rodei o Analisador que eu mesmo construí no meu próprio site, duas vezes, com 29 dias de intervalo: a nota foi de 7,3 para 8,6, e mesmo assim o celular levou 12,7 segundos para carregar o conteúdo principal. Abaixo estão os cinco achados que apareceram, como conferir cada um sem ferramenta nenhuma e o que fazer com ele.
Por que eu testei a ferramenta em casa
O Analisador lê o HTML e o CSS públicos de um site, mede a performance pelo PageSpeed e devolve uma nota por área, com a lista do que corrigir primeiro. Eu uso essa análise para olhar o site de outras empresas. Faltava aplicar a mesma régua no meu, e publicar o resultado inteiro, inclusive o que não ajuda a me vender. Quem oferece diagnóstico precisa aguentar o próprio.
Antes de corrigir qualquer coisa, confira o número
Na primeira rodada, em 29 de setembro, o Analisador apontou 143 cores distintas no CSS, 114 estilos de botão e 14 famílias de fonte. Antes de assumir isso em público, medi o CSS real da home à mão, no navegador. A contagem bruta deu 251 cores. Unificando as equivalentes e ignorando transparência, 169. O número mudava conforme o método de contagem, então “143 cores” não era uma medida, era uma opinião da ferramenta.
Isso vale para qualquer relatório automático, o meu ou o de outra pessoa. Três perguntas que eu faria antes de acreditar num número de design:
- Dá o mesmo resultado por outro método? Se contar de outro jeito muda muito, o número é instável.
- É total ou é concentração? No meu CSS, dez cores concentram a maior parte do uso e 105 das 219 normalizadas aparecem uma única vez. O total assusta; a concentração conta a história real.
- É código seu ou de terceiros? Boa parte da cauda longa vinha de tema, WPBakery e plugins, não de decisão de design minha. A ferramenta mede o CSS carregado, não o design em uso, e não separa um do outro.
Ajustei a contagem do Analisador depois disso. Na segunda rodada, em 28 de outubro, o relatório mostra 5 famílias de fonte, 150 cores e 25 estilos de botão, e esses números aparecem como retrato técnico, sem virar nota. Por isso não vou dizer que meu design melhorou de 14 fontes para 5: a régua mudou entre as duas rodadas.
Os cinco achados, em ordem de prioridade
1. H1 ausente nas subpáginas
Na primeira rodada, 4 das 10 subpáginas analisadas não tinham H1. Era o achado de maior prioridade: impacto alto, esforço baixo. O H1 é o título principal da página, e o Google usa o título principal, entre outras fontes, para montar o título que exibe na busca. Deixar esse título claro é uma recomendação da própria documentação do Google Search Central.
Como conferir sem ferramenta: abra a página, clique com o botão direito, escolha “Exibir código-fonte” e procure por “<h1”. Se não achar, a página não tem. Como corrigir: no construtor de páginas, o título principal precisa estar com a tag H1 (no Elementor, o widget de título tem o campo “HTML Tag”; no WPBakery, o cabeçalho tem a opção de tag do elemento). Uma por página é o padrão mais simples de manter.
2. Title longo demais
O title da minha home tinha 69 caracteres, e hoje tem 55. Aqui existe uma imprecisão comum: o Google informa que não há limite de tamanho para o elemento title, e que o título exibido é cortado quando necessário, em geral para caber na largura do dispositivo. Os 60 caracteres são uma referência prática, não uma regra do Google. O que importa mais é que o title seja específico e descritivo, sem termos vagos como “Home”, sem repetição de palavra-chave e com a marca de forma curta, no início ou no fim.
Como conferir: o title aparece na aba do navegador e no código-fonte, dentro de <title>. Se o Google reescrever o seu na busca, pode ser sinal de que o title está incompleto, desatualizado ou não reflete o conteúdo da página.
3. Imagens em JPG/PNG e sem lazy loading
O Analisador apontou 11 imagens em formato tradicional e nenhuma com loading=”lazy”. Os dois itens são de impacto baixo ou médio e merecem cuidado, porque o conselho óbvio pode piorar o problema.
- Formatos modernos. WebP e AVIF comprimem melhor que JPEG e PNG, segundo a documentação do Lighthouse. WebP tem suporte nos navegadores recentes; AVIF tem suporte mais limitado, e por isso convém manter um fallback. No WordPress, o caminho comum é um plugin que converte as imagens enviadas.
- Lazy loading. Faz sentido nas imagens abaixo da dobra. Na imagem principal, que costuma ser o elemento do LCP, não. Segundo o web.dev, os sites com lazy loading tinham LCP mediano pior em uma análise de correlação, e o teste em WordPress mostrou que o lazy loading reduzia bytes mas atrasava o LCP. A orientação é nunca aplicar lazy loading à imagem do LCP.
Ou seja: “nenhuma imagem com lazy loading” não é automaticamente um problema. Depende de quais imagens.
4. Dívida de design system
Cores demais, fontes demais, espaçamento fora de múltiplos de 4 pixels, estilos de botão demais. O Analisador classifica isso como impacto baixo e esforço alto, e eu concordo. É sintoma de crescimento sem padrão, não emergência. Em site feito com tema e construtor de páginas, boa parte vem de fábrica. Eu trataria como backlog, não como correção urgente, e só atacaria quando for mexer no layout de qualquer jeito.
5. Performance no celular: o número que a nota não mostra
Ao lado da nota geral, o relatório traz a performance medida pelo PageSpeed no celular: 52 de 100, com LCP de 12,7 segundos. O LCP mede quanto tempo o maior elemento da página leva para aparecer, e o Google considera bom 2,5 segundos ou menos. Em julho, na análise que fiz para o redesign, o mesmo site marcava 65 e 5,6 segundos. Um site pode fechar 8,6 e ainda demorar 12,7 segundos para mostrar o conteúdo principal no celular. Quem chega pelo celular não vê a nota, vê a espera.
É medição de laboratório de uma rodada só, e esse tipo de número oscila. Eu trato como alerta e rodaria mais de uma vez antes de concluir. Para investigar, o web.dev divide o LCP em quatro partes, com proporções de referência: cerca de 40% é o tempo até o primeiro byte, menos de 10% é o atraso até o recurso começar a carregar, cerca de 40% é o carregamento do recurso e menos de 10% é o atraso até renderizar. Descobrir qual parte domina diz onde agir:
- Primeiro byte lento: reduzir redirecionamentos e servir o conteúdo em cache, por CDN quando possível.
- Recurso demora a começar: a imagem principal precisa estar no HTML inicial, com fetchpriority=”high”, e nunca com lazy loading.
- Recurso pesado: formatos modernos, tamanho adequado ao espaço que ocupa, compressão.
- Renderização travada: CSS grande e scripts síncronos no cabeçalho bloqueiam a tela. Reduzir o CSS e adiar o JavaScript que não é essencial.
No meu caso, esse é o item que fica pendente. Escrevi mais sobre o assunto em o que é velocidade de site.
Checklist de dez minutos para o seu site
- Abra o código-fonte da home e de duas subpáginas e procure “<h1”. Cada uma precisa de um título principal.
- Leia o title de cada página na aba do navegador. Ele descreve a página? Tem “Home” ou nome repetido?
- Rode o PageSpeed no celular duas ou três vezes e anote o LCP. Acima de 2,5 segundos, vale investigar.
- Identifique qual elemento é o LCP e confira se ele não está com lazy loading.
- Se algum número de design assustar, repita a contagem por outro método antes de agir.
Se você quiser ver o que o Analisador diz do seu site, é só rodar a análise, que é gratuita. Se preferir olhar o resultado comigo, o diagnóstico gratuito é o caminho, e o resto do meu trabalho está no portfólio.
Fontes
Quer saber o que o relatório diz do seu site?
Rode o Analisador no seu endereço, ou me mande o link no WhatsApp que eu rodo para você. Eu leio o resultado com você, separo o que vale corrigir agora do que pode esperar e digo o que eu faria primeiro. Sem compromisso.
