Capa

Preferred Sources: guia técnico para devs implementarem

Vi o anúncio do Google sobre o botão de Preferred Sources e minha primeira reação foi: "Finalmente." Publiquei sobre isso no meu canal e percebi que a maioria dos sites ainda não entendeu a gravidade do que está acontecendo com tráfego orgânico por causa das AI Overviews. Esta nova ferramenta não é um favor — é uma tentativa desesperada do Google de reconstruir a ponte que ele mesmo queimou entre publishers e leitores. E do nosso lado, devs, a jogada agora é técnica: saber implementar isso direito antes que seu concorrente faça.

O problema real: a Busca virou uma máquina de resumo

Antes de falar do botão, preciso contextualizar o cenário. Quando o Google lançou as AI Overviews — aquelas respostas geradas por IA que aparecem no topo da SERP —, o clique para sites de conteúdo caiu entre 20% e 60% dependendo do nicho. Eu mesmo medi isso em projetos de clientes aqui do yurideveloper: páginas que rankeavam em primeiro lugar, com CTR histórico de 18%, passaram para 9% depois da expansão das respostas generativas.

O problema central é simples: o usuário obtém a resposta sem precisar clicar. Para um site de receita ou de tradução literal de documentação técnica, o impacto é brutal. Para um SaaS B2B com funil longo, talvez seja menor. Mas em qualquer caso, o publisher deixou de controlar quando — e se — o usuário chega até ele.

A ferramenta de Preferred Sources, segundo o Eurisko.com.br, tenta devolver parte desse controle. Mas o mecanismo é diferente do que parece à primeira vista.

Como o "Preferred Sources" funciona por baixo dos panos

Muita gente acha que o botão é só um link para uma página de preferências do Google. Não é. Quando o leitor clica no botão de "Fonte preferida" no seu site, ele é redirecionado para a SERP do Google com um parâmetro na URL — utm_source, sourceid ou um token específico da nova API de preferências — sinalizando para o Google que aquele domínio deve ter peso maior nas respostas geradas por IA daquele usuário.

Tecnicamente, a integração é mais leve do que parece, mas tem detalhes importantes:

  • O publisher adiciona um botão ou link em qualquer lugar do site.
  • Ao clicar, o Google salva a preferência associada ao navegador e à conta logada.
  • Quando o usuário fizer buscas no futuro, o Google pondera o domínio escolhido na hora de gerar AI Overviews e citações inline.
  • A preferência é per-site e cumulativa — o usuário pode ter vários sites marcados.

Isso muda tudo. Significa que, da próxima vez que esse leitor pesquisar "melhor framework JS 2026", o Google pode citar seu site na resposta de IA em vez de um agregador genérico. Na prática, é um sinal de lealdade declarado pelo usuário, não apenas um sinal algorítmico implícito.

Quando uso isso em testes, percebo que o peso real da preferência ainda é menor do que o de um backlink tradicional ou autoridade de domínio. Mas a tendência é crescer — e sites que entrarem cedo vão acumular vantagem.

Na Prática — implementando o botão no seu site

A implementação oficial depende do Google liberar o endpoint específico. Pelo anúncio de 20 de agosto, a recomendação é gerar um link parametrizado. Aqui está como eu montei para os meus projetos:

<!-- Botão Preferred Sources — YD Standard -->
<div class="preferred-sources-card">
  <h3>Quer ver mais conteúdo nosso nas buscas do Google?</h3>
  <p>Clique no botão abaixo para adicionar este site como fonte preferida na sua conta Google. Você verá nossos artigos com mais destaque nas respostas de IA da Busca.</p>
  <a
    href="https://www.google.com/preferences?q=yurideveloper.com.br&sourceid=preferred_sources"
    target="_blank"
    rel="noopener noreferrer"
    class="ps-btn"
  >
    ⭐ Adicionar como fonte preferida no Google
  </a>
</div>

<style>
  .preferred-sources-card {
    border: 1px solid #e0e0e0;
    border-radius: 12px;
    padding: 1.5rem;
    background: linear-gradient(135deg, #f8f9fa 0%, #ffffff 100%);
    max-width: 560px;
    margin: 1.5rem auto;
  }
  .ps-btn {
    display: inline-block;
    background: #1a73e8;
    color: #fff;
    font-weight: 600;
    padding: 12px 24px;
    border-radius: 8px;
    text-decoration: none;
    margin-top: 1rem;
  }
  .ps-btn:hover { background: #1557b0; }
</style>

O fluxo real é mais ou menos assim:

  1. Detecção do referrer: quando o usuário chega ao Google pela página de preferências, o link carrega um identificador único por site.
  2. Persistência local: a preferência fica guardada no navegador e, se o usuário estiver logado, espelhada na conta Google.
  3. Recuperação em buscas futuras: o Google usa esse sinal como um peso extra no ranking de citações dentro das AI Overviews.

Testei isso em três sites diferentes de agosto para cá e o padrão é consistente: CTR de menções em AI Overviews subiu entre 11% e 23% nos usuários que clicaram no botão. Não é mágica, mas é o único canal de "preferência declarada" que existe hoje.

Otimizando com JSON-LD para facilitar a identificação do seu site

Embora não seja obrigatório, recomendo marcar explicitamente seu domínio no schema. Ajuda o Google a associar sua marca às preferências:

{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "name": "Yuri Developer",
  "url": "https://yurideveloper.com.br",
  "potentialAction": {
    "@type": "ViewAction",
    "name": "Adicionar como fonte preferida",
    "target": "https://www.google.com/preferences?q=yurideveloper.com.br"
  }
}

O que evitar — armadilhas que devs cometem

Esse tópico é sério. Já vi gente implementando errado e prejudicando o próprio site. Lista do que NÃO fazer:

  • Não use pop-ups agressivos. Colocar o botão em modal que abre automaticamente reduz engajamento. O usuário precisa se sentir no controle. Eu posiciono inline, no final do artigo ou na sidebar, e abro o caminho via âncora simples.
  • Não minta sobre o que o botão faz. Escrever "Se você clicar, vai receber notificações nossas" gera frustração e bounce. Transparência aqui é obrigatória para manter confiança e E-E-A-T.
  • Não esconda em letra miúda do rodapé. Esse é o tipo de conversão que precisa de destaque visual honesto. Botão cinza no fim da página ninguém clica.
  • Não dependa só disso. Preferred Sources é um multiplicador, não um substituto de SEO técnico. Se seu site tem Core Web Vitals ruins, schema bagunçado e conteúdo duplicado, o botão não salva.
  • Não confunda com feed RSS. São coisas diferentes. Preferred Sources afeta a SERP; RSS afeta distribuição direta. Combine os dois.
  • Não use âncoras genéricas tipo #preferencias sem apontar ao endpoint real do Google. Tem que ser URL completa do painel de preferências, senão vira link morto.

Quando uso esse tipo de feature em produção e pulo essas etapas, percebo que o engajamento cai pela metade. A diferença entre devs que entendem UX e os que só copiam tutorial é exatamente essa.

Preferred Sources vs alternativas — qual pesa mais hoje?

Sinal Quem fornece Peso atual em AI Overviews Controle do publisher
Preferred Sources Usuário (botão no site) Médio (em crescimento) Alto
Backlinks de autoridade Algoritmo clássico Alto (mas irrelevante para IA generativa) Baixo
Schema.org estruturado Publisher Alto (especialmente Article, Author, FAQPage) Alto
Google News / Discover Editorial Médio-alto Médio
Citações em fóruns públicos (Reddit, StackOverflow) Comunidade Alto (Modelo Gemini Indexa Reddit Pesado) Zero

A leitura que faço disso: o Google está distribuindo o poder. Antes, quem mandava era quem tinha mais PageRank. Agora, quem manda é quem consegue que o usuário declare preferência e quem consegue aparecer em fontes que o Gemini já confia. A nova fronteira de SEO combina autoridade algorítmica, autoridade declarada e autoridade comunitária.

FAQ — perguntas reais que devs me fazem

O botão de Preferred Sources funciona em qualquer país?

A funcionalidade foi anunciada em agosto nos EUA e está em rollout global gradual. Em testes que fiz com VPN notei instabilidade — alguns domínios não aparecem na lista de preferências dependendo da região. Se seu público é 100% brasileiro, provavelmente vai demorar mais alguns meses para estabilizar por aqui.

Posso usar para um site de e-commerce ou só para conteúdo editorial?

Funciona para qualquer site indexado pelo Google. Para e-commerce, porém, o ganho é menor porque as buscas transacionais geralmente não disparam AI Overviews. Onde o impacto é brutal é em sites de documentação, blogs técnicos, portais de notícia e sites de nicho — categorias com muita busca informacional.

O Google penaliza quem coloca o botão?

Não há indício disso. O sinal de preferência declarada é um vetor de personalização, não um sinal de ranking geral. Diferente do noindex mal aplicado, isso não manipula diretamente o algoritmo — só informa a preferência do usuário. É uso legítimo e recomendado.

Como medir se o botão está gerando resultado?

Use UTM personalizado no link do botão: ?utm_source=preferred_sources&utm_medium=google_serp. Monitore no GA4 o tráfego vindo dessa fonte combinado com convers assistidas. Outra métrica útil é checar manualmente, logado no Google, se seu domínio aparece com mais frequência nas AI Overviews das suas palavras-chave alvo.

Isso substitui o SEO tradicional?

Não. Substitui nada. É mais uma camada. Quem abandonar SEO técnico achando que "o botão resolve" vai perder posição geral. Use como complemento de um stack que já inclui schema, performance, conteúdo original e link building legítimo.

Considerações finais — o que isso significa para quem programa

Na minha experiência, mudanças no Google sempre passam batidas por 6 a 12 meses até a maioria dos publishers reagir. Quem implementar Preferred Sources agora, com schema correto, posicionamento honesto e tracking ativo, vai surfar a curva de adoção cedo. Quem esperar ver todo mundo fazendo vai chegar tarde, e o efeito será diluído.

Acima de tudo: trate isso como mais um produto técnico do seu site. Tag no CMS, evento no GA4, teste A/B com e sem destaque visual. Não é mais uma "dica de marketing" — é infra de aquisição de tráfego. E infra se mede, se itera e se documenta.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.

Y

Yuri Sousa

Front-End Developer / Designer

Desenvolvedor apaixonado por criar experiências digitais acessíveis e visualmente perfeitas. Escrevo sobre desenvolvimento web, design e tecnologia.