crontabだとエラーが起こったときのログ確認や多重起動の制御などがしやすいため、
crontabの代用としてjenkinsを使ってみました。

jenkinsに置き換えて処理実行

エラーが起こった際は、晴れマークが曇りマークor雨マークになるので直ぐに検知ができます。
アラートはメールでいいのでは？と思うかもしれませんが、
バッチ数が50件などと多くなると、アラートメールでは難しくなります。

処理スクリプトごとにログを確認できます。
さらに過去処理のログもすぐに確認ができます。

懸念があるとすれば、２点ほど
・サーバ移行したとき記述を変えないとならないのがめんどくさい。
・新しくバッチを追加するときに他のバッチのスケジュールを一覧でみれないので、空き時間がわかりずらい。
とはいえ、メリットがでかいので、cronのjenkins処理はおすすめです。

twitterからメールが来てました。
タイトル：安全のため、あなたのTwitterアカウントはロックされました。

twitterを見てみるとレイバンとかtweetされてるのかな？と思ったけどそういうのはなかったです。
たぶん自動でtweetするボットを1分ごとに仕掛けてたのが原因と思われます。

twitterの運用さんじゃなくてtweetを監視するbotが
自動でアラートメールを送ってるのかな？と思われます。

analyticsのリアルタイムユーザ数の期間が自分の中で曖昧だったので調べてみました。
調べる前はグラフに示されている30分間の期間を集計しているもんだと思ってましたが、
違いました。

前回訪問した6分前のユーザはカウントされていますが、

7分前のユーザは除外されました。

よってリアルタイムにカウントされる期間は6分間です。

対応期間のPV

以下はSearch ConsoleのHTML改善項目。カッコ内は詳細画面内の件数
——————-
9/11対応前 5:15対応
重複するメタデータ(descriptions) 179,641(詳細ページ41,041)
短いメタデータ(descriptions) 135,848(詳細ページ135,848)
タイトルタグの重複 233,062(詳細ページ63,677)
——————-
9/17
重複するメタデータ(descriptions) 153,915(30,593)
短いメタデータ(descriptions) 133,727(133,727)
タイトルタグの重複 227,208(62,888)
——————-
9/21
重複するメタデータ(descriptions) 139,919(25,475)
短いメタデータ(descriptions) 129,089(129,089)
タイトルタグの重複 235,443(68,691)
——————-
9/24
重複するメタデータ(descriptions) 28,369(6,931)
短いメタデータ(descriptions) 41,189(41,189)
タイトルタグの重複 67,009(25,313)
——————-
9/28
重複するメタデータ(descriptions) 22,973(5,181)
短いメタデータ(descriptions) 38,256(38,256)
タイトルタグの重複 61,535(23,689)
——————-
10/1
重複するメタデータ(descriptions) 17,475(3,535)
短いメタデータ(descriptions) 31,481(31,481)
タイトルタグの重複 54,103(21,216)
——————-
10/5
重複するメタデータ(descriptions) 14,213(2,913)
短いメタデータ(descriptions) 25,955(25,955)
タイトルタグの重複 42,828(16,763)
——————-
10/8
重複するメタデータ(descriptions) 12,281
短いメタデータ(descriptions) 20,651
タイトルタグの重複 31,707
——————-
10/12
重複するメタデータ(descriptions) 10,115(2,269)
短いメタデータ(descriptions) 17,368(17,368)
タイトルタグの重複 27,103(10,488)
——————-
10/15
重複するメタデータ(descriptions) 7,617(1,486)
短いメタデータ(descriptions) 14,932(14,932)
タイトルタグの重複 20,714(7,812)
——————-
10/19
重複するメタデータ(descriptions) 6,858 (1,447)
短いメタデータ(descriptions) 13,328(13,328)
タイトルタグの重複 19,881(7,762)
——————-

*考察
修正対応後10日ぐらいにがっつり減ってます。
多分この期間までにサイト内を大まかにbotが巡回するようですね。

*結果
ただ、タイトル重複を修正してもあまりPVに影響はありませんでした。

このサイトのPVが10/16にガタ落ちしました。

分析していくと、GoogleからのPVが落ちてました。

ということで、SearchConsoleを開き、
手動による対策について確認しましたが、
“手動によるウェブスパム対策は見つかりませんでした。”
と表示されていたので手動スパムではなさそうです。

SearchConsoleの別の場所をいろいろ見ていったところ、
ソフト404が増えていることがわかりました。

何をやっていたかというと閉鎖したページをトップにリダイレクト処理していた箇所がソフト404判定されていました。
以下参考サイトをみると、閉鎖したページを301でトップに転送するとペナルティを受けるようです。

参考：削除したページを単一のページにまとめて301リダイレクトするとソフト404になる

間違ったリダイレクトを行なった場合のgoogleの見解

正直知らなかったので、該当箇所を404にして修正。
確かに、ユーザにとってはそんなページが検索に載ってると邪魔かもしれません。

まずは、タイピングについてトレンドを測定。
予想どおり、モバイル化が進んでいるためタイピングは下降トレンドになってます。
毎年4月にピークがあるようで、これは新入生・新入社員研修で使うためでしょうか？

次に人気タイピングソフトについてトレンドを調査
それっぽいものを3ついれてみました。
e-typing、寿司打、タイプウェル共に下落。

パソコン普及率かなり急落してるかと思ったけど、そんなことなかった。
単身と複数世帯をみると、複数世帯は維持。
単身は7%ぐらい下落してる模様。

参照:http://www2.ttcn.ne.jp/honkawa/6200.html

結論から言うと、検索ページで検索件数が0だった場合、
httpのステータスコードを404にしていたのですが、
キャッシュしたhtmlのステータスコードが200になってました。

controllerで検索件数が0だった判定をしたところで
http_response_code(404);
を使ってたのが原因でした。

対応策として、サイトとしてsmartyを使ってたので、404判定の時はinsertを使って
http_response_code(404);
を実行するようにしました。

これでバッチリキャッシュしたhtmlを読み込んでも大丈夫になりました。
気づきずらい実装なので記事にしてみました。

2013年ごろから検索で0件だった場合、search_consoleでソフト404判定されるので、
こういう実装をしてないと場合はソフト404で検出されると思います。

pagespeedサイトの警告の１つとして以下警告がありますが、

“スクロールせずに見えるコンテンツのレンダリングをブロックしてaいる JavaScript/CSS を排除する”

今回はjqueryを使う際の問題解決方法を紹介します。
一番最初に対応したのがscriptの属性としてasync属性(*1)を付けるというものですが、
これだとjqueryをasync属性とするとjqueryをベースとしてるjsが動作しなくなり、
どうしてもjqeuryをasync属性にできない問題がありました。

(*1: asyncってのはjsの読み込み自体を非同期にするもの)

そこでひらめいたのが、
js自体を中段コンテンツ(２画面目)あたりで挿入する方法。
元々headタグ内に配置してたjqueryを２画面目あたりに入れることでうまく回避することができました。
jqueryプラグインのjsもうまく動作します。
例えばテンプレファイルとしてmiddle_head.tplなるものを用意してそこに挿入するjsを追加すれば
管理しやすいと思います。

pagespeedはスコアが悪ければそれがトリガーとなり
検索ランクの1要素として評価される可能性も十分あるので、
スコアを上げればseoに効く可能性があります。
やっておいて損はないと思います。

対応前

対応後