ECサイトのリニューアルに決まった年数の目安はありません。見た目が古いという理由だけで全面改修する前に、購入者が困る操作、保守できない機能、商品・受注業務の変化を具体的に確認します。小さな修正で解消できる問題と、システムや情報設計まで見直す問題を分けて判断しましょう。
リニューアルの要否を課題から判断する
| 観察した課題 | 先に調べること | 検討する選択 |
|---|---|---|
| 注文や決済の途中で失敗がある | 端末、画面、決済方法、発生日時と再現手順 | 不具合修正、表示改善、決済設定の変更 |
| 商品が見つけにくい | 検索語、カテゴリ、絞り込み、問い合わせ内容 | 分類・検索調整、商品情報・一覧の改善 |
| スマートフォンで操作しづらい | 商品選択、入力欄、送料・合計、訂正方法 | 画面単位の修正、レスポンシブ対応、全面再設計 |
| 維持・連携が困難 | 保守期限、担当者、外部サービス、データ出力 | 連携更新、部分移行、システム変更 |
| 必要な業務に対応できない | 新しい商品・配送・受注業務の要件 | 現行機能の追加または構築先の変更 |
比較する期間や指標は、季節、広告、商品構成、送料・価格変更などの影響を受けます。売上や検索順位の一時的な変化だけで全面リニューアルを決めず、購入者の声、注文データ、問い合わせ、運営上の手戻りをあわせて確認します。
公開前に基準と検収条件を決める
改修前に、対象ページ・対象端末・購入テスト・計測方法を記録します。GA4を使う場合は、商品表示・カート追加・購入などのイベントが適切に記録されているかを確認し、期間や対象をそろえて前後を比較します。速度を調べる場合も、同じURLと測定条件で確認し、数値だけで売上効果を断定しないでください。
- 対象範囲、公開日、承認者、未決事項、保守担当を文書で合意する。
- 商品、価格、在庫、決済、送料、注文メール、返品・問い合わせをテストする。
- 公開前のバックアップ、切り戻し条件、障害時の連絡先を決める。
- スマートフォンで主な本文・商品情報・購入手順が確認できるか点検する。
URLやシステムを変える場合の移行表
ページのURLを変えるときは、旧URLから新URLへの対応表を作り、必要なリダイレクト、内部リンク、canonical、サイトマップ、構造化データのURLを確認します。変更しないURLは原則そのまま維持し、同じURLへ不要な転送を増やしません。Googleは301等の恒久転送、URLごとの対応、Search Consoleとサイトマップによる確認を案内しています。詳細はGoogle Search CentralのURL変更ガイドを参照してください。
| 旧URL | 新URL | 確認 |
|---|---|---|
| 移行するページの現行URL | 内容に対応する新URL | 旧URLの恒久転送が新URLへ一度で到達する |
| 変更しないページ | 同じ現行URL | 不要な転送がなく、canonicalが現行URLを示す |
| 各ページの参照先 | 新しい現行URL | 内部リンク・画像・サイトマップ・構造化データを確認 |
公開後の比較は同じ条件で続ける
公開後は、注文テスト、エラー、表示崩れ、受注・在庫連携、問い合わせを先に確認します。検索流入はSearch Consoleのクリック・表示回数等を、購入行動は計測設定済みのECイベントを使って観察します。Googleはサイト移行後にクロールと再インデックスが進む間、順位が一時変動することがあり、処理時間に固定期間はないと説明しています。直後の順位だけで成否を決めず、移行ガイドに沿ってURLごとに確認します。
画面やスマートフォン対応を含む改修については、ECサイト制作のサービス内容をご覧ください。現行サイトの課題と変更予定をお問い合わせから共有してください。
コメント