ebisumart 自動バージョンアップ後のSEO確認
ebisumart 自動バージョンアップ後のSEO確認
- Category
- Tips 7分で読める 日本ECプラットフォーム別 検索・AI検索ガイド
ebisumartは基盤が自動でバージョンアップされるため、セキュリティと機能は常に最新ですが、テンプレートやSEO関連の出力が意図せず変わることがあります。バージョンアップ後に確認すべき項目を、メタデータ・...
- URL
- searchos.io/ja/blog
- Copyright
- © 2026 Search OS
ebisumartは基盤側で自動的にバージョンアップされます。そのため、先月のバージョンアップのあとにリッチリザルトが消えた気がする、という相談が寄せられます。
自動バージョンアップは基盤側の変更で、通常はテンプレートやカスタマイズを壊さないように設計されています。canonicalは、どのURLが正なのかを検索エンジンに伝える印です。それでも、標準の出力である構造化データ、canonical、メタタグの生成ルールが変わることはあります。変更は「壊れる」形ではなく「静かに変わる」形で起きるため、画面を見ても気づけません。検索結果の変化で初めて気づいたときには、バージョンアップから数週間たっています。
この記事では、バージョンアップ後30分で確認する5領域のチェックリストと、変更を見つけたときの対処、確認を続ける仕組みを整理します。
結論: バージョンアップの通知を受けたら、翌営業日に5領域を確認し、前回の記録と比較する
領域 | 確認するもの | 道具 | 所要 |
|---|---|---|---|
メタデータ | title・description・canonicalの出力 | 主力3ページのソース | 5分 |
構造化データ | 検出される型とエラー | リッチリザルトテスト(商品1・カテゴリ1・トップ) | 10分 |
URL | 主力ページのURLと、パラメータ付きURLのcanonical | ブラウザ | 5分 |
サイトマップ | URL数、lastmod、エラー | サイトマップのURLとSearch Console | 5分 |
速度 | LCP・CLS・INP | PageSpeed Insights(主力商品ページ) | 5分 |
Category
- Search OS
- ガイド 01
バージョンアップ翌営業日の30分チェック
前回の記録と比較して「変わったか」を見る
| 項目 | 所要時間 | チェック内容 |
|---|---|---|
| メタデータ | 5分 | title・description・canonical 主力3ページのソース |
| 構造化データ | 10分 | 検出される型とエラー リッチリザルトテスト |
| URL | 5分 | 主力URLとパラメータ付きURLのcanonical |
| サイトマップ | 5分 | URL数・lastmod・エラー |
| 速度 | 5分 | LCP・CLS・INP PageSpeed Insights |
- POINT
- 「変わったか」は「前がどうだったか」の記録がなければ分からない
© 2026 Search OS
重要な考え方: 「変わったか」は、「前がどうだったか」の記録がないと分かりません。体重計に乗る前の数字を知らなければ、増えたか減ったかは判断できません。チェックリストより先に、前回の記録を用意します。
まず、前回の記録を作る
初回は、バージョンアップの前に次を記録しておきます。引っ越し前に部屋の写真を撮っておくのと同じ役割です。
主力3ページ(トップ・主力カテゴリ・主力商品)のtitle・description・canonicalの文字列
同じ3ページでリッチリザルトテストが検出する型と、警告の有無
サイトマップのURL数
PageSpeed InsightsのLCP・CLS・INPの値
robots.txtの内容
スプレッドシートに、日付付きで残します。次回以降は、この記録と比べるだけで済みます。
領域ごとに疑うこと
領域 | 変わっていたら疑うこと |
|---|---|
titleの生成ルールが変わった(ショップ名の位置、区切り文字) | 基盤側のtitleテンプレートの変更 |
canonicalの向き先が変わった | パラメータの扱いの変更 |
構造化データの型が消えた、属性が減った | 基盤側の標準出力の変更、またはテンプレートとの競合 |
サイトマップのURL数が大きく変わった | 対象範囲の変更、または生成の停止 |
速度が悪化した | 基盤側で追加されたスクリプト |
robots.txtが変わった | 基盤側のデフォルト変更 |
Search OS ガイド 02
変わっていたら何を疑うか
領域ごとの典型的な原因
| 番号 | 主な変化 | 詳細・原因 |
|---|---|---|
| 1 | titleの生成ルールが変わった | 基盤側のtitleテンプレートの変更 |
| 2 | canonicalの向き先が変わった | パラメータの扱いの変更 |
| 3 | 構造化データの型・属性が減った | 標準出力の変更、またはテンプレートとの競合 |
| 4 | サイトマップのURL数が大きく変わった | 対象範囲の変更、または生成の停止 |
| 5 | 速度が悪化した | 基盤側で追加されたスクリプト |
| 6 | robots.txtが変わった | 基盤側のデフォルト変更 |
© 2026 Search OS
変更を見つけたときの対処
ebisumartのリリースノートで、該当バージョンの変更内容を確認する
変更が意図的なもの(仕様変更)か、副作用かを判断する
仕様変更なら、新しい仕様に合わせてテンプレート・設定を調整する
副作用なら、サポートに問い合わせる。記録した「前後の差分」を添える
調整後、再度5領域を確認し、記録を更新する
サポートに問い合わせるとき、「順位が下がった」だけでは伝わりにくい内容になります。「バージョンX.Yの後、商品ページのProduct構造化データからofferが消えた」のように、差分を具体的に伝えます。問い合わせ文には、記録した前後の差分を添えます。
「3秒」はどこに当たるか
GoogleのCore Web Vitals基準。3秒超はLCP「改善が必要」以下
| 指標 | 説明 | 良好 (Good) | 改善が必要 (Needs Improvement) | 不良 (Poor) |
|---|---|---|---|---|
| LCP | 最大コンテンツの描画 | 2.5秒以下 | 2.5秒超 〜 4秒以下 (3秒はこの範囲に含まれる) | 4秒超 |
| INP | 操作への応答 | 200ms以下 | 200ms超 〜 500ms以下 | 500ms超 |
| CLS | レイアウトのずれ | 0.1以下 | 0.1超 〜 0.25以下 | 0.25超 |
出典: Google Search Central「Core Web Vitals」の基準値
© 2026 Search OS
確認を続ける仕組み
自動バージョンアップは定期的に行われます。毎回30分の確認を続けるには、担当者と通知を受け取る経路を決めておきます。通知を見落とすと、確認のタイミングを逃します。決めるのは、通知の受け取り先と担当者の二つです。
チェックリストでは届かないところ
チェックリストは、人が見に行ける範囲が対象です。変化が主力3ページ以外の数千ページで起きていれば、3ページの確認では見つかりません。浜辺の砂を数粒だけ見て浜全体を判断するのと同じ状態です。AIクローラーがバージョンアップ後もページを取得できているかは、Search ConsoleにもPageSpeed Insightsにも出ません。
Search OSは、ebisumartを含む自動更新される基盤のサイトに対して、メタデータ・構造化データ・canonical・サイトマップの状態を全ページで継続的に検証します。バージョンアップの前後で変わったものを差分として検出し、修正対象に整理します。バージョンアップを止める層ではありません。バージョンアップのたびに何が変わったかを見続ける仕組みを、運用の側に置きます。
よくある質問
バージョンアップを止めることはできますか
ebisumartの自動バージョンアップは基盤の特徴で、通常は選べません。止めるのではなく、変化を検出する運用にします。
テンプレートをカスタマイズしていれば影響を受けませんか
カスタマイズした部分は、保持されることが多いです。ただし、カスタマイズしていない基盤側の標準出力は変わります。カスタマイズの有無にかかわらず確認します。
順位の変動がバージョンアップのせいか、Googleのアップデートのせいか分かりません
両方の時期を記録しておきます。バージョンアップの直後に5領域で差分があれば、原因は基盤側です。差分がなければ、検索エンジン側の可能性が高いです。
あわせて読みたい
参考資料
Google Search Central: Page Indexing report
Google: Rich Results Test
Google: PageSpeed Insights