SI構築サイトに 開発工数なしでSEO・AI対応を足せるか
ECサイトをSIに作ってもらった企業から、いちばんよく受ける相談の1つがこれです。テンプレートやheadを直すには改修の見積もりと開発サイクルが要り、対応は半年先になる。開発工数を新たに取らずにSEOとAI検索対応を進める方法はないか、という相談です。
答えは「あります。ただし方式によります」です。原本のコードを直す方式は、どうしても開発サイクルを待つことになります。レンダリングは、ブラウザが画面を組み立てる過程です。原本を変えずに、検索エンジンとAIクローラーにだけ別のレンダリング層を渡す方式もあります。レンダリング層は、ボット向けに組み立て直した画面です。こちらなら、SIの開発サイクルとは切り離して進められます。
この記事では、SI構築サイトでSEO変更が止まる理由を確認したうえで、2つの方式の比較、適用範囲と限界、判断基準、実際の事例を整理します。
結論: 原本を直す方式は開発サイクルが要る。別レンダリング層の方式なら独立して進められる
方式 | 内容 | 開発工数 | 適用範囲 | リスク |
|---|---|---|---|---|
A. 原本修正 | SIにテンプレート・head・構造化データの改修を依頼 | 見積もり・開発・テスト・リリースの各サイクル | 全面 | 改修のたびに同じサイクル。保守契約の範囲外なら追加費用 |
B. タグマネージャ経由 | GTM等でメタタグや構造化データを注入 | 小 | 限定的 | JavaScript注入はクローラーに読まれない場合が多い。根本解決にならない |
C. 別レンダリング層 | 原本を変えず、検索エンジン・AIクローラー向けに整理されたHTML・メタデータ・構造化データを別途提供 | ほぼなし(DNSまたはプロキシの設定) | メタデータ・構造化データ・sitemap・robots・canonical・可視テキストの整理 | 決済・会員機能など人向けの機能は対象外(元のまま) |
多くのSI構築サイトで現実的なのはCです。Aは本来あるべき形ですが、改修サイクルに縛られている限り、SEOとAI検索対応はいつも半年遅れになります。Bは手軽に見えます。ただし、クローラーの多くはJavaScriptで後から差し込んだ内容を安定して読まないため、期待した効果が出ないことが多くなります。
重要な考え方: SEOとAI検索対応は、人が見る画面を変える作業ではありません。ボットが読む層を整える作業です。店の内装はそのままで、店の外に置く案内板だけを書き換えるのに近い作業です。ボットが読む層を原本から切り離せれば、開発サイクルとは別に運用できます。まず「人向けの画面」と「ボットが読む層」を分けて考えます。
SI構築サイトでSEO変更が止まる理由
止まる理由は技術ではありません。体制です。
変更権限がSIにある。 テンプレートやheadを1行変えるだけでも、依頼・見積もり・承認の順番待ちになります。
保守契約の範囲が「不具合修正」に限られている。 SEO改善は「機能追加」の扱いになり、別契約になります。
リリースサイクルが固定されている。 四半期に1回といったペースです。SEOは小さな修正の積み重ねなので、このペースとは合いません。
レンダリングがJavaScript依存。 SIが選んだフレームワークがクライアント側描画だと、クローラーは商品情報を読み取れません。直すとなると大がかりな改修になります。
4つ目はとくに重い項目です。原本を直す方式だと、フレームワークの入れ替えに近い改修になります。上のどれに当てはまるかを、まず書き出します。
別レンダリング層の方式でできることと、できないこと
できること | できないこと |
|---|---|
title・meta description・canonical・hreflangの整理 | 決済・会員・カートなど人向けの機能変更 |
JSON-LD(Product、Article、BreadcrumbList等)の付与と可視テキストとの整合 | 商品データそのものの修正(元データが誤っていれば元を直す必要がある) |
sitemap.xml、robots.txt、llms.txtの生成・運用 | デザインやUIの変更 |
クライアント側描画で隠れている商品情報の、ボット向けHTMLへの展開 | 原本のパフォーマンス(人向けの表示速度)の改善 |
画像内テキストのテキスト化 | |
ボットログの取得と観測 |
ボットが読む層に関わるものは対象で、人が操作する機能は対象外です。商品説明のテキスト化は対象、カートのボタンの変更は対象外になります。SEOとAI検索対応に要る作業の大半は、前者に入ります。やりたいことを「ボット向け」と「人向け」に仕分けます。
自社に向いているかの判断基準
別レンダリング層の方式が向いているのは、次の条件に2つ以上当てはまるときです。
テンプレート変更の依頼から反映まで1か月以上かかる
保守契約でSEO改善が範囲外になっている
サイトがクライアント側描画で、Search ConsoleのURL検査で商品情報が取得HTMLに含まれない
商品・カテゴリ・コンテンツページが数千以上あり、個別対応が現実的でない
CDN・WAF・ボット対策ツールの設定変更権限が自社またはインフラ会社にある
最後の条件だけは、先に確かめてください。DNSやリバースプロキシの設定を変えられないと、別レンダリング層を挟めません。ここはSIではなく、インフラ担当との相談になることが多い部分です。DNSの設定を誰が変えられるかを確認します。
事例: 追加の開発・マーケター人員なしで
年商400億ウォン(約40億円)規模の韓国ECブランドの事例です。SIには改修を頼まず、別レンダリング層で、Technical SEOの基盤(レンダリング、canonical、メタデータ、構造化データ、索引可能性)を3週間で整えました。画像にしかなかった商品説明は、OCRでHTMLテキストに変えています。販売中の商品に残っていた、隠れた品切れテキストも取り除きました。そのあとはボットログを見ながら、商品・カテゴリ・ブランドコンテンツを優先して改善しています。結果として、3か月でOrganic購入売上が約9,206万ウォンから約1.66億ウォンに伸びました。追加の開発人員もマーケター人員も入れていません。自社の商品説明が画像だけになっていないかは、同じ手順で確認できます。
開発サイクルから独立した運用へ
SI構築サイトでいちばんの壁は、技術ではありません。「変更のたびに開発サイクルを待つ」体制です。ボットが読む層を原本から切り離せば、マーケティング部門が主導できます。週単位で修正と検証を回せるようになります。
Search OSは、この別レンダリング層をSEO/GEO自動化ソリューションとして提供しています。既存のサービス運営は大きく揺らしません。検索エンジンとAIが読みやすい別のレンダリング構造を用意します。メタデータ、セマンティックタグ、sitemap.xml、robots.txt、canonical、hreflangも整えます。構造化データとボットログ観測も含めて、ひとまとめで運用します。SIの開発サイクルは人向けの機能改善に集中し、ボットが読む層はSearch OSが担う。そういう分担です。SIに頼む作業と別の層に任せる作業は、先に分けて書き出しておきます。
よくある質問
SIに知らせずに導入できますか
技術的には原本を変えないため可能です。ただし、DNSやプロキシの設定変更にはインフラ担当との調整が要ります。SIには方式を共有し、原本の改修計画と役割を分けておくほうが、運用は安定します。
原本の改修と併用できますか
併用できます。別レンダリング層で先に効果を出し、原本の改修は次のリリースサイクルで進める。この順番が現実的です。改修が終わったあとも、可視テキストと構造化データの一致を確かめる層として残ります。
効果はどこで確認しますか
Search Consoleのクリック・表示回数・索引状況を基準線にします。ボットログでは、Googlebot・GPTBot等が実際に取得しているかを見ます。AI検索での引用は、Bing Webmaster ToolsのAI Performanceや各種AI可視性ツールで追います。
あわせて読みたい
参考資料
Google Search Central: JavaScript SEO basics
Google Search Central: Dynamic rendering as a workaround
Google Search Central: AI features and your website