ecbeing RFPに書くSEO・AI検索の要件
ecbeingのような大規模パッケージでECサイトを構築するとき、RFPのSEO要件が「対応すること」の1行で終わっていることがあります。
書くべきは、構築後に変えられない項目です。レンダリングは、ブラウザが画面を組み立てる過程です。大規模パッケージでは、URL設計、レンダリング方式、メタデータの管理方法をあとから変えると、サイト移転と同じ規模の作業になります。一方で、コンテンツや個別のメタタグはあとからでも変えられます。RFPに書かなければ、その項目はパッケージの標準に従います。標準が発注側の要件に合うとは限りません。
この記事では、6領域の要件を、構築後に変えられない順に、RFPにそのまま書ける文でまとめます。
結論: 変えられない順に6領域。上の3つは必ず書く
順位 | 領域 | 構築後の変更 | RFPに書かなかった場合 |
|---|---|---|---|
1 | URL設計 | 極めて困難(サイト移転相当) | パッケージ標準のURL。パラメータ形式やIDのみの場合がある |
2 | レンダリング方式 | 困難(フロント再構築) | クライアントサイド描画の場合、AIクローラーが内容を読めない |
3 | メタデータ・構造化データの管理 | 困難(管理画面の改修) | 管理画面から設定できず、都度開発依頼 |
4 | ボットのアクセス制御 | 中(WAF・robots設定) | WAFの標準設定でクローラーがブロックされる |
5 | サイトマップ・canonical | 中 | 標準の生成ルールが要件に合わない |
6 | ログの提供 | 中(運用契約) | ボットの取得状況を確認できない |
重要な考え方: RFPは「何をしてほしいか」ではなく、「何を変えられなくするか」を決める文書です。構築後に変えられない項目は、構築前にしか決められません。まず、その項目から書き出します。
領域1: URL設計
RFPに書く要件:
商品・カテゴリ・コンテンツのURLは、パラメータではなくパス形式とする
商品URLは商品を一意に識別し、カテゴリの変更で変わらない
カテゴリURLは階層を反映し、階層の変更時にリダイレクトを管理画面から設定できる
URLの末尾スラッシュ、大文字小文字を統一し、非正規形はリダイレクトする
旧サイトからの移行時、旧URLから新URLへの301リダイレクトを、対応表に基づいて一括設定できる
パラメータ付きURL(並び替え、絞り込み、ページ送り)のcanonicalの規則を提案書に明記すること
領域2: レンダリング方式
RFPに書く要件:
データポイント: 年商400億ウォン(約40億円)規模の韓国ECブランドでは、原本のコードを変えずに別レンダリング層で基盤を整え、3か月でOrganic購入売上を約9,206万ウォンから約1.66億ウォン(+80%)に伸ばしました。(事例記事)
商品名、価格、在庫、商品説明、パンくず、構造化データは、JavaScriptを実行せずにHTMLレスポンスに含まれること(サーバーサイドレンダリングまたは静的生成)
クライアントサイド描画を採用する場合、検索エンジンとAIクローラー向けにサーバーサイドで同等のHTMLを返す仕組みを含めること
提案書に、JavaScriptを無効にした状態での商品ページのHTMLサンプルを添付すること
AIクローラーの多くは、JavaScriptを実行しません。クライアントサイド描画のサイトは、AIからは中身のないページに見えます。ここは構築後に最も変えにくい項目なので、レンダリング方式の要件はRFPの段階で入れます。
領域3: メタデータ・構造化データの管理
RFPに書く要件:
title、meta description、canonical、noindex、OGPを、商品・カテゴリ・コンテンツごとに管理画面から設定できること
設定がない場合のテンプレート(自動生成ルール)を、ページ種別ごとに管理画面から変更できること
Product、BreadcrumbList、Organization、Articleの構造化データを、商品データから動的に出力すること。出力する属性を提案書に明記すること
構造化データの出力を、開発を伴わずに管理画面から有効・無効にできること
同一ページに同じ型の構造化データを二重に出力しないこと
領域4: ボットのアクセス制御
RFPに書く要件:
WAF・ボット対策・レート制限は、検索エンジンおよびAIクローラーの正規のIPを許可リストに含めること。許可リストの更新手順を運用手順書に含めること
robots.txtを管理画面またはデプロイなしで編集できること
AIクローラー(GPTBot、ClaudeBot、PerplexityBot等)の許可・拒否を、robots.txtでクローラーごとに設定できること
領域5: サイトマップ・canonical
RFPに書く要件:
XMLサイトマップを自動生成し、商品・カテゴリ・コンテンツを含め、非公開・販売終了を除外すること。lastmodは更新日時を反映すること
5万URL超で分割し、サイトマップインデックスを出力すること
全ページにcanonicalを出力し、パラメータ付きURLは領域1の規則に従うこと
領域6: ログの提供
RFPに書く要件:
WebサーバーまたはCDNのアクセスログを、User-Agent・応答コード・URL・タイムスタンプを含む形式で、発注者が取得できること
ログの保存期間と取得方法を運用手順書に含めること
ボットが実際に何を取得しているかは、ログでしか分かりません。ログが提供されないと、AI検索への対応状況を確かめる手段がなくなります。発注者がログを自分で取得できることを、RFPに書いておきます。
RFPに添える検収条件
各領域について、「納品時に発注者が次の方法で確認する」と書いておきます。検収条件があれば、「対応します」の解釈のずれが減ります。
領域 | 検収方法 |
|---|---|
URL設計 | 商品・カテゴリ・パラメータ付きURLをブラウザで開き、形式とcanonicalを確認 |
レンダリング方式 | JavaScriptを無効にして商品ページを表示し、商品名・価格・構造化データがHTMLに含まれることを確認 |
メタデータ・構造化データ | 管理画面で設定を変更し、ページに反映されることを確認。リッチリザルトテストで型と値を確認 |
ボットのアクセス制御 | robots.txtの内容と、サーバーログでGooglebot・AIクローラーの応答コードが200であることを確認 |
サイトマップ・canonical | サイトマップをSearch Consoleに登録し、検出URL数が公開ページ数と近いことを確認 |
ログの提供 | 実際にログを取得し、User-Agent・応答コード・URLが含まれることを確認 |
構築したあとに残る作業
RFPで担保できるのは、構築時の状態までです。そのあとの機能追加、パッケージのバージョンアップ、WAFの設定変更で、要件どおりの状態は崩れます。保守契約に「要件の維持」と「変更時の確認」が入っているかを確認してください。
Search OSは、ecbeingなど大規模パッケージで構築されたサイトを対象に、この6領域にあたる状態を継続的に検証します。構築時から崩れた項目や、ボットの取得状況の変化は、修正対象として整理します。構築を行う層ではありません。構築後に要件を見続ける役割は、契約の段階で決めておきます。
よくある質問
RFPにここまで書くと、提案が来なくなりませんか
要件が明確なRFPは、ベンダーにとって見積もりしやすい文書です。対応できない項目があれば、提案書で代替案が示されます。書かないほうが、あとで揉めます。
レンダリング方式は、ベンダーに任せていいですか
任せると、ベンダーの得意な方式になります。AI検索を重視するなら、サーバーサイドレンダリングを要件として書いておいてください。
ログの提供は当たり前ではないのですか
運用契約によっては、ログはベンダー側にあり、発注者が直接取得できないことがあります。RFPに書いておきます。
あわせて読みたい
参考資料
Google Search Central: JavaScript SEO basics
Google Search Central: URL structure best practices
Google Search Central: Ecommerce best practices
Google Search Central: Verifying Googlebot and other Google crawlers