Yandex WebmasterでMissing page contentになる場合の対処

なぜかYandexのボットが謎のURLにアクセスしてくるからクロール制御をしたいと思ってYandex Webmasterへ登録しました。
ところが、Yandexからページのデータがダウンロードできない状態に・・・
Yandex - Missing page content
メッセージは「Missing page content」と表示されておりレスポンスボディがないって事らしい。

サーバーログでは送信バイトもでているからコンテンツデータの転送をしている事になってるけれど、Yandexの受信は0バイト。
gzipの展開に失敗しているか?と思ってYandexだけgzipを切ってもダメ。
CSPなどのセキュリティヘッダーがダメなのか?と考えて、Yandexにだけ出力しないようにしてもダメ。
Google先生にきいても全然情報がなくてダメ、Yandexで検索してもダメ。

じゃあなんなの?
まさかドメインがダメなのか?と思って、Freedomから無料ドメインをゲットしてきて割り当てたらすんなりとダウンロードしてくれました。
これにはビックリしましたが気を取り直して、wolfs.jpドメインと無料ドメインの違いを挙げてみました。
 ・DNSサーバーが違う
 ・TLDがjpとml
 ・ドメイン名が普通のドメインとPunycode
 ・SSLありとなし
違いはこんな所。

とりあえず、簡単に検証できるSSLありとなしを試してみたところ、SSLなしのページではちゃんとダウンロードできました。
まさかの一発ヒット!

Yandexの検索ではSSLページはダメなのか?と思ったけど、GETリクエスト自体はできてきるのでSSL通信自体は問題ないよう。
ならHTTP2かな?ってことで試しにHTTP2からHTTP1.1にしてみたところ、SSLでもページをダウンロードしてくれた。
と言うことで、YandexはHTTP2に対応していないようです。

YandexだけHTTP2を使わないようにするにはApacheの設定へこれを追加すればOK。

BrowserMatch "^Mozilla\/5\.0 \(compatible; Yandex" no_http2
Header unset Upgrade env=no_http2

BrowserMatchはYandexだけで良いかもだけどYandexだけだと何か違う物も無効化してしまいそうだったので、Mozilla~Yandexまでを判定材料にしました。
Missing page contentで困ってるWebマスターさんはYandexのみHTTP2の無効化を試してみてくださいー

Bingクローラーは学習しない

うちのブログは今年9月に完全SSL化しましたが、SNI未対応クライアントを配慮してSSLバーチャルホストのデフォルトをblog.wolfs.jpに設定していました。
その影響でSSLのwww.wolfs.jp、www.blog.wolfs.jpのアクセスも許可していました。

上記サブドメインを許可していた期間は僅か1ヶ月ほどでしたが一部の検索結果に上記サブドメインも載るようになったようで、www.wolfs.jp、www.blog.wolfs.jpへのアクセスがかなり増えましたw
これはダメだな・・と言うことでSNI未対応環境を捨ててblog.wolfs.jpドメインからのみアクセスを許可するよう設定し、検索結果から消すために301 Moved Permanentlyでリダイレクトするように設定して更に1ヶ月が経過。

Googleは9割blog.wolfs.jpへアクセスするようになったけれど、Bingだけは2ヶ月前と全く変わりません。
ログを見るとリダイレクト先へアクセスしていない状況。
但し、robots.txtのリダイレクトだけはちゃんとリダイレクト先にアクセスするよう。

Bingの挙動はかわってるなーと思っていたけど301を理解しないバカクローラーだとは思いませんでしたw
と言うことで、Bingは301を理解しないのでドメインを変更するときは注意が必要です。

ちなみに、リダイレクトをしているのはユーザーエージェントがGoogleとBingだけです。
リダイレクトのコードはこんな感じ。

<?php
 
if ($_SERVER['HTTP_HOST'] !== 'blog.wolfs.jp') {
    $agent = strtolower($_SERVER['HTTP_USER_AGENT']);
    if (strstr($agent, 'googlebot') !== false || strstr($agent, 'bingbot') !== false || strstr($agent, 'msnbot') !== false) {
        $redirect_host = 'blog.wolfs.jp';
        if (strstr($_SERVER['HTTP_HOST'], 'wolfs.jp') !== false) {
            $redirect_host = 'blog.wolfs.jp';
        } else if (strstr($_SERVER['HTTP_HOST'], 'xn--n6x.jp') !== false) {
            $redirect_host = 'xn--n6x.jp';
        } else {
            http_response_code(400);
            exit;
        }
 
        http_response_code(301);
        header('Location: https://'.$redirect_host.$_SERVER['REQUEST_URI'], true, 301);
        exit;
    }
 
    http_response_code(403);
    exit;
}
 
?>

これをwp-config.phpの一番上とかに書いておけば勝手にやってくれます。

WordPressを完全にSSLへ移行してみた

うちのサイトは証明書の関係でPreload HSTS(HTTP Strict Transport Security)にはしていないけれど、
HSTS設定前でもかなりhttpsからのアクセスがあったのでHSTSの設定をして、常にhttpsへ接続してもらうようにました。

で、2017年1月にリリース予定のChromium 56から、パスワードやカード情報を送信するhttpなサイトは「安全ではない」と表示するようになるようです。
Chromium Blog: Moving Towards a More Secure Web

HTTP/2.0になって完全にhttpは要らないんじゃ?って感じになってきてるみたいですね。

もうそれなら完全にSSLへ移行しちゃって良いんじゃないかー!って事で、httpをhttpsへ301でリダイレクトするようにしました。
方法はいろいろあるけれど、WordPressならrewriteで良いと思う。

RewriteEngine on
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://blog.wolfs.jp$1 [R=301,L]

ちなみに、RewriteRuleのURLで最後にスラッシュを入れるとリダイレクト先でダブルスラッシュになるので注意。
例:
 RewriteRule: RewriteRule ^(.*)$ https://blog.wolfs.jp/$1 [R=301,L]
 アクセスURL: http: //blog.wolfs.jp/page-1/
 リダイレクトURL: https: //blog.wolfs.jp//page-1/

これの何が悪いかと言うと、
ダブルスラッシュになっているとWordPressのリダイレクトが働いてhttps://blog.wolfs.jp/page-1/へリダイレクトされるので合計2回リダイレクトされる事に。
かなり無駄なので注意。
RewriteBase /なんかを使うと良いけど、別にそんなの指定しなくても/を1つ抜くだけで動くから要らないとおもうw

この状態でMozillaが提供しているサイトのセキュリティ診断、Observatory by Mozillaをうけてみると・・・
Observatory 結果
うんA+でかなり良いスコアがでました。
続きを読む

Apache 2.4がレスポンスを返さなくなる問題

久々にサーバー環境の見直しと言うことで24日の21:30からサーバーを止めてメンテナンスを開始しました。
メンテナンス内容は、
 ・サーバー機器の掃除
 ・サーバー機器の動作チェック
 ・サーバー機器の取り替え
 ・サーバーOSの再設定
 ・サーバーソフトウエアの設定
という感じでした。
 
サーバー機器の取り替えでは、M/B、CPU、メモリ、FAN、HDDを新しい物へ取り替え。
OSはWindows XP x64からWindows 7 Pro x64へ変更しました。
本当はCentOSがいいんだけど・・・Windowsゲーム用のサーバーも立てるのでOSがWinodwsに(´・ω・`)
 
ハードの交換が完了すればOSをインストールしてサーバー設定を済ませればおわり!なのですが、
実機環境特有の問題がでてきやがりましたww

仮想テスト環境ではWindows Updateに約1時間だったのですが、実機環境だと4時間かかりましたwww
なんだこれはヽ(`Д´)ノ

遅い原因はWindowsUpdateのプロセスがメモリ14Gbとか食っているから・・・かもしれません。
それでも搭載メモリの約半分なので全然余裕なんだけどなあ
 
そしてアップデートが終わってOSの再起動がかかると、ブートレコード破損で起動不能www
diskpartからごにょごにょしてbootrec /fixbootなど試したけれどダメだった。

と言うことでOS入れ直しに約40分。
そして2回目のWindowsUpdateもやっぱり長時間。
なのでここで放置し翌日にすることに。
続きを読む

サーバー環境のメンテ。

16日、17日にサーバー内部アプリケーション等の更新、サーバー本体と周辺のメンテナンスの両方をやっていきます。
チマチマ作業をしてサーバーアプリケーションのコンパイルが思ったより早く完成!

コンパイルした物はApache 2.4.7、PHP 5.5.7。
Apache 2.4は以前にも導入しようとしていたのですが、いろいろ不具合があって導入できなかったのです・・・(´・ω・`)

14日から仮想テスト環境、本番テスト環境とテストして問題ナシでした。
そして10時頃から本番環境に導入を開始して5分ほどで稼働を開始。

やっぱり本番テスト環境で設定しておくと、本番環境への移行はすごい楽w

正常に稼働開始したようにみえた・・・が、今回のApache 2.4.7でもやはりきた。
発生タイミングは不定でApacheがレスポンスを一切返さなくなる。
プロセスは死んでない、エラーログ、デバッグログにも出力されないこの現象・・・なんなんだろう?

と言うことで環境をロールバックしました。
 
コレCentOS環境では発生しないんだよなあー・・・
Windows環境に拘らないならいいんだろうけど、ゲームのサーバーとか一部のアプリケーションがwindows環境のみだから移行できないんだよねー。
Webサーバーだけ仮想環境でやってしまえば解決できるんだろうけど、まだ知識がそこまでないから無闇に手を出せないw

なんとかならないものかー・・・