新機能が検索にもAIにも見えていなかった話｜サイト更新のSEO・AEO点検を、デプロイ前に308ページを機械で見る仕組みにした

サイトを更新して、動作も表示も確認した。それで「完了」にしていませんか。

私たちは2026年10月、追加した新機能が検索エンジンにもAI検索にも伝わらない状態のまま、本番に出していたことに気づきました。

この記事では、何が起きていたか、どう直したか、点検を人の記憶に頼らずどう仕組みにしたかを書きます。最後に、ECの商品ページやLPの更新でそのまま使えるチェックリストを載せます。

発端：検索の数字が落ちていた（10月2日）

私たちは自社で教材のカードゲームを作っており、無料のWebアプリと関連ページ（歌別100ページ・国別197ページ）を公開しています。

10月2日に検索コンソールの実データを確認しました。3か月で38クリック／3,200表示。直近28日に絞ると205表示まで急に落ちていました。

主な原因は次の2つと判断しました。

• 各ページの本文が約400字しかなく薄い
• 内部リンクが足りない。アプリから一覧ページへのリンクが0本で、国別197ページがどこからもたどれない状態だった

ページを作る生成スクリプトを改修し、297ページを作り直しました。国別ページは本文を約370字から約1,200字に増やし、Q&Aと、同じ色・同じ地域の国のページへのリンクを加えています。タイトルは実際の検索語に合わせて見直し、サイトマップの全URLに最終更新日を入れました。

同じ日に自社HPも確認しました。自然検索は28日で12セッション、84ページのうちGoogleに登録されていたのは約10ページです。中心にあったのは、リニューアル後にコラム74本が正規ではないURLを指していた問題でした。内部リンクの張り直し、301リダイレクト、構造化データの整備を行い、機械監査で問題が出るページは81から3に減りました。

つまずき：「動けばOK」のまま本番に出していた（10月5日）

10月5日、アプリに新しいクイズ（言語・通貨）と新しい遊び方の名前を追加して本番に反映しました。確認したのは、動作・音声・配信の3点です。

そこで社内の確認で「サイトの更新時は、SEO、AEO観点のチェックもしている？」と指摘が入りました。

していませんでした。AEOは、AI検索に正しく読まれ、引用されるかという観点です。

調べたところ、悪化はしていませんでした。ただ、新機能と新しい名前はJavaScriptが描画する部分にしか無く、description・構造化データ・静的な本文のどこにも書かれていませんでした。ブラウザで見れば表示されます。しかしJavaScriptを実行せずにHTMLを読む側から見れば、その機能は無いのと同じです。さらにtitle・description・構造化データは、検索結果やAIの要約が材料にする場所です。そこに名前が無ければ伝わりません。

対応したのは次の5点です。

• descriptionと構造化データに反映（機能一覧10項目・更新日）
• 遊び方の一覧9つを静的HTMLにも記載。読み込み後にJavaScriptが同じ形で描き直すため、見た目は変わらない
• 「このアプリについて」の欄を加え、JavaScriptなしで読める本文を664字から1,572字に増やした
• 国別197ページからクイズへのリンクを追加
• サイトマップの更新日を修正

仕組み化：デプロイ直前に308ページを機械で点検する

直すだけでは、次の更新でまた忘れます。そこで点検を「思い出したらやる作業」から外し、デプロイの関門に組み込みました。

点検スクリプトは新しく作り、標準ライブラリだけで動きます。308ページを静的に読み、次の項目を確認します。

• title／description／canonical／h1／OGP／構造化データ
• リンク切れ、内容の重複
• robots.txtでAIのクローラを拒否していないか
• サイトマップの載せ忘れ・存在しないURL・更新日
• JavaScriptなしで読める本文の量
• 新機能の名前が静的HTMLにもあるか
• ページの更新日とサイトマップの日付が一致しているか

点検自体が正しく働くかも確かめました。名前の欠落、canonicalの誤り、リンク切れ、titleの重複、AIクローラの拒否、サイトマップの載せ忘れなど、わざと壊したパターン16通りをすべて検出できることを確認しています。

そのうえで、デプロイのスクリプトが送信前に点検を自動で実行し、エラーがあれば送らないようにしました。反映した後は、本番のHTMLがローカルと一致しているかも照合します。

10月7日に本番へ反映しました（203ファイル、本番照合23件すべて一致）。検索コンソールでサイトマップを再送信し、6ページの登録をリクエストしています。このとき、一覧ページが「クロール済み・インデックス未登録」だったことが分かりました。ある検索語で圏外だった直接の原因はここでした。現在は、本文を強化したページの再クロールを待っています。

機械で見られない6項目と、人が担う部分

機械の点検で抜けは見つけられますが、中身が正しいかまでは判定できません。そのため、次の6項目はチェックリストにして人が確認します。

• 機能追加・名称変更をtitle／description／構造化データに反映したか
• JavaScriptなしで読める本文になっているか
• 関連ページからリンクしているか
• 更新日を変えたか
• 1〜2文で言い切る文があるか（AIが引用しやすい形）
• 本文の内容がアプリや他のページの事実と一致しているか

更新作業の多くは生成AIと分担していますが、人が担う部分もはっきりあります。今回の見落としに気づいたのは人でした。titleとdescriptionの文言を決めること、順位の変化をどう解釈するかも人の仕事です。

AEOの現状も書いておきます。AIクローラを拒否していない、本文は静的HTMLで読める、よくある質問を199ページに設けている、出典と時点を本文に書いている。ここまでは整えました。ただ、効果を数字で測る方法はまだありません。月に1回、AI検索に実際に質問して、引用元に自社のページが出てくるかを確かめる予定です。

ECサイトの更新に置き換えると

商品ページ・LP・自社ECの更新でも同じことが起こります。新しい訴求を、後から読み込まれる部品や画像の中だけに入れると、見た目は完成していても検索やAIには伝わりにくくなります。広告で集客したお客様には見えても、自然検索やAI検索からの「広告費がかからない流入」にはつながりません。広告後粗利の観点では、これがいちばんもったいないところです。

更新のたびに確認したいチェックリストです。

• 新しい訴求・商品名・機能名が、titleとdescriptionに入っているか
• その言葉が、画像やJavaScriptの部品の中だけでなく、テキストの本文にもあるか
• JavaScriptを無効にしてページを開いても、主要な説明が読めるか
• 関連する商品ページやカテゴリから、そのページへリンクしているか
• 構造化データ（商品情報・よくある質問など）が本文と食い違っていないか
• サイトマップの更新日を変えたか
• robots.txtで、意図せずAIのクローラを拒否していないか
• 「この商品は何で、誰向けか」を1〜2文で言い切る文があるか

判断の基準はシンプルです。JavaScriptなしで読めない訴求は、検索とAIにとっては無いものと考えて、公開前に一度確かめてください。できればその確認を人の記憶に任せず、公開手順の中に組み込んでおくのが確実です。

まとめ

• 見た目が同じでも、JavaScriptなしで読めるかどうかで結果は変わる
• 点検は人の記憶に頼らず、デプロイの関門にする
• 機械で見られる項目は機械に任せ、文言の決定・事実確認・数字の解釈は人が担う

まずは自社のページを、JavaScriptを無効にした状態で一度開いてみてください。
店舗 URL での無料 EC 診断もやっています：https://ec-sekitoba.jp/#contact
AI導入・内製化のご相談も同じ窓口で受け付けています。