サイトのドメインの TLD（.com や .jp などの末尾の部分）は、取得したあとで変えるのが大変な選択です。結論から言うと、「誰に向けたサイトか」で gTLD と ccTLD を選び、取得したら主ドメインを1つに決めて残りを転送し、更新・ロック・DNS の管理を最初に整えておくのが基本です。この記事では、TLD と ccTLD の違い、選ぶときの判断の軸、取得後の運用で事故を防ぐための手順を、WordPress サイトの運営者向けに整理します。
TLD・gTLD・ccTLD の違い
TLD（トップレベルドメイン）は、ドメイン名のいちばん右の部分です。大きく次の種類に分かれます。
- gTLD（分野別トップレベルドメイン）：
.com、.net、.orgなど、国や地域に結びつかない TLD です。2010年代以降に追加された.shop、.app、.tokyoなどは「新 gTLD」と呼ばれます。 - ccTLD（国コードトップレベルドメイン）：
.jp、.uk、.deなど、国や地域ごとに割り当てられた TLD です。登録できる人や組織の条件、管理の規則は、その国や地域の登録管理機関（レジストリ）が決めます。
.jp の場合、example.jp のような汎用 JP ドメインは日本国内に住所を持つ個人・組織が登録でき、example.co.jp のような属性型 JP ドメインは日本で登記した会社などに限られ、1つの組織が登録できる数にも制限があります。このように ccTLD は「誰でも取れる」とは限らず、条件を満たさなくなったときの扱いも TLD ごとに決まっています。
選ぶときに見る4つの軸
1. 誰に向けたサイトか
検索での扱いについて、Google 検索セントラルのドキュメントでは、ccTLD は「その国・地域向けのサイトである」という強い手がかりとして扱われると説明されています。日本の利用者向けのサイトなら .jp は自然な選択ですが、海外にも向けたいサイトでは、gTLD を選んで言語ごとにディレクトリを分け、hreflang で関係を示す構成の方が扱いやすくなります。
一方、.io や .co、.me、.tv のように、国コードでありながら一般的な用途で広く使われている TLD は、Google が国の手がかりとしては扱わない「汎用的な ccTLD」として例示しています。対象の一覧は変わることがあるため、選ぶ前に Google の最新のドキュメントで確かめてください（2026年10月現在）。なお、TLD そのものが検索順位を上げたり下げたりするわけではありません。順位への効果を期待して TLD を選ぶのではなく、利用者にとって分かりやすいかで判断します。
2. 利用者から見た信頼感
利用者は URL を見て、知っている TLD かどうかでリンクを開くか判断することがあります。法人サイトで .co.jp が好まれるのは、登録条件があるため「実在の日本の会社」と伝わりやすいからです。逆に、見慣れない新 gTLD は、メールの受信側のフィルターで厳しく扱われる場合があるという指摘もあります。問い合わせフォームの通知メールや会員登録メールを同じドメインから送るなら、送信ドメイン認証（SPF・DKIM・DMARC）を整えたうえで、届くかを事前に試しておくと安心です。
3. TLD 固有の技術的な条件
.app や .dev など一部の TLD は、TLD 全体がブラウザーの HSTS プリロードリストに登録されており、HTTPS でしか開けません。WordPress を HTTP のまま仮に立ち上げて後から SSL を入れる、という順番が取れないため、最初から証明書を用意する必要があります。また、DNSSEC に対応しているか、日本語ドメイン（IDN）を登録できるかも TLD によって違います。
4. 規則と将来の変化
ccTLD は、その国・地域の方針や情勢の影響を受けます。登録条件の変更や、TLD の扱いそのものが議論になることもあります。海外の ccTLD を選ぶ場合は、レジストリの規約、更新できる期間、名義の条件を取得前に読んでおきます。更新料はレジストラやドメインによって大きく異なり、「プレミアムドメイン」として通常より高く設定されている名前もあるため、取得時の価格だけでなく更新時の条件を確かめてから決めます。
取得後の運用のベストプラクティス
主ドメインを1つに決めて、残りは 301 で転送する
ブランド保護のために .com と .jp の両方を取得するのはよくある方法ですが、両方で同じ内容を表示すると、どちらが正規のサイトか検索エンジンにも利用者にも伝わりにくくなります。主ドメインを1つ決め、それ以外のドメインは主ドメインの同じパスへ 301 で転送します。www の有無も同じ考え方で、どちらかに統一します。
WordPress では「設定」→「一般」の WordPress アドレスとサイトアドレスを主ドメインにそろえ、転送はサーバー側（Web サーバーの設定や .htaccess）で行います。後から主ドメインを変える場合は、投稿内の URL も書き換える必要があり、シリアライズされたデータを壊さないように WP-CLI の wp search-replace などを使います。作業前にはデータベースとファイルのバックアップを取り、まずステージング環境で試してください。
# 置き換え件数だけを確かめる（--dry-run では書き換えない）
wp search-replace 'https://old.example.jp' 'https://example.com' --all-tables --dry-run更新切れを起こさない仕組みにする
ドメインの失効は、サイトとメールが同時に止まる大きな事故です。次の点を取得直後に整えます。
- 自動更新を有効にし、登録している支払い方法の有効期限を確かめる
- レジストラからの連絡先メールを、そのドメイン以外のアドレスにする（失効するとそのドメインのメールも受け取れなくなるため）
- 契約期限を社内の予定表など、担当者が変わっても見える場所に記録する
乗っ取りと誤操作を防ぐ
レジストラのアカウントが乗っ取られると、ネームサーバーを書き換えられてサイトもメールも奪われます。アカウントには二要素認証を設定し、ドメインの移管ロック（レジストラロック）を有効にします。重要なドメインでは、レジストラによっては有料の追加の保護（レジストリロックなど）を提供している場合があります。
DNS 側では、TLD とレジストラが対応していれば DNSSEC で応答の改ざんを検出できるようにし、CAA レコードで証明書を発行できる認証局を限定しておくと、意図しない証明書の発行を防ぐ助けになります。DNSSEC は設定を誤ると名前解決そのものができなくなるため、手順を確かめてから有効にします。
状態を定期的に確かめる
TLD の登録情報は、RDAP や whois で確認できます。期限日、ネームサーバー、ドメインの状態（ロックがかかっているかなど）を、年に数回は見直しておくと、更新漏れや意図しない変更に早く気付けます。
whois example.com | grep -iE 'expir|name server|status'
dig example.com NS +shortwhois の出力の項目名は TLD やレジストラによって異なるため、grep の語は手元の出力に合わせて調整してください。
よくある失敗
- 短期のキャンペーン用に取った TLD を放置する：失効後に第三者が取得し、古いリンクやメールの宛先が悪用されることがあります。不要になっても、リンクが残っている間は更新を続けるか、計画的に手放します。
- ccTLD の登録条件を満たさなくなる：海外法人の撤退や住所の変更で条件を外れると、登録を維持できない場合があります。組織の変更があったら、ドメインの名義も見直します。
- 転送元のドメインで SSL を用意しない：
https://の転送元に証明書が無いと、転送される前に警告が出ます。転送用のドメインにも証明書を用意します。
まとめ
- TLD は「誰に向けたサイトか」で選びます。日本向けなら
.jp系、複数の国に向けるなら gTLD とディレクトリの分け方を考えます。 - ccTLD は国・地域向けの手がかりとして扱われますが、
.ioなどの汎用的な ccTLD は例外とされています。TLD 自体が順位を上げるわけではありません。 .appや.devは HTTPS が前提になるなど、TLD 固有の条件と、更新時の価格・規約を取得前に確かめます。- 主ドメインを1つに決めて他は 301 で転送し、自動更新・連絡先・二要素認証・移管ロックを最初に整えます。