“Fragmentos” da base de código do Yandex vazaram online na semana passada. Assim como o Google, o Yandex é uma plataforma com muitos aspectos, como e-mail, mapas, serviço de táxi etc. O vazamento de código apresentava partes de tudo isso.

De acordo com a documentação nele contida, a base de código do Yandex foi dobrada em um grande repositório chamado Arcadia em 2013. A base de código vazada é um subconjunto de todos os projetos no Arcadia e encontramos vários componentes relacionados ao mecanismo de pesquisa no "Kernel", "Biblioteca ”, “Robô”, “Pesquisa” e arquivos “ExtSearch”.

O movimento é totalmente sem precedentes. Desde os dados de consulta de pesquisa da AOL de 2006, algo tão material relacionado a um mecanismo de pesquisa na Web não entrou em domínio público.

Embora estejamos perdendo os dados e muitos arquivos referenciados, esta é a primeira instância de uma visão tangível de como um mecanismo de pesquisa moderno funciona no nível do código.

Pessoalmente, não consigo superar o quão fantástico é o timing para poder realmente ver o código enquanto termino meu livro “The Science of SEO”, onde falo sobre recuperação de informações, como os mecanismos de pesquisa modernos realmente funcionam e como para construir um simples você mesmo.

De qualquer forma, estou analisando o código desde quinta-feira passada e qualquer engenheiro dirá que não é tempo suficiente para entender como tudo funciona. Então, eu suspeito que haverá vários outros posts enquanto eu continuo mexendo.

Antes de começarmos, quero agradecer a Ben Wills da Ontolo por compartilhar o código comigo, me apontar a direção inicial de onde estão as coisas boas e ir e vir comigo enquanto decifrámos as coisas. Fique à vontade para pegar a planilha com todos os dados que compilamos sobre os fatores de classificação aqui.

Além disso, agradeço a Ryan Jones por se aprofundar e compartilhar algumas descobertas importantes comigo por meio de mensagens instantâneas.

OK, vamos nos ocupar!

Não é o código do Google, então por que nos importamos?

Alguns acreditam que revisar essa base de código é uma distração e que não há nada que afete a forma como eles tomam decisões de negócios. Acho isso curioso, considerando que são pessoas da mesma comunidade de SEO que usaram o modelo CTR dos dados da AOL de 2006 como o padrão da indústria para modelagem em qualquer mecanismo de pesquisa por muitos anos.

Dito isso, o Yandex não é o Google. No entanto, os dois são mecanismos de pesquisa da Web de última geração que continuam na vanguarda da tecnologia.

Engenheiros de software de ambas as empresas vão às mesmas conferências (SIGIR, ECIR, etc) e compartilham descobertas e inovações em Recuperação de Informações, Processamento/Entendimento de Linguagem Natural e Aprendizado de Máquina. A Yandex também está presente em Palo Alto e o Google já estava presente em Moscou.

Uma rápida pesquisa no LinkedIn revela algumas centenas de engenheiros que trabalharam nas duas empresas, embora não saibamos quantos deles realmente trabalharam na Pesquisa em ambas as empresas.

Em uma sobreposição mais direta, o Yandex também faz uso das tecnologias de código aberto do Google que foram essenciais para as inovações na Pesquisa, como TensorFlow, BERT, MapReduce e, em uma extensão muito menor, Buffers de protocolo.

Portanto, embora o Yandex certamente não seja o Google, também não é um projeto de pesquisa aleatório do qual estamos falando aqui. Podemos aprender muito sobre como um mecanismo de pesquisa moderno é construído analisando essa base de código.

No mínimo, podemos nos livrar de algumas noções obsoletas que ainda permeiam as ferramentas de SEO, como proporções texto-código e conformidade com o W3C, ou a crença geral de que os 200 sinais do Google são simplesmente 200 recursos individuais dentro e fora da página, em vez de classes de fatores compostos que potencialmente usam milhares de medidas individuais.

Algum contexto sobre a arquitetura do Yandex

Sem contexto ou a capacidade de compilar, executar e percorrê-lo com êxito, é muito difícil entender o código-fonte.

Normalmente, novos engenheiros obtêm documentação, orientações e se envolvem em programação em pares para se integrar a uma base de código existente. E há alguma documentação de integração limitada relacionada à configuração do processo de compilação no arquivo de documentos. No entanto, o código do Yandex também faz referência a wikis internos, mas eles não vazaram e os comentários no código também são bastante esparsos.

Felizmente, o Yandex fornece algumas informações sobre sua arquitetura em sua documentação pública. Há também algumas patentes publicadas nos EUA que ajudam a esclarecer um pouco. Nomeadamente:

• Método implementado por computador e sistema para pesquisar um índice invertido tendo uma pluralidade de listas de postagem
• Classificador de resultados de pesquisa

Ao pesquisar o Google para o meu livro, desenvolvi uma compreensão muito mais profunda da estrutura de seus sistemas de classificação por meio de vários whitepapers, patentes e palestras de engenheiros com base em minha experiência em SEO. Também passei muito tempo aprimorando minha compreensão das práticas recomendadas gerais de recuperação de informações para mecanismos de pesquisa na web. Não é nenhuma surpresa que de fato existam algumas práticas recomendadas e semelhanças em jogo com o Yandex.

A documentação do Yandex discute um sistema de rastreador de distribuição dupla. Um para rastreamento em tempo real chamado “Orange Crawler” e outro para rastreamento geral.

Historicamente, diz-se que o Google tinha um índice estratificado em três compartimentos, um para abrigar o rastreamento em tempo real, um para rastrear regularmente e outro para raramente rastrear. Essa abordagem é considerada uma boa prática em RI.

Yandex e Google diferem a esse respeito, mas a ideia geral de rastreamento segmentado impulsionado por uma compreensão da frequência de atualização se mantém.

Uma coisa que vale a pena destacar é que o Yandex não possui um sistema de renderização separado para JavaScript. Eles dizem isso em sua documentação e, embora tenham um sistema baseado em Webdriver para teste de regressão visual chamado Gemini, eles se limitam ao rastreamento baseado em texto.

A documentação também discute uma estrutura de banco de dados fragmentada que divide as páginas em um índice invertido e um servidor de documentos.

Assim como a maioria dos outros mecanismos de pesquisa da Web, o processo de indexação cria um dicionário, armazena páginas em cache e, em seguida, coloca os dados no índice invertido de forma que os bigramas e trigams e sua colocação no documento sejam representados.

Isso difere do Google porque eles mudaram para a indexação baseada em frases, o que significa n-gramas que podem ser muito mais longos do que os trigramas há muito tempo.

No entanto, o sistema Yandex também usa o BERT em seu pipeline, portanto, em algum momento, os documentos e as consultas são convertidos em incorporações e as técnicas de pesquisa do vizinho mais próximo são empregadas para classificação.

O processo de classificação é onde as coisas começam a ficar mais interessantes.

O Yandex tem uma camada chamada Metasearch , na qual os resultados de pesquisa populares em cache são exibidos após o processamento da consulta. Se os resultados não forem encontrados lá, a consulta de pesquisa será enviada para uma série de milhares de máquinas diferentes na camada de Pesquisa Básica simultaneamente. Cada um cria uma lista de postagem de documentos relevantes e a retorna ao MatrixNet, o aplicativo de rede neural da Yandex para reclassificação, para criar a SERP.

Com base em vídeos nos quais os engenheiros do Google falaram sobre a infraestrutura da Pesquisa, esse processo de classificação é bastante semelhante à Pesquisa do Google. Eles falam sobre a tecnologia do Google estar em ambientes compartilhados onde vários aplicativos estão em cada máquina e os trabalhos são distribuídos entre essas máquinas com base na disponibilidade de poder de computação.

Um dos casos de uso é exatamente este, a distribuição de consultas para uma variedade de máquinas para processar rapidamente os fragmentos de índice relevantes. Calcular as listas de postagem é o primeiro lugar em que precisamos considerar os fatores de classificação.

Existem 17.854 fatores de classificação na base de código

Na sexta-feira seguinte ao vazamento, o inimitável Martin MacDonald compartilhou ansiosamente um arquivo da base de código chamado web_factors_info/factors_gen.in. O arquivo vem do arquivo “Kernel” no vazamento da base de código e apresenta 1.922 fatores de classificação.

Naturalmente, a comunidade de SEO correu com esse número e esse arquivo para espalhar ansiosamente as notícias dos insights nele contidos. Muitas pessoas traduziram as descrições e criaram ferramentas ou planilhas do Google e ChatGPT para entender os dados. Todos os quais são grandes exemplos do poder da comunidade. No entanto, o 1.922 representa apenas um dos muitos conjuntos de fatores de classificação na base de código.

Um mergulho mais profundo na base de código revela que existem vários arquivos de fator de classificação para diferentes subconjuntos dos sistemas de classificação e processamento de consultas do Yandex.

Analisando-os, descobrimos que existem, na verdade, 17.854 fatores de classificação no total. Incluídas nesses fatores de classificação estão várias métricas relacionadas a:

• Cliques.
• Tempo de permanência.
• Aproveitando o equivalente do Google Analytics do Yandex, Metrika.

Há também uma série de notebooks Jupyter que possuem 2.000 fatores adicionais além daqueles no código principal. Presumivelmente, esses notebooks Jupyter representam testes em que os engenheiros estão considerando fatores adicionais para adicionar à base de código. Novamente, você pode revisar todos esses recursos com metadados que coletamos de toda a base de código neste link.

A documentação do Yandex esclarece ainda que eles possuem três classes de fatores de classificação: estáticos, dinâmicos e aqueles relacionados especificamente à pesquisa do usuário e como ela foi realizada. Em suas próprias palavras:

Na base de código, eles são indicados nos arquivos de fatores de classificação com as tags TG_STATIC e TG_DYNAMIC. Os fatores relacionados à pesquisa têm várias tags, como TG_QUERY_ONLY, TG_QUERY, TG_USER_SEARCH e TG_USER_SEARCH_ONLY.

Embora tenhamos descoberto 18 mil fatores de classificação em potencial para escolher, a documentação relacionada ao MatrixNet indica que a pontuação é construída a partir de dezenas de milhares de fatores e personalizada com base na consulta de pesquisa.

Isso indica que o ambiente de ranqueamento é altamente dinâmico, semelhante ao ambiente do Google. De acordo com a patente "Estrutura para avaliação de funções de pontuação" do Google, há muito tempo eles têm algo semelhante em que várias funções são executadas e o melhor conjunto de resultados é retornado.

Finalmente, considerando que a documentação faz referência a dezenas de milhares de fatores de classificação, também devemos ter em mente que existem muitos outros arquivos referenciados no código que estão faltando no arquivo. Portanto, provavelmente há mais coisas acontecendo que não conseguimos ver. Isso é ainda ilustrado pela análise das imagens na documentação de integração, que mostra outros diretórios que não estão presentes no arquivo.

Por exemplo, suspeito que haja mais coisas relacionadas ao DSSM no diretório /semantic-search/.

A ponderação inicial dos fatores de classificação

Primeiro, operei sob a suposição de que a base de código não tinha nenhum peso para os fatores de classificação. Fiquei chocado ao ver que o arquivo nav_linear.h no diretório /search/relevance/ apresenta os coeficientes iniciais (ou pesos) associados aos fatores de classificação em exibição total.

Esta seção do código destaca 257 dos mais de 17.000 fatores de classificação que identificamos. ( Dica para Ryan Jones por retirá-los e alinhá-los com as descrições dos fatores de classificação.)

Para maior clareza, quando você pensa em um algoritmo de mecanismo de pesquisa, provavelmente está pensando em uma equação matemática longa e complexa pela qual cada página é pontuada com base em uma série de fatores. Embora seja uma simplificação exagerada, a captura de tela a seguir é um trecho dessa equação. Os coeficientes representam a importância de cada fator e a pontuação computada resultante é o que seria usado para pontuar as páginas do seletor quanto à relevância.

Esses valores sendo codificados sugerem que esse certamente não é o único lugar em que a classificação acontece. Em vez disso, essa função é mais provável onde a pontuação de relevância inicial é feita para gerar uma série de listas de postagem para cada fragmento sendo considerado para classificação. Na primeira patente listada acima, eles falam sobre isso como um conceito de relevância independente de consulta (QIR), que então limita os documentos antes de revisá-los para relevância específica de consulta (QSR).

As listas de postagem resultantes são então entregues ao MatrixNet com recursos de consulta para comparação. Portanto, embora não saibamos os detalhes das operações de downstream (ainda), esses pesos ainda são valiosos para entender porque eles informam os requisitos para que uma página seja elegível para o conjunto de consideração.

No entanto, isso levanta a próxima questão: o que sabemos sobre MatrixNet?

Há um código de classificação neural no arquivo do Kernel e várias referências a MatrixNet e “mxnet”, bem como muitas referências a Deep Structured Semantic Models (DSSM) em toda a base de código.

A descrição de um dos fatores de classificação FI_MATRIXNET indica que o MatrixNet é aplicado a todos os fatores.

Fator {

Índice: 160

CppName: “FI_MATRIXNET”

Nome: “MatrixNet”

Tags: [TG_DOC, TG_DYNAMIC, TG_TRANS, TG_NOT_01, TG_REARR_USE, TG_L3_MODEL_VALUE, TG_FRESHNESS_FROZEN_POOL]

Descrição: “MatrixNet é aplicado a todos os fatores – a fórmula”

}

Há também um monte de arquivos binários que podem ser os próprios modelos pré-treinados, mas vou levar mais tempo para desvendar esses aspectos do código.

O que fica imediatamente claro é que existem vários níveis de classificação (L1, L2, L3) e uma variedade de modelos de classificação que podem ser selecionados em cada nível.

O arquivo selection_rankings_model.cpp sugere que diferentes modelos de classificação podem ser considerados em cada camada ao longo do processo. É basicamente assim que as redes neurais funcionam. Cada nível é um aspecto que completa as operações e seus cálculos combinados produzem a lista reclassificada de documentos que, por fim, aparecem como SERP. Continuarei com um mergulho profundo no MatrixNet quando tiver mais tempo. Para aqueles que precisam dar uma espiada, confira a patente do classificador de resultados de pesquisa.

Por enquanto, vamos dar uma olhada em alguns fatores de classificação interessantes.

Os 5 principais fatores de classificação inicial ponderados negativamente

A seguir está uma lista dos fatores de classificação inicial de maior peso negativo com seus pesos e uma breve explicação baseada em suas descrições traduzidas do russo.

1. FI_ADV: -0,2509284637 - Este fator determina que haja publicidade de qualquer tipo na página e emite a penalidade ponderada mais pesada para um único fator de classificação.
2. FI_DATER_AGE: -0,2074373667 – Este fator é a diferença entre a data atual e a data do documento determinada por uma função datadora. O valor é 1 se a data do documento for igual a hoje, 0 se o documento tiver 10 anos ou mais ou se a data não estiver definida. Isso indica que o Yandex tem preferência por conteúdo mais antigo.
3. FI_QURL_STAT_POWER: -0,1943768768 – Este fator é o número de impressões de URL relacionadas à consulta. Parece que eles querem rebaixar um URL que aparece em muitas pesquisas para promover a diversidade de resultados.
4. FI_COMM_LINKS_SEO_HOSTS: -0,1809636391 – Este fator é a porcentagem de links inbound com texto âncora “comercial”. O fator reverte para 0,1 se a proporção desses links for maior que 50%, caso contrário, é definido como 0.
5. FI_GEO_CITY_URL_REGION_COUNTRY: -0.168645758 – Este fator é a coincidência geográfica do documento e o país de onde o usuário pesquisou. Este não faz muito sentido se 1 significa que o documento e o país correspondem.

Em resumo, esses fatores indicam que, para obter a melhor pontuação, você deve:

• Evite anúncios.
• Atualize o conteúdo antigo em vez de criar novas páginas.
• Certifique-se de que a maioria dos seus links tenha texto âncora de marca.

Tudo o mais nesta lista está além do seu controle.

Os 5 principais fatores de classificação inicial ponderados positivamente

Para acompanhar, aqui está uma lista dos fatores positivos de classificação mais ponderados.

1. FI_URL_DOMAIN_FRACTION: +0.5640952971 – Este fator é uma estranha sobreposição de mascaramento da consulta versus o domínio da URL. O exemplo dado é a loteria de Chelyabinsk, abreviada como chelloto. Para calcular esse valor, o Yandex encontra três letras cobertas (che, hel, lot, olo), verifica a proporção de todas as combinações de três letras no nome de domínio.
2. FI_QUERY_DOWNER_CLICKS_COMBO: +0.3690780393 – A descrição deste fator é que é “habilmente combinado de FRC e pseudo-CTR”. Não há indicação imediata do que é FRC.
3. FI_MAX_WORD_HOST_CLICKS: +0,3451158835 – Este fator é a clicabilidade da palavra mais importante do domínio. Por exemplo, para todas as consultas em que houver a palavra “wikipedia”, clique nas páginas da wikipedia.
4. FI_MAX_WORD_HOST_YABAR: +0.3154394573 – A descrição do fator diz “a palavra de consulta mais característica correspondente ao site, de acordo com a barra”. Presumo que isso signifique a palavra-chave mais pesquisada na barra de ferramentas Yandex associada ao site.
5. FI_IS_COM: +0.2762504972 – O fator é que o domínio é um .COM.

Em outras palavras:

• Jogue jogos de palavras com seu domínio.
• Certifique-se de que é um pontocom.
• Incentive as pessoas a pesquisar suas palavras-chave de destino na Barra Yandex.
• Continue gerando cliques.

Existem muitos fatores inesperados de classificação inicial

O que é mais interessante nos fatores iniciais de classificação ponderada são os inesperados. A seguir, uma lista de dezessete fatores que se destacaram.

1. FI_PAGE_RANK: +0,1828678331 – PageRank é o 17º fator ponderado mais alto no Yandex. Eles anteriormente removeram completamente os links de seu sistema de classificação, então não é muito chocante o quão baixo ele está na lista.
2. FI_SPAM_KARMA: +0.00842682963 – O Spam karma recebe o nome de “antispammers” e é a probabilidade de o host ser spam; com base em informações Whois
3. FI_SUBQUERY_THEME_MATCH_A: +0,1786465163 – Quão próximo a consulta e o documento correspondem tematicamente. Este é o 19º fator ponderado mais alto.
4. FI_REG_HOST_RANK: +0,1567124399 – Yandex tem um fator de classificação de host (ou domínio).
5. FI_URL_LINK_PERCENT: +0,08940421124 – Proporção de links cujo texto âncora é uma URL (em vez de texto) em relação ao número total de links.
6. FI_PAGE_RANK_UKR: +0.08712279101 – Existe um PageRank ucraniano específico
7. FI_IS_NOT_RU: +0.08128946612 – É positivo se o domínio não for .RU. Aparentemente, o mecanismo de busca russo não confia em sites russos.
8. FI_YABAR_HOST_AVG_TIME2: +0,07417219313 – Este é o tempo médio de permanência conforme relatado por YandexBar
9. FI_LERF_LR_LOG_RELEV: +0.06059448504 – Esta é a relevância do link com base na qualidade de cada link
10. FI_NUM_SLASHES: +0,05057609417 – O número de barras na URL é um fator de classificação.
11. FI_ADV_PRONOUNS_PORTION: -0,001250755075 – A proporção de substantivos pronominais na página.
12. FI_TEXT_HEAD_SYN: -0.01291908335 – Presença de palavras [query] no cabeçalho, levando em conta sinônimos
13. FI_PERCENT_FREQ_WORDS: -0,02021022114 – A porcentagem do número de palavras, que são as 200 palavras mais frequentes do idioma, do número de todas as palavras do texto.
14. FI_YANDEX_ADV: -0,09426121965 – Sendo mais específico com a aversão a anúncios, Yandex penaliza páginas com anúncios Yandex.
15. FI_AURA_DOC_LOG_SHARED: -0,09768630485 – O logaritmo do número de shingles (áreas de texto) no documento que não são exclusivas.
16. FI_AURA_DOC_LOG_AUTHOR: -0,09727752961 – O logaritmo do número de telhas em que este proprietário do documento é reconhecido como autor.
17. FI_CLASSIF_IS_SHOP: -0,1339319854 – Aparentemente, Yandex vai te dar menos amor se sua página for uma loja.

A principal conclusão ao revisar esses fatores de classificação ímpares e a variedade daqueles disponíveis na base de código do Yandex é que há muitas coisas que podem ser um fator de classificação.

Suspeito que os “200 sinais” relatados pelo Google sejam, na verdade, 200 classes de sinal em que cada sinal é uma composição composta de muitos outros componentes. Da mesma forma que o Google Analytics possui dimensões com muitas métricas associadas, a Pesquisa Google provavelmente possui classes de sinais de classificação compostas por muitos recursos.

Yandex raspa Google, Bing, YouTube e TikTok

A base de código também revela que o Yandex possui muitos analisadores para outros sites e seus respectivos serviços. Para os ocidentais, os mais notáveis ​​são os que listei no título acima. Além disso, o Yandex possui analisadores para uma variedade de serviços com os quais eu não estava familiarizado, bem como para seus próprios serviços.

O que é imediatamente evidente é que os analisadores são completos. Cada componente significativo do Google SERP é extraído. Na verdade, qualquer pessoa que esteja pensando em raspar qualquer um desses serviços pode fazer bem em revisar este código.

Há outro código que indica que o Yandex está usando alguns dados do Google como parte dos cálculos do DSSM, mas os 83 fatores de classificação nomeados pelo Google deixam claro que o Yandex se apoiou fortemente nos resultados do Google.

Obviamente, o Google nunca usaria o movimento do Bing de copiar os resultados de outro mecanismo de pesquisa, nem confiaria em um para cálculos de classificação central.

Yandex tem limites superiores anti-SEO para alguns fatores de classificação

315 fatores de classificação têm limites nos quais qualquer valor calculado além disso indica ao sistema que esse recurso da página está superotimizado. 39 desses fatores de classificação fazem parte dos fatores ponderados inicialmente que podem impedir que uma página seja incluída na lista de postagens iniciais. Você pode encontrá-los na planilha à qual vinculei acima, filtrando o Coeficiente de classificação e a coluna Anti-SEO.

Não é exagero conceitualmente esperar que todos os mecanismos de pesquisa modernos definam limites para certos fatores que os SEOs historicamente abusaram, como texto âncora, CTR ou preenchimento de palavras-chave. Por exemplo, o Bing foi dito para alavancar o uso abusivo das palavras-chave meta como um fator negativo.

Yandex impulsiona “Hosts vitais”

O Yandex possui uma série de mecanismos de reforço em toda a sua base de código. Essas são melhorias artificiais em certos documentos para garantir que eles tenham uma pontuação mais alta ao serem considerados para classificação.

Abaixo está um comentário do “assistente de aumento” que sugere que arquivos menores se beneficiam melhor do algoritmo de aumento.

Existem vários tipos de reforços; Eu vi um aumento relacionado a links e também vi uma série de “HandJobBoosts” que eu só posso assumir que é uma tradução estranha de mudanças “manuais”.

Um desses impulsos que achei particularmente interessante está relacionado a “Vital Hosts”. Onde um host vital pode ser qualquer site especificado. Especificamente mencionado nas variáveis ​​é NEWS_AGENCY_RATING, o que me leva a acreditar que o Yandex dá um impulso que influencia seus resultados para certas organizações de notícias.

Sem entrar na geopolítica, isso é muito diferente do Google, pois eles foram inflexíveis em não introduzir vieses como esse em seus sistemas de classificação.

A estrutura do servidor de documentos

A base de código revela como os documentos são armazenados no servidor de documentos do Yandex. Isso é útil para entender que um mecanismo de pesquisa não simplesmente faz uma cópia da página e a salva em seu cache, ele captura vários recursos como metadados para usar no processo de classificação downstream.

A captura de tela abaixo destaca um subconjunto desses recursos que são particularmente interessantes. Outros arquivos com consultas SQL sugerem que o servidor de documentos tem cerca de 200 colunas, incluindo a árvore DOM, comprimentos de sentença, tempo de busca, uma série de datas e pontuação antispam, cadeia de redirecionamento e se o documento é traduzido ou não. A lista mais completa que encontrei está em /robot/rthub/yql/protos/web_page_item.proto.

O que é mais interessante no subconjunto aqui é o número de simhashes empregados. Simhashes são representações numéricas de conteúdo e os mecanismos de pesquisa os usam para comparações extremamente rápidas para a determinação de conteúdo duplicado. Existem várias instâncias no arquivo do robô que indicam que o conteúdo duplicado foi explicitamente rebaixado.

Além disso, como parte do processo de indexação, a base de código apresenta TF-IDF, BM25 e BERT em seu pipeline de processamento de texto. Não está claro por que todos esses mecanismos existem no código porque há alguma redundância no uso de todos eles.

Fatores de link e priorização

A maneira como o Yandex lida com os fatores de link é particularmente interessante porque eles anteriormente desativavam completamente seu impacto. A base de código também revela muitas informações sobre fatores de link e como os links são priorizados.

A calculadora de spam de link do Yandex tem 89 fatores que analisa. Qualquer coisa marcada como SF_RESERVED é obsoleta. Quando fornecido, você pode encontrar as descrições desses fatores na planilha do Google vinculada acima.

Notavelmente, o Yandex tem uma classificação de host e algumas pontuações que parecem durar muito tempo depois que um site ou página desenvolve uma reputação de spam.

Outra coisa que o Yandex faz é revisar a cópia em um domínio e determinar se há conteúdo duplicado com esses links. Podem ser posicionamentos de links em todo o site, links em páginas duplicadas ou simplesmente links com o mesmo texto âncora vindo do mesmo site.

Isso ilustra como é trivial descontar vários links da mesma fonte e esclarece como é importante segmentar mais links exclusivos de fontes mais diversas.

O que podemos aplicar do Yandex ao que sabemos sobre o Google?

Naturalmente, esta ainda é a questão na mente de todos. Embora certamente existam muitos análogos entre o Yandex e o Google, sinceramente, apenas um engenheiro de software do Google trabalhando na Pesquisa poderia responder definitivamente a essa pergunta.

No entanto, essa é a pergunta errada.

Realmente, esse código deve nos ajudar a expandir nosso pensamento sobre a pesquisa moderna. Grande parte da compreensão coletiva da pesquisa é construída a partir do que a comunidade de SEO aprendeu no início dos anos 2000 por meio de testes e da boca dos engenheiros de pesquisa quando a pesquisa era muito menos opaca. Infelizmente, isso não acompanhou o ritmo acelerado da inovação.

Os insights dos muitos recursos e fatores do vazamento do Yandex devem render mais hipóteses de coisas para testar e considerar para a classificação no Google. Eles também devem apresentar mais coisas que podem ser analisadas e medidas pelo rastreamento de SEO, análise de links e ferramentas de classificação.

Por exemplo, uma medida da similaridade de cosseno entre consultas e documentos usando incorporações BERT pode ser valiosa para entender em relação às páginas concorrentes, pois é algo que os próprios mecanismos de pesquisa modernos estão fazendo.

Da mesma forma que os logs de pesquisa da AOL nos levaram a adivinhar a distribuição de cliques na SERP, a base de código Yandex nos afasta do abstrato para o concreto e nossas declarações “depende” podem ser melhor qualificadas.

Para esse fim, esta base de código é um presente que continuará dando. Faz apenas um fim de semana e já coletamos alguns insights muito interessantes desse código.

Prevejo que alguns engenheiros de SEO ambiciosos com muito mais tempo em suas mãos continuarão cavando e talvez até preencham o suficiente do que está faltando para compilar essa coisa e fazê-la funcionar. Também acredito que os engenheiros dos diferentes mecanismos de pesquisa também estão analisando e analisando as inovações com as quais podem aprender e adicionar aos seus sistemas.

Simultaneamente, os advogados do Google provavelmente estão redigindo cartas agressivas de cessação e desistência relacionadas a toda a raspagem.

Estou ansioso para ver a evolução do nosso espaço impulsionada pelos curiosos que irão maximizar esta oportunidade.

Mas, ei, se obter insights do código real não for valioso para você, fique à vontade para voltar a fazer algo mais importante, como discutir sobre subdomínios versus subdiretórios.