SiteGuard「閲覧できません」の直し方|ConoHa WING
※本記事にはプロモーション(広告)が含まれています。
WordPressでAdSenseのコードを貼って保存しようとしたら、画面が切り替わって「閲覧できません (Forbidden access)」。下には「Powered by SiteGuard Lite」の文字。でも、プラグイン一覧を見てもSiteGuardなんて入っていない……。そんな状態で困っている方に向けた記事です。
この記事では、この画面の正体と、止められた操作を通すための手順を書きます。僕はConoHa WINGでこのブログを運営していて、AdSenseのコードを保存したときと、GitHub Actionsから画像をアップロードしたときの2つの場面で、この画面に止められました。どちらもWordPressではなく、ConoHa WING側の設定で解決しています。
読み終わるころには、「どこを開いて、何をすればいいか」と「セキュリティを下げすぎないための注意点」が分かるはずです。
結論:正体はConoHa WINGのWAF。ログから除外すれば通るようになる
- 「閲覧できません Powered by SiteGuard Lite」を出しているのは、ConoHa WINGのWAF(ウェブアプリケーションファイアウォール。サーバーの手前で攻撃っぽい通信を止める仕組み)でした。WordPressのプラグインではありません
- 直し方:ConoHa WINGのWAFの画面でブロックの記録(ログ)を開き、止められた記録を「除外」する。WAFはONのままで、その操作だけ通るようになります
- 1回きりの保存なら:WAFを一時的にOFFにして保存し、すぐONに戻す方法もあります(僕はAdSenseのコードのときはこちらの方法でした)
まず確認:プラグイン一覧にSiteGuardはありますか?
「SiteGuard」で検索すると、WordPressのプラグイン「SiteGuard WP Plugin」の情報がたくさん出てきます。ただ、僕の環境ではプラグイン一覧にSiteGuardは入っておらず、正体はConoHa WING側のWAFの機能でした。
「SiteGuard Lite」と「SiteGuard WP Plugin」は別もの
- SiteGuard Lite:株式会社ジェイピー・セキュアの発表(2013年)によると、Webサーバーのモジュールとして動く「ホスト型WAF」です。2012年の製品紹介記事では、SQLインジェクションやクロスサイトスクリプティングなどの攻撃を重点的に防ぐ製品とされています
- SiteGuard WP Plugin:WordPress.orgの説明(2026年11月時点)によると、ログインページと管理ページのセキュリティを強化するプラグインです
画面に「SiteGuard Lite」と出ていて、プラグイン一覧にSiteGuardが無いなら、サーバー側のWAFを疑うのが近道です。
「Apacheの403」とも見分けておく
ConoHa WINGでは、別の機能でも403(アクセス拒否)になることがあります。画面の見た目で見分けられます。
- 「閲覧できません」+「Powered by SiteGuard Lite」の画面 → この記事のWAF
- 「403 Forbidden」だけのApacheのエラーページ → 海外アクセス制限などの可能性
僕はGoogle Colabから記事を投稿したときに、後者の403にも引っかかりました。そちらの原因と直し方はこちらにまとめています。
→ ConoHa WINGでREST APIが403に|原因と直し方
僕の場合:2つの場面で「閲覧できません」になった
場面1:AdSenseのコードを「WP Headers And Footers」に貼って保存したとき
ブラウザからの普通の操作でも起きました。AdSenseのコード(scriptタグ)を、ヘッダーにコードを追加できるプラグイン「WP Headers And Footers」に貼って保存したら、「閲覧できません」の画面になりました。
SiteGuard Liteはクロスサイトスクリプティング(ページに不正なスクリプトを埋め込む攻撃)を防ぐ製品なので、scriptタグを含む内容を送ったことが攻撃に似て見えた可能性があります。ただし、WAFがどの判定で止めたのかまでは、この記事では確かめていません。
このときは、WAFを一時的にOFFにして保存し、ONに戻しました。
場面2:GitHub Actionsから画像をアップロードしたとき
もう1つは、ブログの自動投稿の仕組みを作っていたときです。GitHub Actions(GitHubの上でプログラムを自動実行できる機能)から、WordPressのREST APIの /wp-json/wp/v2/media に画像をアップロードしたら、403で「閲覧できません (Forbidden access) Powered by SiteGuard Lite」が返ってきました。
WAFを一時的にOFFにすると、アップロードは成功しました。ただ、自動投稿のように繰り返し動く処理で、毎回OFFにするのは現実的ではありません。そこでWAFの画面のブロック履歴から該当の記録を選んで除外登録し、WAFをONに戻したところ、ONのままでもアップロードが成功するようになりました。
ブロック履歴には記録がいくつも並んでいたので、URLを一つ一つ確認して、画像のアップロード先(/wp-json/wp/v2/media)の記録を探しました。
手順:WAFのログから除外して、ONに戻す
ConoHa WINGの公式サポートによると、WAFの設定は次の場所にあります(2026年11月時点)。
- ConoHaのコントロールパネルにログインし、上部メニューの「WING」を開く
- 左メニューの「サイト管理」を開く
- 「サイトセキュリティ」を開き、上のタブから「WAF」を選ぶ
画面には「利用設定」があり、公式サポートの説明ではここを「ON」にするとWAFが有効になります。
1. ログを開いて、該当の記録を「除外」する
記録を見つけやすくするため、先に「閲覧できません」になった操作をもう一度やっておくと、新しい記録が残ります。そのうえで、公式サポートによると次の手順で除外します。
- 「表示切替」で「ログ」を選ぶ(WAFが遮断した攻撃の情報が一覧で出ます。「絞込み条件」も使えます)
- 除外したい記録の「除外」をクリックする
- 確認画面で「はい」をクリックする
除外した内容は、「表示切替」で「除外中」を選ぶと確認でき、「除外解除」で元に戻せると説明されています。
2. WAFがONになっていることを確かめて、もう一度試す
原因を確かめるためにWAFをOFFにしていた場合は、ここで必ず「ON」に戻します。そのうえで同じ操作をして、通れば完了です。
除外やOFFのときに気をつけたいこと
WAFはサイトを攻撃から守るための機能なので、緩めるときは次の2点を意識しておくと安心です。
- OFFにしたままにしない:一時的にOFFにしたら、作業が終わりしだいONに戻す
- 除外は、自分の操作だと分かる記録だけにする:ログには本物の攻撃の記録も残っている可能性があります。まとめて除外せず、止められた操作に当たる記録だけを選びましょう。使わなくなった仕組みの除外は、「除外解除」で戻すことも考えておくとよいです
それでもダメなとき
- 画面がApacheの「403 Forbidden」に変わった:WAFは通っていて、海外アクセス制限など別の制限に止められている可能性があります(上で紹介した403の記事を参照)
- ログに該当しそうな記録が見つからない:止めているのがWAFではない可能性もあります。画面に「SiteGuard」の文字が出ているか、もう一度確かめてみてください
- APIで401が返ってくる:サーバーは通っていて、WordPress側の認証(ユーザー名やアプリケーションパスワード)に問題がある可能性があります。僕の場合は、スクリプトのユーザー名がひな形のままでした
僕はこのブログを開設したときからConoHa WINGを使っています。自動投稿の仕組みを作ったときはWAFに止められましたが、今回のように管理画面から除外できました。それ以外の普段の運営ではトラブルもなく、サーバーのことを意識せずにブログを書けています。これからWordPressを始めるためにサーバーを探している方は、公式サイトで機能や料金を確認してみてください。
まとめ
「閲覧できません (Forbidden access) Powered by SiteGuard Lite」が出たときのポイントをまとめます。
- プラグイン一覧にSiteGuardが無ければ、ConoHa WINGのWAFを疑う
- 「サイト管理」→「サイトセキュリティ」→「WAF」の「ログ」で、止められた記録を「除外」する
- 1回きりの保存なら、WAFを一時OFFにして保存し、すぐONに戻す方法もある
- OFFにしたままにしない。除外は自分の操作の記録だけにする
AdSenseのコードを貼っただけで止められると、何が起きたのか分かりにくいと思います。同じ画面で手が止まっている方の参考になればうれしいです。

ディスカッション
コメント一覧
まだ、コメントがありません