最終更新日：
ブロックされたリソースの発生源がFacebookページプラグインだった件
Contents
サーチコンソールの「ブロックされたリソース」の頻発に悩む今日この頃。
GooglebotsがページのCSSやjsを本格的にクロールしはじめてまだ日が浅いので、いろいろと起こるのは仕方ないことかもしれません。
また、フォーラム等を覗くと、外部リソースについてはＰＶには影響しない、気にしなくていいとされています。
が、しかし。
- ブロックされたリソースの件数が増えてしばらくすると、どうもアクセス数が減る、という反比例現象が起こる。そして、このブロックされたりソースが増加したタイミングと、アクセス数の減るタイミングとが合い過ぎていること
- また、以前のFacebookコメントから起きた大量の「404エラー」発生時も、同様にアクセスダウンしたこと
を踏まえると、
やはり、「ブロックされたリソース」が外部リソースで対処が難しい場合でも、クロール時にエラーがあるとサイト全体の評価が落ちるとか、何かしら影響があるんじゃないか？と思われます。
また、
一番考えられるのは、クローラーに負担がかかるから、ではないかと思います。
そして、2月末また、「ブロックされたリソース」が発生。
ここ最近、ブロックされたリソースも放置しておいても1週間ほどで消えたりするので、
様子を見ていたのですが、今回はちょっと長引いていました。
でも、外部リソースだもん、ほっといてもいいよね・・・と放置した結果、アクセス数がじわっと降下。
3/24あたりから雲行きが怪しくなってきていたので、1/24～2/2と3/24～4/2間での平均掲載順位をサーチコンソールの検索アナリティクスで比較してみました。
やはり、平均掲載順位がじわっと下がっていました。
何もせずにいたらもっとひどいことになりそうな予感がします。
どうせアクセスが下がっているなら、PVダウンにいらいらしてストレスを溜め込むより、ダメもとで対策をしてみよう！とやってみました。
https://external-atl3-1.xx.fbcdn.net って何？
「ブロックされたリソース」のページのブロックされたリソースは
https://external-atl3-1.xx.fbcdn.net
となっています。
fbcdnということは、FacebookのCDNということでしょう。
各ページの実際にブロックされているものが何かをよく見てみると、
external-atl3-1.xx.fbcdn.net/safe_image.php?・・（略）・・png
という画像が、ブロックされたリソースとしてあり、サイトの全ページでこれが起こっていました。
この、external-atl3-1.xx.fbcdn.net/safe_image.php?・・（略）・・pngがどの画像で、どうしてブロックされたリソースになっているのか？どこで発生しているのか？を探ってみたところ、
サイドバーウィジェットに設置していた、
Facebookページプラグインが発生源
ということが判明。
ディベロッパーツールで見るとわかりやすいですね。
ページプラグインの高さを設定していない場合、プラグインの表示の中で最近の投稿が表示されますよね。
この最近の投稿のアイキャッチ画像が例の
”external-atl3-1.xx.fbcdn.net/safe_image.php?・・（略）・・png”でした。
よりによって、SEOをうたう画像が足を引っ張るとは(笑)
Googleは埋め込みプラグインの中の画像でも、ページに表示されている画像についてのデータを取得しようとします。
しかし、それをFacebook のrobots.txtがブロックしてしまうので、「ブロックされたリソース」になってしまう、というわけ。
対応策：Facebookのページプラグインの設定変更
ならばと、投稿とアイキャッチ画像が表示されないようにミニマムの高さ、70に設定。
上の設定にすると、下のようなFacebook Page Pluginになるコードが生成されます。
こうしてしまうとすごくアピール度低めになってしまいますが、そのせいでアクセスされなければ、にぎやかにしてあっても、本末転倒、意味がない！ですもんね(^_^;)
その代わり、今まで表示させていなかったカバー画像を復活させました。
カバー画像も表示させていると、この画像も同じように「ブロックされたリソース」になってしまうのですが、これもなくなると、地味すぎて・・。
例）カバー画像なしの状態
これだともういっそのこと設置しない方が良い様な気がするのでせめて、というところです(^_^;)
そして、Jetpackのウィジェット表示管理機能を使って、ページプラグインをサイドバーウィジェットで表示させるのはトップページだけ、という設定にしました。
こうすれば、ブロックされたリソース問題が起こるのはトップページだけになります。
※Jetpackのウィジェット表示管理機能についての詳細は別記事はこちら！
「WordPressウィジェット表示を操れ！Jetpackのウィジェット表示管理」
まあ、Facebookページプラグインを設置しないのが一番手っ取り早いでしょうけどね(°∀°）
Fetch as Googleで再インデックスを促す
対処後、Googleが再インデックスするのを待っていても良いのですが、Fetch as Googleで再インデックスを促した方が早くインデックスされます。
Fetch as Googleはサーチコンソールのクロールのメニュー内にありますが、いちいちURLをコピペするのも大変です。
ブロックされたリソースのページに表示されている該当するページからFetch as Googleをする方が簡単で効率的です。
どうするのかというと、まず、ブロックされたリソース画面の下にリストアップされている、リソースの一覧をクリックします。
すると、そのブロックされているリソースが検出されたページの一覧が表示されます。
このページの行をクリックします。
すると、ポップアップ画面が表示されるので、この画面内のFetch as Googleのボタンをクリックします。
Fetch as Googleの画面が開きますので、取得 または 取得してレンダリング のボタンをクリックし、
下のようなポップアップウィンドウが表示されるので、
①私はロボットではありません
②URLのみをクロール
③送信ボタン
の3ヶ所をクリックします。
取得が完了すると表示される「インデックスに送信」ボタンをクリックします。
Fetch as Googleの詳細については以下のページを参照して下さい。
Search Console ヘルプ・ウェブサイト用 Fetch as Google を使用する
https://support.google.com/webmasters/answer/6066468?hl=ja
これで対処できるはずですが、あまりFetch as Googleをやりすぎるとロボットと疑われ、食べ物の画像をクリックなどの認証画面が出てくるようになります。
時間をおいてからFetchすると良いでしょう。
さて、実はもうひとつ、別の「ブロックされたリソース」
http://hublog.biz/bwpb/wp-admin/admin-ajax.php
がサブディレクトリのサイトの方に発生していました。
こちらは、外部リソースではなかったので、影響がかなりありました。
こちらについてはまた別の記事「順位下落要因！ブロックされたリソースのadmin-ajax.phpに対処する方法」に書いています。
コレで少しは立ち直ってくれると良いのですが・・(^^ゞ
ではでは、今日はこの辺で。
お役に立ちましたら、シェアなどしていただけるとうれしいです！(^^)
