この記事の対象: 取得済みの独自ドメインをShopifyストアに向けたい事業者・制作担当者
読了時間: 約14分
Shopifyでストアを作り終えて、最後に残るのがドメインの設定です。◯◯◯.myshopify.com のままでは公開できないので、すでに持っている独自ドメインをつなぐことになります。
ここでつまずく人が多いのは、Shopifyの管理画面に「接続する」と「移管する」という似た選択肢が並んでいるからです。名前は似ていますが、やっていることも、失敗したときの被害も、まるで違います。特に既存サイトを運用中の会社がここを間違えると、サイトだけでなく会社のメールが止まります。
この記事では、他社で取得したドメインをShopifyに向ける具体的な手順と、DNSのどのレコードを触るのか、そしてメールを止めないための注意点を順に書きます。作る側が実際に確認している順番そのままで進めます。
Shopifyのドメイン「接続」と「移管」はどう違うか
まず用語を揃えます。Shopify管理画面の「設定 → ドメイン」には、次の2つの入口があります。
- 既存のドメインを接続する（Connect existing domain）
- ドメインを移管する（Transfer domain）
この2つは目的が違います。
接続＝ドメインはそのまま、向き先だけ変える
接続は、ドメインの管理はこれまでのレジストラ（お名前.com、ムームードメイン、Xserverドメイン、Cloudflare Registrarなど）に置いたまま、DNSの設定だけを書き換えてShopifyのサーバーを指すようにする方法です。
ドメインの所有者情報も、更新の請求も、これまで通りレジストラ側にあります。変えるのはDNSレコードだけです。作業は短時間で終わり、間違えてもレコードを元の値に戻せば復旧できます。
移管＝ドメインの管理そのものをShopifyに引っ越す
移管は、ドメインの管理権限ごとShopifyに移すことです。レジストラが変わるので、更新料の請求先もShopifyになり、DNSの管理画面もShopify側になります。
こちらは手続きに数日かかり、条件もあります。ドメインのロック解除と認証コード（AuthCode / EPPコード）の取得が前提で、取得直後や直近で移管したばかりのドメインは、ICANNのルールにより60日間は移管できません。
接続（おすすめ）
- レジストラは今のまま
- DNSレコードを書き換えるだけ
- 反映は数十分〜48時間
- 間違えても戻せる
- メールのMXは自分で守る
移管
- 管理がShopifyへ移る
- 認証コードとロック解除が必要
- 手続きに数日かかる
- 取得・移管から60日以内は不可
- DNS管理画面もShopify側に
結論から言うと、既存サイトを運用している会社は、まず「接続」を選ぶべきです。移管は「ドメインの管理先を一本化したい」という運用上の都合で選ぶもので、Shopifyでストアを公開するために必須の作業ではありません。
移管を選んでいい場面、避けるべき場面
移管が向くのは、次のような条件がそろったときです。
| 条件 | 移管の向き不向き |
|---|---|
| ドメインをShopifyストアでしか使っていない | 向く。管理先が1つにまとまる |
| 会社のメールが同じドメインで動いている | 慎重に。DNS管理画面が変わる |
| サブドメインで別サーバーの何かが動いている | 慎重に。全レコードの移設が必要 |
| ドメイン取得・前回移管から60日以内 | 不可。ICANNのルールで移管できない |
| 複数の部署・業者がDNSを触っている | 避ける。誰がどこを触るか整理が先 |
制作の現場で見ていると、移管でトラブルになるのは決まって「そのドメインでメールも動いていた」ケースです。移管するとDNSレコードの管理画面ごと移るので、移管前のDNS設定を控えずに実行すると、メールのMXレコードやSPF・DKIMのTXTレコードが引き継がれずに消えます。移管は一手で戻せる作業ではないので、この記事では接続を軸に進めます。
Shopifyに独自ドメインを接続する手順
ここからが実作業です。手順自体は短いので、順番と確認ポイントを押さえれば迷いません。
この4つのうち、飛ばされがちなのが1番目です。ここを省くと、後述するメール停止事故につながります。
ステップ1｜今のDNSレコードを全部控える
DNSを触る前に、現在のレコードをまるごと控えます。画面のスクリーンショットではなく、テキストで残すのがおすすめです。後で見比べるときにコピーできるからです。
控えるべきレコードは次のとおりです。
| レコード種別 | 何のためにあるか | 触ってよいか |
|---|---|---|
| A | ドメインをIPアドレスに向ける | 触る（Shopifyのものに差し替え） |
| CNAME | 別のホスト名に転送する | 触る（wwwをShopifyへ） |
| MX | メールの配送先を決める | 絶対に触らない |
| TXT（SPF） | 送信元サーバーを認証する | 触らない |
| TXT（DKIM） | メールの署名を検証する | 触らない |
| CNAME（DKIM用） | 署名鍵を公開する | 触らない |
| TXT（DMARC） | なりすまし対策の方針 | 触らない |
| その他のA/CNAME | サブドメインの向き先 | 内容を確認してから判断 |
ターミナルが使える環境なら、dig コマンドで現状を書き出しておくと確実です。
# 現在のDNSレコードを一括で控える
DOMAIN=example.com
for TYPE in A AAAA CNAME MX TXT NS; do
echo "===== $TYPE ====="
dig +short "$DOMAIN" "$TYPE"
done
# wwwとメール関連のサブドメインも個別に見る
dig +short www."$DOMAIN" CNAME
dig +short mail."$DOMAIN" A
dig +short _dmarc."$DOMAIN" TXT
Windowsの場合は nslookup でも確認できます。
nslookup -type=MX example.com
nslookup -type=TXT example.com
nslookup -type=A example.com
実装のポイント：dig の結果はキャッシュされた値を返すことがあるため、レジストラの管理画面に表示されている「登録済みレコード一覧」も必ず見てください。管理画面にしか存在しないレコード（たとえばレジストラ独自のメール転送設定）があると、dig では拾えないことがあります。
ステップ2｜Shopify側にドメインを申告する
Shopify管理画面で 設定 → ドメイン → 既存のドメインを接続する を開き、使いたいドメインを入力します。
ここで入力するのはルートドメイン（example.com）です。www.example.com ではありません。wwwありで運用したい場合も、まずルートで登録してから、後段の「優先ドメイン」設定でwwwを主にします。
入力すると、Shopifyが設定すべきDNSレコードの値を表示します。この画面を開いたまま次のステップに進みます。
ステップ3｜レジストラ側でDNSレコードを書き換える
レジストラのDNS管理画面で、次の2つを設定します。
| ホスト名 | 種別 | 値 |
|---|---|---|
@（ルート） |
A | Shopifyが指定するIPアドレス |
www |
CNAME | shops.myshopify.com |
Aレコードの値は必ずShopifyの管理画面に表示されているものを使ってください。 他サイトに載っているIPアドレスをコピーしないこと。ShopifyはIPを変更することがあり、古い記事の値をそのまま入れると接続できません。CNAMEの向き先である shops.myshopify.com は、自分のストアのサブドメインではなくこの共通ホスト名です（◯◯◯.myshopify.com と書かないよう注意）。
既存のAレコードは差し替えます。 追加すると、ルートドメインが2つのIPを持つことになり、アクセスが旧サーバーとShopifyに振り分けられます。半分だけ新サイトが表示される、という最も気づきにくい壊れ方をするので、ここは必ず「置き換え」です。
つまずきやすい点：レジストラによっては、ルートドメインにAレコードを設定できず、代わりに ALIAS / ANAME / CNAMEフラット化 という仕組みを持っている場合があります（Cloudflare の CNAME Flattening など）。その場合はShopifyのIPを入れる代わりに、レジストラの案内に従ってフラット化されたCNAMEを使います。どちらの方式でも、次の「www」のCNAME設定は共通です。
Cloudflareを使っている場合は、もうひとつ注意があります。プロキシ（オレンジの雲マーク）を有効にしたままにすると、ShopifyのSSL証明書の発行が完了しないことがあります。接続確認が終わるまではプロキシをオフ（グレーの雲＝DNS only）にしておくのが安全です。
ステップ4｜反映を待って検証する
DNSの変更は即座には行き渡りません。世界中のDNSキャッシュが切り替わるまで、短ければ数十分、長ければ48時間程度かかります。設定直後に「表示されない」と慌てないことです。
反映を早めたいなら、切り替えの数日前に対象レコードのTTLを短くしておくという手があります。TTLはそのレコードをキャッシュしてよい秒数なので、既定の3600秒（1時間）などを300秒程度に下げておくと、切り替え当日の待ち時間が短くなります。TTLの短縮自体が行き渡るのにも旧TTLぶんの時間がかかるので、前日ではなく数日前に下げておくのがコツです。切り替えが落ち着いたら元に戻します。
Shopify管理画面のドメイン設定に「接続済み」と表示され、SSL証明書の発行が完了すればゴールです。この証明書はShopifyが自動で発行するので、自分で用意する必要はありません。ただし発行にはDNSが正しく向いていることが前提なので、DNSの反映待ちの間は「保留中」のまま止まって見えます。
検証はコマンドで行うのが早いです。
DOMAIN=example.com
# ルートがShopifyのIPに向いているか
dig +short "$DOMAIN" A
# wwwがShopifyのCNAMEに向いているか
dig +short www."$DOMAIN" CNAME
# HTTPSで正しく返るか（リダイレクトも追う）
curl -sIL "https://$DOMAIN" | grep -Ei '^(HTTP|location|server)'
# 証明書の発行者と有効期限を見る
echo | openssl s_client -connect "$DOMAIN":443 -servername "$DOMAIN" 2>/dev/null \
| openssl x509 -noout -issuer -dates
curl の結果に HTTP/2 200 と、Shopify由来のヘッダーが返れば接続できています。リダイレクトが想定どおりか（wwwありに寄せているか、なしに寄せているか）もここで確認できます。
対応環境：dig はmacOS・Linuxに標準搭載、Windowsでは nslookup を使うか、WSLまたは DNS Checker のようなWeb上の確認ツールで代用できます。openssl s_client はmacOS・Linuxで利用できます。
メールを止めないための注意点｜MXレコードの扱い
ここがこの記事で一番大事なところです。ドメイン切り替えで実害が出るのは、サイトではなくメールです。
サイトが数時間表示されないのは、痛いですが取り返せます。しかしメールが止まると、その間に届くはずだった注文の問い合わせも、取引先からの連絡も、送信元にエラーを返して消えます。しかも本人はしばらく気づきません。「最近メールが減ったな」と思った頃には数日経っています。
なぜドメイン設定でメールが止まるのか
Webサイトの向き先を決めるのはAレコード、メールの配送先を決めるのはMXレコードです。この2つは別のレコードなので、本来は片方を変えてももう片方には影響しません。
事故が起きるのは、次の2パターンです。
- DNSレコードを「全部消してから入れ直した」
移管や、DNSサーバーの切り替え（ネームサーバー自体の変更）をすると、レコードが白紙になります。Aレコードだけ入れ直してMXを忘れると、その瞬間からメールが宛先不明になります。 - ネームサーバーごとShopifyや別事業者に向けた
「接続」ではなくネームサーバーを変更してしまうと、そのドメインのDNSを管理する場所自体が移ります。移った先には以前のMXレコードが存在しないので、同じ結果になります。
つまり、Aレコードの書き換えだけで済ませる限り、メールは止まりません。危ないのは「DNSの管理場所ごと動かす」操作です。
切り替え前に必ず控える3種類
メール関連で控えておくべきレコードは、最低でも次の3つです。
| レコード | 典型的な値の形 | 消すとどうなるか |
|---|---|---|
| MX | aspmx.l.google.com（優先度つき） |
受信が全部止まる |
| TXT（SPF） | v=spf1 include:... ~all |
送信メールが迷惑メール判定される |
| TXT / CNAME（DKIM） | 長い公開鍵、または署名用CNAME | 署名検証に失敗し、到達率が落ちる |
DMARCレコード（_dmarc.example.com のTXT）を設定している場合はそれも控えます。SPFとDKIMが崩れた状態でDMARCのポリシーが reject になっていると、自社から送ったメールが相手に届かなくなります。
つまずきやすい点：MXレコードには優先度（プリファレンス値）があります。1 aspmx.l.google.com の「1」の部分です。入れ直すときにこの数字を落とすと、複数サーバーの優先順位が壊れます。値だけでなく優先度もセットで控えてください。
もうひとつ見落とされやすいのが、メール配信サービス用のサブドメインです。配信ツールやカスタマーサポートツールを使っていると、mail.example.com や em1234.example.com のような送信専用サブドメインにCNAMEやTXTが刺さっていることがあります。これらはWebの向き先とは無関係ですが、DNSを白紙にすると一緒に消えます。控える対象は「ルートのレコード」だけでなく「登録済みレコード一覧の全行」です。
切り替え後にメールの生死を確かめる
サイトが表示されたら終わり、にしないことです。切り替え後は必ずメールの往復を確認します。
DOMAIN=example.com
# MXがちゃんと生きているか
dig +short "$DOMAIN" MX
# SPFが消えていないか
dig +short "$DOMAIN" TXT | grep spf1
# DMARCの方針
dig +short _dmarc."$DOMAIN" TXT
この3つが切り替え前に控えた内容と一致していれば、DNS上は無事です。そのうえで、外部のアドレス（Gmailなど）から自社ドメイン宛に1通送り、届くか確認するのが最終チェックです。DNSが正しくても、旧サーバー側でメールアカウントが停止されていれば届きません。コマンドで見えるのはDNSの状態までで、メールサーバーの稼働までは保証してくれません。
受信だけでなく送信も試してください。自社アドレスから外部のGmailへ1通送り、受信側で「メッセージのソースを表示」を開いて SPF: PASS DKIM: PASS が並んでいるかを見ます。ここが FAIL や NONE なら、SPFかDKIMのレコードが欠けています。受信は生きているので気づきにくく、しばらく経ってから「うちのメールが相手の迷惑メールに入る」という形で表面化します。
旧サーバーの契約を切るタイミング
既存サイトからShopifyに移す案件で、切り替えと同時に旧サーバーを解約するのは早すぎます。旧サーバーには次のものが残っている可能性があります。
- メールアカウントと過去のメールデータ
- 旧サイトの画像・PDF（外部から直リンクされていることがある）
- サブドメインで動いている別システム（採用サイト、予約フォームなど）
- 問い合わせフォームの送信ログ
メールの移行が完全に済み、過去データの退避が終わるまで旧サーバーを残すのが現実的な進め方です。目安としては、切り替え後にひと月ぶんの受信を通し、月次の定型メール（請求書、システムからの自動通知など）が新環境に届くのを確認してから解約すると安全です。ドメインとサーバーの持ち方そのものを整理したい場合は、費用と名義の観点をまとめた記事も参考になります。
サブドメイン運用という選択肢
「ドメインをShopifyに向けたいが、既存サイトは残したい」というケースは珍しくありません。この場合、ルートドメインを触らずにサブドメインでECを立てる方法があります。
ルートとサブドメインの使い分け
example.com（ルート）をShopifyへ
- コーポレートとECを一体で運用
- ドメイン評価が1つに集まる
- 既存サイトは移設か廃止が前提
shop.example.com をShopifyへ
- 既存サイトはそのまま残せる
- 切り戻しが簡単（CNAME1本）
- 評価は分かれる
サブドメイン運用は、既存サイトのAレコードに一切触らずに済むのが利点です。追加するのは shop のCNAMEを shops.myshopify.com に向ける1行だけ。ルートのAレコードもMXレコードも触らないので、事故が起きる余地がほぼありません。
一方で、検索エンジンからはサブドメインが別サイトとして扱われる傾向があるため、ドメイン全体の評価を集めたい場合はルートに寄せたほうが有利です。
サブドメイン名は後から変えにくいことも頭に入れておいてください。shop store ec のどれにするかは好みの問題に見えますが、一度公開して検索結果や外部リンクが付いたあとに変えると、リダイレクト設計をやり直すことになります。日本語圏の利用者にとって最も意味が伝わりやすく、印刷物にも書きやすいのは shop です。特段の理由がなければここに寄せて構いません。
このあたりの判断は、そもそもコーポレートサイトとECをどう配置するかという設計の話に直結します。Shopifyを1つのドメインでコーポレートとECの両方に使う考え方は、別記事で詳しく書いています。
段階的に切り替えるという手
公開日をずらせない案件では、次の順序で進めると安全度が上がります。
- まず
shop.example.comでShopifyを公開し、動作確認と検収を済ませる - 決済・配送・メール通知まで実注文相当のテストを通す
- 問題がなければルートドメインのAレコードを差し替える
- 旧サブドメインからルートへ301リダイレクトを設定する
この順にすると、ルートを触る段階では「サイトが動くこと」がすでに確認済みになります。DNSの反映待ちの間にバグを踏む、という最悪の組み合わせを避けられます。
検収段階のサブドメインを検索結果に出したくない場合は、Shopifyのパスワード保護を有効にしたまま検収を進めるのが確実です。パスワード保護中はクローラーも中身を読めないので、テスト用URLが先にインデックスされる心配がありません。
配送設定や注文確認メールなど、公開前に詰めておくべき設定は別途あります。
制作会社が公開前に見ているチェックポイント
ドメインがつながったあと、公開までに確認している項目を挙げます。手順書には書かれていないが、抜けると後で効いてくるものです。
優先ドメインをどちらかに固定する
example.com と www.example.com の両方でアクセスできる状態は、SEO上も運用上も好ましくありません。Shopifyの管理画面では、接続したドメインのうち1つをプライマリドメインに指定でき、もう一方は自動で301リダイレクトされます。
どちらを主にするかは、既存サイトの実績を引き継げるほうを選ぶのが原則です。すでにwwwありで長く運用してきたサイトなら、被リンクも検索結果もwwwありに蓄積されています。ここでwwwなしに変えると、リダイレクトは効くものの、わざわざ一段階挟むことになります。新規ドメインなら好みで構いません。
旧URLからのリダイレクト設計
既存サイトからの移行なら、旧URLの受け皿が要ります。Shopifyでは 設定 → アプリと販売チャネル → オンラインストア → ナビゲーション → URLリダイレクト で個別に設定できます。
全ページを1対1で移す必要はありませんが、少なくとも次は拾ってください。
- 検索流入が多かったページ（Search Consoleの上位ページ）
- 外部から被リンクを受けているページ
- 名刺・チラシ・広告に印刷されているURL
- 旧サイトのサイトマップに載っていた主要カテゴリ
つまずきやすい点：ドメイン切り替え後にリダイレクトを設定しようとすると、旧サイトのURL一覧が取得できなくなります。切り替え前に旧サイトのURL一覧を書き出しておくのが正解です。Search Consoleの「ページ」レポートをCSVで書き出し、旧サイトの sitemap.xml も保存しておけば、移行後に突き合わせられます。
Search Consoleとアナリティクスの付け替え
ドメインを切り替えると、Google Search Consoleのプロパティ側は自動では追従しません。サブドメインを新設した場合は、そのサブドメインを新規プロパティとして登録する必要があります。ドメインプロパティ（example.com 全体）で登録してあれば、サブドメインも含めて拾えます。
所有権確認の方法にも注意が必要です。 ドメインプロパティはTXTレコードで所有権を確認します。DNSを触る過程でこのTXTを消してしまうと、Search Consoleの所有権が失効してデータが見られなくなります。控えるレコードの一覧に、この確認用TXTも必ず含めてください。
GA4のタグは、テーマに直接埋め込んでいる場合と、Shopifyの標準連携やGoogleチャネル経由で入っている場合があります。両方入っていると二重計測になるので、切り替えのタイミングで一度どこから入っているかを洗い出してください。
パスワード保護を外し忘れない
Shopifyのオンラインストアには、公開前にパスワードで閉じておく機能があります。ドメインをつないでも、この保護が有効なままだとアクセス者はパスワード入力画面に飛ばされます。DNSは正しいのにサイトが見えない、という問い合わせでよくある原因です。
設定 → 販売チャネル → オンラインストア → 各種設定（テーマ画面の「パスワードで保護する」）から解除します。公開直前のチェックリストに必ず入れてください。
アプリが埋め込んだスクリプトの向き先
ドメイン変更にともなって、外部サービス側に登録したURLが古いままになることがあります。よくあるのは次の3つです。
| 対象 | 古いままだと何が起きるか |
|---|---|
| 決済サービスの管理画面のドメイン設定 | 決済完了後の戻り先が myshopify.com になる |
| 広告アカウントのコンバージョン設定 | URL条件で計測しているとカウントされなくなる |
| メール配信ツールの差出人ドメイン | SPF/DKIMの認証が通らず到達率が落ちる |
アプリを多く入れているストアほど、この付け替え漏れは起きやすくなります。そもそもアプリを増やすかどうかの判断軸については、別記事で線引きを書いています。
実際に運用している側から見た、ドメイン設計の勘どころ
Soreiine!!を運営している会社は、受託でShopifyを構築するだけでなく、自社でもShopifyストアを運用しています。Dawnテーマをベースに、アプリに頼らず自前で組んでいる機能もあります。運用側に立つと、ドメインまわりで気になる点が変わってきます。
ドメインは「誰の名義か」が一番の論点になる
技術的な手順よりも実務で問題になるのは、そのドメインを誰が管理しているかです。制作会社が代理で取得したドメインだと、乗り換えのたびに「取得元に連絡が取れない」「認証コードが出てこない」という足止めが起きます。
ドメインの名義は事業者本人、レジストラのアカウントも事業者本人が持ち、制作会社にはDNSの編集権限だけを渡す。この形にしておくと、制作会社を変えてもドメインは動かせます。最初にここを決めておくだけで、数年後の選択肢が保たれます。
すでに制作会社名義になっている場合は、サイトの作り替えと同時にドメインだけ自社名義へ移すのが現実的です。移管には認証コードとロック解除が要るため、現在の管理者と連絡が取れるうちに動くのが鉄則です。連絡が取れなくなってからでは、更新期限が来て失効するのを待つしかなくなります。
DNSの変更履歴を残しておく
DNSは「誰がいつ何を変えたか」が残りにくい領域です。レジストラの管理画面に変更ログが残らないことも多く、何かが壊れたときに「先週と何が違うのか」を突き合わせられません。
自社の運用では、DNSを触る前後で dig の出力をテキストで保存して差分を取っています。手順というほどのものではありませんが、これがあるだけで原因の切り分けが早くなります。
# 変更前後で保存して差分を取る
DOMAIN=example.com
snapshot() {
for TYPE in A AAAA CNAME MX TXT NS; do
echo "--- $TYPE ---"
dig +short "$DOMAIN" "$TYPE" | sort
done
}
snapshot > dns-before.txt
# ここでDNSを変更し、反映を待ってから
snapshot > dns-after.txt
diff -u dns-before.txt dns-after.txt
意図した行だけが差分に出ていれば正常です。意図していない行が消えていたら、そこが事故の芽になります。特にMXやTXTが - 側に出ていたら、その場で止めて戻してください。
切り替えの時間帯を選ぶ
DNSの切り替えは、平日の午前中に行うのが合理的です。夜間や金曜夕方に実行すると、問題が起きたときにレジストラのサポートにも、社内の担当者にも連絡がつきません。反映に時間がかかる作業だからこそ、人が動いている時間にやります。
ECサイトの場合は注文が少ない時間帯を選びたくなりますが、DNSの切り替えでは注文が止まるわけではありません（旧サイトか新サイトのどちらかが表示されるだけです）。それよりも、トラブル時に人を呼べるかどうかを優先してください。
表示速度への影響も見ておく
ドメイン接続そのものは表示速度に影響しませんが、Cloudflareなどを間に挟んでいる場合は経路が増えます。プロキシを有効にしたままShopifyの前段にCDNを重ねると、キャッシュの挙動が読みにくくなり、テーマの更新が反映されないといった混乱が起きます。Shopify自体がCDNを持っているので、前段にさらにCDNを置く必然性は通常ありません。
よくある質問
Shopifyでドメインを接続すると、今のメールは使えなくなりますか？
Aレコードの書き換えだけで接続する限り、メールは影響を受けません。メールの配送先はMXレコードが決めており、Webサイトの向き先を決めるAレコードとは別のものだからです。ただし、ネームサーバーごと変更したり、ドメインをShopifyに移管したりするとDNSが白紙になり、MXを入れ直さなければメールが止まります。切り替え前に必ずMX・SPF・DKIMのレコードを控えてください。
ドメインを接続してから反映されるまでどれくらいかかりますか？
早ければ数十分、遅いと48時間程度かかります。DNSの情報は世界中のサーバーにキャッシュされているため、設定した瞬間に全員が新しい向き先を見るわけではありません。Shopify管理画面のドメイン設定が「接続済み」になり、SSL証明書の発行が完了すれば作業としては完了です。反映待ちの間は、古いサイトが表示される人と新しいサイトが表示される人が混在します。待ち時間を短くしたいなら、切り替えの数日前にTTLを下げておいてください。
Shopifyにドメインを移管したほうがいいですか？
必須ではありません。ストアを公開するだけなら「接続」で足り、こちらのほうが安全です。移管が意味を持つのは、そのドメインをShopifyストアでしか使っておらず、管理先を一本化したい場合に限られます。メールや他のサブドメインが同じドメインで動いているなら、移管は避けて接続を選んでください。なお、ドメイン取得から60日以内は移管できません。
ルートドメインとサブドメイン、どちらでShopifyを公開すべきですか？
既存サイトを残すならサブドメイン（shop.example.com）、Shopifyに一本化するならルートドメインです。サブドメインは既存のAレコードやMXレコードに一切触らずに済むため、事故の可能性がほぼありません。一方で検索エンジンからは別サイトとして扱われる傾向があるため、ドメイン全体の評価を集めたい場合はルートに寄せます。段階的に進めるなら、まずサブドメインで公開して検収し、後からルートに移す方法もあります。
DNSを書き換えたのにサイトが表示されません。何を確認すればいいですか？
まず dig +short example.com A で、実際にShopifyのIPに向いているかを見てください。向いているのに表示されないなら、Shopifyのパスワード保護が有効なままか、SSL証明書の発行が完了していない可能性が高いです。古いAレコードを消さずに追加していると、アクセスのたびに旧サーバーとShopifyに振り分けられて「たまに見える」状態になります。この場合はレコードが2行ある状態なので、古いほうを削除してください。
ドメイン設定を元に戻したくなったら、どうすればいいですか？
「接続」で進めていれば、控えておいたAレコードとCNAMEの値に書き戻すだけで元のサイトに戻ります。これがステップ1で現状を控える最大の理由です。旧サーバーを解約していなければ、反映を待つだけで復旧します。一方、移管してしまった場合は、別のレジストラへ移管し直す手続きが必要で、しかも移管から60日間はそれ自体ができません。「戻せるかどうか」が接続と移管の実質的な違いです。
まとめ
Shopifyへの独自ドメイン設定は、作業自体は短時間で終わります。難しいのは手順ではなく、触ってはいけないものを見分けることです。
要点を整理します。
- 「接続」と「移管」は別物。 既存サイトを運用しているなら、まず接続を選ぶ
- 触るのはAレコードとCNAMEだけ。 MX・SPF・DKIMには手を出さない
- 切り替え前にDNSの全レコードをテキストで控える。 これが唯一の保険になる
- 古いAレコードは追加ではなく置き換え。 残すと半分だけ壊れて気づけない
- 既存サイトを残したいならサブドメイン。 ルートを触らないので事故が起きない
- サイトが見えたら終わりではない。 メールの受信と送信、両方の往復まで確認して初めて完了
ドメインは、サイトを作り替えても残り続ける資産です。切り替えのたびに誰かの善意で乗り切るのではなく、名義と管理権限を整理し、変更前の状態を残しておく。この2つを習慣にしておけば、次にサイトを作り替えるときも同じ苦労を繰り返さずに済みます。
