ampの効果測定をするため、とりあえず導入することにしました。
*amp対応して気づいたこと
・画像の幅が必須なのであらかじめロジックを組んでおく
・amp対応しているサイトhtmlをコピーしてきてそれを置き換えたほうが気楽
・ampテンプレはスマホ側である程度直してスマホ版をcopyして作ると良い。(fontタグは使えない・styleはheadのみで個別styleは使えない)
・jsが使えないので、スマホページをampに置き換えるというよりは、スマホページを維持しつつampページも作っておく感じになると思います。
*amp対応前後のpagespeed
対応前
対応後
対応前からある程度高いですが、対応後モバイル・pcともに98まで上がりました。
*ampテンプレチェック
urlの最後に#development=1をつけ
chrome/開発/デベロッパーツール/consoleを開く
AMP validation successful.と表示されればok
ACRやi2iやblozooなど逆アクセルランキングパーツなどを対象としたものですが、
結論を言うと、自サイトからそれらサイトに遷移する時に、
1つの専用ページをかまして移動させた方が良いです。
例えばアンテナサイトから外部サイトにリンクをする際に
普通は//example.com/content/1234などにコンテンツを掲載し外部リンクも
同ページに貼ります。
・管理されているサイトでは
同一サイトの参照数を管理人がまとめて、
上位にランキングされることはあるのですが
・管理されていないサイトでは
参照元ページが分散してランキング上位に掲載されません。
参照元ページを初めから1箇所にまとめてあげることによって、
管理されていない逆アクセスランキングを攻略することができるのです。
ページをまとめる方法はいくつかあると思いますが、
例えばsessionを使ってurlをリダイレクトページに渡せばokです。
逆アクセスランキングに掲載されることで被リンクが増えますし、
seoにも良い影響がでると思います。
先日ペナルティを食らってしまったので、引っ越すことにしました。
通常であれば301で丸ごとredirectしてしまうのですが、
ペナルティも一緒についてくると都合が悪いので、
ペナルティを継承せずに引っ越す方法がないかと検索してみました。
すると以下サイトが見つかりました。
ペンギン対応？ ペナルティを引き継がずにリダイレクトする方法
https://www.suzukikenichi.com/blog/redirecting-without-forwarding-penalty/
301リダイレクトでドメイン変更！Googleから手動スパムのお知らせがまた来ました。
http://liapoc.com/domain-tr.html
リダイレクトする際にDisallowをかますようですね。
２サイトでdisallowページが旧・新サイトそれぞれだったのでこれはどちらに設定してもよいのか
どちらかが正しいのか・・・ちょっとわからなかったので２つともかましてみました。
リダイレクトページであるdisallowページは引越し前に
“disallow”とgoogleが認識している必要があります。
私のサイトではmyページ周りをdisallowとしていたので、その領域にredirectページを
作成して引越ししました。
ということで以下のような構成で引っ越しました。
旧サイト
↓
旧サイトdisallowリダイレクトページ
↓
新サイトとdisallowリダイレクトページ
↓
新サイト
後は、新サイトにペナルティがこないことを祈るだけですね。
追記2016/3/7 4:00
新サイトにもペナルティがきました。
ダメですね。この方法。
検索流入が1/10ぐらいになりました。
日本ランキングがそのまま世界ランキングに反映されているかと思ったのですが、
どうやら違うようです。
世界ランキングは日本ランキングを一切無視して、
世界でのトラフィックでもってランキング生成しているようです。
以下２サイトは同日に集計したものです。
この２つを見てみると世界ではBサイトがランキング高いのですが、
日本ではAサイトの方が高いのです。
Aサイト
Bサイト
考えてみれば当たり前なのかもしれませんが、
私はこのランキングを確認してちょっと考えてしまいました。
*サンプル
git clone https://github.com/joshfraser/pubsubhubbub-php
require_once __DIR__ . ‘/pubsubhubbub-php/library/publisher.php';
$p = new Publisher(“http://pubsubhubbub.appspot.com/”);
$url = “http://wp.nonip.net/”;
if ($p->publish_update($url)) {
echo ‘成功';
} else {
echo ‘失敗';
print_r($p->last_response());
}
PubSubHubBubで通知したところ0秒でgooglebotがウェブサイトを見に来ていました。UserAgentは”FeedFetcher-Google”できてるみたい。
66.249.79.121 – – [20/Feb/2016:14:14:11 +0900] “GET /article/1340 HTTP/1.1″ 200 10557 “-” “FeedFetcher-Google; (+http://www.google.com/feedfetcher.html)” “-“
こちらは普通のbot。ipは同じだけどUserAgentが違うので判断できますね。
66.249.79.121 – – [20/Feb/2016:14:14:14 +0900] “GET /article/532 HTTP/1.1″ 200 8926 “-” “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)” “-“
上記のようにbotが即webサイトを見に来たことから
このプラグインはgoogleがurl検知してから検索エンジンに登録されるまでの時間が
短くなる訳ではなく（たぶん)。url検知がほぼ0秒となることで結果index登録が速くなる
というプラグインなのかなと思ってます。
もしPubSubHubBubから登録することでGoogleがindex登録の優先度をあげてるとすれば
間違った仮説かもしれませんが。
通知したurlを15時間ぐらい待って検索結果に表示されるか確認しましたが、
まだ登録されていませんでした。うーんな感じです。
AM5時に導入したときのanalytics結果です。午後に同曜前週比3%upしている感じです。
こちらは別サイトですがAM9時に導入した時のanaytics結果です。
同曜前週比7%upしている感じです。
AM0,1時の数値は別要因でUPしたものです。
以下反映速度についての記事紹介。
15分が桁違いに速くなったらしい。
http://shumaiblog.com/blog-pubsubhubbub-fat-ping/
10時間~3日で登録されたらしい。
http://memo.everyday.jp/archives/264
25分たっても表示されなかったらしい
https://b.eax.jp/wp/wp-plugin/7600/
4-5時間が30秒未満へ
http://on-ze.com/archives/2613
GoogleのエンジニアMatt Cutts氏が「コピー対策・スクレイパー対策」として導入を推奨しているし
入れておくといいかも。
追記2016/02/26
pubsubhubbub対応したサイトがgogoleの手動ペナルティをくらいました。
多分短いスパン(秒間)でpubsubをしてしまったせいだと思います。
使用時はお気をつけを。
SearchConsoleにサイトマップを登録した時のindexされるまでの期間を計測してみました。
件数は200件程度と少ないですが解りやすいグラフが得られたので公開します。
2/1に登録して2/9にほぼindexが完了しています。
こちらは少し件数が多いですがやはり9日間程度でindex登録されるようです。
ニュースサイトなどはsitemap登録以外にもseo対策しないと
他サイトに負けてしまうでしょう。
laravel5は海外で人気らしいです。
helloworldからauthあたりまでlaravel5(5.2)を触ってみました。
以下は一発コマンドで作ったauth画面です。
fuelphpにあるものはだいたいついてる感じでした。
“Blade”テンプレートエンジンはすっきりしていていいかもしれません。
あとmigrationで自動で作られたコンテンツを見ることで、
トレンドとかは把握できそうな気がします。
テンプレを見ることでcdnはここのを使ってたりとか。
<script src=”https://cdnjs.cloudflare.com/ajax/libs/jquery/2.1.4/jquery.min.js”>
<script src=”https://maxcdn.bootstrapcdn.com/bootstrap/3.3.6/js/bootstrap.min.js”>
grunt.jsでなくgulp.jsを使ってたりとか
以下は自サイト(Zendベース)のサイトトップページのphp7バージョンアップによるxhgui解析比較です。
レガシーなライブラリを使ってると大変ですが、
phpを7にバージョンアップするだけなんで楽ちんパフォーマンスチューニングですね。
php5.6/opcacheの上位ボトルネック(全体22,237 microsecs)
php7.0/opcacheの上位ボトルネック(全体15,680 microsecs)
解析図ではボトルネック箇所がVersionUpで変わっているためメソッド名が上下してます。
主要なボトルネック箇所は以下のように処理時間が早くなってます。
単位はμs
Zend_Config_Ini::_processKey 724 → 355
Zend_Config_Ini::_processKey@1 624 → 274
Zend_Config_Ini::_processKey@2 522 → 272
Zend_Config_Ini::_processKey@3 515 → 251
Zend_Config_Ini::_processKey@4 402 → 236
Zend_Controller_Router_Rewrite::addConfig 215 → 232
smarty_core_read_cache_file 224 → 222
Zend_Config_Ini::_processSection@1 367 → 183
Zend_Controller_Router_Route::getInstance 226 → 158
Zend_Controller_Response_Abstract::outputBody 202 → 143
サイトトップページ全体では主にcacheを使ってるのですが、それだけでも7msは速くなってます。
レスポンス時間は全体の3割減となりました。
パフォーマンスチューニング仕切ってcache化したものが更に速くなるのは嬉しいですね。
まずdockerのipを確認しておく
$ docker-machine ip
192.168.99.101
php7つきの仮想imageを探す
$ docker search centos:php7
NAME DESCRIPTION STARS OFFICIAL AUTOMATED
padster83/centos7-php7-laravel5 centos7 php7 and larvel5.1 4 [OK]
skywidesoft/centos-apache-php7 1
bobbydvo/centos-php7 Docker container running Centos7 and the O… 0 [OK]
miyamotota/php7-centos67 PHP7 based CentOS6.7 0 [OK]
一番下の仮想imageが良さそうだったので、imageをpullする
$ docker pull miyamotota/php7-centos67
80port開放の状態で起動
$ docker run -it –publish 80:80 –name webphp7 miyamotota/php7-centos67:latest /bin/bash
apacheをinstallし起動させる
[root@8ff8c5a8cb27 /]# yum install httpd
[root@8ff8c5a8cb27 /]# /etc/rc.d/init.d/httpd start
dockerを再接続したい場合
$ docker start webphp7
$ docker attach webphp7
ローカルマシンからhttp://192.168.99.101へアクセスすると画面が開く
php -v
PHP 7.0.3 (cli) (built: Feb 3 2016 11:40:05) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend Technologies
with Xdebug v2.4.0RC4, Copyright (c) 2002-2016, by Derick Rethans
php7の動作検証にdockerは使えそうです。
みなさんサイトマップを作成する際どのように作ってますでしょうか？
全てのページを１つのサイトマップに作っていることはありませんか？
私は以下のようにページを種類ごとにまとめてサイトマップを作成してます。
画像だけページでまとめたサイトマップと
ログページでまとめたサイトマップ
2013年だけをまとめたサイトマップ
直近作成したページをまとめたサイトマップ
ここから価値のあるページとないページがわかると思います。
2016現在評価の低いページは削除(noindex化)をしたほうが
サイト全体の評価が高くなるということが言われています。
この場合、ログページはindex率が0%だったので
この後、サイトマップから除外することにしました。
*応用1
例えばpagerがついたページを全てsitemapに登録している場合は、
1ページと2ページを別にしてsitemapを作ってindex率を見ながら
あるページ以後はindex率が少ないので、sitemap登録から除外するなどという使い方
*応用2
お気に入りをつけることができる記事を表示しているときは
お気に入り数が5,10,15,20以下などと種類を区切って
sitmeap登録する。
お気に入り数が5以下はindex率が少ないので除外するなどといった使い方。