AdSenseの広告コードが勝手に消えた

ついひと月ほど前からAdsenseを始めて以来、順調に低空飛行を続けそのうちコーヒー一杯くらいは飲めそうだなとレポートを眺める日々です。

ところが、気が付くとまったく推定収益額が上がらず、サイトへのアクセスそのものは特に変動がないという不思議な現象が起こっていました

■閲覧者全員がAdSense広告を器用に避けた?

ひょっとして、広告ブロッカーが突然優秀になったりしてサイト訪問者の全員が器用に広告に触れることなく閲覧している、なんてことがあるのかな?などと予想してみたのですが・・・

さすがに天下のグーグル様が配信に手を下しているAdSenseでそんな器用に回避できるとも思えず(私個人的には、WEBの理想的にはそれが実現するのが一番良いとおもっているのですけれどね)

余談はさておき、いったい何が起こったのだろうと調べてみることに。

■AdSense内のメニューをチェック

まずは、予想外にさらっとAdSenseの審査に通ってしまったがゆえに「今になってやっぱり低品質なコンテンツだ」とグーグルから否認されてしまったのかなあ?なんていう疑心暗鬼に陥ります。

あるいは、自ドメインのサーバーの認証が解けてしまったのではないだろうか?何度も抜き打ちでチェックされるのかもしれないなあ、などとネガティブな妄想にも駆られます

そのため、アドセンス内のメニューから配信登録の状態をチェックしてみます。

AdSenseの認証状況

どうやら、審査が否認されたわけでもなく、認証が解けてしまったなんてこともなく、いたって平常運転である様子でネガティブな予想はただの取り越し苦労だったようです。

そうなると調べる対象はAdSense側ではなく手前のWordpress側ということになります。

■どうやってAdSense広告を配信していたか

さて、AdSenseの広告配信コードはいくつかあるようですが、導入がもっとも楽な方法1つのみを選択しておりました。

具体的には、ブログ運用はローカルのWordpressで行っており、広告の配信方法はAdSenseに完全お任せな「自動配信」のみとしています。

導入時にさらっと調べて、もっとも楽そうな「テーマヘッダ(header.php)」ファイルにAdSenseの配信コードを1行ペタッと貼り付けるというお手軽な導入方法で配信を開始し、今に至ります。

■テーマヘッダーのコードが初期化されていた

配信コードが変更されたりしていないか(無いと思うものの)念のためにAdSenseで再びコードをコピーして、既存のコードに上書きするつもりでWordPressの設定からheader.phpファイルの中身を開いてみると・・・あれ?有るはずの配信コードが存在しない

Wordpressのテーマファイルエディタより

どこか別のファイルに貼り付け直したんだっけ?と疑問に思いながら適当なファイル達の中身をチェックしてみるものの、やはり存在しない。

どういうわけかAdSenseの配信用コードがきれいさっぱり消えてしまっているようです。

■ファイルが初期化されていた

そういえば、数日前にWordpressの自動更新が掛かっていたなと思い出しました。

どうやら自動更新の最にあろうことかテーマヘッダ等のファイルが初期状態に差し替えられてしまっていたようなのです。

今までローカルのWordpressに対してはせいぜいウィジェットを少し貼り付けるくらいの事しかしていなかったために、ヘッダが初期化されてしまうことがあるなんて考えたこともなかったのです。

原因が特定できれば対処は簡単で、ふたたびテーマヘッダファイルにAdSenseの広告配信用コードを1行ペタッと貼り付けて更新するだけ。

動作確認をすると、ちゃんと表示されるように戻っていました(ページの前半部分が広告だらけになるので実はあまり好きではないのですけれども)

■ふいの初期化を回避するためには

ヘッダーファイルにコードを貼り付けてしまう方法がもっとも楽なのはおそらく揺らぎのない事実でしょう。

ですが、ふいに初期化されてしまうと気が付かないうちに広告配信が止まってしまっているということが起こります。

ヘッダーに貼り付ける以外の方法としてウィジェットとして追加しておくほうがより安心して任せていられるのかな?と考えるのですが、されどうでしょうか?

とりあえず私としては、気が付いたときにサクッと貼り付け直せるようにマニュアルを整備したところで手が止まっちゃっているのですが(^^)


消えちゃった動画や写真データの復元は
安心安全な『株式会社パソコントラブル救助隊』へ。
https://hqsecure.net/

Apacheからnginxへ変更してみたら

巷では静的コンテンツは劇的にレスポンスが速いと耳にするサーバーnginxへと乗り換えてみるのもありかなと、実験的にApache環境からの入れ替えを行ってみました。

その忘備録的な感想です。

■たしかに速いかも

なにせApacheしか経験が無かったのでまるっきりわからないところからのスタート。

しかもサイトそのものはいつでも元に戻せるように温存したまま限られた時間での移行という条件だったのです。

そもそもサーバーなんてやること同じなのだから設定も大差ないでしょ、などとタカをくくっていたらえらいギャップに悩まされることになりました。

■単純なHTTML構成のページは効果的

導入そのものはすごく簡単。先人の知恵をたくさん拝借できるので多少いびつな構成であっても困る事なく導入ができました。

そして、単純なWEBページについてはレスポンスが体感できるほど早くなった(そもそものApacheの設定が遅すぎたというのもありますが)

なんだ簡単じゃないか、と一瞬思ったわけなのですよ幸せだったのはそのほんの一瞬

■バーチャルホストは書く場所が違うだけ

Apacheではアクセスされたホスト名にあわせて処理内容を変えることができるようバーチャルホストで運営しているわけですが、通常だと /etc/apache/sites-available/ などに設定を書き溜めますよね。

nginxではどこに書いたら良いのだろう、たいして考え方は変わらないよね?と思っていたらありました。

/etc/nginx/cond.d/ 以下にバーチャルホストごとに分けて書けばおおもとの設定ファイルからすべて読み取ってくれるので問題なし。

極論すればバーチャルホストの設定は書いておく場所が違うだけ、と言えなくもない

■PHPが動かない

今回、管理下の複数のサーバー(Ubuntu数台とCentOS)で同時に実験したわけなのです。

まっさきに外部非公開サーバーで問題が出てきたわけですが、php構成のページが急に消えたと。

そうです。経験のある方はすでに感づいてらっしゃるでしょうがApacheと違ってphp-fpmを導入してあげないと動いてくれないnginxでphpページを表示するならphp-fpmを呼んであげるという考え方にしないといけないわけです。

設定そのものは特段難しくもなく、まずはphp-fpmを追加でインストールして、設定ファイルにどうやって呼び出すか(fastcgi 127.0.0.1:9000とか.sockとかなんとか)を追記してあげることでOKです。Apacheからしたら最初は「なんで機能を有効にするのに外を呼ぶの?」ってな感じでした。有効無効ってな感じとはぜんぜん違ったわけですね。

■Apacheからの乗り換えはパーミッションに注意

導入時点で前提がフラフラしているのがトラブルの原因ですが、nginxへの移行で時間がかかるならApacheへすぐ戻せるようにしておこうというのが一番ネック

既存のページ構造には手を加えない前提なので、なにかサーバーを換えることでトラブルが出るならサーバー側の設定で吸収できるようにしなくちゃいけない

単純な話ですが、サーバーが変わるということはサイトのファイルをアクセスするユーザーが変化するわけで。

たとえばサイトの権限が www-dataとか wwwグループとかいった具合に将来を見据えて最初から汎用的に設定している場合は楽なわけですよ。

ところが、長年の環境を引きずっていると場当たり的に apache:apache なんて権限になっているフォルダやファイルが大量にあったり。

もちろんnginxからはデフォルトでは nginx:nginx という権限でアクセスしますから、権限設定によってはここではじかれてしまいます。

ここでは非常に迷いましたが、本来であれば将来を見据えて apacheと設定されている権限の部分をすべてwww-dataなどと汎用的に書き換えてしまうのがベストかと考えます

あるいは、そこそこ余裕のあるハード構成であればリバースプロクシ設定でnginxの後段でApacheに処理してもらうというサーバー構成にするのもトラブル原因を最小にできて良いかと思います。

ただし今回は一時的な試行でなおかつ既存サイトに手を入れないという前提を守るために本来は禁じ手であろうnginx側の動作権限をuser apache;と書き換えることでしのぐことにしました(変更先:/etc/nginx/nginx.conf

上記にあわせてphp-fpm側の設定も listen.owner = apache、 listen.group = apacheと変更しておく必要もあるでしょう(変更先/etc/php-fpm.d/www.conf

あくまでもApacheと同時には動かさないという前提であるがゆえにできる手抜きかなと思いますが、こういう手抜きをすると後々トラブルシュートしないといけなくなったときに原因が特定できずに大変だろうなと思います。

でも楽に動いてくれます。手抜き効果はすごい!

■WordPressがめちゃくちゃ遅い

さて、nginxへの切り替えから2日、やたらとレスポンスが遅くなったものがありました

もともとチープなサーバーで近々リプレースを予定しているハード構成で動かしているものなのでApache運用でももっさりしていたWordPressなわけですが、nginxに切り替えてから劇的に遅くなり単純にダッシュボードを見ているだけでもjetpackから「サーバーがダウンしています」なんて通知が頻繁にくるように。

ダウンと言ってもそのまま固まってしまうような重症ではないので単純にリソース不足なのでしょう。

もともとMySQLがネックになっていることは自覚していましたのでまずは /etc/my.cnf を見つめて設定を切り詰めていきます。

が、しかしあまり改善するべき点が見つからず改善効果もみられない。そもそもが切り詰めたあとだったのでむしろ動作が窮屈だったのではなかろうかという設定具合。

どうやらその他のところにもなにやら問題がありそうな気配です。
もう一度 /etc/php-fpm.d/www.conf の設定をじっくり見ながら、

pm = dynamic
pm.max_children = 30
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 10
pm.max_requests = 50

あわせて、/etc/nginx.conf の側でも

sendfile on;
tcp_nopush on;
tcp_nodelay on;
server_tokens off;
keepalive_requests 100;
keepalive_timeout 10;

fastcgi_buffers 8 64k;
fastcgi_buffer_size 64k;
fastcgi_connect_timeout 60;
fastcgi_send_timeout 60;
fastcgi_read_timeout 300;
client_max_body_size 200m;

といった具合に追記修正して少しは軽くなったかな?と淡い期待を込めてphp-fpmとnginxを再起動すると、おお!素晴らしい、ちゃんと軽くなった

■変更した甲斐があり軽くなりました!

少なくとも重すぎてダウンしているという通知が来ることはなくなり、Apache上よりもはるかに軽く作業ができるようになりました。さすがnginxというところか。

これで一時的にはなんとか運用継続できるようになったわけですが、近いうちにどうせサーバーのリプレース作業があるわけでその時にはもう少し実用的な構成を要求したいなあ。得意な戦術はなに?と問われたら迷わず「物量戦」と答えたい派なので。


消えちゃった動画や写真データの復元は
安心安全な『株式会社パソコントラブル救助隊』へ。
https://hqsecure.net/