エンタープライズEcommerce SEO

要点 — エンタープライズecommerce SEOは、数万から数百万もの商品ページを持つ巨大なオンラインストアのSEOです。順位付けの規則は他のサイトと同じですが、規模が小さな問題を巨大化させます。小規模店で数百個の余分なURLを生む絞り込み機能が、エンタープライズストアでは数百万個を生み、修正には一人の午後ではなくチーム全体が必要です。

「エンタープライズecommerce」の本当の意味

大規模小売業者専用のGoogleアルゴリズムがあるわけではありません。Googlebotは一人で運営するShopify店と同じ方法で巨大ストアをクロールし、インデックスし、順位付けします。違うのはSEOを取り巻く次の条件です。

• カタログ規模 — 数万から数百万の商品があります。
• 至る所にあるフィルター — 色、サイズ、ブランド、価格、評価の各組み合わせが固有URLになり、急速に増えます。
• 多数のチーム — merchandising、engineering、法務、地域責任者がそれぞれ優先事項を持ち、誰も「SEO」の直属ではありません。
• 大規模で怖い移行 — 数年ごとのreplatformで、誤ったredirect map 1つが長年の順位を失わせます。

覚えておくべき一つの考え方

規模は問題を乗算します。 小規模ストアならフィルターの誤りで数千個の不要URLができても、厄介なだけで大きな害はないかもしれません。エンタープライズでは同じ誤りが数百万個の不要URLを生み、Googleの時間、つまり「crawl budget」を浪費して、本来の商品ページへ到達しにくくします。計算は苛烈です。各5選択肢のフィルターが10個あるカテゴリーは、1カテゴリーだけで二百万を超えるURL組み合わせを生成し得ます。

最も重要なこと

• フィルターに無限のページを作らせない。 最大の問題です。主にbotの進入禁止領域を示すrobots.txtで制御します。
• Amazonを真似しない。 Amazonが2億7 500万ページで順位を得られる一因はAmazonだからです。小規模ブランドなら致命傷になることも吸収できます。構造は参考にしても、近道は真似しないでください。
• メーカーの商品説明はそのままでもよい。 数百万件をすべて書き直す必要はありません。重要な商品へレビュー、写真、動画、独自情報を追加します。
• 最も難しいのは通常、技術ではなく人です。 修正方法を知ることより、engineering、法務、5人のstakeholderを通して実装するほうが難題です。

crawl budgetの計算、structured data、移行、組織playbookまで必要なら、Advancedタブへ切り替えてください。

要点 — エンタープライズecommerce SEOは、すでに複雑な2分野が交わり、複雑さが加算ではなく乗算される領域です。技術的な柱では、faceted navigationがGoogleのクロール問題の約50%を占めるため（Illyes）、crawl budget制御（robots.txt > canonical > noindex）を最優先します。canonicalizationの判断は数百万URLへ波及し、ProductGroup／hasVariantのstructured dataとMerchant Center feedがvariantと商品発見を支えます。在庫切れはページ単位でなく規則で処理し、移行は最大のリスクイベントです。しかし実際のbottleneckは組織にあります。知識不足ではなく連携不足によって、14-hopのredirect chainや同一ページの24種類のURLが出荷されるのを見てきました。

この領域が独立した専門分野である理由

enterprise SEO と、より広い ecommerce SEO については別に書いており、このページは意図的にその焼き直しにしていません。エンタープライズecommerce SEOは、両者を重ねて複雑さを乗算したものです。

enterprise SEOは規模、technical debt、組織政治のため難しく、ecommerce SEOはfaceted navigation、variant、duplicate content、platform制約のため難しくなります。組み合わせると、小規模ストアで5万個の重複URLを生む誤りが、エンタープライズ規模では5 000万URLのcrawl trapになります。修正は10分のrobots.txt編集ではなく、engineering sprint、法務レビュー、経営承認です。これが乗算効果であり、以下のすべてを見る視点です。

エンタープライズの聴衆に必ず伝える注意点は、巨大サイトを真似しないことです。Amazonは約2億7 500万ページで月間organic visit約6億8 600万、Microsoftは約5億1 600万を得ています。技術的な誤りがあってもauthorityが損害を吸収するため順位を得ています。優れたinformation architectureは参考にしても、近道は決して真似しないでください。

Faceted navigation：ウェブ最大のクロール問題

エンタープライズecommerceで一つ直すなら、これです。Gary Illyesによると、faceted navigationとaction parameterはGoogleがウェブ全体で対処するクロール問題の約**75%**を占め、**faceted navigationだけで約50%**です。フィルターが組み合わせ爆発を起こすエンタープライズecommerceが主な発生源です。各5値のフィルター10個で1カテゴリー当たり二百万URL超、20カテゴリーなら最適化前に数億のクロール可能な組み合わせを作ります。

破壊的になる理由は構造にあります。Illyesは、URL空間を発見したGoogleは*“cannot make a decision about whether that URL space is good or not unless it crawled a large chunk of that URL space.”* (翻訳) 「そのURL空間の大部分をクロールしない限り、良い空間かどうか判断できない」と述べています。そのためGoogleは不要だと学ぶためだけにcrawl budgetを消費します。

Googleの制御手段（効果が高い順）：

1. robots.txt disallow — そもそもクロールを防ぎます。facet pageをインデックスする必要がない場合の最も強力な手段です（例：Disallow: /*?*color=）。
2. フィルター用URL fragment（#） — Googleは通常fragment URLをクロールしないため、#による絞り込みはcrawl costを生みません。
3. rel="canonical" — “may, over time, decrease the crawl volume of non-canonical versions.” (翻訳) 「時間とともにnon-canonical版のクロール量を減らす場合がある」ものの、遅く信頼性も低く、Googleが上書きする場合があります。
4. rel="nofollow" — 対象URLへ向かうすべてのlinkへ適用した場合に限り機能します。

最も頻繁に否定する誤解もこれです。インデックスしたくないfacetの既定策に noindex は適しません。 Google自身が*“block unimportant pages using robots.txt instead of noindex”* (翻訳) 「重要でないページはnoindexではなくrobots.txtで遮断する」と案内しています。noindexでもクロールは行われ、守りたい資源を消費するためです。

実際の検索需要がありfacet pageをインデックスする必要がある場合は、標準の&をparameter separatorに使い、parameter orderを一貫させて重複を避け、結果がない組み合わせには一般的なerror pageへのredirectではなくHTTP 404を返します。

Crawl budgetを決めるのはサイト規模ではなくURL品質

よくある最大の認識違いは「エンタープライズだからcrawl crisisだ」というものです。必ずしもそうではありません。John Muellerの説明は覚える価値があります。“crawling is independent of website size. Some sites have a gazillion (useless) URLs and luckily we don’t crawl much from them,” (翻訳) 「クロールはサイト規模と無関係で、膨大な（役に立たない）URLを持つサイトは幸いあまりクロールされない」、また*“for most normal websites, crawl budget is not something you need to focus on at all.”* (翻訳) 「大半の通常サイトではcrawl budgetを重視する必要はまったくない」と述べています。

実務上の意味は、clean URLを持つ1 000万ページのストアは問題がない一方、10万ページから1 000万のfacet組み合わせを生成するストアは本物のcrawl crisisに陥るということです。引き金は規模ではなく、URL品質と重複です。

Googleによると、週単位で変わる100万以上のunique page、毎日更新される1万以上のpage、またはGSCで*“Discovered – currently not indexed”* (翻訳) 「検出 - インデックス未登録」が大量にある場合、積極的なcrawl budget管理が重要になります。主な手段は、“Consolidate duplicate content to focus on unique pages rather than unique URLs,” (翻訳) 「固有URLではなく固有ページに集中するため重複コンテンツを統合する」、“Block unimportant pages using robots.txt instead of noindex,” (翻訳) 「重要でないページはnoindexでなくrobots.txtで遮断する」、恒久削除には404／410を返す、正確なlastmodでsitemapを最新に保つことです。空のcategory pageや廃止商品群のsoft 404はクロールされ続けて*“waste your budget.”* (翻訳) 「予算を浪費する」ため特に監視します。

大規模なduplicate content（存在しないpenalty）

duplicate contentそのものへのpenaltyはありません。MicrosoftのFabrice CanelとKrishna Madhavanは実害を、“doesn’t trigger search penalties on its own, but it does reduce visibility by diluting authority, confusing intent, and slowing how updates reach both search engines and AI-powered discovery systems.” (翻訳) 「それ自体は検索penaltyを引き起こさないが、authorityを希薄化し、意図を曖昧にし、検索エンジンとAIによる発見システムへ更新が届くのを遅らせるため、visibilityを下げる」と説明しています。

エンタープライズecommerceの重複源は予測できます。ウェブ全体へ配布されるメーカー説明、URL variantを作るfaceted navigation、複数カテゴリーに属する同一商品です。variantにはcanonical tag、統合には恒久redirect、localizationにはhreflang、そして厳格なURL hygieneで直します。canonical判断は数百万ページへ波及します。GoogleはURL structure、internal link、sitemap、Merchant Center dataなど約40のcanonicalization signalを使うため、rel=canonicalは強いhintであってcommandではありません。

Variant、商品data、structured data

variantの扱いを変えた点は2つあります。第一に、Googleは2024年2月からProductGroupとhasVariant、variesBy、productGroupIDをサポートし、多数のvariantを持つ衣料、家電、家具に適したpatternになりました。第二に、エンタープライズで十分活用されていないMerchant Center feedは発見漏れへの保険です。Googleは*“web crawling is not guaranteed to find all products on your site,”* (翻訳) 「ウェブクロールでサイト上の全商品が見つかる保証はない」と明記し、“for larger sites or sites with frequently changing content,” (翻訳) 「大規模サイトや頻繁に内容が変わるサイト」には定期的なfeed uploadを推奨しています。feedならContent APIで1時間単位まで更新時刻を制御し、ページにない店舗別在庫も共有し、クロールだけではできない発見を保証できます。feedとon-page structured dataは二者択一でなく補完関係です。

Product／ProductGroup以外で大規模運用に役立つschema typeは、BreadcrumbList（階層）、Organization（brand trustと返品方針）、Review、LocalBusiness（omnichannel）、VideoObjectです。rel="next"／rel="prev"のpagination tagはdeprecatedで機能しません。各pagination pageに固有URLとself-referencing canonicalが必要で、page 1へ向けてはいけません。

PDPとPLP：実際に労力を投じる場所

商品詳細ページでは、メーカー説明を大規模にそのまま使っても問題ありません。数百万件の一括書き換えはROIがほぼゼロです。私は*“add product reviews, video content, comparisons, or unique attributes rather than rewrites,”* (翻訳) 「書き換える代わりに商品レビュー、動画、比較、独自属性を追加する」ことを選び、head termの機会がある高売上PDPへ集中します。user-generated reviewはチームが執筆せずに大規模展開できる最良のunique-content手段です。

商品一覧／category pageでは、掲載商品の選定が想像以上に重要です。網羅的な一覧より、さまざまなfacetに重要商品を表示し、有用なpage contentは隠さず、役立つ位置（page上部や短いsnippet）へ置きます。brand positioningによる順位上限も直視してください。すべてのcategory pageがmarketplaceを上回れるわけではありません。

在庫切れ商品の規則は次の通りです。恒久廃止なら類似商品へ301（homepageはsoft 404扱いの恐れがあるため不可）するか、internal link削除後に404／410で削除します。一時的で再入荷するならrestock date、waitlist、通知付きで維持し、不確実なら優先度を下げて維持します。数千SKUが出入りするエンタープライズではページごとに判断できません。私が述べたように、“Set some rules that you’re comfortable with and just go with them… there’s no perfect solution.” (翻訳) 「納得できる規則を決めて運用すればよい。完璧な解決策はない」のです。大規模では規則を自動化します。

Internal linkingはPageRankの配管

Googleの資料は明快です。“The more links a page has to it within a site, the higher the relative importance,” (翻訳) 「サイト内でページへ向かうlinkが多いほど相対的重要度が高い」、また*“if category pages don’t include direct links to all products in a category, Googlebot might not find all of your products.”* (翻訳) 「category pageがカテゴリー内の全商品へ直接linkしなければ、Googlebotは全商品を見つけられない場合がある」としています。エンタープライズでは、まず数百の宛先へlinkするmega-menuが低価値ページへequityを薄めるため、簡素化して重要箇所へ集中させます。次にnavigationはJavaScript click handlerでなく実際の<a href> linkを使います。Googleは*“doesn’t submit searches into site search boxes during crawling,”* (翻訳) 「クロール中にサイト内検索boxへqueryを送信しない」ため、検索やJS eventだけで到達するページは発見されない場合があります。

移行：最大のリスクイベント

replatformには中規模で約5万 USD、エンタープライズで50万 USD超、期間は4–8+か月かかり、長年のorganic equityが失われやすい場面です。Googleは段階移行を勧め、“You can choose to move larger sites one section at a time. This can make it easier to monitor, detect, and fix problems faster.” (翻訳) 「大規模サイトは1sectionずつ移動でき、そのほうが監視、検出、迅速な修正を行いやすい」と説明しています。必須事項は、sitemap、log、analyticsからimage、video、CSS、JSを含む全旧URLを記録すること、server-side 301／308を使いchainを3-hop未満にすること、全新URLのself-referencing canonical、internal linkの即時更新、GSCのChange of Address（HTTP→HTTPSを除く）、そして忘れられがちな launch前にstagingの noindex とrobots.txt blockを削除すること です。これは保証ではありません。checklistは既知で制御可能なリスクを減らしますが、移行中の順位、traffic、revenue維持を約束しません。Googleの移行資料も移行後の変動を想定内としており、追うべき失敗signalとはしていません。

International、JavaScript、monitoring

international展開では関係が急増し、5万商品×15か国なら一貫して保つhreflang関係は75万件になり、machine-translated thin contentも実際のリスクです。JavaScriptについてMartin Splittは、renderingがserver-rendered HTMLより*“a few hours to even weeks”* (翻訳) 「数時間から数週間」の遅延を加える場合があると述べています。そのためnavigationや商品一覧をclient-side renderingの背後に隠すReact／Vue／Angular storefrontは、クロール効率が下がります。monitoringでは1 000万ページの全量月次crawlは遅く高価です。重要なpage templateを毎日見るcrawl samplingと、botが実際に到達した先を示すlog file analysisを推奨します。Splittの*“concerns more the contents side than the technical infrastructure aspect”* (翻訳) 「technical infrastructureよりcontent面に関係する」という説明の通り、crawl-budget最適化はGoogleへ追加クロールを頼むのでなく、低価値URLを減らして行います。

本当のbottleneckは組織層

多くのguideが省き、programを実際に止める部分です。IBM在籍時、私はEnterprise SEO Chaos — 37万8 000人超が170か国超で働く企業内部の機能不全を扱う発表 — を行いました。代表例は14-hopのredirect chain、同一ページの24種類のURL、約束した35件中14件しか実装されなかったredirect、全domainから単一ページへのredirect、クロールを阻むJS menu、同じkeywordを社内部門同士で争う状況です。どの場合もSEO知識はありましたが、実行連携が失敗しました。中心的な教訓「すべてを連動させる」は、collaboration（siloを壊す）とeducation（すべてのstakeholderにSEOの基本を理解してもらう）の2点に集約されます。

だからこそenterprise auditは小さく保ちます。deliverableは300-slideのreportではなく、business impactを金額で示した優先課題5～10件です。まずstakeholderに話を聞いてpain pointを見つけ、section、language、region、technical frameworkでサイトを分割して扱いやすくし、“focus on a few key issues and not a massive report of everything.” (翻訳) 「すべてを並べた巨大reportでなく、少数の重要課題へ集中する」のです。変更はA/B testとして提示し、impact/effort matrixで承認を得ます。地味な構造作業について私が述べた通り、“It’s hard to do that at scale, but boring projects = $$$ when it comes to enterprise SEO.” (翻訳) 「大規模に行うのは難しいが、enterprise SEOでは地味なprojectほど$$$になります。」

AI検索がshopping surfaceを変えている

エンタープライズ小売が注視すべき変化は2つです。AI Overviewsはshopping queryの約14%に表示され、2025年後半の2,1%から約5,6倍になりました。2026年1月発表のGoogle Universal Commerce Protocolにより、AI agentは買い物客がサイトを訪れなくてもAI Mode／Gemini内で商品を発見し、cartを作り、取引できます。一方Googleは戦術について、“structured data isn’t required for generative AI search, and there’s no special schema.org markup you need to add,” (翻訳) 「generative AI検索にstructured dataは必須でなく、追加すべき特別なschema.org markupもない」と説明しています。Merchant Centerと高品質な商品contentがAI visibilityの最も強い手段である点も変わりません。土台は同じで、surfaceが移っています。

AI要約

Advanced版の要点を簡潔にまとめます。

• 定義： エンタープライズecommerce SEOはenterprise SEO × ecommerce SEOで、2つの複雑さが乗算されます。小規模店の5万重複URLが5 000万URLのcrawl trapとなり、修正にはengineering、法務、経営承認が必要です。
• 巨大サイトを真似しない。 Amazon（約2億7 500万ページ）はauthorityが隠す誤りにもかかわらず順位を得ます。構造は参考にしても近道は真似しません。
• Faceted navigationが最大のクロール問題（IllyesによるとGoogleの問題の約50%）。robots.txt > URL fragment > canonical > nofollowで制御し、クロールを許すnoindexを既定にしません。
• Crawl budgetはサイト規模でなくURL品質です（Mueller）。cleanな1 000万ページは問題がなくても、10万ページから1 000万facetを作るサイトは危機です。
• duplicate-content penaltyはありません。 重複はauthorityを薄め、意図を混乱させます。canonical、恒久redirect、hreflang、URL hygiene（約40のcanonicalization signal）で直します。
• Variantと発見： 2024年2月対応のProductGroup／hasVariantとMerchant Center feedを使います。クロールで*“is not guaranteed to find all products.”* (翻訳) 「全商品が見つかる保証はありません。」
• PDP／PLPへの投資： メーカー説明は大規模にはそのままでよく、高売上ページへreview、video、比較を追加します。在庫切れは規則で自動処理します。
• 移行は最大のリスクイベント： 段階化し、全URLをmapし、3-hop未満の恒久redirect、self-canonical、staging blockのlaunch前削除を徹底します。
• 本当のbottleneckは組織： IBMでは14-hop chain、同一ページ24 URL、35件中14件しか実装されないredirectがありました。collaborationとeducationが解決します。
• AI検索： shopping queryの約14%にAI Overviewsが表示され、Universal Commerce Protocol（2026年1月）は訪問なしの購入を可能にします。土台は同じでsurfaceが変化しています。

公式ドキュメント

エンタープライズecommerce SEOを規定する一次資料です。

Google

• Ecommerce SEO概要 — Google検索向けecommerceの8テーマをまとめたhubです。
• Faceted navigation URLのクロール管理 — 制御階層（robots.txt > fragment > canonical > nofollow）とindexable facetの規則です。
• Crawling December：Faceted navigation（2024年12月） — 上記資料を補うblogです。
• Crawl budgetの最適化 — 規模の目安と統合指針です。
• EcommerceのURL structure設計 — path／queryによるvariantと3つのURL設計trapです。
• Googleにecommerce site structureを理解させる — internal linkingと<a href> navigationです。
• 商品dataをGoogleと共有する — structured dataとMerchant Center feedです。
• Ecommerce向けstructured data — Product、ProductGroup、BreadcrumbList、Reviewなどです。
• Product variant structured data（2024年2月） — ProductGroup／hasVariant／variesByです。
• Paginationとincremental page loading — rel=next/prevがdeprecatedである理由です。
• URL変更を伴うsite move — 段階的移行playbookです。
• Core Web VitalsとGoogle検索 — LCP <2,5s、INP <200ms、CLS <0,1です。
• AI機能とウェブサイト — AI visibilityに有効なこと／無効なことです。

Bing／Microsoft

• Bing Webmaster Guidelines — crawlability、unique content、structured dataの指針です。
• AI検索でcontentを発見可能に保つsitemap（2025年7月） — enterprise sitemapの上限とlastmod精度です。
• IndexNowによる高速で賢いcontent discovery（2025年5月） — 変化の速いcatalog向けreal-time URL送信です。
• Duplicate contentはSEOとAI検索visibilityを害するか（2025年12月） — 重複の実害に関するCanelとMadhavanの説明です。

情報源からの引用

GoogleとBing担当者の公的発言です。deep linkはsource pageの引用箇所（またはその検索）へ移動します。

Faceted navigationとクロール — Google、Gary Illyes

• “crawlers will typically access a very large number of faceted navigation URLs before the crawlers’ processes determine the URLs are in fact useless.” (翻訳) 「crawlerは通常、無用だと判断するまでに非常に多くのfaceted navigation URLへアクセスします。」 引用箇所へ
• “Once it discovers a set of URLs, it cannot make a decision about whether that URL space is good or not unless it crawled a large chunk of that URL space.” (翻訳) 「一群のURLを発見すると、そのURL空間の大部分をクロールしない限り、良い空間かどうか判断できません。」 — Google、Gary Illyes。記事を読む
• “Sometimes you might create these new fake URLs accidentally, exploding your URL space from a balmy 1000 URLs to a scorching 1 million, exciting crawlers that in turn hammer your servers unexpectedly…” (翻訳) 「新しい偽URLを誤って作り、URL空間を穏やかな千から灼熱の百万へ爆発させ、crawlerを刺激してserverへ予期せぬ負荷をかける場合があります。」 — LinkedInでのGary Illyes。記事を読む

Crawl budget — Google、John Mueller (二次資料からのparaphrase)

• Muellerは繰り返し、クロールはサイト規模から独立し、ほとんどが無用なURLならGoogleはわずかしかクロールしないこと、大半の通常サイトではcrawl budgetに注力する価値がないことを説明しています。一次資料で確認するまではparaphraseとして扱ってください。

JavaScriptとcrawl budget — Google、Martin Splitt (二次資料からのparaphrase)

• Splittは、JS renderingがHTMLより遅延を加えること、crawl-budget最適化はinfrastructureよりcontent品質の問題であることを説明し、“you can tell us not to index or not to scan contents that is of low quality.” (翻訳) 「低品質なcontentをindex／scanしないよう伝えられる」と述べています。一次資料で確認するまではparaphraseとして扱います。

Crawl budget資料 — Google Search Central

• “Consolidate duplicate content to focus on unique pages rather than unique URLs.” (翻訳) 「固有URLではなく固有ページへ集中するためduplicate contentを統合してください。」 引用箇所へ
• “Block unimportant pages using robots.txt instead of noindex.” (翻訳) 「重要でないページはnoindexでなくrobots.txtで遮断してください。」 引用箇所へ

Site structureと商品data — Google Search Central

• “The more links a page has to it within a site, the higher the relative importance.” (翻訳) 「サイト内でページへ向かうlinkが多いほど、相対的重要度が高くなります。」 引用箇所へ
• “If category pages don’t include direct links to all products in a category, Googlebot might not find all of your products.” (翻訳) 「category pageがカテゴリー内の全商品へ直接linkしなければ、Googlebotは全商品を見つけられない場合があります。」 引用箇所へ
• “Web crawling is not guaranteed to find all products on your site.” (翻訳) 「ウェブクロールでサイト上の全商品が見つかる保証はありません。」 引用箇所へ

移行 — Google Search Central

• “You can choose to move larger sites one section at a time. This can make it easier to monitor, detect, and fix problems faster.” (翻訳) 「大規模サイトは1sectionずつ移動できます。そのほうが監視、検出、迅速な修正を行いやすくなります。」 引用箇所へ

AI検索 — Google Search Central

• “Structured data isn’t required for generative AI search, and there’s no special schema.org markup you need to add.” (翻訳) 「generative AI検索にstructured dataは必須ではなく、追加すべき特別なschema.org markupもありません。」 引用箇所へ

Duplicate content — Microsoft Bing、Fabrice CanelとKrishna Madhavan

• “Duplicate content doesn’t trigger search penalties on its own, but it does reduce visibility by diluting authority, confusing intent, and slowing how updates reach both search engines and AI-powered discovery systems.” (翻訳) 「Duplicate contentはそれ自体で検索penaltyを引き起こしませんが、authorityを薄め、意図を混乱させ、検索エンジンとAIによる発見システムへ更新が届くのを遅らせるため、visibilityを低下させます。」 引用箇所へ

エンタープライズecommerce SEO checklist

ページ単位でなくtemplate単位で実行します。この規模では1つのtemplate修正が数十万URLへ反映されます。

クロールとfaceted navigation

• クロール可能なURLを作るすべてのparameter（色、サイズ、sort、page、session）を特定する。
• 規則を書く前にfacetごとにindexable／non-indexableを決める。
• non-indexableなfacet空間はrobots.txtで遮断し、noindexを使わない。
• indexable facetでは& separatorと一貫したparameter orderを使い、空の結果には404を返す。
• 無限空間（calendar、relative-link爆発、session ID）がない。

重複とcanonicalization

• variantをrel=canonicalまたはProductGroup／hasVariantで解決する。
• 複数カテゴリーに属する商品はcanonical URLを1つにする。
• すべてのlocale pairでhreflang関係が一貫している。
• soft 404（空カテゴリー、廃止商品群）は実際の404／410を返す。

商品dataとstructured data

• 確実な商品発見のためMerchant Center feedを稼働させる。
• Product／ProductGroup、BreadcrumbList、Review、Organization markupをvalidateする。
• deprecatedのrel=next／rel=prevを使わず、pagination pageはself-canonicalにする。

Contentの優先度

• 高売上PDPを一括書き換えでなくreview、video、比較で強化する。
• 大規模にunique contentを増やせるUGC／reviewを有効化する。
• 在庫切れを手動でなく規則（301／維持／404）により自動処理する。

Architectureとinternal link

• NavigationにはJS click handlerでなく実際の<a href>を使う。
• Mega-menuのlink数によるequity希薄化を確認する。
• Category pageから商品へ直接linkする。

移行とmonitoring

• 移行前にimage／video／CSS／JSを含む全旧URLを記録する。
• 301／308、3-hop未満のchain、新URLのself-canonicalを確認する。
• launch前にstagingのnoindex／robots blockを削除し、Change of Addressを送信する。
• 重要templateを毎日crawl samplingし、log fileで浪費を確認する。

Mental model

1. 乗算効果。 「enterpriseの問題＋ecommerceの問題」でなく、enterprise × ecommerceと考えます。すべてのecommerce課題（facet、variant、重複、在庫切れ）は規模で増幅し、すべての修正は組織摩擦で増幅します。作業範囲を決める前に両軸を見積もります。

2. Crawl control hierarchy（効果が高い順）。 robots.txt disallow → URL fragment（#）→ rel=canonical → rel=nofollowです。状況が許す最も強い手段を選び、インデックスしたくないfacetへcrawl budgetを消費するnoindexを既定にしません。

3. Crawl budget = サイト規模ではなくURL品質。 Googleに追加クロールを頼むのでなく、facet、重複、soft 404という浪費を除いて実効予算を増やします。規模だけが引き金になることはなく、重複が問題です。

4. 在庫切れdecision tree（その後自動化）。 恒久廃止なら類似商品へ301するか、internal linkを外した後に404／410で削除します。一時的で再入荷するならrestock／waitlist付きで維持し、不確実なら優先度を下げて維持します。納得できる規則を選んでcode化します。大規模ではページごとに判断できません。

5. 移行リスクmodel。 sectionごとの段階化 → 全旧URLのmap → 3-hop未満の301 → 全新URLのself-canonical → internal link更新 → staging block削除 → Change of Address送信 → template単位の監視、の順です。一つの漏れが長年のequityを消し得ます。

6. 組織成熟度ladder。 ad-hoc → centralization → SOP → proactive trainingとbuy-inです。エンタープライズprogramの多くは知識ではなく連携で止まり、このladderを上ることが本当の仕事です。audit deliverableはimpact/effort matrix上でA/B testとして示す、金額換算した5～10課題です。300-slide reportではありません。

エンタープライズecommerce SEO — cheat sheet

Faceted-nav control — 各手段の役割

Crawl-budgetの目安（Googleの概算）

• 週単位で変わる百万以上のunique page → 管理する。
• 毎日変わる1万以上のpage → 管理する。
• GSCで*“Discovered – currently not indexed”* (翻訳) 「検出 - インデックス未登録」が多い → 管理する。

在庫切れの規則

• 恒久廃止 → 類似商品へ301（homepage／categoryは不可）、または404／410。
• 一時的で再入荷 → restock date／waitlist／通知付きで維持。
• 不確実 → 優先度を下げて維持。

移行時の必須事項

• 301／308、chain <3-hop、self-canonical、internal link更新、staging block削除、Change of Address送信（HTTP→HTTPSを除く）。

Core Web Vitalsのthreshold

• LCP <2,5s · INP <200ms · CLS <0,1。順位のtiebreakerですが実際のconversion leverでもあります（Vodafone：LCPを31%改善 → 売上8%増）。

Variant structured data

• ProductGroup + hasVariant + variesBy + productGroupID（2024年2月対応）。

なくすべき誤解

• duplicate-content penalty（存在しない）· facetへのnoindex（robots.txtを使う）· メーカー説明をすべて書き直す（不要）· rel=next/prev（deprecated）· 「sitemapを送ればGoogleがすべて見つける」（保証されない）。

エンタープライズecommerce SEOのtool

• Google Search Console — Page Indexing report（pipelineからpageが脱落する箇所）とCrawl Stats（response code、average response time、file type別）。crawl wasteを最初に調べる場所です。
• Google Merchant Center — feedによる商品発見と価格／在庫更新（Content APIなら1時間単位）。クロール発見漏れへの保険です。
• Bing Webmaster Tools + IndexNow — 変化の速いcatalog（新商品、価格変更、promotion）のreal-time URL送信。変更からindexまでの遅れを減らします。
• Server log file analysis — botが実際にクロールした先を示すground truthです。Screaming Frog Log File Analyserを使うか、logをBigQuery／log platformへ送ります。
• Site crawler／audit — Ahrefs Site AuditとScreaming Frog SEO Spiderでdepth、redirect chain、blocked URL、trap状のfacet patternを調べます。エンタープライズ規模では月次全量crawlより重要templateの日次sampleを優先します。
• Ahrefs Webmaster Tools — 所有確認したサイト向けの無料crawl＋auditです。
• Rich Results Test／Schema validator — 数百万ページへ展開する前にProduct／ProductGroup、BreadcrumbList、Review markupを確認します。

在庫切れ商品URLをどう扱うべきか

Playbook：replatform後にorganic visibilityが低下した場合

1. Templateとsectionで影響範囲を確認する。 旧／新URL set、Google Search Consoleのpage／index data、crawl結果を比較します。低下が一部だけなら影響のないsectionの作業を止め、壊れたtemplateを診断します。sitewideならlaunch controlとredirectを最初に疑います。
2. productionがまだ遮断されていないか確認する。 robots.txt、page-level robots directive、response headerにstaging規則がないか調べます。blockがあればlaunch rollback processで削除し、他を変える前に再testします。
3. 旧URLのredirectを追跡する。 sitemap、log、analytics、image、assetから高価値URLをsampleします。旧URLが意図した宛先へserver-side 301／308で到達しなければmapを修正し、chainが計画上限を超えるなら可能な限り1-hopへ短縮します。
4. 宛先signalの一致を確認する。 各新URLは意図したstatusを返し、self-canonicalとなり、更新済みinternal linkを受ける必要があります。canonicalやlinkが別へ向くならURLごとでなく共通templateを直します。
5. Discovery inputを比較する。 XML sitemap、Merchant Center feed、navigationを確認します。旧URLやblocked URLを出しているなら個別exportを掃除せず、その生成元を更新します。
6. 続行、段階化、rollbackを選ぶ。 対象sectionがlaunch checkを通過しvisibilityが安定した場合だけ続行します。未移行sectionは保留し、重要templateのblockやredirect coverageを安全に回復できなければ文書化済みrollback pathを使います。
7. Cohort単位で監視する。 クロール、indexation、organic performanceが落ち着くまで旧／新URL pairとtemplate groupを追跡します。失敗checkを記録して次段階のpreflight gateにします。

Faceted navigation規則を分類する

Review this faceted-navigation inventory and propose a crawl/indexation disposition
for each parameter or combination: indexable landing page, blocked crawl space,
canonicalized duplicate, or needs manual review.

For every recommendation, cite the supplied evidence: search demand, product count,
internal links, current canonical, robots rule, response code, and URL examples.
Flag empty combinations that should return 404. Use a consistent parameter-order
policy. Do not assume noindex saves crawl budget, and do not invent demand data.

Inventory:
[PASTE CSV]

Variant用ProductGroup markupを確認する

Compare this product-variant JSON-LD with the visible product data. Check the use of
ProductGroup, hasVariant, variesBy, productGroupID, URLs, offers, prices, availability,
and identifiers. Return:
1. Field-level mismatches
2. Required source data that is missing
3. A corrected JSON-LD draft using only values present in my input
4. A validation checklist

Do not fabricate prices, availability, reviews, identifiers, URLs, or variants.

Visible product data and current JSON-LD:
[PASTE BOTH]

Redirect mapのspot check

実行するtest： header-following HTTP clientまたはcrawlerで、旧product、category、image、asset URLを層化sampleします。期待結果： 各旧URLが意図したserver-side 301／308を返し、不要なchainなしでmap済み新URLへ到達します。失敗の意味： 規則漏れ、広すぎるfallback redirect、または連鎖したlegacy mappingが残っています。監視期間： deployment直後、および各migration sectionのlaunchごとに再実行します。rollback条件： 重要URL cohortがmap先へ到達しない、または一般ページへ解決され始めた場合です。

新templateのcanonical check

実行するtest： 代表的な新PDP、PLP、pagination、variant URLをcrawlし、各canonicalと最終取得URLを比較します。期待結果： indexableにする全pageがsuccessを返してself-referencing canonicalを持ち、duplicate variantは承認済み統合規則に従います。失敗の意味： 共通templateまたはenvironment valueが旧domain／別templateのcanonicalを出しています。監視期間： release直後とlaunch期間中の日次です。rollback条件： 重要templateが一貫して旧site、別locale、無関係なpageへcanonicalizeする場合です。

Production block削除check

実行するtest： productionのrobots.txtを取得し、rendered pageのrobots directiveと全重要templateのresponse headerを確認します。期待結果： index対象URLにstaging専用disallowやnoindex blockが残っていません。失敗の意味： launch configurationまたはCDN／header規則がstaging controlを保持しています。監視期間： DNS／routing変更前とcutover直後です。rollback条件： production siteが重要section全体のクロールまたはindexを遮断した場合です。

Product variantのvalidation

実行するtest： 代表的なProductGroup pageをGoogleのRich Results Testで検査し、抽出されたvariant dataをvisible pageとMerchant Center feedに照合します。期待結果： markupをparseでき、variant関係が一貫し、price、availability、identifier、URLがvisible dataと一致します。失敗の意味： schema templateまたはcommerce feedが不完全／矛盾した商品dataを出しています。監視期間： rollout前、template出荷直後、重要なfeed変更後です。rollback条件： deploy済みmarkupがtemplate cohort全体でpriceまたはavailabilityを誤表示した場合です。

時間を使う価値のある資料

私の関連記事

• 最大成長のためのEnterprise SEO戦略 — 専用のenterprise ecommerce section（PDP、PLP、規模benchmarks）を含みます。
• Enterprise siteでtechnical SEOが真価を発揮する理由 — 優先順位とcrawl-sampling手法です。
• Enterprise SEOの課題と誤り — buy-in、法務bottleneck、technical debt、地味なprojectが利益を生む理由です。
• Enterprise SEO Audit — 分割、scope設定、優先課題5～10件の出荷方法です。
• 在庫切れ商品をどう扱うべきか？状況による — 大規模に自動化するdecision frameworkです。
• Googleは約40のCanonicalization signalを使用 — 数百万ページへcanonicalをdeployする前の必読資料です。
• Faceted Navigation （Sam Underwood著、私がreview）— 最大のクロール問題を詳しく扱います。

私の講演

• Enterprise SEO Chaos （SMX Advanced 2016、IBM時代）— 14-hopのredirect chainと同一ページ24 URLの実例です。

その他の執筆者

• GoogleのEcommerce SEO資料 — 8テーマの専門hubです。
• Sitebulb — Enterprise ecommerce SEOの5戦略 — JS、mega-menu、facetを詳しく扱います。
• Search Engine Land — Google：クロール問題の75%は2種類のURL誤りから — faceted navigation統計の根拠となるGary Illyesへのinterviewです。
• Search Engine Land — Faceted navigation SEO guide — controlとindexation判断を扱う詳細guideです。
• Search Engine Journal — URL parameter問題に関するGary Illyesの警告 — LinkedInのURL爆発に関する引用元です。
• Search Engine Land — shopping queryの14%にAI Overviews — shopping AI coverage増加のdataです。
• web.dev — Core Web Vitalsのbusiness impact — Vodafone、Nykaa、AliExpressのrevenue case studyです。
• r/TechSEO — 大規模crawl／index debuggingのcommunityです。

引用に使える統計

• 全クロール問題の約50%はfaceted navigationが原因（facet＋action parameterで約75%）— Googleの年末crawl reportについてのGary Illyes発言。出典
• 1カテゴリーから二百万以上のURL — 各5値のフィルター10個が、最適化前のenterprise crawl trapを作る計算です。
• shopping queryの約14%にAI Overviews — 2025年後半の2,1%から約5,6倍。記事
• Enterprise organic規模benchmark — Amazonは約2億7 500万ページで月間organic visit約6億8 600万、Microsoftは約5億1 600万。近道を真似しないでください。出典
• Core Web Vitals → revenue — Vodafone Italy：LCP 31%改善で売上8%増、Nykaa：LCP 40%改善でorganic traffic 28%増、AliExpress：CLS 10倍＋LCP 2倍改善でbounce 15%減。出典
• Bing sitemap規模 — 1file当たり50 000 URL、1index当たり50 000 child sitemap、index file全体で最大2,5兆URL。出典
• Replatform cost／期間 — 中規模で約5万 USD、エンタープライズで50万 USD超、4–8+か月。enterprise retail最大のSEOリスクイベントです。

理解度test：エンタープライズecommerce SEO

crawl control、商品処理、移行に関する5問です。回答を選び、結果を確認してください。

変更履歴