AOSSL

3月に検索語ランキングが獲れなくなった件。

常時SSL(AOSSL)対応に加え、robots.txtの設定の後、HTTPリファラが獲れるようになった。

analog設定でもSEARCHENGINEのhttpsや、LOGFILEのssl_access.logを加える事で検索語まで獲れるようになってきたのだが、ここにきて気がついたキーワードがまさかの"うんこ"。

2015年4月に書いたうんこ演算 子どもの算数を面白くする計算ドリルの記事に飛んできているらしく、なんで今頃？と思ったのだが、問題の例文が全て「うんこ」ばかりといううんこ漢字ドリルが発刊されて話題になっているらしい。

なんと！！

参照

ITmedia News http://www.itmedia.co.jp/news/

• キーマン、本を語る【仕事が面白くてたまらなくなる3冊】：スラムダンクに学ぶ勝ち負けの真髄――カヤック・柳澤社長 2012年6月27日
• 「うんこ漢字ドリル」登場　全例文に「うんこ」入り 2017年3月22日

ITmedia Mobile http://www.itmedia.co.jp/mobile/

• “うんこ”で楽しく算数を学ぶ――カヤックの「うんこ演算」 2011年2月16日

ごりらのせなか http://www.goriluckey.com/

• 全例文で「うんこ」を使用! 『うんこ漢字ドリル』発刊で学校教育に激震走る!? 2017年3月26日

日本一楽しい漢字ドリル｜うんこ漢字ドリル (公式) https://unkokanji.com/

Google Play https://play.google.com/

• うんこ演算

面白法人カヤック http://www.kayac.com/

• うんこ演算 子どもの算数を面白くする計算ドリル

さくらのSSL https://ssl.sakura.ad.jp/

• 常時SSL化（https化）のメリットと必要性とは 2017年8月29日

Amazon.co.jp https://www.amazon.co.jp/

• 日本一楽しい漢字ドリル うんこかん字ドリル 小学1年生

15日に書いた、常時SSL(AOSSL)の流れで301リダイレクトさせるようにした件。

そのうちGoogleやYahoo!のキャッシュがリフレッシュされ、直接HTTPSでリファラが飛んでくるようになるかと思いきや、逆に1日に200近くだったアクセス数がどんどん減ってここ数日は安定的に100も越えなくなった。

analogの解析結果を見たところ、9552回の301リダイレクトに対して200 OKはたった304回しかなく、GooglebotやYahoo!のクローラがリダイレクト後のフォローをしていない気配。

なんでクローラがリトライして来ないのかと考えていたのだが、ウェブマスターツール改めGoogle Search Consoleを確認したところ、robots.txtの内容として

User-agent: *
Disallow: /

を返しているので、クロール対象外になっている事がわかった。

よくよく調べてみると、/etc/apache2/sites-available/www.bravotouring.com.confの

<VirtualHost *:443>

側設定が

Alias /robots.txt /home/yano/public_html/robots.Disallow_all

となっていたので、

Alias /robots.txt /home/yano/public_html/robots.txt

に変更。ウェブマスターツール改めGoogle Search Consoleで

User-agent: yodaobot
Disallow: /
User-agent: YodaoBot
Disallow: /

となる事を確認し、一段落。

参照

Google Search Console https://www.google.com/webmasters/tools/

Wikipedia https://ja.wikipedia.org/wiki/

• HTTPS
• HTTPリファラ
• Googlebot
• クローラ

昨日書いた、常時SSL(AOSSL)の流れでHTTPリファラが獲れなくなった件。

bravotouring.comでも1年前からHTTPSサポートしているので、HTTPS同士で遷移すればリファラ出してくれてもいいような気がしたのだが、よく考えるとGoogleやYahoo!がindexしているのが"http:～“なので、こちらからは手出しのしようがない。

取り敢えず、.htaccessを

*** .htaccess.old  2014-08-25 23:24:54.278343341 +0900
--- .htaccess   2017-03-15 17:44:49.937510550 +0900
***************
*** 3,8 ****
--- 3,12 ----
  DirectoryIndex rnote.php
  RewriteEngine on
+ RewriteCond %{HTTPS} off
+ #RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R,L]
+ RewriteRule ^(.*)$ https://www.bravotouring.com/~yano/$1 [R=301,L]
+
  RewriteBase /~yano/
  #RewriteRule ^(index.html?)$ rnote.php [L]
  RewriteRule ^(.+\.htm)$ rnote.php?u=$1&%{QUERY_STRING} [L]

…てな感じにして、HTTPでリクエストが来てもHTTPSで出直すようにリダイレクトさせてみたが、やはりHTTPで出す流れの中でリファラが排除されているので、リダイレクトされた際にわざわざリファラを付け直すという事は無く、無駄に終わった。

しかし、GooglebotやYahoo!のクローラも同様にリダイレクトされる事から、時が経てばGoogleやYahoo!のindexも必然的に"https:～“になると思われるので、その時にリファラが復活する可能性があるかも！？

参照

ホワイトベアー株式会社 http://whitebear-seo.com/

• httpからhttpsに.htaccessを使ってリダイレクトさせる方法 2016年4月1日

さくらのSSL https://ssl.sakura.ad.jp/

• 常時SSL化（https化）のメリットと必要性とは 2017年8月29日

Wikipedia https://ja.wikipedia.org/wiki/

• HTTPS
• HTTPリファラ
• Googlebot
• クローラ

2008年から稼動中の「検索語ランキング」。HTTPリファラに基づくAnalogの検索語句レポートを活用したものだが、最近どうもカウントが少なすぎる。

GoogleやYahoo!のクエリがまた変わってカウントが漏れているのかと調べていたのだが、どうやらGoogleやYahoo!が常時SSL（AOSSL）した事から検索クエリを含むHTTPリファラ自体が送られなくなったという事だ。

具体的には

Yahoo! JAPANではお客様により安全にサービスをご利用いただくため、2016年4月から2017年3月にかけて、Yahoo! JAPANトップページやYahoo!ニュースを含むすべてのサービスにおいて常時SSL（AOSSL）に対応いたします（※1）。

今後、Yahoo! JAPAN（HTTPS）から外部サイト（HTTP）にページ遷移する場合、原則、HTTP Referer（リファラ）は送出されなくなります（※2）。 そのため、HTTP Refererを利用してYahoo! JAPANからサイトへの流入量を計測することはできなくなりますので、ご注意ください。

との事。

常時SSL(Always on SSL)の流れでHTTPリファラが影響を受けるのは盲点だったが、裏返すと参照先もHTTPSであれば今まで通りHTTPリファラを出すという事になるのかな？

参照

SEO Pack https://seopack.jp/seoblog/

• Yahooの検索キーワード 突然not providedばかりに！現状と対処法のまとめ 2016年12月21日

Yahoo! JAPAN http://www.yahoo.co.jp/

• Yahoo! JAPANサービスは常時SSL（AOSSL）に対応します

ウェブマスター向け公式ブログ https://webmaster-ja.googleblog.com/

• HTTPS をランキング シグナルに使用します 2014年8月7日

Wikipedia https://ja.wikipedia.org/wiki/

• HTTPS
• HTTPリファラ

昨日書いた、Let’s Encryptプロジェクト。

5月のStartSSL更新に間に合うよう…と書いたものの、やっぱり気になるのでさっそくやってみた。

Let’s Encrypt の使い方に従って

yano@vps:~$ git clone https://github.com/letsencrypt/letsencrypt
yano@vps:~$ cd ~/letsencrypt/
yano@vps:~/letsencrypt$ ./letsencrypt-auto certonly -a standalone -d mail.bravotouring.com

とやってみたところ、何やらエラーになったっぽかったので昨夜は一旦諦めたのだが、今朝Let’s Encrypt の使い方を読み直したところ、

Let’s Encrypt クライアントソフトウェアは、ドメイン所有者であることの認証に TCP Port 80 を使用しているため、SSL/TLS サーバ証明書を取得プロセスを完了させるためには、Webサーバを一時的に終了させる必要があります。

と書いてあるのに気付いた。

というわけで、Webサーバを一時的に終了させた後でやり直して /etc/letsencrypt/archive 配下に証明書等が生成される事を確認。

apache設定ファイル /etc/apache2/sites-available/mail.bravotouring.com.conf の

SSLCertificateFile      /etc/letsencrypt/live/mail.bravotouring.com/cert.pem
SSLCertificateKeyFile   /etc/letsencrypt/live/mail.bravotouring.com/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/mail.bravotouring.com/chain.pem

で/etc/letsencrypt/live 配下のシンボリックリンクを指すようにして確認OK。

…と思ったのだが、自宅のIPv6環境からではダメだった。なんだ～、Let’s Encryptまだまだかな…と思いつつ、StartSSLの証明書に戻してみても状況は変わらず。おぉぉぉっ、そういえば6月のIPv6 by auひかりの後は確認してなかった気がするよ。orz

「IPv6だとサーバ証明書も違うんだっけ、ていうかIPアドレス関係あったっけか？」と思い調べてみたところ、やはりそういうわけでもないらしい。“IPアドレス"で縛られてしまうようだと分散冗長構成に差し支えるので、大規模な商用サービスでは全然使えない事になる。

という事は、単純にapache設定のIPv6対応をしくじっているという事が考えられるので/etc/apache2/sites-available/mail.bravotouring.com.confを素直に見直したところ、

を

<VirtualHost *:443>

と訂正する事で無事解決した。

【追記】webrootプラグインを使用する事でWebサーバを一時的に終了させずに認証できた。にゃるほど～。

yano@vps:~/letsencrypt$ sudo ./letsencrypt/letsencrypt-auto certonly --webroot --webroot-path=/var/www/html -d mail.bravotouring.com

参照

INTERNET Watch http://internet.watch.impress.co.jp/