.dev ドメインの注意点｜HTTPS 強制で運用中・移行時に起きやすいトラブルと対処

.dev は TLD 全体がブラウザの HSTS プリロードリストに入っているため、HTTPS でしか開けず、証明書に問題があると利用者は警告を無視して先へ進むこともできません。つまり .dev の注意点の多くは「証明書と HTTPS の不具合が、そのままサイト停止になる」ことに集約されます。この記事では、.dev で WordPress サイトを運用している人や、既存サイトを .dev に移そうとしている人に向けて、起きやすいトラブルと確認・対処の方法を説明します。

前提：.dev は HTTPS 以外では開けない

.dev は Google 系のレジストリが運営する gTLD で、一般登録は 2019年に始まりました。主要なブラウザ（Chrome、Firefox、Safari、Edge など）は HSTS プリロードリストを内蔵しており、.dev はその中に TLD 単位で登録されています（2026年10月現在）。

この結果、次のような動きになります。

• 利用者が http://example.dev と入力しても、ブラウザは通信を始める前に https:// に切り替える
• 証明書の期限切れや名前の不一致があると、エラー画面に「詳細設定から進む」といった回避の手段が表示されない
• サーバー側で HSTS ヘッダーを送っていなくても、また HSTS を止めたくても、この動きは変えられない

この記事では取得前の選び方や新規構築の手順には深入りせず、運用と移行で困る場面に絞って説明します。

注意点1：証明書切れが即サイト停止になる

ほかの TLD なら、証明書が切れても警告を承知で進む利用者がいますが、.dev ではそれができません。証明書の更新漏れは、そのままサイトとすべてのサブドメインの停止を意味します。

有効期限の確認

サーバーの証明書の有効期限と対象のドメイン名は、次のコマンドで確認できます（OpenSSL 1.1.1 以降を想定）。

echo | openssl s_client -connect example.dev:443 -servername example.dev 2>/dev/null \
  | openssl x509 -noout -subject -dates -ext subjectAltName

notAfter が有効期限、subjectAltName が証明書に含まれるドメイン名です。www.example.dev で運用しているのに証明書に example.dev しか含まれていない、といった不一致もここで分かります。

自動更新が動くかを試す

Let's Encrypt を certbot で使っている場合は、更新処理を実際には行わずに試せます。

sudo certbot renew --dry-run

ここでエラーが出る場合、更新日になっても失敗します。よくある原因は、ファイアウォールで80番ポートを閉じている（HTTP-01 チャレンジが通らない）、Web サーバーの設定変更で /.well-known/acme-challenge/ に届かなくなった、DNS-01 チャレンジ用の API トークンが失効した、などです。

期限の通知を自前で用意する

Let's Encrypt は 2025年に有効期限の通知メールの送信を終了しました。また、証明書の最大有効期間は業界全体で段階的に短くなる方向にあり、更新の回数は今後増えていきます。サーバー内の自動更新に加えて、外部の監視サービスで証明書の期限を見る仕組みを用意しておくと、更新処理そのものが止まったときにも気づけます。

注意点2：既存サイトを .dev に移すときの手順

既存の WordPress サイトを別のドメインから .dev に移す場合は、「証明書が先、URL の置き換えが後」の順序が大切です。.dev では証明書がない状態ではページを一度も表示できないため、DNS を切り替える前に証明書を用意できるかを確認しておきます。

作業前には、データベースとファイルのバックアップを取り、可能であればステージング環境で手順を一度通してください。

1. .dev ドメインの DNS を新しいサーバー（または同じサーバー）に向ける
2. .dev の証明書を取得し、https://example.dev でサーバーが応答することを確認する
3. データベース内の URL を置き換える
4. 旧ドメインから .dev へ 301 リダイレクトを設定する
5. Google Search Console で新しいドメインのプロパティを追加し、アドレス変更ツールを使う

URL の置き換えには WP-CLI の search-replace が便利です。シリアライズされたデータも正しく書き換えてくれます。まず --dry-run で件数を確認してから本番の実行に移ります。

# 置き換え対象の件数だけ確認する（データは変更されない）
wp search-replace 'https://old.example.com' 'https://example.dev' --all-tables --skip-columns=guid --dry-run

# 問題がなければ実行する
wp search-replace 'https://old.example.com' 'https://example.dev' --all-tables --skip-columns=guid

# 設定が切り替わったか確認する
wp option get home
wp option get siteurl

guid 列は投稿の識別子として使われるため、置き換えの対象から外すのが一般的です。

注意点3：混在コンテンツは「自分のドメイン」と「外部」で動きが違う

.dev のページに http:// の画像やスクリプトが混ざっている場合、自分のドメイン（http://example.dev/...）宛ての読み込みは、HSTS によりブラウザが自動で https:// に切り替えます。そのため、データベースに http://example.dev の URL が残っていても表示は崩れないことがあります。

一方、外部のサイト（HSTS が有効でないドメイン）から http:// で読み込んでいる画像やスクリプトは、ブラウザに止められたり警告の対象になったりします。表示が崩れたときは、ブラウザの開発者ツールのコンソールで、どの URL が止められているかを確認してください。

自分のドメインの http:// が残っているとしても、ブラウザ以外の仕組み（RSS リーダー、OGP を読むサービス、検索エンジンのクローラーなど）は HSTS プリロードリストを使わないことがあるため、データベースの URL は https:// にそろえておくほうが安全です。

注意点4：ブラウザ以外の接続元を忘れない

HSTS プリロードはブラウザの仕組みです。curl やサーバー間通信、外部サービスからの Webhook はプリロードリストを参照しないため、http:// で届いてしまいます。

• サーバー側でも http:// から https:// への 301 リダイレクトは残しておく
• 決済サービスやフォームサービスの Webhook、API のコールバック先は、最初から https:// の URL で登録する
• POST の通知は、リダイレクトされると本文が失われたりメソッドが変わったりする場合があるため、リダイレクトに頼らない

外部サービスの通知が届かないときは、登録している URL が http:// になっていないかを最初に確認します。

注意点5：サブドメインもすべて HTTPS 前提

.dev の HTTPS 強制は TLD 全体に及ぶため、staging.example.dev や mail.example.dev などのサブドメインも、すべて有効な証明書が必要です。社内ツールや古い機器の管理画面など、HTTP でしか動かないものを .dev のサブドメインで公開することはできません。

サブドメインが増える予定なら、ワイルドカード証明書（*.example.dev）を検討します。Let's Encrypt でワイルドカード証明書を取得するには DNS-01 チャレンジが必要なので、DNS サービスの API に対応した ACME クライアントを使います。

症状からの切り分け

よくある症状と、最初に確認したい点をまとめます。

まとめ

• .dev は TLD 全体が HSTS プリロードされており、HTTPS 以外では開けず、証明書エラーを回避して進むこともできない
• 証明書の期限切れはサイト停止に直結するため、certbot renew --dry-run と外部監視で更新を見守る
• 既存サイトの移行は、証明書を先に用意し、wp search-replace を --dry-run で確かめてから実行する
• ブラウザ以外の接続元のために 301 リダイレクトを残し、Webhook などは https:// で登録する
• サブドメインも含めてすべて HTTPS が前提になる

• SSL 証明書の有効期限を監視してアラートを出す方法
• HTTPS の混在コンテンツを解消する方法