この記事はAhrefs公式ブログの日本語訳です。
原文：SEOs Are Breaking Pagination After Google Changed Rel=Prev/Next – Here’s How to Get It Right
（著者： Patrick Stox, Joshua Hardwick/ 原文の最終更新日：April 15, 2020）
※フルスピード註：この記事は2020年4月15日時点の記載をもとに翻訳しています。Ahrefs公式ブログの記事は今後追記・再公開されることがありますことをご了承ください。
Google がrel=prev/next マークアップが何年も使用されていなかったと発表したとき、その実装を変更し、積極的にWebサイトへ損害を与えるWebサイトが増加していることに気づきました。何が変わったのか、何をすべきなのかを見てみましょう。
rel=prev/next の目的は、シリーズ内のページ分割されたページを示すことです。Googleは当初、このマークアップを使用してページ分割されたページのグループとシグナルを共有しながら、検索結果に最も関連性の高いページを表示するために切り替えを行っていました。一般的な使用例には、コンテンツを複数の部分に分割し、製品リスト、フォーラムスレッド、ブログのリスト用に複数のページを作成することが含まれます。
3ページのシリーズで、実際のコードがどのようになるかを見てみましょう。
ページ 1:
これは最初のページなので、次のページを参照するだけで済みます。
<link rel="next" href="https://website.com/page/2" />
ページ 2:
これは、シリーズ内にある次のページと前のページの両方を参照します。
<link rel="next" href="https://website.com/page/3" /> <link rel="prev" href="https://website.com/page/1" />
ページ 3:
これは最後のページであるため、前のページを参照するだけで済みます。
<link rel="prev" href="https://website.com/page/2" />
しかし、2019 年に Google は、ページネーションに rel=prev/next を使用しなくなったと発表することを決定しました。さらに悪いことに、彼らは何年もそれを使用していなかったそうです。
この変更は実際にはSEOに影響しませんでした。重複コンテンツの場合、同じテキストブロックがいくつかあってもサイトに悪影響を与えることはなく、ペナルティもありません。Googleは引き続き、そのコンテンツの最適なバージョンを見つけて表示しようとします。
そこで問題となるのが、なぜ変更したかということです。何かあった場合、それについて何をすべきでしょうか？
この投稿では、目次のように以下を学ぶことができます：
一番上の項目から始めましょう。
Google が rel=prev/next のサポートを削除したのはなぜ？
Google が rel=prev/next をもう使用しないという爆弾発言をする前、ページネーションに関する公式の推奨事項の1つは、 何もせず Google に理解させるというものでした。
何もしないでください。ページ分割されたコンテンツは非常に一般的であり、Googleは、コンテンツが複数のページに分割されているかどうかに関係なく、最も関連性の高い結果をユーザーに返すという優れた仕事をしています。
これを知っていると、rel=prev/next の使用をやめた最も可能性の高い理由は、単に検索エンジン側で理解するのがうまくなり、追加のヒントは必要ないと感じたからと考えることができます。
Googleには、rel=prev/next 以外にも、シリーズ内のページを識別するために使用できるオプションがいくつかあります。ほとんどの場合、ウェブサイトはページ分割されたページの実装と一致しており、Googleは次のようなことを確認できます。
- 見出し
- ページタイトル（同じタイトルまたはページ番号を追加）
- ページ上のリンク（セット内の他のページへの内部リンク）
また、サイトがコンテンツを複数のページに分割しているため、ページネーションに関する推奨事項がユーザー エクスペリエンスの低下につながっていた可能性もあります。ほとんどの場合、これはページビューと広告収入を目的として行われていましたが、ユーザーにとって煩わしいエクスペリエンスであり、探しているものを見つけるのが困難でした。私が言いたいことの例を、こちらとこちらの2つリンク先に挙げておきます。
SEO担当者は、rel=prev/next が機能しないことをどうやって知ることができたのか？
Google が rel=prev/next を何年もサポートしていないと発表したとき、多くのSEO担当者から私が受けた最初の質問の1つは、テクニカルSEO担当者である私たちがどうしてこれを知らなかったのか、というものでした。
簡単な答えは、それを伝える方法がなかったということです。Googleが教えてくれなかったら、私たちは知ることができなかったでしょう。
ページネーションが機能していれば、Googleは一連のページのシグナルを統合することになります。通常、セット内の最初のページが表示されますが、検索結果にセット内のより関連性の高いページがある場合には、表示するページを入れ替えることもありました。ページネーションが機能していなかったとしても、Googleはクエリに対して最も関連性の高いページを返すのが検索の仕組みであるため、同じことが起こるでしょう。
SEO は rel=prev/next を削除する必要がありますか?
いいえ。
Web サイトに rel=prev/next をすでに実装している場合は、削除しないでください。この情報を使用したのはGoogleだけではありません。これは現在もW3C によって推奨されており 、WebアクセシビリティとADA準拠のために使用されています。一部のブラウザではプリフェッチにも使用されます。また、 Bingなど他の検索エンジンでも 依然としてこのマークアップが使用されています。
許容可能なページネーションの実装
rel=prev/next を使用するほとんどのセットアップでは、自己参照のcanonicalタグも使用します。この設定では、何も変更しません。サイト上の他のインデックス可能なページと同じようにページを扱い、ページネーション セット内の他のページへ内部リンクするようにしてください。
ページ分割されたページを正規化して、すべてのコンテンツを表示するすべての表示ページを指すようにすることもできます。この方法では、コンテンツをユーザー向けのページに分割することができますが、インデックス付きバージョンにはすべてのコンテンツが含まれることになります。
人々は誤った設定で、自分のサイトにどのような損害を与えてしまっているか
各ページがクロールされて検出される一般的な設定は次のとおりです。
しかし、ページネーションを処理するとき、サイトに損害を与えるよくある間違いがいくつかあります。これらは：
- 最初のページへの正規化
- ページのインデックス作成なし
- 次のリンクがない
- クロールのブロック
これらのそれぞれの問題と、サイト上でそれらを確認する方法を詳しく見てみましょう。
間違い 1：最初のページまで正規化する
ここでの最良のシナリオは、Google がcanonicalタグを無視することです。canonicalタグが尊重されると、多くのページへのクロールパスが遮断され、コンテンツが孤立してしまいます。これにより、検索エンジンが貴重なコンテンツを見つけてインデックスに登録することが難しくなり、 サイト全体のPageRankの流れも遮断されます。
自分のWeb サイトでこの間違いを確認する方法
Ahrefsのサイト監査 / Site Auditでサイトをクロールし、ページエクスプローラーに移動して、以下のスクリーンショットのようにフィルタセットを適用してください。
一致するURLがある場合は、正規URLを確認してください。最初のページに正規化されるページネーションシリーズのページは変更する必要があります。
間違い 2：ページがnoindexになってしまっている
ページにnoindexを追加すると、 インデックスからページが削除されます。これらのページはランク付けの対象外となり、PageRankは渡されません。
ページ上のリンクは最初はクロールされる可能性がありますが、時間の経過とともに変更される可能性があります。Googleウェブマスター / トレンドアナリストのJohn Mueller氏は、noindexページがある時点でnofollowとして扱われるだろうと述べていますが、それにどれくらいの時間がかかるかは不明です。別のウェブマスター / トレンドアナリストのGary Illyes氏にも、このことについて尋ねたところ、今後もクロールされるだろうと考えているようでした。
これがどのように機能するかを完全に理解していない場合は、別のクロールパスがない限り、慎重になってこれらのページにnoindexは設定しないことをお勧めします。
自分のWebサイトでこの間違いを確認する方法
AhrefsのSite Auditでサイトをクロールし、ページエクスプローラーに移動して、以下のスクリーンショットのようにフィルタセットを適用しましょう。
一致するURLがある場合は、 ページまたはURLのrobots metaタグまたはX-Robots-Tag HTTPヘッダーからnoindexディレクティブを削除します。
間違い 3：分割ページの内部リンクをnofollowにしてしまう
他の分割されたページへの内部リンクには、決してnofollowを付けないでください。nofollowは Googleへのヒントになっており、Googleが無視するように伝えるのが最良のユースケース。これを分割ページの内部リンクで行ってしまった場合に何が起こるかというと、サイト内でのクロールや PageRank などのシグナルの受け渡しが遮断され、再びページが孤立してしまう可能性があります。
自分のWebサイトでこの間違いを確認する方法
AhrefsのSite Auditでサイトをクロールし、ページエクスプローラーに移動して、以下のスクリーンショットのようにフィルタセットを適用してください。
一致するURLがある場合は、「No. of inlinks nofollow（nofollowの内部リンクの数）」列の番号をクリックしてください。
これにより、サイト上のnofolloweリンクの場所を示すオーバーレイが表示されます。
これらの特定のリンクからnofollow属性を削除するか、ページまたは URL の robots メタ タグまたは X-Robots-Tag HTTP ヘッダーから nofollow ディレクティブを削除します。
間違い 4: クロールをブロックする
ページのクロールをブロックすると 、Webサイト上のコンテンツを見つけることが再び困難になり、ページが孤立してしまい、サイト内のPageRankの流れも遮断されます。
自分のWebサイトでこの間違いを確認する方法
robots.txtファイルに、検索エンジンによるページ分割されたページのクロールをブロックするディレクティブがないか確認してください。これは次のようになります。
User-agent: * Disallow: /blog/page/
これらのディレクティブを robots.txtファイルから削除しましょう。
まとめ
ページネーション用に rel=prev/next がすでに実装されている場合は、そのままにしておきましょう。それを変更する理由はありませんし、変更は良いことよりも害を及ぼす可能性が高くなります。
ページ分割されたページの品質が低い、またはあまり価値がないと思われるためにページ分割を変更する場合は、ユーザーにとって便利で、検索エンジンに代替のクロールパスを提供する方法でページをグループ化することを検討してください。
たとえば、カテゴリを使用してブログ投稿の束をグループ化したい場合、多くのトピックに関する投稿を含むページ分割されたページの束よりも、その方がユーザーにとっておそらく便利です。 1つのトピックに関する投稿を含むこれらのカテゴリ ページは、そのカテゴリに関する関連用語のSERPに表示される可能性があります。
カテゴリをクロールおよびナビゲーションパスとして使用する場合は、カテゴリがホームページからリンクされていることを確認する必要もあります。それにはウェブサイトの再デザインが必要になる可能性があるため、いずれにしてもサイトデザインを変更するつもりがない限り、これはお勧めできません。この方法を使用した場合でも、各カテゴリに多数の投稿がある場合、カテゴリに対して何らかの形式のページネーションを使用することになる可能性があるため、設定が複雑になります。
rel=prev/next をまだ実装しておらず、これから実装すべきかどうか迷っている場合、それは難しい決断です。それは主に、今それを追加するのに必要な労力とその影響に依存すると思います。このマークアップは他の検索エンジンや一部のブラウザ、またアクセシビリティのために今でも使用されているため、努力する価値はあるかもしれないことに注意してください。
削除された元ドキュメントへのリンクが必要な場合に備えて、ここにアクセスしてください。
rel=prev/next またはページネーションについて質問がありますか？著者のTwitterへメッセージを送ってください。
著者プロフィール
Patrick Stox
Ahrefsのプロダクトアドバイザー、テクニカルSEO、およびブランドアンバサダーです。彼は、Raleigh SEO Meetup、Raleigh SEO Conference、Beer & SEO Meetup、Findability Conference の主催者であり、/r/TechSEO のモデレーターでもあります。
著者の個人サイト、X（旧Twitter）、Facebook、LinkedIn
この記事の貢献者
Joshua Hardwick
コンテンツ責任者 @ Ahrefs（平たく言えば、私はAhrefsが公開するすべてのブログ記事が壮大であることを保証する責任を負っています）。
著者のTwitter
コメント