Magento/Adobe Commerceでは、最初にpublic storefrontをどのレイヤーが配信しているか確認します。
Content → Design → Configurationを確認します
対象store viewでSearch Engine Robotsを確認し、実ドメインの/robots.txtと比較します。
Default Robotsは別の設定です
Default Robotsはページのindexing directiveで、robots.txtのcrawl ruleそのものではありません。
ecommerce URLを実際にテストします
search、cart、account、facetはstoreごとに異なります。generic blocklistを貼らず、parameter URLはパラメータガイドで判断します。
Cloudでは環境差を確認します
Adobe Commerce Cloudではstaging、本番、sitemap、indexing policyの違いを確認します。
PWA/headlessでownerが変わる場合があります
PWA/headless frontendやCDNがpublic hostを配信するなら、その層が/robots.txtを所有する可能性があります。checkerでlive responseを確認します。
Adobe Commerce Cloudでは所有レイヤーを先に特定します
Cloudではrobots.txtが設定からオンデマンド生成され、repositoryの物理ファイルが使われない構成があります。sitemapやfilesystemにも固有制約があるため、live responseが違う場合はCommerce、Fastly/CDN、PWA、headless frontendのどれが公開hostを所有するかを先に確認します。
Production、staging、integrationでindex policyを無条件に共有しません。環境ごとにrobots.txt、sitemap、hostname、indexing stateを検証します。
Headless・multi-storeはhost単位で監査します
Adobeの新しいbest practicesはnative storefrontと他のstorefront solutionを区別しています。PWAではcart、account、search、filter pathがMagento標準と違う場合があります。実際のfrontend URLを基準に設定し、複数website/store viewがある場合はhostnameごとにownershipとpolicyを確認します。
Storefrontの所有レイヤーを最初に特定します
Adobe CommerceではAdminの設定だけを見て終了しません。native storefront、Cloud、Fastly/CDN、PWA、headless frontendのどの層がpublic hostnameの /robots.txt を実際に返すかを確認します。backendで設定を変更しても、frontend/CDNが別fileを配信していればcrawlerには届きません。複数websiteやstore viewがある場合は、hostnameごとにownerとsitemapを記録します。
production、staging、integrationで同じindex policyを共有しないことも重要です。productionは検索向けにopenでも、lower environmentは認証や別のindex controlが必要です。deploy前後でrobots.txt、sitemap、canonical host、主要pageのindexing directiveを環境別に確認します。
Ecommerce特有のURLをテストします
商品、カテゴリ、内部検索、facet/filter、cart、account、parameter付きURLを代表ケースとして用意します。単にrobots syntaxがvalidかではなく、商用価値のあるURLがcrawl可能か、低価値な組み合わせが無限に生成されていないか、canonical/noindexとcrawl ruleが整合しているかを見ます。headless PWAではMagento標準pathをそのままcopyせず、実際のfrontend routeを基準にpolicyを設計します。
変更理由をstore単位で記録します
複数storeを持つ構成では、どのhostnameで何をblockしたのかを変更履歴に残します。後から別storeへ同じruleを展開するときも、URL構造が本当に同じかを再確認します。
