Sprachen

YandexBot und SEO

Was YandexBot ist, wie man ihn erkennt und verifiziert, die Yandex-exklusive Clean-param-Direktive, warum Crawl-delay tot ist, wie er mit JavaScript umgeht und wie er im Vergleich zu Googlebot und Bingbot abschneidet.

Erstveröffentlicht: 3. Juli 2026 · Zuletzt aktualisiert: 3. Aug. 2026 · Fortgeschritten
Sprachen
AIVerfasst vonAI v2
1 Evidenzsignal auf dieser Seite

YandexBot ist der Haupt-Webcrawler von Yandex – der Bot, der Seiten für die Yandex-Suche entdeckt und abruft, die Suchmaschine mit einem Marktanteil von über 70 % in Russland. Sein robots.txt-Token ist YandexBot (nur der Haupt-Indexierungs-Bot) im Gegensatz zu Yandex (die breitere Bot-Familie). Er unterstützt eine Yandex-exklusive Direktive, Clean-param, die URL-Parameter konsolidiert und kein Google-/Bing-Pendant hat – und er hat am 22. Februar 2018 aufgehört, Crawl-delay zu beachten (einige SEO-Leitfäden behaupten das fälschlicherweise immer noch). Das JavaScript-Rendering ist Beta und 'im Ermessen des Bots', und der Quellcode-Leak von 2023 deutete darauf hin, dass es kein separates JS-Rendering-System gibt, wie Google eines hat. Verifizieren Sie einen echten YandexBot durch Reverse-then-Forward-DNS auf einen yandex.ru/.net/.com-Host – dieselbe Technik, die Google und Bing für ihre eigenen Bots verwenden – und nicht anhand des User-Agent-Strings.

TL;DR — YandexBot ist der primäre Indexierungs-Crawler der Yandex-Suche. Sein robots.txt Token YandexBot zielt nur auf den Haupt-Indexierungs-Bot; Yandex zielt auf die breitere Bot-Familie. Es unterstützt eine nur bei Yandex verfügbare Direktive, Clean-param, die URL-Parameter konsolidiert — kein Google/Bing-Äquivalent — und es hat die Unterstützung für Crawl-delay am 22. Februar 2018 eingestellt (nutzen Sie stattdessen das Crawl-Rate-Tool; einige SEO-Leitfäden behaupten fälschlicherweise weiterhin, dass Yandex Crawl-delay unterstützt). JavaScript Rendering erfolgt nach Ermessen des Crawlers, daher bevorzugen Sie SSR/Pre-Rendering für kritische Inhalte. Disallow ≠ noindex (gleiche Falle wie bei Google). Verifizieren Sie einen echten YandexBot durch Reverse-then-Forward-DNS zu einem yandex.ru/yandex.net/ yandex.com-Host — dieselbe Technik, die auch Google und Bing verwenden — niemals nur den User-Agent- String allein.

Evidence for this claim Yandex documents its search robots and their user-agent identifiers in Yandex Webmaster Help. Scope: Current official Yandex robot list. Confidence: high · Verified: Yandex Webmaster: Yandex robots Evidence for this claim Yandex provides an official method for checking whether an IP address belongs to a Yandex robot; a user-agent string alone can be spoofed. Scope: Current Yandex robot verification guidance. Confidence: high · Verified: Yandex Webmaster: Verify a robot

Was YandexBot tatsächlich ist

YandexBot ist der primäre Web-Crawler für Yandex, die russische Suchmaschine. Er entdeckt URLs, ruft Seiten ab und speist den Yandex-Index — dieselbe Rolle, die Googlebot und Bingbot für ihre Suchmaschinen spielen. Der User-Agent-String, den Yandex dokumentiert (auf seiner Seite „Überprüfen, ob ein Roboter zu Yandex gehört“), lautet:

Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.268

Yandex fügt einen nützlichen Hinweis hinzu: Da „die Browserversion sich ändern kann“, empfiehlt es, nicht auf eine feste Chrome-Version zu matchen, wenn Sie versuchen, den Bot zu identifizieren. Matchen Sie das YandexBot-Token, nicht Chrome/81.0.4044.268.

Entscheidend ist, dass „YandexBot“ wirklich nur das Haupt-Indexierungs-Mitglied einer Familie von Yandex-Robotern ist — YandexImages, YandexMetrika, YandexDirect, YandexMobileBot, YandexAccessibilityBot, YandexRenderResourcesBot, YandexCalendar und weitere — jedes einzeln in robots.txt steuerbar. Viele Artikel vermischen „YandexBot“ mit „allen Yandex-Crawlern“, was unpräzise ist.

Ein weiterer, den es zu kennen lohnt: Die Server-Log-Tabelle von Yandex dokumentiert jetzt YandexAdditionalBot (und ein fast identisches Token, YandexAdditional) als einen Roboter, der „hilft, robots.txt zu verarbeiten, um zu verhindern, dass Seiteninhalte in der Suche mit Yandex-KI-Antworten erscheinen“, angewendet auf Seiten, die der Haupt-Crawler bereits indexiert hat. Laut derselben Tabelle berücksichtigt er die allgemeinen User-agent: *-Regeln nicht — wenn Sie eine Seite also gezielt von Yandex-KI-Funktionen ausschließen möchten, benötigen Sie einen expliziten User-agent: YandexAdditionalBot-Block, dasselbe Muster, das auch die KI-Crawler-Opt-outs anderer Suchmaschinen verwenden.

Evidence for this claim Yandex documents its search robots and their user-agent identifiers in Yandex Webmaster Help. Scope: Current official Yandex robot list. Confidence: high · Verified: Yandex Webmaster: Yandex robots

YandexBot vs. „Yandex“ in robots.txt — sie sind nicht dasselbe Token

Dies ist die unauffälligste robots.txt-Eigenheit von Yandex, und sie beißt Menschen, die von Google-zentrierter technischer SEO migrieren. Beginnen Sie mit Yandex’ eigenem ausgearbeitetem Beispiel — es macht die Aufteilung des Geltungsbereichs explizit, Kommentare inklusive:

User-agent: YandexBot # will be used only by the main indexing bot
Disallow: /*id=

User-agent: Yandex # will be used by all Yandex bots
Disallow: /*sid= # except the main indexing bot

User-agent: * # will not be used by Yandex bots
Disallow: /cgi-bin

Wörtlich gelesen sind die Kommentare des Beispiels selbst die Dokumentation:

  • User-agent: YandexBot — wird nur vom Haupt-Indexierungs-Bot verwendet.
  • User-agent: Yandex — wird von Yandex-Bots breiter verwendet — aber laut Kommentar des Beispiels zum zweiten Block „mit Ausnahme des Haupt-Indexierungs-Bots.“ Das breitere Token ist nicht einmal innerhalb der Yandex-Familie universell.

Zwei Dinge folgen aus Yandex’ Regeln hier. Erstens, Priorität: „Wenn der User-agent: Yandex-String erkannt wird, wird der User-agent: *-String ignoriert.“ Ein generischer User-agent: *-Block gilt also nicht für Yandex-Bots, wenn Sie auch einen Yandex- Block geschrieben haben. Zweitens — und das überrascht sicherheitsbewusste Leser — warnt Yandex, dass „Einige Yandex-Roboter Direktiven in robots.txt ignorieren können, einschließlich jener für User-agent: Yandex.“ Nicht jeder Yandex-Bot ist garantiert bereit, einer pauschalen Regel zu gehorchen, was ein weiterer Grund ist, warum serverseitige Verifizierung und Blockierung für den vollständigen Ausschluss wichtig sind.

Verifizieren, dass es wirklich YandexBot ist

Da der User-Agent fälschbar ist, empfiehlt Yandex, die Verifizierung per DNS durchzuführen, genau wie Google und Bing es für ihre eigenen Crawler tun. Yandex: “Some robots can disguise themselves as Yandex robots by indicating the relevant User Agent. You can check the authenticity of a robot using a reverse DNS lookup.” (Übersetzung) „Einige Roboter können sich als Yandex-Roboter ausgeben, indem sie den entsprechenden User Agent angeben. Sie können die Authentizität eines Roboters mithilfe eines Reverse-DNS-Lookups überprüfen.“ Die dokumentierte Methode:

  1. “Determine the IP address of the user agent in question using your server logs.” (Übersetzung) „Ermitteln Sie die IP-Adresse des betreffenden User-Agents mithilfe Ihrer Server-Logs.“
  2. “Use a reverse DNS lookup of the IP address to determine the host domain name.” (Übersetzung) „Führen Sie einen Reverse-DNS-Lookup der IP-Adresse durch, um den Host-Domainnamen zu ermitteln.“
  3. “Check whether the host belongs to Yandex. All Yandex robots have names ending in yandex.ru, yandex.net or yandex.com.” (Übersetzung) „Prüfen Sie, ob der Host zu Yandex gehört. Alle Yandex-Roboter haben Namen, die auf yandex.ru, yandex.net oder yandex.com enden.“ (Wenn der Hostname eine andere Endung hat, ist es nicht Yandex.)
  4. “Make sure that the name is correct. Use a forward DNS lookup to get the IP address corresponding to the host name. It should match the IP address used in the reverse DNS lookup.” (Übersetzung) „Stellen Sie sicher, dass der Name korrekt ist. Führen Sie einen Forward-DNS-Lookup durch, um die IP-Adresse zu erhalten, die dem Hostnamen entspricht. Sie sollte mit der IP-Adresse übereinstimmen, die im Reverse-DNS-Lookup verwendet wurde.“

Und die Fehlerbedingung, in Yandex’ eigenen Worten: “If the IP addresses do not match, it means that the host name is fake.” (Übersetzung) „Wenn die IP-Adressen nicht übereinstimmen, bedeutet das, dass der Hostname gefälscht ist.“ Yandex erwähnt außerdem ein offizielles „IP-Adress-Prüftool“ als Alternative zur manuellen Durchführung der Lookups.

Dies ist dasselbe Forward-Confirmed-Reverse-DNS-Muster (FCrDNS), auf das sich alle drei großen Suchmaschinen einigen — Google verifiziert gegen googlebot.com/google.com/ googleusercontent.com, Bing gegen *.search.msn.com und Yandex gegen yandex.ru/yandex.net/yandex.com. Keine von ihnen behandelt eine veröffentlichte IP-Liste als ausreichend vertrauenswürdig. Die Befehle befinden sich im Tab Skripte; die Domain-Suffixe sind das Einzige, was sich zwischen den Suchmaschinen ändert. (Für die Google- und Bing-Versionen siehe die Geschwisterartikel Googlebot und Bingbot.)

Steuerung von YandexBot mit robots.txt

Yandex erkennt einen vertrauten Kern von Direktiven, die jeweils in der eigenen Dokumentation definiert sind:

  • User-agent — “Indicates the robot to which the rules listed in robots.txt apply.” (Übersetzung) „Gibt den Roboter an, auf den die in robots.txt aufgeführten Regeln zutreffen.“
  • Disallow — “Prohibits crawling of sections or individual pages of the site.” (Übersetzung) „Verhindert das Crawlen von Abschnitten oder einzelnen Seiten der Website.“
  • Allow — “Allows indexing site sections or individual pages.” (Übersetzung) „Erlaubt das Indexieren von Website-Abschnitten oder einzelnen Seiten.“
  • Sitemap — “Specifies the path to the Sitemap file that is posted on the site.” (Übersetzung) „Gibt den Pfad zur Sitemap-Datei an, die auf der Website veröffentlicht ist.“
  • Clean-param — “Indicates to the robot that the page URL contains parameters (like UTM tags) that should be ignored when indexing it.” (Übersetzung) „Weist den Roboter darauf hin, dass die Seiten-URL Parameter (wie UTM-Tags) enthält, die beim Indexieren ignoriert werden sollten.“ (Nur bei Yandex — siehe unten.)

Einige Dateianforderungen sind wissenswert: Die Datei muss “a TXT file named “robots”, robots.txt,” (Übersetzung) „eine TXT-Datei namens „robots“, robots.txt“ sein, ihre Größe darf 500 KB nicht überschreiten, und der Server muss für das Lesen einen HTTP-200-OK-Status zurückgeben.

Disallow ≠ noindex — dieselbe Falle wie bei Google

Die am häufigsten missverstandene Tatsache über robots.txt gilt direkt auch für Yandex, und Yandex formuliert es klar: “Pages restricted in robots.txt can participate in Yandex search. To remove pages from search, specify the noindex directive in the HTML code of the page or configure the HTTP header.” (Übersetzung) „In robots.txt eingeschränkte Seiten können an der Yandex-Suche teilnehmen. Um Seiten aus der Suche zu entfernen, geben Sie die noindex-Direktive im HTML-Code der Seite an oder konfigurieren Sie den HTTP-Header.“ Mit anderen Worten: Disallow steuert das Crawlen, nicht das Indexieren — eine disallowte URL kann weiterhin in den Yandex-Ergebnissen erscheinen. Dies ist dieselbe konzeptionelle Falle wie bei Google (ich habe sie für Google in Indexed, though blocked by robots.txt beschrieben), und die Lösung ist identisch: Um eine Seite tatsächlich zu entfernen, erlauben Sie das Crawlen und fügen noindex hinzu. Yandex erklärt im selben Abschnitt genau, warum: “Do not restrict such pages in robots.txt, or the Yandex bot can’t index them and detect your instructions.” (Übersetzung) „Schränken Sie solche Seiten nicht in robots.txt ein, sonst kann der Yandex-Bot sie nicht indexieren und Ihre Anweisungen nicht erkennen.“ Eine Indexsteuerungs-Direktive funktioniert nur, wenn der Crawler die Seite abrufen kann, um sie zu sehen — Disallow und noindex auf derselben URL ist ein Widerspruch: Das Disallow verhindert, dass Yandex das noindex-Tag jemals liest, sodass die Seite genau dort bleibt, wo sie war.

Clean-param — Yandex’ einzigartige Parameter-Direktive

Clean-param ist die mit Abstand yandex-spezifischste Direktive für ein Publikum, das Google und Bing gewohnt ist, und sie hat kein Google- oder Bing-Pendant. Ihr Zweck laut Yandex: “The Yandex robot uses this directive to avoid reloading duplicate information. This improves the robot’s efficiently and reduces the server load.” (Übersetzung) „Der Yandex-Roboter verwendet diese Direktive, um das erneute Laden doppelter Informationen zu vermeiden. Dies verbessert die Effizienz des Roboters und reduziert die Serverlast.“ (Dieses „efficiently“ ist ein echter Tippfehler auf Yandex’ Live-Seite – ich zitiere es unverändert, statt es stillschweigend zu korrigieren.)

Das Problem, das sie löst: “The new parameter that doesn’t affect the page content may result in duplicate pages that should not be included in the search.” (Übersetzung) „Der neue Parameter, der den Seiteninhalt nicht beeinflusst, kann zu doppelten Seiten führen, die nicht in die Suche aufgenommen werden sollten.“ Die Syntax:

Clean-param: p0[&p1&p2&..&pn] [path]

Yandex’ eigenes Praxisbeispiel – drei URLs, die sich nur durch einen ref-Tracking-Parameter unterscheiden:

www.example.com/some_dir/get_book.pl?ref=site_1&book_id=123
www.example.com/some_dir/get_book.pl?ref=site_2&book_id=123
www.example.com/some_dir/get_book.pl?ref=site_3&book_id=123

…kollabieren zu einer kanonischen URL (www.example.com/some_dir/get_book.pl?book_id=123) mit einer einzigen Direktive:

User-agent: Yandex
Clean-param: ref /some_dir/get_book.pl

Zwei Details machen Clean-param leicht falsch anzuwenden. Erstens: “The Clean-param directive does not require mandatory combination with the Disallow directive” (Übersetzung) „Die Clean-param-Direktive erfordert keine zwingende Kombination mit der Disallow-Direktive“ – sie steht für sich allein; Sie müssen die Parameter-URLs nicht Disallowen. Zweitens ist sie intersektional: Laut Yandex ist sie “intersectional, so it can be specified anywhere in the file, regardless of the location.” (Übersetzung) „intersektional, sodass sie überall in der Datei angegeben werden kann, unabhängig vom Ort.“ Anders als Allow/Disallow, die an einen Pfad gebunden sind, ist Clean-param eine globale Direktive, die Sie überall in der Datei platzieren können.

Yandex merkt außerdem an, dass es einige Parameter automatisch behandeln kann: “Parameters for analytics and tracking that don’t affect the page content may be automatically removed by the search engine if the algorithms determine that those parameters are insignificant.” (Übersetzung) „Parameter für Analytik und Tracking, die den Seiteninhalt nicht beeinflussen, können von der Suchmaschine automatisch entfernt werden, wenn die Algorithmen feststellen, dass diese Parameter unbedeutend sind.“ Aber sich für die Parameter, die Ihnen wichtig sind, auf Clean-param zu verlassen, ist der deterministische Schritt. Dies ist das Yandex-Pendant dazu, wie Google sich inzwischen auf Kanonisierungssignale (Canonical-Tag, interne Verlinkung) stützt, seit es sein altes URL-Parameter-Tool eingestellt hat – Yandex gibt Ihnen nur eine explizite robots.txt-Direktive, wo Google keine bietet.

Crawl-delay ist tot (seit Februar 2018)

Wenn Sie gelesen haben, dass Crawl-delay in Yandex’ robots.txt funktioniert, sind diese Informationen veraltet. Yandex’ eigene dedizierte Seite ist unmissverständlich: “From February 22, 2018, Yandex doesn’t take into account the Crawl-delay directive.” (Übersetzung) „Ab dem 22. Februar 2018 berücksichtigt Yandex die Crawl-delay-Direktive nicht mehr.“

Das ist erwähnenswert, weil mindestens eine vielgelesene SEO-Ressource immer noch das Gegenteil behauptet. Ahrefs’ robots.txt-Leitfaden (verfasst von Joshua Hardwick, nicht von mir) sagt derzeit: “Google no longer supports this directive, but Bing and Yandex do.” (Übersetzung) „Google unterstützt diese Direktive nicht mehr, aber Bing und Yandex tun es.“ Was die Yandex-Hälfte betrifft, widerspricht dem Yandex’ eigene aktuelle Dokumentation. Ich würde Yandex’ dedizierte, datierte Seite hier als maßgeblich betrachten – aber die breitere Lektion ist die nützliche: Überprüfen Sie eine Crawl-Verhaltens-Behauptung anhand der Live-Dokumente der Engine, bevor Sie einem sekundären Leitfaden vertrauen, denn diese Details driften und selbst gute Quellen werden veraltet. (Beachten Sie den Kontrast zu Bing, das crawl-delay tatsächlich weiterhin berücksichtigt – eine der echten Bingbot/YandexBot-Divergenzen.)

Der Ersatz ist die Crawl-Rate-Einstellung in Yandex Webmaster, mit der Sie beeinflussen können, wie schnell YandexBot Ihre Website abruft. (Yandex’ Crawl-delay-Seite ist im Wesentlichen ein Satz plus ein Verweis auf diese Einstellung.)

Wie YandexBot mit JavaScript umgeht

Yandex’ JavaScript-Rendering ist von Yandex selbst explizit als Beta (β) gekennzeichnet, und das Standardverhalten ist “at the bot’s discretion” – der Bot “will independently determine whether to execute JavaScript code on the site’s pages.” (Übersetzung) „wird unabhängig entscheiden, ob JavaScript-Code auf den Seiten der Website ausgeführt wird.“ Wenn er es tut, kann er “assess the quality and completeness of the content on the pages with and without JavaScript” (Übersetzung) „die Qualität und Vollständigkeit des Inhalts auf den Seiten mit und ohne JavaScript bewerten“ und die Version ausliefern, die für den Besucher wahrscheinlich nützlicher ist.

Es gibt eine bedeutsame Spannung, die es wert ist, hervorgehoben zu werden. Der Yandex-Quellcode-Leak von 2023 (offengelegte interne Engineering-Dokumente, keine offizielle Stellungnahme – ich werde weiter unten näher darauf eingehen) deutete auf ein einfacheres Bild hin. Wie Mike King in seiner Search Engine Land-Analyse des Leaks schrieb: “Yandex has no separate rendering system for JavaScript. They say this in their documentation and, although they have Webdriver-based system for visual regression testing called Gemini, they limit themselves to text-based crawl.” (Übersetzung) „Yandex hat kein separates Rendering-System für JavaScript. Das sagen sie in ihrer Dokumentation, und obwohl sie ein Webdriver-basiertes System für visuelle Regressionstests namens Gemini haben, beschränken sie sich auf textbasiertes Crawlen.“ (Dieses interne „Gemini“ ist ein Yandex-Tool für visuelle Regressionstests – völlig unabhängig von Googles Gemini-KI-Modell, trotz des gemeinsamen Namens. Es lohnt sich, das zu verdeutlichen, damit niemand die beiden verwechselt.) Und Dan Taylors Search Engine Journal-Beitrag schlussfolgerte, dass es “nothing new to suggest Yandex can crawl JavaScript yet outside of already publicly documented processes.” (Übersetzung) „nichts Neues gibt, das darauf hindeutet, dass Yandex JavaScript bereits außerhalb bereits öffentlich dokumentierter Prozesse crawlen kann.“

Die ehrliche Antwort ist also weder „YandexBot rendert JS genau wie Googlebot“ noch „YandexBot berührt JavaScript nie.“ Es ist selektiv und Beta, nach Yandex’ eigener Beschreibung. Die Aussage des Leaks über „kein separates Rendering-System“ ist mit diesem Rahmen konsistent, aber es handelt sich um geleaktes internes Material, das über Branchenberichte weitergegeben wurde, nicht um eine Offenlegung von Yandex – behandeln Sie „architektonisch einfacher als Google“ also als plausible Lesart zweier konsistenter Signale, nicht als dokumentierte Tatsache. Verlassen Sie sich für eine Route, die Ihnen wichtig ist, auf keine der beiden Darstellungen blind; testen Sie es direkt:

  • Gerenderte Ausgabe: Rufen Sie die Seite mit deaktiviertem JavaScript ab und vergleichen Sie sie mit der JS-gerenderten Version. Wenn sich die beiden wesentlich unterscheiden, gehen Sie nicht davon aus, dass Yandex die gerenderte Version gesehen hat.
  • Ressourcenzugriff: Stellen Sie sicher, dass die JS-, CSS- und API-Endpunkte, von denen die Seite abhängt, nicht in robots.txt blockiert sind. Yandex’ YandexRenderResourcesBot ruft Renderzeit-Ressourcen ab, aber (laut Yandex’ eigener Dokumentation dazu) nur für Seiten, die der Haupt-Indexierungs-Bot bereits erreichen kann – eine blockierte Ressource auf einer erlaubten Seite wird weiterhin nicht geladen.
  • Verzögerte und interaktive Inhalte: Alles, was nach dem DOMContentLoaded-Ereignis oder hinter einem Klick lädt, ist nicht garantiert gerendert. Yandex’ erweiterte Rendering-Einstellungen (window.YandexRotorSettings) existieren speziell für Websites, bei denen „Inhalte mit Verzögerung laden“ – das ist ein Signal, das es wert ist, gelesen zu werden, nicht nur eine Konfigurationsoption.

Die praktische Schlussfolgerung: Yandex’ eigene Dokumentation empfiehlt, “Prohibit rendering if SSR (Server-Side Rendering) or pre-rendering is implemented on the site,” (Übersetzung) „Rendering zu verbieten, wenn SSR (Server-Side Rendering) oder Pre-Rendering auf der Website implementiert ist,“ und weist darauf hin, dass “Executing JavaScript code may create additional load on your server.” (Übersetzung) „Das Ausführen von JavaScript-Code kann zusätzliche Last auf Ihrem Server erzeugen.“ Wenn Sie zuverlässige Yandex-Indexierung von JS-lastigen Inhalten wünschen, liefern Sie sie serverseitig aus, statt Ihr Glück mit clientseitigem Rendering zu versuchen.

Für AJAX-ähnliche Websites sagt Yandex: “When indexing an AJAX site, the Yandex bot scans the original URLs and executes JavaScript code on them” (Übersetzung) „Beim Indexieren einer AJAX-Website scannt der Yandex-Bot die ursprünglichen URLs und führt JavaScript-Code auf ihnen aus“ – und es hat sich von dem alten HTML-Snapshot-Hack entfernt: Wenn Sie weiterhin den veralteten meta name="fragment"-Ansatz verwenden, “the bot will ignore it and index the original page.” (Übersetzung) „wird der Bot ihn ignorieren und die ursprüngliche Seite indexieren.“ Seine moderne Empfehlung spiegelt Googles wider: “If the links on AJAX pages use the # character, change the addresses to URLs without this character. For example, you may use the History API.” (Übersetzung) „Wenn die Links auf AJAX-Seiten das #-Zeichen verwenden, ändern Sie die Adressen in URLs ohne dieses Zeichen. Sie können beispielsweise die History-API verwenden.“

Was der Quellcode-Leak von 2023 über den Crawler enthüllte

Im Januar 2023 leakte der interne Quellcode von Yandex – ein gut belegtes Ereignis, über das unter anderem Search Engine Land und Search Engine Journal berichteten. Behandeln Sie dies als geleakte interne Dokumentation, nicht als offizielle Stellungnahme von Yandex, aber es offenbarte echte Details darüber, wie der Crawler funktioniert. Laut Mike Kings SEL-Analyse: “Yandex’s documentation discusses a dual-distributed crawler system. One for real-time crawling called the ‘Orange Crawler’ and another for general crawling.” Er zog einen Vergleich zu Google, das “is said to have had an index stratified into three buckets, one for housing real-time crawl, one for regularly crawled and one for rarely crawled.” Beide Suchmaschinen scheinen also segmentiertes Crawling zu nutzen, das davon abhängt, wie oft Inhalte aktualisiert werden.

Der Leak verband das Crawling auch direkt mit der Seitenarchitektur. Laut Dan Taylors SEJ-Berichterstattung: “URLs that are reachable from the homepage have a ‘higher’ level of importance.” Das ist eine klare Brücke von „Crawler-Mechanik” zu „warum interne Verlinkung wichtig ist” – dieselbe Crawl-Tiefen-Logik, die auch für Googlebot gilt.

(Zur Einordnung: Die Berichterstattung merkte an, dass die vielzitierte Zahl von „1 922 Ranking-Faktoren” nur für eine Archivdatei galt, während der vollständigere Codebase Berichten zufolge weit mehr über mehrere Dateien hinweg enthielt – behalten Sie bei jeder konkreten Zahl ein Datum und eine Quelle bei, wenn Sie eine zitieren.)

Warum YandexBot immer noch wichtig ist – und wie häufig er in robots.txt vorkommt

Der globale Marktanteil von Yandex ist winzig, aber der in Russland nicht: ~71 % in Russland gegenüber ~27 % bei Google (Stand Juni 2026, StatCounter). Diese Stabilität ist der einzige Grund, warum YandexBot eine separate Behandlung verdient. Wenn Sie ein Geschäft mit Russland/GUS-Ausrichtung haben, schließt das Blockieren von YandexBot die dominierende Suchmaschine in diesem Markt aus.

Wie oft konfigurieren Websites überhaupt für ihn? Selten, aber zunehmend. Im Web Almanac 2022 SEO-Kapitel (ich war in dem Jahr Reviewer; ich war Hauptautor des Kapitels 2021): YandexBot erschien in “just 0.5% of robots.txt files in 2021. By 2022, there was a six-fold increase, with 3% of files specifying Yandexbot.” Klein, aber ein klarer Aufwärtstrend – und eine nützliche Basislinie dafür, „wie häufig ist das in freier Wildbahn”.

Wenn Sie entscheiden, ob Sie ihn blockieren sollen, ist die ehrliche Einordnung eine geschäftliche Frage, keine technische – und es ist eine echte Debatte, die in Webmaster-Foren ausgetragen wird. Für die allgemeineren Mechanismen, in denen YandexBot lebt – URL-Erkennung, Crawl-Scheduler, Rendering und die Unterscheidungen zwischen Crawlen, Indexieren und Ranking – siehe den Crawling-Hub. Und für die spezifische Konfiguration von Yandex als Teil einer Russland/GUS-Strategie verbindet das internationale-SEO- und marktspezifische-SEO-Material die Punkte.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.