# Fatores de ranqueamento do Google e o que os vazamentos mostram

URL: https://lucasferraz.com/blog/fatores-de-ranqueamento-do-google/
Autor: Lucas Ferraz
Publicado em: 2026-09-27
Revisado em: 2026-11-02

Os vazamentos do Google (documentação da Content Warehouse API, 2024) e do Yandex (código, 2023) provam que certos dados existem, não o peso de cada um. Dos 14.031 atributos do pacote original do Google, conferido em setembro de 2026, só 5 dizem na descrição que são aplicados no ranqueamento. O resto é hipótese sobre os fatores de ranqueamento do Google.

## Principais pontos

- A versão 0.4.0 do pacote google_api_content_warehouse, publicada no hex.pm em 28 de março de 2024, tem 2.596 arquivos e 14.031 atributos declarados, pela minha contagem de setembro de 2026;
- Só 5 desses atributos dizem na própria descrição que são aplicados no componente Qstar do ranqueamento, entre eles o siteAuthority;
- A versão 0.5.0 do pacote, publicada em 7 de maio de 2024, caiu para 177 arquivos, sem siteAuthority e sem os módulos do NavBoost;
- A decisão de 5 de agosto de 2024 no processo Estados Unidos contra Google registra que o NavBoost memoriza dados de clique, com 13 meses de dados desde 2017;
- No arquivo de 1.923 fatores do vazamento do Yandex, 1.228 (63,9%) estão marcados como depreciados ou não usados, inclusive o fator de PageRank;
- A Sistrix chegou a 417 fatores ativos do Yandex subtraindo a soma de quatro etiquetas de desuso, e contando cada fator uma vez nessas quatro etiquetas sobram 599 de 1.923;
- Nas 12 rodadas que fiz em 27 de setembro de 2026 no ChatGPT, Gemini, Perplexity e Claude, três respostas afirmaram uso de atributos que a documentação só descreve.

## Quais são os fatores de ranqueamento do Google?

**Os fatores de ranqueamento do Google não têm lista pública nem peso divulgado pelo próprio Google.** O que existe de oficial é o [guia dos sistemas de ranqueamento da Busca](https://developers.google.com/search/docs/appearance/ranking-systems-guide), que descreve sistemas como os de frescor, de conteúdo original e de reviews sem dizer quanto cada um pesa. O que existe de vazado é a documentação de atributos de 2024, que lista dados guardados, não fatores com peso.

Os grupos de sinal que dá para discutir com fonte são seis, e cada um tem seção própria adiante. São os cliques e o NavBoost, com confirmação judicial, a autoridade do site, o foco tópico, as datas e o frescor, os rebaixamentos de qualidade e o autor como entidade. As listas de "200 fatores" que dominam esta busca são compilações de terceiros. O número ecoa a [página de tecnologia do Google em 2009](https://web.archive.org/web/20091229190850/http://www.google.com/corporate/tech.html), que falava em "more than 200 signals" sem dizer quais, e as listas costumam enumerar itens sem fonte para cada um nem peso.

## O que vazou do Google em 2024 e do Yandex em 2023?

**O vazamento do Google foi documentação de API, e o do Yandex foi código-fonte.** Essa diferença decide o que cada um consegue provar. Documentação lista os campos que um sistema guarda e descreve alguns deles. Código mostra como um fator é calculado e, às vezes, com que peso entra em uma fórmula.

O material do Google é a referência de um pacote de biblioteca chamado google_api_content_warehouse, publicado no repositório público de clientes de API do Google no GitHub e indexado pelo hex.pm, onde continua disponível. Em 29 de maio de 2024, a autenticidade foi confirmada por um porta-voz do Google em resposta ao The Verge, e um alerta contra suposições feitas a partir de dados "fora de contexto, desatualizados ou incompletos" (tradução minha). O material do Yandex veio a público em janeiro de 2023, e a empresa declarou que o conteúdo correspondia a uma versão desatualizada do repositório, diferente da usada nos serviços, segundo a cobertura do Search Engine Journal.

| Vazamento | Quando veio a público | O que é o material | O que a empresa declarou |
|---|---|---|---|
| Google | maio de 2024 | Referência de API gerada das definições internas, com descrição de cada campo | Documentos autênticos, com risco de estarem fora de contexto, desatualizados ou incompletos (The Verge, 29/05/2024) |
| Yandex | janeiro de 2023 | Código-fonte, incluindo arquivos com a lista de fatores e etiquetas de uso | Versão desatualizada do repositório, diferente da usada nos serviços (Search Engine Journal, 2023) |

### A contagem que refiz no pacote original

**Baixei o pacote do Google direto do hex.pm, o repositório de bibliotecas de onde ele foi indexado, e contei eu mesmo.** O número que circula desde 2024 é de 2.596 módulos e 14.014 atributos. Na versão 0.4.0, publicada em 28 de março de 2024 e usada como referência nas primeiras análises, encontrei 2.596 arquivos de código, 2.593 deles módulos de dados, e 14.031 atributos declarados. A diferença de 17 atributos provavelmente vem do critério de contagem, e não muda nada de substância.

O histórico de versões do pacote conta a retirada melhor do que qualquer relato.

| Versão | Publicada no hex.pm | Arquivos | Atributos declarados | siteAuthority e NavBoost |
|---|---|---|---|---|
| 0.2.0 | 15/03/2024 | 2.590 | 14.062 | presentes |
| 0.3.0 | 17/03/2024 | 2.590 | 14.062 | presentes |
| 0.4.0 | 28/03/2024 | 2.596 | 14.031 | presentes |
| 0.5.0 | 07/05/2024 | 177 | 594 | ausentes |
| 0.6.1 | 06/12/2024 | 191 | 630 | ausentes |

A queda de 2.596 para 177 arquivos em 7 de maio de 2024 é a remoção do material da Busca. O pacote seguiu existindo com o que parece ser só a API pública de documentos. As versões antigas continuam baixáveis, e qualquer pessoa pode refazer essa contagem.

Um detalhe da mesma contagem ajuda a calibrar a leitura. Os três prefixos com mais módulos são assistant (303, do Assistente), google (205) e geostore (203, dados de mapa). O prefixo quality, onde mora a maior parte dos sinais de qualidade da Busca, tem 147 módulos. Boa parte do pacote descreve outros produtos, e isso sozinho desmonta a ideia de "14 mil fatores de ranqueamento".

## Atributo documentado não é fator com peso

**Um atributo na documentação prova que o dado existe em algum sistema do Google, não que ele pesa na ordem dos resultados.** Entre existir e pesar há dois degraus que a documentação quase nunca sobe: ser usado no ranqueamento da Busca web, e ter um peso conhecido. A documentação não informa o peso de nenhum sinal na ordem final dos resultados. Alguns poucos atributos dizem onde são usados.

Procurei, na descrição de cada atributo, as expressões que indicam aplicação. O resultado define três níveis de evidência que uso no resto deste texto.

| Nível | O que a descrição diz | Quantos | Exemplos |
|---|---|---|---|
| A. Aplicação declarada | "applied in Qstar" ou "one of the web page quality qstar signals" | 5 | siteAuthority, lowQuality, serpDemotion, scamness, unauthoritativeScore |
| A. Aplicação declarada | usado em um twiddler, a etapa que reordena resultados já pontuados | alguns | hostAge, datesInfo (FreshnessTwiddler), spamtokensContentScore (SiteBoostTwiddler) |
| B. Só descrição | diz o que o dado é, sem dizer onde entra | a grande maioria | goodClicks, siteFocusScore, contentEffort, bylineDate |
| C. Depreciado ou vazio | cita depreciação, "no longer" ou campo não populado | 293 | unsquashedClicks ("not being populated for the current format") |

O nível A vale mais quando alguma fonte independente confirma, como uma decisão judicial ou o guia oficial do Google. O nível B é hipótese com nome técnico. Pelo menos três das 12 respostas que colhi nas IAs de chat em 27 de setembro de 2026 trataram atributos de nível B como uso comprovado, entre elas uma que descreveu o contentEffort como medida de tempo na página. A descrição original diz outra coisa, como mostro mais abaixo.

## Os achados cruzados com as frentes de SEO

**A tabela abaixo liga cada achado a uma frente de trabalho, ao nível de evidência e ao jeito como eu confiro a prática nos meus sites.** A coluna do Google mostra se o próprio Google descreve algo equivalente no guia público dos sistemas de ranqueamento, atualizado em dezembro de 2025.

| Frente | Atributo e módulo | O que a descrição original diz | Nível | O Google declara algo equivalente? | Como eu confiro |
|---|---|---|---|---|---|
| Comportamento depois do clique | goodClicks, badClicks, lastLongestClicks (QualityNavboostCraps) | lastLongestClicks é o número de cliques que foram o último e o mais longo em consultas relacionadas; goodClicks e badClicks não têm descrição | B, com confirmação judicial do NavBoost | Não no guia; sim no processo judicial | CTR por posição no Search Console e rolagem no Clarity |
| Dados do navegador | chromeInTotal (QualityNsrNsrData) | visualizações do Chrome no nível do site | B | Não | não há métrica equivalente acessível |
| Autoridade do site | siteAuthority (CompressedQualitySignals) | convertido de SiteAuthority, aplicado no Qstar | A | Sim, "sinais e classificadores do site inteiro também são usados" | impressões por tema no Search Console, não métrica de ferramenta |
| Âncoras | anchorMismatchDemotion (CompressedQualitySignals) | convertido de QualityBoost.mismatched | B | Não por nome | auditoria de âncora contra o conteúdo da página de destino |
| Domínio com a palavra-chave | exactMatchDomainDemotion (CompressedQualitySignals) | convertido de QualityBoost.emd | B | Sim, sistema de domínio de correspondência exata | não se aplica a domínio de marca |
| Foco tópico | siteFocusScore, siteRadius (QualityAuthorityTopicEmbeddingsVersionedItem) | quanto o site é focado em um tema; quanto os embeddings das páginas se afastam do embedding do site | B | Não | distância de cosseno de cada URL ao centro temático do site |
| Datas | bylineDate, syntacticDate, semanticDate | data exibida no snippet; data da URL ou do título; data estimada pelo conteúdo, âncoras e documentos relacionados | B | Sim, guia de datas de publicação | data visível, schema e sitemap iguais |
| Frescor | datesInfo (PerDocData) | usado no FreshnessTwiddler | A | Sim, sistemas de frescor | data e conteúdo atualizados juntos |
| Conteúdo original | OriginalContentScore (PerDocData) | só páginas com pouco conteúdo têm o campo | B | Sim, sistemas de conteúdo original | cobertura e ganho de informação da página |
| Esforço do conteúdo | contentEffort (QualityNsrPqData) | estimativa de esforço feita por LLM para páginas de artigo | B | Não por nome | o que a página tem que custou trabalho e outra não tem |
| Título e busca | titlematchScore (QualityNsrNsrData) | o quanto os títulos do site combinam com as consultas | B | Não por nome | consultas com impressão contra o title de cada URL |
| Idade do host | hostAge (PerDocData) | usado em twiddler para segurar spam novo no momento de servir | A | Não | curva de impressões dos primeiros meses de um domínio |
| Autor | isAuthor (RepositoryWebrefDetailedEntityScores) | a entidade é autora do documento; ajustado sobretudo para notícias | B | Não | Person com o mesmo @id em todas as páginas do autor |
| Demoções de qualidade | pandaDemotion, babyPandaV2Demotion, navDemotion, serpDemotion, productReviewPDemoteSite | codificações de Panda, rebaixamentos por navegação e por resultado, confiança de rebaixamento de review | serpDemotion A; demais B | Sim para Panda e reviews | auditoria dos padrões de página em cada demoção |
| Temas sensíveis | ymylHealthScore, ymylNewsScore, isElectionAuthority, isCovidLocalAuthority | classificadores de saúde e notícia; sinal de autoridade eleitoral e de covid local | B | Sim, sistemas de informação confiável | só relevante em saúde, notícia e eleição |
| Site pessoal pequeno | smallPersonalSite (QualityNsrNsrData) | pontuação de promoção de site pessoal pequeno | B | Não | não há medição direta |

Os dados da tabela estão no arquivo que gerei da contagem, com a descrição original em inglês de cada atributo, módulo e tipo.

## Sinais de clique e de navegador

**O NavBoost é o caso em que o vazamento deixa de estar sozinho.** A decisão de 5 de agosto de 2024 no processo Estados Unidos contra Google, no parágrafo 96, descreve o NavBoost como um sinal que liga consultas a documentos memorizando dados de clique dos usuários, com base no depoimento de Eric Lehman, que foi Distinguished Software Engineer do Google. Pelo depoimento de Pandu Nayak, vice-presidente de Busca do Google, citado no mesmo parágrafo, o Google treinava o NavBoost com 18 meses de dados até 2017 e passou a usar 13 meses depois disso. No parágrafo 102, também com base no depoimento de Lehman, a decisão registra que os sinais mais novos baseados em modelos de linguagem não substituíram o NavBoost no ranqueamento.

O vazamento completa com o nome dos campos. O módulo de cliques traz clicks, goodClicks, badClicks, lastLongestClicks, impressions e uma versão "squashed" e outra "unsquashed" dos mesmos sinais. Só o lastLongestClicks tem descrição, e goodClicks e badClicks não têm nenhuma. O que torna um clique bom ou ruim é inferência de quem analisa, não texto da documentação. O mesmo módulo fatia os dados por país, dispositivo e idioma, e os exemplos da própria descrição citam "BR" e "pt-BR".

O Chrome é outra história. O chromeInTotal, descrito como visualizações do Chrome no nível do site, está em um módulo de qualidade do site. A descrição não diz onde o valor é usado, então o Chrome fica no nível B. Afirmar que "dados do Chrome influenciam o ranqueamento", como uma das IAs fez nas rodadas, vai além do que o texto sustenta.

### Como eu confiro no meu site?

O sinal do NavBoost não é visível para ninguém de fora. O que dá para medir é a parte que antecede e sucede o clique. No Search Console, separo as consultas por faixa de posição e olho o CTR de cada faixa. No lucasferrazseo.com, de 27 de junho a 27 de setembro de 2026, as 200 consultas sem marca com mais impressões ficaram assim.

| Faixa de posição | Consultas | Impressões | Cliques | CTR |
|---|---|---|---|---|
| 1 a 3 | 8 | 665 | 57 | 8,57% |
| 4 a 10 | 42 | 4.765 | 105 | 2,20% |
| 11 a 20 | 29 | 3.128 | 5 | 0,16% |
| 21 em diante | 121 | 9.788 | 4 | 0,04% |

A leitura útil está nas exceções. Cinco consultas estavam entre as dez primeiras posições, com 100 impressões ou mais, e zero clique. Para o NavBoost, uma consulta sem clique não gera nem clique bom nem clique ruim. Essas são as primeiras que reviso, em title, snippet e intenção. Depois do clique, o Clarity mostra rolagem e cliques mortos, que são o mais perto que chego de saber se a visita voltou para a busca. A leitura da [posição média do Search Console](/blog/posicao-media-do-search-console/) tem armadilhas próprias, e a faixa de posição precisa delas em mente.

## Autoridade do site e perfil de âncoras

**O siteAuthority é o único atributo famoso do vazamento com aplicação declarada na própria descrição.** O texto diz que ele é convertido de um dado chamado SiteAuthority e aplicado no Qstar. O guia oficial dos sistemas de ranqueamento, atualizado em dezembro de 2025, diz que o Google trabalha no nível da página, e que sinais e classificadores do site inteiro também são usados. As duas fontes combinam.

O que nenhuma fonte diz é como o siteAuthority é calculado. Por isso a comparação com as métricas de ferramenta não fecha. A autoridade de domínio e as métricas equivalentes são calculadas pelas empresas a partir do perfil de links, e o [texto da agência sobre autoridade de domínio](https://lucasferrazseo.com/blog/seo-estrategico/eeat-autoridade-de-dominio/) mostra por que elas servem de comparação entre concorrentes, não de meta. Uma métrica de ferramenta pode andar junto do siteAuthority. Ela não mede o siteAuthority.

Nas âncoras, o vazamento traz o anchorMismatchDemotion, convertido de um campo "mismatched" do QualityBoost. O nome sugere rebaixamento quando a âncora não combina com a página de destino, e a auditoria que faço segue essa leitura: âncora interna e externa comparada com o título e o tema da URL que recebe o link. O exactMatchDomainDemotion é o único item desta frente que o Google descreve em público com o mesmo sentido, como sistema que evita dar crédito demais a domínio criado para casar com uma busca.

## Foco tópico com siteFocusScore e siteRadius

**Dois atributos do mesmo módulo descrevem foco temático com vetores.** O siteFocusScore é descrito como um número que mede a concentração do site em um tema. O siteRadius é descrito como a medida de quanto os embeddings das páginas se afastam do embedding do site. O módulo guarda também o embedding do site e o das páginas.

Isso não prova que o foco pesa na ordem dos resultados. Prova que o Google calculava o foco do site com a mesma matemática que qualquer um consegue reproduzir. A reprodução que faço é esta: gero o embedding do texto principal de cada URL indexável, calculo o centro do site como a média dos vetores e meço a distância de cosseno de cada página até esse centro. A média das distâncias aproxima o foco, e a dispersão aproxima o raio. As URLs mais distantes são as candidatas a sair, a ser fundidas ou a ganhar links de páginas do centro do tema. A base dessa conta está no texto sobre [embeddings e busca semântica](/blog/embeddings-e-busca-semantica/).

O modelo de embedding que eu uso não é o do Google, então o número que sai é uma aproximação do conceito, não o escore.

## Datas e frescor

**A documentação vazada guarda três datas diferentes para o mesmo documento.** A bylineDate é descrita como a data que será mostrada no snippet dos resultados da busca. A syntacticDate é a data mencionada explicitamente na URL ou no título. A semanticDate é a data estimada pelo conteúdo do documento, pelas âncoras e por documentos relacionados, com um valor de confiança.

O guia oficial do Google sobre datas de publicação, atualizado em dezembro de 2025, usa o mesmo termo, "byline date", e define como a data que o Google estima para a publicação ou atualização. O guia pede data visível na página, com rótulo como "Publicado" ou "Atualizado", e datePublished e dateModified no schema com o mesmo valor. A coincidência de vocabulário entre o guia e a documentação interna é das mais claras do vazamento.

Para o frescor, o campo datesInfo é descrito como usado no FreshnessTwiddler, e o guia público fala em sistemas de frescor para buscas em que conteúdo recente é esperado. O que eu alinho em cada página é simples de listar.

| Fonte da data | Onde fica | O que precisa bater |
|---|---|---|
| Data visível | corpo da página, com rótulo | igual ao schema |
| datePublished e dateModified | JSON-LD | igual à visível, sem data futura |
| lastmod | sitemap | muda só quando o conteúdo muda |
| Data na URL ou no título | slug e title | evitar ano no slug de página que será atualizada |

No lucasferraz.com, a data visível, o schema, o sitemap e o feed saem do mesmo campo do arquivo de cada texto, e o campo de atualização só muda com revisão real. A relação entre data e citação por IA está no texto sobre [frescor e decaimento de citação](/blog/freshness-e-decaimento-de-citacao/).

## Demoções e idade do host

**O vazamento nomeia uma série de rebaixamentos, e só um deles traz aplicação declarada.** O serpDemotion é descrito como aplicado no Qstar. Os demais descrevem de onde o valor vem.

- **pandaDemotion e babyPandaV2Demotion:** codificação dos campos do Panda e um novo rebaixamento aplicado por cima dele. O Google conta no guia público que o Panda foi anunciado em 2011 e virou parte dos sistemas centrais em 2015;
- **navDemotion:** convertido de um campo "nav_demoted" do QualityBoost. O nome aponta para problemas de navegação, e a descrição não detalha;
- **productReviewPDemotePage e productReviewPDemoteSite:** confianças de rebaixamento ou promoção de reviews de produto. O guia público descreve o sistema de reviews;
- **exactMatchDomainDemotion:** o domínio com a palavra-chave exata, já tratado acima;
- **scamness e unauthoritativeScore:** pontuação de golpe e de falta de autoridade, as duas descritas como sinais de qualidade do Qstar.

A idade do host tem a descrição mais citada e mais mal lida do vazamento. O hostAge é a data em que a primeira página daquele host ou domínio foi vista, e a descrição diz que o dado é usado em um twiddler para segurar spam novo no momento de servir o resultado. Isso é um freio para spam recente. Não é um período de espera para todo site novo, e a descrição não fala em prazo.

## Autor como entidade e temas sensíveis

**O vazamento mostra o autor como entidade ligada ao documento, com uma ressalva que quase ninguém cita.** O isAuthor indica que uma entidade é a autora do documento. A descrição diz que o campo foi desenvolvido e ajustado principalmente para artigos de notícia, também é preenchido para outros conteúdos, como artigos científicos, e pode mudar de sentido ou ser removido.

A prática que isso sustenta é a mesma do schema de autor: a pessoa como entidade, com o mesmo @id em todas as páginas que ela assina, nos dois domínios quando for o caso. O caminho técnico está no texto sobre [ProfilePage e schema de autor](/blog/profilepage-e-schema-de-autor/).

Para temas sensíveis, o vazamento traz classificadores de saúde e de notícia (ymylHealthScore e ymylNewsScore) e dois sinais de autoridade específicos, um eleitoral e um de covid local. O guia público fala em sistemas de informação confiável. Fora de saúde, notícia e eleição, esses campos não mudam o trabalho.

## O que o Yandex acrescenta e onde ele para?

**O vazamento do Yandex tem uma vantagem que o do Google não tem: o arquivo de fatores traz etiquetas de uso.** Contei as etiquetas no arquivo de fatores convertido em JSON por um repositório público. São 1.923 entradas, uma a mais que os 1.922 fatores dos relatos de 2023. Dessas, 999 têm a etiqueta de depreciado e 242 a de não usado. Contando cada fator uma vez, 1.228 (63,9%) estão fora de uso naquela versão, perto dos "mais de 64%" que a cobertura de 2023 publicou.

A Sistrix chegou a outro número com o mesmo arquivo. Na [análise publicada em janeiro de 2023](https://www.sistrix.com/blog/yandex-code-leak-reveals-ranking-factors/), ela soma às duas etiquetas que contei as de não implementado (149) e de removido (115) e conclui que sobram 417 fatores ativos dos 1.922. O 417 sai de subtrair dos 1.922 a soma das quatro etiquetas, e um mesmo fator pode ter mais de uma. Refiz a conta no arquivo em JSON contando cada fator uma vez, e 1.324 das 1.923 entradas têm pelo menos uma das quatro etiquetas, o que deixa 599 sem nenhuma. Nesse arquivo, a etiqueta de não implementado aparece em 160 entradas, não em 149, então a versão que a Sistrix leu provavelmente não é idêntica.

Algumas contagens por grupo mudam a leitura comum do vazamento.

| Grupo de fatores (etiqueta) | Total | Sem etiqueta de depreciado ou não usado |
|---|---|---|
| Grafo de links | 39 | 3 |
| Texto de âncora | 146 | 8 |
| Datas | 19 | 11 |
| Texto da URL | 153 | 63 |
| Navegador | 185 | 95 |
| Tempo de permanência depois da busca | 102 | 40 |
| Cliques (grupo click machine) | 133 | 55 |

O fator de PageRank está marcado como não usado nesse arquivo. Isso não quer dizer que o Yandex ignorava links, porque o cálculo pode estar em outro lugar do código. Quer dizer que a frase "o Yandex confirma o PageRank", repetida em uma das respostas de IA que colhi, não se apoia nesse arquivo. Entre os fatores de URL sem etiqueta de desuso está o número de barras no endereço, que conversa com a leitura de [profundidade de clique](/blog/profundidade-de-clique/).

O limite é o de sempre. O Yandex é outro buscador, com outro modelo, e o próprio código cita o MatrixNet, que a empresa substituiu pelo CatBoost em 2017, segundo a mesma cobertura. Uso o Yandex para confirmar que uma categoria de sinal existe em um buscador real. Não uso para dizer que o Google faz igual.

## O que os vazamentos não dizem sobre as IAs?

**Os dois vazamentos são sobre ranqueamento de busca, não sobre como modelos de linguagem escolhem fontes.** O documento do Google descreve dados da Busca até março de 2024, e nenhum campo explica como o ChatGPT, o Perplexity ou o Claude escolhem o que citar.

A ligação que existe passa pelo Google. As AI Overviews e o AI Mode recuperam páginas do índice da Busca com os sistemas centrais de ranqueamento, segundo o guia de recursos de IA generativa do Google, então o que decide a posição orgânica também pesa na chance de uma página entrar nessas respostas. O caminho da recuperação está em [RAG e SEO](/blog/rag-e-seo/) e a relação com a posição em [AI Overviews e ranking orgânico](/blog/ai-overviews-e-ranking-organico/).

As rodadas mostram outro efeito. Nas 12 respostas colhidas em 27 de setembro de 2026, as IAs de chat citaram análises em inglês de 2024 e documentos do processo judicial. Nenhuma fonte em português apareceu, e três respostas repetiram como fato leituras de nível B. A AI Overview e o AI Mode da busca em português se apoiaram em páginas brasileiras de 2024 com a mesma confusão entre existir e ser usado.

## O que muda para quem mede?

**A regra que tiro dessa conferência é separar o que a documentação afirma do que a análise supõe, atributo por atributo.** Na prática, isso vira três perguntas antes de recomendar qualquer coisa com base no vazamento.

1. A descrição original diz onde o atributo é aplicado, ou só diz o que ele é?
2. Existe confirmação independente, em decisão judicial, depoimento ou guia oficial do Google?
3. Consigo medir a prática correspondente no meu site, com dado que eu mesmo coleto?

Três "sim" viram recomendação. Um "não" na segunda pergunta vira hipótese com teste marcado. Um "não" na terceira vira nota de rodapé. Para quem contrata, a versão sem jargão deste assunto está no [guia de posicionamento no Google da agência](https://lucasferrazseo.com/blog/seo-estrategico/posicionamento-no-google/).

<blockquote class="citavel"><p>Dos 14.031 atributos da documentação vazada do Google, só 5 dizem na própria descrição que são aplicados no ranqueamento. O resto descreve dados, não pesos.</p><p><cite><a href="/">Lucas Ferraz</a>, especialista em SEO</cite></p></blockquote>

## Minha posição sobre o tema

Leio o vazamento do Google como inventário de dados, não como lista de fatores. Só trato como indício de uso o atributo cuja própria descrição diz onde ele é aplicado, ou que tem confirmação em fonte judicial ou em documentação oficial do Google. O resto entra como hipótese, e hipótese eu testo nos meus sites antes de virar recomendação. Os achados que mudam o trabalho são os que dá para medir, como o comportamento depois do clique, o foco temático do site e a coerência das datas. (Lucas Ferraz)

## Nota de método

- **O que foi medido.** O pacote google_api_content_warehouse nas versões 0.2.0, 0.3.0, 0.4.0, 0.5.0 e 0.6.1 baixadas do hex.pm; o arquivo de fatores do vazamento do Yandex convertido em JSON; o Search Console do lucasferrazseo.com (200 consultas sem marca); 12 rodadas nas IAs de chat e a SERP das buscas do tema; na revisão, a SERP de "fatores de ranqueamento do google" e de "vazamento algoritmo google", a análise da Sistrix sobre o vazamento do Yandex, o texto da decisão judicial de 2024 e a página de tecnologia do Google arquivada em 2009.
- **Quando.** 27 de setembro de 2026 e 2 de novembro de 2026.
- **Como.** Contagem de arquivos e de declarações de campo por versão do pacote; busca, na descrição de cada atributo, das expressões que indicam uso (applied in Qstar, qstar signals, twiddler) e depreciação; contagem das etiquetas TG_DEPRECATED e TG_UNUSED no arquivo do Yandex e, na revisão, das etiquetas TG_UNIMPLEMENTED e TG_REMOVED, contando cada fator uma vez; CTR por faixa de posição de 27 de junho a 27 de setembro de 2026, pelo conector de leitura do Search Console.
- **Limitação.** A descrição de um atributo diz o que a equipe do Google escreveu na época, não o que roda hoje. A busca por expressões de uso só encontra o que está escrito, então atributo usado sem essa menção fica fora da contagem. O arquivo do Yandex é um dos arquivos de fatores do vazamento, não o conjunto inteiro. O CTR por faixa vem de um site pequeno e de um trimestre.

## Perguntas frequentes

### Quantos fatores de ranqueamento o Google tem?

O Google não publica a contagem atual nem a lista. A página de tecnologia da empresa dizia, em 2009, que a busca usava mais de 200 sinais, sem nomear quais. A documentação vazada de 2024 tem 14.031 atributos declarados na minha contagem, mas atributo não é fator, e só 5 dizem na descrição que são aplicados no ranqueamento.

### Site novo indexado que não aparece na busca comum está no sandbox?

O vazamento mostra o atributo hostAge, a data em que a primeira página do host foi vista, descrito como usado para segurar spam novo na hora de servir o resultado. É um freio para spam recente, não um período fixo para todo site novo. Site novo em tema disputado e sem links costuma demorar por falta de sinais.

### CTR mais baixo derruba a posição?

A decisão judicial de 2024 confirma que o NavBoost usa dados de clique por consulta e documento, com janela de 13 meses. O CTR do Search Console, porém, não é o sinal. A documentação fala em cliques bons, ruins e no último clique mais longo, então a queda de CTR importa quando reflete visitas que voltam à busca.

### O siteAuthority é a mesma coisa que DA ou DR?

Não. Autoridade de domínio e Domain Rating são métricas de ferramentas calculadas a partir de links. O siteAuthority é um atributo interno do Google, convertido de um dado chamado SiteAuthority e aplicado no Qstar, segundo a própria descrição. A documentação não diz como ele é calculado, então nenhuma métrica de ferramenta mede o siteAuthority.

### Dá para controlar a data que o Google mostra no resultado?

Dá para influenciar, não para escolher. O Google estima a data de exibição, que a documentação vazada chama de bylineDate, e o guia oficial pede data visível na página, com rótulo, igual à do schema. A documentação também guarda uma data sintática, tirada da URL ou do título, e uma data semântica, estimada pelo conteúdo.

### Quanto tempo a busca leva para reconhecer a autoridade de um site novo?

Nenhum documento vazado traz prazo. O NavBoost trabalha com 13 meses de cliques, e o siteAuthority depende de dados de qualidade do site cujo cálculo não aparece. Na prática, conto em meses e acompanho impressões por consulta de marca e de tema no Search Console, que mostram quando a busca começa a associar o site ao assunto.

## Fontes

- Hex.pm, pacote google_api_content_warehouse (versões e datas de publicação) (2024) - https://hex.pm/packages/google_api_content_warehouse
- HexDocs, google_api_content_warehouse v0.4.0, referência da API (2024) - https://hexdocs.pm/google_api_content_warehouse/0.4.0/api-reference.html
- The Verge, Google confirms the leaked Search documents are real (2024) - https://www.theverge.com/2024/5/29/24167407/google-search-algorithm-documents-leak-confirmation
- Tribunal Distrital dos EUA para o Distrito de Colúmbia, United States v. Google LLC, Memorandum Opinion (Document 1033) (2024) - https://storage.courtlistener.com/recap/gov.uscourts.dcd.223205/gov.uscourts.dcd.223205.1033.0_2.pdf
- Google Search Central, guia dos sistemas de ranqueamento da Busca (2025) - https://developers.google.com/search/docs/appearance/ranking-systems-guide
- Google Search Central, datas de publicação nos resultados da Busca (2025) - https://developers.google.com/search/docs/appearance/publication-dates
- Google Search Central, guia de otimização para recursos de IA generativa (2026) - https://developers.google.com/search/docs/fundamentals/ai-optimization-guide
- Search Engine Journal, Yandex Data Leak, Ranking Factors and the Myths We Found (2023) - https://www.searchenginejournal.com/yandex-data-leak/477905/
- Repositório público com os fatores do Yandex convertidos em JSON (2023) - https://github.com/devidw/yandex-ranking-factors
- Sistrix, Yandex code leak reveals ranking factors (2023) - https://www.sistrix.com/blog/yandex-code-leak-reveals-ranking-factors/
- Google, Corporate Information, Technology Overview (cópia do Internet Archive de 29/12/2009) (2009) - https://web.archive.org/web/20091229190850/http://www.google.com/corporate/tech.html

## Histórico deste texto

- 2 de novembro de 2026: Seção nova que responde quais são os fatores de ranqueamento do Google, a contagem da Sistrix para o Yandex comparada com a minha nas mesmas quatro etiquetas, o nome e o cargo de quem depôs sobre o NavBoost na decisão judicial e uma pergunta nova no FAQ.

---
Sobre o autor: Especialista em SEO, criação de sites e Generative Engine Optimization, Lucas Ferraz é fundador da agência Lucas Ferraz SEO, sediada em Belo Horizonte, e atua desde 2007 ajudando empresas de todo o Brasil a aparecerem no Google, serem compreendidas por sistemas de inteligência artificial e transformarem buscas em oportunidades comerciais.