ecbeing 検索・AI検索に出ないとき見る6つ

ecbeingのような大規模パッケージで構築したサイトが検索やAI検索に出ないとき、原因はコンテンツよりも構築時に決まった設計にあることが多くあります。URL設計、レンダリング方式、メタデータの管理方法は、あとから変えるとサイト移転と同じ規模の作業になります。基幹連携ごとリニューアルして数万のURLが一度に変わる案件では、リダイレクトの設計が索引と流入を左右します。

この記事は、ecbeingについて書いた2本の記事から、担当者が最初に確認する6つの項目を抜き出したものです。各項目の詳細は、末尾の記事に譲ります。

1. URLがパス形式で、商品IDがカテゴリ変更で変わらないか

RFPに書かなければ、URLはパッケージの標準に従います。パラメータ形式やIDのみのURLになっている場合があります。構築後にURL設計を変えるのは極めて困難で、サイト移転相当の作業です。まず、商品・カテゴリ・パラメータ付きURLをブラウザで開き、形式とcanonicalを確認します。

2. JavaScriptを無効にしても商品情報がHTMLに含まれるか

AIクローラーの多くは、JavaScriptを実行しません。クライアントサイド描画のサイトは、AIからは中身のないページに見えます。レンダリング方式は構築後に最も変えにくい項目で、変更にはフロントの再構築が伴います。確認は難しくありません。JavaScriptを無効にして商品ページを表示し、商品名・価格・構造化データがHTMLに含まれているかを見ます。

• 商品名、価格、在庫、商品説明、パンくず、構造化データが、JavaScriptを実行せずにHTMLレスポンスに含まれている(サーバーサイドレンダリングまたは静的生成)

• クライアントサイド描画を採用している場合、検索エンジンとAIクローラー向けにサーバーサイドで同等のHTMLを返す仕組みがある

• 構築前なら、提案書にJavaScriptを無効にした状態の商品ページのHTMLサンプルを添付してもらう

データポイント: 年商400億ウォン(約40億円)規模の韓国ECブランドでは、原本のコードを変えずに別レンダリング層で基盤を整え、3か月でOrganic購入売上を約9,206万ウォンから約1.66億ウォン(+80%)に伸ばしました。

3. title・canonical・構造化データを管理画面から変えられるか

管理画面から設定できないと、メタデータの変更は都度開発依頼になります。構築後に管理画面を改修するのは困難です。管理画面で設定を変更し、ページに反映されることを確認します。構造化データは、リッチリザルトテストで型と値を見ます。

4. WAFとrobots.txtがクローラーを止めていないか

WAFの標準設定でクローラーがブロックされることがあります。ステージングで設定した noindex や Disallow: / が本番に残ってしまう事故は、大規模リニューアルで最も多い失敗の1つです。robots.txtの内容と、サーバーログでGooglebot・AIクローラーの応答コードが200であることを確認します。

• WAF・ボット対策・レート制限の許可リストに、検索エンジンおよびAIクローラーの正規のIPが含まれている。許可リストの更新手順が運用手順書にある

• robots.txtを管理画面またはデプロイなしで編集できる

• AIクローラー(GPTBot、ClaudeBot、PerplexityBot等)の許可・拒否を、robots.txtでクローラーごとに設定できる

• 切り替え直後に、ステージングのnoindexとDisallowが本番に残っていない

5. リニューアルのリダイレクトが1回の301で新URLに届くか

商品3万点、カテゴリ2千、コンテンツ5千といった規模のリニューアルでは、URLが全部変わります。全部を手で設定するのは無理なので、規則で9割、対応表で1割という設計にします。多段のリダイレクト(旧 → 中間 → 新)は、評価の減衰とクロールの無駄につながります。切り替え前に、ステージングで全URLを機械的に検証します。

検証では、旧URLの一覧をステージングの新サイトに対してリクエストし、301以外(404、多段の301、302、200)を抽出して修正します。「全URLが1回の301で200のページに到達する」まで繰り返します。切り替え当日は、検索流入・被リンク上位50件を手動で開き、Search Consoleにサイトマップを再登録し、主力ページの索引登録をリクエストします。リダイレクトは切り替え当日で終わらず、最低1年、被リンクが残っている限りは恒久的に残します。

6. サイトマップとアクセスログを発注者が扱えるか

ボットが実際に何を取得しているかは、ログでしか分かりません。運用契約によっては、ログはベンダー側にあり、発注者が直接取得できないことがあります。ログが提供されないと、AI検索への対応状況を確かめる手段がなくなります。サイトマップはSearch Consoleに登録し、検出URL数が公開ページ数と近いことを確認します。

Search OSは構築後の状態を見続ける層です

Search OSは、ecbeingなど大規模パッケージで構築されたサイトを対象に、上の6項目にあたる状態を継続的に検証します。404・リダイレクトチェーン・canonical・索引数の変化と、ボットが取得している旧URLと新URLの対応を見ます。構築時から崩れた項目や、リニューアルで失われたページは、修正対象として整理します。構築やリニューアルの作業を置き換えるものではありません。構築後に要件を見続ける役割は、契約の段階で決めておきます。

担当者が先に見る質問

• 商品URLはパス形式で、カテゴリを変えても変わらない設計になっているか

• JavaScriptを無効にした状態で、商品名・価格・構造化データがHTMLに含まれているか

• title、canonical、noindex、構造化データを、開発依頼なしに管理画面から変えられるか

• サーバーログで、Googlebot・AIクローラーの応答コードが200になっているか

• ステージングのnoindexや Disallow: / が本番に残っていないか

• リニューアル後の旧URLは、1回の301で新URLの200ページに届いているか

• WebサーバーまたはCDNのアクセスログを、発注者が自分で取得できる契約になっているか

結論

ecbeingのサイトが検索・AI検索に出ないとき、先に見るのはコンテンツではなく、構築時に決まった設計です。URL設計、レンダリング方式、メタデータの管理は構築前にしか決められません。ボットのアクセス制御、リダイレクト、サイトマップとログは、構築後も機能追加やWAFの設定変更で崩れ続けます。RFPで担保できるのは構築時の状態までなので、保守契約に「要件の維持」と「変更時の確認」が入っているかを確認し、崩れを見つける担当をあらかじめ決めておきます。

あわせて読みたい

• ecbeingのRFPにSEO・AI検索の要件をどう書くか: 構築後に変えられない項目

• ecbeingの大規模リニューアルでURLとリダイレクトをどう設計するか: 数万URLの移転

参考資料

• Google Search Central: JavaScript SEO basics

• Google Search Central: URL structure best practices

• Google Search Central: Verifying Googlebot and other Google crawlers

• Google Search Central: Site moves with URL changes

• Google Search Central: Redirects and Google Search

• Google Search Central: Large site owner's guide to managing your crawl budget