ECサイトのHTTPS対応とSEO｜移行時に確認すべきポイント
目次
HTTPSは、ブラウザとWebサイト間の通信を暗号化し、改ざんや盗み見のリスクを抑える仕組みです。個人情報や決済を扱うECサイトでは、商品ページを含むサイト全体をHTTPSで提供することが基本です。
HTTPからHTTPSへの移行ではURLが変わるため、証明書を入れるだけでは完了しません。転送、canonical、内部リンク、サイトマップ、外部サービスの設定をHTTPSへそろえます。
HTTPSが必要な理由
ログイン、住所入力、決済だけでなく、商品閲覧時にもCookieや行動データが通信されます。サイト全体をHTTPSにすることで、ページ間を移動するたびに安全性が変わる状態を避けられます。
ブラウザの安全表示や外部サービスの要件にも関わります。SEO効果だけを目的にせず、利用者が安心して購入できる基盤として扱います。
TLS証明書を正しく設定する
対象ホストを含む有効な証明書を設定し、有効期限、証明書チェーン、暗号設定を確認します。wwwあり・なし、画像用サブドメイン、決済や会員用サブドメインも対象を整理します。
証明書の自動更新を使う場合も、更新失敗を監視します。期限切れは利用者のアクセスとクローラーの取得を同時に妨げます。
HTTPからHTTPSへ恒久転送する
すべてのHTTP URLから対応するHTTPS URLへ、サーバー側の恒久的なリダイレクトを設定します。トップページだけへ転送せず、商品やカテゴリを一対一で同じパスへ送ります。
wwwの統一やURL改修も同時に行うと問題の原因を切り分けにくくなります。可能ならHTTPS化以外の大きな変更は分けて実施します。
内部リンクをHTTPSへ更新する
メニュー、商品カード、パンくず、画像、CSS、JavaScript、フォーム送信先をHTTPSへ更新します。転送に頼ってHTTPリンクを残すと、ページ表示ごとに余計な通信が発生します。
メール、広告、商品フィード、SNSプロフィール、外部モール連携など、管理できるリンクも更新します。外部リンクはすべて変えられなくても転送で受けられます。
canonicalとサイトマップ
HTTPSページのcanonicalはHTTPSの正規URLを指すようにします。XMLサイトマップもHTTPS URLだけに切り替え、Search Consoleへ送信します。
HTTPをcanonicalに残す、HTTPSをサイトマップへ載せながらHTTPへ転送するなど、手掛かりの矛盾をなくします。構造化データ内のURLも確認します。
mixed contentを解消する
HTTPSページ内でHTTPの画像、スクリプト、CSSを読み込むとmixed contentになります。ブラウザがリソースをブロックし、画像や購入機能が動かないことがあります。
商品説明へ担当者が貼り付けた外部画像、古いバナー、レビュー部品など、テンプレート外の内容も確認します。自社で管理できないHTTPリソースは、安全な配信先へ置き換えます。
Cookieとフォームを確認する
セッションCookieにはSecure属性など適切な設定を行い、ログインやカートがHTTPSで維持されるかを確認します。HTTPとHTTPSでセッションが分かれ、カート内容が消える事故に注意します。
フォーム送信先、API、決済コールバックもHTTPSへそろえます。SEOだけでなく購入完了までの動作テストが必要です。
Search Consoleと計測設定
HTTPSのプロパティでサイトを確認し、インデックス、サイトマップ、クロール状況を監視します。ドメインプロパティを使う場合も、HTTPとHTTPSの動きを分けて確認します。
アクセス解析、広告タグ、コンバージョン計測が新URLで動作するかをテストします。参照元やクロスドメイン設定が変わる場合があります。
公開前後のテスト
商品、カテゴリ、画像、ログイン、カート、決済、問い合わせからサンプルを選びます。証明書、HTTPからの転送、最終200、canonical、mixed contentを確認します。
公開後はHTTPへのアクセス、転送エラー、404、5xx、Googlebotのクロールを監視します。HTTPS URLの登録が増え、HTTP URLが減っていくかを一定期間見ます。
よくある間違い
- トップページだけHTTPSへ転送する
- 内部リンクや画像URLをHTTPのまま残す
- canonicalがHTTPを指し続ける
- 証明書の更新失敗を監視しない
- HTTPS化とCMS・URL構造変更を同時に行う
確認項目
- 全ホストの証明書が有効か
- HTTPから対応するHTTPSへ一回で転送するか
- 内部リンク、canonical、サイトマップがHTTPSか
- mixed contentがないか
- ログイン、カート、決済が正常か
- Search Consoleと計測設定を更新したか
段階移行と一括移行を選ぶ
HTTPS化は一般にサイト全体でそろえるほうが分かりやすい一方、大規模サイトでは一部ホストやカテゴリで先行テストする方法もあります。HTTPとHTTPSが混在する期間は、canonical、内部リンク、Cookie、決済遷移が複雑になるため短く管理します。
先行範囲では、検索流入が極端に季節変動しないページを選びます。証明書、転送、mixed content、ログイン、Googlebotの取得を確認してから広げます。
HSTSの導入を検討する
HSTSはブラウザへHTTPS接続を強制する仕組みです。安全性を高められますが、設定後に証明書やHTTPS配信へ問題があるとHTTPへ戻れません。全サブドメインを含める指定は影響範囲が大きいため、準備が整ってから段階的に導入します。
SEOだけで設定せず、セキュリティとインフラの担当者が証明書更新、サブドメイン、復旧手順を確認します。事前読み込みリストへの登録も、長期運用の責任を理解して判断します。
外部連携を棚卸しする
決済、在庫API、レビュー、チャット、広告計測、商品フィード、メール内リンク、画像CDNなど、ECサイトは外部サービスと多く連携します。コールバックURLや許可ドメインがHTTPのままだと、一部機能だけ失敗することがあります。
連携先、担当者、設定変更、テスト結果を一覧にします。本番公開時には、購入完了、キャンセル、再決済、会員登録など通常以外の経路も確認します。
移行後のHTTPアクセスを分析する
ログからHTTPへのアクセス元を調べ、内部リンク、外部サービス、古いアプリ、botを分けます。管理できるHTTPリンクはHTTPSへ更新し、転送負荷を減らします。
HTTP URLへのGooglebotアクセスが残っていても、正しい恒久転送を維持します。旧URLが減るまでの時間はサイト規模で異なるため、転送を早期に外しません。
ECサイトでの移行例
商品ページ「http://example.com/products/123」は、同じパスの「https://example.com/products/123」へ一回で301転送します。HTTPのトップページへ転送してから商品へ移す二段階は避けます。
商品説明内に「http://cdn.example.com/image.jpg」が残る場合、画像CDNもHTTPSへ対応し、本文データを更新します。テンプレートだけ直しても、過去に登録した説明文やバナーにはHTTPが残ることがあります。
公開後は、HTTP版URL一覧をクロールして最終HTTPSと200を確認します。Search Console、ログ、ブラウザのmixed content警告、決済テストを並行して見れば、検索と購入の問題を早く切り分けられます。
まとめ
ECサイトのHTTPS対応は、安全な通信と購入体験の基盤です。SEO面ではURL移行として扱い、HTTPからHTTPSへの転送と各種URLの統一を行います。
商品ページだけでなく、画像、API、フォーム、Cookieまで確認してください。公開後はHTTPとHTTPSのクロール・登録状況を監視し、古いURLやmixed contentを段階的に解消します。
