Powered by Google App Engine

プログラマ的SEO

 

noindexとnofollowを正しく使い分ける

nofollowとnoindex、正しく使い分けてますか?よくあるミスとそれぞれの使い所について解説します。

新サイト、tree-mapsを公開しました!!

tree-maps: 地図のWEB TOOLの事ならtree-mapsにお任せ!

地図に関するWEB TOOL専門サイトです!!

大画面で大量の緯度経度を一気にプロット、ジオコーディング、DMS<->DEGの相互変換等ができます!

◯ 広告

クローラに「このページはインデックス化しないでね」というヒントを与えます。

あくまでヒントなので、適用するかどうかはクローラが決定します。

重要なヒントなので基本的に適用されますが、行儀の悪いクローラは無視するかもしれません。

また、検索エンジン以外の目的でクロールするクローラも無視する可能性があります。

単にnoindex機能未対応のクローラも同様でしょう。

headタグ内にmetaタグを記述します。

<meta name="robots" content="noindex" />

主に以下がnoindexの使い所かと思います。

  • 管理画面
  • 確認・完了画面
  • 開発者用のデバッグページ

個人情報が絡む確認・終了画面には必須です。個人情報がインデックス化されると最悪の事態を招くでしょう。

いいえ。しっかりPageRankは渡ります

インデックスされないのとPageRankの引渡しは別物なのです。

いいえ。しっかりクロールされます

インデックスされないのとクロールしないのとは別物なのです。

「このページ、又はこのリンクはクロールしなくていいよ」というヒントを与えます。

前述のnoindexと同様、ヒントなので無視される可能性があります。

2種類あります。

1つ目は、headタグ内にmetaタグを記述する方法です。

<meta name="robots" content="nofollow" />

2つ目は、aタグ内にrel属性を記述する方法です。

<a href="hoge.html" rel="nofollow">リンクです</a>

metaタグで記述した場合はページ全体に対して有効になります。

aタグで記述した場合はそのリンクに対してのみ有効になります。

主に以下がnoindexの使い所かと思います。

  • ユーザのコメント機能のaタグにrel="nofollow"は必ず挿入し、スパムを防止する。
  • 信用できるサイトかどうか判断できない時、aタグにnofollowを付与する。
  • 管理画面
  • 確認・完了画面
  • リンク階層を遡る場合。(グローバルメニューはnofollowしてかまいません)

クロールされると困る場面で使います。

スパムにPageRankを渡さないのと、見せたくないページに対して設定しましょう。

スパムと知らずにnofollow無しのリンクを貼ると、スパム幇助と取られる可能性があるので注意しましょう。


リンク階層の遡りは、例えば 飲料 -> 発泡酒 -> キリン という階層の場合、クローラは飲料からキリンへと下ります。

クローラは下っていくので、上らせる必要はありません。

クロールを下り方向に限定してクロール量を減らせば、クロール速度も向上するでしょう。

グローバルメニューに関してもnofollowにします。理由は階層の件と同様です。

いいえ。しっかりインデックス化されます

そのサイト・そのリンクからはクロールされない=インデックスされない」ですが、別のサイト・リンクからはクロールされます。

つまりインデックスされてしまいます。

クロールさせない、インデックスさせない、アーカイブさせない。

<meta name="robots" content="noindex,nofollow,noarchive" />

しかしこれでは不十分です。前述のヒントを無視するクローラの対応が必要です。

ヒントに加え、basic認証もしくはIP制限をしましょう。

これで確実にクロールされず、インデックスさせない事ができます。

クロールさせない、インデックスさせない、アーカイブさせない。

入力画面は構いませんが、確認・完了画面にPageRankを渡す必要はないのでnofollowを加えます。

<meta name="robots" content="noindex,nofollow,noarchive" />

しかしこれでは不十分です。前述のヒントを無視するクローラの対応が必要です。

basic認証+IP認証は使えません。ユーザのIPも不定で、basic認証をかける訳にもいきませんね。

代わりに、token認証を導入しましょう。

token認証とは、URL直打ちによるアクセスをできなくする手法です。

入力画面 -> 確認画面、という動線はOKだが、URL直打ちで確認画面を表示するとエラー画面に遷移させます。

仮にクローラが入力画面 -> 確認画面と遷移し、且つ入力情報まで正確である場合があります。

それを考慮する場合、画面遷移時にUA判定でクローラの場合はエラー画面に飛ばしてしまいましょう。

クロールさせない、インデックスさせない、アーカイブさせない。

<meta name="robots" content="noindex,nofollow,noarchive" />

しかしこれでは不十分です。前述のヒントを無視するクローラの対応が必要です。

ヒントに加え、IP制限をしましょう。

社内の開発者にのみ公開したい、且つbasic認証をいちいち入力していては効率が悪い。

それを考慮するとIP制限がいいでしょう。

◯ 広告