.store はネットショップ向けの名前として選ばれることが多い新 gTLD で、だれでも登録できます。ただし EC サイトでは、ドメインが決済代行会社の審査、注文メールの到達、Google Merchant Center の確認などと結びつくため、後からドメインを変えるのが一般的なサイトより大変です。この記事では、.store を取得する前・取得直後・ショップ公開前・運用中の4段階に分けて、確認しておきたい項目をチェックリストの形で整理します。
.store ドメインの前提
.store は 2016年ごろから一般登録が始まった新 gTLD で、レジストリは Radix 系の事業者と案内されています。登録者の業種や国籍による制限はなく、実際に店舗を持っていなくても取得できます（2026年10月現在）。条件は登録時にレジストリとレジストラの規約で確認してください。
DNS や SSL/TLS 証明書の扱いは .com と同じで、WordPress や WooCommerce も特別な設定なしで動きます。Google は新 gTLD を他の gTLD と同じように扱うと説明しており、.store だから検索で有利・不利になるということもありません。
気をつけたいのは技術面よりも、費用・信頼・ショップ運営との結びつきです。
取得前のチェック
名前と商標
- 店名やブランド名と同じ綴りになっているか（ハイフンの有無、ローマ字表記の揺れ）
- 他社のブランド名や商品名を含んでいないか。特許庁の J-PlatPat で似た商標がないかを確認する
- 口頭やチラシで伝えたときに聞き間違えにくいか
他社の商標を含む名前は、商標権者からの紛争処理手続き（UDRP など）でドメインを失うおそれがあります。
費用
- 初年度価格だけでなく、2年目以降の更新費用を確認したか
- 希望の名前がプレミアムドメインになっていないか。プレミアムは更新もプレミアム価格のままのことが多い
- 見積もりは「更新費用 × 運営する予定の年数」で比べたか
レジストラ
- 自動更新に対応し、支払い失敗時にメールなどで知らせてくれるか
- DNS 管理画面で TXT・CAA・MX など必要なレコードを設定できるか
- 二要素認証でアカウントを保護できるか
- サポートの言語と対応時間が自社の体制に合っているか
守りのための取得
- .com や .jp、.shop など、主要な TLD の同名ドメインも押さえるかを決めたか
- よくある打ち間違い（綴りの1文字違いなど）を押さえるかを決めたか
偽のショップサイトは本物の店名に似たドメインを使うことが多いため、守りの取得は費用と相談しながら判断します。すべてを取る必要はなく、自社名の .com と主力の TLD を押さえる程度でも効果があります。
取得直後のチェック
- 登録者メールアドレスに届く確認メールを開き、認証を済ませたか。放置すると一定期間後にドメインが一時停止される場合がある
- 自動更新を有効にし、登録しているカードの有効期限を確認したか
- レジストラロック（移管ロック）が有効になっているか
- 登録情報（WHOIS）の公開代行やプライバシー保護の状態を確認したか
- レジストラの管理画面に二要素認証を設定したか
- 更新通知メールが、担当者の異動後も届くアドレス（共有アドレスなど）になっているか
登録状態や有効期限は、ターミナルから RDAP で確認できます。
# 登録状態（status）と有効期限（events の expiration）を確認する
curl -sL https://rdap.org/domain/example.store | python3 -m json.tool
# ネームサーバーが意図したものになっているか
dig +short NS example.storegTLD の登録情報の照会は WHOIS から RDAP へ移行しています。whois コマンドで情報が出ない場合は RDAP を使ってください。
ショップ公開前のチェック
HTTPS と WordPress の URL
- SSL/TLS 証明書を発行し、
https://でアクセスできるか - WordPress の「設定」→「一般」の WordPress アドレスとサイトアドレスが
https://の .store ドメインになっているか http://やwww付きでアクセスしたときに、正規の URL へ 301 でリダイレクトされるか
# リダイレクト先とステータスを確認する
curl -sI http://example.store/ | grep -iE '^(HTTP|location)'
curl -sI https://www.example.store/ | grep -iE '^(HTTP|location)'カートや決済画面で混在コンテンツ（https のページに http の画像やスクリプトが混ざる状態）があると、ブラウザが警告を出したり読み込みを止めたりします。公開前にブラウザの開発者ツールのコンソールで警告が出ていないかを確認してください。
注文メールの到達
EC サイトでいちばん困るのは、注文確認メールや発送通知が迷惑メールフォルダに入る、または届かないことです。迷惑メール対策の統計では一部の新 gTLD が悪用の多い TLD として挙がることがあり、受信側が厳しめに判定する場合もあります。
- SPF レコードで、送信に使うサーバーやメール配信サービスを許可したか
- DKIM の署名を有効にし、公開鍵を DNS に登録したか
- DMARC レコードを設定したか（最初は
p=noneでレポートを集め、問題がないのを確かめてから強める） - WordPress のメール送信を、サーバーの PHP mail ではなく SMTP やメール配信サービス経由にしたか
- 送信元アドレス（From）が .store ドメインのアドレスになっているか
Gmail などの大手メールサービスは送信者に認証の設定を求める方針を強めているため、送信件数が少ないうちから設定しておくのが安全です。
決済と外部サービス
- 決済代行会社の加盟店審査に出す URL を、最終的に使う .store ドメインにしたか
- 決済サービスの Webhook や通知先 URL を .store ドメインで登録したか
- Apple Pay などウォレット決済を使う場合、決済サービス側でドメインの登録や確認が必要か、各社のドキュメントで確認したか
- Google Merchant Center で商品を掲載する場合、ウェブサイトの確認と申請を .store ドメインで済ませたか
これらは公開後にドメインを変えると、すべて登録し直しになります。審査をやり直す必要が出ることもあるため、ドメインは公開前に確定させておきます。決済の設定は、各決済サービスのテストモードで注文から返金まで一度通してから本番に切り替えてください。
信頼を補う表示
新 gTLD は、利用者から「見慣れないドメイン」と受け取られることがあります。運営者の情報をはっきり示すことが、ドメインの見慣れなさを補う方法になります。
- 特定商取引法に基づく表記（事業者名・所在地・連絡先など）を掲載したか
- 問い合わせ先と返品・交換の条件がすぐに見つかる位置にあるか
- SNS や既存の店舗サイトから .store サイトへリンクし、公式であることが分かるようにしたか
運用中のチェック
- 有効期限の1〜2か月前に、自動更新が動く状態かを確認しているか
- 証明書の有効期限を外部の監視サービスなどで見ているか
- DMARC レポートで、自社以外から自社ドメインを名乗るメールが送られていないかを確認しているか
- 似たドメインの偽サイトを見つけたときの連絡先（レジストラの不正利用窓口など）を把握しているか
まとめ
- .store はだれでも登録でき、技術的には .com と同じように使える
- 取得前は商標・更新費用・プレミアムかどうか・守りの取得を確認する
- 取得直後に確認メールの認証、自動更新、ロック、二要素認証を済ませる
- 公開前に HTTPS・注文メールの認証・決済や Merchant Center の登録を .store ドメインでそろえ、後から変えなくて済むようにする
- 運用中は更新・証明書・DMARC レポートを定期的に見る