WordPressのドメイン設定徹底解説｜取得・紐付け・SSL・DNSまで初心者向けに整理

WordPressでサイトを始めようと思ったとき、最初にぶつかりやすいのが「ドメイン設定」です。
やりたいことはシンプルなのに、用語や設定画面が多くて、こんな声になりがちです。

「独自ドメインって、どこで取るのが正解？ 更新費も気になる…」
「サーバーとドメインって何が違うの？ DNSって結局なに？」
「設定したのにサイトが表示されない／人によって見え方が違う」
「httpsにしたのに鍵マークが出ない。混在コンテンツって何？」
「wwwあり／なしはどっちがいい？ 途中で変えたらSEOに悪い？」
「既存サイトのドメインを変えたいけど、順位が落ちないか怖い…」
「WordPress.comと自前サーバー（WordPress.org）で手順が違って混乱する」

ドメインは“住所”なので、一度つまずくと ログインできない・表示されない・メールが届かないなど、影響が大きくなります。
でも逆に言うと、ポイントさえ押さえれば、初心者でも安全に進められます。

この記事では、公式ドキュメントで示されている基本を土台にしつつ、現場で事故が起きやすい部分（URL設定、DNS、SSL、正規化、移行時の301など）を、手順とチェックリストでわかりやすく整理します。

この記事でわかること

• 独自ドメインの選び方（信頼・運用・更新コストの考え方）
• 取得したドメインをWordPressに紐付ける最短手順（DNSの要点だけ）
• SSL（https化）と、鍵マークが出ないときの典型原因
• www有無・末尾スラッシュなど、正規URLを揃えるコツ
• ドメイン変更・移行の流れ（SEOを守る設計と、移行後の確認）

「何を、どの順番でやればいいか」が一発でわかる構成にしているので、必要な章だけ拾い読みでもOKです。
迷ったときに戻れる“地図”として、ぜひ活用してください。

【おすすめ独自ドメイン取得サービス↓】

お名前.com公式サイト
ムームードメイン公式サイト
XServerドメイン公式サイト
シンドメイン公式サイト
スタードメイン公式サイト

ラッコドメイン公式サイト

最初に結論：あなたの状況別に「やること」が一発でわかる

まずは「いま何をしたいか」で、手順も注意点もガラッと変わります。
下の表で、自分のルートを決めてから進めるのが最短です。

あなたの状況	やること（最短）	失敗しやすい点	影響が出やすいもの
新規で独自ドメインを使う	ドメイン取得 → DNS設定 → サーバー設定 → SSL → WordPress設定	DNSの設定先ミス／SSL未設定	表示・メール・安全性
いまのサイトのドメイン変更	新ドメイン準備 → WordPress側URL更新 → 301リダイレクト → 検索系設定	301漏れ／URL置換の不備	SEO・アクセス
サーバー移転だけ（ドメイン同じ）	新サーバー移行 → 動作確認 → DNS切替	DNS切替タイミング／メール設定	表示・メール
WordPress.comで切替	ドメイン追加/接続 → 主要アドレス設定	「サイトアドレス変更」と混同	リンク・表示

新規で独自ドメインを使ってWordPressを始めたい（最短ルート）

初心者の最短ルートは、「ドメイン → DNS → サーバー → SSL → WordPress」の順です。
逆順にすると、原因切り分けが難しくなります。

やることチェックリスト（この順が安全）

• ✅ ドメインを取得する（更新の自動化まで設定）
• ✅ DNSを設定して、サーバーに向ける
  • “ネームサーバーを変える”方式か、“DNSレコードを編集する”方式かを確認
• ✅ サーバー側でドメインを追加し、公開先（フォルダ）を決める
• ✅ 無料SSLを有効化して https に統一する
• ✅ WordPressをインストール（または紐付け）し、表示確認

つまずきやすいポイント

• DNSが反映されない：反映（伝播）には時間がかかることがあります。慌てて設定を何度も変えると迷子になりがちです。
• SSLが有効なのに鍵が出ない：画像などが http のまま混在していることがあります。
• 「WordPressのURL設定」を早い段階で触る：設定箇所を誤ると管理画面に入れなくなることがあります（後述の“変更ルート”で扱う内容）。

費用の目安（ざっくり把握）

• 独自ドメインは、種類（.com / .jp など）と会社で幅があります。
  例として、ムームードメインでは .com の新規取得が年770円、更新が年1,728円の表示があります（キャンペーン等で変動あり）。また .jp の新規取得が年990円、更新が年3,344円の表示があります。
• 「初年度が安い」より、更新費（2年目以降）まで見て選ぶと失敗しにくいです。
• サーバー会社によっては “サーバー契約中はドメイン取得・更新が無料”の特典がある一方、継続条件が付くことがあります。申し込み条件を必ず確認してください。

いまのサイトのドメインを変えたい（順位を守る移行ルート）

ドメイン変更は、SEO的には「引っ越し」です。
成功のカギは “旧URL→新URLを漏れなく301でつなぐ”ことと、移行後の監視です。

やることチェックリスト（順位を守る基本）

• ✅ 事前準備
  • サイトのフルバックアップ（ファイル＋DB）
  • 主要ページ（上位表示ページ・被リンクが多いページ）をメモ
• ✅ 新ドメインを用意（DNS/SSL/サーバー設定まで整える）
• ✅ WordPress側のURLを更新（方法は環境で変わる）
• ✅ サイト内の旧ドメイン表記を置換（画像URL・内部リンク・埋め込みを含む）
• ✅ 301リダイレクトを全ページ分設定（旧→新を1回で到達できる形が理想）
• ✅ 移行後にチェック
  • 404が出ていないか
  • 表示崩れ・画像抜けがないか
  • Search Console等でクロール/インデックスを監視

初心者が特に注意すべき“2つの罠”

• 301が「トップだけ」になっている
  旧サイトの各ページが、新サイトの対応ページへ正しく飛ぶ必要があります。トップへ一律転送は損失が出やすいです。
• データベース置換でサイトが壊れる
  WordPressは保存形式の都合で、単純な文字置換が危険なケースがあります。安全な手順（専用ツールや適切な置換手順）で行うのが無難です。

運用面の注意

• 旧ドメインは、しばらく維持してください（少なくともリダイレクトが必要な間）。
  更新忘れ対策として、自動更新・支払い期限の通知・ドメインロックも一緒に見直すと安心です。

サーバー移転だけしたい（ドメインは変えない）

このケースは、ドメイン変更より安全で、SEOリスクも小さめです。
やることは 「中身だけ新居へ」「住所（ドメイン）はそのまま」のイメージです。

やることチェックリスト（事故を減らす順番）

• ✅ 新サーバーへサイトを移す（ファイル＋DB）
• ✅ 新サーバー側で動作確認（テストURLやhosts等を使えると理想）
• ✅ 画像・フォーム・メール送信（お問い合わせ）まで確認
• ✅ DNSを新サーバーに切り替える（切替前後で確認）
• ✅ SSL（https）設定を新サーバー側で有効化

つまずきやすいポイント

• DNS切替直後に「見える人／見えない人」が出る
  反映のタイムラグが原因のことがあります。切替のタイミングは余裕を持つのが安全です。
• メールが止まる
  ドメインでメールを運用している場合、MXなどのDNSレコードも関係します。
  Webだけ移して「メール設定を置き去り」にしがちなので要注意です。

最低限のゴール

• ブラウザで表示できる
• 管理画面に入れる
• SSLが有効（httpsで統一）
• お問い合わせなどの送信が通る

WordPress.comでドメインを切り替えたい（主要アドレスの考え方）

WordPress.comは、一般的な「自前サーバーのWordPress」と発想が少し違います。
ポイントは “主要アドレス（Primary）”をどれにするかです。

まず混同しやすい2つを整理

• 独自ドメインを使う（おすすめ）：例）example.com を接続して、表示をそのドメインに統一
• WordPress.comのサイトアドレスを変更する：例）example.wordpress.com の“文字列”を変える
  → これをやると、古いアドレスへのリンクが切れる可能性があるので注意が必要です。

やることチェックリスト（WordPress.comの基本）

• ✅ ドメインを用意する方法を選ぶ
  • WordPress.comで新規登録する
  • すでに持っているドメインを接続する（“マッピング”）
• ✅ ドメインを追加したら、主要アドレスとして設定する
  • 主要アドレスにしたドメインが、訪問者に見える“正面玄関”になります
• ✅ 表示確認（https・www有無・リダイレクト挙動）
• ✅ 必要に応じてメール（ドメインメール）も検討

費用まわりの考え方（初心者向け）

• WordPress.comでは、ドメイン接続（マッピング）は有料プランで利用できると案内されています。
• 年間プランの購入で、1年間の無料ドメインクレジットが付くケースがあります（条件の確認が大切です）。

「ドメイン／URL／サーバー」基礎を3分で整理

WordPressで独自ドメインを扱うとき、つまずきの原因はたいてい「用語の混同」です。
ここでは ドメイン・URL・サーバーの役割を整理し、後の設定作業がスムーズになる土台を作ります。

ドメインとは何か：DNSとセットで理解すると失敗が減る

ドメインは、ざっくり言うと「サイトの住所（文字列）」です。
でも、ドメイン単体ではWebサイトにたどり着けません。そこで必要になるのが DNS です。

• ドメイン：人間が覚えやすい住所（例：example.com）
• IPアドレス：サーバーの場所を示す番号（例：192.0.2.1 のような形式）
• DNS：ドメインをIPアドレスに変換する仕組み（“住所録”の役割）

つまり、あなたがブラウザにドメインを入れたとき、裏側ではこう動きます。

1. ブラウザがDNSに「このドメインの行き先（IP）は？」と問い合わせる
2. DNSが「このサーバーだよ」と返す
3. ブラウザがそのサーバーにアクセスしてページを表示する

DNSでよく出てくるレコード（最低限これだけ）

DNSの設定画面でよく見るのが「レコード」です。初心者はまず、次の意味だけ押さえればOKです。

種類	役割	よくある用途
A	ドメイン → IPv4アドレス	サイトの“行き先”をIPで指定
AAAA	ドメイン → IPv6アドレス	IPv6対応の行き先指定
CNAME	別のドメイン名へ“別名”として紐付け	www を本体ドメインへ向ける等
MX	メールの行き先	ドメインメールを使うときに重要
TXT	追加情報のメモ欄（認証など）	SPF/DKIM/所有確認など

ポイント
Webサイトだけ動けばOK、と思っていると、あとで「メールが届かない」などが起きがちです。
ドメインでメールも使う予定なら、DNSはWeb以外にも影響すると覚えておくと安心です。

URLの構造：プロトコル（http/https）・www・パスの役割

URLは、Web上の“住所の書き方”です。ドメインはURLの一部に含まれます。

例：https://www.example.com/blog/article?x=1#top

URLは主に次のパーツでできています。

• プロトコル：http / https
  • https は通信を暗号化します。今は基本的に httpsを標準にする前提です。
• ホスト名（ドメイン部分）：www.example.com
  • www はサブドメインの一種（あとで説明）
• パス：/blog/article
  • サイト内の“どのページか”を指定します
• （必要に応じて）クエリ：?x=1
• （必要に応じて）フラグメント：#top

www は“付けても付けなくてもいい”が、統一が大事

www.example.com と example.com は見た目が似ていますが、技術的には 別のホスト名です。
どちらを使うにせよ、最終的に表示されるURLは どちらか一方に統一するのが基本です。

サブドメインとサブディレクトリ：どっちを選ぶべき？

同じ「ブログ」でも、置き方は2種類あります。

• サブドメイン：blog.example.com
• サブディレクトリ：example.com/blog/

どちらが正解、というより 目的と運用で決めるのが失敗しにくいです。

迷ったら：基本はサブディレクトリが無難

WordPress初心者の場合、サイトを分断しないほうが管理がラクなので、まずはサブディレクトリが扱いやすいことが多いです。

選び方の早見表

観点	サブドメイン	サブディレクトリ
運用の分離	分けやすい（別サイト感）	分けにくい（同一サイト感）
WordPress構成	別インストールになりがち	同一インストールで管理しやすい
計測・設定の手間	個別に設定が増えやすい	まとめやすい
向いている例	サポート、店舗検索、別システムの管理画面	ブログ、コラム、サービス紹介

現実的な判断基準

• 「中身も運用担当も別」ならサブドメイン
• 「同じ目的で育てるコンテンツ」ならサブディレクトリ

正規URLを揃える重要性（www有無・末尾スラッシュ・https統一）

WordPress運用で見落とされがちなのが URLの“表記ゆれ”です。
同じページが複数URLで見えてしまうと、検索エンジンやSNS・解析の面で損をすることがあります。

代表的な“重複パターン”

• http://example.com と https://example.com
• https://example.com と https://www.example.com
• https://example.com/page と https://example.com/page/（末尾スラッシュ有無）

末尾スラッシュは「見た目がちょっと違うだけ」に見えますが、URLとしては別物として扱われるケースがあります。
そのため、サイト全体で どちらの形式にするかを決めて統一するのが安全です。

正規URLを揃える実務的なやり方（初心者向け）

難しいことを全部やる必要はありません。優先順位はこれだけでOKです。

1. https に統一する（http→httpsは転送）
2. wwwあり／なし を決める（片方に転送）
3. 末尾スラッシュのルールを決める（混在させない）

補足として、検索エンジンには「このURLが正です」と伝える仕組み（canonicalなど）もありますが、初心者はまず 転送（リダイレクト）で揃えると理解しやすいです。

WordPressの2つのURL設定がややこしい理由

WordPressには、URLに関する設定が2つあります。
ここを誤ると、表示はできても管理画面に入れないなどの事故が起きやすいので、意味をセットで覚えるのがコツです。

「WordPressアドレス」と「サイトアドレス」の違い

• WordPressアドレス（URL）
  WordPress本体（コアファイル）が置かれている場所のURL
• サイトアドレス（URL）
  訪問者がアクセスする、表のURL（サイトの入口のURL）

多くのサイトはこの2つが同じですが、次のようなケースでは異なります。

• WordPress本体は example.com/wp に置きつつ
  サイトは example.com で見せたい（よくある）

このとき、2つのURLを“何となく同じにする”と崩れやすいです。
自分の構成がどれに当たるかを先に決めてから入力するのが安全です。

ここを間違えると起きる典型トラブル（管理画面に入れない等）

初心者が遭遇しやすいのは次のパターンです。

• 管理画面にアクセスすると 別URLへ飛ばされ続ける（ログインループ）
• 「ページが見つかりません」になって サイトも管理画面も開けない
• リダイレクトが多すぎます と表示される
• 画像やCSSだけ読み込めず、表示が崩れる（URL混在が原因のことも）

重要な注意点
URL設定を変更する前に、必ず次を用意してください。

• バックアップ（最低でもDB）
• いまの正しいURLのメモ
• できれば復旧手段（サーバーにログインできる状態）

「設定を変えたら入れなくなった…」は珍しくありません。
不安がある場合は、まず テスト環境で試すのが堅実です。

WordPressのタイプで手順が変わる：まずここを判定

「WordPressで独自ドメインを使う」と言っても、運用タイプによって 設定画面・できること・注意点が変わります。
先にタイプを判定すると、ムダな作業やトラブルを避けやすいです。

まずは3つの質問で判定する

1. サーバーを自分で契約していますか？
   • 例：レンタルサーバー会社（Xserverなど）と契約している → 自前サーバーの可能性が高い
2. ドメインのDNS（レコード）をどこで管理していますか？
   • ドメイン会社（レジストラ）やサーバー会社のDNS画面 → 自前サーバー寄り
   • WordPress.comの管理画面でDNSを編集できる → WordPress.com寄り
3. サイトの管理画面に入る導線はどこですか？
   • あなたのドメイン/wp-admin にログイン → 自前サーバーが多い
   • WordPress.comのダッシュボード（アップグレード→ドメイン等）中心 → WordPress.comが多い

不安なら、下の表でざっくり整理すると迷いが減ります。

比較ポイント	自前サーバー（WordPress.org）	WordPress.com
サーバー	自分で契約・管理	WordPress.com側が提供
ドメイン更新	レジストラで更新（自分で管理）	WordPress.comで取得した場合はWordPress.com側で更新（プラン/契約次第）
DNS設定	レジストラ or サーバー側で行うことが多い	WordPress.comの管理画面でDNS管理になるケースが多い
変更時の作業	自分でDNS/サーバー/WordPress設定/リダイレクトを触る	「ドメイン追加」「主要アドレス設定」が中心

自前サーバー（WordPress.org）で運用している場合

自前サーバーは「自由度が高い」反面、作業範囲が広いのが特徴です。
ドメイン設定は基本的に、次の3か所を触る可能性があります。

1) ドメイン側（レジストラ）

• ネームサーバー設定（DNSをどこで管理するか）
• DNSレコード（A / CNAME など）

2) サーバー側

• ドメイン追加（このドメインで公開する、という登録）
• SSL（https化）
• 301リダイレクト（www有無、http→https、ドメイン変更時の転送など）

3) WordPress側

• 「WordPressアドレス」「サイトアドレス」の設定
• 内部リンクや画像URLの整合性

初心者が覚えるべき要点（ここだけで事故が減る）

• DNS＝“行き先の指定”、サーバー＝“受け皿”、WordPress＝“サイトの中身”
  → この3つが揃って初めて表示されます。
• URLを変える作業は、うっかりすると 管理画面に入れなくなることがあります。
  変更前にバックアップと復旧手段（サーバーにログインできる状態）を必ず用意してください。

WordPress.comで運用している場合

WordPress.comは、独自ドメインの取り扱いが「WordPress.comの管理画面中心」になります。
特に重要なのは次の2点です。

• 独自ドメインを接続すると、.wordpress.com の初期アドレスは新しい独自ドメインへ自動的に誘導（転送）される
• 接続したドメインのDNS設定は、WordPress.com側の画面で管理する運用になるケースがある

また、独自ドメインの接続（いわゆる“ドメインマッピング”）は、有料プランで利用できるという整理が基本です。
（プラン名や料金は変わることがあるので、作業前に公式の最新案内を確認してください）

「主要アドレス（Primary）」を設定する考え方

WordPress.comでは「どのドメインを正面玄関にするか」を 主要アドレスで決めます。

• 主要アドレス＝訪問者のブラウザのアドレスバーに最終的に表示される“正”のURL
• 主要ではないドメイン＝主要アドレスへ転送される（表記ゆれや打ち間違い対策に便利）

なぜ重要か？

• SEO的にも、アクセス解析的にも、URLがブレると不利になりがちです。
  主要アドレスを決めて統一しておくと、混乱が減ります。

よくある誤解

• 「ドメイン名は編集して直せる」→ 基本的にできません。
  変更したい場合は 新しいドメインを追加して、主要アドレスを切り替えるのが王道です。

複数ドメイン運用／www版の扱い

WordPress.comは、1つのサイトに対して 複数のドメインを追加できます。
ただし「同じ内容を別ドメインで“別サイトとして見せる”」というより、基本は 主要アドレスへ集約（転送）する使い方が中心です。

複数ドメインを持つメリット例

• よくあるスペルミスのドメインも追加しておき、主要アドレスへ誘導する
• 旧ドメインを残しておき、新ドメインへ自然に移行させる（告知期間の確保）

www版の考え方

• wwwあり と wwwなし は別のホスト名なので、混在させず 最終的にどちらかに寄せるのが安全です。
• WordPress.comでは、主要アドレスを決めることで「最終的に表示される形」を揃えやすくなります。

どちらにも共通する事前準備（バックアップ／作業時間／告知）

タイプが違っても、ドメイン関連作業は“戻せない事故”が起きやすい領域です。
以下を先に押さえておくと、初心者でも安全に進められます。

バックアップ（必須）

• ✅ 自前サーバー：
  • データベース（記事・設定）
  • wp-content（画像・テーマ・プラグイン）
  • できれば「復元手順」もメモ
• ✅ WordPress.com：
  • 最低でも エクスポート（記事/固定ページ/メディアの範囲は要確認）
  • プラン機能としてバックアップがある場合も、作業前に状態を確認

作業時間の確保（焦りが最大の敵）

• DNS反映には時間がかかることがあるため、余裕のある時間帯に行う
• できればアクセスが少ない時間に実施
• 途中で設定を何度も変えない（原因切り分けが難しくなる）

告知（ドメイン変更・移行がある場合）

• ✅ サイト内の告知（バナーやお知らせ）
• ✅ SNSやメルマガなど外部チャネルの案内
• ✅ 重要なリンク元（提携先・プロフィール・名刺QRなど）の更新

特にドメイン変更は、技術作業だけでなく「周知」も成功の一部です。
早めに告知設計まで含めて進めると、移行後の混乱が減ります。

失敗しないドメイン選び：SEOより「信頼」と「運用」を優先する

「WordPressのドメイン選び」は、SEOテクニックというより “長期運用の設計” です。
あとから変えるほど移行コストが上がり、失敗するとアクセスも信用も落ちます。だから最初に「信頼されやすい名前」「運用しやすい契約」を決めるのが近道です。

ドメイン名の決め方：短い・読める・間違えにくい

最優先の基準は「口頭で伝わるか」

SNSや名刺、営業資料などで、ドメインは意外と“声”で伝わります。
次の条件を満たすほど、ミスと機会損失が減ります。

• 短い（覚えやすい）
• 読める（ローマ字・英単語が自然）
• 打ち間違えにくい（似た綴り・紛らわしい文字を避ける）
• 書きやすい（ハイフン多用は基本不利）
• 説明が不要（「これって何のサイト？」が名前から伝わる）

ありがちな落とし穴チェック

• 数字： “0（ゼロ）” と “O（オー）”、 “1” と “l” が混ざると事故りやすい
• ハイフン：1つまでは許容でも、複数は口頭説明が長くなりがち
• 略語：業界外の人には意味不明になりやすい（E-E-A-Tの「信頼」面で損）
• 流行語：数年で古くなる可能性がある（長期運用に不利）

迷ったら「ブランド寄り」か「テーマ寄り」かで決める

• ブランド寄り：将来ジャンルを広げても違和感が出にくい
• テーマ寄り：初期の分かりやすさは強いが、後で拡張すると窮屈になりやすい

結論：SEO目的でキーワードを詰め込むより、“覚えやすい固有名” の方が長期で有利になりやすいです（指名検索・被リンク・引用が増えやすい）。

TLDの選び方：.com / .jp / 汎用JPなどを目的別に整理

まず前提：TLDで順位が決まるわけではない

「.comだから上がる」「.jpだから強い」という単純な話ではありません。
ただし、国や利用者の認識、そして 制約（取得資格・運用ルール） が違うため、結果として“クリックされやすさ・信用・運用”に差が出ます。

目的別のおすすめ（迷ったらここ）

• 国内向けの個人ブログ／小規模サイト
  • 候補：.com または .jp（汎用JP）
  • 判断軸：ブランド感（.com）／日本向けの分かりやすさ（.jp）
• 日本の法人・団体で「公式感」を最優先
  • 候補：.co.jp（企業）や .or.jp（法人）など
  • ただし、取得条件・制限があるので要確認
• 将来、海外も視野に入る／多言語展開の可能性がある
  • 候補：.com（＋言語別はディレクトリ運用などが無難）
  • 国ごとにドメインを分ける設計は強い反面、運用負荷が上がります

ざっくり比較表（初心者向け）

種類	向いているケース	強み	注意点
.com	万人向け	認知が高い／汎用的	競争が激しく希望名が取りづらいことも
.jp（汎用JP）	日本向け中心	日本サイトと伝わりやすい	取得条件（国内住所など）がある
.co.jp等（属性型JP）	日本の法人の公式サイト	信用が取りやすい	原則「1組織1ドメイン」など制約が強い
新gTLD（.blog等）	コンセプト重視	意味が伝わる	更新費が高い場合がある／相手によっては警戒される

ブランド・商標・個人情報の注意点（WHOIS／公開代行）

商標は「あとから気づく」のが一番危ない

ドメインは早い者勝ちですが、商標や商号に抵触するとトラブルになります。
最低限これだけはやっておくと安全度が上がります。

• 候補名を 商標検索（読みも含めて）
• 同業・近いサービス名に“寄せすぎない”
• 「公式っぽく見える誤認」を誘う命名を避ける
• 将来、法人化やサービス化するなら 先に商標取得も検討

JPドメインは紛争処理の仕組みがある

「他人の権利を侵害する目的」や「誤認を狙う使い方」だと、手続きで移転・取消の対象になり得ます。
安易に“有名サービス名に似せたドメイン”は避けるのが無難です。

WHOIS公開とプライバシー対策

ドメインには登録者情報（WHOIS）が紐づきます。個人運営なら、次の対策がほぼ必須です。

• WHOISの代理公開（公開代行） を使う
• 申込みのタイミングで 無料/有料が変わることがある（会社ごとに条件が違う）
• “代理公開しても連絡が完全に遮断されるわけではない”こともある（問い合わせ窓口経由など）

目安：個人サイトは「代理公開＋ドメインロック＋二段階認証（可能なら）」までセットで考えると安全です。

長期運用で差が出るポイント（更新費・移管しやすさ・管理画面）

初年度の安さより「3点セット」を見る

ドメイン費用は、ざっくりこの3つが基本です。

• 取得費（初回）
• 更新費（毎年／複数年）
• 移管費（引っ越しするとき）

さらに、以下が地味に効きます。

• WHOIS代理公開の料金体系（無料条件の有無）
• 価格調整費の有無（請求時に上乗せされる仕組みがある会社も）
• 管理画面の分かりやすさ（DNS編集が迷路だと事故る）
• セキュリティ（2FA、ドメインロック、認証コードの扱い）
• サポート（チャット/電話、営業時間）

参考：料金の見方（比較のコツ）

• “最安0円”はキャンペーンであることが多い
• 更新費が高いと、3〜5年で逆転することがある
• 「サーバー契約中はドメイン無料」系は、解約時の扱いを必ず確認する

「サーバーと同一会社で契約」するメリット／デメリット

メリット

• 管理画面が一つになりやすい（更新漏れ・設定ミスが減る）
• WordPress導入が簡単（DNSのテンプレや自動設定があることが多い）
• サポートが一本化（たらい回しが減る）
• セット割や「ドメイン無料」特典が付く場合がある

デメリット

• 将来の乗り換えで“心理的ハードル”が上がる（移管を先延ばししがち）
• セット特典前提だと、解約時にコストが跳ねる可能性
• 障害・アカウント凍結などの影響範囲が広くなる（全部止まるリスク）

別会社運用で詰まりやすいポイント（DNS／サポート分断）

別会社運用は悪ではなく、むしろ“プロ寄りの安定運用”にもなります。
ただし初心者が詰まりやすいポイントが決まっています。

詰まりポイント

• DNSの向き先が分からなくなる（A/CNAME/MXの意味が曖昧なまま触る）
• wwwあり/なし、https の統一で混乱する
• 「サーバー側は正常です」「ドメイン側の設定です」とサポートが分断される

回避策（初心者向けテンプレ）

• DNSの作業前に、必ずメモ：
  • 現在のネームサーバー
  • 主要レコード（A / CNAME / MX）
  • TTL（切替時は短くするのが定石）
• 変更は一気にやらず、“1変更→確認” を徹底
• メールを使っているなら、MXレコードは最重要（サイトより事故が痛い）

独自ドメインを取得してWordPressに紐付ける手順（新規向け）

ここでは「独自ドメインを新規取得 → 自前サーバーのWordPress（WordPress.org）で公開」までを、初心者でも迷いにくい順番でまとめます。
（WordPress.comの場合も近い工程がありますが、DNSやSSLの触り方が一部違います。該当しそうな箇所は補足を入れます。）

ステップ0：必要情報を揃える（サイト名／メール／サーバー）

最初に“決めること”を先に揃えると、設定ミスが激減します。

事前に用意・決定するもの

• サイト名（後で変えられるが、ドメイン候補に影響）
• 連絡用メール（ドメイン更新通知が届くメール）
• サーバー契約情報（サーバー名、サーバーIP、初期ドメインなど）
• ドメインの最終形（後で統一するために先に決める）
  • https にする
  • www あり／なし
  • 末尾スラッシュの方針（基本はWordPressに任せればOKだが、混在させない）

初心者が見落としがちな重要ポイント

• ドメインの登録メールは、普段使うメールにする（退職アドレスや捨てアドレスは危険）
• ドメインでメール運用する予定があるなら、最初に方針決め（後でDNSを触り直すと事故りやすい）

ステップ1：ドメインを取得する（更新設定・自動更新・ロック）

ドメイン取得は「買って終わり」ではなく、失効させない仕組み作りが本番です。

購入前チェック（ここを押さえると後悔しにくい）

• 初年度だけでなく、更新費が許容範囲か
• 「サービス維持調整費」など、表示金額に上乗せ要素があるか
• WHOISの代理公開（公開代行）が利用できるか（個人運用なら重要）
• 2段階認証やドメインロックなどのセキュリティ設定があるか
• 将来移管（引っ越し）したいときに手間が大きすぎないか

取得後に必ずやる設定（事故防止セット）

• ✅ 自動更新をON（支払い方法も登録）
• ✅ ドメインロックをON（勝手な移管・変更を防ぐ）
• ✅ WHOIS代理公開を設定（個人情報の露出を抑える）
• ✅ 管理画面の2段階認証をON
• ✅ 更新通知が届くメールを確認（迷惑メールに入らないよう設定）

料金の例（目安として“相場観”を掴む）

• たとえばムームードメインでは、.com は取得770円／更新1,728円、.jp は取得990円／更新3,344円といった表示があります（別途、調整費の注記あり）。
• いっぽうで、お名前.comのようにキャンペーン価格や条件付き割引がある場合もあり、登録時期や条件で更新額が変わる注意書きもあります。
  → なので、最終的には必ず「取得」「更新」「移管」を公式の価格表で確認してから決めるのが安全です。

ステップ2：DNSでサーバーへ向ける

ここが最大の山場です。結論としては、DNSは「ドメインをどこへ案内するか」を決める作業です。

ネームサーバー変更とレコード編集の違い

初心者が迷うのは、この2択です。

方式	何をする？	向いている人	注意点
ネームサーバー変更	DNS管理を“サーバー会社側”に丸ごと移す	初心者／設定を簡単にしたい	既にメール等でDNSを使っていると影響が出ることがある
レコード編集	DNS管理は“今のDNS”のままで、必要なレコードだけ変える	メール等を細かく管理している	レコード理解が必要。ミスるとサイトもメールも止まり得る

迷ったら

• サイト以外（メール、外部サービス認証）が特にない → ネームサーバー変更がラク
• 既にドメインメール運用、外部サービスのTXT認証が多い → レコード編集が安全なことが多い

A/AAAA/CNAMEの使い分け（典型パターンだけ覚える）

Webサイト表示に必要な“典型パターン”は、まずこれだけでOKです。

よくある基本形

• @（例：example.com） → AレコードでサーバーのIPv4へ
• www（例：www.example.com） → CNAMEで example.com へ（またはAで同じIPへ）
• IPv6を使う場合のみ → AAAA を追加

覚え方

• A：ドメイン → IPv4アドレス
• AAAA：ドメイン → IPv6アドレス
• CNAME：別名（サブドメイン）を“本体ドメイン”へ寄せる

※サーバー会社によっては「DNSテンプレ」「自動設定」があり、入力項目が簡略化されていることがあります。

DNS反映（伝播）に時間がかかるときの見分け方

DNSは「変更してすぐ反映」にならないことがあります。焦って何度も変えると、逆に混乱します。

反映待ちかどうかを見分けるコツ

• スマホ回線と自宅Wi-Fiで、見える結果が違う → 反映途中の可能性
• DNSの確認で、参照する場所によってIPが違う → 反映途中の可能性
• ブラウザのキャッシュを消しても変わらない → DNS側の問題の可能性が上がる

確認手段（初心者向け）

• オンラインのDNS確認サービスで、地域ごとの解決結果を見る
• PCなら nslookup で現在参照される先を確認（難しければ“サーバー側の簡単診断”でもOK）

メールを使う人は先に決める（MX/SPF/DKIM/DMARCの方針）

ドメインメールを使う予定があるなら、DNSは“Webだけ”では終わりません。

方針を先に決めるとラク

• どこでメールを運用するか（例：Google Workspace／Microsoft 365／サーバー付属メール）
• 迷惑メール対策（送信ドメイン認証）をどうするか

最低限の考え方

• MX：メールの届け先（どこのメールサーバーで受けるか）
• SPF（TXT）：そのドメインから送って良い送信元を宣言
• DKIM（TXT）：署名で送信元を検証
• DMARC（TXT）：SPF/DKIMの結果を踏まえた扱い方針（隔離・拒否など）

注意

• Web公開だけ先に進めて、後からメールDNSを触るのはOKですが、逆に「既にメール運用中のDNSを安易にネームサーバー変更」すると、メールが止まる原因になります。

ステップ3：サーバー側でドメインを追加する（公開フォルダの設計）

DNSでサーバーに向いたら、次はサーバーに「このドメインで公開します」と登録します。

サーバー側でよくある設定項目

• ドメイン追加（example.com を登録）
• 公開フォルダ（ドキュメントルート）を決める
• PHPバージョン等の環境設定（サーバー会社が推奨する設定に合わせる）

公開フォルダ設計のおすすめ（事故が減る）

• 1ドメイン＝1フォルダ（サイトが増えても管理しやすい）
• テスト用と本番用を混ぜない（後で削除・移行が困難になる）

よくある失敗

• 既存の別サイトのフォルダに上書きしてしまう
• “どのフォルダが公開されているか”が分からなくなる
  → サーバーの「ドメイン一覧」と「公開フォルダ」の対応は必ずメモしておくと安心です。

ステップ4：WordPress側でURLを整える（表示されるURLの統一）

ここは「サイトの正しい住所をWordPress自身に教える」工程です。
ただし、やり方を間違えると 管理画面に入れなくなることがあるので慎重に進めます。

まず決める：あなたの“正規URL”

• https://example.com にするのか
• https://www.example.com にするのか

WordPressの設定箇所（多くのケース）

• 管理画面 → 設定 → 一般
  • WordPressアドレス（URL）
  • サイトアドレス（URL）

初心者向けの安全ルール

• SSL（https）がまだ不安定なら、先にサーバー側でSSLを整えてからhttpsへ統一する
• “wwwあり／なし”の統一は、サーバー側の転送とセットで考える（片方に寄せる）

もし間違えて管理画面に入れなくなったら

• 慌てて何度もURLを触らず、まずは復旧の入口を作るのが先です。
• 代表的な復旧策として、wp-config.php に WP_HOME と WP_SITEURL を定義してURLを上書きする方法があります（やり方は出典にある公式情報を参照してください）。

ステップ5：SSLでhttps化し、混在コンテンツを潰す

いまのWebでは、https（鍵マーク）前提で考えるのが基本です。
SSLは「暗号化」と「なりすまし防止」を支える仕組みで、サイトの信頼性にも直結します。

無料SSLと有料SSLの選び方（更新・運用コストで比較）

結論として、一般的なWordPressサイトなら 無料SSL（DV）で十分なケースが大半です。
ただし、用途によっては有料が必要になることもあります。

項目	無料SSL（例：Let’s Encrypt系）	有料SSL
費用	無料	年額課金が一般的
手間	サーバーが自動更新ならラク	契約・更新・設置が増えることがある
向いている例	ブログ、企業サイト、オウンドメディア	組織実在性を強く示したい、運用要件が厳しい
注意	サーバー側の更新方式を確認	証明書種別・更新サイクルの管理が必要

初心者向けの判断基準

• 迷ったら：まず無料SSLで開始
• 例外：社内規定や取引要件で「特定の証明書」が必要な場合のみ有料を検討

「鍵マークが出ない」原因トップ3

原因1：混在コンテンツ（httpの素材が残っている）

• 例：画像URL、CSS/JS、埋め込みが http:// のまま
• 対処：
  • WordPressのURLをhttpsに統一
  • 置換（Search Replace）で http → https を整理（慎重に）
  • テーマやプラグイン側のURL指定も確認

原因2：証明書が“今のアクセス先”をカバーしていない

• example.com だけ有効で www.example.com は未対応、など
• 対処：
  • 証明書の対象ドメイン（SAN）を確認
  • 正規URL（www有無）を先に決めて揃える

原因3：転送設定が噛み合っていない（リダイレクトループ）

• http→https、www→なし、プラグインの強制などが二重になると起きがち
• 対処：
  • 強制設定は“どこか1か所”に集約（サーバー or プラグイン）
  • 一つずつOFFにして原因を切り分ける

ステップ6：公開前チェックリスト（表示・パーマリンク・インデックス）

最後に、公開直前の「やり残しゼロ」を作ります。
ここを丁寧にやるほど、公開後のトラブル対応が減ります。

絶対に確認したい5項目

表示確認

• ✅ トップページと主要ページが開く
• ✅ wwwあり と wwwなし の両方でアクセスしても、最終的に正規URLへ揃う
• ✅ http で開いても https に統一される
• ✅ 画像やレイアウト崩れがない（特にトップと記事ページ）

管理画面ログイン

• ✅ /wp-admin にアクセスできる
• ✅ ログイン後、管理画面のリンク遷移が正しく動く（別URLへ飛ばされない）
• ✅ 可能なら管理者アカウントのメールも受信確認（パスワードリセットが重要）

パーマリンク

• ✅ パーマリンク設定を決めて保存（例：「投稿名」など）
• ✅ 公開後に大きく変えない前提で決める（後から変更はリンク切れ要因）
• ✅ カテゴリや固定ページのURLが意図通りか確認

https統一

• ✅ 鍵マークが出る（ブラウザ警告がない）
• ✅ 混在コンテンツがない（開発者ツールの警告が出ない）
• ✅ WordPress内の内部リンク・画像URLが https になっている

検索エンジン設定

• ✅ 検索エンジンに出したい場合、サイトが「非公開」設定になっていない
  • WordPress：設定 → 表示設定（Reading）で “検索エンジンがサイトをインデックスしないようにする” がONになっていないか
  • WordPress.com：サイト可視性が公開で、同様のチェックがOFFになっているか
• ✅ Search Consoleに登録（できれば公開直後に）
• ✅ サイトマップ送信（SEOプラグインやWordPress標準のサイトマップを利用）

既存サイトのドメインを変更する手順（SEOを守る移行設計）

ドメイン変更は「引っ越し＋表札替え」です。
成功のコツは、作業そのものよりも “事前の設計” にあります。ここを丁寧にやると、順位下落やアクセス減を最小限にできます。

まず判断：本当にドメイン変更が必要？（代替案も含めて検討）

ドメイン変更は、基本的にSEOリスクが伴います。まずは「変える理由」が本当に強いかを確認しましょう。

ドメイン変更が“必要になりやすい”ケース

• 会社名・サービス名が完全に変わった（今のドメインだと誤認が出る）
• 商標・法務の事情で継続利用が難しい
• 過去のドメイン履歴に問題があり、信頼回復を優先したい
• 国・事業範囲の変更などで TLDを変える必然性がある（例：国内→グローバル）

代替案で済むことも多い（リスクを下げる）

「ブランドは変えたいが、SEOの損失は避けたい」場合は、次の選択肢も検討価値があります。

目的	代替案	こんな人に向く	注意点
見た目・名称を変えたい	サイト名・ロゴ・デザイン・タイトルを変更	リブランディング中心	ドメイン自体は変わらないのでSEOリスクは小さめ
新サービスも始めたい	既存ドメイン配下で新カテゴリ/新LPを作る	一つの資産として育てたい	サイト構造が複雑化しない設計が必要
新ドメインも使いたい	新ドメインは広告・名刺用に使い、本体へ誘導	まずは周知目的	“重複コンテンツ”にならないよう運用を工夫

判断の目安

• 迷う場合は「ドメイン変更しない方法」で目的が達成できないかを先に探す
• それでも無理なら、SEOを守るために “設計に時間を割く” のが正攻法です

移行方針を決める：URL構造は維持する？ 同時に変える？

結論から言うと、初心者ほど 「ドメイン以外はなるべく変えない」 が安全です。

方針の基本はこの2択

1. URL構造を維持（おすすめ）
   • 例：old.com/service/a → new.com/service/a
   • メリット：移行がシンプルで、301の設計もミスりにくい
2. URL構造も同時に変更（上級者向け）
   • 例：old.com/service/a → new.com/a
   • メリット：情報設計を刷新できる
   • デメリット：作業量が増え、リダイレクト漏れや評価引き継ぎミスが起きやすい

失敗しにくい移行の鉄則（初心者向け）

• 変更は一回に一つ
  • ドメイン変更と同時に、デザイン総入れ替え・大量リライト・カテゴリ再編までやると、原因切り分けが難しくなります。
• 1対1の対応表（旧→新）を作る
  • “旧URLがどこへ行くか”が曖昧だと、301の漏れが増えます。
• 正規URL（https、www有無）を先に決める
  • 途中で揺れると、リダイレクトが二重・ループしやすくなります。

事前準備チェックリスト（作業前に“損失”を防ぐ）

ドメイン移行は、技術作業よりも 「準備の抜け」 で失敗します。
ここはチェックリストで機械的に潰すのが最強です。

完全バックアップ（ファイル／DB／復元手順まで）

バックアップは「取る」だけだと不十分で、戻せることが重要です。

最低限そろえるべきもの

• ✅ ファイル一式
  • wp-content（画像、テーマ、プラグイン）は特に重要
• ✅ データベース（DB）
  • 記事・固定ページ・設定・ユーザー情報などが入っています
• ✅ 復元手順メモ
  • どこから戻すか、どの順で戻すか（緊急時に助かります）

初心者がやりがちな落とし穴

• 「エクスポート（記事データ）だけ」＝完全バックアップではありません
  画像や設定が戻らないことがあります。
• できれば テスト環境で復元できるか一度試す
  → “戻せる安心感”があると、移行作業が一気にラクになります。

現状のSEO記録（順位・流入・被リンク・主要ページ）

移行前の記録がないと、移行後に「何が落ちたか」「戻っているか」が判断できません。
ここは数字で保険をかけます。

最低限とっておきたい記録（おすすめ順）

• ✅ Search Console
  • 検索パフォーマンス（クリック・表示回数・平均掲載順位・CTR）
  • 上位の ページ と クエリ
  • インデックス状況、サイトマップ、クロールエラー
• ✅ アクセス解析（GA4など）
  • 流入（Organic）、ランディングページ上位、CV（成果）
• ✅ 被リンク・参照元
  • Search Consoleのリンクレポート
  • 可能なら主要な外部リンク元（SNSプロフィール、提携先、記事掲載など）も控える
• ✅ “守るべきページ”リスト
  • 収益ページ、上位表示ページ、被リンクが多いページは最優先で守る

ワンポイント
移行後に「順位が落ちた／戻った」を見たいなら、
主要キーワードの順位を 移行前の数値としてメモしておくと比較が簡単です。

内部リンク／外部連携（フォーム・決済・API）棚卸し

ドメインを変えると、サイトの外側・裏側が壊れやすいです。
特に収益や機会損失に直結するので、ここは丁寧に。

棚卸しチェック（例）

• ✅ お問い合わせフォーム（送信・通知メール・自動返信）
• ✅ 決済・予約・会員登録（Stripe/PayPalなど）
• ✅ 計測タグ（GA4、GTM、広告コンバージョン）
• ✅ 外部API連携（CRM、チャット、メール配信、地図、SNS埋め込み）
• ✅ アフィリエイト計測（発リンク、計測パラメータ、提携先の登録URL）
• ✅ 画像・ファイルの直リンク（旧ドメイン参照が残りやすい）

地味に効くポイント

• プロフィール、SNS、名刺、プレスリリースなど
  “外のリンク”が古いままだと、せっかく移行しても流入が取りこぼれます。

新ドメイン側の準備（DNS・SSL・テスト環境）

新ドメイン側は、移行当日に慌てないために 「受け皿を完成させてから」 旧サイトを引っ越すのが安全です。

新ドメインで先にやること

• ✅ 新ドメイン取得（自動更新・ロック・WHOIS代理公開）
• ✅ DNS設計（www有無、A/CNAME、メール運用方針）
• ✅ SSL（https）を有効化して、正規URLを決める
• ✅ テスト環境（ステージング）を用意
  • 本番公開前に表示・ログイン・主要機能を確認できる状態にする

SEO目線で重要な注意

• 旧サイトは、移行の間も クロールできる状態を保つのが基本です。
  （検索エンジンが旧URL→新URLの転送を確認できないと、移行が進みにくくなります）
• 移行後に使うツール類も先に用意
  • 新ドメインをSearch Consoleに追加・所有権確認
  • 新ドメインのサイトマップ送信準備
  • （必要なら）Search Consoleの「アドレス変更」ツールを使う段取りを決めておく

移行の実作業：推奨の順番（事故りにくい）

ドメイン変更は「旧サイトを動かしたまま、新サイトを完成させ、最後に切り替える」のが安全です。
この順番にすると、トラブルが起きても戻しやすく、SEOの引き継ぎもスムーズになります。

1）新ドメインで“受け皿”を用意し、テスト表示する

まず、新ドメイン側で「公開できる完成形」を作ります。旧サイトは止めません。

やること（最低限）

• 新ドメインをサーバーに追加（公開フォルダを分ける）
• SSL（https）を有効化（www あり/なしも含め、証明書の対象を揃える）
• WordPressを用意（方法は2つ）
  • 旧サイトを複製して持ってくる（一般的）
  • 新規WordPressを入れて、コンテンツ移行する（規模次第）

テスト表示のコツ

• 公開前は、検索エンジンに拾われないようにしておく（テスト環境の露出を避ける）
• 表示・ログイン・主要機能（フォーム等）まで確認してから次へ進む

2）WordPressのURL設定を更新する（3つのやり方）

WordPressにはURLの核となる設定があり、ミスると「管理画面に入れない」が起きやすい部分です。
基本は 安全な方法 → どうしても無理なら強い方法 の順で使います。

管理画面から変更できるケース

管理画面に入れる状態なら、まずこれが最も簡単です。

手順（一般的な流れ）

• 管理画面 → 設定 → 一般
• 「WordPressアドレス（URL）」と「サイトアドレス（URL）」を新ドメインに変更
• 保存 → いったんログインが切れることがあるので、新URLで入り直す

注意点

• SSL（https）が未確定のままURLだけ先に変えると、ループや表示崩れの原因になります
  → 先にSSLを安定させてから、https://新ドメイン に統一するのが安全です。

wp-config.phpで強制指定するケース

「管理画面が開けない」「変更後に入れなくなった」など、復旧や強制上書きで使います。
この方法を使うと、管理画面でURLを変更できなくなる点に注意です（“固定”されるため）。

// wp-config.php に追記（例）
define('WP_HOME',    'https://new.example.com');
define('WP_SITEURL', 'https://new.example.com');

使いどころ

• 移行中の一時的な固定（復旧のための安全弁）
• ループして管理画面に入れないときの復帰手段

終わったら

• 設定が安定したら、不要な固定は外す（将来の変更が楽になります）

DB（siteurl/home）を直接修正するケース

管理画面にもサーバー設定にも入れず、最後の手段として使うイメージです。
（作業前にDBバックアップは必須）

概要

• wp_options テーブルの siteurl と home を新ドメインへ更新します
• テーブル接頭辞（wp_）は環境で異なるので注意

-- 例：wp_options の場合（接頭辞は環境に合わせる）
UPDATE wp_options SET option_value='https://new.example.com' WHERE option_name IN ('siteurl','home');

注意点

• マルチサイトは構造が違うため、安易に同じ手順で触らない（別設計になります）
• キャッシュ（オブジェクトキャッシュ等）を使っている場合は、変更後にキャッシュクリアが必要になることがあります

3）データベース内のURLを置換する（シリアライズ注意）

ドメイン変更後、「本文のリンク」「画像URL」「ウィジェット設定」などに旧ドメインが残ることがあります。
ここで危険なのが、DBを単純置換してしまうことです。

なぜ危険？

• WordPressの設定の一部は、シリアライズ（文字数を含む形式）で保存されます
• 文字列だけ置換すると、形式が壊れて表示崩れや設定消失が起きることがあります

初心者におすすめの基本方針

• 可能なら シリアライズ対応の置換手段を使う（WP-CLIなど）
• まずは dry-run（試し置換）で影響範囲を確認する

WP-CLIの例（代表パターン）

# まず試す（置換される件数を確認）
wp search-replace 'https://old.example.com' 'https://new.example.com' --dry-run

# 問題なければ実行（GUIDは基本スキップ推奨のことが多い）
wp search-replace 'https://old.example.com' 'https://new.example.com' --skip-columns=guid --all-tables

ポイント

• 置換は「旧→新」を基本に、必要なら「http→https」も別途行う
• 置換後は、表示確認と合わせて「旧ドメイン文字列が残っていないか」を検索（管理画面やHTMLソース）すると安心です

4）テーマ／プラグイン／ウィジェットの参照URLを点検する

DB置換だけでは取り切れない“残りカス”がここに出ます。
原因は「テーマやプラグインが独自の保存場所を持つ」ためです。

点検チェックリスト（よく残る場所）

• メニュー（カスタムリンク）
• ウィジェット（バナーHTML、プロフィール等）
• カスタマイザー（ロゴ、ヘッダー画像、フッター設定）
• SEO系プラグイン
  • canonicalやOGP、サイト名、SNSプロフィールURL
• 解析・広告
  • GA4/GTM/広告タグ、コンバージョン設定
• フォーム・決済・予約などの外部連携
  • コールバックURL、送信先URL、埋め込みコード
• キャッシュ／CDN系プラグイン
  • “サイトURL”の再指定が必要なことがある

確認のコツ

• サイト内検索で旧ドメインを検索（管理画面内の設定も含めて探す）
• ブラウザでページのソースを見て、旧ドメインの読み込みが残っていないか確認（画像/CSS/JS）

5）DNS切替とSSL適用（切替タイミングの決め方）

ここが「公開の瞬間」です。焦らず、切替前に“前提”を揃えます。

切替前に揃えること

• 新ドメイン側で https が正常（鍵マーク、証明書エラーなし）
• 旧サイトと新サイトの内容が一致（少なくとも重要ページ）
• 301設計が用意できている（次のステップ）

切替タイミングの考え方

• アクセスが少ない時間帯を選ぶ
• DNSは反映にタイムラグがあるので、作業は余裕を持って行う
• 切替直前にTTLを短くする運用もありますが、初心者は無理に触らず「余裕のある時間帯」を優先してもOKです

6）301リダイレクトを設計して実装する（全ページ対応が基本）

SEOを守る本丸です。原則はこれだけ。

• 旧URLは対応する新URLへ1対1で301
• リダイレクトは1回で最終URLに到達（途中で何回も転送しない）
• 旧ドメインは当面維持（転送が機能し続ける必要がある）

.htaccessで行う場合

Apache環境でよく使われます。旧ドメイン側（旧サイト側）に設置します。

RewriteEngine On

# old.example.com と www.old.example.com を new.example.com へ
RewriteCond %{HTTP_HOST} ^(www\.)?old\.example\.com$ [NC]
RewriteRule ^(.*)$ https://new.example.com/$1 [R=301,L]

Nginxで行う場合

Nginx環境では server ブロックでまとめるのが一般的です。

server {
  listen 80;
  server_name old.example.com www.old.example.com;
  return 301 https://new.example.com$request_uri;
}

CDN／WAF配下で行う場合

CDN（例：Cloudflare等）を使っていると、サーバーより上流でリダイレクトを管理できます。
大量のURL対応が必要な場合は「一括リダイレクト（Bulk Redirects等）」が便利です。

この方式が向くケース

• 旧サイトのサーバーに触れない/触りたくない
• 大量のURLを一覧で管理したい
• 切替を素早く反映したい（エッジで制御）

注意

• サーバー側の転送と二重にすると、ループの原因になります
  → “どこで転送を担当するか”を1つに決めるのが鉄則です。

最低限の動作テスト

• 旧URLにアクセス → 301 → 新URL → 200 になるか
• 旧トップだけでなく、旧記事URLも同様に確認
• 302（一時）になっていないかも確認（原則301で）

7）canonical／サイトマップ／構造化データを更新する

移行後は「検索エンジンに新住所を正として伝える」仕上げをします。

必ず更新したいもの

• canonical：新ドメインのURLになっているか
• XMLサイトマップ：新URLで生成し直し、送信し直す
• 構造化データ：URLを含む項目（ロゴ、sameAs、WebSite/WebPageのURL等）が旧ドメインのままになっていないか
• OGP/Twitterカード：画像URLやページURLが旧ドメイン参照になっていないか

Search Consoleでやること（重要）

• 新ドメインをプロパティとして追加し、所有権確認
• サイトマップ送信
• 条件が揃ったら「アドレス変更」ツールの利用を検討（旧→新の移行を伝える）

移行後の確認

ドメイン移行は「切り替えて終わり」ではなく、移行後1〜4週間の点検で勝負が決まることが多いです。
ここを丁寧にやると、順位の戻りが早くなり、数字の崩れ（CV・広告・SNSシェア）も防げます。

リダイレクト網羅チェック（旧URL→新URLが1回で到達するか）

結論：旧URLの“漏れゼロ”と、転送が“1回で終点”になっているかを確認します。
（2回以上の転送＝遅い・評価伝達が弱い・ループの温床になりがち）

やること（初心者でも実施しやすい順）

• 旧サイトのURL一覧を作る
  • 旧サイトのサイトマップ
  • Search Consoleの「上位ページ」
  • アクセス解析のランディング上位
  • 重要ページ（収益・被リンク・人気記事）を手動で追加
• 一覧の旧URLにアクセスして、以下を確認
  • 旧URL → 301 → 新URL → 200 になっているか
  • 旧URLが新トップへ一律転送になっていないか（※原則NG）
• 旧URLと新URLの対応が正しいか
  • 旧記事 → 新記事（同等内容）
  • 旧カテゴリ → 新カテゴリ（同等内容）

最低限の判定基準（これだけ覚える）

• ✅ ステータスが 301（恒久転送）
• ✅ 転送回数が 1回（旧→新で終了）
• ✅ 到達先が 意図した新URL
• ✅ 新URLは 200（正常表示）

手軽な確認コマンド（慣れている人向け）

curl -I http://old.example.com/sample-page/

• Location: が新URLになっているか
• 301 → 200 の流れが崩れていないか
  （※実運用では https / www の組み合わせも同様に確認）

404／500／リダイレクトループを検出して潰す

移行後トラブルは「ユーザー体験の悪化」だけでなく、クロール効率にも影響します。
優先度は ループ > 500 > 404 の順で潰すのが基本です。

よくある原因トップ5

1. 旧→新の転送と、WordPress/プラグインの転送が二重（ループ）
2. wwwあり/なし と https 統一が噛み合っていない（ループ）
3. 旧URLの一部が未転送で404（漏れ）
4. 置換や移行の途中でパスが変わって404（対応表不足）
5. PHP/DB接続や権限まわりで500（環境差・権限不足）

検出のコツ（初心者でもやりやすい）

• ブラウザで旧URLを開き、アドレスバーの遷移が不自然に何度も変わる → ループ疑い
• 重要ページを中心に、以下が正常か確認
  • トップ / カテゴリ / 人気記事 / お問い合わせ / 申し込み導線
• サーバーのアクセスログ・エラーログ（見られるなら最短）
  • 404が大量に出ているパスを拾って、301で救済する

404の“正しい潰し方”

• 旧URLが消えたなら：近い新URLへ 301で救済
• 本当に不要なら：404のままでOK（ただし重要ページ由来は救済推奨）
• “とりあえずトップへ”は避ける（評価・UXともに弱くなりやすい）

Search Console対応（プロパティ追加・サイトマップ送信・監視）

Search Consoleは、移行後の「異常の早期発見」に最も役立ちます。
やることは多く見えますが、実務は次の3つに絞れます。

必須タスク（最短セット）

• 新ドメインをSearch Consoleに追加（所有権確認まで）
• 新ドメインのサイトマップを送信
• 旧ドメイン側で「移転」をGoogleに伝える操作（条件が揃う場合）

移行後に見るべき画面（優先順）

• インデックス関連（ページが増えているか、除外が急増していないか）
• サイトマップ（成功/エラー、URL数の推移）
• 404（見つかりません）やソフト404の兆候
• 重大な手動ペナルティやセキュリティ問題（もし出たら最優先で対応）

監視のコツ

• 最初の1週間は毎日、次の2〜4週間は週2〜3回が目安
• 「エラーが0」を目指すより、重要ページのエラーが0を先に達成する方が効果的

解析・広告・SNSの設定更新（見落とすと数字が崩れる）

ここが抜けると「順位は戻ったのに売上が戻らない」状態になりがちです。
“計測・導線・シェア”の3系統で点検します。

解析（GA4 / GTMなど）

• GA4のデータストリーム設定（サイトURL）を新ドメインに更新
• GTMのトリガー（ホスト名条件）が旧ドメインのままになっていないか
• 参照元除外・クロスドメイン（決済/予約など）設定が崩れていないか
• 自己参照（リファラが自分のドメインになる）を確認
  • 転送やサブドメインの絡みで発生しやすいです

広告（Google広告 / Meta等）

• コンバージョンタグの動作確認（実際に発火しているか）
• ランディングURL、最終URL、追跡テンプレートの更新
• 計測パラメータ（gclid等）が途中で欠落していないか

SNS・外部露出

• OGP（タイトル/説明/画像）が新URLで正しく出るか
• プロフィールや固定ポスト、リンク集、名刺QR、提携先リンクの更新
• RSS、メール配信フォーム、チャットウィジェットなど外部連携のURL更新

おすすめの最短チェック

• 自分で1回、申し込み/問い合わせ/購入の動線を最初から最後まで通す
• 管理画面側で「1件のCVが記録された」まで確認できれば安心です

順位変動の見方：落ちても慌てないための観測期間

ドメイン移行後は、多少の順位変動が起きやすいです。大事なのは「想定内」と「異常」を分けることです。

よくある“想定内”の動き

• 一時的に順位が上下し、2〜8週間くらいで落ち着く
• 旧URLが減り、新URLが増える（インデックスの入れ替え期間）

異常を疑うサイン（早めに対処）

• 旧→新の301が一部でも切れている（特に重要ページ）
• 新サイトがnoindexになっていた、robotsで塞いでいた
• canonicalが旧ドメインを指したまま
• 404が急増している（重要ページの未救済）
• リダイレクトが多段（2回以上）が大量にある

観測のおすすめ（初心者向け）

• 重要キーワードは「日次」で一喜一憂せず、週次の平均で見る
• 重要ページ（収益ページ・被リンクページ）が
  • 新URLでインデックスされているか
  • 新URLへ流入が移っているか
    を最優先で確認する

移行後の運用ルール

• 301リダイレクトは短期で外さない（最低でも長めに維持する前提で設計）
• “戻らないから戻す”を急いでやるほど混乱が増えやすい
  → まずは「301漏れ・canonical・サイトマップ・noindex」を点検するのが先です

旧ドメインをいつまで保持する？（コストとリスクの現実解）

ドメイン移行で「いちばん後悔しやすい」のが、旧ドメインを早く手放してしまうことです。
旧ドメインは“古い住所”であると同時に、旧URLの301リダイレクトを維持する土台であり、第三者に取られるとなりすまし・フィッシング・悪質転送のリスクも出ます。

最低でも維持したい期間の目安

結論としては、次の考え方が安全です。

• 最低ライン：1年
  • Googleの移転ガイドでは、301リダイレクトはできるだけ長く、一般的に少なくとも1年維持することが推奨されています。
  • Search Consoleの「アドレス変更」関連の案内でも、旧ドメインは少なくとも1年は維持して第三者に取られるリスクを避ける趣旨が示されています。
• 現実解：1〜2年（多くのサイトはここが無難）
  • 被リンク更新（外部サイトがリンクを書き換える）には時間がかかりやすい
  • 旧URLへの“指名アクセス”“ブックマーク”“SNSの古い投稿”が意外と残る
• 推奨：2年以上（サイト規模が大きい／被リンクが強い／長期資産なら）
  • 大規模サイトほど、クロール・評価移行・リンク更新に時間がかかる傾向がある
  • 年1回の更新コストで、事故の保険としては安いことが多い

判断を迷わなくする簡易ルール

• 旧ドメインに 検索流入・参照・直打ちが少しでも残る → 延長
• 旧ドメインがブランド名・会社名に近い（第三者に取られると危険）→ 延長
• 旧ドメインでメールを使っていた／名刺・資料に残っている → 延長

状況別の目安（ざっくり）

状況	旧ドメイン保持の目安	理由
小規模（記事少なめ・被リンク少なめ）	最低1年 / できれば2年	301の評価移行＋古いリンク残り対策
中規模（収益ページあり・SNS導線あり）	2年推奨	参照元が多く、取りこぼしが起きやすい
大規模（被リンク強い・長期資産サイト）	2年以上（可能なら長期）	外部リンク更新と評価移行に時間がかかる

コストを抑えて“保持だけ”するコツ

• 旧ドメイン側のサーバーは高額プランである必要はありません。
  旧ドメインで必要なのは基本「転送（301）が動くこと」なので、
  • 旧サーバーを最小構成にする
  • 旧ドメイン側の転送をCDN/WAFやサーバーの最小設定で維持する
    などで固定費を下げられます（ただし“転送の担い手”は1つに統一）。

更新忘れを防ぐ仕組み（自動更新／支払い／通知）

旧ドメイン保持で一番怖いのは「うっかり失効」です。
失効すると、復旧できる猶予期間があるTLDもありますが、手続きや追加費用が発生したり、最悪第三者に再取得されます。
（gTLDには失効後の猶予や復旧制度があり、.jpにもライフサイクル上の“回復”手続きがありますが、確実ではありません。）

失効を防ぐ“鉄板セット”

• ✅ 自動更新をON（最重要）
• ✅ 支払い方法を最新に保つ（カード更新・利用限度の見直し）
• ✅ 通知メールを複数登録（可能なら）
• ✅ 通知先メールは「退職・使わなくなるアドレス」を避ける
• ✅ 管理画面に2段階認証を設定
• ✅ ドメインロックをON（不正移管の防止）
• ✅ 更新月の前に、カレンダーにもリマインドを入れる（保険）

おすすめの運用テンプレ（初心者でも回る）

1. ドメイン会社の管理画面で
   • 自動更新：ON
   • 通知先：メイン＋サブ（可能なら）
   • 2FA：ON
   • ロック：ON
2. クレカの更新月を迎えたら、ドメイン会社の支払い情報も更新
3. 年1回だけ「棚卸し日」を作る
   • 有効期限の一覧を見る
   • 旧ドメインの転送が今も正常か（旧URL→新URLが1回で到達）を確認

“失効しかけ”の時に知っておきたいこと（超ざっくり）

• gTLDの世界では、期限切れ後に一定期間の猶予や復旧（Redemption）に関する仕組みがありますが、復旧は追加料金になることが多いです。
• .jpにも、状態遷移と登録回復期間の仕組みがあります。
  → ただし「戻せるから大丈夫」ではなく、失効しない仕組みが最優先です。

よくあるトラブル集：症状→原因→復旧の順で探せる

この章は「症状から逆引き」できるように、各トラブルを 原因 → 切り分け → 復旧 の順でまとめます。
作業前の共通ルールは2つだけです。

• バックアップを取ってから触る（特にDB編集）
• 同時に複数の変更をしない（原因が特定できなくなる）

管理画面が真っ白／ログインできない

よくある原因

• WordPressのURL設定（siteurl/home）が誤っている（ドメイン移行直後に多い）
• プラグイン／テーマのPHPエラー（真っ白＝致命的エラーの典型）
• キャッシュ／CDN／WAFの転送設定が衝突している
• PHPメモリ不足、.maintenance の残骸 など

切り分け（最短ルート）

• まずはブラウザのシークレットで https://新ドメイン/wp-login.php を開く
• 可能ならデバッグログを有効化（真っ白の“原因文”が出る）
  • WP_DEBUG をON、debug.log 出力（本番では表示はOFF推奨）
• プラグインが疑わしい場合：wp-content/plugins を一時的にリネームして全停止（戻せる）

wp-config.phpでURLを固定して復旧する

管理画面に入れないときの“救急処置”として有効です。
ただし 固定すると管理画面の一般設定から変更できなくなる点は理解して使ってください。

1. サーバー上の wp-config.php を開く
2. 下記を追記（example.com を新ドメインに置き換え）

define('WP_HOME',    'https://new.example.com');
define('WP_SITEURL', 'https://new.example.com');

復旧確認

• https://新ドメイン/wp-admin/ にアクセスできるか
• 表示はできるのにログインだけ不可なら、プラグイン由来の可能性もあるため、次の対処へ進みます

安定したら

• 将来の運用を楽にするため、URLが確定した段階で固定を外し、管理画面側の設定へ戻す判断も検討します
  （※外す前に必ず現状の値をメモ）

DBのsiteurl/homeを修正して復旧する

wp-config.php でも戻らない／固定したくない場合はDBを直します。
必ずDBバックアップを取ってから実行してください。

基本方針

• wp_options の siteurl と home を新URLへ更新する
  （テーブル接頭辞 wp_ は環境で異なります）

UPDATE wp_options
SET option_value = 'https://new.example.com'
WHERE option_name IN ('siteurl','home');

復旧後にやること

• キャッシュ（サーバー・プラグイン・CDN）を削除
• まだ真っ白なら、URL以外（プラグイン／テーマ／PHP）の可能性が高い
  • WP_DEBUG のログ（wp-content/debug.log）を確認して原因箇所を特定

https化したのに鍵が出ない（混在コンテンツ）

症状の特徴

• ページ自体は https なのに「保護されていない」「一部保護されていない」表示
• 画像・CSS・JSの一部が http のまま読み込まれている

よくある原因

• 本文やウィジェット、テーマ設定に http://旧ドメイン が直書き
• 画像URL・フォント・外部JSなどが http 配信のまま
• キャッシュで古いHTMLが出続けている

切り分け

• ブラウザの開発者ツール（Console / Security）で「Mixed Content」警告を見る
• ページのソースを検索して http:// が残っていないか確認

復旧の基本手順

1. WordPressのサイトURLが https で統一されているか確認（home/siteurl）
2. DB内の旧URLを シリアライズ対応で置換（WP-CLI等が安全）
3. テーマ／ウィジェット／カスタマイザーに残った http を手動で修正
4. キャッシュ全削除 → 再確認

無限リダイレクトが起きる（www・https・正規化の衝突）

症状の特徴

• 「ページがリダイレクトしていません」「ERR_TOO_MANY_REDIRECTS」
• 端末やブラウザによって出たり消えたりする（Cookie・キャッシュ差）

よくある原因

• サーバー（.htaccess/Nginx）とWordPress（URL設定）とCDNが 別々に正規化して衝突
• http → https と wwwあり/なし が二重にかかっている
• プロキシ配下で「実際はhttpsなのに、WordPressがhttp判定」して転送を繰り返す

切り分け（最短）

• まず「正規URL」を1つ決める（例：https://example.com か https://www.example.com）
• そのうえで、転送ルールを 担当者1人（1箇所）に統一する
  • サーバーだけで統一する
  • あるいはCDNだけで統一する
    （両方は事故りやすい）

復旧の方向性

• WordPressのhome/siteurlを正規URLに揃える
• サーバー側の転送は「正規URLへの一本化」にする（多段転送を作らない）
• キャッシュとCookieを削除して再テスト

画像だけ表示されない／リンクが旧ドメインのまま

よくある原因

• DB置換が不完全（本文・ウィジェット・カスタムHTMLに旧URLが残る）
• テーマやプラグインが独自テーブル／設定にURLを保持している
• 画像の参照先が外部（旧ドメインや別ストレージ）になっている
• キャッシュが古いHTMLやCSSを配信している

切り分け

• 表示されない画像のURLを右クリックで確認し、旧ドメインが残っていないかチェック
• 画像だけ http になっていないか（混在コンテンツも併発しがち）

復旧手順（再発しにくい順）

1. DBをシリアライズ対応で再置換（旧→新、必要なら http→https）
2. ウィジェット・メニューの「カスタムリンク」を点検
3. テーマの設定（ロゴ、OGP画像、フッターHTML等）を点検
4. キャッシュ全消し
5. それでもダメなら、画像自体が旧環境に置きっぱなしの可能性
   • メディアライブラリの実体ファイルが uploads に存在するか確認

DNSが反映されない／表示が人によって違う

起きていること（ざっくり）

• DNSは即時に世界中へ揃うわけではなく、各所のキャッシュやTTLの影響を受けます
• 「自分は見えるのに、他人は旧サイトが見える」などの差が出やすいです

よくある原因

• ネームサーバー変更とレコード変更を混同している
• A/AAAA（IPv4/IPv6）の片方だけが古い
• TTLが長く、古い情報が残っている
• 参照しているDNSリゾルバ（会社・プロバイダ・端末設定）が違う

切り分け（初心者向け）

• スマホ回線（4G/5G）で見てみる（家庭Wi-Fiと違う結果になればDNS/キャッシュ差の可能性が高い）
• nslookup や dig で、返ってくるIPが想定どおりか確認

例：

nslookup new.example.com

復旧の基本

• 正しいネームサーバー／DNSレコードになっているか、管理画面で再確認
• A/AAAA/CNAMEの整合性を取る（不要な方が残っていると“端末差”が出る）
• 時間経過＋キャッシュクリア（端末のDNSキャッシュ、ブラウザキャッシュ）で解消するケースも多いです

メールが届かない（MX/SPF/DKIM/DMARCの設定漏れ）

ドメイン移行でメールが絡むと、サイト表示より厄介になりがちです。
まずは「どのメールが届かないのか」を分けます。

最初の切り分け

• 自分 → 外部に送れない（送信側の問題：SMTP/認証/From設定）
• 外部 → 自分に届かない（受信側の問題：MX/DNS/迷惑判定）
• 一部の宛先だけ届かない（SPF/DKIM/DMARCの判定や送信元の評判）

よくある原因

• MXレコード未設定／優先度ミス（メールサーバーが見つからない）
• SPFがない／複数存在する（SPFは基本1つにまとめる）
• DKIM未設定（サービス側で鍵発行→DNSに公開鍵を登録が必要）
• DMARCがいきなり強すぎる（最初から quarantine/reject で事故る）

復旧の現実解（安全順）

1. MXが正しいか確認（メールサービスの指定どおりか）
2. SPFを整える（送信に使うサービスを網羅）
3. DKIMを有効化（送信サービス側の手順に従ってDNSへ）
4. DMARCは段階的に（まずは p=none でレポート収集→問題なければ強化）

WordPress由来の“フォーム送信メール”が届かない場合

• サーバー標準の送信（PHP mail）は弾かれやすいことがあります
  → 送信方式（SMTP等）を見直すと改善するケースが多いです（ただし環境依存）

マルチサイトのドメイン変更で詰まるポイント

マルチサイトは「1サイトのつもりで変更」すると高確率で詰まります。
理由は、ネットワーク全体の情報と各サイトごとの情報が別々に保存されているためです。

詰まりポイントあるある

• メインサイトだけ直してサブサイトが全部404
• 一部サイトだけ旧ドメインに戻る（DBの更新漏れ）
• ドメインマッピング（複数ドメイン運用）で、どのドメインが正か混乱する
• sunrise.php などの“早期読み込み”設定を見落とす

復旧の考え方（ざっくり）

• まず「ネットワークの正規ドメイン」を決める（メインはどれか）
• DBは「ネットワーク情報」「各サイト情報」の両方を更新する必要がある
  （例：ネットワーク系のテーブル＋各 wp_XX_options の home/siteurl）
• ドメインマッピングを使っている場合は、追加要素（設定ファイル・drop-in）まで含めて点検する

注意

• マルチサイトは環境差が大きいので、作業前に必ずフルバックアップ＋復元手順を用意してから進めるのが安全です

運用とセキュリティ：ドメインは“資産”なので守る

ドメインは「サイトの住所」であると同時に、メール・ログイン・DNS（行き先案内）まで含む“インフラの鍵”です。
更新ミスや乗っ取りが起きると、WordPress以前に サイトそのものが消えることもあるので、ここは最初に仕組み化しておくのが得策です。

更新忘れ＝即死を防ぐ（自動更新・二重通知・担当分け）

なぜ「更新忘れ」が危険なのか

更新が切れると、次のような連鎖が起こり得ます。

• サイトが表示できない（アクセス・売上が止まる）
• メールも止まる（問い合わせ対応が止まる）
• 失効後に第三者に取られると、なりすましや悪質転送の温床になる

最低限の“事故防止セット”

以下を入れておけば、初心者でもかなり安全側に倒せます。

• ✅ 自動更新をON
• ✅ 支払い方法を登録（カード期限切れ・残高不足も要注意）
• ✅ 通知先メールを2系統にする（個人なら「普段使い＋バックアップ」）
• ✅ 年1回の棚卸し日を作る（更新月の前にチェック）
• ✅ 管理画面ログインは2段階認証（可能なら必須）

二重通知の作り方（現実的に回る）

• ドメイン会社の通知：登録メール＋サブメール（可能なら）
• 自分のカレンダー：更新月の1か月前・1週間前に通知
• 支払いカード：カード更新月に「ドメイン支払い情報も更新」リマインド

担当分け（個人でも“役割”で分けると事故が減る）

「自分しかいない」場合でも、考え方として役割を分けるとミスが減ります。

• 支払い担当：自動更新・カード管理・請求書確認
• 技術担当：DNS変更やロック解除が必要な作業
• 監視担当：期限チェック、サイト稼働確認、通知メール確認

可能なら、通知先は個人アドレスだけでなく「共有できるメール（例：運用用アドレス）」も混ぜると強いです。

WHOIS情報の扱い（公開／公開代行／法人情報）

WHOIS（登録データ）で何が起きる？

ドメインの登録情報は、公開ディレクトリ（WHOIS / RDDS）に表示される場合があります。
個人運用でこれを放置すると、住所・氏名・電話・メールなどが露出し、迷惑行為やフィッシングの入口になります。

公開代行（プライバシー／プロキシ）の基本

ICANNが説明しているとおり、プライバシー／プロキシ系サービスは、公開される連絡先情報を置き換える仕組みです（ただし、サービス形態や公開範囲は提供元・TLDで異なります）。

初心者向けの結論

• 個人：基本は 公開代行を使う（使えないTLDなら代替策を取る）
• 法人：
  • 「公式として公開して問題ない情報」を出す
  • 担当者個人の連絡先を直出ししない（退職・異動で破綻しやすい）

“公開代行でも安全ではない”ときの対策

公開代行を使っても、次のような穴が残ることがあります。

• 公開メールが転送になっていて、迷惑メールが増える
• サービスの仕様変更で公開範囲が変わる
• ドメイン会社のアカウントが弱いと、結局乗っ取られる

対策の優先度

1. まずアカウントを強化（2FA、強固なパスワード、権限分離）
2. WHOISの公開状態を“年1回”見直す
3. 連絡先は「運用を継続できるアドレス」に寄せる（個人アドレス依存を減らす）

不正移管・乗っ取り対策（ロック・2段階認証・権限分離）

まず入れるべきは「移管ロック（Transfer lock）」

多くのレジストラでは、ドメインを他社へ勝手に移されないよう 移管ロックを設定できます。
GoDaddyのヘルプでも、移管前には解除（アンロック）が必要であることや、状況によって一定期間移管できないケースがあることが案内されています。
要するに、普段はロックON、必要なときだけ短時間OFFが基本です。

さらに強くするなら「レジストリロック」

JPドメインの場合、JPRSが提供する「レジストリロック」のように、登録情報の変更自体を強く制限する仕組みがあります。
重要度が高いドメイン（企業名・決済・会員サイトなど）は、このクラスまで検討すると安全側です。

2段階認証と権限分離が“効く理由”

攻撃の入口はだいたいこの2つです。

• パスワード漏えい（使い回し・フィッシング）
• メール乗っ取り（通知や承認リンクを奪われる）

やることはシンプル

• ✅ ドメイン会社のログインに2FA
• ✅ 登録メールにも2FA（ここが弱いと全部抜かれます）
• ✅ 管理者アカウントは最小人数（個人でも“管理用”を分ける）
• ✅ 作業用アカウントは権限を絞る（DNS編集だけ、請求だけ、など）

認証コード（EPP/Auth code）の扱い

移管時に必要になる認証コードは“鍵そのもの”です。

• 共有チャットに貼らない
• 期限があるなら短時間で使う
• 使い終わったら破棄・再発行（可能なら）

DNSを守る（DNSSEC／管理者アカウント設計）

DNSは「ドメインの行き先」を決める中枢です。ここを奪われると、

• サイトが偽サイトへ誘導される
• メールが奪われる（MXを書き換えられる）
• ログイン情報が抜かれる（フィッシングの完成）

といった被害に直結します。

DNSSECを有効化する（可能なら）

DNSSECは、DNS応答の改ざんを検知しやすくする仕組みです。
Cloudflareのドキュメントでも、DNSSEC有効化の手順（DNS側で有効化し、レジストラ側へDSレコードを登録する流れ）が説明されています。

初心者向けの判断

• DNSサービス／レジストラが「ワンクリック」や分かりやすい手順を用意している → 有効化を検討
• 仕組みが複雑で運用に自信がない → 無理に触らず、まずはアカウント強化と変更監視を優先

DNSのアカウント設計（ここが差別化ポイント）

DNSを守るうえで効くのは、技術より 運用ルールです。

おすすめのルール（最小構成）

• ✅ DNS管理アカウントは2FA必須
• ✅ 変更できる人を限定（権限分離）
• ✅ 変更履歴が残るサービスを選ぶ（監査ログ）
• ✅ 変更前に「現状バックアップ」（ゾーン情報の控え）
• ✅ ネームサーバー変更は原則“申請制”（その場ノリで触らない）
• ✅ 重要レコード（A/CNAME/MX/TXT）は一覧で台帳化

運用メモのテンプレ（これだけ控える）

• 正規URL（https、www有無）
• ネームサーバー
• Web用レコード（A/AAAA/CNAME）
• メール用レコード（MX/SPF/DKIM/DMARC）
• TTL（変更時に混乱しやすい）

FAQ：検索されやすい疑問を先回りで解消

ドメイン変更で順位は必ず落ちる？ 戻るまでの目安は？

必ず落ちるわけではありませんが、現実的には「一時的に上下する」ケースが多いです。
これは、検索エンジン側で 旧URL→新URLへの評価の引っ越し（クロール→理解→再評価）が走るためです。

落ちやすい条件

• URL対応（旧→新）の漏れがある／トップへ一律転送している
• 301が多段（旧→中継→新）になっている
• www/https/canonical/サイトマップがバラバラ
• ドメイン変更と同時に、デザイン・構造・URL設計・コンテンツも大幅に変えた

戻るまでの体感目安（あくまで“よくある範囲”）

• 小規模サイト：数日〜数週間で落ち着くことが多い
• 中〜大規模：数週間〜数か月かけて移行が進むことがある

不安を減らす“観測ポイント”

• 旧URL→新URLが 1回の301で到達しているか（最重要）
• 新URLのインデックスが増え、旧URLが減っていく「入れ替わり」が進んでいるか
• 重要ページ（収益・被リンク・人気記事）だけでも先に安定してきているか

やっておくと強い結論

• 301は短期で外さず、できるだけ長く維持する（少なくとも1年を基準に考える）
• 変更を“重ねない”（ドメイン変更のタイミングで別の大改修をしない）

サーバー移転だけなら、何を変えて何を変えない？

サーバー移転だけなら、考え方はシンプルです。
「住所（ドメイン/URL）はそのまま、引っ越し先（サーバー）だけ変える」が基本です。

変えるもの（主にDNSとサーバー側）

• DNSの向き先（A/AAAAレコードのIP、またはネームサーバー）
• サーバー環境（PHPバージョン、DB、キャッシュ、WAF、CDNなど）
• SSL証明書の再設定（環境によっては自動発行されるが、確認は必須）

変えないもの（ここを守ると事故が減る）

• サイトのURL（home / siteurl）※基本は変更しない
• パーマリンク構造（記事URLの形）
• 旧→新の301リダイレクト設計（サーバー移転だけなら通常不要）

サーバー移転で起きやすい“落とし穴”

• 旧サーバーで動いていた .htaccess / Nginx設定が新環境で再現されていない
• 画像やCSSが404（移行漏れ、パーミッション、パス不整合）
• キャッシュや圧縮の仕様差で表示崩れ

最短の安全手順

1. 新サーバーでテスト表示（hosts切り替えや一時URLなど）
2. SSLと正規化（https・www有無）を新サーバー側で確定
3. DNS切替
4. 404/500が出ていないか、アクセス解析が計測できているか確認

変更後に元へ戻したいとき、やってはいけないことは？

「戻せば直る」と思って慌てて動くと、評価移行が二重化して混乱しやすいです。
やり直す前に、まず “何が原因で困っているか”を切り分けするのが近道です。

やってはいけないこと（事故率が高い）

• 旧⇄新を短期間で何度も切り替える（検索側が追従しきれない）
• 301を外す／302にする／転送を途中で変える
• noindexやrobotsで新旧どちらかを雑に塞ぐ（意図せぬインデックス崩壊）
• canonicalが旧ドメインを指したままなのに、別の修正を重ねる
• URL削除ツールで“正規化”しようとする（隠すだけで解決にならない）
• 旧ドメインを解約する（悪用リスクも含めて最悪手になりやすい）

現実的な“戻し方”の考え方

• まず復旧の最小単位を決める（例：ログイン不能だけ直す／転送ループだけ直す）
• 旧→新の対応表と301は維持しつつ、原因箇所（URL設定・正規化・DNS・SSL）を一点修正
• どうしてもロールバックが必要なら、短期間で完結させる計画を立て、再度の移行は落ち着いてから

無料ドメインから独自ドメインへ移行する最適な手順は？

「無料ドメイン」が何を指すかで最適手順が分かれます。代表はこの2パターンです。

自前サーバー（WordPress.org）で “サブドメイン/無料ドメイン” → 独自ドメイン

ゴール：旧URLを残し、旧→新へ全ページ301で引っ越す

最短ルート

1. 独自ドメイン取得（自動更新・ロック・2FAをセット）
2. DNSで新サーバーへ向ける（またはサーバー側にドメイン追加）
3. WordPressのURLを新ドメインへ（管理画面／wp-config.php／DBの順で安全に）
4. DB内の旧URLを置換（シリアライズ対応で）
5. 旧ドメイン（旧URL）から新URLへ 1対1の301 を実装
6. サイトマップ更新、Search Consoleで新ドメインを追加して監視（必要ならアドレス変更も）

WordPress.com の「〜.wordpress.com」→ 独自ドメイン

WordPress.comは運用ルールが独特なので、先に押さえると迷いません。

• 独自ドメインを“主要アドレス（Primary）”として使うには、プラン要件がある
• 旧アドレス（〜.wordpress.com）からの転送は、用途に応じて「サイトリダイレクト」の考え方がある

現実的な手順

1. 独自ドメインを追加（登録 or 接続）
2. 独自ドメインを主要アドレスに設定（可能な条件を満たす）
3. 旧アドレスからの流入を逃さない設定を確認（必要に応じてリダイレクトを設計）
4. SNSやプロフィールのリンクを新ドメインに更新

wwwあり／なしはどちらが良い？ 途中で変えてもいい？

どちらでもOKです。大事なのは「選んだら統一する」ことです。
検索エンジンは wwwあり と なし を別URLとして扱い得るため、放置すると重複や評価分散が起きやすくなります。

選び方（初心者向けの実務判断）

• 見た目を短くしたい：なし（https://example.com）
• サブドメイン運用やDNS設計の都合がある：あり（https://www.example.com）
• すでに運用している形式がある：基本はそのまま（途中変更はコストが出やすい）

途中で変えてもいい？
可能ですが、全URLが変わるので “小さなドメイン移行”に近い扱いになります。

変えるなら守ること

• 旧（www/なし）→新（www/なし）へ、全ページを 301で1回 で到達させる
• canonical・サイトマップ・内部リンクを新に揃える
• 変更と同時に別の大改修を重ねない（原因が分からなくなる）

一次情報・公式ドキュメント

「WordPress　ドメイン」は情報が多く、ブログ記事だけだと手順や用語がブレがちです。
迷ったらまず一次情報（公式・標準）に戻れるように、初心者でも追いやすい“当たりどころ”を整理します。

WordPressのURL設定に関する公式情報

• 公式サポート（サイトURLの変更手順）
  • 管理画面での「WordPressアドレス」「サイトアドレス」の扱い
  • うっかり変更して入れなくなったときの復旧ルート（wp-config.php / DB など）
  • 「変更方法が複数ある」理由と、ケース別の選び方がまとまっています
• 公式開発者ドキュメント（wp-config.php）
  • WP_HOME / WP_SITEURL の意味（どちらが“表示URL”で、どちらが“WordPress本体の場所”か）
  • 定数で固定したときの挙動（管理画面から編集できなくなる等）
  • 「管理画面が死んだ」状況での復旧にも直結するので、最小限ここだけ読んでも価値があります
• 公式開発者ドキュメント（移行・引っ越し）
  • サーバー移転／URL変更／ドメイン変更が絡むときの基本的な考え方
  • “どこを変えると何が壊れるか”の地図として使えます（作業前の確認にも便利）

WordPress.comのドメイン運用（主要アドレス）

WordPress.comは「主要アドレス（Primary）」の概念が軸です。
複数ドメインを追加できても、ユーザーに見せたい“正”のURLをどれにするかを決めるのが先です。

• ドメイン管理の総合案内（Domains / Domain management）
  • まずここを起点にすると、設定画面の導線（Domains、DNS、SSL、転送、連絡先確認など）で迷いにくいです
• 主要アドレス（Primary）の設定
  • 追加した複数ドメインのうち、ブラウザに表示させる正のURLをどれにするか
  • 無料サブドメイン（〜.wordpress.com）との関係も、このページの理解が起点になります
• 既存ドメインの接続（Connect a domain）
  • 「ネームサーバーを変える方式」か「DNSレコードで向ける方式」かの考え方
  • メールを使っている場合に、DNS変更の順番を間違えると止まり得る点など、実務の注意がまとまっています
• DNSレコードの管理（WordPress.com上で触れる条件と範囲）
  • “どの条件ならWordPress.com側でDNSが編集できるか”が明確です
  • TXT/CNAME追加など、外部サービス連携で必要になる操作の入口にもなります
• SSL（https）の扱い
  • WordPress.com側でのSSLの基本仕様と、表示が安全にならないときの確認ポイントがまとまっています
• DNSSEC（使う場合のみ）
  • DNSSECを有効化できるか／するなら何を理解しておくべきか、公式の入口として便利です
• リダイレクト・転送（似ているが用途が違う）
  • サイトアドレスのリダイレクト（移行時の“旧→新”などに使う発想）
  • ドメイン転送（Forwarding：見た目は似るが、用途や向かないケースがある）
  • 「何をしたいか」によって正解が変わるので、公式の注意書きを先に押さえるのがおすすめです
• ドメイン名自体を“変更”したいとき（編集はできない）
  • 登録済みドメインは文字列を直接編集できない前提で、現実的な手を案内しています
  • 誤字修正やブランド変更で詰まりやすいポイントの整理に使えます

DNS／SSLの基礎を確認できる公的・標準情報

「どの会社のDNS画面でも通用する“共通言語”」を持つと、WordPress周りの作業が一気に安定します。
ここは、標準（RFC）→実務ガイド→公式運用例、の順で当たると迷いが減ります。

DNSの標準仕様（まずはここが土台）

• DNSの概念（名前解決が何をしているか）：RFC 1034
• DNSの実装・メッセージ形式（レコード、問い合わせ/応答の枠組み）：RFC 1035
  ※必要に応じて日本語訳（JPRS）もあります

DNSSEC（DNSの“改ざん耐性”）

• DNSSECの標準概要：RFC 4033
• 国内の理解補助：JPRS / JPNIC の解説（仕組みや背景が平易）

SSL/TLS（httpsの中身）

• TLS 1.3（現代のHTTPSの土台）：RFC 8446
• 推奨設定の考え方（暗号スイートや運用の指針）：NIST SP 800-52 Rev.2
  ※サーバー設定の勘所を“公的ガイド”として押さえたいときに役立ちます

証明書（CA）の運用ルールと、現場の標準

• 公開信頼された証明書の最低要件：CA/Browser Forum Baseline Requirements
  （証明書運用の世界観をつかむのに有効です）
• 証明書の形式・拡張の標準：RFC 5280（X.509）
• 自動発行（ACME）の標準：RFC 8555
  （無料SSLが自動更新される“仕組み側”を理解したい人向け）
• 実務で最も参照されるCAの公式例：Let’s Encrypt（Getting Started / certificates）
  （標準そのものではありませんが、運用の現実として参照価値が高いです）

まとめ

WordPressのドメイン設定は、細かい作業が多く見えても、押さえるべき要点は次の通りです。

• ドメインは“資産”。まずは 更新・管理（自動更新、通知、2FA、ロック）を仕組み化する
• 設定は「ドメイン取得 → DNSでサーバーへ向ける → サーバー側で追加 → WordPressのURLを整える → SSLでhttps化 → 正規URL統一」の順が安全
• つまずきやすいのは DNS・SSL・WordPressのURL（home/siteurl）・正規化（www/https）
• ドメイン変更（移行）をするなら、全ページ1対1の301と、移行後の監視（Search Console、404、計測タグ）が勝負どころ
• 旧ドメインは早く手放さず、リダイレクト維持と第三者取得リスクの観点で“現実的な期間”を確保する

最後に、迷ったときのために、行動の目安を置いておきます。

次にやることチェック

• 新規で独自ドメイン：DNS設定 → SSL → WordPress URL統一 → 公開前チェック
• 既存サイトのドメイン変更：対応表作成 → 301設計 → DB置換（シリアライズ注意）→ 監視体制
• サーバー移転だけ：URLは基本触らず、DNS切替と表示・計測の確認に集中

ドメイン周りは“最初に整えるほど、後でラクになる”領域です。
このページを手元に置きつつ、1つずつ順番に進めれば、初心者でも安全にドメイン設定・移行まで完了できます。

【おすすめ独自ドメイン取得サービス↓】

お名前.com公式サイト
ムームードメイン公式サイト
XServerドメイン公式サイト
シンドメイン公式サイト
スタードメイン公式サイト

ラッコドメイン公式サイト