【実務記録】社名変更に伴うサイトリニューアルで、SSLが使えなくなった話

目次

概要

クライアントの社名変更に伴うサイトリニューアル対応。ドメイン変更、そして新ホームページはStudioで構築済みという前提のプロジェクトだった。

旧サイトはWordPressで、サブディレクトリ運用していたSEOメディアも、この機会にWordPressごと移行することになった。

当初の依頼は「SEOメディアの移行のみ」というシンプルなものだったが、ふたを開けてみると以下まで対応することになった。

  • Studio公開設定
  • サブドメイン設計
  • DNS設計
  • SSL設計
  • Cloudflare導入
  • URL正規化
  • HTTPSリダイレクト

一番の山は、SSLだった。

サイト構成

移行前

| 項目 | 内容 |

|—|—|

| サーバー | へテムル |

| ドメイン | ムームードメイン |

| ホームページ | WordPress |

| SEOメディア | WordPress(サブディレクトリ) |

移行後

| 項目 | 内容 |

|—|—|

| ドメイン | ムームードメイン |

| DNS | Cloudflare |

| ホームページ | Studio(本ドメイン) |

| SEOメディア | WordPress(サブドメイン) |

課題

1. サブディレクトリ運用ができない

Studioを本ドメインで公開する構成にしたため、従来の「本ドメイン/メディア名」というサブディレクトリ構成がそもそも使えなくなった。SEOメディアはサブドメインに切り出すしかない。

2. 無料SSLが使えない

サブドメインに切り出したところで発覚したのがこれ。へテムルの無料SSLには「本ドメインが同一サーバーを向いていること」という適用条件があり、今回は本ドメインのDNSがStudio側を向いているため、この条件を満たせなかった。

つまり、サーバー側の設定が正しくても、本ドメインの向き先次第でサブドメインの無料SSLが取れなくなるということ。ここは事前にほぼ想定していなかった落とし穴だった。

3. URL正規化が未対応

Studio側で www あり・なしの統一がされておらず、これも合わせて手当てする必要があった。

対応内容

① 構成確認

サイト構成、サーバー・ドメイン・DNSの管理会社、SSLの提供元と適用条件を洗い出し。

② WordPress移行

  • サブドメイン作成
  • WordPress新規インストール
  • All-in-One WP Migrationでバックアップ取得
  • ローカル環境で復元確認
  • URL・会社名・メール設定を変更
  • 新環境へ復元

③ SSL問題対応

  • 無料SSLが使えないことを確認した上で、以下を比較検討。
  • へテムル有料SSL(クイック認証SSL)
  • Cloudflare
  • 手動SSL
  • 最終的にCloudflareを採用。

④ Cloudflare導入

  • アカウント作成
  • DNS管理をCloudflareへ移行
  • DNSレコードの整理
  • Proxy設定
  • SSLモードの検証
  • HTTPS動作確認

⑤ SEO・公開設定

  • www なしへ301リダイレクト
  • HTTPSへのリダイレクト
  • SiteURLの確認
  • mixed content の確認

⑥ 公開確認

  • dig確認
  • SSL Labs確認
  • 表示確認
  • 公開確認

最終構成

  • ドメイン管理:ムームードメイン
  • DNS管理:Cloudflare
  • ホームページ:Studio(本ドメイン)
  • SEOメディア:WordPress(サブドメイン)
  • ユーザー ⇔ Cloudflare:HTTPS
  • Cloudflare ⇔ Studio:HTTPS
  • Cloudflare ⇔ へテムル:HTTP(Flexible運用)
  • www → 非wwwへ301リダイレクト
  • HTTPSへ自動リダイレクト

SEOメディアは問題なく移行・公開完了。

なお、Cloudflareとへテムル間はSSL化されておらず、厳密には完全SSL(End to End)ではない。ただし今回は一般的なSEOメディア・WordPress・記事閲覧・問い合わせフォーム程度の構成だったため、リスクを説明した上で現状運用とする判断をした。

また、へテムルの有料SSL(クイック認証SSL)はStudio側との構成上不要になったため、更新しない方向で整理した。

今回の学び

WordPress移行案件でも、公開構成(本ドメイン/サブドメイン/サブディレクトリ)次第でDNS・SSLまで影響が及ぶことがある

StudioとWordPressが混在する構成では、最初に「公開構成をどうするか」を決めることが全ての前提になる

無料SSLの可否は、サーバー単体の性能ではなく「ドメインとサーバーの向き先の組み合わせ」で決まることがある

CloudflareはSSL対応だけでなく、DNS管理を同時に整理できるツールとしても機能する

公開前には SSL・リダイレクト・DNS・mixed content まで一通り確認する

次回、同種の案件で最初に確認すること

サイト構成

  • 本ドメイン・サブドメイン・サブディレクトリのどれで運用するか
  • ホームページとメディアをどこに配置するか
  • Studio・WordPress・その他CMSの組み合わせ

サーバー・ドメイン

  • サーバー会社
  • ドメイン管理会社
  • DNS管理会社
  • SSL提供元

SSL

  • 無料SSLの適用条件
  • サブドメイン利用の可否
  • Cloudflare利用予定の有無
  • サーバー間のSSLが必要かどうか

SEO

  • URL変更の有無
  • 301リダイレクトの方法
  • www の正規化
  • HTTPSへのリダイレクト
  • Search Console対応

DNS

  • DNS切り替えのタイミング
  • TTL
  • Aレコード・CNAMEの構成
  • Studio側の要求設定
  • WordPress側の要求設定

公開前確認

  • SSL
  • リダイレクト
  • mixed content
  • 表示確認(PC/SP)
  • DNS反映確認
  • Search Console
  • サイトマップ送信

目次