より、ユーザーがマークしたページとは異なるページが正規ページとして選択されました」の項目を重点的に確認します。全体のインデックス数に比べ、数パーセント程度なら問題はありません。大量に発生している場合は、クロールバジェットに影響がありますので、原因を特定したほうがよいです。ソフトエラーページソフトエラーという言葉を使っていますが、今はソフト404に統一されています。ソフト404を簡単に説明すると、HTTPレスポンスは200(正常応答)を返して、ページは「見つかりません」など価値がないものを表示する事です。Googleは、価値のあるものをインデックスして検索エンジンに表示しようとします。それなのに、暗号化されて解読できないデータや、見つかりませんや、また、トップページを別のURLでも表示したりすると、ソフト404を検出します。ソフト404の確認方法ソフト404は、サーチコンソールのカバレッジから、除外を選択してソフト404を選びます。ソフト404の項目が無い場合は、検出してませんので問題ありません。表示されているURLを確認してページを表示してみてください。エラーページや、他のページと同じものがあったら要注意です。問題は、大量に発生している場合です。インデックス数の半分とか、1/4とかが大量だと思います。大量発生が問題かというと、通常の404(みつかりません)と大きく違うからです。404見つかりませんは、コンテンツが見つからない場合で、処理は特にありません。(404は後述します)しかしソフト404は、サーバーが正常応答した通常コンテンツを、Googleが別のページと同一ではないか?、エラーページではないか?などをアルゴリズムで算出して判断しています。従ってソフト404が大量に発生してしまうと、そのサイトに膨大な処理(Google自体のリソース)を消費してしまいます。ソフト404が大量にある場合、クロールバジェットを減らされて通常のクロールに影響が出てしまうのです。繰り返しますが、大量に発生しなければ気にする必要は無いですよ。私が解決したトラブルで多かったのが、下位ページをトップページにリダイレクトしていたとか、トップページのコピーを下位ページで表示していた等です。純粋に404ページを200で表示しているサイトもありました。404ページをカスタマイズして、独自の404ページを表示する事は推奨されます。そのような前向きの姿勢なのに404ページが200になっていたり301になっていたりするのを多数確認しています。カスタマイズされている方は、必ずHTTPレスポンスが404になっているか確認してください。多いのが、サイト内検索で情報が見つからないとき応答に200を使う場合です。私は古くから啓蒙していますが、未だ対応されないサイトが多いです。WordPressではなくても、一般サイトでも同じです。日本を代表する上場企業が、こういった「恥さらし」をして商標価値を毀損することになりかねないのです。ハッキングされたページGoogle公式ヘルプハッキングされたコンテンツは、重要な内容が多いので一通り目を通しておいてください。現在メジャーなハッキングは、検索エンジンに表示されたときだけハッキングされたサイトに転送する方式です。SEOに敏感で無い企業の場合、自社のページの検索結果をクリックしたりしません。そのため、発見が遅れてしまう事が多いです。仕組みは、クローキングという方式を使います。Googlebotには正常なサイト(高品質な企業ページ)を表示して、人間が検索結果をクリックしたときだけ感染ページへ転送します。「人間」と「検索エンジンに表示されたものをクリックした」の二つの条件が重なるときなので、気付きにくいです。ちなみに検索エンジンから来るクローラーには、正常ページを見せるので、検索エンジンも気づくのに時間がかかります。私が言うといろいろ問題になりますけど、ひとつ言いますww例えばchromeで利用状況を送信する事に同意していると、Googleはその情報をみて、同じURLでも別のコンテンツに転送されているのを発見できると思います。利用者の多いサイトのクローキングは、すぐに分かってしまう訳ですね。(この手法をGoogleが使っているかどうかは私は知りませんw)Googleがハッキングによるクローキングを検出した場合、検索結果に「ハッキングされている可能性がある」旨を表示して検索者を保護すると同時に、大量に作成されるスパムコンテンツのインデックスを遅らせるため、クロールバジェットを極端に減らします。ハッキングされた事を検索者に知らせ注意を喚起するまた、この時インデックスされるコンテンツは、リンク集、ワードサラダや他のサイトのスクレイピングなどで、非常に品質が低いです。いう低品質なコンテンツを発見した場合もクロールバジェットを減らしてインデックスを抑止します。ハッキングされたサイトが、中々クリーンアップされないのは、クロールバジェットを減らされているからだと私は考えています。日頃よりセキュリティに関心をもち、対策や確認を怠ることのないようにしたいですね。無限のスペースとプロキシ無限xxというフレーズが出てくると、クローラーは、困ります。5.1、5.2に非常に近いと思います。具体的には、カレンダーのパラメーターが、それに当たります。サイドバーなどのウィジェットでカレンダーを表示していて、翌月のurlが「&y=2019&m=7」となっておりそれをクロールすると翌々月は「&y=2019&m=8」となります。これには終わりがありません。このような無限スペースは、クロールをやめてしまいインデックス対象にはなりません。クロールバジェットを浪費してインデックスもされないという訳です。無限の彼方へ?そんなの嫌です!(↑米版公式ブログ:ブログタイトルは私による意訳)こういう無限スペースを発見した場合、サーチコンソールにメッセージが行く様ですが、私は確認していません。ブログでは対策方法が2つ提示されています。(公式ヘルプの方がわかりやすく内容も濃いです)1)robots.txtによるブロックこちらはクロールバジェットの浪費を抑え、無限スペースを回避できます。2)nofollowによるブロックこちらは、クロールバジェットの浪費に効果はあまりないですが、長く続けているとクロールが減るので効果があると思います。番外)URLパラメータの設定これは私が考えついた案です。URLパラメータを指定し、クロールしないという風にすれば、1)と同じ効果があると考えます。私からはひとことこんなの設置しないでくださいです。次にtwitterなどでよく見る「無限スクロール」です。こちらは、日本語版のブログがあります。検索エンジンとの相性を考慮した無限スクロールのベストプラクティス概要としては、無限ページを固定のパラメータリンク(相対ではない)で分割するという方式をベストプラクティスとして提示しています。今は回線速度も速くなりモバイル中心の時代です。何度も分割をクリックするより、ある程度の行を一気に読み込む方が、利用者に優しいです。下手に分割するより、インデックスしたい分だけ固定(月単位とか日単位)で持つようにすれば良いのでは無いかとおもいます。どんなサイトで使うかによります。私からはひとことこんなの設置しないでくださいです。例で出したtwitterは、おそらく専用のインデキシング機能を使っているのではないかと想定しています。IndexingAPIのような・・・でないとこんなの出来ませんよね。鈴木はるかのtwitterのSERP品質の低いコンテンツやスパムコンテンツゲイリーさんの記事では、最後の項目となりました。他サイトからスクレイピングされた情報や、自動生成されたコンテンツなど、価値が低いと判断されたコンテンツを掲載しているサイトやページは、クロールバジェットを減らされます。検索結果に出す価値がないですから、インデックスさせる必要がないので、クロールさせる必要も無いという訳です。詳細な事例や内容は、ウェブマスター向けガイドライン(品質に関するガイドライン)が一番近いと思います。ウェブマスター向けガイドライン(品質に関するガイドライン)下の方に13個の具体的な例が載っています。このほとんどがクロールバジェットに影響する内容だとおもいます。対策としては、ひとことです。私が、想定でクロールバジェットに影響するのではないか?と考えるものを羅列します。現在のレンダリングエンジンは、chrome74相当(2019年6月8日時点)の機能を持っています。高度なDOM操作をクライアント側で実行しても、クローラーは判別できるようになっていると思われます。実行に時間がかかったり、非常に広範囲の場所に要素を配置すると、解読できないばかりかクローラーのリソースを消費して得るものがない(インデックスできない)結果になります。この場合、同様のページが複数あればページだけではなくサイト全体のクロールバジェットを減らされる可能性があります。確かに便利になりましたがnoscriptでも、コンテンツが判別できるように構築したいです。レンダリングタイムアウトは、通常クロールで約20秒という実験結果が出ています。これは最長であって、JSネストによる他処理やローディング(サーバー処理時間)のクリティカルパスによっては、実際の実行時間が10秒でもインデックス出来ない可能性があります。インデックスできないということは、クローラーからみれば無駄足ですよね。無駄なサイトにクロールの労力を割くわけが無いので、クロールバジェットを減らされると考えています。現在は、JSを利用したサイト向けにも、各種試験(モバイルフレンドリーテストやURL検査など)が充実しているので、振る舞いをクローラーの目から充分に確認してください。検索に関連したJavaScriptの問題を修正する(タイトルの翻訳は私による)4xx/5xxのエラーを返すこと404/410は、クローラーがアクセスしたURLのコンテンツを、削除した事をGoogleに知らせます。通常運用でも発生することであり、何か問題がある訳ではありません。クローラーに4xx(コンテンツ削除、アクセス制限)を返したコンテンツが、その後どうなるかです。1)ステップ1通常のページと同様の速度でクロールを行い、発見後アルゴリズムの判断で404が検出された事を内部処理2)ステップ2(~1day)間違いで無いと判断したら検索結果から削除3)ステップ3(~1m)この間URLを復元すると、ほぼ元の順位に戻る4)ステップ4(1m~)クロールバジェットを徐々に減らされていくただし完全にゼロにはならない削除:404/410とアクセス制限:403/401の動きを簡単にまとめたら、以上のような感じです。503/500(サーバーエラー/サービス利用不可)1)ステップ1(~1w)高頻度で、再クロールを実施2)ステップ2(1w~1m)パーマネントエラーでインデックス削除クロールバジェットは404レベルこの間URLを復元すると、ほぼ元の順位に戻る3)ステップ3(1m~)クロールバジェットを徐々に減らされていくただし完全にゼロにはならないこうしてみると、サイトを一時中断するときは、404は使用せず503がベストだというのが分かります。概ね一ヶ月を超える期間でその状態にしていると、徐々にページの価値は失われ、クロール回数も減っていきます。サイトの状態やコンテンツをどうしたいのか、よく考えてクローラーに返却するコードを選んでください。矛盾をしたサイトマップを送ること私の記事を全て読んだなら、サイトマップとサイトマップ更新Pingがどれだけ重要か分かると思います。サイトマップに矛盾する内容を入れていたらどうなるかです。robots.txtでブロックされているURLをサイトマップで送信したとします。クローラーは、サイトマップに書かれたURLでクロールを行うとしますが、robots.txtでブロックされているためできません。このような行為は、該当URLのクロールバジェットを減らされるどころか、サイトマップを信用しなくなるかもしれません。通常運用にてlastmodで時刻を指定したURLに対して、robots.txtでブロックするような奇妙な人はいないとおもいます。このような運用は避けたいですね。矛盾のある組み合わせ(以下をサイトマップで送信)・robots.txtでブロックしているページ・noindexページ・エラーページ(5xx/4xx)・重複ページ・canonical元(※)・301リダイレクト元(※)(※)一時的(1ヶ月以内など)ならクロールを促進しサイトの構成変更に対応noindexを使うことnoindexは、検索エンジンに対しての絶対命令で、コードが正しく解読された場合、URLに付随する情報は検索結果から削除されます。メタタグで、htmlに書き込む事も出来ますし、クローラーのHTTPリクエストに対して、HTTPヘッダのレスポンスにnoindexを指定する事も出来ます。この命令は、インデックスの削除です。実行され次第、クロールバジェットは減らされていくと思います。そのURLに対して、インデックスの必要がありませんので、クロールすること自体も無駄になるわけです。唯一のクロール目的はnoindexが外されたか?をチェックすることです。外されたとしてもクロールバジェットが減らされているので、検出するのに多くの時間が消費されるでしょう。その場合は、サーチコンソールのURL検査で当該URLの更新リクエストをするのも手だと思います。頻繁にnoindexとindexを繰り返すという運用は向かないので、そういう使い方をしないでください。私は、日付archiveなどnoindexにしています。一度も戻したことはないですね^^;別のページを実装することクロールバジェットは、クロールの割り当て量です。サイトのタグで、1つのページから複数のページへ分岐する場合、クロールバジェットを消費します。1000ページの中規模サイトを持っており、全ページにメタタグで英語をの翻訳版を追加したとしたら、2000ページになってしまいます。レスポンシブでは無くモバイルとPCで別のコンテンツにした場合、4000ページになります。一気に大規模サイトの仲間入りかもしれません。1000コンテンツしかないのに、alternateで別のページを実装することでこのような状態になります。新規で中規模サイトを設計するときは、レスポンシブは必須としてどんな言語を実装するのか、ガラケーはどうするのかなど、充分な設計が必要です。クロールの統計情報を俯瞰するいろいろなサイトの統計情報や、自分の実験で分かった事があるので、見方を想定してみます。サイトの総量であるクロールバジェットの上限になっているか否かは、一般的なサイトでは分からないです。クロールの統計情報で分かるのは、サーバーのパフォーマンスとクロールレートの試行錯誤です。特徴として、次を挙げさせてもらいます。・高速なサイトはページ数がなだらかできめ細かい・低速なサイトはページ数がギザギザで高低が激しい・高速なサイトはダウンロード時間がなだらかできめ細かい・低速なサイトはダウンロード時間がギザギザで高低が激しいまたダウンロード速度の平均値は、2000以内になっていることが望ましいです。遅いサイトは、ノコギリの歯のようになるのでしょうか?それは、クローラーが沢山クロールしたいのにできないからです。クロールレート上限まで行く→調整してゆっくりになるこの繰り返しのため、ギザギザになるものと思われます。ダウンロード速度は2秒以内を目指し、サイトのパフォーマンスを調整することは、閲覧者を増やし、コンバージョンを増やすことに繋がりますので、もしパフォーマンスに問題があるようであれば、すぐにできる対策なので実施した方が良いでしょう。パフォーマンスは、ランキングに直接影響はありません。好まれるサイトは上位に行きやすいので、結果的に早いサイトが上位になっていることも、統計上明らかです。(サイバーエージェント木村氏の調査より)harukas.orgのクロールの統計情報(古いサーチコンソールのみ)サイトが早すぎて文句を言われるのを聞いたことがありません。遅いサイトはクロールレートに影響します。それよりも訪問者に対するエクスペリエンスの向上を目指したいですね。ECサイトで商品が品切れの時のベストプラクティスtwitterで、ジョンさんがECサイトの運営者と話していた内容です。質問者は、在庫があるときはindexで無い時は、noindexにしていました。これについてジョンさんは、noindexとindexを交互に繰り返す手法は良くないと言いました。noindexは、該当のURLを削除してインデックスしない命令です。それなのに、一時的に品切れだからと言って、noindexにすると、実際に入荷したときインデックスされない(時間がかかる)可能性があります。いう矛盾のある行為は避けた方がよいでしょうね。品切れの時のベストプラクティスは何でしょうか?2020年1月オフィスアワーで、ジョンさんが回答を出しました。どれがベストかという回答を控えました。在庫が無い場合は、以下の2パターンが考えられます。→場合によってはnoindex(はるか注:二度とその商品を置かない場合のみ)※代品が無い場合は、サイトの規模や運営者の意図に依存するという感じで、これだ!という回答は出ませんでした。想定通りの内容でした。以下は、私が買う立場だった場合の想定です。・概ね一ヶ月以上経つと品切れでrobots.txtでブロックなどを行う(404でも良いでしょう)・入荷の予定があれば入荷日/予定を書きインデックスする(ファンの店ならこれが一番)こんな感じですかね。入荷の予定が無いのに1年間売り切れとかはやめてほしいですwまとめクロールは、SEOの基本です。そのクロールがどんな条件で何を判断してどのくらい行われるかをまとめてみました。クロール数とランキングは別物です。・クロールバジェットが足りてないと思われる・クロールレートが非常に低く設定されているなどを問題とする場合、その影響をしっかり考えてください。検索順位が変わることでは無いので、対応の優先順位の付け方には注意してください。皆様の知識の向上に役立てたなら幸いです。フォーラム関連記事SEO対策タイトルとスニペットを検証するSEOに興味が出てきた頃から、マットさんの次のヘルプが大好きでした。このヘルプは神級で「暗唱できるレベルにすべき」とまで私は言っています。これはもの凄く簡単に説明が可能です。今回は内部リンクについては触れません。AMPは、恒久的に続く仕組みではありません。HTML5の利便性を享受できない言語であるという事を強く理解してください。重複コンテンツの対策についてコンテンツの複製は、多数の問題を発生させます。最大の問題は、検索者(お客様)への検索体験低下です。具体的には、次の通りです。就任」等で検索します。コメントをキャンセルメールアドレスが公開されることはありません。t("").html(tocplus.visibility_show).text():default:t(this).html(tocplus.visibility_hide),t.cookie&&(o?t.cookie("tocplus_hidetoc","1",{expires:30,path:"/"}):t.cookie("tocplus_hidetoc",null,{path:"/"})),t("#toc_container").css("width",tocplus.width).removeClass("contracted"),t("ul.toc_list").show("fast")}})}}});。