Guia · Conectores

Como conectar o Google Search Console ao Looker Studio — e o que fazer quando ele esbarra nos limites

Publicado em 26 de setembro de 2026 · 10 min de leitura

O Search Console é uma das poucas fontes que o Looker Studio (renomeado Data Studio pelo Google em abril de 2026) conecta de forma nativa, de graça, em uns noventa segundos. Na prática, você cria uma fonte de dados, escolhe o conector do Search Console, autoriza a conta do Google, seleciona a propriedade, o tipo de tabela e o tipo de pesquisa, e conecta. Este guia faz essa parte direito — os passos exatos e a única escolha de configuração que decide, sem alarde, quais perguntas o seu painel vai conseguir responder pelo resto da vida dele. Depois, mostra os quatro limites em que todo painel do Search Console acaba esbarrando, porque "grátis e nativo" não é o mesmo que "suficiente".

Como conectar: os passos de verdade

Você precisa de uma propriedade verificada no Search Console e de uma conta do Google com pelo menos permissão restrita nessa propriedade. Depois:

No Looker Studio, clique em Criar → Fonte de dados (Create → Data source) e procure Search Console. É um conector feito pelo Google, então ele aparece perto do topo da lista, sem selo de parceiro e sem preço.
Autorize (Authorize) o conector com a conta do Google que tem acesso à propriedade.
Escolha a propriedade. A lista mostra tanto propriedades de domínio (sc-domain:example.com) quanto propriedades com prefixo de URL (https://example.com/).
Escolha o tipo de tabela — Impressão do site (Site Impression) ou Impressão do URL (URL Impression). Essa é a escolha que importa; a próxima seção é inteira sobre ela.
Escolha o tipo de pesquisa — Web, Imagem, Vídeo ou Notícias. Ele é fixo por fonte de dados, então um relatório que precisa de Web e Imagem precisa de duas fontes de dados.
Clique em Conectar (Connect) e depois em Criar relatório (Create report). Coloque uma série temporal de cliques e você tem um painel funcionando.

A escolha da propriedade é uma armadilha que merece nome. Uma propriedade de domínio soma todos os subdomínios e os dois protocolos; uma propriedade com prefixo de URL conta só o prefixo exato em que foi verificada. São conjuntos de dados diferentes, que dão números diferentes para o mesmo site, e um gráfico montado na propriedade errada parece totalmente plausível. Escolha a que o seu time realmente usa nos relatórios e anote a escolha num lugar onde a próxima pessoa vai encontrar.

A escolha que cobra a conta depois: Impressão do site ou Impressão do URL

O conector pede que você escolha uma de duas tabelas, e a diferença não é cosmética: as duas contam de jeitos diferentes, então dão totais diferentes para os mesmos dias.

Impressão do site traz a Consulta (Query), país, dispositivo e data — mas não a página de destino. Ela conta como o gráfico do relatório de Performance do Search Console, por propriedade: quando duas páginas suas aparecem na mesma pesquisa, isso vale uma impressão só.
Impressão do URL traz a página de destino (Landing Page) e a Consulta, além de país, dispositivo e data. Ela conta por página: a mesma pesquisa mostrando duas páginas suas vale duas impressões, e os cliques e a CTR ficam com cada URL.

Então a pergunta de SEO mais natural — quais consultas trazem tráfego para esta página? — tem resposta no Looker Studio, mas só pela tabela Impressão do URL, e só na contagem dela. As impressões dessa tabela não vão bater com os totais da Impressão do site nem com o gráfico do Search Console nas mesmas datas. Nenhum dos dois números está errado: o Google agrega por propriedade os dados de consultas, países, dispositivos e datas, e por página os dados de páginas (Ajuda do Search Console, relatório de Performance).

A armadilha é misturar as duas. Um gráfico ou uma combinação que junta as duas tabelas soma números contados de dois jeitos diferentes, e nada na tela avisa isso. Escolha uma tabela por pergunta: Impressão do URL quando a pergunta envolve páginas, Impressão do site quando você precisa dos mesmos totais que o cliente ou o gestor vê no Search Console.

O que o conector continua sem entregar

Mesmo na tabela Impressão do URL, as consultas que o Google anonimiza por privacidade ficam de fora de todas as linhas por consulta, então uma tabela de consulta por página sempre soma menos que os cliques da própria página. A própria API Search Analytics do Search Console devolve as duas agregações, por propriedade e por página, e qualquer sistema que leia essa API periodicamente pode guardar as duas lado a lado — o detalhe de consulta por página ao lado dos totais do site, que ainda incluem o tráfego anônimo, e além dos dezesseis meses de retenção do Search Console.

Então a solução não é um gráfico melhor. É ler a mesma API num lugar que guarde as duas visões.

Os quatro limites, na ordem em que você vai esbarrar neles

1. Dezesseis meses, e acabou

O Search Console guarda aproximadamente dezesseis meses de dados de desempenho. O Looker Studio consulta esses dados ao vivo, então o histórico do seu painel é o histórico do Search Console — não existe arquivo por trás. Na primeira vez que alguém pedir uma comparação de sazonalidade de dois anos, a resposta vai ser que os dados não existem mais em lugar nenhum, a não ser que você estivesse guardando tudo por conta própria desde o começo.

2. Consultas anônimas fazem os números nunca baterem

O Search Console filtra as consultas de frequência muito baixa por motivo de privacidade (Ajuda do Search Console). A consequência pega muita gente de surpresa: a soma de uma tabela por consulta sempre vai ser menor que o total de cliques do site exibido na mesma página. Nenhum dos dois números está errado; são populações diferentes. Mas quem recebe o relatório e vê dois totais que não batem vai perguntar sobre isso todo santo mês, e um gráfico de "principais consultas" deixa de fora, sem avisar, toda a cauda longa enquanto parece completo.

3. Os dois últimos dias não são definitivos

O Search Console publica dados recentes em poucas horas e depois os revisa para cima conforme o processamento termina. Um painel de segunda-feira que inclui o dia anterior mostra um número provisório que o Google vai aumentar ao longo da semana. Nada na tela do Looker Studio marca quais linhas ainda não estão consolidadas — a linha do gráfico cai na ponta direita e alguém lê isso como queda.

4. Tudo fica preso na tela

Cada pergunta nova é um gráfico novo, montado à mão por quem tem permissão de edição. Uma combinação chega no máximo a cinco fontes de dados e oferece semântica de join em vez de SQL. Então, quando a pergunta vira "como os cliques orgânicos acompanharam o investimento em mídia paga no último trimestre", você está conciliando dois painéis no olho — e é exatamente nesse momento que as pessoas começam a se perguntar se a tela do Looker Studio é o lugar certo para isso. Levamos esse argumento adiante em alternativas ao Looker Studio (em inglês).

O outro caminho: ler a mesma API onde dá para cruzar os dados

O TableBI conecta o Search Console pelo mesmo fluxo OAuth e guarda os dados em dois níveis: search_console_raw, a tabela própria da plataforma, que mantém consulta e página juntas em cada linha (com os totais do site, os totais por página e país × dispositivo em tabelas próprias), e facts, onde cliques e impressões ficam nas mesmas definições entre canais que as suas plataformas de anúncios. A configuração leva três comandos:

terminal

# instale a CLI e ensine o seu agente a usá-la
npm i -g @tablebi/cli
tablebi login
tablebi install

# o navegador abre para o OAuth, depois o histórico é sincronizado
tablebi connect gsc --site sc-domain:example.com

# confira o que entrou e quão atualizado está
tablebi sources

Agora a pergunta de consulta por página vira uma instrução só, rodada sobre uma cópia guardada, e não sobre a API ao vivo:

claude code → tablebi

# quais consultas levam impressões para quais páginas?
tablebi ask "SELECT query, page, SUM(clicks) AS clicks,
             SUM(impressions) AS imp, AVG(position) AS pos
             FROM search_console_raw
             WHERE date >= (SELECT MAX(date) FROM search_console_raw) - 28
             GROUP BY query, page
             ORDER BY imp DESC LIMIT 50"

Dois detalhes dessa consulta são de propósito. O filtro de data se ancora em MAX(date), e não na data de hoje — por causa do limite nº 3, "hoje" ainda não é uma linha que existe, e ancorar no calendário dá uma janela vazia toda manhã. E toda resposta volta com um bloco de confiança: o quanto cada fonte está atualizada, mais as ressalvas que importam aqui — que os dois últimos dias são provisórios e que as somas por consulta ficam abaixo dos totais do site por definição. O seu agente lê isso e para de reportar, cheio de certeza, uma revisão como se fosse queda.

Se você quer o fluxo completo do Search Console, e não só a conexão, veja Claude Code para SEO (em inglês); se o que você queria mesmo era a API bruta sem escrever um cliente OAuth, veja a alternativa à API do Search Console (em inglês).

A pergunta que a tela do Looker Studio não alcança

O motivo para tirar o Search Console de um painel só dele raramente é o Search Console. É que o orgânico é uma linha num quadro que também tem mídia paga, e o limite da combinação é onde esse quadro deixa de ser montável:

claude code → tablebi

# cliques orgânicos ao lado do investimento em mídia paga: um resultado, as mesmas definições
tablebi ask "SELECT platform, SUM(clicks) AS clicks, SUM(cost) AS spend
             FROM facts WHERE date >= (SELECT MAX(date) FROM facts) - 28
             GROUP BY platform ORDER BY clicks DESC"

Fixe numa URL ao vivo

Quando vale a pena guardar uma visão, fixe. O que fica salvo é a consulta, e não um retrato — então a URL se atualiza sozinha toda vez que a fonte sincroniza:

claude code → tablebi

tablebi pin --title "Search Console — 28 days" \
  --widget "Daily clicks::line=SELECT date, SUM(clicks) AS clicks FROM search_console_raw …" \
  --widget "Top query × page=SELECT query, page, SUM(impressions) AS imp FROM search_console_raw …"
✓ published → https://dk.tablebi.com/d/dsh_…  (public, read-only, self-refreshing)

Aqui está um de verdade — dados ao vivo do Search Console de um portfólio de sites, fixados exatamente assim. Não é mockup; ele se atualiza conforme as fontes sincronizam:

Qual caminho escolher de verdade

O conector nativo é bom de verdade no que faz, e trocá-lo só por trocar é uma tarde jogada fora. Resumindo sem rodeios:

Fique com o conector nativo do Looker Studio quando o relatório é de uma propriedade só, as perguntas são tendências do site como um todo, o seu time já vive no Looker Studio e ninguém precisa de mais de dezesseis meses nem de orgânico ao lado do pago.
Vá para um backend operado por CLI quando você precisa de consulta × página ao lado dos totais do site, de histórico além da retenção do Search Console, de orgânico e pago no mesmo resultado, ou quando quem lê os dados é um agente, e não uma pessoa — porque um agente não arrasta gráfico, mas escreve SQL e lê um bloco que diz quão atualizados estão os dados.

Para ver como esse segundo caminho fica como produto final, e não como uma lista de comandos, veja o guia de painel de SEO (em inglês). E se o seu problema é uma fonte para a qual o Looker Studio não tem conector nenhum, a situação é outra, e pior — tratada em sem conector do Looker Studio para a sua fonte (em inglês).

Perguntas frequentes

O Looker Studio agora se chama Data Studio?

Sim. O Google renomeou o Looker Studio para Data Studio em 16 de abril de 2026, e a edição paga agora se chama Data Studio Pro (notas de versão do Data Studio). A documentação do conector do Data Studio continua descrevendo um conector do Search Console criado pelo Google, com os mesmos dois métodos de agregação: impressões do site e impressões do URL.

O conector do Google Search Console para o Looker Studio é gratuito?

É. O Search Console é um produto do Google, então o Looker Studio oferece um conector do próprio Google sem custo — sem assinatura de parceiro, sem cobrança por conta. Isso é a exceção, não a regra: a maioria das fontes que não são do Google depende de conectores de parceiros pagos.

Dá para ver consultas e páginas de destino na mesma tabela do Looker Studio?

Sim, pela tabela Impressão do URL, que tem a Consulta e a página de destino (Landing Page). Os números dessa tabela são contados por página, então não batem com a Impressão do site nem com o gráfico do Search Console nas mesmas datas, e as consultas que o Google anonimiza ficam de fora de qualquer linha por consulta.

Quanto histórico do Search Console o Looker Studio mostra?

Uns dezesseis meses, que é a janela de retenção do próprio Search Console. O Looker Studio consulta a API ao vivo em vez de guardar uma cópia, então não existe histórico mais longo por trás do painel. Se você precisa de comparações de vários anos, alguma coisa tem que estar guardando as linhas antes de você precisar delas.

Por que a soma das consultas no Looker Studio não bate com o total de cliques?

O Search Console anonimiza as consultas de frequência muito baixa, então qualquer detalhamento por consulta soma menos que o total do site. Os dois números estão corretos para o que medem. Conte com essa diferença, explique uma vez e não tente conciliar — ela não tem como ser fechada.

Dá para levar o Search Console para um painel sem usar o Looker Studio?

Dá. O TableBI conecta o Search Console pelo mesmo fluxo OAuth, guarda as linhas de consulta por página em search_console_raw e publica a URL de um painel ao vivo, somente leitura, com um único comando tablebi pin. O painel guarda a consulta, e não um retrato, então se atualiza conforme a fonte sincroniza.

Experimente

Consulte o Search Console do jeito que a API permite — e fixe o resultado ao vivo.

terminal

npm i -g @tablebi/cli && tablebi install

A interface e a documentação do TableBI estão em inglês; o agente de IA com que você opera o TableBI (o Claude Code, por exemplo) pode responder em português.

Ler o guia rápido (em inglês) Preços (em inglês) →