Um site que demora mais de 2,5 segundos para carregar o elemento principal da página já está perdendo posição no Google antes mesmo de qualquer outro fator entrar em jogo — esse é o limite oficial do LCP, uma das três métricas que o Google usa para decidir se a experiência do seu site é boa ou ruim. Melhorar um site em 2026 passa por três frentes que funcionam juntas: velocidade técnica, estrutura para celular e qualidade do conteúdo. Negligenciar uma delas limita o resultado das outras duas.
Na prática, uma otimização completa precisa responder a cinco perguntas: o site pode ser encontrado e indexado pelo Google? As páginas carregam e respondem rápido em aparelhos reais, não só no computador do escritório? O conteúdo resolve de verdade a dúvida de quem chega até ele? A navegação leva o visitante a uma ação clara? E o site consegue crescer sem acumular link quebrado, página esquecida e risco de segurança? Este checklist segue essa ordem.
Core Web Vitals: as três métricas que o Google mede de verdade
Desde 2021, o Google usa um conjunto de três métricas técnicas, chamadas Core Web Vitals, como fator oficial de ranqueamento. Em 2026 elas continuam sendo:
| Métrica | O que mede | Limite “bom” |
|---|---|---|
| LCP (Largest Contentful Paint) | Tempo até o maior elemento visível da página carregar | 2,5 segundos ou menos |
| INP (Interaction to Next Paint) | Tempo de resposta da página a um clique ou toque | 200 milissegundos ou menos |
| CLS (Cumulative Layout Shift) | Quanto os elementos da página “saltam” enquanto carregam | 0,1 ou menos |
O Google avalia pelo percentil 75: 75% das visitas reais ao seu site precisam atingir esses números para a página ser classificada como “boa”. Um site pode parecer rápido para você, testando em uma conexão boa, e ainda assim falhar nesse critério para a maioria dos visitantes reais, que acessam em redes piores.
O que realmente trava o LCP
Na prática, três coisas costumam atrasar o carregamento do elemento principal da página:
- Imagens pesadas sem compressão — converter para o formato WebP com compressão adequada reduz o tamanho do arquivo entre 25% e 35% sem perda visual perceptível;
- Scripts de terceiros — plugins, pixels de rastreamento e widgets de chat carregam recursos externos que competem pelo mesmo tempo de processamento que o conteúdo principal;
- Cache mal configurado — sem cache adequado, o servidor reprocessa a página do zero a cada visita, em vez de entregar uma versão já pronta.
Por que o CLS é o mais fácil de resolver e o mais ignorado
CLS alto geralmente tem uma causa simples: imagens ou anúncios sem dimensão definida no código, que “empurram” o texto da página para baixo no momento em que terminam de carregar. A correção é definir a largura e altura (width e height) de toda imagem antes dela carregar — o navegador reserva o espaço certo desde o início, e o conteúdo não se move depois.
Site mobile-friendly: o que o Google realmente verifica
Mais da metade do tráfego de busca no Brasil acontece pelo celular, e o Google usa principalmente a versão mobile do site para indexação. Os pontos que mais pesam:
- Design responsivo que se adapta a qualquer resolução de tela, sem precisar dar zoom para ler;
- Botões e links com área de toque grande o suficiente para não exigir precisão de pixel;
- Formulários otimizados para preenchimento em tela pequena — menos campos, teclado certo para cada tipo de informação;
- Velocidade de carregamento testada em conexão 4G, não só em Wi-Fi de escritório.
O Google descontinuou a antiga ferramenta Mobile-Friendly Test em dezembro de 2023 — hoje a avaliação de usabilidade mobile é feita pelo Lighthouse (disponível no Chrome DevTools e no PageSpeed Insights), que mede esses pontos junto com desempenho e acessibilidade na mesma auditoria. Vale também testar manualmente em um celular real — alguns problemas de toque e legibilidade só aparecem na prática.
HTTPS e segurança: o básico que ainda falha em muitos sites
Certificado SSL válido é pré-requisito, mas não é só isso. Três erros comuns mesmo em sites que já têm HTTPS:
- Conteúdo misto — alguma imagem, script ou fonte ainda carregando via HTTP dentro de uma página HTTPS, o que o navegador trata como falha de segurança parcial;
- Redirecionamento mal configurado — a versão HTTP do site deveria redirecionar automaticamente para HTTPS, sem etapas extras;
- Certificado perto de expirar — sem renovação automática configurada, o site fica vulnerável a ficar fora do ar com aviso de “conexão não seguraria” no navegador do visitante.
Conteúdo e estrutura: links quebrados custam mais do que parecem
Um link interno quebrado não é só um inconveniente para quem clica — ele interrompe o caminho que o Google usa para entender a estrutura do site e distribuir autoridade entre as páginas. Sites com muito conteúdo acumulado ao longo dos anos tendem a acumular esse tipo de problema sem que ninguém note, porque o link funcionava quando foi criado e só quebrou depois que outra página foi movida, renomeada ou apagada.
Vale fazer uma varredura periódica (não só uma vez) procurando links internos que apontem para páginas que não existem mais, e corrigir ou redirecionar.
Conteúdo: a pergunta que vem antes de qualquer ajuste técnico
Um site pode passar todos os testes de velocidade e segurança e ainda assim não rankear, se o conteúdo não resolver de verdade a dúvida de quem chegou até ele. Antes de revisar o on-page de uma página, vale perguntar: ela responde à pergunta que a pessoa pesquisou, ou só fala em volta do assunto? Páginas que pareceram completas para quem escreveu, mas deixam a decisão real do leitor sem resposta, tendem a perder posição com o tempo, mesmo tecnicamente saudáveis.
On-page básico que continua determinando o resultado
Antes de qualquer ajuste técnico de velocidade, vale confirmar se o básico de SEO on-page está correto — sem isso, mesmo um site rápido tem dificuldade para ranquear:
- Um H1 por página, contendo a palavra-chave principal — páginas com H1 duplicado ou ausente confundem o Google sobre qual é o assunto central;
- Hierarquia de heading sem saltos — pular de H2 direto para H4 sem H3 quebra a estrutura semântica que o Google usa para entender a organização do conteúdo;
- Title tag entre 50 e 60 caracteres, com a palavra-chave principal próxima do início;
- Meta description entre 150 e 160 caracteres, com um motivo claro para clicar, não só uma repetição do título.
Como auditar seu site sozinho, passo a passo
Não é necessário nenhuma ferramenta paga para o primeiro diagnóstico:
- PageSpeed Insights (gratuito, do próprio Google) — rode a URL da homepage e de 2-3 páginas internas importantes, separadamente. O resultado mobile costuma ser mais baixo que o desktop, e é o que importa mais;
- Relatório de Core Web Vitals no Search Console — mostra dados reais agregados de todas as páginas do site, separando as que estão “boas”, “precisam de melhoria” e “ruins”;
- Lighthouse (dentro do Chrome DevTools ou do próprio PageSpeed Insights) — substituiu o antigo Mobile-Friendly Test e confirma rapidamente se há erro crítico de usabilidade mobile, junto com desempenho e acessibilidade;
- Inspeção manual de 5-10 links internos nas páginas mais visitadas — clique em cada link e confirme que a página de destino ainda existe.
Esse diagnóstico de 30-40 minutos já aponta onde focar primeiro, sem precisar de ferramenta paga de auditoria completa.
Dados de laboratório vs. dados de campo: por que os números nunca batem
É comum rodar o PageSpeed Insights, ver uma nota alta, e ainda assim encontrar o site classificado como “precisa de melhoria” no relatório de Core Web Vitals do Search Console. Isso não é contradição — são duas medições diferentes.
- Dados de laboratório vêm de um teste controlado, em condição de rede e aparelho padronizada. Servem para reproduzir um problema específico e comparar uma alteração antes/depois, mas não representam a experiência de todo mundo;
- Dados de campo vêm de visitas reais, em aparelhos e conexões variados — são esses que o Google usa para avaliar Core Web Vitals de fato, e aparecem no Search Console depois de volume suficiente de visitas acumuladas.
Um site pode ter nota de laboratório excelente e dados de campo ruins, principalmente se boa parte do público real acessa por celular em conexão fraca — exatamente o cenário que o teste de laboratório, rodado no Wi-Fi do escritório, não captura.
Quanto tempo leva para ver resultado depois de melhorar o site
Depois de implementar qualquer uma dessas correções, os dados de campo do Google (os que realmente contam para o ranqueamento) levam entre 4 e 8 semanas para refletir a melhora, porque o Google usa dados de visitas reais acumuladas, não uma medição instantânea. É normal testar uma página no PageSpeed Insights, ver o resultado melhorar imediatamente no teste de laboratório, e ainda assim não ver mudança no relatório de Core Web Vitals do Search Console por mais de um mês.
Checklist resumido por prioridade
| Prioridade | Ação |
|---|---|
| Alta | Comprimir imagens para WebP e definir dimensões explícitas |
| Alta | Revisar scripts de terceiros que carregam sem necessidade em todas as páginas |
| Alta | Corrigir conteúdo misto e configurar redirecionamento HTTP para HTTPS |
| Média | Testar o site em um celular real, não só na ferramenta do Google |
| Média | Mapear e corrigir links internos quebrados |
| Baixa | Configurar renovação automática de certificado SSL |
Erros comuns ao tentar melhorar um site
Otimizar só a homepage
O Google avalia Core Web Vitals por página, não só pelo site como um todo — uma homepage rápida com páginas internas lentas não resolve o problema de fundo.
Confiar só no teste de laboratório
Uma nota alta no PageSpeed Insights, medida em condição controlada, não garante que os visitantes reais — em redes piores, aparelhos mais fracos — tenham a mesma experiência. Os dados de campo do Search Console mostram a realidade.
Adicionar mais plugins para resolver o que outro plugin causou
É comum instalar um plugin de cache para compensar a lentidão causada por outros três plugins de funcionalidade — às vezes a solução mais eficaz é remover o que não é essencial, não adicionar mais uma camada.
Esperar resultado imediato
Como mostrado na seção sobre prazo, dados de campo demoram de 4 a 8 semanas para refletir qualquer correção — abandonar uma melhoria por “não ter funcionado” depois de poucos dias costuma ser precipitado.
No fim das contas, velocidade não é sobre impressionar o Google
Cada um dos itens deste checklist — LCP, INP, CLS, mobile-friendly, HTTPS, links quebrados — existe porque afeta diretamente a experiência de quem visita o site, e o Google só está medindo o que o visitante já sente na prática. Resolver na ordem de prioridade certa (compressão de imagem e scripts de terceiros primeiro, depois mobile e segurança, por último a manutenção contínua de links) costuma trazer o ganho mais visível com o menor esforço.
Perguntas frequentes sobre como melhorar um site
Qual é o fator mais importante para melhorar um site no Google?
Não existe um único fator — Core Web Vitals, mobile-friendly, HTTPS e qualidade de conteúdo trabalham juntos. Mas problemas de LCP (carregamento lento) costumam ter o impacto mais visível e mais fácil de medir.
Quanto tempo leva para o Google reconhecer as melhorias feitas no site?
Entre 4 e 8 semanas, porque o Google usa dados reais de visitantes acumulados ao longo do tempo, não uma medição instantânea.
Como saber se meu site tem problema de Core Web Vitals?
O relatório de Core Web Vitals dentro do Google Search Console mostra os dados reais de campo, separados por LCP, INP e CLS, com as páginas específicas que estão fora do limite recomendado.
Comprimir imagens realmente faz diferença perceptível?
Sim — converter para WebP com compressão adequada reduz o tamanho do arquivo em 25% a 35% sem perda visual perceptível, o que ajuda diretamente o LCP.
Meu site é responsivo, ainda preciso me preocupar com mobile-friendly?
Sim — responsivo é só um dos critérios. Área de toque dos botões, velocidade em rede 4G e facilidade de preencher formulários em tela pequena também contam, e um tema responsivo não garante automaticamente nenhum desses três.
Vale a pena contratar alguém para resolver isso ou dá para fazer sozinho?
Boa parte do checklist (compressão de imagem, teste mobile, verificação de links) pode ser feita sem conhecimento técnico avançado. Itens como configuração de cache no servidor e remoção segura de scripts de terceiros costumam exigir mais familiaridade técnica para não quebrar outra parte do site no processo.
