Pular para o conteúdo
Todos os artigos

O que o Google enxerga no seu site

Um guia prático do Google Search Console para quem constrói aplicações web: o que ele mostra, como configurar do jeito certo e o que olhar antes que o tráfego caia.

Sumário

Você instrumenta tudo o que roda do seu lado: latência, erro, fila, uso de CPU. Mas metade do que decide o destino da sua aplicação na busca acontece dentro de um sistema que pertence ao Google e não emite um único log no seu servidor. O Search Console é o painel gratuito e oficial desse lado — e é justamente a parte da stack que quase ninguém abre.


Uma lupa sobre a janela de um site; dentro da lente, no lugar do conteúdo, tags de código envolvendo um container vazio
O que você publica e o que o Google indexa nem sempre são o mesmo documento.

Abertura · O ponto cego de toda aplicação web

O deploy passou, o domínio resolve, a página abre bonita no navegador. Está no ar. Só que "estar no ar" e "existir para o Google" são afirmações diferentes, e a distância entre elas é onde nascem quase todos os problemas de busca que aparecem tarde demais.

Publicar uma página é entregá-la a um processo que você não hospeda. Um robô decide se vai visitar; se visita, decide se executa o seu JavaScript; se executa, decide o que aquilo significa; e um segundo sistema decide onde colocar o resultado numa lista. Do ponto de vista do seu servidor, tudo respondeu 200 e acabou. O resto é invisível.

O Google Search Console (GSC) existe para tornar esse resto visível. É um serviço gratuito onde o índice de busca do Google reporta, para quem provou ser dono do site, o que ele viu e o que fez com isso. Nasceu discreto em 2005 como uma ferramenta de envio de sitemap, virou Google Webmaster Tools em 2006 e ganhou o nome atual em maio de 2015. Mudou de nome; a função não. É a única superfície oficial onde o sistema que decide o seu ranqueamento fala de volta com você. Tudo o mais que chamamos de SEO é observação de fora; o Search Console é o índice descrevendo a si mesmo.

Antes de configurar, vale ter o pipeline na cabeça, porque cada relatório do GSC mede um estágio dele:

Figura 01 · O caminhoDa URL publicada ao resultado exibido
Da URL publicada ao resultado exibidoDa URL que existe ao resultado que aparece: descoberta, rastreio, renderização, indexação e exibição, com o relatório do Search Console que cobre cada etapa e os pontos onde a página some sem gerar erro no seu servidor.PUBLICADORESULTADO01DescobertaSitemapsLinks02RastreioEstatísticasde rastreamento03RenderizaçãoInspeçãode URL04IndexaçãoIndexação(Páginas)05ExibiçãoDesempenhoRELATÓRIO NO SEARCH CONSOLE

Configuração · Propriedade e verificação

Antes de ver qualquer dado, você declara o que quer monitorar (a propriedade) e prova que é dono (a verificação). São duas decisões, e errar a primeira te deixa cego em pontos inteiros do site.

Existem dois tipos de propriedade:

  • Propriedade de domínio (bispolabs.com) — cobre todos os subdomínios (www, blog, app, api) e os dois protocolos (http e https) de uma vez. É a visão completa, à prova de futuro: qualquer subdomínio novo já entra sozinho. A contrapartida é que só pode ser verificada de uma forma: um registro TXT no DNS.
  • Propriedade de prefixo de URL (https://www.bispolabs.com) — cobre apenas aquela combinação exata de protocolo e host. Mais restrita, porém com mais formas de verificar, e obrigatória se você quiser vincular ao Google Analytics 4.

Para a verificação de prefixo, o Google aceita cinco métodos: arquivo HTML na raiz, meta tag no <head> da home, conta do Google Analytics (exige permissão de edição), Google Tag Manager (exige permissão de publicação) e registro DNS (TXT ou CNAME). Escolha um e não o remova depois — o Google revalida a posse periodicamente, e apagar o token derruba o acesso. Mudança de DNS propaga de alguns minutos a 48 horas (no Cloudflare costuma ser quase instantânea).

A recomendação prática: se você tem acesso ao DNS, comece pela propriedade de domínio. Ela evita o erro clássico de verificar a versão errada do site (http em vez de https, ou sem www) e ficar coletando dado de um lugar onde ninguém entra. Mas há um detalhe que quase ninguém sabe: em propriedades grandes, o GSC amostra e agrega os dados, e subdomínios ou seções menores acabam diluídos no total. Por isso vale ter a propriedade de domínio para a visão macro e propriedades de prefixo para as partes que você quer enxergar em detalhe — o blog, a API pública, uma landing específica.

Figura 02 · A propriedadeUma abraça tudo; a outra recorta
Uma abraça tudo; a outra recortaUma propriedade de domínio cobre todos os subdomínios e os dois protocolos e só é verificada por DNS; um prefixo de URL recorta uma versão exata e aceita cinco métodos de verificação. O ideal é combinar as duas.PROPRIEDADE DE DOMÍNIOPREFIXO DE URLbispolabs.comwwwblogappapihttp · https · todo subdomínioverificação: só por DNSwww.bispolabs.comexatamente esta versão1 protocolo · 1 hostverificação: cinco métodos

Sitemap e robots · Dizendo o que existe (e o que ignorar)

Verificada a propriedade, dois arquivos na raiz do site conversam com o crawler, e confundi-los é um dos erros mais caros que já vi em produção.

Envie o seu sitemap.xml em Sitemaps — é a lista das URLs que você quer que o Google conheça, e acelera a descoberta em sites grandes ou novos. O robots.txt, por outro lado, controla o rastreio: diz ao robô onde ele pode ou não entrar.

A armadilha mora aqui: robots.txt não é a mesma coisa que noindex. Bloquear uma URL no robots.txt impede o Google de rastreá-la — mas, se ela já for conhecida por outros links, ele pode indexá-la mesmo assim, sem conteúdo, como uma casca. Pior: se você quer tirar uma página do índice com uma tag noindex, mas bloqueou aquela rota no robots.txt, o robô nunca chega a ler o noindex. Para remover, é o contrário do intuitivo: deixe o Google rastrear para que ele veja a instrução de não indexar.

As quatro ferramentas que realmente importam

O GSC tem dezenas de telas, mas o trabalho de quem constrói se concentra em quatro.

Desempenho · o que o mundo digitou para te achar

Mostra as consultas que trouxeram sua página, com cliques, impressões, CTR e posição média, cruzáveis por página, país, dispositivo e data. É o relatório mais olhado — e o mais mal lido. Alguns cortes que valem mais que o número absoluto de cliques:

  • Posição boa + CTR baixo numa consulta: você aparece, mas o título/description não convence. É otimização barata e de retorno rápido.
  • Marca vs. não-marca: separe as buscas pelo seu nome das buscas por tema. Crescer em não-marca é crescer de verdade; crescer só em marca é reflexo de outro canal.
  • Nível de página: descubra quais URLs sustentam o tráfego antes de mexer nelas numa refatoração.

Guarde uma limitação para depois: esse relatório retém 16 meses de histórico e mostra até 1.000 linhas por consulta na interface.

Inspeção de URL · o que a máquina renderizou

Cole qualquer URL do site e o GSC mostra o estado dela no índice: quando foi rastreada, se está indexada, sob qual canônica, e — o que mais importa para uma aplicação moderna — o HTML renderizado que o Google de fato extraiu. Não é o seu código-fonte nem o que o seu Chrome mostra; é o DOM depois de o Googlebot executar (ou tentar executar) o seu JavaScript.

Para qualquer app com renderização no cliente (React, Angular, Vue em CSR), essa é a tela decisiva. Já vi página perfeita no navegador aparecer, na inspeção, como um <div id="root"> vazio: o usuário via tudo, o robô, nada. O botão Solicitar indexação força uma nova visita depois de uma correção, e o teste ao vivo compara a versão atual com a última indexada.

Indexação (Páginas) · onde cada URL travou

Indexação não é sim ou não; é um funil, e o relatório de Páginas te diz em qual degrau cada URL parou e por quê. Os estados que mais aparecem:

  • Descoberta – atualmente não indexada: o Google sabe que existe, mas não priorizou rastrear. Sinal de orçamento de rastreio ou de conteúdo raso.
  • Rastreada – atualmente não indexada: leu e decidiu não guardar. Quase sempre é qualidade ou duplicidade.
  • Página alternativa com tag canônica adequada / Duplicada sem canônica selecionada pelo usuário: problemas de canonical.
  • Excluída por noindex e Bloqueada pelo robots.txt: às vezes proposital, às vezes um resquício de staging que foi para produção.
  • Soft 404: respondeu 200, mas parece uma página de erro.

Nenhum desses erros aparece no seu monitoramento de aplicação, porque todos retornaram 200. Só aparecem aqui.

Core Web Vitals · a experiência medida em campo

Reporta a saúde de três métricas com dado de campo real (do CrUX), no percentil 75, separadas por mobile e desktop — e não em laboratório:

  • LCP (Largest Contentful Paint) — carregamento — bom até 2,5 s.
  • INP (Interaction to Next Paint) — responsividade — bom até 200 ms. Substituiu o antigo FID em março de 2024, medindo a resposta ao longo de toda a visita, não só do primeiro clique.
  • CLS (Cumulative Layout Shift) — estabilidade visual — bom até 0,1.

É sinal de ranqueamento e, ao mesmo tempo, o proxy mais honesto de UX real que você tem de graça. Da tela do GSC você salta para o PageSpeed Insights para diagnosticar página a página.

Figura 03 · Os instrumentosCada tela responde uma pergunta
Cada tela responde uma perguntaDesempenho, Inspeção de URL, Indexação e Core Web Vitals: cada relatório responde a uma pergunta diferente e mede um estágio diferente do caminho até a busca.O QUE CADA TELA RESPONDE01Desempenhoquem te achou?02Inspeção de URLo que o robô viu?03Indexaçãoonde a URL travou?04Core Web Vitalsé rápida de verdade?cada um mede um estágio

O resto do painel · o que checar de vez em quando

Fora do dia a dia, o GSC guarda relatórios que você abre quando precisa:

  • Aprimoramentos / Resultados avançados — valida os seus dados estruturados (schema.org) e mostra por que um rich result não está sendo elegível.
  • Links — os principais links internos e externos e os textos-âncora. Útil para entender a arquitetura de informação que o Google inferiu do seu site.
  • Ações manuais e Problemas de segurança — o aviso de que um humano do Google aplicou penalidade, ou de que ele detectou conteúdo hackeado/malware. É a tela que você quer que esteja sempre vazia — e a primeira a checar quando o tráfego cai do nada.
  • Estatísticas de rastreamento (em Configurações) — quantas requisições o Googlebot fez, com quais respostas e tempos. Ajuda a flagrar picos de erro 5xx ou orçamento de rastreio sendo gasto em URL que não deveria.
  • Remoções — esconde uma URL dos resultados temporariamente (não é o mesmo que desindexar de verdade).

Limites e exportação · onde o painel acaba

Aqui é onde o dev precisa saber a verdade antes de construir dashboard em cima. Os dados do GSC têm três tetos:

  1. Interface: 1.000 linhas por consulta.
  2. API do Search Console: até 25.000 linhas por requisição.
  3. Retenção: 16 meses de histórico — e isso vale para a interface, a API e o Looker Studio. Passou disso, sumiu de todos.

Para furar os limites de linha existe o Bulk Data Export: uma exportação diária, automática e sem amostragem de todos os dados de desempenho direto para o BigQuery (em Configurações › Exportação em massa de dados — você concede à conta de serviço search-console-data-export@system.gserviceaccount.com os papéis BigQuery Job User e BigQuery Data Editor e cola o ID do projeto). Duas ressalvas honestas: ele não faz backfill — só captura do dia em que você liga em diante — e o BigQuery tem custo próprio além da cota gratuita. Se SQL é demais para o caso, o conector nativo do Looker Studio é gratuito, fura o teto de 1.000 linhas e resolve a maioria dos relatórios (ainda preso aos 16 meses).

A lição prática: se você quer histórico longo, comece a exportar cedo. O dado que você não capturou hoje não volta.

Figura 04 · A exportaçãoQuanto mais dado, mais fundo desce
Quanto mais dado, mais fundo desceDa interface, limitada a mil linhas, à API com 25 mil linhas por requisição e ao Bulk Data Export para o BigQuery, sem limite nem amostragem. A retenção de 16 meses corta todos os degraus, e nada recupera o passado que não foi exportado.QUANTO MAIS FUNDO, MAIS DADOInterface1.000 linhas por consultaAPI25.000 linhas por requisiçãoBigQuery · Bulk Exportsem limite · sem amostragem16 meses de retenção cortam todos

Rotina · 15 minutos por semana

O valor do GSC não está em abrir uma vez e esquecer, e sim em virar hábito curto e regular. Um roteiro que cabe num café:

  • Desempenho, semana contra semana: alguma queda ou pico fora do normal?
  • Indexação: alguma página que estava indexada saiu? Alguma presa em Descoberta – não indexada há mais de duas semanas merece investigação.
  • Core Web Vitals: alguma URL migrou de "bom" para "precisa melhorar" depois do último deploy?
  • Ações manuais / Segurança: continua tudo limpo?

Numa migração ou refatoração, esse mesmo painel vira rede de segurança: você compara antes e depois e pega regressão de indexação antes que ela vire perda de tráfego.

O painel é seu para ler, não para possuir

O Search Console é a camada de observabilidade gratuita e oficial da parte da sua stack que o Google hospeda. Nenhuma ferramenta paga substitui isso, por um motivo simples: é o único lugar onde o sistema que decide o seu destino conta o que enxergou. Configurar direito — propriedade de domínio, verificação que não some, sitemap enviado, robots e noindex no lugar certo — é trabalho de uma tarde que evita meses de ponto cego.

Vale lembrar só de uma coisa ao ler a agulha: o painel é do Google. Ele decide o que mostrar, o que amostrar, quanto histórico guardar e o que esconder atrás de um limite de linha. É uma régua emprestada, calibrada pelo dono da caixa.

Mas é a única régua que a caixa te entrega — e um site que ninguém mede é um site que você publicou no escuro.


Fontes