簡単な答え: Search Consoleでのsitemap_collections_1.xmlの「Couldn't fetch」やHTTPエラーは通常一時的なものです。これは、Shopifyが自動生成する子サイトマップをGoogleが再試行している状態です。URLがブラウザで読み込めること、親のsitemap.xmlを提出したこと(子ファイルを直接ではなく)、Googleをブロックするパスワードページやリダイレクトがないことを確認してください。問題なく読み込める場合は、親サイトマップを再提出して待ちましょう。通常、次のクロールでエラーは解消されます。
Shopifyのsitemap_collections_1.xmlに関するエラーは、Google Search Consoleで「Couldn't fetch」や「HTTPエラー」、「Sitemap could not be read」として報告されることが多く、見た目には心配ですが、ほとんどの場合、数分で修正可能です。このガイドでは、ファイルの内容、エラーが発生する理由、そしてそれを解決するための具体的なチェック手順を、最も一般的な原因から順に説明します。
sitemap_collections_1.xmlの実際の内容
Shopifyのsitemap.xmlは自動生成されます。編集はできず、それが設計上の仕様です。your-store.com/sitemap.xmlのルートファイルはサイトマップのインデックスであり、ページを直接リストするのではなく、Shopifyがリソースタイプごとに作成する子サイトマップ(sitemap_products_1.xml、sitemap_collections_1.xml、sitemap_pages_1.xml、sitemap_blogs_1.xml)を指します。大規模なカタログは、各ファイルがいっぱいになると番号付きの続き(_2, _3)が作成されます。コレクションの子サイトマップは、公開されたすべてのコレクションURLとその最終更新日をリストします。
子サイトマップはライブカタログから生成されるため、リソースを追加、削除、非表示にすると自動的に更新されます。このエラーの裏にある良いニュースは、ファイル自体が壊れることはほとんどないということです。Shopifyが構築するためです。エラーはほとんどの場合、アクセスに関するもので、Googleがファイルを取得できなかったか、古いレポートに関するものです。Shopifyサイトマップガイドはシステム全体をカバーしていますが、この記事はエラー自体のトラブルシューティングパスです。
ステップ1: ファイルを自分で開く
何かを変更する前に、your-store.com/sitemap_collections_1.xml(およびルートのsitemap.xml)をブラウザで開いてください。3つの結果が3つの異なる意味を示します。
| ブラウザの結果 | 意味 | 対応 |
|---|---|---|
| コレクションURLのリストを含むXMLが表示される | ファイルは正常; 問題はアクセスまたは報告 | ステップ2–5(ドメインチェック、保留中のクロール、ファイアウォール、空のファイル)に進む |
| パスワードページにリダイレクトされる | パスワード保護されたストアがGooglebotをブロック | オンラインストア → 設定でストアフロントのパスワードを削除 |
| 404エラーが表示される | 間違ったドメインをテストした; サイトマップはプライマリドメインでのみ提供される | 設定 → ドメインでプライマリドメインを確認し、そのURLをテスト |
コレクションURLのリストを含むXMLが表示される場合、ファイルは正常です。問題はアクセスまたは報告にあるため、ステップ2–5に進んでください。パスワードページにリダイレクトされる場合、それが答えです。パスワード保護されたストアがGooglebotからすべてのURLをブロックしており、サイトマップも含まれます。修正方法は、オンラインストア → 設定でストアフロントのパスワードを削除することです。404エラーが表示される場合、テストしたドメインを確認してください。サイトマップはプライマリドメインでのみ提供されるため、.myshopify.comのバリアントやリダイレクトされていないエイリアスは404を返すことがありますが、実際のファイルは正常です。
ステップ2: 提出したドメインを確認する
Search Consoleでは、サイトマップURLはプロパティの正確なドメインと一致します。よくある間違いは、プライマリドメインがベアである(またはその逆)場合にwwwプロパティの下でサイトマップを提出することや、.myshopify.comアドレスの下で提出することです。Shopify管理画面の設定 → ドメインでプライマリドメインを確認し、他のすべてのバリアントがそれに301リダイレクトされることを確認し、https://your-primary-domain/sitemap.xmlを対応するGSCプロパティにのみ提出してください。最近プライマリドメインを変更した場合、古いサイトマップの提出を削除し、新しいプロパティで再提出してください。
ステップ3: 「Couldn't fetch」の保留状態を理解する
これが多くの商人の時間を浪費する原因です: 「Couldn't fetch」はしばしばエラーではありません。 サイトマップを初めて提出すると、Search Consoleは「Couldn't fetch」をステータスとして表示します。これは、Googleがファイルを初めて正常にクロールするまでの状態で、新しいプロパティでは数時間から数週間かかることがあります。ファイルがブラウザで正常に開く(ステップ1をクリア)し、最近提出した場合、正しい対応は数日待ってから実際の失敗として扱うことです。再提出を繰り返してもこれを早めることはできません。
信頼できる判断基準はURLインスペクションツールです: サイトマップの子URLを直接検査してください。ライブテストでGoogleが取得できることが示されれば、レポート行は古くなっており、自動的にクリアされます。
ステップ4: ファイアウォールとボット保護のブロックを除外する
ファイルがあなたには読み込めるが、Googleが数日間本当に取得できない場合、GoogleとShopifyの間で何かがリクエストを拒否しています。通常の疑わしいのは、カスタムドメインの前にあるCDNやセキュリティレイヤーです。CloudflareのBot Fight Modeや同様の機能は、Googlebotやサイトマップフェッチャーを含む正当なクローラーをチャレンジまたはブロックすることが知られています。DNSやプロキシがCloudflareや他のCDNにある場合、Googlebotのリクエストがブロックされたファイアウォールイベントを確認し、検証済みの検索クローラーに対するボットチャレンジルールを無効にしてください。同じレイヤーはAIクローラーもブロックすることが多く、これによりサイトマップエラーの上にアンサーエンジンの可視性が静かに失われます。
また、robots.txtがまだサイトマップを参照しており、それを禁止するルールが追加されていないことを確認してください。Shopifyのデフォルトは正しいですが、カスタマイズされたrobots.txt.liquidテンプレートはそれを壊すことがあります。
ステップ5: 空または本当に壊れた子を確認する
まれに、子自体が問題です。公開されたコレクションがゼロのストアは、いくつかのバリデーターがフラグを立てる空のコレクションサイトマップを生成します。オンラインストア以外の販売チャネルにのみ公開されたコレクションは存在せず、キャッシュされた後に非表示にされたコレクションは一時的に残ることがあります。これらの状態はShopifyがファイルを再生成する際に解決されます。あなたのレバーは、インデックスされたいリソースがオンラインストアチャネルに公開され、表示されていることを確認することです。
このエラーが影響することとしないこと
修正中に視野を保ちましょう: サイトマップの取得エラーはサイトを非インデックス化しません。Googleはリンクを通じてURLを発見します。サイトマップは発見を加速し、ページレポートにフィードします。アクセスの問題を修正し、ルートのsitemap.xmlを一度再提出し、次のクロールサイクルで通常は成功に変わります。その後もコレクションがインデックスされない場合、原因は他にあります: 薄いコレクションページ、canonicalの問題、または内部リンクです。これらはShopifyコレクションSEOとGoogle Search Console for Shopifyガイドでカバーされています。
無料のストア監査は、サイトマップ、ロボットルール、インデックス状態を一度にチェックします — 各サイトマップの子が200を返すかどうか、リストされたページが実際にインデックス可能かどうかを含めて — 1つのファイルではなく全体のチェーンを確認できます。