.app ドメインのいちばん大きな特徴は、TLD 全体が主要ブラウザの HSTS preload リストに登録されていて、HTTPS でしか開けないことです。証明書の準備が遅れたり、更新が止まったりすると、閲覧者は警告を無視して先へ進むこともできません。この記事では、この仕組みが実際にどんな問題を起こすかを整理し、公開前の証明書の準備、WordPress の設定、サブドメインや開発環境での注意点を順に説明します。
ブラウザの実装や各サービスの画面は変わることがあります。手順は考え方として読み、実際の表記は各サービスの案内で確認してください（2026年10月現在）。
.app ドメインの基本と HTTPS 必須の仕組み
.app は Google Registry が運営する gTLD で、2018年に一般登録が始まりました。登録者の国や業種の制限はなく、アプリの紹介サイトに限らず誰でも取得できます。
HSTS（HTTP Strict Transport Security）は、「このサイトには HTTPS でしか接続しない」とブラウザに覚えさせる仕組みです。通常はサイトが Strict-Transport-Security ヘッダーを返して初めて有効になりますが、.app は TLD 単位で preload リストに入っているため、ブラウザは初回のアクセスから HTTPS を使います。
この結果、次のような挙動になります。
http://example.app/と入力しても、ブラウザは通信の前にhttps://に置き換えます- 証明書の期限切れや名前の不一致があると、警告画面から「詳細設定」などで先へ進む選択肢が出ません
- サブドメイン（
www.example.app、staging.example.appなど）も同じ扱いです - サイト側の設定で HSTS を外すことはできません
一方、curl や監視ツール、サーバー間の API 通信など、ブラウザ以外のクライアントの多くは preload リストを参照しません。「curl では HTTP で開けるのに、ブラウザでは開けない」という食い違いはこれが原因です。
よくある問題と対処
1. DNS を向けたのにサイトが開けない
もっとも多いのは、DNS をサーバーへ向けた直後、証明書がまだ発行されていない状態です。HTTP なら仮のページが見えるはずの時間帯でも、.app ではブラウザが何も表示できません。
確認は次の順で行います。
# 名前解決が新しいサーバーを向いているか
dig +short example.app A
# 443番ポートで返ってくる証明書の名前と期限
openssl s_client -connect example.app:443 -servername example.app </dev/null 2>/dev/null \
| openssl x509 -noout -subject -ext subjectAltName -dates証明書が返ってこない、または別のドメイン名の証明書が返る場合は、サーバー側で証明書の発行・設定を済ませます。レンタルサーバーの無料 SSL は、DNS が向いてから発行まで時間がかかることがあります。
2. 証明書を公開前に用意したい
公開時の空白をなくすには、DNS を切り替える前に証明書を用意します。方法はサーバーの種類で分かれます。
- VPS や自前のサーバー：Let's Encrypt の DNS-01 認証を使えば、Web サーバーが公開されていなくても TXT レコードで発行できます。HTTP-01 認証も使えます。認証局の検証は 80 番ポートへの HTTP 接続で行われ、ブラウザの HSTS の影響は受けません。
- レンタルサーバー：DNS 切り替え前に SSL を設定できる機能を用意している事業者もあります。対応の有無と手順は事業者の案内で確認します。
- CDN を前に置く場合：CDN 側でエッジ証明書が発行されるまでの時間と、オリジンとの間の証明書の両方を確認します。
3. 証明書の期限切れでサイトが止まる
.app では証明書の期限切れがそのままサイトの停止になります。Let's Encrypt なら自動更新が動いているかを certbot renew --dry-run で確かめ、外部の監視サービスで証明書の残り日数も見ておきます。証明書の最長有効期間は業界ルールで段階的に短くなっているため、手作業の更新に頼る運用は早めに自動化に切り替えるのが安全です。
WordPress で .app を使うときの手順
新規に構築する場合
インストール時のサイトアドレスを最初から https://example.app にします。証明書が有効になってからインストーラーを開くと、URL が HTTPS のまま保存されます。
- 「設定」→「一般」の WordPress アドレスとサイトアドレスが
https://で始まっているか - テーマやプラグインの設定に
http://の URL を直接書いていないか
既存サイトを .app に移す場合
ドメインの変更は、データベース内の URL の置き換えを伴います。作業前にファイルとデータベースのバックアップを取り、可能ならステージング環境で試してから本番に適用します。WP-CLI が使える環境では、まず --dry-run で件数を確認します。
# まず件数だけ確認（実際には書き換えない）
wp search-replace 'https://old-example.com' 'https://example.app' --skip-columns=guid --dry-run
# 問題がなければ実行
wp search-replace 'https://old-example.com' 'https://example.app' --skip-columns=guid--skip-columns=guid は投稿の GUID を書き換えないための指定です。シリアライズされたデータも WP-CLI 側で扱われますが、独自形式でデータを保存するプラグインは個別の確認が要ります。旧ドメインから新ドメインへは 301 リダイレクトを設定します。
混在コンテンツを残さない
ページは HTTPS でも、画像やスクリプトを別ホストの http:// から読み込んでいると、ブラウザがブロックしたり自動で HTTPS に置き換えたりします。置き換え先が HTTPS に対応していなければ読み込みに失敗します。ブラウザの開発者ツールのコンソールで警告を確認し、外部の埋め込みや CDN の URL を HTTPS に直します。
サブドメインと開発環境での注意
TLD 単位の preload なので、ステージングや管理用のサブドメインにも有効な証明書が要ります。サブドメインが多い場合は、ワイルドカード証明書（*.example.app）を DNS-01 認証で取得すると管理が楽になります。ワイルドカードは1階層分だけが対象で、example.app 自体は含まれない点に注意します。
ローカル開発のホスト名に .app を使うのも避けます。実在する TLD なので名前の衝突が起こり、ローカルのサーバーに自己署名の証明書しかないとブラウザで開けません。ローカル用には .test や .localhost など、予約されている名前を使います。
なお、HSTS は Web ブラウザの HTTPS 接続に関する仕組みで、メールの送受信（SMTP）には影響しません。.app のアドレスでメールを使う場合は、MX・SPF・DKIM・DMARC を通常どおり設定します。
まとめ
- .app は TLD 全体が HSTS preload リストに入っており、ブラウザでは HTTPS でしか開けず、証明書エラーも回避できません。
- DNS を切り替える前に証明書を用意し、
openssl s_clientで名前と期限を確認します。 - WordPress は最初から
https://のアドレスで構築し、移行時はバックアップと--dry-runを経て URL を置き換えます。 - サブドメインにも証明書が要ります。ローカル開発には
.testなどの予約名を使い、証明書の自動更新と期限の監視を整えておきます。