Como Verificar Seus Core Web Vitals no AmICited

Páginas rápidas e estáveis também importam para a visibilidade em IA — os mecanismos de resposta favorecem fontes de carregamento rápido. Antes de explorar a auditoria do AmICited, vale entender o que os Core Web Vitals realmente medem e por que um problema de velocidade de página pode silenciosamente se transformar em um problema de citação em IA.

O que são os Core Web Vitals?

Os Core Web Vitals são um conjunto de métricas padronizadas que o Google criou para quantificar a experiência de página no mundo real: a rapidez com que o conteúdo principal de uma página aparece, a velocidade com que ela responde a interações e o quão estável ela permanece visualmente durante o carregamento. Foram criados para substituir noções vagas como “o site parece lento” por números que você pode acompanhar, comparar e usar para responsabilizar equipes de engenharia. O Google incorporou esses dados aos seus sinais de classificação de busca há anos, e os mesmos dados subjacentes — coletados de usuários reais do Chrome via Chrome UX Report (CrUX) — cada vez mais influenciam quais fontes os mecanismos de resposta estão dispostos a buscar, renderizar e citar.

As três métricas principais são Largest Contentful Paint (LCP), Interaction to Next Paint (INP) e Cumulative Layout Shift (CLS), cada uma associada a um limite de aprovação/reprovação que o Google publica e atualiza periodicamente. Duas métricas de apoio, First Contentful Paint (FCP) e Time to First Byte (TTFB), completam o panorama de velocidade de página ao isolar a rapidez com que o servidor responde e a rapidez com que qualquer coisa é renderizada, mesmo antes de o conteúdo principal estar pronto. Como o CrUX é construído a partir de dados de campo anonimizados — visitas reais de usuários reais do Chrome —, os números refletem condições reais (mix de dispositivos, qualidade da rede, geografia) em vez de um único teste de laboratório feito em uma conexão rápida de escritório.

Por que isso importa especificamente para a otimização para mecanismos generativos ? Os crawlers de IA e os sistemas de recuperação por trás das AI Overviews, da busca do ChatGPT e do Perplexity precisam buscar e interpretar sua página antes de poderem citá-la. Uma página que expira, carrega lentamente ou desloca conteúdo durante o carregamento é mais cara de rastrear em escala e menos confiável para extrair conteúdo limpo. Um TTFB lento, em particular, pode fazer com que um crawler abandone a busca antes mesmo de o conteúdo principal chegar. Nada disso é o fator dominante para determinar se você será citado — relevância de conteúdo, autoridade e estrutura importam muito mais —, mas uma página inicial cronicamente lenta ou instável é um atrito que os mecanismos de resposta não têm motivo para tolerar quando um concorrente mais rápido oferece a mesma informação.

Este também é um caso em que o SEO técnico e a otimização para mecanismos de resposta se sobrepõem quase completamente: os mesmos ajustes de engenharia que melhoram seu posicionamento no Google — dimensionamento de imagens, tempo de resposta do servidor, estabilidade de layout — são os que mantêm suas páginas acessíveis e citáveis para sistemas de IA. É exatamente por essa sobreposição que o AmICited apresenta os Core Web Vitals dentro de uma auditoria mais ampla de visibilidade em IA , em vez de como uma ferramenta de SEO isolada: é um dos insumos que determinam se os mecanismos de IA consideram seu site confiável e fácil de trabalhar.

Onde encontrar

Abra Auditoria → Web Vitals no menu de navegação esquerdo. A página explica: “Core Web Vitals para a página inicial do seu domínio… a velocidade da página é um fator de classificação do Google e os mecanismos de resposta de IA favorecem páginas de carregamento rápido.” O AmICited coleta esses dados automaticamente para o seu domínio monitorado e para cada concorrente que você acompanha, então você não precisa rodar uma ferramenta separada nem colar URLs manualmente — é o mesmo conjunto competitivo que você já usa para acompanhar share of voice e o ranking de citações em outras partes da plataforma.

Como o CrUX exige um volume mínimo de tráfego real do Chrome antes de publicar números estáveis para uma URL, domínios com pouco tráfego — incluindo muitos sites B2B e de nicho — às vezes exibirão valores em branco por um tempo. Isso é comportamento esperado, não um bug: significa que o Google ainda não acumulou dados de campo suficientes para reportar com confiança, e os valores serão preenchidos assim que o tráfego (ou o tempo) se acumular.

O que as métricas significam

A tabela de comparação de concorrentes lista cada domínio com:

• Pontuação — um resumo geral de aprovação/reprovação dos Core Web Vitals, dando uma visão rápida de se um domínio atende aos limites do Google de forma geral.
• LCP (Largest Contentful Paint) — a rapidez com que o conteúdo principal carrega, tipicamente a maior imagem ou bloco de texto na área visível. É a métrica mais diretamente ligada à percepção de um visitante — ou de um crawler — de que “a página está pronta”.
• INP (Interaction to Next Paint) — o quão responsiva a página parece quando um usuário realmente interage com ela (clicando, tocando, digitando). Substituiu a antiga métrica First Input Delay porque capta a responsividade ao longo de toda a visita à página, não apenas na primeira interação.
• CLS (Cumulative Layout Shift) — o quão visualmente estável a página é durante o carregamento. Um CLS alto significa que elementos saltam de lugar conforme imagens, anúncios ou fontes carregam, o que é incômodo para os visitantes e pode dificultar a interpretação consistente do conteúdo por sistemas automatizados.
• FCP (First Contentful Paint) — a rapidez com que algo aparece pela primeira vez na tela, mesmo antes de o conteúdo principal estar pronto. É um sinal precoce de que a página está de fato carregando, em vez de permanecer em branco.
• TTFB (Time to First Byte) — velocidade de resposta do servidor: o tempo entre a requisição da página e o recebimento do primeiro byte de resposta. É quase inteiramente uma métrica de backend/infraestrutura, e costuma ser a mais fácil de corrigir com mudanças de hospedagem, cache ou CDN.

Seu próprio domínio é marcado como Você, com as páginas iniciais dos seus concorrentes monitorados listadas abaixo, de modo que cada métrica é imediatamente comparada em vez de vista isoladamente.

Como usar

1. Compare com os concorrentes. Se as páginas dos concorrentes são mais rápidas, essa é mais uma vantagem que eles têm tanto nas buscas quanto nas respostas de IA — e uma lacuna barata de fechar em relação a trabalho de conteúdo ou autoridade.
2. Corrija os vermelhos. Um LCP ou CLS reprovado aponta para trabalhos específicos de engenharia: imagens de destaque com tamanho excessivo, atributos de largura/altura ausentes, scripts que bloqueiam a renderização ou fontes web não otimizadas costumam ser os culpados de sempre.
3. Priorize o TTFB se estiver lento. Como ele está a montante de todas as outras métricas, um TTFB lento também prejudica o LCP, e costuma ser a métrica mais rápida de melhorar — muitas vezes por meio de cache, uma CDN ou um upgrade de hospedagem, em vez de uma reescrita de conteúdo.
4. Reavalie após alterações. Conforme os dados de campo são atualizados, volte para confirmar se as melhorias foram aplicadas. Os dados do CrUX usam uma janela móvel de 28 dias, então as mudanças levam tempo para aparecer — não espere que os números mudem no dia seguinte a um deploy.
5. Trate o TTFB como um sinal de alerta precoce. Um servidor que regularmente leva mais de um segundo para retornar o primeiro byte é um forte candidato a ter problemas de rastreamento e renderização que vão muito além desta auditoria específica — vale a pena entender por que engenheiros de crawlers cada vez mais tratam um TTFB rápido como limite para o sucesso de crawlers de IA , e não como algo apenas desejável.

Nenhuma dessas quatro métricas opera isolada do restante da sua base técnica. Uma página inicial com boa pontuação nos Core Web Vitals, mas que bloqueia crawlers de IA no robots.txt, ou que exibe uma página praticamente vazia para clientes sem JavaScript, ainda assim não será citada — a velocidade só ajuda depois que um crawler tem permissão de entrar e consegue interpretar o que está ali. Por isso vale a pena tratar esta auditoria como um checkpoint dentro de uma rotina mais ampla, em vez de uma correção pontual: execute-a junto com suas outras auditorias do AmICited em uma cadência regular, da mesma forma que você revisitaria periodicamente uma checklist de auditoria técnica mais ampla cobrindo rastreabilidade, dados estruturados e extraibilidade de conteúdo.

Os Web Vitals sozinhos não garantem citações, mas páginas lentas e instáveis podem te prejudicar — esta auditoria mostra onde você está em relação aos sites entre os quais os mecanismos de IA estão escolhendo. Se quiser se aprofundar na pesquisa por trás dessa recomendação, veja se a velocidade de página realmente afeta a visibilidade em buscas de IA , e combine esta verificação com uma auditoria de acessibilidade para IA mais ampla do seu site para cobrir o lado da rastreabilidade. A partir daí, o próximo passo natural é incorporar os Web Vitals à sua cadência regular de monitoramento junto com o rastreador de ranking em IA do AmICited e o acompanhamento de citações, para que uma regressão de desempenho seja detectada ao mesmo tempo em que você notaria uma queda nas menções — em vez de ser descoberta separadamente, semanas depois, quando já tiver custado visibilidade.