はるかのひとりごと » SEO » インデックスカバレッジレポートの対処方法について
こんにちは。
SEO-OTAKUのはるかです。
サーチコンソールの新機能について、慣れてきたでしょうか?
インデックスについて、もの凄く詳細な分析とレポートが作成されていて、とても便利なツールになっています。
機能は、まだ開発途中なので今後どんな機能が実装されるのか楽しみですね。

それでは、新機能であるインデックスカバレッジレポートの詳細と対処方法を解説します。


今回解説するインデックスガバレッジレポートは、構造がツリー形式になっており、上位メニューから下位メニューに降りていくような構造となっています。
その見方と吐き出されるエラーに対して、対処しなければならない問題を分かりやすく解説したいと思います。

なお私は、Googleのインデックスはコントロールすべきと主張しています。

インデックスは何が何でも多い方が良いとか、Webマスターは何もせずGoogleに任せるとか、こういう方針は様々な問題を発生させる可能性があります。
せっかく作ったサイトやページなのですから、自分の想定しているキーワードで検索して、正しく想定したページが検索結果に表示される様にサイトを構成して欲しいです。
そういったノウハウも提示してみたいと思います。



レポートの確認の仕方と優先順位

インデックスカバレッジレポートは、非常に多くの解析内容が表示されるため、それらの情報に優先順位を付けて確認する必要があります。

インデックスカバレッジレポート
インデックスカバレッジレポート

まず、最初に表示される上部の4つの枠を見ます。
その左から2つの枠がとても重要なので注視します。
特に一番左の赤枠で表示されているエラーは、緊急性を要します。
すぐに対処する必要があります。

次の優先順位としては有効(警告あり)を確認します。
こちらがレポートされている場合も詳細確認が必要です。
これら二つについて、それぞれ見てみましょう。

エラーがレポートされた場合の確認項目と対処

SEOの基本は、サイトをGooglebotにくまなくクロール(サイトを網の目の様に巡回すること)してもらう事が必要です。

Googlebotは得たいの知れないものではありません。
現在(2018.02)Chrome41程度のレンダリングを機能を備えたブラウザで、サイトを巡回してくると思って良いです。
そのためサイトを巡回してエラーになるようなら、ここにレポートされます。

まずは日本からで良いので、普通にブラウザを使い対象サイトを見てください。
これでエラーが出るようであれば、クローラーでもエラーが出ますので、エラーの解除に全力を集中します。

エラーコードで4xxや5xxが返却されるようであれば、サーバーが返却したコードに応じたエラーが記録されます。

5xxエラーの発生原因と対策方法

たとえば5xxは、サーバー設定を間違えた場合に発生する事が多く、Apacheであれば主にhttpd.confの外部ファイルである.htaccessの記述ミスで簡単に発生します。

サイトの構成を変えたり該当ファイルを触ったり、プラグインをインストールしたりした場合、発生する場合があります。

原因追及は時間掛かるでしょうから、今までちゃんと動いていたなら、その状態に戻すのが手っ取り早いです。
SEOに限らずSEO以外にも言えることですが問題が起きたら元に戻すは鉄則です。
何かの大きな修正を行う場合、必ず元に戻せるようにします。

5xxのエラーは、その他サーバーのパフォーマンスを超えた場合のトランザクションでも発生します。
SNS等で取り上げられてバズに耐える事ができないと503などになります。

5xxエラーの対処は大きく分けて二つです。

①再現性(確実に発生するか)
 →確実に発生する場合は、問題となっている原因を追及し除去する

②発生頻度(どの程度の頻度で発生するか)
 →たまにしか発生しない場合は、頻度の確認とログなどから原因を追求し対処の有無を判断する

頻度については、あるプラグインが実行されたときとか、あるページだけとか、そういうのを細かく調べます。
サーバーのエラーログやアクセスログは、解析に役に立つと思いますので、それを見る事ができるホスティング会社の場合、ログなどから状況を推察します。

全く原因が推測できずエラーが無いのに低頻度で500などが発生する場合は、ホスティングのプランなどを変更したり会社を変更したりする必要があるかもしれません。

レンタルサーバーは、仮想システムやマルチアカウント対応のアプリケーションで稼働しており、複数のアカウントを同一物理サーバーで動作させています。
そのため、あるアカウントがCPU能力を一時的に占有したり、HDD(SSD)のバスを占有したりすると、パフォーマンス問題が発生する可能性があります。

一つの物理サーバーに同居する他のアカウントの問題は、原因追及するのがとても難しくホスティング業者に依頼するのが得策です。
どうしても原因が分からない場合は、調査内容をレポートにして、ホスティング業者に提示を行い、頼っても良いと思います。

次に日本からブラウザでサイトを見ると全く問題は無いのに、エラーが記録されたりする事があります。
そういった現象が発生する場合は、次の手順で確認します。

まず、サーチコンソールを使いFetch as Googleを行います。

Fetch as Google
Fetch as Google

サーチコンソールでFetch as Googleを行う事により、Googlebotをサイトに呼び込んで、その時のレンダリング状態やサーバーが返却するレスポンスを確認する事が可能です。
このコード(HTTPレスポンス)が200になっていれば、問題はありませんが200以外だと色々な問題が発生しますし、Fetch as Google自体がエラーになる可能性があります(レンダリングできません等)

このようにFetch as Googleは、Googleがどのように自分のサイトを見ているのかGoogleの目を使ってサイトを見る事ができる、とても便利なツールなのです。

様々なトラブルシューティングに使用できるので、是非ともサーチコンソールにサイトを登録して、すぐに使えるように環境を整備しておいてくださいね。

Fetch as Googleは、大変便利なツールですが、Googleのサービスを直接使いたくない(アカウント連携を知られたくない)等の事情で使えない人がいるかもしれません。
※これは私の推測では、GoogleはクッキーやIPを使った同一性のチェックを必ずやっており、サイトの管理者がどのアカウントか、隠してもバレバレだと思いますので、こういった行為は無意味だと思います。

そういう事情があってもGooglebotの振る舞いを見たい場合があると思います。
実は、それに最適なツールが幾つかあります。

モバイルフレンドリーテスト
ページスピードインサイト

です。
実はこれらのツールはめちゃくちゃ優秀で、クロールに関する問題をトラブルシューティングするのにFetch as Googleの次に使えるツールと言っても過言ではありません。

エラーで記録される「robots.txt」によるブロックの確認も可能です。
さらにGooglebotを送出するアメリカにあるサーバーでステータスを確認する事ができますので、初心者に多い「海外からのアクセスをブロックする」という設定をONしてしまった場合のトラブルを見つけることもできます。

モバイルフレンドリーテストは、画面は小さいですがレンダリング結果も出力しますので、簡易なレンダリング確認も行えます。

モバイルフレンドリーテスト
モバイルフレンドリーテスト

このように、モバイルフレンドリーテストやPageSpeedInsightは、簡易なインデックス状態を確認するツールとして使うことが出来ます。

少し外れますが、リッチリザルトを確認するリッチリザルトテストもある程度インデックスを確認する事が可能です。
こちらはあくまで、マークアップした構造化データの確からしさを検証し、リッチリザルトのシミュレーションを行うツールです。

リッチリザルトテスト画面
リッチリザルトテスト画面

表示の通りβ版なので、まだまだ機能が追加されるかもしれません。
また画面デザインを見て分かると思いますが、これは新しいサーチコンソールと同じような新機能です。

よく見ると驚くべき機能が搭載されています。
例えば読み込みに関する問題の詳細をクリックします。
するとGooglebotがサイトインデックスしたとき、PCのGooglebotがインデックスしたのかモバイルのGooglebotがインデックスしたのか確認する事ができ、簡易なJavaScriptコンソールでWordPressが吐き出すJQueryのメッセージを表示したり、スタックトレースを確認する事が出来ます。

検索結果のプレビューは画像付きでリッチリザルトを表示する事ができます。
ソースの表示類は、承知の通りGooglebotがインデックスした時点のものですので、そういった確認も可能です。

サーチコンソールに登録しなくても使える機能なので、是非私のページのデータで色々見て下さい。
https://search.google.com/test/rich-results?id=G91-PzrQFHJHMmyFFI3ydw
↑新しいサーチコンソール(ではないですがw)の機能から共有がこの様に簡単にできる様になったので使ってみて下さい。

Googleのインデックスに送信するベストプラクティス

2018年9月現在、Googleへのインデックス送信は、次の3つのみです。
1.Fetch as Google
2.URL検査ツールでのインデックス登録
3.サイトマップの送信

です。
Fetch as Googleは、サーチコンソールの機能なのでGoogleAnalyticsまたは、サーチコンソールどちらかにサイトを登録する必要があります。
Fetch as Googleの確認方法は、前項で説明しましたので省略します。

次にURL検査ツールでのインデックス登録です。
こちらは、サイトを修正して素早くインデックスを更新したい場合や、何かのミスでエラーが出た場合修正するのに便利です。
ボタン一つで素早くインデックスしてくれるので、便利に使いましょう。
例えば、あるURLに対してURL検査ツールを使った後、すぐにインデックス登録をリクエストできます。

URL検査ツールでインデックス登録をリクエスト
URL検査ツールでインデックス登録をリクエスト

ページを変更しましたか?の後ろにある「インデックス登録をリクエスト」ボタンを押すことにより、インデックスに送信する事が可能です。
新しいサーチコンソールのURL検査ツールは、このように問題の対処も出来るようになっています。

最後に、サイトマップの送信です。

Googleに継続的にインデックスを正しく送信するベストプラクティスは、サイトマップを送信することです。
正しいサイトマップ構成と矛盾の無いサイトマップを送信する事で、サイトの更新状態を素早くGoogleに伝える事ができます。
サイトマップでGoogleが参照するのはURLとlastmodのみで、lastmodもGoogleが独自で記録しているインデックスレコード内にある「更新時間」と大きく差異がある場合信用しなく(見なく)なります。

サイトマップを構成する上で、矛盾がないというも重要です。
canonical元のurlをサイトマップに記載したり、noindexのurlを記載したりするものではありません。
またrobots.txtでブロックしているURLを指定するとクロールエラーになるでしょう。
自作する場合は、デバッグを慎重に行います。

サイトマップを送信する手段は次の3種類になります。
1.robots.txtにサイトマップのURLを記述する
2.サーチコンソールのサイトマップレポートで再送信ボタンを押す
3.Pingを打つ(https://google.com/ping?sitemap=URL)

一番下の方法は、あまり知られていないので、覚えておいてください。
暫定的に作ったサイトマップをGoogleに送信する事ができます。

サイトマップPingでGoogleに送信
サイトマップPingでGoogleに送信

Googleのインデックスに正しく送信する手段は限られていますので、サイトマップを正しく使って下さい。
xmlサイトマップでは、lastmodを使う場合がありますが、Googleはあまり重要視していません。
それよりもサイトマップを正しく送信する事を優先してください。

言いたいことは、プラグインを使わないと難しいコーディングが必要なxmlサイトマップを作るのでは無く、URLだけ記述したテキストファイルだけでサイトマップを構成しても良いという事です。
Googleが対応しているサイトマップ形式はこれだけあります。

作りやすいものを選択してください。
ヘルプの通り、テキストなら1行1URLをテキストで記述して、.txtというファイルを作り該当ドメインにアップロードするだけです。
あとは、サーチコンソールでそのテキストファイルを登録すればOKです。
CMSを使用していない環境では、こういった形で作られても良いと思います。

404/ソフト404の原因と対策方法

次に404系の話しをします。
404や410は「コンテンツが見つかりません」という意味です。
この数字は、あくまで先ほどFetch as Googleで確認出来るサーバーが返却するコードです。
このコードとレンダリング結果は、実は一致していない事があるのです。
何が言いたいかよく分かりませんね。こう言う意味です。

①サーバーは200を返しコンテンツも正常表示
②サーバーは200を返すがコンテンツは「見つかりません」
③サーバーは404を返すがコンテンツは正常表示
④サーバーは404を返しコンテンツは「見つかりません」


こう箇条書きにすれば①と④がコードと画面が合っているというのが分かります。
世の中全て①と④だけなら問題無いのですが、残念なことに②と③を出す場合があるのですね・・・。

まず②についてです。
これは、ソフト404というコードになる事が多いです。
たとえば、Webサイトにサイト検索フォームを備えている場合があり、そこにサイトに存在しない情報を入れると、通常「見つかりません」と表示します。
このとき、意図的に404になる様に設定していないと200で「見つかりません」を表示する事になります。
ちゃんとレスポンスを確認して、見つからない時は404、見つかったときは200になる様にします。

これは余談ですが、私は検索画面はインデックスすべきではないと啓蒙しています。

リンク記述先の内容は、是非とも守って欲しいです。

ソフト404を意図的に発生させるのは難しいです。
Googleは内部処理でもう一つの大きな原因もソフト404とします。
その原因とは同じURLでコンテンツが全く違う場合です。

同じURLでコンテンツが違うというシチュエーションは限定的です。

ソフト404になり得る操作
(1)中古ドメインを購入した
(2)サイトを削除/修正した
(3)全く違う記事に301リダイレクト/canonicalした
(4)その他

など限られてくるでしょう。
(1)は中古だと知らずに購入して、自分は新規ドメインと思い込みブログを公開したら、新記事はインデックスされたが、サーチコンソールには大量にソフト404が発生したなど、起こりうると思います。

これは、以前のドメイン使用者と新しいドメイン使用者のコンテンツが違うからです。
まあ、当然といえば当然ですね。

しかし私は、その当然というのが嫌いなので、遊んでみました。
(ちょっと余談なので、興味の無い方は読み飛ばしてください)

私はゲーム会社(ニトロプラス等)が、購入していたドメインが売り出されていたので、それを購入して以前と同じページを復元しました。

そのページがコレです。
STEINS;GATEなどで有名ですね。
希テクノロジーグループ
↑これが私が復元したページです。
元のページは私は見たことがありませんでしたので、使ったのがWaybackです。
それがコレです。

WayBack2008年6月12日のログ

見事復元していますw
しかも当時はボタンとか、クリックできないようになっていたと思われるのをすべて押せるようにしたり、会社のロゴも1からデザインしなおし、アイコン登録までしています。

ゲームマニアが今でもリンクしているので、PageRankもあると思われますw
というか、こんなイカレタ人がいるのですね。
さてこのページ、ソフト404は絶対出さないぞと意気込んで作りました。
見事ソフト404にはならず、PageRankも引き継いだという訳です。

話をもどしますね。
(2)の「サイトを削除/修正した」の説明に移ります。

Googleは、インデックスのレコードに更新情報やその他多くの情報を歴史として保管しています。
サイト運営者がコンテンツをリライトしたり削除したりする行為は、全て理解していると思って良いと思います。

以前はAと書いていた記事に全く違うBという記事に変更した場合、認識するのに時間が掛かり、最初はソフト404が記録されるかもしれません。
そういう意図的な修正の場合は、ソフト404が記録されても問題なく、見守る事が必要です。
Aという記事の一部を削除し一部を追加したなど、改善や修正した場合A’と判断され検索順位に優位に働く可能性も秘めています。

ただ何処を修正したかもちろん見ていますので、タイトルだけとかキーワード追加しただけというスパミーな行為は、逆に順位を下げるかも知れませんし、ソレこそソフト404になるかもです。

ということでソフト404は原因が多くあり、一筋縄に行きませんが、大量に出なければ、urlに対して「info:」演算子を使い検索して、どんなインデックス状態か確認して対処法を決めた方が良いです。

また何かの変更を意図的に行った場合、途中経過でソフト404が記録される事もありますので、意図的で影響が大きくない場合は、長期的に見守る事も必要です。
他の項目にもソフト404は登場しますのでよく仕組みを理解してください。

(3)の「全く違う記事に301リダイレクト/canonicalした」の説明です。
全く違うページに正規化やリダイレクトするのは、スパム行為です。

例えば、トップページを検索上位にするために、canonical命令を複数のPageRankが高いページやサイトに設定することがあります。
こうした悪意ある行為は瞬時に見抜かれ、無視されるかソフト404になる事もあります。

また、リダイレクトも同じです。
全く違うコンテンツにリダイレクトすると、不正なリダイレクト扱いされたり、ソフト404になります。

(4)は説明しません。
ということでワルサをしていなかったら良いかと思います。

最初の項番にもどります。
では③の「サーバーは404を返すがコンテンツは正常表示」の説明です。

こんなの無いだろうと思うでしょ?
実は結構あるのですね。

私はウェブマスターフォーラムで3件は対処したと思います。
主に起きるのが、WordPressでトップページを「固定ページを表示する」に設定しておいて、その固定ページが無い場合です。
サイトを構築した初期の段階での話しですので、すぐに気付きますが「1ヶ月ずっとトップページがインデックスされません」などの相談もありました。
こうした設定ミスも、Fetch as Googleなどで調査できますので、必ずトップページや記事ページのHTTPレスポンスを確認する癖を付けておいてください。

単純にレスポンスコードだけ見るのであれば、SEOチェキや、ブラウザのF12を押して出てくる開発者メニューでレスポンスコードを表示するようにすれば見る事ができます。

404対策のベストプラクティス

404発生時の対処です。
一度作ったページを、気に入らないので削除したなど、こういうページは半永久的にクロールエラー(404)が出る可能性があります。
またページではなく、カテゴリーやタグなども同様です。
半永久的に出ますので、どうするかきっちりと判断します。

ベストな対策は次の通りです。
・放置する
・リダイレクトする
・同じURLで記事を書き直す
概ねこのような対処になると思います。

私の指針は、今そのページは無く、無いのが正常であるなら404を返すべきです。
変なリダイレクトを行い、人気の高いページに誘導したりトップページに誘導する必要はありません。
そのURLでは、コンテンツが無いという事をGoogleに伝えるのは、正しい行為です。

ただし、一度書いた記事を削除して「新しい改善した記事」を書いた場合、削除した記事のURLから新しい記事のURLに301リダイレクトするのは、正しい行為です。
訪問者にとっても有効なものは、是非実施して下さい。

404にするか?、リダイレクトにするか?の判断は非常に微妙です。
見る人によっても違いますし、受け取る側によっても違います。
基本的には「同じような内容」であれば、リダイレクトをするのは推奨されますし、実施した方が良いでしょう。
これは記事を書いた人がそう思えば、やって良いレベルだと思います。

問題なのは、不正なリダイレクトというペナルティです。
これは、全く別のコンテンツに誘導する方式です。

例えば「ジャガイモのレシピ」のページで人気を集めて、このページを削除して「何かの契約のページ」にリダイレクトする等です。
こういったのは、外部から見ても明らかにスパム目的だというのが分かりますので、不正なリダイレクトの適用を受ける可能性があります。

意図的にそういう行為を行わなかったら大丈夫ですので、リダイレクトした方が訪問者のためというのであれば、リダイレクトしてください。
404を明示するのも間違っていないので大切な事です。

一番訳が分からない対応はエラーが出るのでリダイレクトしたい等と考える事です。
実は質問でも、理由を聞くとこう答える方が結構多かったりします。

このような「意思のない無意味なリダイレクト」は絶対にやめてください。
404でリダイレクトされて嬉しいのは、同じような記事の場合です。

エラーがウザいというのは、確かにありますが、これは、今後このURLでコンテンツが再作成される可能性を、Googleが調べているのです。
なので、もし低品質で削除した等でしたら、同じURLで書き直してみるのはどうでしょうか。

余談ですが、404が大量に発生したことをGoogleが検知した場合、サーチコンソールにメールで通知が来る場合があります。
これを初めて受けるとびっりします。

良質なコンテンツが沢山あるのに、ある日、急に404を大量検出したGoogleは、ウェブマスターの元に沢山404を検出しているけどあなたのサイト大丈夫なの?と心配してくれるのです。
私は、こういう気遣いのできるシステムは、凄く好きです。
ただ、いきなり受け取ると焦りますよね(^◇^;)

もし通知されても、自分で意図的に削除したのなら問題はありません。
しかしサイトの構成変更などでミスをしてしまい、インデックスを消失するような事になった場合、速やかに元に戻してください。

後者の場合も焦る必要は無いですよ。
検索結果に全く出なくなる可能性もあります。
それでも、過去の順位をGoogleは、ちゃんと覚えておいてくれるのです。

概ね2週間を超えると本気で削除を行いに来ますので、いくら「覚えておいてくれる」と言っても、早めの修正を行うのが良いです。

クロールエラーは原因や環境によっても、発生の仕方がいくつもありますので、Googleのヘルプは一通り見ておいてください。


info: site:の意味と使い方

さてinfo:演算子の話が出たところで、info:演算子の使い方を解説します。

info:演算子で分かること
・そのURLが、インデックスされているか
・そのURLが、どこにリダイレクトされているか
・そのURLが、どこに正規化(canonical)されているか


などが分かります。

ただし、これらは有識者が使って初めて理解出来る内容です。
この項では有識者になるための情報を記載します。
最近リリースされたURL検査ツールは、かなり優れものでこれでトラブルはほとんど回避出来ます。

ちょっと例も載せますね。

私の旧URLから新URLへの変更状態やHTTPS移行状態の確認
私の旧URLから新URLへの変更状態やHTTPS移行状態の確認

よくsite:と混同されている方がいますが、site:では正確なHTTPSの移行状態や正規化先などは分かりません。
site:はインデックスの概要(どの程度インデックスされているか)を見ることに使ったりします。
また、一覧で表示されますので、その他の演算子、例えばマイナス(-)やキーワード、またinurl:などと併用してインデックス状態を確認する事が出来ます。

気をつけて欲しいのは、site:はとてもいい加減で、インデックス個数はめちゃくちゃで表示されます。
SERP’sに表示されるので、インデックスされている?と思っても、普通のキーワードで検索すると出てこなかったりします。

このようにsite:は正確性に欠いている演算子です。
使用は、インデックスのおおまかな状態を知るというレベルに、とどめておいてください。
正しいインデックス状態を確認するには、必ずinfo:を使用するように身につけてください。

リダイレクト先の確認や正規化の確認は必ずinfo:やURL検査ツールを使ってください。

コンテンツの盗作が完全に成功している場合、info:で見抜くことができる場合があります。
正規化は、canonical命令だけではなく、Googleが自動的に行う正規化(auto canonical)も反映します。

従って、自分の記事URLをinfo:すると、盗作先のURLが表示される事があります。
これは、盗作が100%成功していて、自分のドメインは検索結果に表示されないという恐い状況になります。
Googleは、正規化アルゴリズムをかなり改善をしているので、最近はあまり見かけません。

自分のサイト内でinfo:演算子を使うと、全く別の記事が表示されたりする場合があります。
それは、後述する重複コンテンツが発生しているからです。
重複コンテンツ対策に「info:」はとても役立ちますので、新規記事を書いて5日程度経過後、info:をする癖を付けましょう。
なぜ5日?
もっと早い場合もありますが、自動正規化には時間が掛かると思ってください。

URL検査ツールの使い方

URL検査ツールは、Googleにインデックスされているか?
また、問題があればどんな問題か?
構造化データやAMPは正しく機能しているか?
などを一発で調べることが出来ます。

URL検査ツールは新しいサーチコンソールのみの機能です。

アクセス方法は以下の3種類です。
・最上部にある入力フォームにURLを入力する
・左側にメニューより「URL検査」をクリックする(上のフィールドに移動するだけ)
・各種インデックスカバレッジの調査でURLを選択した場合、メニューに出る
こんな感じでとても目立ちます。
Googleも沢山使って欲しいと思っているのでしょうね。

画面は、次の通りです。

URL検査ツールの画面
URL検査ツールの画面

みての通り、インデックスデーターベースの一部を公開しています。
ディレイドバッチ処理(リアルタイムではない)なので瞬時の判断には使えません。
私が表示している例は、旧URL及び、旧URL形式を301リダイレクトして新しいURLにインデックスが変更されたことが確認できます。

また、問題があれば、その内容が表示されます。
なにかインデックスに関する問題があった場合は、最初にこのツールを使うのが優先されそうです。

あとは、マークアップした構造化データを確認したり、AMPをマークアップしている場合、その内容も表示されます。
エラーが出ても速やかにトラブルシューティングできるようになっているので、便利です。

有効(警告あり)がレポートされた場合の確認項目と対処

robots.txt によりブロックされましたが、インデックスに登録しました
これ、知らなかったら何の事か分からないですよね。
まず大前提として、以下を確実に覚えてください。

①robot.txtでクロールを阻害する
→Googlebotはサイトを巡回する事ができない。ただしインデックスは行う。

②metaタグなどでnoindexを指定する
→Google/Bingに対する絶対命令で解読された場合、インデックスを消去する。

①と②は全く別の話ですが「クロールを阻害する=インデックスさせない」と勘違いしている人がいます。
クロールが阻害されると確かにインデックスするのは難しくなります。

しかしGoogleは充分に人気が高く、リンクしているサイトが多い場合、robots.txtでブロックされていてもその内容をインデックスする事があります

Googlebotがブロックされるとクロールできませんので、その時のタイトルは「サイト名」や「アンカーテキスト」になる事が多いです。
meta説明文は、クロールできないので、もちろん表示しません。

インデックスさせたくない場合は②のnoindexを使う事を頭に入れておいてください。
また、noindexとrobots.txtによる阻害を両方設定していると、noindexと書かれた文をクロールできませんので、インデックスされるという真逆の行為になります。

公開前サイトのベストプラクティス

公開前のサイトのベストプラクティスについて説明します。

サイトを非公開にしてテストで作成し、ある日を境に公開したいという場合、どのようにしますか?

こういう質問をすると、robots.txtでクロールを阻害するという人も多いかと思います。
しかし、先ほどの例の通り、robots.txtでクロールをブロックする行為は、インデックスさせないという命令とは違います。
もしかしたら、テストサイトがインデックスされてしまう可能性があります。

では、どのようにしたら良いか?です。
もう一つのインデックス阻害方法である、noindexを使えば良いか?という話しになります。

実は私は、これを勧めていませんし、使うべきでは無いと思います。
将来的に一切インデックスさせる必要が無い場合、もちろんこれで良いのです。
しかし、将来的にページをインデックスする予定がある場合、noindexを使ってはなりません。

理由は、noindexを指定するとそれを解除するのに時間が掛かるからです。
サイトが新規オープンする日に素早くインデックスさせたい等のベストプラクティスは、アクセス制限を使用することです。

httpd.confやnginx.confなどでアクセス制限を設定しGooglebotに対して403(401)を返却するようにします。
これにより、解除してFetchを行えば、素早くインデックスする事が可能です。

ただしこれには条件があり、短期の場合のみ有効です。
一ヶ月を超える場合、ずっと403を返し続けるとそのサイトは、永遠にそうだと思い込みクロールバジェットを減らされる可能性があります。
テストはできる限りローカルで行い、本番環境はアクセス制限を付与して短期間公開/確認するのが最適な方法だと思います。

オフラインでサイトが完成していてオンラインでテストする必要が無い場合は、アクセス制限ではなくサーバーエラーの503を使うことも可能です。
このコードを受信したGooglebotは、サイトが一時的に閲覧出来ない状態だと認識して、回復するまで何度か定期的にトライしてくれます。
従ってうまく使えば、新規サイトのオープンに利用する事も可能です。
(もちろん、運営中の不具合で緊急的にサーバーを停止しなければならない等にも使用できます)

503も403/401同様、概ね2週間以上(503は1週間以上)続ける物ではありませんので注意してください。

そのほかの警告があるのか、ヘルプの情報が少ないので、現状「警告」はこの項目だけ説明しました。

次は、インデックスの除外についての説明と対策です。

インデックス除外の項目説明と対策

インデックスはすべてサイト運営者がコントロールして行います。

以下の例で説明します。
・記事数200記事
・カテゴリ10個
・タグ20個
・一覧は1ページ10記事

私がコントロールしている例を掲載します。
日付アーカイブは、noindexにします。
日付で検索する奇妙な人はいませんので、日付でインデックスさせる必要はありません。
日付で検索する奇妙な人がいたとしても、Googleの検索オプションを使うのでサイト側でインデックスさせる必要性はありません。
日付アーカイブはトップページに最新記事一覧を表示していたら同一になりますから、これまた意味がありません。

私はページネーションで複数のページをインデックスするは好きではありません。
例えば、「アニ菓子(1/2)」など出てきても、ほとんど意味の無いインデックスです。

いまはページネーションのページは全てインデックスしています。
これはYoastが機能を排除したからです(笑)

サーチコンソールをみても、特に問題が発生しているように思えないので、この設定でも良いかと想います。


ということで、私の書いている事を遵守したなら、
200+10+20+1(トップページ)
という事になります。

約200記事書いたとすれば、インデックスに登録されているページは231程度という事になります。
この数値が適正という訳ではなく、インデックスをコントロールしていると、この当たりの数値になると理解出来れば良いかと思います。

たかだか200記事しかないのに、インデックスに登録が「400」とか訳の分からない数字になっていませんか?
私がインデックスはコントロールすべきと言っているのは、こういった内容です。

では実際に表示される、インデックス除外項目を見てみましょう。

noindexタグによるブロック発生時の対策

これは、noindexタグによってインデックスが除外されたレポートです。
クリックすると詳細情報が見れますので、自分でコントロールしたURLがnoindexになっていれば問題ありません。

この項目があるからといって「ゼロにしよう」だとかいう行為は、全くの無意味で、サイトにとって悪い事ばかりです。
ちゃんとコントロールが働いているか、確認するレベルにとどめましょう。

私と同じような設定にしているなら、カテゴリーの2ページ目以降とかトップページの2ページ目以降とかの不要なコンテンツは、ここに正しく記録されているはずです。

この項目は、確認がメインの項目です。
設定ミスをしない限り、突然増えることもありませんので、noindexを扱うシステム変更をしたときは、注視するようにします。

noindexは、head内に記載するのが正しいhtmlになります。
しかしGoogleは、bodyタグの中に入れても機能します。
noindexの説明をするページがnoindexになるのは、非常に間抜けですのでもしそういったコンテンツがあれば括弧をエンコード文字にするなどの対策を行います。

こういうコメントがもしあった場合、公開承認をしないよう注意してください。

ページ削除ツールによりブロック発生時の対策

これは、URL削除リクエストにて該当URLを削除したものが表示されます。

私は、このツールを簡単に使うべきでは無いと、いつも啓蒙しています。
Googleのヘルプでは、インデックスをクリーンナップするなど、誤った使い方を禁止しています。

このツールを使うシチュエーションは、運営者のミスで個人情報を漏洩してしまったり、機密事項を漏洩してしまったりして、すぐにでも情報を削除しないと不利益を被る場合です。

なぜ乱用してはならないか?
それは乱用するとインデックスしたいページが、このツールの影響でインデックスできないという現象が発生するからです。
インデックスをコントロールするとは、こういうツールを使うことではありませんから、決して誤解しないようにしてください。

サイトを運営していると、間違って変なページをインデックスしてしまうことがあります。
その場合、影響が軽微であったら処理をGoogleに任せるのが一番の得策となるわけです。

間違えたら、消せばいいや程度でURL削除ツールを使用すると、取り返しの付かない状況になる可能性がありますので、このツールを使うときは、特に慎重になってください。

URL削除ツールのブロックは、普通の状態では、表示されてなくてかまいません。
ツールを使用したならそのURLが表示されるはずです。

ただし、通常404も同時に行うはずですから、将来的(直近なら90日後)には404の方だけに記録されるかもしれません。
そういったものがあっても、インデックスはコントロールしていますので、自分の行った作業の結果と一致していれば、問題ありません。

robots.txt によりブロック発生時の対策

ドメインのトップに設置してある、robots.txtは、Webサイトにやってくるクローラーにあらゆる指示を与えることができます。

Googleのように真面目に従うのもあれば、完全に無視するMJ12botなどがあります。
ahr○○sのようにブロックしていても、その他のIPや環境変数でアクセスに来るかもしれませんw

問題なのは、クロールしてインデックスされなければならないコンテンツにブロックが指定されていて、インデックスされない事です。
そういったトラブルを、このレポートでは発見する事ができます。

私からの助言はrobots.txtは使う必要はありません。
え?と思いますか?
では、何故いるのでしょうか??

大手ブログや超超大規模サイト(インデックス数が数百万以上)などは、限られたクローラーのリソースをうまく使い、クロールさせる必要があります。そのリソース管理(クローバジェット管理)が必要です。
リソースをうまく管理するのに、robots.txtは役立ちます。
つまり一般サイトは、そんな対策は必要ないので不要であるという事ですね。

WordPressでは、robots.txtが勝手に作成されますが、特にそれを使用しても問題はありません。(私はWordPressが作った物は使っていなく、その設定はありません)

そもそもクローラーにアクセスされて困るページは公開するものではありませんね。
ということで、このレポートが記録されている場合は、詳細を見てURLを確認しrobots.txtを確認してください。
サーチコンソールのFetch as Googleや、その他のGoogleのツールでもブロックは確認できます。

繰り返しますがGoogleに表示されたくないコンテンツがある場合は、noindexを使用してください。
また、アクセス制限を使うのも効果的です。こちらは403のエラーが記録されるかもしれませんが、コントロールしていれば問題ありません。

さてクロールの実情を話しますと、robots.txtに従わないクローラーは当たり前ですし、サイトのパフォーマンスを気にして設定するのも意味がありません。
理由は、従わない下品なクローラーが圧倒的に多いので従うクローラー(Google、Yahoo、Bing)にブロックの設定をしてても、パフォーマンス対策が目的なら全く意味が無いからです。(紳士なクローラーが3社で10回として指標を30としたら、下品は500程度です。500をブロックすれば効果はありますが、500は無視して30に何必死で対応しているの?という感じです)

下品なクローラーは何をしてるかですって?
ええ、ハッキングできるか試しているのです。
例えば脆弱性のあるWordPressのバージョンを使っているとか、バックドア(既にハッキング済みで運営者が気付いてない場合、そういったサイトを探す)があるサイトを探しています。

全く面識がない企業のサイトです(笑)
こういう情報を無料提供しているのは好きなのでリンクしておきます。

WordPressワードプレスセキュリティースキャナー

こう言うサイトで、外部から問題があるかどうか見てくれます。
あ、言い忘れましたが、ここで真っ赤に表示されるからといって、焦る必要は無いですよ。
多分そういった方は結構いますので、心配な方は有識者に確認してみてください。

WordPressのフォーラムを利用するのもお勧めです。


クロールエラーと4xx/5xxの違い

新しいサーチコンソールからは、クロールエラーと404が分かれてレポートされますが、特に意味があるように思えません。

クロールエラーは、4xx/5xxなどで発生します。
ならクロールエラーと4xx/5xxの違いはなにか?
知りたいですね。
実は、結構簡単な違いです。

Googleが勝手に検出したものや外部リンクで発生するのが4xx/5xxという分類になり、サイトマップの送信や内部リンク発生時に行うクロール時に検出するエラーをクロールエラーという分類にしているのではないかと思います。

ただし、クローラーがサイトを巡回したタイミングに記録されますから、どちらも検出したり、片方しか検出しなかったりしていますので、クロールエラーと4xx/5xxは、同じようにみるようにしてください。


クロール済みインデックス未登録発生時の対策


実は、今回のサーチコンソールで私は、この機能が一番すばらしいと思っています。
自然言語を解析をしたり、そういうお仕事をされている方は、既に気付いていると思います。

実はこの項目、Googleが判別している品質チェックそのものなのです。
私が確認しているのは、次の通りです。

・表現などで問題のある記事
・品質が極めて低い記事
・その他


ただ、検出精度や検出時間の問題もあり、どの程度本気なのかわかりません。
ここで、検出されても、みるみる減っていく可能性があります。
その場合は、落ち着くまで待って対処をした方が良いです。

明らかな低品質記事がある場合、記事を改善する事をお薦めします。

一つアドバイスです。
WordPressなどのCMSを使われている方は、すぐに改善出来ないので削除してしまおうという人もいるかもしれません。
そういう人は、削除では無く記事を非公開に設定してください。
削除すると、折角の記事が台無しです。
非公開にして、時間があるときに改善してから再公開すれば良いのです。

そもそも記事を削除して品質が上がるというのは、私はよく分かりません。
削除などは安易に行う物ではないです。

話を戻します。
ここで「クロール済みインデックス未登録」で検出する機能が、なぜ素晴らしいか?
多くの人に分かってもらいたいので、説明しますね。

例えば、どの程度の文字数で大丈夫なのか、質疑応答か、タイトルが答えになっているか、誘導ページになってないか、などGoogleの品質チェック項目のママなので、これを逆手に取ると、スパムに使われるのです。
なので少々アルゴリズムは弱い感じにはしていると思います。
Googleは、スパムに利用される危険性を理解した上で、ここまでここまでウェブマスターに譲歩しているのです。
検索者の立場に立ち、サイト運営者に改善のヒントを出してくれています。

「このコンテンツは公開できません」という判断基準を私たちに提示して、改善を求めていると理解してほしいです。
ある種の自動ペナルティですね。

ヘルプには情報が少なく、そんな書き方はしていないですけど・・・
別の要因でもコレを使うのかもしれません。
(一時的にインデックス登録できない等)

ここでレポートされたコンテンツは、検索結果に表示されている場合もありますが、表示されない場合もあります。
(検索エンジンにインデックスされ、表示しているか否かを確認するには説明の通り「info:記事URL」で確認してください。サーチコンソールでURLをクリックすると表示される「検索結果として表示または、URL検査」をクリックしても同様の確認が行えます)

URL検査などで調べて、インデックスされていないと判明しても、安易に削除したりしないでくださいね。
SEOの基本は、想定以外の方向に動いたら、元に戻すですから。
サーチコンソールのチェックが品質と全く関係無いかもしれません。
そういうときに、元に戻らない様な施策を実施するべきではありません。

ということで、このレポートは非常に興味深いです。
私は、ほとんど対策して、ほぼ出ていないです。
ドメインパワーに影響があるか?と言われれば、あるのでしょうね・・・。

私は、記事の削除でドメイン価値向上は、真っ向から否定しています。
そんなのでドメイン価値が上がるなら、不正記事を自動作成で1万ページくらい作ってGoogleに認識させた後、削除しますわw

引き続きこのレポートは、注意深く見守ります。

<追記>
この項目、当初より精度が良く分からなくなっています。
Googleも試行錯誤しているのだと思います。

一つ言えるのは、この項目は
インデックスされているが検索結果に出さない
という項目です。
インデックスの課程で出る場合もあるかもしれませんが、古いコンテンツで継続的に表示される場合は、なんらかの対策を打つのが良いかと思います。

代替ページcanonicalあり発生時の対策

canonicalタグなんてねーよとか、言わないでくださいね( ̄。 ̄;)
意味が分かればよいのですから。

このレポートは、canonicalタグを正しく検出して正規化が成功している場合です。
私の場合、ほぼampのオリジナルページ(Googleやキャッシュで無く、制作者のAMPページ)やパラメータ付きのURLが検出され、正しく正規化が出来ている事を確認できます。

info:を実行すると(ページ詳細メニューの検索結果として表示ボタンをクリックしても確認できます)どのページに正規化されているのか、確認する事も可能です。
ampのページなら、ampの付かないオリジナルページが検索結果に表示されるはずです。

それではcanonicalの使い方について説明します。

canonicalの使い所は次の通りです。
・自己参照設定を行い付随するパラメータの排除
→パラメータが付与された複数のURLを排除するため、自分自身をcanonicalする
・ECサイトで色だけ違う商品などを統合する
・小説サイトなどで1ページ目をインデックスさせる
・上と似ているがページャーの設定
・モバイルページの正規化
・その他

など多数の用途があります。

canonicalは、canonicalする側とされる側に分かれます。
canonicalされた側は、インデックスに表示されない事になります。
つまり、非正規ページをインデックスから消すという行為も入っていることに注意してください。

canonicalは、悪意の無い使い方をしていれば、問題はありません。
リダイレクトと違い、ブラウザはページを表示することが出来ます。
そのため、Googleに対しては、canonical命令はウェブマスターからGoogleへの提案でしかなく、絶対命令ではありません。
なので、canonicalを記述しているのに、その通りに動作しない事があります。
これはアルゴリズムにより決定されているのでウェブマスター側から操作はできません。

注意が必要なのは、canonicalの無限ループや、1つのURLを複数のページにcanonicalする命令が入っているなどです。
このような使われ方を発見次第、canonicalは動作しなくなります。

canonicalでも、301リダイレクトでも良い場合は、301リダイレクトを優先するように設計しましょう。

あと詳しいことは次の重複ページの項目で説明します。

重複ページの対策

ページが重複して、canonicalが無いと、ここでレポートされます。
この場合、複数のページがインデックスされるわけではなく、Googleにより適切なページのみインデックスされます。
つまり、Googleに対して重複と検出され次第いずれかの重複ページはインデックスから消えるわけです。

重複はペナルティでは無いという言葉遊びに付き合わないで下さい。
私たちは、記事を書いて公開しています。
記事を書いて公開したが、インデックスされないのは、明確なペナルティであり直ちに修正しなければならない項目です。

問題なのは、重複はペナルティでは無いと暗示をかけ、思考や改善を停止し原因が分からず放置したり、その状態を続けてしまうことです。
ウェブマスターは重複の解除に注力しなければなりません。
言葉遊びに付き合わないで下さい。

重複についての危険性と回避方法は、こちらのページに詳しく書いています。
このページは読むのも大変なので、twitterに書いている、お手軽確認方法を記述します。

記事を書いたら即座に実施と書いていますが、セカンドトラックインデックスになる約5日程度間を置いて確認すると、さらにキーワード効果の確認が効果的です。

手順1.記事を書いてFetch as Googleを行う
サイトにクローラーを呼びインデックスを要求します。
Googleにインデックスに送信するベストプラクティスはサイトマップを送信する事です。
上述していますが、5日以上経過後次の手順にいくのが良いです。

手順2.info:でインデックス状態を確認する
正しいURLにてインデックスされているか確認します。
何も表示しなかったり、別のURLが表示されると問題です。
重複が発生していると、まさに何も表示されなかったり別のURLが表示されます。

info:で記事がインデックスされている事を確認する
info:で記事がインデックスされている事を確認する

手順3.site:ドメインとクエリで期待順位を確認する
重複記事があれば、何も表示されなかったり、自分の期待クエリに対する記事とは別の記事が表示されます。

期待クエリにおいて、正しい検索順位で表示することを確認する
期待クエリにおいて、正しい検索順位で表示することを確認する

たとえば私のページでは「クッキー」というクエリを重視していて、「クッキー」のキーワードでは「アイスボックスクッキー」を表示したかったとします。(例ですよ)
それなのに、アイスボックスクッキーは2位で、バレンタインは1位です。

自分のドメイン内の1位、2位の違いなんて、関係無いと思いますか?
期待しているページが2位になっているのだから、満足ですか?

Google検索で、他サイトと自分のサイトの順位をコントロールするのは極めて難しいです。
しかし、ここで説明しているのは、自分のサイト内の話です。

自分のサイト内の記事くらいは自分で順位をコントロールしましょう。

コントロールは、記事内のキーワードやキーワードに対する説明の仕方で簡単に調整できます。
※かといって下げたい記事の重要なキーワードを削除したりするのではなく、上げたい方に良質なコンテンツをさらに追加するという「改善」が望ましいです。
通常は、コンテンツを作成するときにある程度キーワードを意識することと、既にサイト内にある別記事との差別化を充分行うことを意識します。

なおクエリにより全く変わってきますので、コントロールと言っても何ヶ月もかかる可能性があります。

さて、このサイト内順位コントロールを怠ると、大問題が発生してしまうのです。
では、それを見てみましょう。

一般人が通常の検索で使用しそうな「はるか クッキー」の検索結果
一般人が通常の検索で使用しそうな「はるか クッキー」の検索結果

私の記事は、このキーワードで2位や3位に表示されています。
しかし、ここに表示されているのは、サイト内検索1位の記事で、私が検索結果に表示したいと思うアイスボックスはこのページにはありません。
いえ、このページどころか、20位、30位にも居ません。

そうです。アイスボックスクッキーは、検索結果から消されたのと同義なのです。
自分のサイト内で2位だからいいや・・・こんな安易な気持ちが、期待したクエリで検索結果に表示しないという大問題を発生させるのです。

これは、極端な例で説明しましたが、似たような記事を量産すると、このように見てもらいたいコンテンツを見てもらえない状況が発生します。
自分のサイト内なのですから、インデックスは順位を含め、自分でコントロールしてください。

すこし補足しておきますが、私は重複コンテンツが悪だと言っている訳ではありません。
むしろ、カテゴリーやタグのキーワードを強くするコンテンツ群で、必要だと言っています。
このあたりの説明は、
顧客心理を追求して売上を伸ばすサイトを作るラダリングとは?
詳しく書いています。

私が強く言いたいのは、インデックスやコンテンツを、Googleの検索結果に照らし合わせてコントロールする術を身に付けて下さいという事です。

「はるか クッキー」で検索したときの2位は「自分のドメインが獲得した枠」という認識で良いです。
なので、自分のサイト内(「site:ドメイン クッキー」で検索)で1位の物が機械的に出てくると考えて問題ありません。

どうですか?Googleの検索順位の仕組みが少しはわかりましたか?
この例は、ドメインフィルターの話です。
今回は拡散しすぎるので詳しく説明しませんが、興味がある場合ドメインフィルターなどのキーワードで検索してみてください。

といってもここまで出すと見たいですよね。

種明かししますと、ドメインフィルターを解除する命令である「&filter=0」を検索結果のurl欄の一番後ろに入れる事により「アイスボックス」が出てくるようになります。

ドメインフィルターを解除した純粋な順位
ドメインフィルターを解除した純粋な順位

しかし、私の順位は5位6位になっています。

この説明は簡単で、nicovideoがこのクエリで獲得しているドメイン枠が4で私が2でピクシブが1つです。

この4,2,1はクエリによって自動的に決められているものと思われます。
またクエリの順位付けにより獲得枠も自動的に変更される場合があります。
たとえば私がnicovideoに勝てるほどのコンテンツを保有していれば、一気に1位になり、最大枠は4という事になります。

という事でドメインフィルターは、自サイト内の検索順位にもの凄く関連してドメインで獲得した枠に自サイト内の順位の高い物を割り当てているのです。

ここでnicovideoと私のコンテンツの強さを比べ僅差であるなら、nicovideoは最大4つまである枠を1まで減らされます。
nicovideoから見たら、私のコンテンツは、腹立たしいわけです。
その後ろの順位も同じ様に試算されます。

私のコンテンツが弱ければ(無ければ)、nicovideoは4つで私が強ければ1つという事です。

自サイト内の順位が強くないと表示する順番により、検索結果に出ない危険性がある事が理解出来ればGOODです。

非HTMLページの重複発生時の対策

htmlのページの重複は、canonicalの有無で分類されますが、pdfなど非htmlは、こちらにレポートされます。
非htmlなので、linkタグのcanonicalは使用できません。

しかし、HTTPヘッダーを利用して、canonicalを指定する事が可能です。
指定方法は、HTTPのリクエストヘッダ(htmlのheadセクションの事では無い)内に以下を記述します。

Link: <http://www.example.com/downloads/white-paper.pdf> rel=”canonical”
(URLは絶対パスを使用します)

詳細はヘルプを確認してください。

まあCMSのみを使っているサイトではあまり気にすることはないですね。
ただ、pdfはHTMLのように内部を解析しますので、例のようにdownloadsディレクトリ等に、アップロードしている場合は、他のコンテンツとの関連性などを充分に把握しておいてください。
Googleは、pdfを普通のhtmlマークアップのように解析してインデックスしようとします。

法的申し立てによりページが削除されました

Googleは、できる限りWebサイトを公正に扱います。
また、不公平と思われる強制的なインデックスの削除は、その情報をWebサイトに公開し、透明性をレポートしています。
この項目は、DMCAというアメリカで著作権を管理している団体に訴訟をおこされた内容で、インデックスを削除する必要があると判断された場合、インデックスが削除されここにレポートされます。

著作権違反など知的財産の侵害をしなかったら、無縁です。
ただ、どのようなとばっちりを受けるか分かりません。
例えば、DMCAに嘘の申請をする第三者がいたとして、自分のサイトのインデックスが削除されるなどです。
こういった場合、サーチコンソールに通知されるので、必ずログインして中身を確認してください。

ページにリダイレクトがあります

リダイレクトを正しく設定していれば、その内容がここにレポートされます。
例えば、/無しから/ありのURLにリダイレクトしたり、サイト内でファイルを移動したりした場合、表示されます。
ここで気をつけたいのは、第三者のハッキングなどにより、意味不明なアダルトサイトにリダイレクトされたりする可能性があります。
もし、意図的ではないリダイレクトが発生し、その先がアダルトサイトや偽物通販の場合、ハッキングの可能性が考えられますので、トラブルシューティングに応じて、対応をしてください。


まとめ

何か整理方法を間違えた感がありますが、非常に多くの情報を記述しました。
SEO初心者の方には、必ず役立つコンテンツだと思いますので、じっくりと読んでみて下さい。
またこれだけの量を数日で書いたため、間違いや疑問などの質問は大いに歓迎ですのでtwitterやコメントをお待ちしています。

・サーチコンソールの新機能はこれからまだ充実していく
・サーチコンソールに登録してトラブルシューティングできる環境をつくる
・エラーと警告について優先順位を決め対策をおこなう
・info:/site:演算子を正しい知識で使いこなす
・URL検査ツールも必要に応じて使う
・インデックスはコントロールする

ではでは、皆様方のサイトがGoogleフレンドリーになりますように。

コメント一覧

  1. はるか
    2018年3月現在、私はカテゴリー、タグ、一覧などの2ページ目以降をindexする命令に変更しています。
    これはYoastが勝手に仕様変更したためです。
    現在不具合がおきるか調査中です。
    もし不具合が起きたらYoastは使用しなくなりここで、必ず報告します。
    問題がなさそうだと判断した場合も、ここで報告します。
    なお、/2/などのサブページをnoindexに指定する方法はとても簡単で、プラグインに頼る必要はありません。
    もし、サブページをインデックスする事で不具合が起きたら、指定方法も解説したいと思います。
    • はるか
      2018年7月時点で、一般的なクエリで1ページ目と/21/などを表示する事を確認しています。
      これが発生すると本来2枠あった場合、2枠目は記事一覧で占有され運営者にとって害にしかなりません。
      ただ、そのあとのアルゴリズム改良で修正されていると思います。
      もしあっても、まれで、Googleが問題視しているようなので、現在の私の判断は/2/などをnoindexにする必要は無いと考えています。
  2. 匿名
    robots.txt によりブロックされましたが、インデックスに登録しました
    が表示されて困っていましたが、原因が分かりました。
    ちゃんとnoindexが認識されるようにnoindexとrobotのblockを指定していました。
    • はるか
      原因が分かって良かったです。
      robots.txtでブロックすると検索結果に出ない場合があるので、非表示と勘違いする場合がありますね。
      noindexは、絶対命令ですし、robotsによるブロックは通常の運用では全く必要無いと私は思っています。
  3. 山崎裕也
    こんばんわ
    ソフト404が大量に出てこまっています。何か対策はないでしょうか?
    • はるか
      ソフト404は、この記事で説明している通り、画面は404を表示しているにもかかわらず、HTTPレスポンスは200を返す時に発生する場合が多いです。
      また、以前は正常なコンテンツなのに404相当の低品質な画面にリダイレクトされた場合などでも発生します。
      大量発生という事ですが、何かシステム変更をしてませんでしょうか?
      リダイレクトのミスなど、エラーの出ているURLを通常のブラウザで確認してどうなるか確認してください。

コメントする

Gravatarに登録してログインすると自分専用のアバターを表示できます。

コメントを残す





鈴木はるかのプロフィール画像
(Haruka Suzuki)
仕事:金融システムのSE
好きな物:スイーツ、絶景
趣味:お菓子/アニメ/多趣味
iOSの方はご面倒おかけしますがPush7アプリをAppStoeよりインストールして通知を許可して下さい

カテゴリ一覧

月別の記事を見る