ECサイトのrobots.txt設定完全ガイド｜売上を守る正しい設定方法とテンプレート
「ECサイトの検索順位が下がっている気がする…」 「robots.txtって設定した方がいいの?間違えると怖い…」 「カート機能やログインページまでGoogleにインデックスされている…」
ECサイトを運営していて、このような悩みを抱えていませんか?実は、ECサイト特有のページ構造を理解せずにrobots.txtを設定すると、重要な商品ページがクロールされなくなったり、逆に無駄なページばかりがクロールされてサーバーに負荷をかけたりする可能性があります。
結論から言うと、ECサイトのrobots.txtは「最低限ブロック+サイトマップ案内」を基本にしつつ、検索・フィルタ・内部機能ページのクロールを抑える設計が最も扱いやすいです。この記事では、ECサイト運営者が安心して設定できるように、プラットフォーム別の具体例とコピペで使えるテンプレートを用意しました。
robots.txtを正しく設定することで、商品ページへのクロール効率が向上し、検索順位の改善やサーバー負荷の軽減につながります。ぜひ最後までお読みいただき、あなたのECサイトに最適な設定を見つけてください。
目次
ECサイトにrobots.txt設定が必要な3つの理由
ECサイト特有のページ構造とクロールの課題
ECサイトは一般的なコーポレートサイトやブログと異なり、商品ページ・カテゴリページ・カートページ・マイアカウントページなど、多種多様なページタイプで構成されています。加えて、検索機能・絞り込みフィルタ・並び替え機能によって、同じ商品でも無限にURLが生成される特徴があります。
この構造は、Googleのクローラーにとって大きな負担となります。クローラーは限られた時間とリソース(クロールバジェット)の中でサイトを巡回するため、重要でないページに時間を費やしてしまうと、本当に評価してほしい商品ページやカテゴリページが十分にクロールされない可能性があるのです。
robots.txtを適切に設定することで、クローラーの巡回を効率化し、重要なページに集中させることができます。ECサイトの規模が大きくなればなるほど、この設定の重要性は増していきます。
クロールバジェットの最適化でSEO効果を高める
クロールバジェットとは、検索エンジンが特定のサイトに対して割り当てるクロール(巡回)のリソースのことです。ECサイトでは商品数が数千〜数万点になることも珍しくなく、さらにフィルタやソート機能で生成されるURLを含めると、膨大なページ数になります。
Googleのクローラーは全てのページを平等にクロールするわけではありません。重要度の低いページや重複コンテンツに時間を費やすと、新商品ページや更新した商品情報が検索結果に反映されるまでに時間がかかってしまいます。
robots.txtで不要なURLへのクロールをブロックすることで、クローラーは商品ページやカテゴリページなど、SEO上重要なページに集中できます。結果として、新商品の掲載スピードが向上し、検索順位の改善にもつながるのです。
サーバー負荷軽減とユーザー体験の向上
ECサイトは商品検索やカートシステムなど、動的な処理が多いため、通常のWebサイトよりもサーバーに負荷がかかりやすい特徴があります。Googleのクローラーが過剰にアクセスすると、サーバーのリソースが圧迫され、実際のお客様がサイトを訪れた際にページの表示が遅くなる可能性があります。
特に、検索結果ページや並び替え機能のように動的にページが生成されるURLは、データベースへのクエリが発生するため、サーバー負荷が高くなります。これらのページへの不要なクロールをrobots.txtでブロックすることで、サーバーリソースを本来のお客様のために確保できます。
ページ表示速度はユーザー体験に直結し、さらにSEOの評価指標にもなっています。robots.txtによるサーバー負荷軽減は、間接的にSEO効果とコンバージョン率の向上につながる重要な施策なのです。
ECサイトで許可すべきページ・ブロックすべきページ
必ず許可すべき重要ページ一覧
ECサイトでクロールを許可すべきページは、主に「お客様が商品を見つけて購入を検討するページ」です。具体的には以下のページタイプを許可する必要があります。
商品詳細ページ(/products/ や /item/ など) 個別の商品情報を掲載するページは、ECサイトのSEOにおいて最も重要です。商品名や型番で検索したユーザーを直接商品ページに誘導できるため、必ずクロールを許可してください。
カテゴリページ・ブランドページ 「レディース 靴」「Nike スニーカー」など、カテゴリやブランドで検索するユーザーも多いため、これらのページも重要です。商品一覧ページとして機能し、内部リンクのハブにもなります。
特集・キャンペーンページ 季節の特集やセール情報など、期間限定で集客力のあるコンテンツはクロールを許可しましょう。ただし、終了したキャンペーンページは適宜noindexタグを設定することも検討してください。
これらのページは、CSS・JavaScript・画像ファイルも含めて、基本的に全て許可(Allow)する設定が推奨されます。レンダリング評価に必要なリソースをブロックすると、SEOに悪影響を与える可能性があるためです。
絶対にブロックすべき内部機能ページ
ECサイトには、検索エンジンにインデックスされる必要がないページが数多く存在します。これらのページをブロックすることで、クロールバジェットを節約し、サーバー負荷も軽減できます。
カート・チェックアウト・決済ページ(/cart/ /checkout/ など) カートや決済プロセスのページは、ユーザーごとに動的に生成され、SEO上の価値もありません。むしろ、これらのページがインデックスされると、セキュリティ上のリスクにもなりかねません。必ずブロックしてください。
マイアカウント・ログインページ(/my-account/ /login/ など) 会員情報や注文履歴など、個人情報に関連するページも当然ブロック対象です。ログインが必要なページは、robots.txtに加えて、サーバー側の認証でもアクセス制限をかけることを推奨します。
サイト内検索結果ページ(/search ?s= など) ユーザーが検索した結果を表示するページは、無限に生成される可能性があり、検索エンジンからのアクセスは不要です。これらをブロックすることで、重複コンテンツの問題も回避できます。
「カートに追加」などのアクションURL(add-to-cart= など) ボタンクリックで発火するアクションURLも、クロール不要です。WooCommerceなどのプラットフォームでは、パラメータ付きのURLが生成されるため、ワイルドカード(*)を使ってブロックします。
注意が必要なフィルタ・ソート・ページネーション
絞り込み・並び替え機能のURL制御方法
ECサイトの絞り込み機能や並び替え機能は、ユーザーにとって便利な一方で、SEO上の課題も生み出します。色・サイズ・価格帯などで絞り込むたびに新しいURLが生成されるため、同じ商品一覧でも無限にURLのバリエーションができてしまうのです。
クロールすべき絞り込みパターンの見極め 全ての絞り込みURLをブロックするのではなく、検索需要があるパターンは許可することも検討してください。例えば「レディース 靴 黒」など、色での絞り込みは検索されやすいため、canonical設定とあわせてクロールを許可する選択肢もあります。
パラメータベースのフィルタはブロック 一方で、?sort=price ?order=desc ?filter=color-redのように、パラメータで制御されるURLは基本的にブロック対象です。robots.txtでワイルドカードを使い、Disallow: /*?sort=* のように指定することで、効率的にブロックできます。
Google Search Consoleのパラメータ設定と併用 robots.txtでブロックするだけでなく、Google Search Consoleの「URLパラメータ」設定も活用しましょう。パラメータの役割をGoogleに伝えることで、より適切なクロール制御が可能になります。
ページネーション(ページ送り)の正しい扱い方
商品一覧ページのページネーション(2ページ目、3ページ目…)も、ECサイト特有の悩みです。全てのページをクロールさせると負荷がかかりますが、完全にブロックすると深い階層の商品が発見されにくくなります。
基本方針:ページネーションはクロールを許可 結論として、ページネーションのURLは基本的にクロールを許可することを推奨します。ただし、rel=”next”とrel=”prev”の適切な設置や、全商品ページへの内部リンクを充実させることで、クローラーの効率を高めることができます。
異常に深いページはブロックも検討 例えば100ページ目以降など、実質的にユーザーがアクセスしないページは、robots.txtでブロックするか、noindexタグで制御することも一つの手です。ただし、この判断はアクセス解析データをもとに慎重に行ってください。
プラットフォーム別robots.txt設定例とテンプレート
Shopifyでのrobots.txt設定方法
Shopifyは、デフォルトで自動生成されるrobots.txtファイルを持っています。管理画面から直接編集することはできませんが、robots.txt.liquidテンプレートを編集することでカスタマイズが可能です。
Shopifyのデフォルトrobots.txt確認方法 まず、あなたのストアURL/robots.txtにアクセスして、現在の設定を確認しましょう。Shopifyは自動的に以下のようなディレクトリをブロックしています。
User-agent: *
Disallow: /admin
Disallow: /cart
Disallow: /orders
Disallow: /checkouts/
Disallow: /checkout
カスタマイズが必要なケース 検索機能やフィルタのパラメータを追加でブロックしたい場合、robots.txt.liquidファイルを編集します。Shopifyテーマエディタから「テーマファイルを編集」→「テンプレート」→「robots.txt.liquid」を選択してください。
Shopify用推奨テンプレート
User-agent: *
Disallow: /admin
Disallow: /cart
Disallow: /orders
Disallow: /checkouts/
Disallow: /checkout
Disallow: /account
Disallow: /search
Disallow: /*?sort_by=*
Disallow: /*?filter.*
Sitemap: https://yourstore.com/sitemap.xml
WooCommerce(WordPress)でのrobots.txt設定方法
WooCommerceはWordPressベースのECプラットフォームです。WordPressは仮想robots.txtを自動生成しますが、カスタマイズするには物理ファイルをアップロードするか、プラグインを使用します。
デフォルト設定の確認 あなたのサイトURL/robots.txtにアクセスして、現在の設定を確認してください。WordPressのデフォルトでは、以下のようなシンプルな設定になっています。
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
物理ファイルでのカスタマイズ方法 FTPクライアント(FileZillaなど)を使って、サイトのルートディレクトリ(public_htmlやwww)にrobots.txtファイルをアップロードします。物理ファイルが存在する場合、WordPressの仮想robots.txtよりも優先されます。
WooCommerce用推奨テンプレート
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /cart/
Disallow: /checkout/
Disallow: /my-account/
Disallow: /*add-to-cart=*
Disallow: /shop/?*
Disallow: /*?orderby=*
Sitemap: https://yoursite.com/sitemap_index.xml
EC-CUBEでのrobots.txt設定方法
EC-CUBEは日本国内で広く使われているオープンソースのECプラットフォームです。robots.txtファイルは手動で作成し、サーバーにアップロードする必要があります。
ファイルの配置場所 EC-CUBEのインストールディレクトリのルート(index.phpと同じ階層)にrobots.txtファイルを配置します。通常は、public_html や html などのディレクトリ直下になります。
EC-CUBE用推奨テンプレート
User-agent: *
Disallow: /admin/
Disallow: /cart/
Disallow: /shopping/
Disallow: /mypage/
Disallow: /products/list.php?*
Disallow: /*mode=*
Disallow: /*orderby=*
Sitemap: https://yoursite.com/sitemap.xml
EC-CUBE特有の注意点 EC-CUBEはバージョンによってURL構造が異なります。EC-CUBE 4系では、商品一覧のパラメータが /products/list?category_id=* のような形式になるため、実際のURL構造を確認してからrobots.txtを設定してください。
BASE・カラーミーショップなどASPカート
BASE、カラーミーショップ、MakeshopなどのASP型ECカートサービスでは、robots.txtを直接編集できない場合がほとんどです。これらのプラットフォームは、運営会社側でデフォルトのrobots.txtを設定しています。
BASEの場合 BASEは運営側でrobots.txtを管理しており、ユーザー側での編集はできません。ただし、個別商品やページに対してnoindexタグを設定することは可能です。
カラーミーショップの場合 カラーミーショップの一部プランでは、管理画面から限定的なrobots.txt編集が可能です。「集客」→「SEO設定」から、基本的なブロック設定ができる場合があります。
ASPカートでの代替策 robots.txtの編集が制限されている場合、以下の代替策を検討してください。
- 重要でないページに対してnoindexメタタグを設定
- canonical URLを適切に設定して重複を回避
- Google Search Consoleのパラメータ設定を活用
- サイトマップに重要なページのみを含める
robots.txt設定後の確認・検証方法
Google Search Consoleでのテスト手順
robots.txtを設定・更新したら、必ずGoogle Search Consoleで正しく機能しているかテストしてください。誤った設定は、サイト全体の検索順位に影響する可能性があるため、慎重な確認が必要です。
robots.txtテスターの使い方(旧版) 以前はGoogle Search Consoleに「robots.txtテスター」というツールがありましたが、新しいSearch Consoleでは削除されました。ただし、旧版Search Consoleでは一部まだアクセス可能です。
テスターでは、特定のURLが robots.txt によってブロックされているかどうかをシミュレーションできます。重要な商品ページやカテゴリページのURLを入力し、「ブロックされました」と表示されないことを確認してください。
URL検査ツールでの確認 新しいSearch Consoleでは、「URL検査」ツールを使って個別URLのクロール状況を確認できます。検証したいURLを入力し、「robots.txtによりブロックされました」というメッセージが出ないことを確認してください。
クロールエラーとインデックス状況の確認
robots.txt設定後は、定期的にSearch Consoleの「カバレッジ」レポートを確認しましょう。ここでは、サイト内のページがどのような状態にあるかを把握できます。
確認すべき主な項目
- 「robots.txtによりブロックされました」:意図的にブロックしたページ以外がここに表示されていないか確認
- 「クロール済み – インデックス未登録」:重要なページがここに分類されている場合、品質やクロールバジェットの問題がある可能性
- 「検出 – インデックス未登録」:発見されているが優先度が低いと判断されたページ
想定外のブロックを発見した場合 もし重要なページが「robots.txtによりブロックされました」に分類されていたら、すぐにrobots.txtの記述を見直してください。特に、ワイルドカード(*)の使い方が広範囲すぎる場合に、このようなミスが起こりやすくなります。
外部ツールでの構文チェック方法
robots.txtの構文が正しいかチェックするために、外部ツールを活用することも有効です。
推奨ツール
- robots.txt Checker by Small SEO Tools:URLを入力するだけでrobots.txtの構文エラーをチェック
- Ryte robots.txt Validator:詳細な構文チェックと改善提案を提供
- Merkle’s robots.txt Checker:特定のUser-agentに対するブロック状況をシミュレーション
これらのツールは、記述ミスや意図しないブロックを事前に発見するのに役立ちます。特に、大規模なECサイトでrobots.txtを大幅に変更する際は、本番反映前に必ずチェックしてください。
よくある設定ミスと対処法
重要な商品ページを誤ってブロックしてしまった
これは最も深刻な失敗例です。Disallow: /products/ のように、商品ディレクトリ全体を誤ってブロックしてしまうケースがあります。この場合、全ての商品ページがGoogleにクロールされなくなり、検索結果から消えてしまう可能性があります。
対処法 すぐにrobots.txtから誤った記述を削除してください。修正後、Google Search Consoleから主要な商品ページのURL検査を実施し、「インデックス登録をリクエスト」をクリックしてクロールを促しましょう。
通常、Googleは数日〜2週間程度で再クロールし、インデックスが復活します。ただし、完全に元の順位に戻るまでには、さらに時間がかかる場合があります。
予防策 robots.txtを変更する前に、必ずバックアップを取っておきましょう。また、変更後は必ずSearch Consoleでテストし、主要なURLがブロックされていないことを確認してから本番反映してください。
CSS/JavaScriptをブロックしてレンダリングに影響
ECサイトでは、商品画像のスライダーやカート機能など、JavaScriptに依存する機能が多く存在します。これらのリソースファイルをrobots.txtでブロックすると、Googleがページを正しくレンダリングできず、モバイルフレンドリー判定などに悪影響を与える可能性があります。
よくある誤った記述
Disallow: /js/
Disallow: /css/
Disallow: /images/
Googleは2014年以降、JavaScriptとCSSのブロックを推奨していません。これらをブロックすると、ページがどのように表示されるかをGoogleが理解できなくなります。
正しい対処法 基本的に、CSS・JavaScript・画像ファイルはクロールを許可してください。もし特定のファイルだけブロックしたい場合は、個別にファイル名を指定し、ディレクトリ全体をブロックしないようにしましょう。
noindexとの混同によるインデックス問題
「検索結果に出したくないページ」に対して、robots.txtのDisallowとnoindexタグの両方を設定してしまうミスです。実は、この組み合わせは逆効果になります。
なぜ逆効果なのか Googleのクローラーがページにアクセスできない(robots.txtでDisallow)場合、ページ内のnoindexタグも読み込めません。結果として、すでにインデックスされているページは、いつまでたっても検索結果から削除されないのです。
正しい削除手順
- まずrobots.txtのDisallow設定を削除し、クロールを許可
- ページにnoindexメタタグを設置
- Googleが再クロールし、noindexを認識するのを待つ(数日〜数週間)
- インデックスから削除されたことを確認
- 必要に応じて、再度robots.txtでクロールをブロック
パラメータ指定の誤りで広範囲ブロック
ワイルドカード(*)を使ったパラメータ制御は便利ですが、記述を誤ると予想外に広範囲のURLをブロックしてしまう危険があります。
誤った記述例
Disallow: /*?*
この記述は、「?」を含む全てのURLをブロックします。ECサイトでは、商品ページに?color=redのようなパラメータが付く場合があり、これらも全てブロックされてしまいます。
正しい記述例 ブロックしたいパラメータを具体的に指定しましょう。
Disallow: /*?sort=*
Disallow: /*?orderby=*
Disallow: /*?filter=*
robots.txtと併用すべきSEO施策
XMLサイトマップの最適化
robots.txtでクロールを制御したら、次はXMLサイトマップでGoogleに「クロールしてほしいページ」を明示的に伝えましょう。両者は車の両輪のような関係です。
サイトマップに含めるべきページ
- 全ての商品詳細ページ
- カテゴリページ・ブランドページ
- 特集・キャンペーンページ
- ブログ記事(コンテンツマーケティングを実施している場合)
サイトマップに含めるべきでないページ
- カート・チェックアウトページ
- マイアカウント・ログインページ
- 検索結果ページ
- robots.txtでブロックしているページ
robots.txtの最後にSitemap: https://yoursite.com/sitemap.xmlを記述することで、クローラーに効率的にサイトマップを案内できます。
canonicalタグで重複コンテンツを整理
ECサイトでは、同じ商品が複数のカテゴリに属したり、色違いで別URLになったりと、重複コンテンツが発生しやすい構造です。canonicalタグを使って、「この商品の正規URLはこれです」と明示しましょう。
canonicalタグの設置例 例えば、黒いスニーカーが /products/sneaker-black/ と /category/shoes/sneaker-black/ の両方でアクセスできる場合、商品ページの<head>内に以下を記述します。
<link rel="canonical" href="https://yoursite.com/products/sneaker-black/" />
これにより、Googleは正規URLのみを評価対象とし、重複による評価分散を防げます。
meta robotsタグとの使い分け
robots.txtとnoindexタグ(meta robotsタグ)は、それぞれ異なる役割を持っています。両者を適切に使い分けることが重要です。
使い分けの基本原則
| 目的 | 使用するツール | 理由 |
|---|---|---|
| クロール自体を拒否したい | robots.txt | サーバー負荷軽減、クロールバジェット節約 |
| 検索結果に出したくない | noindexタグ | インデックス削除の確実性 |
| 既にインデックスされたページを削除 | noindexタグ | クローラーがnoindexを読める状態に保つ必要がある |
併用する場合の注意点 基本的に、robots.txtとnoindexは併用しないでください。どうしても両方使いたい場合は、まずnoindexでインデックスを削除してから、robots.txtでクロールをブロックする順序を守りましょう。
クロールバジェット最適化の総合戦略
robots.txt単体ではなく、総合的なクロールバジェット最適化戦略を立てることが、大規模ECサイトのSEO成功の鍵です。
最適化施策のチェックリスト
- robots.txtで不要なURLへのクロールをブロック
- XMLサイトマップに重要ページのみを含める
- canonicalタグで重複コンテンツを整理
- 404エラーページやリダイレクトチェーンを削減
- ページの読み込み速度を改善(Core Web Vitals最適化)
- 内部リンク構造を最適化し、重要ページへのリンクを増やす
これらの施策を組み合わせることで、Googleのクローラーは効率的にサイトを巡回し、重要なページを優先的に評価できるようになります。
トラブルシューティング:設定後の問題対処
設定したのにクロールされてしまう場合
robots.txtに正しくDisallowを記述したにもかかわらず、該当ページがクロールされてしまうケースがあります。いくつかの原因が考えられます。
原因①:クローラーがrobots.txtを無視している 残念ながら、全てのクローラーがrobots.txtのルールを守るわけではありません。GooglebotやBingbotなど主要な検索エンジンは遵守しますが、悪質なボットやスクレイピングツールは無視することがあります。
対処法として、サーバー側でIPアドレスベースのアクセス制限(.htaccessやWAF設定)を検討してください。
原因②:記述の構文エラー robots.txtの記述にミスがあると、意図した通りにブロックされません。特に多いのが、以下のようなミスです。
- スペースやタブの入れ方が不適切
- ファイル名の大文字小文字の間違い(
Robots.txtではなくrobots.txt) - 文字コードがUTF-8でない
原因③:キャッシュの問題 Googleはrobots.txtファイルを一定期間キャッシュします。変更してもすぐには反映されず、最大24時間程度かかることがあります。急いで反映させたい場合は、Search Consoleから「robots.txtの再読み込み」をリクエストしましょう。
重要ページがインデックスされない場合
robots.txtの設定は正しいのに、商品ページやカテゴリページがなかなかインデックスされない場合の対処法です。
原因①:クロールバジェット不足 サイト全体のページ数が多すぎると、重要なページまでクローラーが到達しない可能性があります。robots.txtでさらに不要なページをブロックし、XMLサイトマップに重要ページのみを含めることで改善できます。
原因②:内部リンク構造の問題 トップページから3クリック以上離れたページは、クローラーが発見しにくくなります。重要な商品ページへは、トップページやカテゴリページから直接リンクを張りましょう。
原因③:ページ品質の問題 内容が薄いページや、他ページと重複が多いページは、Googleが意図的にインデックスしない場合があります。商品説明文を充実させ、オリジナルコンテンツを増やすことが重要です。
Search Consoleでエラーが出る場合
Google Search Consoleでrobots.txt関連のエラーが表示される場合の対処法です。
「robots.txtが取得できません」エラー このエラーは、Googleがrobots.txtファイルにアクセスできない状態を示しています。
- ファイルが正しい場所(ドメインルート)に設置されているか確認
- サーバーがダウンしていないか確認
- .htaccessでrobots.txtへのアクセスをブロックしていないか確認
「robots.txtの構文エラー」 記述にミスがある場合に表示されます。Search Consoleの指摘箇所を確認し、以下をチェックしてください。
- User-agent、Disallow、Allowのスペルミスがないか
- 各ディレクティブの後ろにコロン(:)があるか
- ファイルがUTF-8で保存されているか
ECサイト規模別の推奨設定テンプレート
小規模ECサイト(商品数〜500点)向けテンプレート
商品数が少ない小規模ECサイトでは、シンプルな設定で十分です。過度にブロックすると、逆にクロール機会を逃す可能性があるため、最小限の設定に留めましょう。
User-agent: *
# 管理・会員機能のブロック
Disallow: /admin/
Disallow: /cart/
Disallow: /checkout/
Disallow: /my-account/
Disallow: /login/
# サイト内検索結果のブロック
Disallow: /search
Disallow: /*?s=*
# カート追加アクションのブロック
Disallow: /*add-to-cart=*
Sitemap: https://yoursite.com/sitemap.xml
小規模サイトの設定ポイント
- フィルタやソート機能が少ないため、パラメータ制御は最小限でOK
- 全商品ページを確実にクロールしてもらうことを優先
- XMLサイトマップに全商品を含める
中規模ECサイト(商品数500〜5,000点)向けテンプレート
商品数が増えてくると、フィルタ機能や検索機能による動的URLが増加します。クロールバジェットを意識した設定が必要になります。
User-agent: *
# 管理・会員機能のブロック
Disallow: /admin/
Disallow: /cart/
Disallow: /checkout/
Disallow: /my-account/
Disallow: /login/
Disallow: /password-reset/
# サイト内検索・フィルタのブロック
Disallow: /search
Disallow: /*?s=*
Disallow: /*?search=*
Disallow: /*?q=*
# ソート・フィルタパラメータのブロック
Disallow: /*?sort=*
Disallow: /*?order=*
Disallow: /*?orderby=*
Disallow: /*?filter=*
# ページネーションの過度なブロックは避ける
# (基本的にページネーションは許可)
# カート関連アクションのブロック
Disallow: /*add-to-cart=*
Disallow: /*remove_item=*
Sitemap: https://yoursite.com/sitemap.xml
中規模サイトの設定ポイント
- フィルタ・ソート機能のパラメータを具体的に指定
- ページネーションは基本許可し、canonical設定で対応
- 重要カテゴリページへの内部リンクを強化
大規模ECサイト(商品数5,000点以上)向けテンプレート
大規模サイトでは、クロールバジェットの最適化が死活問題になります。徹底的な不要URLブロックと、サイトマップの分割管理が必要です。
User-agent: *
# 管理・会員・システムページのブロック
Disallow: /admin/
Disallow: /cart/
Disallow: /checkout/
Disallow: /my-account/
Disallow: /login/
Disallow: /password-reset/
Disallow: /wishlist/
Disallow: /compare/
# サイト内検索の完全ブロック
Disallow: /search
Disallow: /results
Disallow: /*?s=*
Disallow: /*?search=*
Disallow: /*?q=*
Disallow: /*?query=*
# フィルタ・ソート・パラメータの徹底ブロック
Disallow: /*?sort=*
Disallow: /*?order=*
Disallow: /*?orderby=*
Disallow: /*?filter=*
Disallow: /*?price=*
Disallow: /*?color=*
Disallow: /*?size=*
Disallow: /*?brand=*
# セッションIDや追跡パラメータのブロック
Disallow: /*?sid=*
Disallow: /*?session=*
Disallow: /*?ref=*
Disallow: /*?utm_*
# 印刷用ページなどのブロック
Disallow: /*/print/
Disallow: /*.pdf$
# カート関連アクション
Disallow: /*add-to-cart=*
Disallow: /*remove_item=*
Disallow: /*update_cart=*
Sitemap: https://yoursite.com/sitemap_index.xml
大規模サイトの設定ポイント
- サイトマップを商品カテゴリ別に分割(sitemap_products.xml, sitemap_categories.xmlなど)
- Google Search Consoleで定期的にクロールバジェット状況を監視
- 優先度の低い古い商品はnoindexタグで制御
- CDNのURLやAMP版URLも適切に管理
まとめ:ECサイトrobots.txt設定のチェックリスト
ECサイトのrobots.txt設定は、SEOとサイト運営の両面で重要な役割を果たします。この記事で解説した内容をもとに、以下のチェックリストを確認してください。
設定前の確認事項
- [ ] 現在のrobots.txtを確認した(
ドメイン/robots.txtにアクセス) - [ ] 使用しているECプラットフォームのデフォルト設定を理解した
- [ ] サイトのURL構造(商品ページ、カテゴリページ、パラメータなど)を把握した
基本設定
- [ ] 商品ページ・カテゴリページのクロールを許可している
- [ ] カート・チェックアウトページをブロックしている
- [ ] マイアカウント・ログインページをブロックしている
- [ ] サイト内検索結果ページをブロックしている
- [ ] CSS・JavaScript・画像ファイルのクロールを許可している
パラメータ制御
- [ ] ソート機能のパラメータをブロックしている
- [ ] フィルタ機能のパラメータをブロックしている
- [ ] 不要な追跡パラメータをブロックしている
サイトマップ設定
- [ ] XMLサイトマップのURLを記述している
- [ ] サイトマップに重要ページのみを含めている
- [ ] サイトマップをGoogle Search Consoleに登録している
設定後の確認
- [ ] Google Search ConsoleのURL検査で主要ページがブロックされていないことを確認した
- [ ] robots.txtテスター(または外部ツール)で構文エラーがないことを確認した
- [ ] 実際にブラウザで
/robots.txtにアクセスして内容を確認した - [ ] 1週間後、1ヶ月後にSearch Consoleでクロール状況を確認する予定を立てた
定期メンテナンス
- [ ] 3ヶ月ごとにクロール状況を確認する
- [ ] 新機能追加時にrobots.txtを見直す
- [ ] サイトリニューアル時は必ず再設定する
ECサイトのrobots.txtは「最低限ブロック+サイトマップ案内」を基本に、サイトの成長に合わせて段階的に最適化していくことをおすすめします。設定後は必ず検証を行い、商品ページが正しくクロールされていることを確認してください。
正しいrobots.txt設定で、あなたのECサイトの検索順位向上と売上アップを実現しましょう。
よくある質問(FAQ)
Q1. robots.txtで完全にページへのアクセスをブロックできますか?
A. いいえ、robots.txtは「行儀の良いクローラーへのお願い」であり、完全なアクセス制限ではありません。Googlebot や Bingbot などの主要な検索エンジンのクローラーはこのルールを守りますが、悪意のあるボットや一般ユーザーは robots.txt の設定に関係なくアクセスできます。
会員限定ページや管理画面など、本当にアクセスを制限したいページには、Basic認証やログイン機能などのサーバー側の認証機能を使用してください。robots.txtはあくまでSEO対策とクロール制御のためのツールです。
Q2. robots.txtの設定はどのくらいの頻度で見直すべきですか?
A. 基本的には3〜6ヶ月に一度の見直しをおすすめします。ただし、以下のようなタイミングでは必ず確認してください。
- 新しい機能(フィルタ、検索など)を追加したとき
- サイトリニューアルやURL構造の変更を行ったとき
- 商品数が大幅に増加したとき(1,000点→5,000点など)
- Search Consoleでクロールエラーが急増したとき
- 検索順位が大幅に下落したとき
また、Google Search Consoleの「カバレッジ」レポートで「robots.txtによりブロックされました」の項目を月1回チェックし、意図しないブロックが発生していないか確認することを推奨します。
Q3. 既存のECサイトでrobots.txtを変更する際の注意点は?
A. 既存サイトでrobots.txtを変更する際は、特に慎重な対応が必要です。以下の手順で進めてください。
- 現在の設定をバックアップ:変更前の robots.txt をテキストファイルとして保存
- 影響範囲を事前確認:変更によってブロックされるページ数をSearch Consoleで推定
- 段階的に変更:いきなり大幅な変更をせず、まず一部だけ変更してテスト
- 変更後1週間は毎日監視:Search Consoleでクロール状況、インデックス数、検索順位を確認
- 問題があればすぐに戻す:異常が検出されたら、バックアップから即座に復元
特に注意すべきは、誤って重要ページをブロックしてしまうケースです。大規模な変更前には、必ずステージング環境でテストすることをおすすめします。
Q4. robots.txtとnoindexはどう使い分けますか?
A. robots.txtとnoindexは目的が異なります。以下のように使い分けてください。
robots.txt (Disallow)を使うケース
- クローラーの訪問自体を拒否したい(サーバー負荷軽減)
- まだインデックスされていないページをクロール対象から除外したい
- クロールバジェットを節約したい
noindexタグを使うケース
- すでにインデックスされているページを検索結果から削除したい
- クロールは許可するが、検索結果には表示させたくない
- 低品質ページや重複コンテンツを検索エンジンから隠したい
絶対にやってはいけない組み合わせ
- すでにインデックスされたページに対して、robots.txtでブロック+noindexタグを設置 → クローラーがnoindexタグを読めないため、いつまでも検索結果に残ってしまいます
正しい手順は、「まずnoindexでインデックス削除」→「削除確認後、必要に応じてrobots.txtでクロールブロック」です。
Q5. robots.txt設定変更後、効果が出るまでの期間は?
A. robots.txtの変更は即座には反映されず、効果が実感できるまでには通常1週間〜1ヶ月程度かかります。
タイムラインの目安
- 0〜24時間:Googleがrobots.txtの変更を認識(キャッシュ更新)
- 1週間〜2週間:変更されたルールに従った再クロールが開始
- 2週間〜1ヶ月:インデックス状況が変化し始める
- 1ヶ月〜3ヶ月:検索順位への影響が顕在化
急いで反映させたい場合は、Google Search Consoleから「robots.txtの再読み込み」をリクエストし、主要ページに対して「インデックス登録をリクエスト」を実行してください。ただし、これでも完全な即時反映は保証されません。
大規模なECサイトほど、全体の再クロールには時間がかかります。焦らず、Search Consoleのデータを週次で確認しながら経過を観察しましょう。
参考資料・引用元
- Google検索セントラル「robots.txtファイルを作成する」:https://developers.google.com/search/docs/crawling-indexing/robots/create-robots-txt
- SEOBot.ai「WordPress robots.txt Best Practices」:https://seobotai.com/blog/wordpress-robots-txt/
- Remarkable Marketing「Ideal Ecommerce Robots File」:https://remarkable.net/blog/ideal-ecommerce-robots-file/
- Tillison Consulting「Robots.txt for Ecommerce」:https://tillison.co.uk/blog/robots-txt-for-ecommerce/
関連記事
