Mapeamento link-para-consulta do Search Console com relatório da API

O que você está tentando medir (e o que não está)

O mapeamento link-para-consulta do Search Console junta três coisas numa só vista: uma página específica, as consultas para as quais essa página aparece e as páginas de referência que começaram a linkar para ela.

O objetivo não é provar que um link causou um salto de ranking. O Google não marca impressões ou cliques com “isto aconteceu por causa do link X”, e os rankings mudam por muitos outros motivos (edições de conteúdo, links internos, sazonalidade, alterações de concorrentes e atualizações do Google). O timing também é confuso. Um link pode ir ao ar hoje e ser descoberto dias ou semanas depois.

Um objetivo prático é mais simples: conectar novas páginas de referência a mudanças nas impressões e na posição média para a URL exata, por consulta. Isso dá uma narrativa útil do tipo: “Esta página ganhou novos links, depois a visibilidade melhorou para estas consultas.” É correlação com cautelas, não prova judicial.

O que este relatório pode dizer

Usado com cuidado, um relatório da API do Google Search Console como este pode responder algumas questões de alto valor:

• Quais consultas para uma URL ganharam ou perderam impressões depois de novas páginas de referência aparecerem.
• Se a tendência da posição média dessa URL melhorou, ficou estável ou caiu na mesma janela.
• Quais páginas que linkaram recentemente se alinham com as maiores mudanças, para saber o que revisar primeiro.

O que este relatório não pode dizer

Este relatório não consegue de forma confiável:

• Atribuir crédito a um único link ou calcular um “valor do link” exato por consulta.
• Separar o impacto do link de outros trabalhos de SEO sem controlos adicionais.
• Garantir que o Google contabilizou ou confiou num link só porque ele existe.

Exemplo: a sua página de preços ganha dois novos links a partir de artigos do setor. Nas próximas 2 semanas, as impressões sobem para “product pricing” e “enterprise pricing”, enquanto “free trial pricing” fica estável. Isso não prova que os links causaram o aumento, mas mostra que a página começou a aparecer com mais frequência para certas pesquisas depois de novas páginas de referência aparecerem.

Se você usa um serviço de placements como SEOBoosty (seoboosty.com) para apontar backlinks premium a uma página específica, este mapeamento também é um cheque de sanidade. Mantém o foco em saber se a visibilidade por consulta dessa URL se moveu, em vez de confiar em médias do site todo.

Os dados que você vai combinar do Search Console

Você precisa de duas vistas diferentes do Search Console. Uma mostra o que aconteceu na pesquisa (impressões, cliques, posição). A outra mostra quais páginas na web linkam para você.

1) Dados de Performance (o que mudou na pesquisa)

Isto vem do relatório Performance no Search Console (via o endpoint Search Analytics na API). É a forma mais clara de medir resultados como impressões e posição média.

Puxe métricas como cliques, impressões, CTR e posição média, e agrupe por dimensões que expliquem o que mudou. Para este relatório, as dimensões mais úteis são page, query e date. País e dispositivo podem ajudar se você tiver mercados mistos ou diferenças fortes entre mobile e desktop.

Uma regra prática: inclua sempre page. Adicione query quando quiser saber quais buscas mudaram, não apenas se a página mudou.

2) Dados de Links (o que mudou fora do seu site)

Isto vem do relatório Links no Search Console (via os endpoints de links). É onde você encontra as páginas de referência que apontam para o seu site.

Para o mapeamento link-para-consulta, os campos que interessam são:

• target page (qual das suas URLs o link aponta)
• linking page (a página externa específica que linka)
• linking site (o domínio, útil para rollups)

Os dados de links não dizem qual consulta um link impactou. Diz apenas que o link existe para uma dada página-alvo. Qualquer “atribuição” no seu relatório baseia-se no timing e na URL afetada, não numa causa provada.

Porque você precisa de janelas “antes” e “depois”

Links e rankings não mudam no mesmo dia, e os dados do Search Console não são perfeitamente em tempo real. Olhar para uma só data cria ruído.

Use duas janelas de tempo iguais para os dados de performance:

• uma janela “antes” para estabelecer uma linha de base
• uma janela “depois” para medir a mudança

Depois alinhe as novas páginas de referência pela primeira vez que as viu (ou a data mais antiga que pode atribuir), e compare performance antes vs depois.

Se só guardar um modelo mental: Performance explica o movimento; Links sugerem o que pode tê-lo desencadeado. Combiná-los por URL é o objetivo principal.

Defina escopo, janelas e regras para “novos links”

Este relatório só funciona se você bloquear o escopo antes de começar. Se mudar o conjunto de URLs ou as janelas de tempo a meio, os resultados vão oscilar por razões que nada têm a ver com links.

Comece com o conjunto de URLs alvo e mantenha-o: uma página importante, uma pasta ou um pequeno conjunto de templates (como páginas de produto). Quanto mais restrito o conjunto, mais fácil é conectar novas páginas de referência a mudanças em impressões e posição média.

A seguir, escolha duas janelas de igual duração. Para muitos sites, 28 dias vs os próximos 28 dias é um bom padrão porque suaviza a variação diária.

Agora defina “novo”. Uma regra simples: uma página de referência é “nova” se teve zero links registados para o conjunto de URLs alvo antes da janela de comparação, e pelo menos um link registado durante a janela de comparação. Se a sua fonte de links atualiza lentamente, acrescente um pequeno buffer, por exemplo excluindo os primeiros dias da janela de comparação da detecção de “novo link”.

Para reduzir ruído, defina limiares mínimos antes de calcular mudanças. Caso contrário, uma impressão aleatória pode parecer um “salto de ranking”. Por exemplo:

• Inclua apenas URLs alvo com pelo menos X impressões em ambas as janelas (exemplo: 100)
• Inclua apenas consultas com pelo menos Y impressões em ambas as janelas (exemplo: 10)
• Requerer pelo menos Z dias ativos com impressões por janela (exemplo: 10 dias)
• Ignore mudanças de posição quando as impressões forem demasiado baixas para serem estáveis

Exemplo: na baseline de 28 dias, a sua página de preços tem 1.200 impressões a uma posição média de 11.2. Nos próximos 28 dias tem 1.650 impressões a 9.8. As suas regras ajudam a tratar isso como significativo, enquanto ignoram páginas onde as impressões passaram de 3 para 9.

Se estiver a rastrear placements de um fornecedor (incluindo placements pagos), trate cada página de referência como o seu próprio evento “nova página de referência”. Isso permite comparar resultados entre fontes sem agrupar múltiplas mudanças.

Desenhe um modelo de dados simples para o relatório

Mantenha o modelo de dados simples. Três tabelas mais regras partilhadas para URLs e datas são suficientes. Se as chaves forem consistentes, o relatório torna-se joins e comparações diretas.

1) Tabela de URLs alvo (as páginas que lhe interessam)

Este é o seu catálogo de páginas. Evita duplicados quando a mesma página aparece com parâmetros, maiúsculas mistas ou barras finais.

Guarde:

• target_url_canonical: a URL canónica que reporta
• target_url_normalized: chave normalizada para join (ver regras abaixo)
• page_type: categoria, produto, blog, docs, etc.
• notes: opcional, como “página de alto valor” ou “recentemente atualizada”

2) Tabela de páginas de referência (os novos links)

Isto é o input “o que mudou”. Cada linha é uma página de referência que aponta para uma das suas URLs alvo.

Guarde:

• referring_url: página exata que linka para si
• referring_url_normalized: normalizada para deduplicação
• referring_domain: domínio extraído (para agrupar)
• target_url_normalized: join de volta à URL alvo
• first_seen_date: primeira data em que observou o link (ou a data reportada pelo seu fornecedor)

Se uma página de referência linka para duas URLs alvo, mantenha duas linhas. O mapeamento precisa de permanecer explícito.

3) Tabela de Performance (saída do Search Console)

Mantenha os dados de performance no nível mais baixo útil para poder agregá-los depois.

Guarde:

• date
• target_url_normalized
• query
• impressions
• clicks (opcional mas geralmente vale a pena guardar)
• position (posição média do Search Console)

Evite pré-agregar demasiado cedo. Pode sempre somar impressões mais tarde, mas não recupera o detalhe a nível de query uma vez colapsado.

Estratégia de chaves para joins (regras que mantêm tudo consistente)

Escolha regras uma vez e aplique em todos os locais:

• URL Normalizada: torne o host em minúsculas, remova fragments e padronize barras finais. Decida como tratar parâmetros (frequentemente: remover parâmetros de tracking, manter os significativos).
• Extração de domínio: guarde o domínio registável ou pelo menos o host para agrupar por domínio.
• Buckets de data: crie um campo date_bucket como semana (YYYY-WW) ou mês (YYYY-MM) para tornar as comparações mais estáveis do que gráficos diários.

Com estas três tabelas e chaves consistentes, o relatório final é: novas páginas de referência (por first-seen date) unidas às mudanças de performance (por URL, query e bucket de data).

Passo a passo: puxar os dados com a API do Search Console

Comece com dados de performance em que confia, depois adicione novas páginas de referência de uma fonte separada. A API padrão do Search Console foi construída para reporting de performance, não para uma exportação completa do relatório Links.

1) Obtenha acesso à propriedade certa

Puxe dados da mesma propriedade que a sua equipa usa no Search Console (Domain property vs URL-prefix property). Usar a errada faz com que links ou rankings pareçam ter “desaparecido” quando na verdade está a olhar para outro conjunto de dados.

Antes de correr qualquer coisa, confirme:

• a sua conta Google tem permissão na propriedade (Owner ou Full user)
• a API do Search Console está ativada no projeto do Google Cloud
• consegue listar o site na API (cheque de sanidade rápido)

2) Puxe performance por página + query (diário se possível)

Use o método Search Analytics query. Escolha um intervalo de datas e peça dimensões que permitam ligar mudanças a uma URL e termo de busca específicos.

Um ponto de partida prático:

• Dimensões: date, page, query
• Métricas: clicks, impressions, position
• Filtros opcionais: país/dispositivo fixos se o seu site variar muito

Adicionar dimensões aumenta o número de linhas. Planeie paginar usando startRow até atingir o fim.

Aqui está um corpo de pedido mínimo (apenas shape) que pode reutilizar no seu script:

{
  "startDate": "2026-01-01",
  "endDate": "2026-01-31",
  "dimensions": ["date", "page", "query"],
  "rowLimit": 25000,
  "startRow": 0
}

3) Obtenha dados de “novas páginas de referência” (o que é possível)

O relatório Links do Search Console é útil na UI, mas o Google não expõe o mesmo dataset "top linking pages -> target page" através da API padrão do Search Console.

Se precisar das URLs de páginas de referência, normalmente tem duas opções:

• Exportar o relatório Links da UI do Search Console numa agenda e ingerir esse ficheiro.
• Usar uma fonte de backlinks separada e casar as páginas de referência com as URLs alvo.

De qualquer forma, mantenha a URL bruta da página de referência, a URL da página alvo e uma data de first-seen (ou data de exportação) para depois classificar o que é “novo”.

4) Guarde as respostas brutas antes de transformar

Salve cada resposta da API (e os parâmetros de pedido que a geraram) como ficheiros JSON brutos ou linhas numa tabela raw. Reexecutar fica mais fácil quando ajusta regras de matching, janelas de data ou filtros. Também ajuda quando alguém pergunta por que a posição média de uma URL mudou e precisa mostrar o que a API retornou.

Passo a passo: limpar, casar e calcular mudanças

Este relatório vive ou morre pela capacidade de casar a mesma URL entre datasets. Se as URLs não se juntarem bem, o “impacto” torna-se aleatório.

1) Normalize URLs para que as linhas realmente se juntem

Escolha uma forma canónica para cada URL de página alvo, depois aplique as mesmas regras em todo o lado (Search Console pages, a sua lista de backlinks e a saída).

Correções comuns:

• Use um protocolo e host uniformes (por exemplo, sempre https e o host preferido).
• Padronize barras finais para que /page e /page/ não se dividam.
• Remova parâmetros de tracking (utm_*, gclid, fbclid) e mantenha apenas parâmetros que alteram o conteúdo.
• Trate duplicados óbvios como index.html.

Depois da normalização, crie uma chave estável (normalized_url) e una a sua tabela de páginas de referência com os dados de performance do Search Console por essa chave.

2) Casar consultas sem transformar isto num projecto de taxonomia

Agrupar queries deve responder a uma pergunta: a visibilidade cresceu principalmente para procura com marca, descoberta não marcada, ou ambos?

Mantenha leve. Dois tags por query costumam ser suficientes: brand vs non-brand, mais um bucket de intenção simples (informacional, comercial, navegacional). Use regras curtas e editáveis. Por exemplo, brand é "query contém marca ou nome do produto", navegacional inclui "login" ou "pricing", e o resto é informacional ou comercial com base numa pequena lista de palavras-chave.

3) Calcule deltas e alinhe ao “first seen”

Para cada página de referência, guarde link_first_seen como a data mais antiga em que a observou apontando para a URL alvo. Depois alinhe essa data às suas janelas.

Uma regra simples:

• before_window = 28 dias terminando no dia antes de link_first_seen
• after_window = 28 dias começando em link_first_seen

Calcule mudanças ao nível (target URL, grupo de query) e depois agregue ao nível da URL. Mantenha as métricas legíveis:

• Impressions delta = impressions_after - impressions_before
• Position delta = avg_position_after - avg_position_before (negativo é melhor)
• Visibility score = impressions * (1 / avg_position) ou outra ponderação simples que use de forma consistente
• Contribution share = URL delta dividido pelo delta do site para o mesmo período

Exemplo: um post de blog ganha um novo referrer visto pela primeira vez a 10 de Maio. Nos 28 dias antes teve 1.000 impressões a posição 14. Nos 28 dias depois teve 1.450 impressões a posição 11. O seu relatório mostra +450 impressões e -3 posições, e pode ver se o ganho veio de queries informacionais não-branded ou de um aumento brand.

Se estiver a rastrear placements de um fornecedor como SEOBoosty, armazene também o mesmo campo link_first_seen para essas colocações para que as suas janelas sejam comparáveis entre fontes.

Construa as vistas do relatório que as pessoas realmente leem

Um bom relatório link-para-consulta não é uma folha de cálculo com dezenas de separadores. É um pequeno conjunto de vistas que respondem a uma pergunta rapidamente: “O que mudou depois desta página ganhar novos links, e confiamos no sinal?”

Vista 1: resumo de impacto por URL (a vista que abre primeiro)

Comece com uma linha por URL alvo. Mantenha legível e faça “novas páginas de referência” parecerem concretas.

Inclua:

• Target URL
• Contagem de novas páginas de referência (na janela de links)
• First seen date (data mais antiga de nova ref page)
• Impressions delta (antes vs depois)
• Avg position delta (antes vs depois)

Adicione uma célula compacta “New referring pages” com 2–3 exemplos (domínio + first seen), com a lista completa disponível via drilldown ou filtro. Aqui os leitores rapidamente checam se os links parecem reais ou são ruído.

Vista 2: impacto por query para uma URL (a vista do “porquê”)

Quando alguém clica numa URL, mostre as consultas que moveram. Limite aos maiores movers.

Um layout prático:

Ordene pelas maiores subidas de impressões primeiro, depois adicione um filtro para quedas. Mantenha uma coluna “Note” para contexto rápido como “brand query” ou “apareceu um SERP feature”.

Colunas de contexto que evitam decisões erradas

Se detalhar por dispositivo, país ou tipo de pesquisa, deixe isso óbvio na UI para que os leitores não misturem maçãs com laranjas. Um cabeçalho simples como “Device: Mobile” funciona.

Adicione um campo curto de confiança manual por URL: “High” (elevação clara em várias queries), “Medium” (elevação mas principalmente numa query), “Low” (timing conflita com mudança no site).

Um exemplo realista (sem matemática complicada)

Foque numa URL por uma semana, depois compare com uma semana similar antes dos links aparecerem.

Cenário

Você publica um post no blog: /blog/on-page-checklist. Na semana de 6 a 12 de Maio, os seus registos de fontes de links mostram três novas páginas de referência que apontam para essa URL. Duas são artigos relevantes e uma é uma lista de recursos geral.

Defina duas janelas:

• Before window: 29 Abr a 5 Mai
• After window: 6 Mai a 12 Mai

Agora puxe métricas a nível de query para essa URL no Search Console para ambas as janelas e calcule deltas.

Como os números podem parecer

Para a query “on page checklist”, as impressões saltam de 1.200 para 2.100 (+900), mas a posição média mantém-se parecida (8.4 para 8.3). Isso normalmente significa que está a ser mostrado mais vezes, mas ainda não a ranquear mais alto. Razões comuns incluem elegibilidade mais ampla (mais variantes long-tail) ou maior procura.

Para a query “on page seo steps”, as impressões ficam estáveis (300 para 310), mas a posição melhora (14.2 para 10.8). Isso pode ocorrer quando a confiança melhora para um conjunto mais restrito de buscas, mesmo que a procura não mude muito.

O importante é que o relatório liga a data de first-seen de cada nova página de referência à janela de comparação e mantém resultados separados por URL (não misturados por todo o site).

Como resumir isso numa atualização semanal

Mantenha curto e orientado a decisões:

• O que mudou: 3 novas páginas de referência para /blog/on-page-checklist (6–12 Mai)
• O que se moveu: +900 impressões na query principal; melhoria de posição numa query secundária
• O que provavelmente significa: visibilidade cresceu primeiro; rankings podem estar a começar a mudar para termos específicos
• O que vigiar: repetir a mesma comparação na próxima semana para ver se a posição acompanha

Se usar placements do SEOBoosty, este mesmo formato semanal é uma forma limpa de reportar o que aconteceu após cada lote sem afirmar que os links causaram todas as mudanças.

Armadilhas comuns que tornam o relatório enganador

Este relatório é útil, mas é fácil enganar-se. O maior risco é transformar correlação numa história só porque o gráfico é arrumado.

Armadilha 1: “O link apareceu, rankings mudaram, logo o link fez isso”

Alinhamento de datas não é prova. Dados do Search Console podem atrasar, links são descobertos devagar, e o Google pode reprocessar sinais mais tarde. Um link pode ser encontrado numa segunda-feira, reportado na quinta e ter qualquer efeito (se tiver) depois disso.

Trate o link como uma explicação candidata. O relatório deve mostrar o que mudou, não o que causou.

Armadilha 2: Dividir uma página em muitas “URLs”

Se misturar variantes de URL, divide o sinal e as mudanças antes vs depois ficam ruidosas. Culpados comuns: http vs https, www vs non-www, barra final, maiúsculas, parâmetros e páginas canonicalizadas.

Escolha uma regra de normalização e cumpra-a. Caso contrário pode culpar uma queda de posição em “novas páginas de referência” quando metade das impressões está numa URL com parâmetros.

Armadilha 3: Janelas de comparação desiguais

Comparar 7 dias antes com 28 dias depois (ou misturar dias de semana com fins de semana) cria subidas e descidas falsas. Muitos sites têm padrões fortes por dia da semana.

Se precisar usar janelas curtas, mantenha-as simétricas e alinhadas por dia da semana. Para tópicos sazonais, adicione notas de contexto (lançamentos, feriados, menções em PR) ao lado dos números.

Armadilha 4: Tratar a posição média como uma verdade única

A posição média pode mudar só porque a mistura de impressões mudou. Se uma página começa a aparecer para uma nova query na posição 35 com muitas impressões, a posição média piora mesmo que a sua query principal tenha melhorado.

Verifique a distribuição: as impressões moveram-se para posições mais altas ou mais baixas? Uma nova query dominou o período depois?

Armadilha 5: Ignorar indexação e mudanças on-page

Um relatório de “impacto de links” desmorona quando a própria página mudou. Reescritas de título, links internos, atualizações de template, edições de conteúdo e problemas de indexação podem todos mover impressões e posição.

Antes de creditar um backlink, confirme que a página estava estável e indexável.

Guardrails que mantêm o relatório honesto:

• Use janelas de igual duração (e combine dias da semana) para cada comparação.
• Normalize URLs e agrupe variantes de query quando fizer sentido.
• Marque períodos com atualizações de conteúdo, redirects ou avisos de indexação.
• Reveja os movers a nível de query, não apenas as médias da página.
• Trate “novas páginas de referência” como ponto de partida e depois verifique com outros sinais.

Cheques rápidos e próximos passos

Antes de confiar em qualquer gráfico, verifique os inputs. O mapeamento link-para-consulta pode parecer convincente mesmo quando URL, link ou dados de query estão desencontrados.

Cheques rápidos (5 minutos)

• Confirme que a URL alvo é consistente: canónica como espera, indexável e não bloqueada por noindex, robots ou canonical errado.
• Valide que as “novas páginas de referência” são reais: a página existe, não está atrás de login e realmente linka para a sua página (não só para o domínio).
• Certifique-se que o link aponta para a versão correta da URL: http vs https, www vs non-www, barra final, parâmetros e redirects podem dividir o sinal.
• Verifique o tamanho da amostra antes de confiar em mudanças de posição. Baixas impressões fazem a posição média oscilar muito.
• Percorra a mesma janela em busca de outras mudanças: edições de título, atualizações de template, redirects, alterações de links internos, lançamentos de PR ou variações sazonais.

Exemplo: vê uma nova página de referência e a posição média para uma query melhora de 14 para 9. Se a página teve só 30 impressões antes e 40 depois, esse salto pode ser ruído. Se teve 5.000 e 6.000 impressões, é mais provável que seja real.

Próximos passos que mantêm o relatório útil

Consistência importa mais do que fórmulas sofisticadas.

• Monitore semanalmente usando as mesmas janelas e regras.
• Adicione anotações para quedas de links e grandes mudanças no site.
• Marque páginas de “alta confiança”: URL estável, volume forte de impressões e uma nova página de referência clara que linka diretamente.
• Verifique novamente depois de 2 a 4 semanas. Links e rankings raramente mudam em sincronia, e os dados do Search Console podem atrasar.

Se quiser testes antes-e-depois mais limpos para URLs específicas, placements controlados ajudam porque pode registar alvos e datas exactas. Por exemplo, SEOBoosty (seoboosty.com) oferece acesso por subscrição a placements de backlinks curados, o que pode facilitar comparar resultados entre eventos de links semelhantes.

Mantenha os cheques leves e regulares. O relatório permanece legível e passa-se menos tempo a discutir casos limite.