TL;DR: WP STAGING は主要な WordPress ホスティングプロバイダーのほとんど (共有・マネージドの両方) で動作します。下の検証済みリストには、ホスト固有の注意点と、避けるべき非対応ホストの別リストも記載されています。
WP STAGING は WordPress 向けの高品質でエンタープライズレベルの Backup・Staging ソフトウェアであり、ほとんどのホスティングプロバイダーとサーバーに対応しています。リリースのたびに 1,000 以上の自動ユニットテストとエンドツーエンドテストを通過し、一貫したパフォーマンスを保証しています。
お使いのホスティングプロバイダーがここに記載されていない場合、それは単に当社がまだ WP STAGING でテストしていないだけです。ただし、お使いのホスティング環境でも WP STAGING が動作する可能性は非常に高いです。
Contents
WP STAGING 検証済み・対応ホスティングプロバイダー
下の表は、検証済みの各プロバイダーが WP STAGING の Staging (サブフォルダクローン) と Backup・移行機能にどれだけ対応しているかと、報告されている問題をまとめたものです。Known Issues 列の「—」は、当社にホスト固有の問題が報告されていないことを意味します。
| ホスト | Staging | Backup・移行 | 既知の問題 |
|---|---|---|---|
| Cloud86.io | ✓ | ✓ | — |
| DigitalOcean | ✓ | ✓ | — |
| Amazon AWS / Lightsail | ✓ | ✓ | — |
| BlueHost | ✓ | ✓ | — |
| Hostinger | ✓ | ✓ | — |
| GoDaddy | ✓ | ✓ | — |
| HostGator | ✓ | ✓ | PHP エラーが WordPress のデバッグログではなくホスト側のログにリダイレクトされることがあります |
| Strato | ✓ | ✓ | 一部のサーバーでは Backup パートごとに最大ファイルサイズ 4 GB の制限があります。大規模サイトでは Multipart Backup を使用してください |
| SiteGround | ✓ | ✓ | — |
| Hetzner | ✓ | ✓ | — |
| Microsoft Azure | ✓ | ✓ | — |
| InMotion Hosting | ✓ | ✓ | — |
| Bitnami AWS | ✓ | ✓ | — |
| Dimoweb | ✓ | ✓ | — |
| IONOS (標準プラン) | ✓ | ✓ | 一部のレガシーな事前構成プランにはファイル権限の制限があります — 非対応セクションの IONOS 1&1 を参照 |
| Doominio | ✓ | ✓ | — |
| WordPress.com | ✗ | ✓ | サブフォルダ Staging には非対応。Backup と移行は完全に動作します |
| Elementor Cloud | ✗ | ✓ | Staging には非対応。Backup は動作します |
Cloud86.io
Cloud86.io は Trustpilot で素晴らしい評価を獲得している、高速で信頼性の高い欧州のホスティングプロバイダーです。多くの顧客がすでにこのプラットフォーム上で WP STAGING を使用しているため、このプロバイダーは当社のリストの上位に値すると考えています。
DigitalOcean
DigitalOcean はクラウドインフラの大手プロバイダーで、使いやすいプラットフォーム・信頼性の高いサービス・優れたコストパフォーマンスで知られています。仮想マシンからマネージドデータベース、Kubernetes まで、幅広い製品を提供しており、開発者や企業がアプリケーションを構築・スケールするために必要なものをすべて揃えています。WP STAGING では 10 年以上にわたって自社サービスにも DigitalOcean を使用しており、その高いパフォーマンス・信頼性・優れたサポートを高く評価しています。
Amazon AWS と Amazon Lightsail
Amazon Lightsail
BlueHost
Hostinger
GoDaddy
Hostgator
Strato
制限事項: Strato のサーバーの中には、最大許容ファイルサイズが 4 GB に制限されているものがあります。サイトが 4 GB を超えていて WP STAGING の Backup 機能を使用したい場合は、Backup ファイルのサイズをより小さなチャンクに分割する必要があります。このフィルターを使えば、それが可能です。
Siteground
Hetzner
Microsoft Azure
InMotion Hosting
Bitnami AWS
Dimoweb
IONOS
Doominio
WordPress.com (一部制限あり)
WP STAGING の Backup・移行機能は、wordpress.com のホスティングプラットフォームに完全対応しています。
WordPress.com ホスティングプラットフォームの技術的制限により、同じシステム上のサブフォルダに WP STAGING で Staging サイトを作成することはできません。ただし、別のサーバーに空の WordPress サイトを用意し、WP STAGING の Backup 機能で WordPress.com からのサイト移行または WordPress.com への移行を行うことは可能です。
Elementor Cloud (Staging は不可、Backup は可能)
Elementor Cloud では WP STAGING の Backup 機能は非常によく動作するため、別のホスティングプロバイダーから Elementor への移行に役立ちます。
ただし、WP STAGING の Staging 機能は動作しません。Elementor は他の移行・Backup Plugin のインストールを許可していませんが、現時点では WP STAGING は許可されています。Elementor が今後も WP STAGING の利用を許可してくれることを期待しています。WP STAGING は CPU 使用率の低さとパフォーマンスにおいて卓越しているため、他の Backup Plugin のように禁止する理由はありません。
当社は無料の Staging 機能が Elementor Cloud で動作するよう取り組んでいます。完了し次第、ここを更新します。
WP STAGING 向けのホストの選び方
ホスティングのプラン階層によって WP STAGING のパフォーマンスは変わります。下の判断表を使って、ご自身のユースケースに合った階層を選んでください。
| ホスティング階層 | Staging | Backup | WP STAGING で典型的に注意すべき点 | 最適な用途 |
|---|---|---|---|---|
| 共有ホスティング | ✓ | ✓ | 厳しい PHP 実行時間の制限により、大規模なクローン処理が中断されることがあります。タイムアウトする場合はチャンク処理を有効化してください | 小規模サイト、低トラフィック |
| マネージド WordPress (例: SiteGround) | ✓ | ✓ | 多くのマネージドプランは完全対応です。Staging サブフォルダがプラットフォームのルールでブロックされていないか確認してください | 中規模サイト |
| VPS / クラウド (例: DigitalOcean、Hetzner) | ✓ | ✓ | 制限が最も少なく、PHP の上限やファイル権限を必要に応じて自由に調整できます | 開発者、大規模サイト |
| コンテナマネージド (例: Kinsta、WP Engine) | ✓ | ✓ | コンテナや環境の制限がサブフォルダ Staging に影響することがあります。Staging ワークフローでこれらのプラットフォームに依存する前にテストしてください | 高トラフィック、パフォーマンス重視のサイト |
当社の経験では、PHP 実行時間の制限が厳しい共有ホストが WP STAGING のクローン失敗の最も多い原因です。クローンが途中で停止する場合は、チャンク処理を有効にするとジョブがより小さなセグメントに分割され、ホストの時間制限内で完了します。
ホスト別のよくあるトラブルシューティング
SiteGround
SiteGround は Staging と Backup の両方で WP STAGING に完全対応しています。クローンが失敗した場合は、WP STAGING の Plugin ログでタイムアウトや権限エラーメッセージを確認してください。これらはマネージドの共有ホスティングプラットフォームで失敗の最も多い原因です。
BlueHost
BlueHost は完全対応です。BlueHost の共有プランでクローンが途中で停止する場合、最も可能性の高い原因は PHP の実行時間制限です。WP STAGING の設定でチャンク処理を有効化すると、クローンが許可された実行ウィンドウ内で完了する小さなステップに分割されます。
HostGator
HostGator を含む多くの共有ホストは、PHP エラーを WordPress のデバッグログに書き込むのではなく、独自のサーバー側ログにリダイレクトします。HostGator で WP STAGING の操作が静かに失敗する場合は、根本原因を特定するために、WP STAGING のログとあわせてサーバー側のエラーログを確認してください。
Strato
一部の Strato サーバーでは、Backup パートごとに最大ファイルサイズ 4 GB の制限があります。サイトがこのサイズを超えている場合は、このフィルターを使って Multipart Backup を有効化し、Backup を小さなチャンクに分割してください。
Kinsta と WP Engine
WP STAGING の Backup・移行機能は、標準的な WordPress インストールであればどこでも動作するように設計されています。Kinsta と WP Engine はコンテナベースのマネージド環境を使用しており、サブフォルダ Staging に制限を課す可能性があります。これらのプラットフォーム上で WP STAGING の Staging ワークフローに依存する前に、本番以外のサイトでテストクローンを実行することをお勧めします。
WP STAGING 非対応のホスティングプロバイダー
サーバーの制限や性能不足のため、WP STAGING は以下のホスティングプロバイダーでは動作しません。
WP STAGING と非互換で良い体験ができないことが判明しているホスティングプロバイダーがいくつかあります。
names.co.uk
2026 年 3 月 26 日更新: 最近、お客様から names.co.uk でホストされているサイトで WP STAGING がもう動作しないとの報告を受けました。当社はホスティングプロバイダーと連絡を取り、原因を特定しようとしています。
Aruba.it
2022 年 8 月 8 日更新: WP STAGING による Staging サイトと Backup の作成が Aruba.it で動作するようになりました。
Aruba には依然として Microsoft Windows Server 2012 R2 Standard を使用しているサーバーがあります。Aruba.it が WordPress サイトのルートフォルダに設定しているファイル制限のため、WP STAGING はそのような古いサーバーでは動作しません。そのような古い Web サーバー上のサイトを使用することはお勧めしません。
ホスティングプロバイダー aruba.it は WP STAGING で作成された Staging サイトに対応していません (2020 年 6 月 14 日時点)。その結果、Staging サイトはエラー 500 を返し、WordPress のデバッグログは無視されてシステムに書き込まれないため、問題のデバッグが不可能になっています。
想定される問題:
Aruba.it のクライアントサイトでは、データベース上の siteurl は https で正しく見えていても、WordPress の siteurl が常に http という誤ったスキームを返す現象を経験しました。これを解決して正しいプレフィックス付きの siteurl (http) を返すには、データベース内で siteurl を同じ値で再度更新する必要がありました。
この問題の原因はわかりませんが、不適切なデータベースキャッシュ設定、または http リンクに対する aruba.it のカスタムリダイレクトが原因の可能性があります。
また、データベースで http://example.com を検索することができず、検索語が即座に https://example.com に置き換えられたのも特筆すべき点です。これは HTTP から HTTPS へのデータベース内部のリダイレクトがあることを示しています。
IONOS 1&1 Web Hosting (一部プランで制限あり)
一部の IONOS ホスティングパッケージは、user/group 43:600 という閉じた環境で WordPress を実行します。これはおそらくワンクリックインストールスクリプトによる事前構成の WordPress インストールのようです。残念ながら、これらのユーザー権限では本番サイトのルートに新しいフォルダを作成できません。また、SFTP アカウントではルートディレクトリ内にカスタムフォルダを作成できません。wp-content/uploads フォルダ内からサイトをクローンして実行することも不可能です。すべてのファイルが制限されたユーザー / グループ 133320:600 で実行されるため、PHP ファイルを実行できないからです。
Crazydomains.com.au
crazydomains のサーバーでは、クローンや Push の処理でエラー 400・エラー 508「Resource Limit Reached」、その他のリソースエラーがファイルコピー処理中に発生します。これは I/O 制限を超えていることを示しています。crazydomain のサーバーが非常に遅いとの報告が複数のクライアントから寄せられています。
これは、サーバーに多数のクライアントを詰め込んでいるホストではないかと推測されます。そのため、各クライアントのパフォーマンスが良くありません。
したがって、crazydomains のホスティングプロバイダーに連絡して、最低限のリソースと動作するサイトを保証してもらうことをお勧めします。他のオプションとしては、別のホスティングプロバイダーに切り替えるか、crazydomains にもっと性能の良いサーバーへのサイト移動を依頼することです。
Elementor Cloud (Staging は不可、Backup は可能)
同一サブスクリプションで複数の WordPress サイトを持つことは Elementor Cloud では未対応のため、現時点ではそこにホストされているサイトから Staging サイトを作成することはできません。
ただし、WP STAGING の Backup 機能は動作します。
注: Elementor は他の移行や Backup Plugin のインストールを許可していませんが、現時点では WP STAGING は許可されています。Elementor が今後も WP STAGING の利用を許可してくれることを期待しています。WP STAGING は CPU 使用率の低さとパフォーマンスにおいて卓越しているため、他の Backup Plugin のように禁止する理由はありません。
Elementor Cloud には制限があります。例えば、すべての Plugin や競合 Theme をインストールすることは許可されていません。完全に独立したホスティングプロバイダーを利用すれば、より自由度が高くなります。ただし、Elementor Cloud のパフォーマンスが非常に良いことは認めざるを得ません。Elementor がすべての移行 Plugin をブロックせず、別のホストへのデータ移行を妨げない限り、お勧めできます。
サイトを Elementor へ、または Elementor から別のホストへ移行する際にサポートが必要でしたら、お気軽にお知らせください。お手伝いいたします。
WordPress.com (一部制限あり)
別のサーバーに空の WordPress サイトを作成し、WP STAGING の受賞歴のある Backup 機能を使って、そのもう一方のサイトにデータを移行できます。WP STAGING の Backup・移行機能は、WordPress.com でホストされている WordPress サイトでも 100% 動作します。
技術的な制限により、同じシステム上のサブフォルダに WP STAGING で Staging サイトを作成することはできません。wordpress.com のホスティングプラットフォームではインスタンスごとに 1 つの WordPress サイト (シングルサイトまたはネットワークサイトのいずれか 1 つ) しか許可されておらず、wp-content フォルダはコアの WordPress ディレクトリパスの外にあり、コアパスへのシンボリックリンクで結ばれています。WP STAGING は wordpress.com プラットフォーム上で Staging サイトを作成したり、本番サイトに Push したりすることはできません。
ホスティングプロバイダーの方で、ここに掲載をご希望ですか
ホスティングプロバイダー、会社オーナー、または技術的な問い合わせに対応されている方で、お客様がホストするサイトで WP STAGING が動作することを保証されたい場合は、お問い合わせください。
このリストに掲載されていないホスティングプロバイダーをご使用で、動作することを確認できる場合は、お知らせいただければここに追加いたします。
