PR 一部リンクは広告・アフィリエイトリンクになる場合があります 詳細

※ 当サイトの一部リンクは、広告・アフィリエイトリンクになる場合があります。 詳細

Web開業・立ち上げ （更新: 2026年10月7日） Web支度室編集部

独自ドメイン取得後にやること — DNS・SSL・公開までの実践手順

独自ドメインを取得したのに、ブラウザでアクセスしても何も表示されない。これは故障ではなく、まだ「ドメインとサイトをつなぐ設定」が済んでいないためです。

この記事では、ドメイン取得後にサイトを公開するまでの作業を順番に整理します。後半では、このサイト（webjitaku.com）で実際に行った流れも紹介します。

ドメインを買っただけではサイトは表示されない

ドメインは、いわばインターネット上の「住所の名前」です。名前を取得しただけでは、その住所にどの建物（サーバー）があるのかが決まっていません。

サイトを表示するには、次の2つが必要です。

  1. サイトのデータを置いて公開する場所（ホスティング）を用意する
  2. 「このドメインにアクセスしたら、そのホスティングにつなぐ」という設定（DNS）を行う

レジストラ・DNS・ホスティングの違い

ドメインまわりでは、似た役割の言葉がいくつも出てきます。最初に整理しておきましょう。

役割していること例
レジストラドメインの登録・更新を受け付けるドメインを購入したサービス
DNSドメイン名を、接続先の情報に変換するレジストラのDNS、Cloudflareなど
ホスティングサイトのデータを置いて配信するレンタルサーバー、Cloudflare Pagesなど

この3つは、同じ事業者がまとめて提供していることもあれば、別々の事業者を組み合わせることもあります。たとえば「ドメインはA社で買い、DNSはB社で管理し、サイトはC社で公開する」という構成も一般的です。

どこで何を管理しているかを把握しておくと、トラブルのときに「どこの設定を見ればいいか」がすぐに分かります。

DNSレコードを確認する

DNSの設定は、「DNSレコード」という単位で管理されています。よく出てくるものは次のとおりです。

レコード主な用途
A / AAAAドメインを接続先のIPアドレスに向ける
CNAMEドメインを別のドメイン名に向ける
MXそのドメイン宛てのメールを受け取るサーバーを指定する
TXTドメインの所有確認や、メールの送信元認証（SPF・DKIM・DMARCなど）に使う

新しく取得したばかりで、まだ何にも使っていないドメインなら、レコードはほとんど設定されていないはずです。一方、すでにメールやほかのサービスで使っているドメインには、大切なレコードが登録されています。作業の前に、まず現在のレコードを一覧で確認しておきましょう。

ネームサーバーを変更する前に確認すること

DNSを別のサービス（たとえばCloudflare）で管理する場合、レジストラ側で「ネームサーバー」を変更します。ネームサーバーを変えると、そのドメインのDNSは新しいサービス側の設定だけが使われるようになります。

そのため、変更前に、今使っているDNSレコードを新しいDNSサービス側へ漏れなく用意しておく必要があります。特に注意したいのはメール関連のレコードです。

  • MX — メールの受信先。これが抜けると、メールが届かなくなるおそれがあります
  • TXT（SPF） — 送信元として正当なサーバーを示すレコード
  • DKIM — 送信メールの電子署名を確認するためのレコード（TXTやCNAMEで設定）
  • DMARC — 送信元認証に失敗したメールの扱いを示すレコード

これらを落とすと、メールが届かない、送ったメールが迷惑メール扱いされる、といった障害につながる可能性があります。Cloudflareの公式ドキュメントでも、ネームサーバー変更前のDNSレコードの確認で、ゾーン頂点（wwwなしのドメイン）、www などのサブドメインに加え、メール関連のレコード（MX、SPF、DKIM、DMARC）に特に注意するよう案内しています（Cloudflare公式：フルセットアップ、2026-10-07確認）。

もうひとつ、DNSSECが有効になっている場合も注意が必要です。Cloudflareの公式ドキュメントは、DNSSECが有効なままネームサーバーを変更するとドメインに到達できなくなるおそれがあるとして、変更前にレジストラ側でDNSSECを無効にするよう案内しています（Cloudflare公式：DNSSEC、2026-10-07確認）。

Cloudflare等へDNSを委任する

Cloudflareを例にすると、流れは次のとおりです（Cloudflare公式：フルセットアップ）。

  1. Cloudflareにドメインを追加し、プランを選ぶ
  2. 既存のDNSレコードを取り込み・確認する
  3. Cloudflareが割り当てたネームサーバーを確認する
  4. レジストラの管理画面で、ネームサーバーをCloudflareのものに変更する
  5. Cloudflare上でドメインが有効（Active）になるのを待つ

ネームサーバーの変更は、すぐに反映されるとは限りません。Cloudflareの公式ドキュメントでは「レジストラがネームサーバーを更新する間、最大24時間待つ」よう案内されています。割り当てられたネームサーバー名は、1文字でも間違えると名前解決できなくなるため、コピーして正確に入力しましょう。

ホスティングと接続する

DNSの準備ができたら、ホスティング側でドメインを接続します。手順はホスティングによって異なります。

Cloudflare Pagesの場合、ホスティング側（Pagesプロジェクト）でカスタムドメインを追加します。公式ドキュメントによると、wwwなしのドメイン（apexドメイン）を使うには、そのドメインがPagesプロジェクトと同じCloudflareアカウント上のゾーンになっている、つまりネームサーバーがCloudflareを向いている必要があります（Cloudflare公式：Pagesのカスタムドメイン、2026-10-07確認）。

また同じドキュメントでは、Pagesのダッシュボードでドメインを関連付けないまま、手動でCNAMEレコードだけを追加すると、ドメインが正しく解決されないと注意しています。DNSレコードを先に手で作るのではなく、ホスティング側の手順に沿って接続するのが基本です。

SSL発行を確認する

接続が済んだら、https:// で表示されるかを確認します。最近のホスティングでは、ドメインを接続すると証明書が自動で発行されるものが多くあります。

確認したいポイントは次のとおりです。

  • ホスティングの管理画面で、ドメインの状態が有効（Active など）になっているか
  • https:// でアクセスして、ブラウザに警告が出ないか
  • http:// でアクセスしたときに、https:// へ転送されるか

証明書の発行には時間がかかることがあります。また、Cloudflare Pagesの公式ドキュメントでは、ドメインにCAAレコード（証明書を発行できる認証局を制限する設定）があり、Cloudflareが利用する認証局を許可していない場合に問題が起きると注意しています。CAAレコードを設定している場合は、内容を確認しておきましょう。

apexとwww

example.com（apex、wwwなし）と www.example.com（wwwあり）は、DNS上は別の名前です。片方だけを設定した場合、もう片方ではサイトが表示されません。

  • どちらを正式なアドレスにするかを決める
  • もう片方も使えるようにする場合は、正式なアドレスへ301リダイレクトする

Cloudflare Pagesの場合、公式ドキュメントでは www からapexへのリダイレクトにBulk Redirectsを使う方法が紹介されています（Cloudflare公式：wwwのリダイレクト、2026-10-07確認）。

名刺や印刷物などで www 付きのアドレスを使う予定があるなら、www 側の設定も忘れずに行いましょう。

canonical

同じ内容のページが複数のURLで表示できる状態だと、検索エンジンがどのURLを正式なものとして扱うかが分かれることがあります。たとえば、ホスティングサービスのURL（〇〇.pages.dev など）と独自ドメインの両方でサイトが表示される場合です。

そこで、各ページの <head> に rel="canonical" を設定し、正式なURLを示します。Googleの公式ドキュメントでは、rel="canonical" は正規URLを示す強いシグナルである一方、絶対的な指示ではないこと、またリダイレクトは転送先を正規ページとする強いシグナルになることが説明されています（Google 検索セントラル：重複するURLの統合、2026-10-07確認）。

公開後は、実際のページのHTMLを開き、canonicalが独自ドメインのURLになっているかを確認しておきましょう。

DNSSEC

DNSSECは、DNSの応答が改ざんされていないことを確認できるようにする仕組みです。Cloudflareの公式ドキュメントでは、偽のドメインへ誘導されることを防ぐための追加の認証層と説明されています（Cloudflare公式：DNSSEC）。

有効にするには、DNSサービス側でDNSSECを有効にしたうえで、表示されたDSレコードをレジストラに登録します。DNSサービスとレジストラの両方で設定が必要なので、どちらか片方だけの設定や、設定の食い違いがあると名前解決の障害につながるおそれがあります。

DNSSECは「最初から必ずONにしなければいけないもの」ではありません。ネームサーバーの変更やサイトの接続が落ち着いてから、別の作業として有効化する進め方もあります。いずれの場合も、今後ネームサーバーを変える予定があるときは、先にDNSSECの扱いを確認してください。

Web支度室の実例

このサイト（webjitaku.com）で実際に行った流れです。作業はいずれも2026年10月7日（日本時間）に行いました。

  1. ドメインを取得：XServerで webjitaku.com を取得（自動更新ON、Whois情報の代理公開ON）
  2. Cloudflareに追加：CloudflareにFree planでドメインを追加。新規取得したドメインで、メールなど既存の用途がなかったため、この時点のDNSレコードは0件
  3. ネームサーバーを委任：XServer側のネームサーバーを、Cloudflareが割り当てた2つのネームサーバーに変更。変更直後のCloudflare上のステータスは「Pending（保留中）」で、その後「Active」になったことを確認
  4. DNSレコードはまだ作らない：Activeになった段階でも、サイト用のDNSレコードは手で追加せず、ホスティング側の接続を待った
  5. Pagesで公開：GitHubのリポジトリと接続したCloudflare Pagesプロジェクトを作成し、まずPagesのURL（〇〇.pages.dev）で表示を確認
  6. カスタムドメインを接続：Pagesプロジェクトに webjitaku.com（apex）を追加。Cloudflareが自動で作成したDNSレコードは、apexからPagesのURLへ向けるCNAMEレコード1件のみ
  7. SSLを確認：カスタムドメインの状態がActiveになり、https://webjitaku.com/ が正常に表示されること、http:// からは https:// へ301リダイレクトされることを確認
  8. canonicalを確認：独自ドメインでも、PagesのURLでも、ページのcanonicalが https://webjitaku.com/ を指していることを確認

2026年10月7日時点で、次の項目はまだ設定していません。

  • www：www.webjitaku.com は未設定です（wwwありのアドレスは名前解決されません）。
  • DNSSEC：ネームサーバーの委任とサイトの接続が安定してから、別の作業として有効化を検討する方針で、現時点では無効のままです。
  • メール：webjitaku.com ではメールを使っていないため、MXなどのメール用レコードはありません。

既存のメールがある本番ドメインで同じ作業をする場合は、手順3の前に、メール用のレコードを新しいDNS側へ用意する作業が加わります。その確認項目はDNS・ネームサーバー移行のチェックリストにまとめています。

関連記事

この記事の確認方法

確認日：2026-10-07

Web支度室で実際に確認したこと

  • webjitaku.com の取得、Cloudflareへの追加、ネームサーバーの委任とActiveへの変化、Pagesでの公開、カスタムドメインの接続と作成されたDNSレコード（作業記録による）
  • https://webjitaku.com/ の表示、http:// から https:// への301リダイレクト、canonicalの値、www が未設定であること、MXレコードがないこと（公開後の実際のアクセスとDNS照会による）

公式情報で確認したこと

編集上の判断

  • 作業の順番（現在のレコード確認→DNS委任→ホスティング接続→SSL確認→www・canonicalの確認）は、上記の実例と公式情報をもとにしたWeb支度室編集部の整理です。
  • DNSSECを「最初から必須」とせず、接続が安定してから別作業として検討する進め方は、Web支度室での判断です。必要性はドメインの用途によって異なります。
  • ネームサーバー名やアカウント情報など、読者の作業に不要な固有情報は掲載していません。

関連記事

Web開業・立ち上げ

GA4・Search Consoleの初期設定チェックリスト — 公開直後に確認すること

GA4とSearch Consoleを「設定したつもり」で終わらせないためのチェックリスト。測定IDの設置、計測リクエスト、リアルタイムでの受信、イベントとキーイベントの違い、プレビューの混入防止、サイトマップとURL検査、公開当日・24時間後・7日後の確認項目を、公式情報とMovanceの運用例で整理します。