サーバー移転を外注に丸投げして、メール不通・決済エラー・検索順位急落——そんな悲劇を防ぐための依頼前確認事項を実案件ベースで解説します。
こんな経験、ありませんか？
「サーバーの契約更新のタイミングで、思い切って移転を業者に依頼した。作業完了の報告をもらったので確認してみると、サイトは表示されている。でも翌朝から、お客様からの問い合わせメールが一通も届いていない——」
これは実際にFivenine Designへ相談が来たケースです。神奈川県内の中小製造業のお客様で、取引先への見積メールがすべて未達になっていたことが、2日後になって初めて発覚しました。さらに調査を進めると、決済代行サービスのコールバックURLが旧サーバーを向いたままで注文が通っておらず、Googleのインデックスには旧IPが残ってページランクも揺れていました。
「サーバーが映っているからOK」——この思い込みが、サイト移転トラブルの温床です。本記事では、移転を依頼する前に必ず確認すべき項目と、実際に手を動かして検証するコマンド・設定例を具体的に紹介します。Web担当者の方が依頼書や仕様書に盛り込める内容になっていますので、ぜひ活用してください。
なぜ「サイトが映っているのに壊れる」のか
サーバー移転を「Webサイトのファイルを別のサーバーにコピーする作業」だと理解している業者は、残念ながら少なくありません。しかし実際には、1つのドメインに紐づくサービスは多岐にわたります。
flowchart TD
A[ドメイン example.com] --> B[Webサーバー HTTP/HTTPS]
A --> C[メールサーバー MXレコード]
A --> D[SPF / DKIM / DMARC 認証]
A --> E[SSL証明書]
B --> F[決済API コールバック]
B --> G[外部サービス Webhook]
B --> H[Googleサーチコンソール / Analytics]
C --> I[受信トレイ 問い合わせフォーム]DNSには「Aレコード（IPアドレス）」だけでなく、「MXレコード（メール）」「TXTレコード（SPF/DKIM）」「CNAMEレコード（サブドメイン）」など複数の設定が同居しています。業者がAレコードだけ書き換えて作業完了と報告する——これが「サイトは見えるのにメールが届かない」現象の典型的な原因です。
さらに、決済代行やフォームサービス・チャットツールなどは「特定のIPやドメインからのみ通信を許可する」ホワイトリスト設定を持つことがあります。サーバーのIPが変わると、これらがすべて認証エラーになります。
移転依頼前に確認すべき項目と検証コマンド
1. 現在のDNSレコードを全件書き出す
業者に移転を依頼する前に、今の設定をすべてスナップショットとして保存しておきます。これがないと、移転後に「何が変わったか」を比較できません。
# 主要レコードをまとめて確認
dig example.com ANY +noall +answer
# MXレコード（メール）
dig example.com MX +short
# TXTレコード（SPF/DKIMなど）
dig example.com TXT +short
# SPF確認（メールがどのサーバーから送信を許可されているか）
dig example.com TXT | grep spf
この出力をスプレッドシートに貼り付けて保存してください。移転後に同じコマンドを実行し、差分がないかを確認することが最初のチェックになります。
2. メール認証（SPF・DKIM・DMARC）の移行確認
メールが届かなくなる原因の多くは、SPFレコードが旧サーバーのIPを指したまま残っていることです。新サーバーのIPを含むSPFレコードに更新されているか、以下で確認します。
# SPFレコードの確認（新サーバーIPが含まれているか）
dig example.com TXT +short | grep "v=spf1"
# 期待する出力例（新サーバーIP 203.0.113.10 が含まれている）
# "v=spf1 ip4:203.0.113.10 include:_spf.google.com ~all"
# DKIMセレクターの確認（メーラーにより異なる）
dig default._domainkey.example.com TXT +short
DMARCポリシーが p=reject になっている場合、SPF/DKIMが正しく設定されていないとメールが受信側で完全に破棄されます。依頼書には「SPF・DKIM・DMARCレコードの移行と動作確認」を明示的に項目として入れてください。
3. SSL証明書の発行と自動更新の設定
Let's Encryptを使っている場合、新サーバーで改めて証明書を発行する必要があります。旧サーバーで発行した証明書をコピーしても、更新フックが動かないため90日後に切れます。
# Certbotで証明書の発行状態を確認
sudo certbot certificates
# 証明書の有効期限を確認
openssl s_client -connect example.com:443 -servername example.com \
</dev/null 2>/dev/null | openssl x509 -noout -dates
# 自動更新の動作テスト（--dry-runで実際には更新しない）
sudo certbot renew --dry-run
「SSL証明書を移行した」という報告が来たとき、必ず「自動更新の設定まで完了しているか」を確認してください。
4. 決済・外部API連携のコールバックURL変更
Stripe・PayPal・GMOペイメントゲートウェイなど決済サービスは、管理画面に「WebhookのURL」や「戻り先URL」を登録します。サーバーのドメインが変わっていない場合でも、IPホワイトリストや証明書の再認証が必要なケースがあります。
移転後に必ず実施すべきテスト手順：
# 決済サービスのWebhookが新サーバーに到達しているかをcurlで簡易確認
curl -X POST https://example.com/webhook/payment \
-H "Content-Type: application/json" \
-d '{"test": true}' \
-v 2>&1 | grep -E "< HTTP|Connected to"
# 期待する出力
# * Connected to example.com (203.0.113.10) ...
# < HTTP/2 200
新サーバーのIPアドレスが応答しているかとHTTPステータスが200かの2点を必ず確認してください。
よくある失敗パターンと対処法
移転後のSEOへの影響を最小化する
上のグラフは、当社が関わった移転案件のデータを元にした推計です。適切な手順を踏めば1〜2週間で元の流入量に戻りますが、丸投げ移転では2ヶ月経っても完全には回復しないケースが実際に存在します。
SEO観点で必ずやるべきことは以下の3点です。
- 301リダイレクトの確認：HTTPからHTTPSへの統一、www有無の統一が正しく設定されているか
- サーチコンソールでのURL変更申請：プロパティが正しく認識されているか
- クロールエラーの監視：移転後2週間はサーチコンソールのカバレッジレポートを毎日確認する
# リダイレクト確認（301が返っているか）
curl -I http://example.com
# Location: https://example.com/ が返れば正常
curl -I http://www.example.com
# Location: https://example.com/ が返れば正常（wwwなしに統一の場合）
サーバー管理、丸ごとお任せください
サーバー保守・運用
監視・障害対応・パフォーマンス改善まで、安定稼働をサポートします
※ 通常1営業日以内にご返信します
まとめ：移転を依頼する前の確認チェックリスト
冒頭のお客様のケースでは、Fivenine Designが入って4時間でメールの復旧、翌日には決済の疎通確認が取れました。しかし2日間の受注機会損失は取り戻せませんでした。移転後に慌てて対処するより、依頼前の確認に1時間をかける方が何倍もコストパフォーマンスが高いです。
以下のチェックリストを、業者への依頼書に添付してください。「これらをすべて対応範囲に含めること」を明示することで、認識のズレを事前に防げます。
移転作業そのものより、何をスコープに含めるかの合意がトラブルを防ぐ最大の鍵です。「サーバーが映っていれば完了」という認識の業者に当たってしまうと、本記事で紹介したような問題がすべて後から発覚します。
Fivenine Designでは、サーバー移転の計画立案から移転後の動作確認まで一貫して対応しています。「今の業者に任せて不安」「移転の仕様書を作りたい」という段階からでも相談を受け付けていますので、お気軽にお問い合わせください。
