YandexBotとSEO

TL;DR — YandexBot は Yandex 検索のクローラーです — Googlebot が Google に対して行うのと同じ仕事を、Bingbot が Bing に対して行うのと同じように。YandexBot はあなたのページを訪問し、ダウンロードし、Yandex のインデックスに追加します。YandexBot を気にするべきかどうかは、1つの質問に尽きます：Yandex が関連する市場に、あなたのオーディエンスやビジネスはありますか？もしあれば、重要です。もしなければ、ログの中のトラフィックに過ぎません。

YandexBot とは

サーバーログに YandexBot が表示された場合、それは Yandex のクローラーです — Google が世界の大半を支配するように、ロシアの検索を支配する検索エンジンです。Googlebot や Bingbot と同様に、YandexBot はリンクを辿り、sitemap を読み、あなたのページをダウンロードし、Yandex の検索インデックスに追加されるように引き渡します。

「Google 以外のボットをすべてブロックする」ではなく、これが単独の記事になる理由は、地理的な理由です。Yandex は世界的には誤差の範囲ですが、ロシアでは Google の約 27 % に対して、検索市場の約 71 % を保持しています（StatCounter、2026 年 6 月）。したがって、ロシア（および歴史的にはいくつかの近隣市場）の人々に販売またはサービスを提供している場合、YandexBot はその検索トラフィックの大部分へのゲートウェイとなります。

見分け方

YandexBot の信頼できる身元確認は、ユーザーエージェント文字列ではなく DNS ルックアップ です — その理由と仕組みは次のとおりです。

YandexBot のユーザーエージェントには YandexBot という単語が含まれています。Yandex 自身のドキュメントには、完全な文字列が次のように記載されています：

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

しかし、その文字列だけでは何も証明されません：誰でも偽装できます。 スクレイパーや悪意のあるボットは、日常的に YandexBot を装います。したがって、ユーザーエージェントは、どのログ行を確認する価値があるかを絞り込むためのフィルターに過ぎません — 実際の証明は、リクエストが本物の Yandex ホストから来たことを確認する逆引き・順引きの DNS ルックアップであり、これは Google と Bing が自社のクローラーに使用しているのと同じ手法です（詳細は Advanced タブで説明）。

ブロックすべきか？

これが多くの人が実際に尋ねている本当の質問です。簡単な考え方：

• ロシア/CIS 向けのビジネスがありますか？ ブロックしないでください — そこでの支配的な検索エンジンから自分を締め出すことになります。
• ロシア向けのオーディエンスがゼロで、クロールがサーバーに負担をかけていますか？ その場合、ブロックまたは速度制限は合理的な判断です。robots.txt に数行追加して、立ち入りを禁止できます。

ブロック側の注意点が 1 つ：robots.txt のルールは リクエスト であり、強制ではありません。Yandex 自身のドキュメントは、一部のロボットが robots.txt の指示を無視する可能性があると警告しているため、確実な除外（「やめてください」ではなく）が必要な場合は、代わりにサーバー/ファイアウォールレベルで検証済み IP によるブロックを行ってください（影響を受ける Yandex ボットについては Advanced タブを参照）。

重要な落とし穴が 1 つあり、それは Google と同じ罠です：robots.txt にページを入れることは、Yandex の検索結果からページを削除するわけではありません — それは Yandex がページを読むのを止めるだけです。Yandex は自社のドキュメントでこれを述べており、知っておく価値のある条件を追加しています：robots.txt でページを も ブロックすると、Yandex は「それらをインデックスできず、あなたの指示を検出できません」— つまり、noindex タグは、Yandex にページを取得させて確認させた場合にのみ機能します。同じ URL でクロールをブロックし、noindex を追加すると、noindex が打ち消されます。ページを実際に除外するには、代わりにクロールを許可し、noindex タグを追加してください。

技術的なバージョン — 正確な robots.txt トークン、Yandex 独自の Clean-param ディレクティブ、本物の YandexBot の検証方法、JavaScript の処理方法 — をご希望ですか？ Advanced タブに切り替えてください。

TL;DR — YandexBot は Yandex Search の主要なインデックス用クローラーです。その robots.txt トークン YandexBot はメインのインデックス用ボットのみを対象とし、Yandex は より広いボットファミリーを対象とします。Google/Bing に相当するものがないYandex 独自のディレクティブ、Clean-param をサポートしており、URL パラメータを統合します。また、2018年2月22日をもって Crawl-delay の尊重を停止しました（代わりに Crawl rate ツールを使用してください。一部の SEO ガイドでは今でも Yandex が Crawl-delay をサポートしていると誤って主張しています）。JavaScript レンダリングはクローラーの裁量で実行されるため、重要なコンテンツには SSR/プリレンダリングを推奨します。Disallow ≠ noindex（Google と同じ罠）。実際の YandexBot を検証するには、逆引き→正引き DNS で yandex.ru/yandex.net/ yandex.com ホストに到達することを確認します（Google や Bing が使用するのと同じ手法）。ユーザーエージェント文字列だけに頼らないでください。

YandexBot が実際に何であるか

YandexBot は、ロシアの検索エンジン Yandex の主要なウェブクローラーです。URL を発見し、ページを取得し、Yandex のインデックスに供給します。これは Googlebot や Bingbot がそれぞれのエンジンで果たす役割と同じです。Yandex が文書化しているユーザーエージェント文字列（「ロボットが Yandex に属しているか確認する」ページ）は次のとおりです：

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

Yandex はその隣に有益な注意書きを追加しています：「ブラウザのバージョンは変更される可能性がある」ため、ボットを識別する際に固定の Chrome バージョンに一致させることは推奨しないとしています。Chrome/81.0.4044.268 ではなく、YandexBot トークンに一致させてください。

重要なのは、「YandexBot」は実際には Yandex ロボットのファミリーのメインのインデックス用メンバーに過ぎないということです。YandexImages、YandexMetrika、YandexDirect、YandexMobileBot、YandexAccessibilityBot、YandexRenderResourcesBot、YandexCalendar などがあり、それぞれ robots.txt で個別に制御できます。多くの記事が「YandexBot」と「すべての Yandex クローラー」を混同していますが、これは不正確です。

もう一つ知っておく価値があるのは、Yandex のサーバーログテーブルに YandexAdditionalBot（およびほぼ重複するトークン YandexAdditional）が、メインのクローラーがすでにインデックスしたページに適用され、「Yandex AI 応答を含む検索でページコンテンツが表示されないように robots.txt の処理を支援する」ロボットとして文書化されていることです。同じテーブルによると、これは一般的な User-agent: * ルールを考慮しません。そのため、ページを Yandex の AI 機能から特に除外したい場合は、他のエンジンの AI クローラー除外と同じパターンで、明示的な User-agent: YandexAdditionalBot ブロックが必要です。

robots.txt における YandexBot と「Yandex」の違い — 同じトークンではない

これは Yandex の最もわかりにくい robots.txt の癖であり、Google 中心の技術 SEO から移行する人々を悩ませます。Yandex 自身の実例から始めましょう。コメントも含めて、スコープの分割が明確に示されています：

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

文字通り読むと、その例のコメント自体がドキュメントです：

• User-agent: YandexBot — メインのインデックス用ボットのみが使用します。
• User-agent: Yandex — Yandex ボットがより広く使用しますが、例の 2 番目のブロックに対するコメントによると、「メインのインデックス用ボットを除く」 とあります。より広いトークンは、Yandex ファミリー内でも普遍的なものではありません。

ここから Yandex のルールに基づいて 2 つのことが導かれます。第一に、優先順位です：「User-agent: Yandex 文字列が検出された場合、User-agent: * 文字列は無視されます。」 つまり、Yandex ブロックも記述している場合、一般的な User-agent: * ブロックは Yandex ボットには適用されません。第二に、セキュリティ意識の高い読者を驚かせる点ですが、Yandex は*「一部の Yandex ロボットは、User-agent: Yandex に対するものを含め、robots.txt のディレクティブを無視する可能性があります」* と警告しています。すべての Yandex ボットが包括的なルールに従うとは限らないため、完全な除外にはサーバーレベルの検証とブロッキングがさらに重要になります。

それが本当に YandexBot であることを検証する

ユーザーエージェントは偽装可能なため、YandexはGoogleやBingが自社のクローラーに対して行うのとまったく同じように、DNSで検証するよう指示しています。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.” (翻訳) 「一部のロボットは、関連するユーザーエージェントを指定することでYandexロボットになりすますことができます。逆DNSルックアップを使用してロボットの信頼性を確認できます。」 文書化された方法は次のとおりです。

1. “Determine the IP address of the user agent in question using your server logs.” (翻訳) 「サーバーログを使用して、問題のユーザーエージェントのIPアドレスを特定します。」
2. “Use a reverse DNS lookup of the IP address to determine the host domain name.” (翻訳) 「IPアドレスの逆DNSルックアップを使用して、ホストのドメイン名を特定します。」
3. “Check whether the host belongs to Yandex. All Yandex robots have names ending in yandex.ru, yandex.net or yandex.com.” (翻訳) 「ホストがYandexに属しているかどうかを確認します。すべてのYandexロボットの名前は、yandex.ru、yandex.net、またはyandex.comで終わります。」 (ホスト名の末尾が異なる場合、それは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.” (翻訳) 「名前が正しいことを確認します。フォワードDNSルックアップを使用して、ホスト名に対応するIPアドレスを取得します。これは、逆DNSルックアップで使用されたIPアドレスと一致する必要があります。」

そして、失敗条件はYandexの言葉で次のとおりです。 “If the IP addresses do not match, it means that the host name is fake.” (翻訳) 「IPアドレスが一致しない場合、それはホスト名が偽物であることを意味します。」 Yandexはまた、手動でルックアップを実行する代わりに、公式の「IPアドレスチェックツール」にも言及しています。

これは、主要な3つのエンジンすべてがたどり着く、同じフォワード確認済みリバースDNS（FCrDNS）パターンです — Googleはgooglebot.com/google.com/googleusercontent.comに対して検証し、Bingは*.search.msn.comに対して、Yandexはyandex.ru/yandex.net/yandex.comに対して検証します。どのエンジンも、公開されたIPリストだけを信頼できるものとは見なしていません。コマンドはScriptsタブにあります。エンジン間で変わるのはドメインのサフィックスだけです。(GoogleとBingのバージョンについては、GooglebotおよびBingbotの関連記事を参照してください。)

robots.txtでYandexBotを制御する

Yandexは、それぞれ独自のドキュメントで定義されている、おなじみのコアディレクティブセットを認識します。

• User-agent — “Indicates the robot to which the rules listed in robots.txt apply.” (翻訳) 「robots.txtに記載されているルールが適用されるロボットを示します。」
• Disallow — “Prohibits crawling of sections or individual pages of the site.” (翻訳) 「サイトのセクションまたは個々のページのクロールを禁止します。」
• Allow — “Allows indexing site sections or individual pages.” (翻訳) 「サイトのセクションまたは個々のページのインデックスを許可します。」
• Sitemap — “Specifies the path to the Sitemap file that is posted on the site.” (翻訳) 「サイトに掲載されているSitemapファイルへのパスを指定します。」
• Clean-param — “Indicates to the robot that the page URL contains parameters (like UTM tags) that should be ignored when indexing it.” (翻訳) 「ページのURLに、インデックス作成時に無視すべきパラメータ（UTMタグなど）が含まれていることをロボットに示します。」 (Yandexのみ — 以下を参照。)

知っておく価値のあるファイル要件がいくつかあります。ファイルは “a TXT file named “robots”, robots.txt,” (翻訳) 「robots.txtという名前のTXTファイル」である必要があり、そのサイズは500 KBを超えてはならず、サーバーは読み取りのためにHTTP 200 OKステータスを返す必要があります。

Disallow ≠ noindex — Googleと同じ罠

最も誤解されているrobots.txtの事実は、Yandexにもそのまま当てはまり、Yandexはそれを明確に述べています。 “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.” (翻訳) 「robots.txtで制限されたページは、Yandex検索に参加できます。検索からページを削除するには、ページのHTMLコードでnoindexディレクティブを指定するか、HTTPヘッダーを設定します。」 言い換えれば、Disallowはクロールを制御し、インデックスは制御しません — 禁止されたURLはYandexの結果に表示される可能性があります。これはGoogleにもあるのと同じ概念的な罠です（Googleについては*Indexed, though blocked by robots.txt*で書いています）、そして修正方法も同じです。実際にページを削除するには、クロールを許可してnoindexを追加します。Yandexは同じセクションでその理由を正確に説明しています。 “Do not restrict such pages in robots.txt, or the Yandex bot can’t index them and detect your instructions.” (翻訳) 「そのようなページをrobots.txtで制限しないでください。そうしないと、Yandexボットはそれらをインデックスできず、あなたの指示を検出できません。」 インデックス制御ディレクティブは、クローラーがページを取得してそれを確認できる場合にのみ機能します — 同じURLでのDisallowとnoindexは矛盾しています。DisallowはYandexがnoindexタグを読み取るのを防ぐため、ページは元の場所に正確に残ります。

Clean-param — Yandex独自のパラメータディレクティブ

Clean-param は、Google や Bing に慣れた読者にとって、Yandex 特有のディレクティブの中で最も特徴的なものであり、Google や Bing に相当するものはありません。 その目的は、Yandex によると次のとおりです: “The Yandex robot uses this directive to avoid reloading duplicate information. This improves the robot’s efficiently and reduces the server load.”（この「efficiently」は Yandex のライブページにある実際のタイポです。私は黙って修正せず、そのまま引用しています。）

これが解決する問題: “The new parameter that doesn’t affect the page content may result in duplicate pages that should not be included in the search.” 構文は次のとおりです:

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

Yandex 自身の実例 — ref トラッキングパラメータだけが異なる 3 つの URL:

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

…単一のディレクティブで 1 つの正規 URL（www.example.com/some_dir/get_book.pl?book_id=123）に集約されます:

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

Clean-param を間違えやすい点が 2 つあります。まず、“The Clean-param directive does not require mandatory combination with the Disallow directive” — これは単独で機能し、パラメータ付き URL を Disallow する必要はありません。次に、これは交差的です: Yandex によると、“is intersectional, so it can be specified anywhere in the file, regardless of the location.” Allow/Disallow がパスに固定されているのとは異なり、Clean-param はファイル内のどこにでも配置できるグローバルディレクティブです。

Yandex はまた、一部のパラメータを自動的に処理する可能性があることも指摘しています: “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.” しかし、自分にとって重要なパラメータについては Clean-param に頼るのが確実な方法です。これは、Google が旧 URL パラメータツールを廃止した後、現在正規化シグナル（正規タグ、内部リンク）に依存しているのと同様の Yandex 版です — Yandex は、Google にはない明示的な robots.txt ディレクティブを提供しているのです。

Crawl-delay は廃止されました（2018年2月以降）

Yandex の robots.txt で Crawl-delay が機能すると読んだことがあるなら、その情報は古いものです。Yandex 自身の専用ページは明確です: “From February 22, 2018, Yandex doesn’t take into account the Crawl-delay directive.”

これは、少なくとも 1 つの広く読まれている SEO リソースが今も反対のことを述べているため、指摘する価値があります。Ahrefs の robots.txt ガイド（著者は Joshua Hardwick で、私ではありません）は現在、“Google no longer supports this directive, but Bing and Yandex do.” と述べています。Yandex に関しては、これは Yandex 自身の現在のドキュメントと矛盾しています。ここでは Yandex の専用で日付入りのページを権威とみなすべきですが、より広い教訓が有益です: クロール動作に関する主張は、二次情報のガイドを信頼する前に、エンジンのライブドキュメントで検証してください。 これらの詳細は変化し、優れた情報源でも古くなるからです。（Bing が今も crawl-delay を尊重しているという対比に注意してください — これは実際の Bingbot/YandexBot の相違点の 1 つです。）

代替となるのは、Yandex Webmaster のクロールレート設定で、YandexBot がサイトを取得する速度に影響を与えることができます。（Yandex の Crawl-delay ページは、実質的に 1 文とその設定へのポインタだけです。）

YandexBot が JavaScript を処理する方法

Yandex の JavaScript レンダリングは、Yandex 自身によって明示的に**ベータ（β）とラベル付けされており、デフォルトの動作は「ボットの裁量による」です — ボットは”will independently determine whether to execute JavaScript code on the site’s pages.” 実行する場合、“assess the quality and completeness of the content on the pages with and without JavaScript” を行い、訪問者にとってより有用と思われるバージョンを提供する可能性があります。

ここには、掘り下げる価値のある重要な緊張関係があります。2023年のYandexソースコードリーク（内部のエンジニアリング文書を公開したもので、公式声明ではありません。以下で詳しく説明します）は、より単純な構図を示唆していました。Mike Kingが*Search Engine Landのリーク分析で書いたように： “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.” (翻訳) 「YandexにはJavaScript用の独立したレンダリングシステムはありません。彼らは自社のドキュメントでそう述べており、Geminiと呼ばれるビジュアル回帰テスト用のWebdriverベースのシステムはあるものの、テキストベースのクロールに限定しています。」（この内部の「Gemini」はYandexのビジュアル回帰テスト*ツールであり、名前が同じでもGoogleのGemini AIモデルとはまったく無関係です。混同しないように明確にしておく価値があります。）そしてDan Taylorの Search Engine Journalの記事は、“nothing new to suggest Yandex can crawl JavaScript yet outside of already publicly documented processes.” (翻訳) 「すでに公開されているプロセス以外で、YandexがまだJavaScriptをクロールできることを示す新しいものはない。」と結論付けました。

したがって、正直な答えは「YandexBotがGooglebotと同じようにJSをレンダリングする」でも「YandexBotはJavaScriptに一切触れない」でもありません。Yandex自身の説明によれば、それは選択的かつベータ版です。リークの「独立したレンダリングシステムはない」という説明はその枠組みと一致していますが、それはYandexの開示ではなく、業界の報道を通じて伝えられたリークされた内部資料です。したがって、「アーキテクチャ的にGoogleより単純」というのは、2つの一貫したシグナルに対するもっともらしい解釈として扱い、文書化された事実としては扱わないでください。自分にとって重要なルートについては、どちらの説明も鵜呑みにせず、直接テストしてください：

• レンダリングされた出力： JavaScriptを無効にしてページを取得し、JSレンダリング版と比較します。2つが有意に異なる場合、Yandexがレンダリングされた方を表示したと想定しないでください。
• リソースへのアクセス： ページが依存するJS、CSS、APIエンドポイントがrobots.txtでブロックされていないことを確認します。YandexのYandexRenderResourcesBotはレンダリング時のリソースを取得しますが、（Yandex自身のドキュメントによると）メインのインデックスボットがすでに到達できるページのみです。許可されたページ上のブロックされたリソースは、それでも読み込まれません。
• 遅延およびインタラクティブなコンテンツ： DOMContentLoadedイベントの後またはクリックの背後で読み込まれるものは、レンダリングが保証されていません。Yandexの高度なレンダリング設定（window.YandexRotorSettings）は、「コンテンツが遅延して読み込まれる」サイトのために特別に存在します。これは、単なる設定オプションではなく、読む価値のあるシグナルです。

実用的な要点：Yandexの公式ドキュメントは、“Prohibit rendering if SSR (Server-Side Rendering) or pre-rendering is implemented on the site,” (翻訳) 「サイトでSSR（サーバーサイドレンダリング）またはプリレンダリングが実装されている場合は、レンダリングを禁止してください。」と推奨し、“Executing JavaScript code may create additional load on your server.” (翻訳) 「JavaScriptコードの実行はサーバーに追加の負荷をかける可能性があります。」と述べています。JS主体のコンテンツをYandexで確実にインデックスさせたい場合は、クライアントサイドレンダリングで運を試すのではなく、サーバーサイドで配信してください。

AJAXスタイルのサイトについて、Yandexは*“When indexing an AJAX site, the Yandex bot scans the original URLs and executes JavaScript code on them”* (翻訳) 「AJAXサイトをインデックスする際、Yandexボットは元のURLをスキャンし、それらに対してJavaScriptコードを実行します。」と述べており、古いHTMLスナップショットのハックからは移行しています。非推奨のmeta name="fragment"アプローチをまだ使用している場合、“the bot will ignore it and index the original page.” (翻訳) 「ボットはそれを無視して元のページをインデックスします。」その最新の推奨事項はGoogleのものと似ています：“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.” (翻訳) 「AJAXページのリンクが#文字を使用している場合は、この文字を含まないURLにアドレスを変更してください。たとえば、History APIを使用できます。」

2023年のソースコードリークがクローラーについて明らかにしたこと

2023年1月、Yandexの内部ソースコードが流出しました。これはSearch Engine Land、Search Engine Journalなどで広く裏付けられた出来事です。これを流出した内部文書であり、Yandexの公式発表ではないと扱ってください。しかし、クローラーの仕組みについての実際の詳細が明らかになりました。Mike King氏のSEL分析によると：“Yandex’s documentation discusses a dual-distributed crawler system. One for real-time crawling called the ‘Orange Crawler’ and another for general crawling.” (翻訳) 「Yandexの文書は二重分散クローラーシステムについて述べている。リアルタイムクローリング用の『オレンジクローラー』と、一般的なクローリング用のもう一つである。」彼はGoogleとの類似性を指摘し、Googleは*“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.”* (翻訳) 「リアルタイムクロール、定期クロール、稀なクロールの3つのバケットに階層化されたインデックスを持っていたと言われている。」つまり、両エンジンはコンテンツの更新頻度に応じたセグメント化されたクローリングを採用しているように見える。

この流出は、クローリングをサイトアーキテクチャに直接結び付けました。Dan Taylor氏のSEJ報道によると、“URLs that are reachable from the homepage have a ‘higher’ level of importance.” (翻訳) 「ホームページから到達可能なURLは『より高い』重要度を持つ。」これは「クローラーの仕組み」から「内部リンクが重要な理由」への明確な橋渡しであり、Googlebotにも適用される同じクロール深度のロジックです。

（規模の参考：広く引用される「1,922のランキング要因」という数字は特定のアーカイブファイルに固有であり、完全なコードベースには複数のファイルにわたってさらに多くの要因が含まれていると報告されています。特定の数字を引用する場合は、日付と出典を明記してください。）

YandexBotが今も重要な理由 — そしてrobots.txtでの一般的さ

Yandexの世界シェアはわずかですが、ロシアでのシェアはそうではありません：ロシアで約71％、Googleの約27％（2026年6月時点、StatCounter）。この安定性こそが、YandexBotを別途扱うべき理由のすべてです。ロシア/CIS向けのビジネスがあるなら、YandexBotをブロックすることは、その市場で支配的なエンジンを締め出すことになります。

サイトが実際にYandexBot向けに設定する頻度はどのくらいでしょうか？まれですが、増加傾向にあります。Web Almanac 2022 SEO章（私はその年のレビュアーで、2021年章の主執筆者でした）： YandexBot appeared in “just 0.5% of robots.txt files in 2021. By 2022, there was a six-fold increase, with 3% of files specifying Yandexbot.” (翻訳) 「2021年にはrobots.txtファイルのわずか0.5％にYandexBotが登場した。2022年までに6倍に増加し、3％のファイルがYandexbotを指定した。」小さいですが、明確な上昇傾向であり、「実際にどの程度使われているか」の有用なベースラインです。

ブロックするかどうかを決める場合、正直な枠組みは技術的な問題ではなくビジネス上の問題です。そして、これはウェブマスターフォーラムで繰り広げられる実際の議論です。YandexBotがその中で動作するより広い仕組み（URL発見、クロールスケジューラ、レンダリング、クロールとインデックスとランクの区別）については、クローリングハブを参照してください。また、ロシア/CIS戦略の一環としてYandexを具体的に設定する方法については、国際SEOおよび市場固有SEOの資料がそれを結び付けています。

AIまとめ

Advancedバージョンの簡潔な見解:

• YandexBot = Yandex検索のメインインデックス用クローラー — Googlebot/Bingbotに相当するYandex版。UA文字列: Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.268 （Chromeバージョンで判定しないこと — 変更されるため）。
• robots.txtのトークンは2つ、スコープが異なる: YandexBot = メインのインデックス用ボットのみ; Yandex = より広いボットファミリー。User-agent: Yandex ブロックがあると、Yandexは User-agent: * を無視する。一部のYandexボットはrobots.txtを完全に無視する場合がある。
• Clean-paramはYandex限定 — コンテンツを変更しないURLパラメータを統合する（Google/Bingに相当するものはない）。Disallow は不要で、交差的（ファイル内のどこにでも置ける）。
• Crawl-delayは廃止 — Yandexは 2018年2月22日 をもってこれを尊重しなくなった。代わりにCrawl rateツールを使用すること。一部のSEOガイドは今でもYandexがこれをサポートしていると誤って主張している。（Bingはサポートするが、Yandexはしない。）
• Disallow ≠ noindex — 禁止されたページは「Yandex検索に参加できる」。実際にページを削除するには noindex（metaまたはHTTPヘッダー）を使用する。
• JavaScriptレンダリングはベータ版であり、「ボットの裁量による」。 2023年のリークは「JavaScript用の独立したレンダリングシステムはない」ことを示唆していた — つまり、選択的であり、Googleの2段階パイプラインより単純。SSR/プリレンダリングを優先し、ハッシュバンURLは避けること（History APIを使用）。
• 2023年のソースコードリーク（リークであり、公式ではない）: 二重クローラーシステム（リアルタイムの「Orange Crawler」+ 一般クローラー）と、ホームページから到達可能なURLがより高い重要度を持つこと（クロール深度がシグナルとして）が明らかになった。
• 逆引き→正引きDNSで検証 し、yandex.ru/yandex.net/ yandex.com ホストに一致させること — GoogleとBingが使用するのと同じFCrDNS手法 — なりすまし可能なユーザーエージェントは決して使わないこと。
• なぜ重要か: ロシアの検索シェア約71%（Google約27%、2026年6月）。世界的にはわずかだが、地域的には支配的。robots.txtでは、Web Almanacによるとファイルの約0,5%（2021年）→ 3%（2022年）。

公式ドキュメント

一次情報のドキュメントで、主にYandex Webmaster Helpから、Google/Bingの対比リンク付き。注意: Yandex Webmasterのいくつかのツールページ（Crawl rate、robots.txtアナライザー）はアプリページであり、完全に表示するにはログインしたブラウザが必要。また、Google/Bingの検証ページはJavaScriptレンダリングされる — リンクが切れた場合はライブで詳細を確認すること。

Yandex

• User-agentディレクティブ — YandexBot と Yandex のトークンのスコープと優先順位のルール。
• ロボットがYandexに属するか確認する方法 — 完全なユーザーエージェント文字列と逆DNS検証方法。
• robots.txtの使用 — Yandexが認識するディレクティブ、500 KB / HTTP 200のファイル要件、および Disallow ≠ インデックスに関する注記。
• Clean-paramディレクティブ — Yandex独自のパラメータ統合ディレクティブ（構文+実例）。
• Crawl-delayディレクティブ — 2018年2月22日以降Crawl-delayが無視されていることを示すページ。
• サイトのクロールレート — Yandex WebmasterにおけるCrawl-delayの代替。
• JavaScriptを使用したページのインデックス作成（β） — 「ボットの裁量による」デフォルトとSSRの推奨。
• AJAXサイトのインデックス作成 — 元のURLでのJS実行とHistory-APIの推奨。

Google / Bing（比較用）

• Verify Requests from Google Crawlers and Fetchers — Googleの逆/正引きDNS方式（googlebot.com/google.com/googleusercontent.com に対する）— Yandexが使用するのと同じFCrDNSパターンです。
• Which crawlers does Bing use? — Bingのクローラーリスト。Bingは *.search.msn.com に対して検証し、今でも crawl-delay を尊重します（Yandexは尊重しません）。

ソースからの引用

Yandex自身のドキュメントからの公式見解、および業界報道を通じて伝えられた内部流出資料。各リンクは、引用した箇所にジャンプするディープリンクです。YandexのドキュメントはYandex自身が公開した英語翻訳であり、それらのページから逐語的に引用しています。

Yandex — robots.txt のトークンと優先順位

• “If the User-agent: Yandex string is detected, the User-agent: * string is ignored.” (翻訳) 「User-agent: Yandex 文字列が検出された場合、User-agent: * 文字列は無視されます。」 引用へジャンプ
• “Some Yandex robots may ignore directives in robots.txt, including those for User-agent: Yandex.” (翻訳) 「一部のYandexロボットは、User-agent: Yandex に対するものを含め、robots.txt 内のディレクティブを無視する場合があります。」 引用へジャンプ
• “YandexAdditionalBot … Helps process robots.txt to prevent page content from appearing in Search with Yandex AI responses. Applies to the pages that have been indexed by the primary crawler.” (翻訳) 「YandexAdditionalBot … ページコンテンツがYandex AI応答付きの検索結果に表示されないように、robots.txt の処理を支援します。プライマリクローラーによってインデックスされたページに適用されます。」 引用へジャンプ

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.” (翻訳) 「一部のロボットは、関連するユーザーエージェントを示すことでYandexロボットになりすますことができます。逆DNSルックアップを使用してロボットの信頼性を確認できます。」 引用へジャンプ
• “Check whether the host belongs to Yandex. All Yandex robots have names ending in yandex.ru, yandex.net or yandex.com.” (翻訳) 「ホストがYandexに属しているかどうかを確認します。すべてのYandexロボットの名前は yandex.ru、yandex.net、または yandex.com で終わります。」 引用へジャンプ
• “If the IP addresses do not match, it means that the host name is fake.” (翻訳) 「IPアドレスが一致しない場合、ホスト名が偽物であることを意味します。」 引用へジャンプ

Yandex — robots.txt と Clean-param

• “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.” (翻訳) 「robots.txt で制限されたページは Yandex 検索に参加できます。検索からページを削除するには、ページの HTML コードで noindex ディレクティブを指定するか、HTTP ヘッダーを設定してください。」 引用へ移動
• “The Yandex robot uses this directive to avoid reloading duplicate information. This improves the robot’s efficiently and reduces the server load.” [sic — “efficiently” is Yandex’s own typo] (翻訳) 「Yandex ロボットはこのディレクティブを使用して、重複情報の再読み込みを回避します。これによりロボットの効率が向上し、サーバーの負荷が軽減されます。」 [原文ママ — 「efficiently」は Yandex 自身のタイプミス] 引用へ移動
• “The Clean-param directive does not require mandatory combination with the Disallow directive.” (翻訳) 「Clean-param ディレクティブは、Disallow ディレクティブとの必須の組み合わせを必要としません。」 引用へ移動
• “Do not restrict such pages in robots.txt, or the Yandex bot can’t index them and detect your instructions.” (翻訳) 「そのようなページを robots.txt で制限しないでください。制限すると、Yandex ボットがそれらをインデックスできず、あなたの指示を検出できなくなります。」 引用へ移動

Yandex — Crawl-delay と JavaScript

• “From February 22, 2018, Yandex doesn’t take into account the Crawl-delay directive.” (翻訳) 「2018年2月22日以降、Yandex は Crawl-delay ディレクティブを考慮しません。」 引用へ移動
• “Prohibit rendering if SSR (Server-Side Rendering) or pre-rendering is implemented on the site.” (翻訳) 「サイトで SSR（サーバーサイドレンダリング）またはプリレンダリングが実装されている場合は、レンダリングを禁止します。」 引用へ移動
• “When indexing an AJAX site, the Yandex bot scans the original URLs and executes JavaScript code on them.” (翻訳) 「AJAX サイトをインデックスするとき、Yandex ボットは元の URL をスキャンし、それらに対して JavaScript コードを実行します。」 引用へ移動

2023年の Yandex ソースコードリーク (流出した内部ドキュメント。業界報道を通じて伝えられたものであり、Yandex の公式声明ではありません)

• “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.” — Mike King, iPullRank, via Search Engine Land. (翻訳) 「Yandex には JavaScript 用の独立したレンダリングシステムはありません。彼らはドキュメントでそう述べており、Gemini と呼ばれる Webdriver ベースのビジュアルリグレッションテストシステムを持っていますが、テキストベースのクロールに限定しています。」 — Mike King（iPullRank）、Search Engine Land 経由。 報道を読む
• “Yandex’s documentation discusses a dual-distributed crawler system. One for real-time crawling called the ‘Orange Crawler’ and another for general crawling.” — Search Engine Land. (翻訳) 「Yandex のドキュメントでは、二重分散クローラーシステムについて説明されています。1つは「Orange Crawler」と呼ばれるリアルタイムクローリング用で、もう1つは一般的なクローリング用です。」 — Search Engine Land。 報道を読む
• “There’s nothing new to suggest Yandex can crawl JavaScript yet outside of already publicly documented processes.” — Dan Taylor, via Search Engine Journal. (翻訳) 「すでに公開されているドキュメント化されたプロセス以外に、Yandex がまだ JavaScript をクロールできることを示す新しいものはありません。」 — Dan Taylor、Search Engine Journal 経由。 報道を読む

Web Almanac 2022、SEO チャプター (私はレビュアーでした)

• “Yandexbot was specified in just 0.5% of robots.txt files in 2021. By 2022, there was a six-fold increase, with 3% of files specifying Yandexbot.” (翻訳) 「Yandexbotは2021年のrobots.txtファイルのわずか0.5%に指定されていました。2022年までに6倍に増加し、3%のファイルがYandexbotを指定しました。」 引用へジャンプ

YandexBotをブロック、許可、またはスロットルすべきか?

YandexBotの問題は、ほとんどの場合、技術的なコスチュームを着たビジネス上の問題です。それを解決してください。

YandexBotに関する誤解と避けるべき間違い

最もよく発生する罠 — いくつかは広く繰り返され、修正する価値があります:

• 「Crawl-delayはYandexBotを遅くする。」 いいえ。Yandexは2018年2月22日にCrawl-delayの尊重を停止しました(「YandexはCrawl-delayディレクティブを考慮しません」)。一部のSEOガイドは今でもYandexがそれをサポートしていると主張しています — それは古い情報です。代わりにYandex WebmasterのCrawl rate設定を使用してください。 (代わりに: クロール動作の主張をYandexのライブドキュメントで検証し、Crawl-delayではなくCrawl rateでスロットルしてください。)
• 「robots.txtのDisallowはページをYandexから削除する。」 いいえ — Yandex自身のドキュメントは、拒否されたページが「Yandex検索に参加できる」と述べています。Disallowはクロールを停止しますが、インデックスは停止しません。 (代わりに: ページを実際に除外するにはHTMLまたはHTTPヘッダーでnoindexを使用し、Yandexがタグを認識できるようにクロールさせてください。)
• 「User-agent: YandexBotとUser-agent: Yandexは同じものだ。」 いいえ — YandexBotはメインのインデックスボットのみを対象とし、Yandexはより広いファミリーを対象とします。また、User-agent: Yandexブロックは、YandexがUser-agent: *ブロックを完全に無視するようにします。 (代わりに: 実際に意図するスコープに一致するトークンを選択し、*ルールがYandexボットに届くと思い込まないでください。)
• 「YandexBotはGooglebotと同じようにJavaScriptをレンダリングする。」 確立されていません。Yandexのレンダリングはベータ版であり、「ボットの裁量による」ものであり、2023年のリークは「JavaScript用の個別のレンダリングシステムはない」ことを示唆しました。 (代わりに: クライアントサイドレンダリングがインデックスされると思い込むのではなく、SSR/プリレンダリングでJS依存コンテンツを提供してください。)
• 「ユーザーエージェント文字列はYandexBotであることを証明する。」 いいえ — それは簡単に偽装できます。 (代わりに: GooglebotやBingbotを検証するのとまったく同じように、yandex.ru/yandex.net/yandex.comホストへの逆引き→正引きDNSで検証してください。)
• 「ロシア以外のサイトへのYandexBotトラフィックは本質的に疑わしい/偽物だ。」 必ずしもそうではありません — 正当なYandexBotは.ruドメインだけでなく、グローバルに公開されているサイトもクロールします。 (代わりに: 偽装と判断する前にDNSで検証してください。実際のYandexホストは、あなたのオーディエンスに関係なく本物です。)
• 「2023年のリークは、Yandexが秘密の優れたJSクローラーを持っていることを証明した。」 いいえ — 報道は「すでに公に文書化されたプロセス以外に、YandexがまだJavaScriptをクロールできることを示唆する新しいものはない」と結論付けました。 (代わりに: リークを過大評価しないでください。それは限定的なレンダリングの状況を裏付けたものであり、覆したものではありません。)

YandexBot — チートシート

ユーザーエージェント文字列(メインのインデックスボット)

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

YandexBotトークンで一致させ、**Chrome/81.0.4044.268**バージョンでは一致させないでください — Yandexはブラウザバージョンが変更される可能性があると述べています。

2つのrobots.txtトークン

User-agent: Yandex ブロックがあると、Yandex はあなたの User-agent: * ブロックを無視します。 一部の Yandex ボットは robots.txt を完全に無視する場合があります。

Yandex が認識するディレクティブ

Clean-param の簡易形式

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

?ref=… のバリエーションを 1 つの URL に統合します。Disallow は不要で、交差的（ファイル内のどこにでも配置可能）です。

Google と Bing との比較（すべて前方確認付き逆引き DNS を使用）

早わかり

• Crawl-delay: 廃止 — 2018年2月22日以降、Crawl rate ツールを使用してください。（Bing は依然として crawl-delay を尊重しますが、Yandex は尊重しません。）
• robots.txt は robots.txt という名前で、500 KB 以下、HTTP 200 を返す必要があります。
• JavaScript レンダリング: ベータ版、「ボットの裁量による」— SSR を推奨します。
• ロシアでのシェア: 約71%（Google 約27% に対し）、2026年6月（StatCounter）。
• robots.txt 内: 0,5%（2021年）→ 3%（2022年） のファイル（Web Almanac）。

ボットが本当に YandexBot であることを確認する

ユーザーエージェントは簡単に偽装されるため、逆引き DNS ルックアップ（Yandex ドメインで終わる必要がある）と、それに続く前方 DNS ルックアップ（同じ IP に解決される必要がある）で確認してください。これは Googlebot や Bingbot に使用するのとまったく同じ FCrDNS パターンです — ドメインの接尾辞だけが異なります（yandex.ru / yandex.net / yandex.com）。

macOS / Linux

# 1) Reverse-DNS the IP from your logs — the host must end in
#    yandex.ru, yandex.net, or yandex.com
host 5.255.253.1
# → 1.253.255.5.in-addr.arpa domain name pointer <something>.yandex.com  (illustrative)

# 2) Forward-DNS that hostname back — it must resolve to the same IP
host <the-hostname-from-step-1>.yandex.com

Windows

nslookup 5.255.253.1
nslookup <the-hostname-from-step-1>.yandex.com

逆引きルックアップが Yandex ドメインで終わらない場合、または前方ルックアップが元の IP を返さない場合、それは YandexBot ではありません — ドロップするかレート制限をかけます。

ログファイルから検証済みと偽装の YandexBot ヒットを抽出する

「YandexBot」行を取得し、各送信元 IP の PTR を確認する簡単なシェルパスです。ログ形式に合わせてフィールド位置を調整してください（これは IP が最初にある一般的な複合形式を想定しています）。

# Pull unique IPs that claimed to be YandexBot, then reverse-resolve each
grep -i 'YandexBot' access.log \
  | awk '{print $1}' | sort -u \
  | while read ip; do
      host="$(host "$ip" 2>/dev/null | awk '/pointer/{print $NF}' | sed 's/\.$//')"
      case "$host" in
        *.yandex.ru|*.yandex.net|*.yandex.com) echo "REAL   $ip  $host" ;;
        "" )                                    echo "NO-PTR $ip" ;;
        * )                                     echo "FAKE   $ip  $host" ;;
      esac
    done

REAL 行は、アクションを起こすものについては前方ルックアップでの確認が依然として必要ですが（host "$host" が元の IP を返す必要があります）、これで明らかな偽装者を先に選別できます。

ユーザーエージェント内の YandexBot トークンに一致する正規表現

製品トークンに一致させます（変更される Chrome バージョンではなく）。大文字と小文字を区別しません:

YandexBot/\d+(\.\d+)?

より広い「任意の Yandex ロボット」一致（YandexImages、YandexMobileBot などを捕捉）:

Yandex[A-Za-z]*/\d

覚えておいてください: 一致するユーザーエージェントは必要ですが十分ではありません — 信頼する前に、上記の DNS チェックと任意の正規表現一致を組み合わせてください。

Yandex 向けの robots.txt の出発点

# Slow/duplicate-parameter cleanup for all Yandex bots
User-agent: Yandex
Clean-param: utm_source&utm_medium&utm_campaign /

# Block only the main indexing bot from a low-value space
User-agent: YandexBot
Disallow: /internal-search/

Sitemap: https://example.com/sitemap.xml

覚えておいてください: Disallow はクロールをブロックし、インデックスはブロックしません — ページを Yandex 検索から削除するには noindex を使用してください。すべての Yandex ボットを完全にブロックするには（一部は robots.txt を無視します）、サーバーで検証済み IP によってブロックしてください。

YandexBot 準備完了チェックリスト

YandexBot を偶然ではなく意図的に処理していることを確認する簡単なパス:

• サイトにとってYandexが重要かどうかを判断済みである（ロシア/CIS圏の オーディエンスやビジネスがあるかどうか）— ブロック/許可の全体像はこれに懸かっている。
• ボット検証は逆引き+正引きDNSを使用してyandex.ru/yandex.net/ yandex.comホストを確認する — 偽装可能なユーザーエージェントやハードコードされたIPリストではない。
• 意図に合った正しいrobots.txtトークンを使用している：YandexBot （メインのインデックス用ボットのみ）vs. Yandex（より広いファミリー）。
• User-agent: Yandexのブロックにより、YandexがUser-agent: *の ブロックを無視することを理解している。
• Crawl-delayに依存していない（2018年2月22日以降無効）— 代わりに Yandex Webmasterのクロールレートツールで調整する。
• Disallowでインデックス除外していない — それはnoindexの役割（クロールは許可したまま）。
• 重複するURLパラメータは、該当する場合Clean-paramで統合している （Disallowは不要で、ファイル内のどこにでも置ける）。
• JS依存のコンテンツはSSR/プリレンダリングで配信している — Yandexのレンダリングはベータ版で「ボットの裁量」によるため。
• AJAXルートはクリーンURL / History APIを使用しており、ハッシュバング（#!）URLではない。
• すべてのYandexボットを完全に除外する場合（robots.txtを無視するものもいる）、 robots.txtだけでなく、サーバー側で検証済みIPによるブロックを行っている。

YandexBotの検証と監視のためのツール

YandexBotに関して最もよくある2つの作業は、アクセスが本物かどうかの確認と、実際にどれだけクロールされているかの把握です。まずはこちらから：

• Googlebot Verifier — ログからIPを貼り付けると、 正引き確認付き逆引きDNSチェックを実行してくれます（Yandexがyandex.ru/yandex.net/yandex.comホストの確認方法として文書化しているのと同じ方法）。 偽装者の場合は実際のネットワーク所有者を特定します。 怪しいアクセスごとに手動でhost/nslookupを実行するより速く、 混合ログを確認する場合はGooglebot、Bingbot、主要なAIクローラーにも対応しています。
• Log File Analyzer — サーバーアクセスログ （nginx、Apache、IIS/W3C、またはJSON）をドロップすると、YandexBotの実際のクロールフットプリントがわかります： サイトのどの程度をクロールしているか、どのセクションか、ステータスコードの無駄、 そしてYandexBotと自称するが検証に合格しないIPを報告するスプーファーレポート。 上記のディシジョンツリーの「このクロールが実際にサーバーに負担をかけているか」という疑問に役立ちます — すべてブラウザ内で実行され、アップロードは一切ありません。

Yandex公式から

• Yandex Webmaster — クロールレート設定（Crawl-delayの代替） とrobots.txtアナライザーはここにあります。どちらも使用するには、検証済みでログインしたYandex Webmasterアカウントが必要です。

時間をかける価値のあるリソース

関連する私の記事

• Indexed, though blocked by robots.txt — robots.txtでブロックされたURLがなぜインデックスされるのか；同じDisallow ≠ noindexの罠がYandexにも当てはまります。
• Robots.txt and SEO: Everything You Need to Know — 一般的なrobots.txtのリファレンス（注：YandexのCrawl-delayに関する記述は、Yandex自身の日付入りドキュメントによると古くなっています — ソースに対して検証することの良い例です）。
• The Story of Blocking 2 High-Ranking Pages With Robots.txt — ランキングページをブロックしたときに実際に何が起こるかについての私のファーストパーティ実験。
• Meet the New Web Crawlers: AI Bots Are Closing in on Search Engine Bots — ログに現れるクローラーの顔ぶれがどう変わったか。
• The SEO Bots That ~140 Million Websites Block the Most — Xibeijia Guanとの共同研究によるrobots.txtブロック率の調査（西洋のSEOツールボットを対象としており、YandexBotは対象外 — 方法論の参考と、サイトがYandex向けに設定することがいかに稀かの対比として引用）。

私の講演

• 検索の仕組み（SlideShare）— クロール、レンダリング、インデックス、ランキングに関する私の解説です。（常時適用される免責事項：「これは私のシステム理解に基づくもので…100%完全または正確ではありません。」）

業界からの情報

• YandexがGoogleやその他のSEO情報をソースコードリークからスクレイピング（Mike King / iPullRank、Search Engine Land、2023年1月30日）— 「Orange Crawler」デュアルクローラーシステムと「JavaScript用の独立したレンダリングシステムなし」という発見。
• Yandexデータリーク：発見したランキング要因と神話（Dan Taylor、Search Engine Journal、2023年2月1日）— クロール深度を重要度シグナルとする点と「JavaScriptクロールに関する新しい情報はない」という結論。
• Yandexの「リーク」が1,922の検索ランキング要因を明らかに（Search Engine Land）— リークの規模に関する文脈と年代。
• YandexコードリークはGoogleについて何か教えてくれるか？（seoClarity）— リークのエンジン横断的な慎重な読み解き。
• Yandex SEOの究極ガイド（Search Engine Journal）— クローラーを超えた、より広範なYandex最適化の文脈。
• Web Almanac 2022 — SEO章（HTTP Archive）— robots.txtでのYandexBot採用統計の出典。

引用に値する統計

• ロシアの検索シェア約71% — StatCounterによると、Googleの約27%に対するYandexのロシア検索市場シェア（2026年6月報告のデータ。時系列に敏感なため、月/年を引用し、変動を想定してください）。これが、YandexBotを「Google以外のボットをすべてブロック」とは別に扱うべき理由のすべてです。 出典
• robots.txtファイルの0,5% → 3% — YandexBotは2021年に「robots.txtファイルのわずか0.5%」で指定されていたのが、2022年には「Yandexbotを指定するファイルの3%」に増加 — 6倍の増加ですが、それでも小規模です（私がレビューしたWeb Almanac 2022 SEO章）。「実際にどの程度一般的か」の歴史的ベースラインとして有用です。 出典
• 2018年2月22日 — Yandexが自社のドキュメントに従ってCrawl-delayのサポートを停止した日付。Yandexがまだこのディレクティブをサポートしていると主張する古いガイドに対抗するための、正確で引用可能な非推奨日付です。 出典

自分で試す：YandexBot

YandexBot、そのrobots.txtの動作、およびGooglebotやBingbotとの比較に関する5つの簡単な質問です。各質問に回答を選び、確認してください。

変更履歴