robots.txtでCSS・JSを拒否していないか｜URL検査での点検手順

ブラウザで見れば、ページはきれいに表示されている。なのに robots.txt を開くと、Disallow: /assets/ や Disallow: /wp-includes/ が並んでいる。——管理画面や部品のフォルダは「検索に関係ないから閉じておく」という書き方は、昔はよく見かけました。

先に答えを書きます。そこにページの見た目や中身を組み立てる CSS・JavaScript（以下 JS）が入っているなら、拒否は外すべきです。Google は robots.txt で拒否された URL を取りに行きません。そして Google 自身が、仕様書の例で「CSS や JS はレンダリング（HTML・CSS・JS を組み立てて、人が見る画面を再現する処理）に必要だ」と書いています。

Googleは拒否されたファイルを取りに行かない

仕組みは単純です。

Google の「JavaScript SEO の基本」は、Googlebot がクロール待ちの列から URL を取り出して HTTP リクエストを送る前に、まず robots.txt を読んでクロールが許可されているかを確かめる、と説明しています。拒否されていれば、その URL へのリクエスト自体を飛ばします。

CSS ファイルも JS ファイルも、1つずつが独立した URL です。だから /assets/ を拒否すれば、そこにある style.css も main.js も、Googlebot は取りに行かないと考えるのが自然です。

困るのはその先です。同じページは、レンダリング後の HTML でコンテンツが見えているかを、リッチリザルト テストか URL 検査ツールで確かめるよう案内しています。そして、レンダリング後の HTML に表示されないコンテンツは Google がインデックスに登録できない、と明記しています。

JS で本文や商品一覧を差し込んでいるページで、その JS が拒否されていたらどうなるか。本文の中身が、Google 側の画面に出てこない可能性があります。

公式の例そのものが「CSSとJSは開けておけ」

robots.txt の仕様ページには、ちょうどこの場面の例があります。

すべてのクローラーに /includes/ を拒否しつつ、Googlebot にだけ /includes/ を許可する書き方です。添えられたコメントには、このフォルダには .css や .js が入っていて、Google はレンダリングにそれらを必要とするので、Googlebot にはクロールを許可している、という趣旨が書かれています。

User-agent: *
Disallow: /includes/

User-agent: Googlebot
Allow: /includes/

つまり「部品フォルダは閉じたい。でも Google のレンダリングは邪魔したくない」という悩みは、公式も想定している悩みです。答えは、閉じたまま例外を開けること。

遮断を見つけて直す6ステップ

ここからは、自社サイトで実際に点検する手順です。

1. 対象ページを3つ選ぶ。 トップ、主要なカテゴリ一覧、JS で中身を出している代表ページ（検索結果ページ・商品一覧・タブ切り替えのあるページなど）が目安です。全ページを見る必要はありません。テンプレートが同じなら結果も同じになりやすいからです。
2. robots.txt を開いて Disallow を書き出す。 https://自社ドメイン/robots.txt をブラウザで開き、User-agent: * と User-agent: Googlebot のグループにある Disallow: を全部メモします。Googlebot や Google-InspectionTool だけに向けたグループがあるかも、ここで見ておきます（理由は後半の「よくある誤解」で触れます）。
3. URL 検査で「公開 URL をテスト」を実行する。 Search Console の URL 検査に対象ページを入れ、テスト結果の「テスト済みのページを表示」を開きます。ヘルプによると、ここで Google-InspectionTool から見たページのスクリーンショットを確認でき、「その他の情報」から読み込まれたリソースの一覧なども見られます。
4. 読み込めなかったリソースを、手順2のメモと突き合わせる。 一覧に読み込めなかったファイルが出ていたら、その URL のパスが、メモした Disallow のどれに当たるかを探します。CSS・JS・Web フォント・画像のどれかで、ページの見た目や本文に関わるものだけを拾います。
5. Allow で例外を足す。 親フォルダの Disallow は消さずに、必要なサブフォルダや拡張子だけを Allow します（書き方は次のワークスルー参照）。編集前の robots.txt は必ず別名で保存しておきます。1行の書き間違いでサイト全体を閉じる事故を、すぐ戻せるようにするためです。
6. もう一度「公開 URL をテスト」して比べる。 スクリーンショットのレイアウトと本文が、ブラウザで見た画面に近づいたか。読み込めなかったリソースが消えたか。この2点を、手順3で残した画面と並べて確かめます。

ワークスルー：WordPressの部品フォルダを丸ごと閉じていた例

よくある形で、一度通してみます。架空の自社サイトで、robots.txt がこうなっていたとします。

User-agent: *
Disallow: /wp-admin/
Disallow: /wp-includes/
Disallow: /wp-content/plugins/

手順3で商品一覧ページを検査すると、スクリーンショットは文字だけが縦に並び、絞り込みの結果も空でした。手順4で読み込めなかったリソースを見ると、/wp-includes/js/ 配下の JS と、/wp-content/plugins/ 配下にある一覧表示プラグインの CSS・JS が出ています。2行目と3行目の Disallow がまさに原因です。

ここで /wp-includes/ の行を丸ごと消す手もあります。ただ、閉じておきたい理由が社内にあるなら、例外だけ開けるほうが合意を取りやすいでしょう。直したあとの形はこうです。

User-agent: *
Disallow: /wp-admin/
Disallow: /wp-includes/
Allow: /wp-includes/*.css
Allow: /wp-includes/*.js
Disallow: /wp-content/plugins/
Allow: /wp-content/plugins/*.css
Allow: /wp-content/plugins/*.js

なぜ Allow が勝つのか。Google の仕様では、同じ URL に Allow と Disallow の両方が当たるとき、パスがより長い（＝より具体的な）ルールを使い、それでも決まらないときは制限の弱いほうを使うと説明されています。/wp-includes/*.js は /wp-includes/ より長いので、JS ファイルには Allow が当たります。* のワイルドカードは sitemap 以外のすべてのルールで使える、と作成ガイドにあります。

判定の細かい数え方は、robots.txtのAllowとDisallowはどちらが優先されるかで例を並べています。

手順6で再テストすると、スクリーンショットに一覧と絞り込みが出て、読み込めなかったリソースから該当ファイルが消えました。これで直ったと判断します。

遮断の重さを決める判定表

読み込めなかったリソースが出ても、全部を開ける必要はありません。何が欠けたかで判断します。

1行目は、さきほどのワークスルーの絞り込み JS がまさにこれでした。スクリーンショットが空だったのは、見た目ではなく中身の問題だったわけです。

最後の行は見落としやすいところです。

自社のrobots.txtで直せない遮断

robots.txt の作成ガイドによると、robots.txt のルールは置かれた場所と同じプロトコル・ホスト・ポートの中だけに効きます。https://example.com/robots.txt のルールは、https://m.example.com/ のようなサブドメインには及びません。

だから CSS や JS を static.example.com のような別ホストから配っているなら、見るべきはそのホストの robots.txt です。外部の配信サービスなら、自社では書き換えられません。本文を出す JS がそこにあるなら、自社ドメインから配信する方法を開発側と相談するのが現実的です。

よくある誤解

「URL 検査で開いていれば、検索でも開いている」とは限りません。 Google の一般的なクローラーのページには、ユーザーエージェント Google-InspectionTool だけに向けたルールは、URL 検査などのテストツールに効き、Google 検索には影響しない、と書かれています。robots.txt に Google-InspectionTool 用のグループを作っていると、テスト結果と本番の Googlebot の扱いがずれることがあります。手順2で、このグループの有無も一緒に見てください。

「直したらすぐ反映される」とも限りません。 JavaScript SEO の基本には、Google のレンダリングの仕組みはネットワークを節約するために積極的にキャッシュし、キャッシュ用のヘッダーを無視することがあり、古い JS や CSS を使う場合がある、とあります。対策として、ファイル名に内容から作った指紋を入れる方法（例: main.2bb85551.js）が挙げられています。再テストで変化が見えないときは、ファイル名が変わっていないことも疑ってください。

「ルールの大文字小文字はどちらでもいい」も誤りです。 作成ガイドは、ルールは大文字と小文字を区別すると明記しています。Allow: /Assets/ と書いても /assets/style.css には当たりません。

直す前に見る点検表

全部「はい」になれば、少なくとも自社の robots.txt が Google のレンダリングを止めている状態は解消できています。

なお、robots.txt はクロールを止める仕組みで、検索結果からページを外す仕組みではありません。逆に「見せたくないページを robots.txt で閉じたのに検索に残る」という悩みなら、noindexが効かないときはrobots.txtを疑うが近い話です。JS で作ったリンクが辿られない問題は、JavaScriptのリンクがクロールされない原因で扱っています。