Yandex'in kod tabanının "parçaları" geçen hafta internete sızdırıldı. Google'a çok benzeyen Yandex, e-posta, haritalar, taksi hizmeti vb. birçok yönü olan bir platformdur. Kod sızıntısı, hepsinin parçalarını içeriyordu.

Oradaki belgelere göre, Yandex'in kod tabanı 2013 yılında Arcadia adlı büyük bir havuza katlandı. Sızan kod tabanı, Arcadia'daki tüm projelerin bir alt kümesidir ve içinde "Çekirdek", "Kütüphane" ve "Kütüphane"deki arama motoruyla ilgili birkaç bileşen buluyoruz. , "Robot", "Arama" ve "ExtSearch" arşivleri.

Hareket tamamen emsalsiz. 2006'nın AOL arama sorgusu verilerinin, kamu malı olan bir web arama motoruyla ilgili çok fazla materyali olduğundan beri değil.

Başvurulan veriler ve birçok dosya eksik olsa da, bu, modern bir arama motorunun kod düzeyinde nasıl çalıştığına dair somut bir bakışın ilk örneğidir.

Şahsen, Bilgi Erişimi, modern arama motorlarının gerçekte nasıl çalıştığı ve nasıl çalıştığı hakkında konuştuğum “SEO Bilimi” kitabımı bitirirken kodu gerçekten görebilmek için zamanlamanın ne kadar harika olduğunu anlayamıyorum. basit bir tane kendin inşa etmek için.

Her halükarda, geçen Perşembe gününden beri kodu çözümlüyorum ve herhangi bir mühendis size her şeyin nasıl çalıştığını anlamak için yeterli zamanın olmadığını söyleyecektir. Bu yüzden, tamir etmeye devam ettikçe birkaç gönderi daha olacağından şüpheleniyorum.

Konuya girmeden önce, Ontolo'dan Ben Wills'e kodu benimle paylaştığı, bana iyi şeylerin olduğu ilk yönü gösterdiği ve biz bir şeyleri deşifre ederken benimle ileri geri gittiği için bir seslenmek istiyorum. Buradaki sıralama faktörleri hakkında derlediğimiz tüm verileri içeren elektronik tabloyu almaktan çekinmeyin.

Ayrıca, araştırma yaptığı ve bazı önemli bulguları benimle IM üzerinden paylaştığı için Ryan Jones'a sesleniyorum.

Tamam, meşgul olalım!

Google'ın kodu değil, öyleyse neden umursayalım?

Bazıları, bu kod tabanını gözden geçirmenin dikkat dağıtıcı olduğuna ve iş kararlarını nasıl alacaklarını etkileyecek hiçbir şeyin olmadığına inanıyor. Bunların, takip eden yıllar boyunca herhangi bir arama motorunda modelleme için endüstri standardı olarak 2006 AOL verilerinden TO modelini kullanan aynı SEO topluluğundan insanlar olduğunu düşünürsek, bunu ilginç buluyorum.

Bununla birlikte, Yandex Google değildir. Yine de ikisi, teknolojinin en ileri noktasında kalmaya devam eden son teknoloji web arama motorlarıdır.

Her iki şirketten yazılım mühendisleri aynı konferanslara (SIGIR, ECIR, vb.) giderek Bilgi Erişimi, Doğal Dil İşleme/Anlama ve Makine Öğrenimi alanlarındaki bulguları ve yenilikleri paylaşırlar. Yandex'in Palo Alto'da da bir varlığı var ve Google'ın daha önce Moskova'da bir varlığı vardı.

Hızlı bir LinkedIn araması, her iki şirkette de çalışmış birkaç yüz mühendisi ortaya çıkarır, ancak kaçının her iki şirkette de Arama üzerinde çalıştığını bilmiyoruz.

Daha doğrudan bir örtüşme içinde Yandex, Google'ın TensorFlow, BERT, MapReduce ve çok daha az ölçüde Protokol Tamponları gibi Arama'daki yenilikler için kritik öneme sahip açık kaynak teknolojilerinden de yararlanır.

Dolayısıyla, Yandex kesinlikle Google olmasa da, burada bahsettiğimiz rastgele bir araştırma projesi de değil. Bu kod tabanını inceleyerek modern bir arama motorunun nasıl oluşturulduğu hakkında öğrenebileceğimiz çok şey var.

En azından, metin-kod oranları ve W3C uyumluluğu gibi SEO araçlarına hala nüfuz eden bazı eskimiş kavramlardan veya Google'ın 200 sinyalinin sınıflar yerine yalnızca 200 ayrı sayfa içi ve sayfa dışı özellik olduğu şeklindeki genel inançtan kendimizi kurtarabiliriz. potansiyel olarak binlerce bireysel önlemi kullanan bileşik faktörler.

Yandex'in mimarisiyle ilgili bazı bağlamlar

Bağlam veya başarılı bir şekilde derleme, çalıştırma ve adım adım ilerleme yeteneği olmadan, kaynak kodu anlamlandırmak çok zordur.

Tipik olarak, yeni mühendisler mevcut bir kod tabanına dahil olmak için belgeler, gözden geçirmeler alır ve çift programlamaya girerler. Ayrıca, dokümanlar arşivinde derleme sürecinin ayarlanmasıyla ilgili bazı sınırlı başlangıç ​​belgeleri vardır. Bununla birlikte, Yandex'in kodu baştan sona dahili wiki'lere de atıfta bulunur, ancak bunlar sızdırılmamıştır ve koddaki yorumlar da oldukça seyrektir.

Neyse ki Yandex, kamuya açık belgelerinde mimarisi hakkında bazı bilgiler veriyor. Ayrıca ABD'de yayınladıkları ve biraz ışık tutmaya yardımcı olan birkaç patent de var. Yani:

• Çok sayıda gönderi listesine sahip ters çevrilmiş bir dizini aramak için bilgisayar uygulamalı yöntem ve sistem
• Arama sonucu sıralaması

Kitabım için Google'ı araştırırken, çeşitli teknik incelemeler, patentler ve mühendislerin SEO deneyimime karşı çıkan konuşmaları sayesinde sıralama sistemlerinin yapısı hakkında çok daha derin bir anlayış geliştirdim. Ayrıca, web arama motorları için genel Bilgi Erişim en iyi uygulamalarını kavramak için çok zaman harcadım. Yandex ile oyunda gerçekten bazı en iyi uygulamaların ve benzerliklerin olması şaşırtıcı değil.

Yandex'in belgelerinde ikili dağıtımlı bir paletli sistem anlatılmaktadır. Biri "Turuncu Paletli" olarak adlandırılan gerçek zamanlı tarama için, diğeri ise genel tarama için.

Tarihsel olarak, Google'ın biri gerçek zamanlı taramayı barındırmak, biri düzenli olarak taramak ve biri nadiren taramak için olmak üzere üç gruba ayrılmış bir dizine sahip olduğu söylenir. Bu yaklaşım, IR'de en iyi uygulama olarak kabul edilir.

Yandex ve Google bu açıdan farklılık gösterir, ancak güncelleme sıklığı anlayışıyla yönlendirilen bölümlere ayrılmış taramanın genel fikri geçerlidir.

Söylemeye değer bir şey, Yandex'in JavaScript için ayrı bir işleme sistemine sahip olmamasıdır. Bunu belgelerinde söylüyorlar ve Gemini adı verilen görsel regresyon testi için Web sürücüsü tabanlı bir sisteme sahip olmalarına rağmen kendilerini metin tabanlı tarama ile sınırlıyorlar.

Belgeler ayrıca, sayfaları ters çevrilmiş bir dizine ve bir belge sunucusuna bölen parçalanmış bir veritabanı yapısını da tartışır.

Diğer birçok web arama motorunda olduğu gibi, dizin oluşturma işlemi bir sözlük oluşturur, sayfaları önbelleğe alır ve ardından verileri ters çevrilmiş dizine yerleştirir, böylece bigramlar ve trigamlar ve bunların belgedeki yerleşimleri gösterilir.

Bu, uzun zaman önce trigramlardan çok daha uzun olabilen n-gramlar anlamına gelen kelime öbeği tabanlı indekslemeye geçmeleri bakımından Google'dan farklıdır.

Ancak Yandex sistemi de kendi iş hattında BERT kullanıyor, bu nedenle bir noktada belgeler ve sorgular gömmelere dönüştürülüyor ve sıralama için en yakın komşu arama teknikleri kullanılıyor.

Sıralama süreci, işlerin daha ilginç olmaya başladığı yerdir.

Yandex, önbelleğe alınan popüler arama sonuçlarının sorguyu işledikten sonra sunulduğu Metasearch adlı bir katmana sahiptir. Sonuçlar burada bulunmazsa, arama sorgusu Temel Arama katmanındaki binlerce farklı makineye aynı anda gönderilir. Her biri, ilgili belgelerden oluşan bir gönderi listesi oluşturur ve ardından SERP'yi oluşturmak için yeniden sıralama için Yandex'in sinir ağı uygulaması olan MatrixNet'e gönderir.

Google mühendislerinin Arama'nın altyapısı hakkında konuştuğu videolara göre, bu sıralama süreci Google Arama'ya oldukça benziyor. Google'ın teknolojisinin, her makinede çeşitli uygulamaların bulunduğu ve işlerin bilgi işlem gücünün mevcudiyetine bağlı olarak bu makineler arasında dağıtıldığı paylaşılan ortamlarda olduğundan bahsediyorlar.

Kullanım durumlarından biri tam olarak bu, ilgili dizin parçalarını hızlı bir şekilde işlemek için sorguların çeşitli makinelere dağıtılmasıdır. İlan listelerini hesaplamak, sıralama faktörlerini dikkate almamız gereken ilk yerdir.

Kod tabanında 17.854 sıralama faktörü vardır.

Sızıntıyı izleyen Cuma günü, taklit edilemez Martin MacDonald hevesle web_factors_info/factors_gen.in adlı kod tabanından bir dosya paylaştı. Dosya, kod tabanı sızıntısındaki "Çekirdek" arşivinden geliyor ve 1.922 sıralama faktörü içeriyor.

Doğal olarak, SEO topluluğu, bu sayı ve dosyadaki bilgilerle ilgili haberleri hevesle yaymak için çalıştı. Birçok kişi, verileri anlamlandırmak için açıklamaları tercüme etti ve araçlar veya Google E-Tablolar ve ChatGPT oluşturdu. Bunların hepsi toplumun gücünün harika örnekleridir. Bununla birlikte, 1.922, kod tabanındaki birçok sıralama faktörü kümesinden yalnızca birini temsil eder.

Kod tabanına daha derin bir dalış, Yandex'in sorgu işleme ve sıralama sistemlerinin farklı alt kümeleri için çok sayıda sıralama faktörü dosyası olduğunu ortaya çıkarır.

Bunları tarayarak, aslında toplamda 17.854 sıralama faktörü olduğunu görüyoruz. Bu sıralama faktörlerine aşağıdakilerle ilgili çeşitli metrikler dahildir:

• tıklamalar
• Bekleme süresi.
• Yandex'in Google Analytics eşdeğeri Metrika'dan yararlanma.

Çekirdek koddakilerin dışında ek 2.000 faktöre sahip bir dizi Jupyter not defteri de vardır. Muhtemelen, bu Jupyter not defterleri, mühendislerin kod tabanına eklemek için ek faktörleri düşündükleri testleri temsil ediyor. Yine kod tabanından topladığımız metadata ile tüm bu özellikleri bu linkten inceleyebilirsiniz.

Yandex'in dokümantasyonu, sıralama faktörlerinin üç sınıfa sahip olduğunu daha da açıklığa kavuşturuyor: Statik, Dinamik ve özellikle kullanıcının araması ve aramanın nasıl yapıldığıyla ilgili olanlar. Kendi sözleriyle:

Kod tabanında bunlar, sıralama faktörleri dosyalarında TG_STATIC ve TG_DYNAMIC etiketleriyle belirtilir. Arama ile ilgili faktörlerin TG_QUERY_ONLY, TG_QUERY, TG_USER_SEARCH ve TG_USER_SEARCH_ONLY gibi birden çok etiketi vardır.

Aralarından seçim yapabileceğiniz potansiyel bir 18k sıralama faktörü ortaya çıkarmış olsak da, MatrixNet ile ilgili belgeler, puanlamanın on binlerce faktörden oluşturulduğunu ve arama sorgusuna göre özelleştirildiğini gösteriyor.

Bu, sıralama ortamının Google ortamına benzer şekilde oldukça dinamik olduğunu gösterir. Google'ın “Puanlama işlevlerini değerlendirmek için çerçeve” patentine göre, uzun süredir, birden fazla işlevin çalıştırıldığı ve en iyi sonuçların döndürüldüğü benzer bir şeye sahipler.

Son olarak, dokümantasyonun onbinlerce sıralama faktörüne atıfta bulunduğunu düşünürsek, kodda atıfta bulunulan ve arşivde eksik olan birçok başka dosya olduğunu da aklımızda tutmalıyız. Yani, muhtemelen göremediğimiz daha fazla şey oluyor. Bu, arşivde bulunmayan diğer dizinleri gösteren ilk katılım belgelerindeki görüntülerin incelenmesiyle daha da açıklanır.

Örneğin, /semantic-search/ dizininde DSSM ile ilgili daha çok şey olduğundan şüpheleniyorum.

Sıralama faktörlerinin ilk ağırlığı

İlk önce, kod tabanının sıralama faktörleri için herhangi bir ağırlığı olmadığı varsayımı altında çalıştım. Sonra /search/relevance/ dizinindeki nav_linear.h dosyasının sıralama faktörleriyle ilişkili ilk katsayıları (veya ağırlıkları) tam ekranda gösterdiğini görünce şok oldum.

Kodun bu bölümü, belirlediğimiz 17.000'den fazla sıralama faktöründen 257'sini vurgulamaktadır. ( Bunları çekip sıralama faktörü açıklamalarıyla sıraladığı için Ryan Jones'a şapka bahşişi.)

Anlaşılır olması için, bir arama motoru algoritması düşündüğünüzde, muhtemelen her sayfanın bir dizi faktöre göre puanlandığı uzun ve karmaşık bir matematiksel denklem düşünüyorsunuzdur. Bu aşırı basitleştirme olsa da, aşağıdaki ekran görüntüsü böyle bir denklemden bir alıntıdır. Katsayılar, her bir faktörün ne kadar önemli olduğunu temsil eder ve elde edilen hesaplanan puan, seçici sayfaları alaka düzeyine göre puanlamak için kullanılacak olan puandır.

Bu değerlerin sabit kodlanmış olması, sıralamanın gerçekleştiği tek yerin kesinlikle burası olmadığını gösteriyor. Bunun yerine, bu işlev büyük olasılıkla sıralama için dikkate alınan her parça için bir dizi gönderi listesi oluşturmak üzere ilk alaka düzeyi puanlamasının yapıldığı yerdir. Yukarıda listelenen ilk patentte, bundan, belgeleri sorguya özgü alaka düzeyi (QSR) için incelemeden önce sınırlayan sorgudan bağımsız bir alaka düzeyi (QIR) kavramı olarak bahsediyorlar.

Ortaya çıkan kayıt listeleri daha sonra, karşılaştırılmak üzere sorgu özellikleriyle birlikte MatrixNet'e teslim edilir. Bu nedenle, aşağı akış işlemlerinin ayrıntılarını (henüz) bilmesek de, bu ağırlıkları anlamak yine de değerlidir çünkü bir sayfanın değerlendirme kümesine uygun olması için gerekenleri size söylerler.

Ancak bu, bir sonraki soruyu gündeme getiriyor: MatrixNet hakkında ne biliyoruz?

Çekirdek arşivinde nöral sıralama kodu vardır ve kod tabanı boyunca MatrixNet ve “mxnet”e çok sayıda referansın yanı sıra Derin Yapılandırılmış Semantik Modellere (DSSM) birçok referans vardır.

FI_MATRIXNET sıralama faktörlerinden birinin açıklaması, MatrixNet'in tüm faktörlere uygulandığını gösterir.

Faktör {

Endeks: 160

CppAdı: "FI_MATRIXNET"

İsim: “MatrixNet”

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

Açıklama: "MatrixNet tüm faktörlere uygulanır - formül"

}

Ayrıca önceden eğitilmiş modeller olabilecek bir sürü ikili dosya da var, ancak kodun bu yönlerini çözmem daha fazla zaman alacak.

Hemen anlaşılan şey, sıralama yapmak için birden fazla seviye olduğu (L1, L2, L3) ve her seviyede seçilebilecek çeşitli sıralama modelleri olduğudur.

Selection_rankings_model.cpp dosyası, süreç boyunca her katmanda farklı sıralama modellerinin dikkate alınabileceğini önerir. Temel olarak sinir ağlarının çalışma şekli budur. Her seviye, işlemleri tamamlayan bir özelliktir ve bunların birleştirilmiş hesaplamaları, sonuçta bir SERP olarak görünen yeniden sıralanmış belge listesini verir. Daha fazla zamanım olduğunda MatrixNet'te derin bir dalışla devam edeceğim. Bir göz atmaya ihtiyaç duyanlar için, Arama sonucu sıralayıcı patentine göz atın.

Şimdilik bazı ilginç sıralama faktörlerine bir göz atalım.

İlk 5 negatif ağırlıklı ilk sıralama faktörü

Aşağıda, ağırlıkları ile en yüksek negatif ağırlıklı ilk sıralama faktörlerinin bir listesi ve Rusça'dan çevrilmiş açıklamalarına dayanan kısa bir açıklama bulunmaktadır.

1. FI_ADV: -0.2509284637 -Bu faktör, sayfada herhangi bir reklam olup olmadığını belirler ve tek bir sıralama faktörü için en ağır ağırlıklı cezayı verir.
2. FI_DATER_AGE: -0.2074373667 – Bu faktör, bir tarih işlevi tarafından belirlenen belgenin geçerli tarihi ile tarihi arasındaki farktır. Belge tarihi bugün ile aynı ise 1, belge 10 yıl veya daha eskiyse veya tarih tanımlanmamışsa 0 değeri verilir. Bu, Yandex'in daha eski içerikleri tercih ettiğini gösterir.
3. FI_QURL_STAT_POWER: -0.1943768768 – Bu faktör, sorguyla ilgili olarak URL gösterimlerinin sayısıdır. Görünüşe göre sonuçların çeşitliliğini artırmak için birçok aramada görünen bir URL'yi indirgemek istiyorlar.
4. FI_COMM_LINKS_SEO_HOSTS: -0.1809636391 – Bu faktör, "ticari" bağlantı metni içeren gelen bağlantıların yüzdesidir. Bu tür bağlantıların oranı %50'den fazlaysa faktör 0,1'e döner, aksi takdirde 0'a ayarlanır.
5. FI_GEO_CITY_URL_REGION_COUNTRY: -0.168645758 – Bu faktör, belgenin ve kullanıcının arama yaptığı ülkenin coğrafi çakışmasıdır. 1, belge ve ülkenin eşleştiği anlamına geliyorsa, bu pek mantıklı değil.

Özet olarak, bu faktörler, en iyi skor için şunları yapmanız gerektiğini gösterir:

• Reklamlardan kaçının.
• Yeni sayfalar oluşturmak yerine eski içeriği güncelleyin.
• Bağlantılarınızın çoğunda markalı bağlantı metni bulunduğundan emin olun.

Bu listedeki diğer her şey kontrolünüz dışındadır.

İlk 5 pozitif ağırlıklı ilk sıralama faktörü

Takip etmek için, en yüksek ağırlıklı pozitif sıralama faktörlerinin bir listesini burada bulabilirsiniz.

1. FI_URL_DOMAIN_FRACTION: +0.5640952971 – Bu faktör, URL'nin etki alanına karşı sorgunun garip bir maskeleme örtüşmesidir. Verilen örnek, chelloto olarak kısaltılan Chelyabinsk piyangosu. Bu değeri hesaplamak için Yandex, kapsanan üç harfi (che, hel, lot, olo) bulur, alan adında tüm üç harfli kombinasyonların ne kadarının olduğuna bakın.
2. FI_QUERY_DOWNER_CLICKS_COMBO: +0.3690780393 – Bu faktörün açıklaması, "FRC ve sözde TO'nun akıllıca birleştirilmesi" şeklindedir. FRC'nin ne olduğuna dair hemen bir gösterge yoktur.
3. FI_MAX_WORD_HOST_CLICKS: +0.3451158835 – Bu faktör, alandaki en önemli kelimenin tıklanabilirliğidir. Örneğin, "wikipedia" kelimesinin bulunduğu tüm sorgular için wikipedia sayfalarına tıklayın.
4. FI_MAX_WORD_HOST_YABAR: +0.3154394573 – Faktör açıklaması “çubuğa göre siteye karşılık gelen en karakteristik sorgu kelimesi” diyor. Bunun, siteyle ilişkili Yandex Araç Çubuğu'nda en çok aranan anahtar kelime anlamına geldiğini varsayıyorum.
5. FI_IS_COM: +0.2762504972 – Etki alanının bir .COM olmasıdır.

Başka bir deyişle:

• Alanınızla kelime oyunları oynayın.
• Bunun bir nokta com olduğundan emin olun.
• İnsanları Yandex Çubuğu'nda hedef anahtar kelimelerinizi aramaya teşvik edin.
• Tıklamaları artırmaya devam edin.

Pek çok beklenmedik ilk sıralama faktörü var

İlk ağırlıklı sıralama faktörlerinde daha ilginç olan, beklenmeyen faktörlerdir. Aşağıda öne çıkan on yedi faktörün bir listesi bulunmaktadır.

1. FI_PAGE_RANK: +0.1828678331 – PageRank, Yandex'deki en yüksek 17. ağırlıklı faktördür. Daha önce sıralama sistemlerinden bağlantıları tamamen kaldırdılar, bu yüzden listede bu kadar düşük olması çok şaşırtıcı değil.
2. FI_SPAM_KARMA: +0.00842682963 – Spam karması, adını "antispam göndericilerden" alır ve ana bilgisayarın spam olma olasılığıdır; whois bilgilerine göre
3. FI_SUBQUERY_THEME_MATCH_A: +0.1786465163 – Sorgu ve belgenin tematik olarak ne kadar yakından eşleştiği. Bu, 19. en yüksek ağırlıklı faktördür.
4. FI_REG_HOST_RANK: +0.1567124399 – Yandex'in bir ana bilgisayar (veya etki alanı) sıralama faktörü vardır.
5. FI_URL_LINK_PERCENT: +0,08940421124 – Bağlantı metni (metin yerine) bir URL olan bağlantıların toplam bağlantı sayısına oranı.
6. FI_PAGE_RANK_UKR: +0.08712279101 – Belirli bir Ukraynaca PageRank var
7. FI_IS_NOT_RU: +0.08128946612 – Etki alanının .RU olmaması olumlu bir şeydir. Görünüşe göre, Rus arama motoru Rus sitelerine güvenmiyor.
8. FI_YABAR_HOST_AVG_TIME2: +0.07417219313 – Bu, YandexBar tarafından bildirilen ortalama bekleme süresidir.
9. FI_LERF_LR_LOG_RELEV: +0.06059448504 – Bu, her bir bağlantının kalitesine dayalı bağlantı alaka düzeyidir
10. FI_NUM_SLASHES: +0.05057609417 – URL'deki eğik çizgi sayısı bir sıralama faktörüdür.
11. FI_ADV_PRONOUNS_PORTION: -0.001250755075 – Sayfadaki zamir isimlerinin oranı.
12. FI_TEXT_HEAD_SYN: -0.01291908335 – Eşanlamlılar dikkate alınarak başlıkta [sorgu] kelimelerinin varlığı
13. FI_PERCENT_FREQ_WORDS: -0.02021022114 – Dilin en sık kullanılan 200 kelimesi olan kelime sayısının, metindeki tüm kelime sayısından yüzdesi.
14. FI_YANDEX_ADV: -0.09426121965 – Reklamlardan hoşlanmama ile daha da belirginleşen Yandex, Yandex reklamlarıyla sayfaları cezalandırıyor.
15. FI_AURA_DOC_LOG_SHARED: -0.09768630485 – Belgedeki benzersiz olmayan kiremit (metin alanları) sayısının logaritması.
16. FI_AURA_DOC_LOG_AUTHOR: -0.09727752961 – Belgenin bu sahibinin yazar olarak tanındığı kiremit sayısının logaritması.
17. FI_CLASSIF_IS_SHOP: -0.1339319854 – Görünüşe göre, sayfanız bir mağaza ise Yandex size daha az sevgi gösterecek.

Bu garip sıralama faktörlerini ve Yandex kod tabanında mevcut olanların dizisini incelemenin ana çıkarımı, bir sıralama faktörü olabilecek birçok şeyin olduğudur.

Google'ın bildirdiği "200 sinyalin" aslında her bir sinyalin diğer birçok bileşenden oluşan bir bileşik olduğu 200 sinyal sınıfı olduğundan şüpheleniyorum. Google Analytics'in pek çok metriği ilişkilendiren boyutlara sahip olması gibi, Google Arama da muhtemelen birçok özellikten oluşan sıralama sinyalleri sınıflarına sahiptir.

Yandex, Google, Bing, YouTube ve TikTok'u sıyırıyor

Kod tabanı ayrıca Yandex'in diğer web siteleri ve ilgili hizmetleri için birçok ayrıştırıcıya sahip olduğunu da ortaya koymaktadır. Batılılar için bunların en dikkat çekeni yukarıdaki başlıkta saydıklarımdır. Ek olarak, Yandex'in bilmediğim çeşitli hizmetler için olduğu kadar kendi hizmetleri için de ayrıştırıcıları var.

Hemen belli olan şey, ayrıştırıcıların tam özellik olduğudur. Google SERP'nin her anlamlı bileşeni ayıklanır. Aslında, bu hizmetlerden herhangi birini almayı düşünen herkesin bu kodu gözden geçirmesi iyi olabilir.

Yandex'in DSSM hesaplamalarının bir parçası olarak bazı Google verilerini kullandığını gösteren başka bir kod var, ancak Google adlı 83 sıralama faktörü, Yandex'in Google'ın sonuçlarına oldukça fazla güvendiğini açıkça ortaya koyuyor.

Açıkçası, Google asla başka bir arama motorunun sonuçlarını kopyalamak için Bing hareketini yapmaz veya temel sıralama hesaplamaları için birine güvenmez.

Yandex, bazı sıralama faktörleri için SEO karşıtı üst sınırlara sahiptir

315 sıralama faktörü, bunun ötesinde hesaplanan herhangi bir değerin sisteme sayfanın bu özelliğinin aşırı optimize edildiğini gösterdiği eşiklere sahiptir. Bu sıralama faktörlerinden 39'u, bir sayfanın ilk gönderiler listesine dahil edilmesini engelleyebilecek başlangıçta ağırlıklı faktörlerin parçasıdır. Bunları yukarıda linkini verdiğim elektronik tabloda Sıralama Katsayısı ve Anti-SEO sütununa göre filtreleyerek bulabilirsiniz.

Kavramsal olarak, tüm modern arama motorlarının, SEO'ların tarihsel olarak suistimal ettiği bağlantı metni, TO veya anahtar kelime doldurma gibi belirli faktörlere eşikler koymasını beklemek çok zor değil. Örneğin, Bing'in meta anahtar kelimelerin kötü niyetli kullanımını olumsuz bir faktör olarak kullandığı söylendi.

Yandex, “Vital Hosts”u güçlendiriyor

Yandex, kod tabanında bir dizi güçlendirme mekanizmasına sahiptir. Bunlar, sıralama için dikkate alınırken daha yüksek puan almalarını sağlamak için belirli belgelerde yapılan yapay iyileştirmelerdir.

Aşağıda, "artırma sihirbazı"ndan, yükseltme algoritmasından en iyi şekilde daha küçük dosyaların yararlandığını öne süren bir yorum yer almaktadır.

Birkaç destek türü vardır; Bağlantılarla ilgili bir destek gördüm ve ayrıca bir dizi "HandJobBoosts" gördüm, bunun yalnızca "manuel" değişikliklerin garip bir çevirisi olduğunu varsayabilirim.

Özellikle ilginç bulduğum bu desteklerden biri, "Vital Hosts" ile ilgili. Burada hayati bir ana bilgisayar belirtilen herhangi bir site olabilir. Değişkenlerde özellikle belirtilen NEWS_AGENCY_RATING, Yandex'in sonuçlarını belirli haber kuruluşlarına yönlendiren bir destek verdiğine inanmamı sağlıyor.

Jeopolitiğe girmeden, sıralama sistemlerine bunun gibi önyargıları sokmama konusunda kararlı oldukları için bu, Google'dan çok farklıdır.

Belge sunucusunun yapısı

Kod tabanı, belgelerin Yandex'in belge sunucusunda nasıl saklandığını gösterir. Bu, bir arama motorunun sayfanın bir kopyasını oluşturup önbelleğine kaydetmediğini, çeşitli özellikleri meta veri olarak yakaladığını ve daha sonra aşağı akış sıralama sürecinde kullandığını anlamada yardımcı olur.

Aşağıdaki ekran görüntüsü, özellikle ilginç olan bu özelliklerin bir alt kümesini vurgulamaktadır. SQL sorguları içeren diğer dosyalar, belge sunucusunun DOM ağacı, cümle uzunlukları, getirme süresi, bir dizi tarih ve antispam puanı, yeniden yönlendirme zinciri ve belgenin çevrilip çevrilmediği dahil olmak üzere 200'e yakın sütuna sahip olduğunu gösterir. Karşılaştığım en eksiksiz liste /robot/rthub/yql/protos/web_page_item.proto konumunda.

Buradaki alt kümede en ilginç olan şey, kullanılan simhash sayısıdır. Simhashe'ler, içeriğin sayısal temsilleridir ve arama motorları bunları, yinelenen içeriği belirlemek için ışık hızında karşılaştırma yapmak için kullanır. Robot arşivinde, yinelenen içeriğin açıkça indirildiğini gösteren çeşitli örnekler vardır.

Ayrıca, indeksleme sürecinin bir parçası olarak kod tabanı, metin işleme boru hattında TF-IDF, BM25 ve BERT'ye sahiptir. Tüm bu mekanizmaların neden kodda var olduğu açık değil çünkü hepsini kullanmada bir miktar fazlalık var.

Bağlantı Faktörleri ve Önceliklendirme

Yandex'in bağlantı faktörlerini nasıl ele aldığı özellikle ilginçtir, çünkü daha önce etkilerini tamamen devre dışı bırakmışlardır. Kod tabanı ayrıca bağlantı faktörleri ve bağlantıların nasıl önceliklendirildiği hakkında birçok bilgi verir.

Yandex'in spam bağlantı hesaplayıcısının baktığı 89 faktör vardır. SF_RESERVED olarak işaretlenen her şey kullanımdan kaldırılmıştır. Sağlandığı durumlarda, bu faktörlerin açıklamalarını yukarıda bağlantısı verilen Google E-Tablosunda bulabilirsiniz.

Özellikle, Yandex'in bir ana bilgisayar sıralaması ve bir site veya sayfa spam konusunda itibar kazandıktan sonra uzun vadede canlı görünen bazı puanları vardır.

Yandex'in yaptığı başka bir şey de, bir etki alanındaki kopyaları incelemek ve bu bağlantılarda yinelenen içerik olup olmadığını belirlemektir. Bu, site çapında bağlantı yerleşimleri, yinelenen sayfalardaki bağlantılar veya aynı siteden gelen aynı bağlantı metnine sahip bağlantılar olabilir.

Bu, aynı kaynaktan birden çok bağlantıyı göz ardı etmenin ne kadar önemsiz olduğunu gösterir ve daha çeşitli kaynaklardan daha benzersiz bağlantıları hedeflemenin ne kadar önemli olduğunu netleştirir.

Google hakkında bildiklerimize Yandex'ten ne uygulayabiliriz?

Doğal olarak, herkesin aklındaki soru hala bu. Yandex ve Google arasında kesinlikle birçok analog olsa da, doğrusu, yalnızca Arama üzerinde çalışan bir Google Yazılım Mühendisi bu soruyu kesin olarak cevaplayabilir.

Yine de bu yanlış soru.

Gerçekten, bu kod, modern arama hakkındaki düşüncelerimizi genişletmemize yardımcı olacaktır. Toplu arama anlayışının çoğu, SEO topluluğunun 2000'lerin başında test yoluyla öğrendiklerinden ve aramanın çok daha az opak olduğu zamanlarda arama mühendislerinin ağızlarından inşa edilmiştir. Ne yazık ki bu hızlı inovasyon hızına ayak uyduramadı.

Yandex sızıntısının birçok özelliğinden ve faktöründen elde edilen içgörüler, Google'da sıralama için test edilecek ve dikkate alınacak daha fazla hipotez sağlamalıdır. Ayrıca SEO taraması, bağlantı analizi ve sıralama araçları tarafından ayrıştırılabilecek ve ölçülebilecek daha fazla şey sunmalıdırlar.

Örneğin, sorgular ve BERT gömmeleri kullanan belgeler arasındaki kosinüs benzerliğinin bir ölçüsü, modern arama motorlarının kendilerinin yaptığı bir şey olduğundan, rakip sayfalara kıyasla anlamak için değerli olabilir.

AOL Arama günlüklerinin bizi SERP'deki tıklamaların dağılımını tahmin etmekten uzaklaştırdığı gibi, Yandex kod tabanı da bizi soyuttan somuta uzaklaştırır ve "duruma bağlıdır" ifadelerimiz daha nitelikli olabilir.

Bu amaçla, bu kod tabanı vermeye devam edecek bir hediyedir. Sadece bir hafta sonu oldu ve şimdiden bu koddan bazı çok ilgi çekici içgörüler topladık.

Ellerinde çok daha fazla zaman olan bazı hırslı SEO mühendislerinin kazmaya devam edeceğini ve hatta belki de bu şeyi derleyip çalıştırmaya yetecek kadar eksik olanı dolduracağını tahmin ediyorum. Ayrıca, farklı arama motorlarındaki mühendislerin de öğrenebilecekleri ve sistemlerine ekleyebilecekleri yenilikleri inceleyip incelediklerine inanıyorum.

Eşzamanlı olarak, Google avukatları muhtemelen tüm kazımalarla ilgili agresif durdurma ve vazgeçme mektupları hazırlıyorlar.

Bu fırsatı en üst düzeye çıkaracak meraklı insanlar tarafından yönlendirilen alanımızın gelişimini görmek için can atıyorum.

Ancak, hey, gerçek koddan bilgi almak sizin için değerli değilse, alt alan adları ve alt dizinler hakkında tartışmak gibi daha önemli bir şey yapmaya geri dönebilirsiniz.