„Fragmenty” bazy kodowej Yandexa wyciekły do sieci w zeszłym tygodniu. Podobnie jak Google, Yandex jest platformą z wieloma aspektami, takimi jak e-mail, mapy, usługa taksówkowa itp. Wyciek kodu zawierał fragmenty tego wszystkiego.
Zgodnie z dokumentacją tam zawartą, baza kodów Yandexa została złożona w jedno duże repozytorium o nazwie Arcadia w 2013 roku. Wyciekła baza kodowa jest podzbiorem wszystkich projektów w Arcadii i znajdziemy w niej kilka komponentów związanych z wyszukiwarką w archiwach „Kernel”, „Library”, „Robot”, „Search” i „ExtSearch”.
Posunięcie to jest całkowicie bezprecedensowe. Nie od czasu danych o zapytaniach do wyszukiwarki AOL z 2006 roku coś tak materialnego związanego z wyszukiwarką internetową weszło do domeny publicznej.
Choć brakuje nam danych i wielu plików, do których się odwołujemy, jest to pierwszy przypadek namacalnego spojrzenia na to, jak działa nowoczesna wyszukiwarka na poziomie kodu.
Osobiście nie mogę wyjść z podziwu, jak fantastycznym momentem jest możliwość zobaczenia kodu, ponieważ kończę moją książkę „The Science of SEO”, w której opowiadam o wyszukiwaniu informacji, o tym, jak faktycznie działają nowoczesne wyszukiwarki i jak samemu zbudować prostą.
W każdym razie, parsowałem przez kod od zeszłego czwartku i każdy inżynier powie ci, że to za mało czasu, aby zrozumieć, jak wszystko działa. Tak więc, podejrzewam, że będzie jeszcze kilka postów jak będę majstrował.
Zanim wskoczymy, chcę dać shout-out do Ben Wills w Ontolo za dzielenie się kodem ze mną, wskazując mi początkowy kierunek, gdzie są dobre rzeczy, i idąc tam i z powrotem ze mną, jak rozszyfrowaliśmy rzeczy. Zapraszam do pobrania arkusza kalkulacyjnego z wszystkimi danymi, które zebraliśmy na temat czynników rankingowych tutaj.
Również, shout out do Ryan Jones za kopanie w i dzielenie się niektórymi kluczowymi ustaleniami ze mną przez IM.
OK, zajmijmy się tym!
To nie jest kod Google, więc dlaczego nas to obchodzi?
Niektórzy uważają, że przeglądanie tej bazy kodów jest rozpraszające i że nie ma nic, co wpłynie na to, jak podejmują decyzje biznesowe. Uważam to za ciekawe, biorąc pod uwagę, że są to ludzie z tej samej społeczności SEO, którzy używali modelu CTR z danych AOL z 2006 roku jako standard przemysłowy dla modelowania w każdej wyszukiwarce przez wiele lat.
To powiedziawszy, Yandex nie jest Google. Jednak obie są najnowocześniejszymi wyszukiwarkami internetowymi, które nadal pozostają na czele technologii.
Inżynierowie oprogramowania z obu firm chodzą na te same konferencje (SIGIR, ECIR, itp.) i dzielą się odkryciami i innowacjami w zakresie Information Retrieval, Natural Language Processing/Understanding i Machine Learning. Yandex jest również obecny w Palo Alto, a Google wcześniej był obecny w Moskwie.
Szybkie wyszukiwanie na LinkedIn ujawnia kilkuset inżynierów, którzy pracowali w obu firmach, chociaż nie wiemy, ilu z nich faktycznie pracowało nad wyszukiwaniem w obu firmach.
W bardziej bezpośredni sposób Yandex wykorzystuje również technologie open source Google, które były krytyczne dla innowacji w wyszukiwarce, takie jak TensorFlow, BERT, MapReduce i, w znacznie mniejszym stopniu, Protocol Buffers.
Tak więc, podczas gdy Yandex z pewnością nie jest Google, nie jest to również jakiś przypadkowy projekt badawczy, o którym tutaj mówimy. Z przeglądu tej bazy kodów możemy się wiele nauczyć o tym, jak zbudowana jest nowoczesna wyszukiwarka.
W każdym razie, możemysabuse ourselves of some obsolete notions that still permeate SEO tools like text-to-code ratios and W3C compliance or the general belief that Google’s 200 signals are simply 200 individual on and off-page features rather than classes of composite factors that potentially use thousands of individual measures.
Trochę kontekstu na temat architektury Yandexa
Bez kontekstu lub zdolności do pomyślnego skompilowania, uruchomienia i kroków przez niego, kod źródłowy jest bardzo trudny do zrozumienia.
Zazwyczaj nowi inżynierowie otrzymują dokumentację, spacery i angażują się w programowanie w parach, aby dostać się do istniejącej bazy kodu. W archiwum docs znajduje się ograniczona dokumentacja związana z konfiguracją procesu budowania. Kod Yandexa odwołuje się również do wewnętrznych wiki, ale te nie wyciekły, a komentowanie w kodzie jest również dość rzadkie.
Na szczęście, Yandex daje trochę wglądu w swoją architekturę w swojej publicznej dokumentacji. Jest też kilka patentów, które opublikował w USA, a które pomagają rzucić trochę światła. Mianowicie:
Jako że badałem Google do mojej książki, rozwinąłem znacznie głębsze zrozumienie struktury jego systemów rankingowych poprzez różne whitepapers, patenty i rozmowy z inżynierami w zestawieniu z moim doświadczeniem SEO. Spędziłem również dużo czasu na doskonaleniu moich umiejętności w zakresie ogólnych praktyk wyszukiwania informacji dla wyszukiwarek internetowych. Nie jest zaskoczeniem, że rzeczywiście istnieją pewne najlepsze praktyki i podobieństwa w grze z Yandexem.
Dokumentacja Yandexa omawia system podwójnie rozproszonych crawlerów. Jeden do indeksowania w czasie rzeczywistym zwany „Orange Crawler” i drugi do ogólnego indeksowania.
Historycznie, Google podobno miał indeks rozwarstwiony na trzy wiadra, jeden dla obudowy w czasie rzeczywistym crawl, jeden dla regularnie crawled i jeden dla rzadko crawled. To podejście jest uważane za najlepszą praktykę w IR.
Yandex i Google różnią się pod tym względem, ale ogólna idea segmentowanego indeksowania napędzanego zrozumieniem częstotliwości aktualizacji trzyma.
Jedną rzeczą, na którą warto zwrócić uwagę jest to, że Yandex nie ma oddzielnego systemu renderowania dla JavaScript. Mówią o tym w swojej dokumentacji i chociaż mają system oparty na Webdriverze do wizualnych testów regresji o nazwie Gemini, ograniczają się do indeksowania tekstowego.
Dokumentacja omawia również strukturę bazy danych sharded, która rozbija strony na odwrócony indeks i serwer dokumentów.
Podobnie jak większość innych wyszukiwarek internetowych, proces indeksowania buduje słownik, buforuje strony, a następnie umieszcza dane w odwróconym indeksie, tak aby bigramy i trygramy oraz ich umiejscowienie w dokumencie były reprezentowane.
Różni się to od Google tym, że przeszli oni na indeksowanie oparte na frazach, czyli n-gramach, które mogą być znacznie dłuższe niż trigramy już dawno temu.
Jednak system Yandex używa BERT w swoim potoku, więc w pewnym momencie dokumenty i zapytania są konwertowane do embeddings i najbliższe techniki wyszukiwania sąsiadów są zatrudnione do rankingu.
Proces rankingowy jest miejscem, gdzie sprawy zaczynają się robić bardziej interesujące.
Yandex posiada warstwę zwaną Metasearch, gdzie po przetworzeniu zapytania serwowane są zbuforowane popularne wyniki wyszukiwania. Jeśli wyniki nie zostaną tam znalezione, wówczas zapytanie jest wysyłane do serii tysięcy różnych maszyn w Basic Search warstwa jednocześnie. Każda z nich buduje listę postów z odpowiednimi dokumentami, a następnie zwraca ją do MatrixNet, aplikacji sieci neuronowej Yandexa służącej do rerankingów, aby zbudować SERP.
Na podstawie filmów, w których inżynierowie Google mówili o infrastrukturze wyszukiwania, że proces rankingowy jest dość podobny do Google Search. Mówią o tym, że technologia Google jest w środowiskach współdzielonych, gdzie różne aplikacje są na każdej maszynie, a zadania są rozdzielane na te maszyny w oparciu o dostępność mocy obliczeniowej.
Jednym z przypadków użycia jest właśnie to, dystrybucja zapytań do różnych maszyn, aby szybko przetworzyć odpowiednie fragmenty indeksu. Obliczanie list postów jest pierwszym miejscem, w którym musimy wziąć pod uwagę czynniki rankingowe.
W
kodzie znajduje się 17 854 czynników ranking
owych
W piątek po wycieku, nieoceniony Martin MacDonald chętnie podzielił się plikiem z kodeka o nazwie web_factors_info/factors_gen.in. Plik pochodzi z archiwum „Kernel” w wycieku kodeksu i zawiera 1,922 czynniki rankingowe.
Naturalnie, społeczność SEO skorzystała z tej liczby i tego pliku, aby z zapałem rozpowszechniać wiadomości o zawartych w nim spostrzeżeniach. Wielu ludzi przetłumaczyło opisy i zbudowało narzędzia lub Google Sheets i ChatGPT, aby nadać sens danym. Wszystko to są wspaniałe przykłady siły społeczności. Jednakże, 1,922 reprezentuje tylko jeden z wielu zestawów czynników rankingowych w bazie kodu.
Głębsze nurkowanie w bazie kodu ujawnia, że istnieje wiele plików czynników rankingowych dla różnych podzbiorów systemów przetwarzania zapytań i rankingu Yandex.
Przeglądając je, okazuje się, że w rzeczywistości istnieje łącznie 17 854 czynników rankingowych. W tych czynnikach rankingowych zawarte są różne metryki związane z:
- Kliknięciami.
- Czas przebywania na stronie.
- Wykorzystanie odpowiednika Google Analytics firmy Yandex, Metrika.
Istnieje również seria notatników Jupyter, które mają dodatkowe 2000 czynników poza tymi w kodzie głównym. Przypuszczalnie te notatniki Jupytera reprezentują testy, w których inżynierowie rozważają dodatkowe czynniki do dodania do bazy kodu. Ponownie, możesz przejrzeć wszystkie te funkcje z metadanymi, które zebraliśmy z całej bazy kodów pod tym linkiem.
Dokumentacja Yandexa dalej wyjaśnia, że mają trzy klasy czynników rankingowych: Statyczne, Dynamiczne i te związane konkretnie z wyszukiwaniem użytkownika i sposobem jego wykonania. Według ich własnych słów:
W codebase są one wskazane w plikach czynników rankingowych za pomocą tagów TG_STATIC i TG_DYNAMIC. Czynniki związane z wyszukiwaniem mają wiele tagów, takich jak TG_QUERY_ONLY, TG_QUERY, TG_USER_SEARCH i TG_USER_SEARCH_ONLY.
Podczas gdy my odkryliśmy potencjalne 18k czynników rankingowych do wyboru, dokumentacja związana z MatrixNet wskazuje, że scoring jest budowany z dziesiątek tysięcy czynników i dostosowywany na podstawie zapytania wyszukiwania.
To wskazuje, że środowisko rankingowe jest bardzo dynamiczne, podobne do środowiska Google. Zgodnie z patentem Google „Framework for evaluating scoring functions”, od dawna mają oni coś podobnego, gdzie uruchamianych jest wiele funkcji i zwracany jest najlepszy zestaw wyników.
Wreszcie, biorąc pod uwagę, że dokumentacja odwołuje się do dziesiątek tysięcy czynników rankingowych, powinniśmy również pamiętać, że tjest wiele innych plików, do których odwołuje się kod, a których brakuje w archiwum. Tak więc, prawdopodobnie dzieje się więcej, że nie jesteśmy w stanie zobaczyć. Jest to dodatkowo zilustrowane przez przeglądanie obrazów w dokumentacji onboardingowej, która pokazuje inne katalogi, które nie są obecne w archiwum.
Na przykład podejrzewam, że w katalogu /semantic-search/ znajduje się więcej elementów związanych z DSSM.
Początkowe ważenie czynników rankingowych
Najpierw działałem przy założeniu, że baza kodowa nie miała żadnych wag dla czynników rankingowych. Potem byłem zszokowany, gdy zobaczyłem, że plik nav_linear.h w katalogu /search/relevance/ zawiera w pełni widoczne początkowe współczynniki (lub wagi) związane z czynnikami rankingowymi.
Ta część kodu podkreśla 257 z ponad 17 000 czynników rankingowych, które zidentyfikowaliśmy. (Czapka zgłów dla Ryana Jonesa za wyciągnięcie tych czynników i połączenie ich z opisami czynników rankingowych).
Dla jasności, kiedy myślisz o algorytmie wyszukiwarki, prawdopodobnie masz na myśli długie i złożone równanie matematyczne, w którym każda strona jest oceniana na podstawie serii czynników. Choć jest to zbytnie uproszczenie, poniższy zrzut ekranu jest fragmentem takiego równania. Współczynniki reprezentują jak ważny jest każdy czynnik, a wyliczony wynik jest tym, co byłoby użyte do oceny stron selekcjonera pod kątem relewancji.
Wartości te są zakodowane na sztywno, co sugeruje, że z pewnością nie jest to jedyne miejsce, w którym dzieje się ranking. Zamiast tego, ta funkcja jest najprawdopodobniej, gdzie początkowa ocena relewancji jest wykonywana, aby wygenerować serię list postów dla każdego sharda, który jest rozważany do rankingu. W pierwszym patencie wymienionym powyżej, mówią o tym jako o koncepcji query-independent relevance (QIR), która następnie ogranicza dokumenty przed przeglądaniem ich pod kątem query-specific relevance (QSR).
Powstałe listy postów są następnie przekazywane do MatrixNet z cechami zapytania do porównania. Tak więc, chociaż nie znamy szczegółów operacji downstream (jeszcze), te wagi są nadal cenne do zrozumienia, ponieważ mówią o wymaganiach dla strony, aby kwalifikować się do zestawu rozważań.
To jednak rodzi kolejne pytanie: co wiemy o MatrixNet?
W archiwum Kernela znajduje się kod rankingu neuronowego, a w całej bazie kodowej są liczne odniesienia do MatrixNet i „mxnet”, a także wiele odniesień do Deep Structured Semantic Models (DSSM).
Opis jednego z czynników rankingu FI_MATRIXNET wskazuje, że MatrixNet jest stosowany do wszystkich czynników.
Factor {
Index: 160
CppName: „FI_MATRIXNET
” Name: „Mat
rixNet
” Tags: [TG_DOC, TG_DYNAMIC, TG_TRANS, TG_NOT_01, TG_REARR_USE, TG_L3_MODEL_VALUE, TG_ŚWIEŻOŚĆ_ZAMROŻONA_POOL].
Opis: „MatrixNet jest stosowany do wszystkich czynników – wzór
”
}
Istnieje również garść plików binarnych, które mogą być samymi wstępnie wyszkolonymi modelami, ale zajmie mi więcej czasu, aby rozwikłać te aspekty kodu.
Od razu widać, że istnieje wiele poziomów rankingu (L1, L2, L3) i istnieje asortyment modeli rankingowych, które można wybrać na każdym poziomie.
The selecting_rankings_model.cpp plik sugeruje, że różne modele rankingowe mogą być rozważane w każdej warstwie w całym procesie. To jest w zasadzie jak sieci neuronowe działają. Każdy poziom jest aspektem, który kończy operacje, a ich łączne obliczenia dają ponownie uszeregowaną listę dokumentów, które ostatecznie pojawiają się jako SERP. Będę śledzić z głębokim nurkowania na MatrixNet, kiedy mam więcej czasu. Dla tych, którzy potrzebują sneak peek, sprawdź patent Search result ranker.
Na razie przyjrzyjmy się kilku ciekawym czynnikom rankingowym.
Top 5 negatywnie ważonych początkowych czynników
rankingowych
Poniżej znajduje się lista najwyższych negatywnie ważonych początkowych czynników rankingowych z ich wagami i krótkim wyjaśnieniem na podstawie ich opisów przetłumaczonych z języka rosyjskiego
.
- FI_ADV: -0.2509284637 – Czynnik ten określa, że na stronie znajduje się jakakolwiek reklama i wydaje najcięższą ważoną karę dla pojedynczego czynnika rankingowego.
- FI_DATER_AGE: -0.2074373667 – Współczynnik ten jest różnicą pomiędzy datą bieżącą a datą dokumentu wyznaczoną przez funkcję dater. Wartość wynosi 1, jeśli data dokumentu jest taka sama jak dzisiejsza, 0, jeśli dokument jest 10 lat lub starszy, lub jeśli data nie jest określona. Wskazuje to, że Yandex ma preferencje dla starszych treści.
- FI_QURL_STAT_POWER: -0,1943768768 – Ten współczynnik to liczba wyświetleń URL, jak to się odnosi do zapytania. Wygląda na to, że chcą zdegradować adres URL, który pojawia się w wielu wyszukiwaniach, aby promować różnorodność wyników.
- FI_COMM_LINKS_SEO_HOSTS: -0,1809636391 – Ten czynnik to procent linków przychodzących z „komercyjnym” anchor textem. Współczynnik powraca do wartości 0,1 jeśli udział takich linków jest większy niż 50%, w przeciwnym razie ustawiany jest na 0.
- FI_GEO_CITY_URL_REGION_COUNTRY: -0.168645758 – Współczynnik ten to zbieżność geograficzna dokumentu i kraju, z którego szukał użytkownik. Ten nie do końca ma sens, skoro 1 oznacza, że dokument i kraj pasują do siebie.
Podsumowując, czynniki te wskazują, że aby uzyskać najlepszy wynik, powinieneś:
- Unikać reklam.
- Aktualizować starsze treści, a nie tworzyć nowe strony.
- Upewnić się, że większość Twoich linków ma markowy anchor text.
Wszystko inne na tej liście jest poza Twoją kontrolą.
Top 5 pozytywnie ważonych wstępnych czynników rankingowych
Aby kontynuować, oto lista najwyżej ważonych pozytywnych czynników rankingowych.
- FI_URL_DOMAIN_FRACTION: +0.5640952971 – Ten czynnik to dziwne maskujące nakładanie się zapytania na domenę adresu URL. Podany przykład to loteria czelabińska, która w skrócie nazywana jest chelloto. Aby obliczyć tę wartość, Yandex znaleźć trzy litery, które są pokryte (che, hel, lot, olo), zobacz, jaka część wszystkich kombinacji trzyliterowych znajduje się w nazwie domeny.
- FI_QUERY_DOWNER_CLICKS_COMBO: +0,3690780393 – Opis tego czynnika jest taki, że jest to „sprytne połączenie FRC i pseudo-CTR”. Nie ma bezpośredniej wskazówki, czym jest FRC.
- FI_MAX_WORD_HOST_CLICKS: +0,3451158835 – Ten czynnik to klikalność najważniejszego słowa w domenie. Na przykład dla wszystkich zapytań, w których występuje słowo „wikipedia” klikaj na strony wikipedii.
- FI_MAX_WORD_HOST_YABAR: +0,3154394573 – Opis czynnika mówi o „najbardziej charakterystycznym słowie zapytania odpowiadającym stronie, według paska”. Zakładam, że.ng oznacza to słowo kluczowe najczęściej wyszukiwane w Yandex Toolbar związane z witryną.
- FI_IS_COM: +0.2762504972 – Czynnikiem jest to, że domena jest .COM.
Innymi słowy:
- Graj w gry słowne ze swoją domeną.
- Upewnij się, że jest to kropka com.
- Zachęcaj ludzi do wyszukiwania swoich docelowych słów kluczowych w pasku Yandex.
- Nieustannie napędzaj kliknięcia.
Jest mnóstwo nieoczekiwanych początkowych czynników rankingowych
Co ciekawsze w początkowych ważonych czynnikach rankingowych są te nieoczekiwane. Poniżej znajduje się lista siedemnastu czynników, które się wyróżniały.
- FI_PAGE_RANK: +0,1828678331 – PageRank jest siedemnastym najwyżej ważonym czynnikiem w Yandexie. Wcześniej całkowicie usunęli linki ze swojego systemu rankingowego, więc nie jest zbyt szokujące, jak nisko jest na liście.
- FI_SPAM_KARMA: +0.00842682963 – Karma Spam jest nazwana na cześć „antyspamerów” i jest prawdopodobieństwem, że host jest spamem; na podstawie informacji Whois
- FI_SUBQUERY_THEME_MATCH_A: +0.1786465163 – Jak blisko zapytanie i dokument pasują tematycznie. Jest to 19. najwyżej ważony czynnik.
- FI_REG_HOST_RANK: +0.1567124399 – Yandex posiada czynnik rankingu hosta (lub domeny).
- FI_URL_LINK_PERCENT: +0.08940421124 – Stosunek linków, których anchor text jest adresem URL (a nie tekstem) do całkowitej liczby linków.
- FI_PAGE_RANK_UKR: +0.08712279101 – Istnieje specyficzny Ukranian PageRank.
- FI_IS_NOT_RU: +0.08128946612 – Pozytywne jest, jeśli domena nie jest .RU. Najwyraźniej rosyjska wyszukiwarka nie ufa rosyjskim stronom.
- FI_YABAR_HOST_AVG_TIME2: +0.07417219313 – Jest to średni czas przebywania na stronie podany przez YandexBar
- FI_LERF_LR_LOG_RELEV: +0.06059448504 – Jest to istotność linku na podstawie jakości każdego linku
- FI_NUM_SLASHES: +0.05057609417 – Liczba ukośników w adresie URL jest czynnikiem rankingowym.
- FI_ADV_PRONOUNS_PORTION: -0.001250755075 – Udział rzeczowników zaimkowych na stronie.
- FI_TEXT_HEAD_SYN: -0.01291908335 – Obecność słów [zapytanie] w nagłówku, z uwzględnieniem synonimów
- FI_PERCENT_FREQ_WORDS: -0.02021022114 – Procentowy udział liczby słów, które są 200 najczęstszymi słowami języka, od liczby wszystkich słów tekstu.
- FI_YANDEX_ADV: -0.09426121965 – Uściślając niechęć do reklam, Yandex penalizuje strony z reklamami Yandexa.
- FI_AURA_DOC_LOG_SHARED: -0.09768630485 – Logarytm z liczby shingli (obszarów tekstu) w dokumencie, które nie są unikalne.
- FI_AURA_DOC_LOG_AUTHOR: -0.09727752961 – Logarytm liczby gontów, na których ten właściciel dokumentu jest rozpoznany jako autor.
- FI_CLASSIF_IS_SHOP: -0.1339319854 – Najwyraźniej Yandex będzie cię mniej kochał, jeśli twoja strona jest sklepem.
Podstawowym wnioskiem z przeglądu tych dziwnych czynników rankingowych i tablicy tych czynników dostępnych w całej bazie kodów Yandex jest to, że istnieje wiele rzeczy, które mogą być czynnikiem rankingowym.
Podejrzewam, że zgłoszone przez Google „200 sygnałów” to tak naprawdę 200 klas sygnałów, gdzie każdy sygnał jest kompozycją zbudowaną z wielu innych składników. W podobny sposób, w jaki Google Analytics ma wymiary z wieloma powiązanymi metrykami, Google Search prawdopodobnie ma klasy rankingowe.g sygnały złożone z wielu funkcji.
Yandex scrapuje Google, Bing, YouTube i TikTok
Baza kodów ujawnia również, że Yandex ma wiele parserów dla innych stron internetowych i ich odpowiednich usług. Dla ludzi Zachodu najbardziej godne uwagi są te, które wymieniłem w nagłówku powyżej. Dodatkowo, Yandex posiada parsery dla różnych usług, których nie znałem, jak również dla swoich własnych usług.
Co jest natychmiast widoczne, to fakt, że parsery są kompletne. Każdy znaczący element Google SERP jest wyodrębniony. W rzeczywistości, każdy, kto może być rozważa scraping żadnej z tych usług może zrobić dobrze, aby przejrzeć ten kod.
Istnieje inny kod, który wskazuje, że Yandex używa niektórych danych Google w ramach obliczeń DSSM, ale 83 czynniki rankingowe nazwane przez Google same w sobie dają jasno do zrozumienia, że Yandex oparł się na wynikach Google dość mocno.
Oczywiście, Google nigdy nie pociągnie za sobą ruchu Binga, polegającego na kopiowaniu wyników innej wyszukiwarki, ani nie będzie zależny od jednej z nich w zakresie podstawowych obliczeń rankingowych.
Yandex ma anty-SEO górne granice dla niektórych czynników rankingowych
315 czynników rankingowych ma progi, w których każda obliczona wartość poza tym wskazuje systemowi, że ta cecha strony jest nadmiernie zoptymalizowana. 39 z tych czynników rankingowych jest częścią początkowo ważonych czynników, które mogą sprawić, że strona nie znajdzie się na początkowej liście postów. Możesz je znaleźć w arkuszu kalkulacyjnym, do którego linkowałem powyżej, filtrując dla współczynnika Rank i kolumny Anti-SEO.
Nie jest daleko idącą koncepcją oczekiwanie, że wszystkie nowoczesne wyszukiwarki ustalają progi dla pewnych czynników, których SEOwcy historycznie nadużywali, takich jak anchor text, CTR lub keyword stuffing. Na przykład, Bing miał wykorzystać nadużywanie meta keywords jako negatywny czynnik.
Yandex boostuje „Vital Hosts
” Yandex
ma serię mechanizmów boostowania w całej swojej bazie kodu. Są to sztuczne ulepszenia pewnych dokumentów, aby zapewnić im wyższy wynik przy rozpatrywaniu ich w rankingu.
Poniżej znajduje się komentarz „boosting wizard”, który sugeruje, że mniejsze pliki najlepiej korzystają z algorytmu boosting.
Istnieje kilka rodzajów boostów; widziałem jeden boost związany z linkami i widziałem też serię „HandJobBoosts”, co mogę tylko przypuszczać, że jest dziwnym tłumaczeniem „ręcznych” zmian.
Jeden z tych boostów, który uznałem za szczególnie interesujący jest związany z „Vital Hosts”. Gdzie żywotny gospodarz może być dowolna strona określona. Szczególnie wspomniane w zmiennych jest NEWS_AGENCY_RATING, co prowadzi mnie do przekonania, że Yandex daje impuls, który uprzedza jego wyniki do niektórych organizacji informacyjnych.
Bez wchodzenia w geopolitykę, to bardzo różni się od Google, że były nieugięte o nie wprowadzanie stronniczości jak to do swoich systemów rankingowych.
Struktura serwera dokumentów
Baza kodów ujawnia, jak dokumenty są przechowywane w serwerze dokumentów Yandex. Jest to pomocne w zrozumieniu, że wyszukiwarka nie robi po prostu kopii strony i zapisuje ją w swojej pamięci podręcznej, ale przechwytuje różne cechy jako metadane, które są następnie wykorzystywane w dalszych procesach rankingowych.
Poniższy zrzut ekranu podkreśla podzbiór tych cech, które są szczególnie interesujące. Inne pliki z zapytaniami SQL sugerują, że serwer dokumentów ma bliżej 200 kolumn, w tym drzewo DOM, długość zdań, czas pobierania, serię dat, wynik antyspamowy, łańcuch przekierowań i to, czy dokument jest przetłumaczony, czy nie. Najbardziej kompletna lista, na jaką się natknąłem, znajduje się w /robot/rthub/yql/protos/web_page_item.proto.
To, co jest najbardziej interesujące w tym podzbiorze, to liczba simhashes, które są zatrudnione. Simhashes są numerycznymi reprezentacjami treści i wyszukiwarki używają ich do błyskawicznego porównania w celu określenia zduplikowanej treści. W archiwum robota są różne przypadki, które wskazują, że zduplikowana treść jest wyraźnie zdegradowana.
Ponadto, jako część procesu indeksowania, kodeks zawiera TF-IDF, BM25 i BERT w swoim potoku przetwarzania tekstu. Nie jest jasne, dlaczego wszystkie te mechanizmy istnieją w kodzie, ponieważ istnieje pewna redundancja w używaniu ich wszystkich.
Czynniki linków i priorytetyzacja
Kod ujawnia również wiele informacji o czynnikach linków i sposobie ich priorytetyzacji.
Kalkulator spamu linków Yandexa ma 89 czynników, na które patrzy. Wszystko oznaczone jako SF_RESERVED jest zdeprecjonowane. Tam, gdzie jest to przewidziane, można znaleźć opisy tych czynników w arkuszu Google, do którego link znajduje się powyżej.
W szczególności, Yandex ma rangę hosta i niektóre wyniki, które wydają się żyć na długi czas po witrynie lub stronie rozwija reputację spamu.
Inną rzeczą, którą robi Yandex jest przegląd kopii w całej domenie i określić, czy istnieje duplikat treści z tych linków. To może być sitewide link placements, linki na zduplikowanych stronach, lub po prostu linki z tym samym anchor text pochodzących z tej samej strony.
To pokazuje, jak banalne jest zdyskontowanie wielu linków z tego samego źródła i wyjaśnia, jak ważne jest ukierunkowanie na bardziej unikalne linki z bardziej zróżnicowanych źródeł.
Co możemy zastosować z Yandexa do tego, co wiemy o Google?
Naturalnie, to pytanie wciąż jest w głowie wszystkich. O ile z pewnością istnieje wiele analogii między Yandexem a Google, to prawdę mówiąc, tylko inżynier oprogramowania Google pracujący nad wyszukiwaniem mógłby definitywnie odpowiedzieć na to pytanie.
Jednak jest to złe pytanie.
Naprawdę, ten kod powinien pomóc nam rozszerzyć nasze myślenie o nowoczesnym wyszukiwaniu. Duża część zbiorowego zrozumienia wyszukiwania jest zbudowana z tego, czego społeczność SEO nauczyła się na początku lat 2000 poprzez testy i z ust inżynierów wyszukiwania, kiedy wyszukiwanie było znacznie mniej nieprzejrzyste. To niestety nie nadąża za szybkim tempem innowacji.
Insights z wielu funkcji i czynników wycieku Yandex powinny przynieść więcej hipotez rzeczy do przetestowania i rozważenia dla rankingu w Google. Powinny one również wprowadzić więcej rzeczy, które mogą być parsowane i mierzone przez narzędzia do indeksowania SEO, analizy linków i rankingu.
Na przykład, miara cosinusoidalnego podobieństwa między zapytaniami i dokumentami przy użyciu BERT embeddings może być cenne dla zrozumienia versus stron konkurencji, ponieważ jest to coś, że nowoczesne wyszukiwarki są same robi.
W podobny sposób, w jaki dzienniki AOL Search przeniosły nas od zgadywania rozkładu kliknięć na SERP, kodeks Yandexa przenosi nas od abstrakcji do konkretu, a nasze stwierdzenia „to zależy” mogą być lepiej kwalifikowane.
W tym celu ta baza kodowa jest prezentem, który będzie stale dawał. Minął dopiero weekend, a my już wyciągnęliśmy z tego kodu kilka bardzo przekonujących wniosków. </p>
Przewiduję, że niektórzy ambitni inżynierowie SEO z dużo więcej czasu na rękach będą nadal kopać i może nawet wypełnić wystarczająco dużo tego, co brakuje, aby skompilować to i dostać go działa. Wierzę również, że inżynierowie w różnych wyszukiwarkach również przechodzą i parsują innowacje, z których mogą się uczyć i dodawać do swoich systemów.
Równocześnie prawnicy Google’a prawdopodobnie przygotowują agresywne listy o zaprzestaniu działań związanych z całym tym skrobaniem.
Z niecierpliwością czekam na ewolucję naszej przestrzeni, która jest napędzana przez ciekawych ludzi, którzy zmaksymalizują tę możliwość.
Ale, hej, jeśli uzyskanie wglądu w rzeczywisty kod nie jest dla ciebie wartościowe, możesz wrócić do robienia czegoś ważniejszego, jak kłótnie o subdomeny i podkatalogi.
Opinie wyrażone w tym artykule należą do autora, a nie do Search Engine Land. Autorzy artykułów są wymienieni tutaj.
