Jetpack の接続エラーは、多くの場合「WordPress.com のサーバーからサイトに届かない」か「サイトの URL が接続時と変わった」ことが原因です。やみくもに切断・再接続を繰り返すより、先に原因を確かめてから再接続したほうが早く直ります。この記事では、Jetpack の接続の仕組み、エラーの原因を起きやすい順に確認する方法、安全な再接続の手順を説明します。
Jetpack の接続の仕組み
Jetpack は、サイトと WordPress.com のサーバーを相互に通信させて動くプラグインです。統計、バックアップ、ダウンタイム監視、関連記事などの機能は、WordPress.com 側で処理された結果を受け取っています。そのため、次の2つがそろっていないと接続できません。
- サイト側から WordPress.com へ通信できること
- WordPress.com からサイトへ、インターネット経由で通信できること
後者は見落とされがちです。サイトが外部から見えない、または特定の通信が遮断されていると、管理画面は普通に使えていても Jetpack だけがエラーになります。Jetpack はこの通信に XML-RPC（xmlrpc.php）や REST API を使っており、どちらを使うかはバージョンや機能によって変わります。
また、接続は「サイト全体の接続」と「ユーザーごとの接続」の2段階になっています。サイトを最初に接続した管理者が「接続の所有者」となり、この人のアカウントが削除されたり権限が下がったりすると、接続が不安定になることがあります。
まず診断ツールで状態を確かめる
Jetpack には接続状態を調べる診断機能があります。管理画面の Jetpack のメニューにあるデバッグ関連のページや、「ツール」→「サイトヘルス」に追加される Jetpack の項目で、接続のどこに問題があるかが表示されます（画面の場所や表記はバージョンで変わるため、目安として読んでください。記事の内容は（2026年10月現在）のものです）。
WP-CLI が使える場合は、次のコマンドで接続状態を確認できます。
# 接続状態を表示する
wp jetpack status
# より詳しい情報を表示する
wp jetpack status full診断結果に表示されたエラーの内容をメモしておくと、以降の切り分けや、サポートへ問い合わせる際に役立ちます。
原因1：xmlrpc.php や REST API が遮断されている
もっとも多い原因です。セキュリティ対策として XML-RPC を無効化していると、Jetpack の通信まで止まることがあります。
確認：サイトの外から、次のようにアクセスできるかを確かめます。
# 403 や 404 が返る場合は遮断されている可能性が高い
curl -I https://example.com/xmlrpc.php
# JSON が返れば REST API は応答している
curl -s https://example.com/wp-json/ | head -c 200xmlrpc.php にブラウザでアクセスすると「XML-RPC server accepts POST requests only.」という文字が表示されれば、ファイル自体には届いています。
対処：遮断している場所を探して、Jetpack の通信を通すように調整します。
- セキュリティプラグイン：XML-RPC の無効化や REST API の制限機能を確認する。Jetpack 用の例外設定を持つプラグインもある
- .htaccess やサーバー設定：
xmlrpc.phpへのアクセスを拒否する記述がないか確認する - ホスティング会社の WAF：管理画面で XML-RPC へのアクセス制限が有効になっていないか確認する
XML-RPC を全面的に開放するのが不安な場合は、ログイン試行回数の制限やアプリケーションパスワードの管理など、別の対策と組み合わせて判断してください。WordPress.com 側の通信元 IP アドレスは変わることがあるため、IP アドレスで許可する方法は保守が難しくなります。
原因2：サイトの URL が変わった（ステージングや移行後）
サイトの複製、ドメイン変更、HTTP から HTTPS への切り替えのあとに起きやすい原因です。Jetpack は接続時の URL を記録しているため、URL が変わると「同じ接続が別のサイトで使われている」と判断し、本番サイトの接続を守るために機能を制限することがあります。
この状態になると、管理画面に URL の変更について確認する通知が出ることがあります。選択肢はおおむね次の3つです（表記はバージョンで変わります）。
- このサイトは複製（ステージング）なので、本番と分けて扱う
- サイトを移行したので、接続を新しい URL へ移す
- 新しいサイトとして接続し直す
どれを選ぶかで、統計やバックアップ、購入済みプランの紐付けが変わります。迷った場合は、選ぶ前に Jetpack のサポートドキュメントを確認してください。
確認：「設定」→「一般」の「WordPress アドレス」と「サイトアドレス」が、意図した URL（https や www の有無を含む）になっているかを見ます。ステージング環境では、Jetpack のステージング用の設定（wp-config.php の定数など）を使うと、本番の接続と衝突しにくくなります。
原因3：サイトが外部から見えない・SSL に問題がある
次の環境では、WordPress.com からサイトに届かないため接続できません。
- ローカル開発環境（localhost など）
- Basic 認証や IP 制限で、サイト全体または
wp-admin以外も保護している - メンテナンスモードや「近日公開」モードで、外部からのアクセスを止めている
- SSL 証明書の期限切れや、中間証明書の設定漏れがある
- CDN のボット対策が、WordPress.com からのアクセスを人以外として遮断している
確認：別の回線（スマートフォンのモバイル回線など）からサイトを開けるか、ブラウザで証明書の警告が出ないかを確かめます。CDN を使っている場合は、ファイアウォールのログで遮断されたリクエストがないかを確認します。
対処：本番公開前のサイトなら、公開してから接続するのが無理のない手順です。開発環境で Jetpack の画面を確認したいだけなら、Jetpack のオフラインモード（JETPACK_DEV_DEBUG 定数など）を使うと、接続なしで一部の機能を試せます。逆に、本番サイトの wp-config.php にこの定数が残っていると接続できないので、あわせて確認してください。
原因4：接続の所有者がいない・プラグインの競合
接続した管理者のアカウントを削除した場合や、別の管理者へ引き継いだ場合は、別の管理者で接続をやり直す必要があることがあります。また、REST API を制限するプラグインや、ログイン処理を変更するプラグインが、Jetpack の認証の通信を妨げることもあります。
確認：ステージング環境で、Jetpack 以外のプラグインを1つずつ無効化し、接続できるようになるかを確かめます。本番環境で一括無効化すると、サイトの表示や決済に影響するので避けてください。
再接続の手順
原因を取り除いたら、次の順で再接続します。
- バックアップを取る：ファイルとデータベースのバックアップを取ります。Jetpack のバックアップ機能を使っている場合も、接続を切ると一時的に使えなくなるため、別の手段でも保存しておきます
- Jetpack とプラグイン全体を最新版にする：古いバージョンでは、接続の仕組みが現在の WordPress.com 側と合わないことがあります
- 接続を解除する：Jetpack のダッシュボードから接続を解除します。管理画面から操作できない場合は、WP-CLI の
wp jetpack disconnect blogを使えます - 管理者でログインした状態で接続し直す：Jetpack の画面から接続を開始し、WordPress.com のアカウントで承認します。購入済みのプランがある場合は、購入時と同じアカウントで接続します
- 動作を確認する：診断ツールで接続が正常になったか、統計やバックアップなど使っている機能が動いているかを確かめます
# 管理画面から解除できない場合（実行前にバックアップを取る）
wp jetpack disconnect blog
# 再接続は管理画面から行い、その後に状態を確認する
wp jetpack status再接続しても同じエラーが出る場合は、接続が切れた原因が残っています。原因1〜3を見直すか、診断結果を添えて Jetpack のサポートに問い合わせてください。
作業時の注意点
- 接続を何度も切り替えない：短時間に解除と接続を繰り返すと、状態がかえって分かりにくくなります
- WordPress.com 側の表示も確認する：WordPress.com のアカウントにログインし、サイトの一覧に対象サイトが残っているか、重複していないかを確認します
- 個人情報の扱い：Jetpack の統計やフォームなどは WordPress.com 側でデータを処理します。利用する機能に応じて、プライバシーポリシーの記載を確認してください
まとめ
- Jetpack の接続エラーは、WordPress.com からサイトへの通信の遮断か、URL の変更が主な原因
- まず診断ツールや
wp jetpack statusで状態を確かめ、エラーの内容をメモする xmlrpc.phpや REST API の遮断、URL の変更、外部から見えない環境、接続の所有者の不在の順に確認する- 原因を取り除いてから、バックアップを取り、最新版にして、解除と再接続を行う
- 再接続後は、使っている機能が実際に動いているかまで確かめる