„Fragmente” din baza de coduri Yandex au apărut online săptămâna trecută. La fel ca Google, Yandex este o platformă cu multe aspecte, cum ar fi e-mail, hărți, un serviciu de taxi, etc. Scurgerea de cod a prezentat bucăți din tot.

Conform documentației din aceasta, baza de cod Yandex a fost pliată într-un depozit mare numit Arcadia în 2013. Baza de cod scursă este un subset al tuturor proiectelor din Arcadia și găsim în ea mai multe componente legate de motorul de căutare în „Kernel”, „Bibliotecă”. ”, „Robot”, „Căutare” și „ExtSearch”.

Mișcarea este cu totul fără precedent. De la datele de căutare AOL din 2006, nu a mai intrat în domeniul public ceva atât de material legat de un motor de căutare web.

Deși ne lipsesc datele și multe fișiere la care se face referire, acesta este primul exemplu de o privire tangibilă asupra modului în care funcționează un motor de căutare modern la nivel de cod.

Personal, nu pot trece peste cât de fantastic este momentul pentru a putea vedea codul în timp ce termin cartea mea „Știința SEO”, unde vorbesc despre regăsirea informațiilor, cum funcționează de fapt motoarele de căutare moderne și cum pentru a construi singur unul simplu.

În orice caz, am analizat codul de joia trecută și orice inginer vă va spune că nu este timp suficient pentru a înțelege cum funcționează totul. Așadar, bănuiesc că vor mai fi câteva postări pe măsură ce continui să schimb.

Înainte de a interveni, vreau să-l felicit pe Ben Wills de la Ontolo pentru că mi-a împărtășit codul, arătându-mă în direcția inițială unde sunt lucrurile bune și mergând înainte și înapoi cu mine în timp ce descifram lucrurile. Simțiți-vă liber să luați foaia de calcul cu toate datele pe care le-am compilat despre factorii de clasare aici.

De asemenea, strigați-i lui Ryan Jones pentru că a cercetat și mi-a împărtășit câteva constatări cheie prin IM.

OK, hai să ne ocupăm!

Nu este codul Google, așa că de ce ne pasă?

Unii cred că revizuirea acestei baze de cod este o distragere a atenției și că nu există nimic care să afecteze modul în care iau decizii de afaceri. Mi se pare curios, având în vedere că aceștia sunt oameni din aceeași comunitate SEO care au folosit modelul CTR din datele AOL 2006 ca standard din industrie pentru modelarea în orice motor de căutare timp de mulți ani de urmat.

Acestea fiind spuse, Yandex nu este Google. Cu toate acestea, cele două sunt motoare de căutare web de ultimă generație, care au continuat să rămână la vârf de tehnologie.

Inginerii de software din ambele companii merg la aceleași conferințe (SIGIR, ECIR etc.) și împărtășesc descoperiri și inovații în regăsirea informațiilor, procesarea/înțelegerea limbajului natural și învățarea automată. Yandex are o prezență și în Palo Alto, iar Google a avut anterior o prezență la Moscova.

O căutare rapidă pe LinkedIn descoperă câteva sute de ingineri care au lucrat la ambele companii, deși nu știm câți dintre ei au lucrat efectiv la Căutare la ambele companii.

Într-o suprapunere mai directă, Yandex utilizează, de asemenea, tehnologiile open source ale Google, care au fost esențiale pentru inovațiile în căutare, cum ar fi TensorFlow, BERT, MapReduce și, într-o măsură mult mai mică, Protocol Buffers.

Deci, deși Yandex cu siguranță nu este Google, nu este nici un proiect de cercetare aleatoriu despre care vorbim aici. Sunt multe despre cum este construit un motor de căutare modern din revizuirea acestei baze de cod.

Cel puțin, ne putem dezabuza de unele noțiuni învechite care încă pătrund în instrumentele SEO, cum ar fi raporturile text-cod și conformitatea cu W3C sau credința generală că cele 200 de semnale Google sunt pur și simplu 200 de caracteristici individuale pe și în afara paginii, mai degrabă decât clase de factori compoziți care pot utiliza mii de măsuri individuale.

Un context asupra arhitecturii Yandex

Fără context sau abilitatea de a compila, rula și parcurge cu succes, codul sursă este foarte greu de înțeles.

În mod obișnuit, noii ingineri obțin documentație, expuneri și se angajează în programarea în pereche pentru a se integra la o bază de cod existentă. Și există o documentație limitată de integrare legată de configurarea procesului de construire în arhiva de documente. Cu toate acestea, codul Yandex face referire și la wiki-uri interne, dar acestea nu s-au scurs și comentariile din cod sunt, de asemenea, destul de rare.

Din fericire, Yandex oferă câteva informații despre arhitectura sa în documentația sa publică. Există, de asemenea, câteva brevete pe care le-au publicat în SUA care ajută la aruncarea de lumină. Și anume:

• Metodă implementată pe calculator și sistem pentru căutarea unui index inversat având o multitudine de liste de postare
• Clasamentul rezultatelor căutării

Pe măsură ce am cercetat Google pentru cartea mea, am dezvoltat o înțelegere mult mai profundă a structurii sistemelor sale de clasare prin diverse documente albe, brevete și discuții de la ingineri formulate pe baza experienței mele SEO. De asemenea, mi-am petrecut mult timp înțelegându-mi cele mai bune practici generale de regăsire a informațiilor pentru motoarele de căutare web. Nu este o surpriză că există într-adevăr unele bune practici și asemănări în joc cu Yandex.

Documentația Yandex discută despre un sistem de crawler cu dublă distribuție. Unul pentru crawling în timp real numit „Orange Crawler” și altul pentru crawling general.

Din punct de vedere istoric, se spune că Google a avut un index stratificat în trei compartimente, unul pentru accesarea cu crawlere în timp real, unul pentru accesul cu crawlere în mod regulat și unul pentru accesarea cu crawlere rar. Această abordare este considerată cea mai bună practică în RI.

Yandex și Google diferă în acest sens, dar ideea generală de crawling segmentat determinată de înțelegerea frecvenței de actualizare este valabilă.

Un lucru care merită menționat este că Yandex nu are un sistem de randare separat pentru JavaScript. Ei spun acest lucru în documentația lor și, deși au un sistem bazat pe Webdriver pentru testarea regresiei vizuale numit Gemini, se limitează la accesarea cu crawlere bazată pe text.

Documentația discută, de asemenea, o structură de bază de date fragmentată care descompune paginile într-un index inversat și un server de documente.

La fel ca majoritatea celorlalte motoare de căutare web, procesul de indexare construiește un dicționar, memorează pagini și apoi plasează date în indexul inversat, astfel încât bigramele și trigamurile și plasarea lor în document să fie reprezentate.

Acest lucru diferă de Google prin faptul că au trecut la indexarea bazată pe fraze, adică n-grame care pot fi mult mai lungi decât trigramele cu mult timp în urmă.

Cu toate acestea, sistemul Yandex folosește și BERT în pipeline, astfel încât, la un moment dat, documentele și interogările sunt convertite în înglobări și sunt folosite tehnici de căutare a celui mai apropiat vecin pentru clasare.

Procesul de clasare este locul în care lucrurile încep să devină mai interesante.

Yandex are un strat numit Metasearch în care rezultatele căutării populare stocate în cache sunt difuzate după ce procesează interogarea. Dacă rezultatele nu sunt găsite acolo, atunci interogarea de căutare este trimisă simultan la o serie de mii de mașini diferite în stratul Căutare de bază . Fiecare construiește o listă de postare a documentelor relevante, apoi o returnează la MatrixNet, aplicația de rețea neuronală Yandex pentru re-clasificare, pentru a construi SERP.

Pe baza videoclipurilor în care inginerii Google au vorbit despre infrastructura Căutării, acel proces de clasare este destul de similar cu Căutarea Google. Ei vorbesc despre tehnologia Google în medii partajate în care diferite aplicații sunt pe fiecare mașină și locurile de muncă sunt distribuite pe acele mașini în funcție de disponibilitatea puterii de calcul.

Unul dintre cazurile de utilizare este exact acesta, distribuirea de interogări către un sortiment de mașini pentru a procesa rapid fragmentele de index relevante. Calcularea listelor de postare este primul loc în care trebuie să luăm în considerare factorii de clasare.

Există 17.854 de factori de clasare în baza de cod

Vinerea următoare scurgerii, inimitabilul Martin MacDonald a distribuit cu nerăbdare un fișier din baza de cod numit web_factors_info/factors_gen.in. Fișierul provine din arhiva „Kernel” din scurgerea bazei de cod și conține 1.922 de factori de clasare.

Desigur, comunitatea SEO a folosit acel număr și acel fișier pentru a răspândi cu nerăbdare știrile despre informațiile din acesta. Mulți oameni au tradus descrierile și au creat instrumente sau Foi de calcul Google și ChatGPT pentru a înțelege datele. Toate acestea sunt exemple grozave ale puterii comunității. Cu toate acestea, 1.922 reprezintă doar unul dintre multele seturi de factori de clasare din baza de cod.

O scufundare mai profundă în baza de cod dezvăluie că există numeroase fișiere cu factori de clasare pentru diferite subseturi ale sistemelor de procesare și clasificare a interogărilor Yandex.

Trecând peste acestea, aflăm că există de fapt 17.854 de factori de clasare în total. În acești factori de clasare sunt incluse o varietate de valori legate de:

• Clicuri.
• Timp de locuire.
• Folosind echivalentul Google Analytics al Yandex, Metrika.

Există, de asemenea, o serie de notebook-uri Jupyter care au încă 2.000 de factori în afara celor din codul de bază. Probabil, aceste notebook-uri Jupyter reprezintă teste în care inginerii iau în considerare factori suplimentari de adăugat la baza de cod. Din nou, puteți examina toate aceste funcții cu metadatele pe care le-am colectat din întreaga bază de cod, la acest link.

Documentația Yandex clarifică în continuare că aceștia au trei clase de factori de clasare: statici, dinamici și cei care au legătură în mod specific cu căutarea utilizatorului și modul în care a fost efectuată. Cu propriile lor cuvinte:

În baza de cod, acestea sunt indicate în fișierele factorilor de rang cu etichetele TG_STATIC și TG_DYNAMIC. Factorii legați de căutare au mai multe etichete, cum ar fi TG_QUERY_ONLY, TG_QUERY, TG_USER_SEARCH și TG_USER_SEARCH_ONLY.

Deși am descoperit potențiali 18.000 de factori de clasare din care să alegeți, documentația legată de MatrixNet indică faptul că scorul este construit din zeci de mii de factori și personalizat pe baza interogării de căutare.

Acest lucru indică faptul că mediul de clasare este foarte dinamic, similar cu cel al mediului Google. Conform patentului Google „Cadru pentru evaluarea funcțiilor de punctare”, acestea au de mult timp ceva similar în care sunt rulate mai multe funcții și se returnează cel mai bun set de rezultate.

În sfârșit, având în vedere că documentația face referire la zeci de mii de factori de clasare, ar trebui să ținem cont și că există multe alte fișiere la care se face referire în cod care lipsesc din arhivă. Deci, probabil că se întâmplă mai multe pe care nu le putem vedea. Acest lucru este ilustrat în continuare prin revizuirea imaginilor din documentația de îmbarcare care arată alte directoare care nu sunt prezente în arhivă.

De exemplu, bănuiesc că există mai multe legate de DSSM în directorul /semantic-search/.

Ponderea inițială a factorilor de clasare

Am operat mai întâi presupunând că baza de cod nu avea nicio pondere pentru factorii de clasare. Apoi am fost șocat să văd că fișierul nav_linear.h din directorul /search/relevance/ prezintă coeficienții inițiali (sau ponderile) asociate cu factorii de clasare pe afișaj complet.

Această secțiune a codului evidențiază 257 din cei peste 17.000 de factori de clasare pe care i-am identificat. ( Sfat de pălărie lui Ryan Jones pentru că le-a tras și le-a aliniat cu descrierile factorilor de clasare.)

Pentru claritate, atunci când te gândești la un algoritm de motor de căutare, probabil că te gândești la o ecuație matematică lungă și complexă prin care fiecare pagină este punctată pe baza unei serii de factori. Deși aceasta este o simplificare excesivă, următoarea captură de ecran este un extras dintr-o astfel de ecuație. Coeficienții reprezintă cât de important este fiecare factor și scorul calculat rezultat este ceea ce ar fi folosit pentru a nota paginile de selectare pentru relevanță.

Aceste valori fiind codificate în mod greu sugerează că acesta nu este cu siguranță singurul loc în care are loc clasarea. În schimb, această funcție este cel mai probabil în cazul în care scorul de relevanță inițial este realizat pentru a genera o serie de liste de postare pentru fiecare fragment luat în considerare pentru clasare. În primul brevet enumerat mai sus, ei vorbesc despre acest lucru ca fiind un concept de relevanță independentă de interogare (QIR) care limitează apoi documentele înainte de a le revizui pentru relevanța specifică interogării (QSR).

Listele de postare rezultate sunt apoi transmise la MatrixNet cu funcții de interogare cu care se pot compara. Așadar, deși nu cunoaștem detaliile operațiunilor din aval (încă), aceste ponderi sunt încă valoroase de înțeles, deoarece vă spun cerințele pentru ca o pagină să fie eligibilă pentru setul de considerații.

Cu toate acestea, aceasta aduce următoarea întrebare: ce știm despre MatrixNet?

Există cod de clasare neuronală în arhiva Kernel și există numeroase referințe la MatrixNet și „mxnet”, precum și multe referințe la modele semantice structurate profunde (DSSM) în întreaga bază de cod.

Descrierea unuia dintre factorii de clasare FI_MATRIXNET indică faptul că MatrixNet se aplică tuturor factorilor.

factor {

Index: 160

CppName: „FI_MATRIXNET”

Nume: „MatrixNet”

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

Descriere: „MatrixNet se aplică tuturor factorilor – formula”

}

Există, de asemenea, o grămadă de fișiere binare care pot fi chiar modelele pre-antrenate, dar îmi va lua mai mult timp să dezleg acele aspecte ale codului.

Ceea ce este imediat clar este că există mai multe niveluri de clasare (L1, L2, L3) și există un sortiment de modele de clasare care pot fi selectate la fiecare nivel.

Fișierul selecting_rankings_model.cpp sugerează că pot fi luate în considerare diferite modele de clasare la fiecare strat pe parcursul procesului. Practic, așa funcționează rețelele neuronale. Fiecare nivel este un aspect care finalizează operațiunile, iar calculele lor combinate generează lista re-clasificată de documente care în cele din urmă apare ca un SERP. Voi continua cu o scufundare profundă pe MatrixNet când voi avea mai mult timp. Pentru cei care au nevoie de o scurtă privire, consultați brevetul pentru clasarea rezultatelor căutării.

Deocamdată, să aruncăm o privire la câțiva factori interesanți de clasare.

Top 5 factori de clasare inițial ponderați negativ

Următoarea este o listă cu cei mai înalți factori de clasare inițial ponderați negativ cu ponderile lor și o scurtă explicație bazată pe descrierile lor traduse din rusă.

1. FI_ADV: -0.2509284637 -Acest factor determină faptul că există publicitate de orice fel pe pagină și emite cea mai mare penalizare ponderată pentru un singur factor de clasare.
2. FI_DATER_AGE: -0,2074373667 – Acest factor este diferența dintre data curentă și data documentului determinată de o funcție de datare. Valoarea este 1 dacă data documentului este aceeași cu cea de astăzi, 0 dacă documentul are 10 ani sau mai mult sau dacă data nu este definită. Acest lucru indică faptul că Yandex are o preferință pentru conținutul mai vechi.
3. FI_QURL_STAT_POWER: -0,1943768768 – Acest factor este numărul de afișări URL în legătură cu interogarea. Se pare că ar dori să retrogradeze o adresă URL care apare în multe căutări pentru a promova diversitatea rezultatelor.
4. FI_COMM_LINKS_SEO_HOSTS: -0,1809636391 – Acest factor este procentul de link-uri de intrare cu text de ancorare „comercial”. Factorul revine la 0,1 dacă proporția unor astfel de legături este mai mare de 50%, în caz contrar, este setat la 0.
5. FI_GEO_CITY_URL_REGION_COUNTRY: -0,168645758 – Acest factor este coincidența geografică a documentului și țara din care a căutat utilizatorul. Acesta nu prea are sens dacă 1 înseamnă că documentul și țara se potrivesc.

Pe scurt, acești factori indică faptul că, pentru cel mai bun scor, ar trebui să:

• Evitați reclamele.
• Actualizați conținutul mai vechi în loc să creați pagini noi.
• Asigurați-vă că cele mai multe dintre link-urile dvs. au text ancora de marcă.

Orice altceva din această listă este în afara controlului tău.

Top 5 factori de clasare inițial ponderați pozitiv

Pentru a continua, iată o listă a celor mai ponderați factori de clasare pozitivi.

1. FI_URL_DOMAIN_FRACTION: +0,5640952971 – Acest factor este o suprapunere ciudată de mascare a interogării față de domeniul adresei URL. Exemplul dat este loteria Chelyabinsk care abreviat ca chelloto. Pentru a calcula această valoare, Yandex găsește trei litere care sunt acoperite (che, hel, lot, olo), vezi ce proporție din toate combinațiile de trei litere sunt în numele domeniului.
2. FI_QUERY_DOWNER_CLICKS_COMBO: +0.3690780393 – Descrierea acestui factor este „combinată inteligent de FRC și pseudo-CTR”. Nu există nicio indicație imediată despre ce este FRC.
3. FI_MAX_WORD_HOST_CLICKS: +0,3451158835 – Acest factor este posibilitatea de a face clic pe cel mai important cuvânt din domeniu. De exemplu, pentru toate interogările în care există cuvântul „wikipedia” faceți clic pe paginile wikipedia.
4. FI_MAX_WORD_HOST_YABAR: +0.3154394573 – Descrierea factorului spune „cel mai caracteristic cuvânt de interogare corespunzător site-ului, conform barei”. Presupun că acesta înseamnă cuvântul cheie cel mai căutat în Bara de instrumente Yandex asociată site-ului.
5. FI_IS_COM: +0.2762504972 – Factorul este că domeniul este un .COM.

Cu alte cuvinte:

• Joacă jocuri de cuvinte cu domeniul tău.
• Asigurați-vă că este un punct com.
• Încurajați oamenii să caute cuvintele cheie țintă în bara Yandex.
• Continuați să generați clicuri.

Există o mulțime de factori de clasare inițial neaștepți

Ceea ce este mai interesant în factorii de clasare ponderați inițiali sunt cei neaștepți. Următoarea este o listă a șaptesprezece factori care s-au evidențiat.

1. FI_PAGE_RANK: +0,1828678331 – PageRank este al 17-lea cel mai mare factor ponderat din Yandex. Anterior, au eliminat complet link-urile din sistemul lor de clasare, așa că nu este prea șocant cât de jos este pe listă.
2. FI_SPAM_KARMA: +0.00842682963 – Karma de spam este numită după „antispammeri” și reprezintă probabilitatea ca gazda să fie spam; pe baza informațiilor Whois
3. FI_SUBQUERY_THEME_MATCH_A: +0,1786465163 – Cât de strâns se potrivesc tematic interogarea și documentul. Acesta este al 19-lea cel mai mare factor ponderat.
4. FI_REG_HOST_RANK: +0,1567124399 – Yandex are un factor de clasare pentru gazdă (sau domeniu).
5. FI_URL_LINK_PERCENT: +0,08940421124 – Raportul dintre linkurile al căror text de ancorare este o adresă URL (mai degrabă decât text) față de numărul total de linkuri.
6. FI_PAGE_RANK_UKR: +0.08712279101 – Există un anumit PageRank ucrainean
7. FI_IS_NOT_RU: +0.08128946612 – Este un lucru pozitiv dacă domeniul nu este un .RU. Aparent, motorul de căutare rus nu are încredere în site-urile rusești.
8. FI_YABAR_HOST_AVG_TIME2: +0,07417219313 – Acesta este timpul mediu de așteptare raportat de YandexBar
9. FI_LERF_LR_LOG_RELEV: +0.06059448504 – Aceasta este relevanța legăturii bazată pe calitatea fiecărei legături
10. FI_NUM_SLASHES: +0,05057609417 – Numărul de bare oblice din adresa URL este un factor de clasare.
11. FI_ADV_PRONOUNS_PORTION: -0,001250755075 – Proporția numelor pronume de pe pagină.
12. FI_TEXT_HEAD_SYN: -0.01291908335 – Prezența cuvintelor [interogare] în antet, ținând cont de sinonime
13. FI_PERCENT_FREQ_WORDS: -0.02021022114 – Procentul din numărul de cuvinte, care sunt cele 200 de cuvinte cele mai frecvente ale limbii, din numărul tuturor cuvintelor din text.
14. FI_YANDEX_ADV: -0,09426121965 – Devenind mai specific cu dezgustul față de reclame, Yandex penalizează paginile cu anunțuri Yandex.
15. FI_AURA_DOC_LOG_SHARED: -0,09768630485 – Logaritmul numărului de șindrilă (zone de text) din document care nu sunt unice.
16. FI_AURA_DOC_LOG_AUTHOR: -0,09727752961 – Logaritmul numărului de șindrilă pe care acest proprietar al documentului este recunoscut ca autor.
17. FI_CLASSIF_IS_SHOP: -0.1339319854 – Aparent, Yandex vă va oferi mai puțină dragoste dacă pagina dvs. este un magazin.

Principala concluzie din revizuirea acestor factori de clasare ciudați și a gamei celor disponibile în baza de cod Yandex este că există multe lucruri care ar putea fi un factor de clasare.

Bănuiesc că „200 de semnale” raportate de Google sunt de fapt 200 de clase de semnal în care fiecare semnal este un compus compus din multe alte componente. În același mod în care Google Analytics are dimensiuni cu multe valori asociate, Căutarea Google are probabil clase de semnale de clasare compuse din multe caracteristici.

Yandex zgârie Google, Bing, YouTube și TikTok

Baza de cod dezvăluie, de asemenea, că Yandex are multe analizoare pentru alte site-uri web și serviciile respective. Pentru occidentali, cele mai notabile dintre acestea sunt cele pe care le-am enumerat în titlul de mai sus. În plus, Yandex are analizatoare pentru o varietate de servicii pe care nu le cunoșteam, precum și cele pentru propriile servicii.

Ceea ce este imediat evident este că analizatorii sunt complet complet. Fiecare componentă semnificativă a SERP Google este extrasă. De fapt, oricine ar putea lua în considerare eliminarea oricăruia dintre aceste servicii ar putea face bine să revizuiască acest cod.

Există un alt cod care indică că Yandex folosește unele date Google ca parte a calculelor DSSM, dar cei 83 de factori de clasare denumiți de Google arată clar că Yandex s-a sprijinit destul de mult pe rezultatele Google.

Evident, Google nu va retrage niciodată mișcarea Bing de a copia rezultatele unui alt motor de căutare și nici nu se va baza pe unul pentru calculele de clasare de bază.

Yandex are limite superioare anti-SEO pentru anumiți factori de clasare

315 factori de clasare au praguri la care orice valoare calculată dincolo de aceasta indică sistemului că acea caracteristică a paginii este supraoptimizată. 39 dintre acești factori de clasare fac parte din factorii ponderați inițial care pot împiedica o pagină să fie inclusă în lista de postări inițiale. Le puteți găsi în foaia de calcul la care am legat-o mai sus, prin filtrarea pentru Coeficientul de rang și coloana Anti-SEO.

Din punct de vedere conceptual, nu este exagerat să te aștepți ca toate motoarele de căutare moderne să stabilească praguri pe anumiți factori pe care SEO i-au abuzat în trecut, cum ar fi textul ancora, CTR sau umplerea cuvintelor cheie. De exemplu, se spunea că Bing folosește utilizarea abuzivă a meta cuvintelor cheie ca factor negativ.

Yandex sporește „gazdele vitale”

Yandex are o serie de mecanisme de stimulare în întreaga sa bază de cod. Acestea sunt îmbunătățiri artificiale aduse anumitor documente pentru a se asigura că acestea au un punctaj mai ridicat atunci când sunt luate în considerare pentru clasare.

Mai jos este un comentariu de la „vrăjitorul de creștere” care sugerează că fișierele mai mici beneficiază cel mai bine de algoritmul de creștere.

Există mai multe tipuri de stimulări; Am văzut un impuls legat de link-uri și am văzut, de asemenea, o serie de „HandJobBoosts” despre care pot doar să presupun că este o traducere ciudată a modificărilor „manuale”.

Unul dintre aceste stimulări pe care mi s-a părut deosebit de interesant este legat de „gazde vitale”. Unde o gazdă vitală poate fi orice site specificat. Menționat în mod special în variabile este NEWS_AGENCY_RATING, ceea ce mă face să cred că Yandex oferă un impuls care influențează rezultatele anumitor organizații de știri.

Fără a intra în geopolitică, acest lucru este foarte diferit de Google prin faptul că au fost hotărâți să nu introducă astfel de părtiniri în sistemele lor de clasare.

Structura serverului de documente

Baza de cod dezvăluie cum sunt stocate documentele în serverul de documente Yandex. Acest lucru este util pentru a înțelege că un motor de căutare nu face pur și simplu o copie a paginii și o salvează în memoria cache, ci captează diferite caracteristici ca metadate pentru a le utiliza apoi în procesul de clasare din aval.

Captura de ecran de mai jos evidențiază un subset al acelor caracteristici care sunt deosebit de interesante. Alte fișiere cu interogări SQL sugerează că serverul de documente are mai aproape de 200 de coloane, inclusiv arborele DOM, lungimea propoziției, timpul de preluare, o serie de date și scorul antispam, lanțul de redirecționare și dacă documentul este sau nu tradus. Cea mai completă listă pe care am întâlnit-o este în /robot/rthub/yql/protos/web_page_item.proto.

Ceea ce este cel mai interesant în subsetul de aici este numărul de simhash-uri care sunt folosite. Simhashurile sunt reprezentări numerice ale conținutului, iar motoarele de căutare le folosesc pentru o comparație rapidă pentru determinarea conținutului duplicat. Există diverse situații în arhiva robotului care indică faptul că conținutul duplicat este retrogradat în mod explicit.

De asemenea, ca parte a procesului de indexare, baza de cod include TF-IDF, BM25 și BERT în conducta sa de procesare a textului. Nu este clar de ce toate aceste mecanisme există în cod, deoarece există o oarecare redundanță în utilizarea lor pe toate.

Factori de legătură și prioritizare

Modul în care Yandex gestionează factorii de legătură este deosebit de interesant, deoarece anterior le-au dezactivat cu totul impactul. Baza de cod dezvăluie, de asemenea, o mulțime de informații despre factorii de legătură și despre modul în care linkurile sunt prioritizate.

Calculatorul de spam de linkuri de la Yandex are 89 de factori pe care îi analizează. Orice lucru marcat ca SF_RESERVED este depreciat. Acolo unde sunt furnizate, puteți găsi descrierile acestor factori în foaia Google de mai sus.

În special, Yandex are un rang de gazdă și unele scoruri care par să trăiască pe termen lung după ce un site sau o pagină își dezvoltă o reputație pentru spam.

Un alt lucru pe care îl face Yandex este să examineze copia de pe un domeniu și să determine dacă există conținut duplicat cu acele linkuri. Acestea pot fi destinații de plasare a linkurilor la nivel de site, link-uri pe pagini duplicate sau pur și simplu link-uri cu același text de ancorare care provin de pe același site.

Acest lucru ilustrează cât de trivial este să reduceți mai multe link-uri din aceeași sursă și clarifică cât de important este să vizați mai multe link-uri unice din surse mai diverse.

Ce putem aplica de la Yandex la ceea ce știm despre Google?

Desigur, aceasta este încă întrebarea în mintea tuturor. Deși există cu siguranță multe analogii între Yandex și Google, cu adevărat, doar un inginer de software Google care lucrează la Căutare ar putea răspunde definitiv la această întrebare.

Totuși, aceasta este întrebarea greșită.

Într-adevăr, acest cod ar trebui să ne ajute să ne extindem gândirea despre căutarea modernă. O mare parte din înțelegerea colectivă a căutării este construită din ceea ce comunitatea SEO a învățat la începutul anilor 2000 prin testare și din gurile inginerilor de căutare, când căutarea era mult mai puțin opaca. Din păcate, acest lucru nu a ținut pasul cu ritmul rapid al inovației.

Perspectivele din numeroasele caracteristici și factori ai scurgerii Yandex ar trebui să dea mai multe ipoteze despre lucruri de testat și de luat în considerare pentru clasarea pe Google. De asemenea, ar trebui să introducă mai multe lucruri care pot fi analizate și măsurate prin crawling SEO, analiza link-urilor și instrumente de clasare.

De exemplu, o măsură a similitudinii cosinus între interogări și documente care utilizează încorporarea BERT ar putea fi valoroasă de înțeles față de paginile concurenților, deoarece este ceva pe care motoarele de căutare moderne o fac ei înșiși.

Așa cum jurnalele de căutare AOL ne-au făcut să ghicim distribuția clicurilor pe SERP, baza de cod Yandex ne îndepărtează de la abstract la concret, iar declarațiile noastre „depinde” pot fi mai bine calificate.

În acest scop, această bază de cod este un cadou care va continua să ofere. A trecut doar un weekend și am adunat deja câteva informații foarte convingătoare din acest cod.

Anticipez că unii ingineri SEO ambițioși, cu mult mai mult timp pe mână, vor continua să sape și poate chiar vor completa suficient din ceea ce lipsește pentru a compila acest lucru și a-l face să funcționeze. De asemenea, cred că inginerii de la diferitele motoare de căutare parcurg și analizează inovații din care pot învăța și să le adauge sistemelor lor.

Simultan, avocații Google redactează probabil scrisori de încetare și renunțare agresive legate de toate răzuirea.

Sunt nerăbdător să văd evoluția spațiului nostru care este condusă de oamenii curioși care vor maximiza această oportunitate.

Dar, hei, dacă obținerea de informații din codul real nu este valoroasă pentru dvs., sunteți binevenit să reveniți la ceva mai important, cum ar fi să discutați despre subdomenii versus subdirectoare.