rel="prev/next"が使えないときページネーションはどうしたらいいか？

海外のSEO/SEM情報を日本語でピックアップ

rel="prev/next"が使えないときページネーションはどうしたらいいか？
★★★☆☆ noindexタグを追加するべきか （John Mueller on Twitter）

ページネーション（ページ分割）の構成について、グーグルのジョン・ミューラー氏とフォロワーがこんなやりとりをしていた。

（フォロワー）

サイトがたくさんのページに分かれていてrel="prev/next"を追加できない場合、ページネーションしていることをグーグルにわからせるためのベストプラクティスはどうなりますか？

noindexとfollow（のrobots meta タグ）を記述すればいいでしょうか？

（ミューラー氏）

普通は、私たちはページネーションしたコンテンツを処理できる。noindexは、すべての検索結果に完全に出なくしてしまうだろうから、ちょっとやりすぎかもしれない。

（フォロワー）

なるほど。2ページ目以降にnoindexとfollowを使うというのはどうでしょうか？ そうすれば少なくとも1ページ目だけは検索結果に出現する可能性がありますよね。

（ミューラー氏）

2ページ目以降のコンテンツ（が検索結果に出なくなること）を気にしないのであれば、ぜんぜん構わない。

複数のページに分割してページ送りしているコンテンツがある場合、rel="prev"とrel="next"のタグ（要素）を設置することをグーグルは推奨している。ひと続きのコンテンツであることをグーグルに伝えられるからだ。

だが、rel="prev/next"がなくても今のグーグルはページ分割をたいていはきちんと認識できるのだろう。必須ではない。

また2ページ目以降が検索結果に出ては困るというのでなければ、あえて2ページ目以降にnoindexタグを設置する必要もないだろう。もちろん、質問者のように、それを承知で実施することに問題はないが。

サイト移転で大切なことをグーグル社員がアドバイス
★★★☆☆ ヘルプ記事も役に立つ （Google Webmaster Help Forum）

3つのサイトを1つに統合する予定のサイト管理者に、グーグルのジョン・ミューラー氏が次のようにアドバイスした。

3サイトを1つに移行するのは、かなり大きな変更だ。

だから、時間をかけて、あらゆることを準備し、計画している変更を文書化し、移行が起こっているときに状況を監視することを推奨する。

まずは、このヘルプ記事から始めるといい。一般的に、こうした変更に関していい情報になる。

時間をかけ、体系的に問題に対処し、すべての手順を入念にチェックするようにしなさい。しばらくの間は重複コンテンツを気にしなくていい。状況は徐々に良くなっていくだろう。

サイト統合にかぎらずサイト移転全般に対して、ミューラー氏のアドバイスは当てはまる。1つ1つのステップを入念に計画し、確実に実行していくことが大切だ。移行中・移行後にも状況をしっかりと監視し、問題が発生していないかどうかを確認することも忘れてはいけない。

ミューラー氏が示した、URLの変更をともなうサイト移転を説明するヘルプ記事にも必ず目を通しておきたい。

キャッシュで表示されるページはGooglebotが見ている姿ではない
★★★☆☆ Googlebotのレンダリング結果はFetch as Googleで調べる （Google Webmaster Help Forum）

現在GooglebotはJavaScriptやCSSを解釈し、ブラウザがレンダリング（表示）するようにウェブページを取得できるようになっている。

Googlebotがページをどのようにページをレンダリングするかを調べる方法について注意したいことがある。

グーグルの検索結果から、キャッシュされたページを見ることができる。しかしこのキャッシュ表示は、Googlebotがレンダリングした状態ではない。

キャッシュページをレンダリングしたのはあなたが使っているブラウザだ。グーグルから返されるのはグーグルがキャッシュしているHTMLのソースコードだけだ。ページに書かれているJavaScriptを実行するのはあなたのブラウザであって、Googlebotではない。

キャッシュで表示されるのは、あなたのブラウザがレンダリングした結果だ

したがってGooglebotがどのようにページをレンダリングしたのかをキャッシュでは確認することはできない、

キャッシュとFetch as Googleの結果が異なることはおおいにありえる。

Googlebotがそのウェブページをどのように見ているかを正しくチェックできるのは、Fetch as Googleの「取得してレンダリング」だけだ。

307リダイレクトって何？ サーバーでは301を設定してるのに？
★★★☆☆ HSTSが機能した内部リダイレクトだから （John Mueller on Google+）

常時HTTPS化にともない、HTTPからHTTPSへ301リダイレクトを設定しているのに、HTTPヘッダーのステータスコードに307が記録されることがある。設定に間違いはないはずなのにどうしてだろうか？

実際に、完全HTTPS化している筆者のブログにhttpで始まるURLでアクセスし、ChromeのデベロッパーツールでHTTPSステータスコードを調べてみたところ、たしかに301ではなく307が返っている。

307が返される理由を、グーグルのジョン・ミューラー氏とジネブ氏がそれぞれ説明してくれた。

@rustybrick not really :) Googlebot sees the redirect for HSTS as a 301 redirect. the 307 is just the redirect shown by the browser.

— Zineb Ait (@Missiz_Z) 2015, 12月 30

端的に言うと、HSTSをあわせて設定しているとブラウザが内部で自動的にリダイレクトしているためだ（HSTSについてはこちらの解説を参照）。

どういうことかというと、たとえhttpのURLでアクセスしようとしても、HSTSの働きによってブラウザはhttpsのURLで必ずアクセスを試行する。httpでは実際にウェブサーバーにアクセスすることはない。

HSTSが機能していない状態ではリダイレクトは次のような流れになる。

1. ブラウザがhttpのURLでウェブサーバーにアクセスする
2. ウェブサーバーが301のステータスコードとともにhttpsのURLをブラウザに返す
3. ブラウザはあらためてhttpsのURLでウェブサーバーにアクセスする

一方、HSTSが効いていると、次のような流れになる。

1. ブラウザがhttpのURLでウェブサーバーにアクセスする（アクセスしようとする）
2. ブラウザは、アクセスしようとしているURLをHSTSでチェックする。
3. HSTS対象であれば、httpのURLは使わず、最初からウェブサーバーにhttpsでアクセスする
4. このときに307（内部リダイレクト）のステータスコードが内部的に返される

307を返しているのはブラウザだけだ。GooglebotはHSTSに対応してないからなのか、実際にhttpでサーバーにアクセスして301のステータスコードを受け取る。

Fetch as GoogleでhttpのURLにアクセスすると301でhttpsにリダイレクトされていることがわかる

常時HTTPS化してHSTSを設定しているのであれば、301ではなく307が返っていたとしても心配する必要はない。307リダイレクトはブラウザにおける内部リダイレクトだ。HSTSがきちんと機能していることを示すので逆に安心していい。

SEO Japanの
掲載記事からピックアップ

ネガティブSEOとモバイル検索についての記事を今週はピックアップ。

• ネガティブSEOの隠された世界。ネガティブSEOは存在し、それはリンクによるものだけではない。
  ★★★★☆ 世にも恐ろしいネガティブSEO
• 【シリーズ連載その3】Android 6 “Marshmallow”とSEO。モバイル検索における”Click to Search”機能。
  ★★★☆☆ モバイルユーザーの検索行動を変化させるか？