【SEO】低品質・重複ページの処理をGoogleに伝える方法
低品質・重複コンテンツを一斉処理したが、一刻も早くGoogleに認識してほしい。そのような思いで現在取り組んでいる内容について紹介します。
まずは結論！
低品質・重複コンテンツを大量に処理する場合、次の方法を取るとGooglebotのクロールを早めることができます。
すべての低品質・重複コンテンツを404・410エラー処理する
「誤ったURLだけのサイトマップ」をGoogleに送信する
リダイレクト処理したことをGoogleに認識してほしい
”スパムリンク「/1000」で生じた重複ページの処理方法”で触れた通り、弊サイト「MY就活ネット」には約16,500件もの低品質・重複コンテンツが発生しており、中にはインデックス登録されてしまったものもあります。
意図しないパラメータをつけられ、「画像・CSSを読み込まず内部リンクもすべて壊れていてさらに内容が重複している”ダメページ”」を一斉に処理したのですが、Googleによる再クロールは遅々として進みません。なぜなら、「ダメページ」などクロールする価値がないからです。
実際、それらの「ダメページ」はスパムとGoogleしかアクセスしないURLではあるのですが、インデックス登録されてしまったものがある以上は間違いなくSEOにマイナスの影響を与えています。筆者としては、処理したことを一刻も早くGoogleに認識してほしいわけです。
具体的な対策
この問題に気づいたのが2024年5月初週で、以下の対策を取りました。
すべてのページにrel="canonical"を設定する
SearchConsoleで「検証」を開始する
すべてのパラメータを無効化する（htaccessでリダイレクト）（24/07/11より410エラー処理）
「ダメページ」だけのサイトマップを送信する
1.すべてのページにrel="canonical"を設定する
結論から言うと、この方法は確実ではありません。URL正規化に関する公式ヘルプによると、カノニカル設定は「301リダイレクト」と同等の「強いシグナル」だとされています。しかし、実際にはカノニカルを無視して「ダメページ」のインデックス登録を続ける動きが見られました。
この理由は、カノニカルはそのページの存在を許すタグだからです。
絞り込み検索や解析用に付与されるパラメータURLなどの類似ページは正規ページを決めてcanonicalを設定します。例えば不動産サイトでは「新着順」「価格の安い順」「人気順」といった検索結果の並び替え機能、通販サイトでは色別に存在する商品ページなどが該当します。検索結果の並び替え機能は、コンテンツの順番が異なっているだけで中身が同じであることからURL正規化すべきページとなります。
ゆえに、基本的にはインデックス登録されないのですが、Googleの判断によっては検索結果に露出することがあります。しかし弊サイトに発生しているのは「画像・CSSの一切を読み込まず内部リンクもすべて間違ったバージョン」ですから、それを誰が有益だと思うのか不明です。
2.SearchConsoleで「検証」を開始する
この方法も間違っています。当初はカノニカル設定、後に301リダイレクトを施してSearchConsoleで「検証」を開始したのですが、すぐに「失敗しました」という通知が返ってきました。
これはどうやら「ダメページが有益なページになった」場合に使うコマンドのようで、「カノニカル設定」や「リダイレクト」を検出すると「問題が解決されていない」という扱いになり、検証が終了してしまいます。
この結果、1ヶ月経過してもカノニカル設定がGoogleによって認識されたのはたったの140ページで、ダメページ16,500件に対して1％にも満たない数値です。これでは処理の完了に10年かかってしまいます。
3.すべてのパラメータを無効化する（htaccessでリダイレクト）（24/07/11より410エラー処理）
前述の通り、カノニカル設定を無視する動きが見られましたので、すべてのダメページをhtaccessで301リダイレクトすることにしました。
最初からこうすればよかったのですが、いくら検索しても「スラッシュ区切りのパラメータ」を処理する方法が出てこず、設定に1ヶ月もかかってしまいました。
htaccessの具体的な記述については、”スパムリンク「/1000」で生じた重複ページの処理方法”で解説しています。
（24/07/11追記）
301リダイレクトがペナルティを引き継ぐことと、そもそも今回の重複ページから引き継ぎたい評価がないことから、「410 Gone」のステータスコードを返すことにしました。つまり、リダイレクト処理は廃止です。
（24/07/19追記）
SEARCH ENGINE ROUNDTABLEで調べていると、下記記述が見つかりました。
if the links are going to URLs that 404 on your site, they're already dropped. They do nothing. If there's no indexable destination URL, there's no link. I'd generally ignore link-spam, and definitely ignore link-spam to 404s.
リンクがサイト上の 404 の URL にリンクしている場合、そのリンクはすでに削除されています。何もしません。インデックス可能なリンク先 URL がない場合、リンクはありません。私は通常、リンク スパムを無視しますが、404 へのリンク スパムは絶対に無視します。
つまり、否認ツールを使わずとも削除のステータスコードを返せば、不正な外部リンクを無効化できるということです。また、Google検索セントラルには以下の記述がありました。
URL をリダイレクトすると、Google は、リダイレクト元（元の URL）とリダイレクト先（新しい URL）の両方を記録します。URL の 1 つが正規版になります。どちらが使用されるかは、リダイレクトが一時的か永続的かなどを示すシグナルによって異なります。もう 1 つの URL は正規 URL の代替名になります。代替名は、ユーザーの認知度や信頼性が高い正規 URL 以外のバージョンです。ユーザーのクエリから、古い URL がより信頼されていると解釈される場合、検索結果に代替名が表示されることがあります。
つまり、canonicalもリダイレクトも、そのURLの存在を許すシグナルだということです。有効な外部被リンクを受けている場合を除き、（不正なパラメータをつけられるような）スパムリンクに対しては404・410のステータスコードを返すのが最適ということになります。
4.「ダメページ」だけのサイトマップを送信する
「ダメページ」の再クロールを促進するために「ダメページだけのサイトマップ」をあえて作成し、SearchConsoleを通じて送信しました。この対処法は、Google公式ヘルプに記載されている方法です。
A: URL が変更または削除された場合は、一時的にサイトマップ ファイルに URL を記載して送信することで、再クロールされるようにすることができます。ただし、今後お客様のサイトや Google 側で混乱が生じないように、必ず 1 か月後をめどにそのサイトマップ ファイルを削除してください。
結果は斜め上の方向に
1&2の方法が失敗に終わり、3&4の方法に切り替えて約3週間が経過しました。気になる結果はというと、斜め上の方向でした。
下記画像の通り、「ダメページだけのサイトマップ」を送信した当日から、Googlebotのクロール数が急増しています。平時なら1日200～300件のクロール数が1,918件をマークしたのです。
では問題が解消に向かっているかというと、確かに「リダイレクトの認識スピード」は上がりました。「サイトマップなし」に比べて10倍速です。これなら1年ですべての処理が終わるでしょう。
ちなみに、1,918件の後にも大きな波が生じているのはサイトマップにURLを追加して送信した日です（エラーページは最大1,000件までしか表示されないためSearchConsole上のデータが更新されるたびに追加送信しています）
ところが、リダイレクト認識件数1,597件のうち、サイトマップで送信したページは555件しか含まれていなかったことが発覚しました。
要するに、Googlebotはサイトマップがきっかけなのに、サイトマップを参照せずにクロールしているということです。
【検証中】サイトマップに関する考察
現在、並行してサイトマップのlastmodに関して検証中なのですが、そちらでわかったのが「lastmodが信用されていないとGooglebotはサイトマップから直接クロールに行かない」ことです。
今回の「ダメページだけのサイトマップ」の場合、何千件ものURLに日付を付するのがめんどくさかったので、URLだけびっしり書いたtxtファイルを「サイトマップ」として送信していました。
するとbotは「lastmodの信用度以前にそもそも記述がない」ために、サイトマップから直接クロールには行かず、「Googleのデータベースに保存されているダメページ」から「サイトマップに記載のURL」を「検出」しに行ったと推測されます（この推測は上記リンク先で複数の根拠を解説しています）。
実際、「送信済みページ」の中でリダイレクトが認識されたページを「URL検査」してみると、「参照元サイトマップが検出されませんでした」となっており、また参照元にはリダイレクト処理済みの「アクセスできないはずのページ」が表示されています。
「検出」する過程でサイトマップで送信していないダメページを大量発見し、それらのリダイレクトを先に認識したのでしょう。結果的に「ダメページ」が大量再クロールされていますので問題はないのですが、サイトマップ検証のため次の処理を行いました。
「ダメページだけのサイトマップ」にlastmodを付与
非常にめんどくさかったのですが、「ダメページだけのサイトマップ」についても、すべてのURLにlastmodを付与しました。
左の「URLのみのデータ」について、「リダイレクト先のファイルの最終更新日時」を取得してxml化するphpプログラムをわざわざ組んで、「lastmodつきの新サイトマップ」を生成しました。
特に「mykk.php」はパラメータに応じて外部ファイルを読み込んで表示する仕組みになっており、外部ファイルの最終更新日時を取得しなければならないのにパラメータ自体に「/1000」を付与されてしまったために取得がうまくいかず苦労しました。
これでもし、「ダメページ」に関してサイトマップに記載したURLを優先してクロールするようになれば、「lastmod超重要説」の1つの根拠になってくれるでしょう。
24/07/01時点の状況
24/07/01にSerachConsoleのデータが更新されたため、経過を記録します。反映されているのは、まだ「サイトマップにlastmodを付与する以前」のデータです。また新サイトマップとGoogleデータベースが紐づくのには時間がかかるため、しばらくは「lastmod未反映」の状況が続くと考えられます。
データの変化は「重複コンテンツ」から「リダイレクト」に300件移動しました。「低品質コンテンツ」に変化は見られませんでした。4日で300件ということは、残り約14,500件の処理を終えるのに193日かかる計算です。
24/07/03時点の状況
24/07/03にSerachConsoleのデータが更新されたため、経過を記録します。結論から言うと、「まだ新サイトマップと各ページが紐づいただけ」の段階です。依然としてサイトマップ関係なしに再クロールを続けていますが、2日で245件の新規リダイレクト認定がありましたので、認識速度は上がっています。
24/07/07時点の状況
新たに「サイトマップのURL検出は『PC用Googlebot』と『その他のエージェント』が担当している」ことが発覚しました。これは、サイトマップにURLを追加して送信した日のクロールリクエスト数を足し算したところ、「検出」の数とほぼ一致したためです。
インデックス更新は「スマートフォン用Googlebot」がクロールして初めて行われることはすでに広く知られているかと思いますが、「サイトマップからの検出」を「スマートフォン用」が担当していない以上は、リダイレクト確認に時間がかかってしまうということです。
おそらくPC用・その他が「インデックス更新の必要度」を判断し、それに基づいてスマートフォン用が動き出すのでしょう。スマートフォン用は「リダイレクト確認済みのページをもう一度確認する」という「削除」と同様の確認行為に力を入れているようですから、もしかすると本当に処理に1年かかるかもしれません（個人的には『確認行為』にこそ『その他のエージェント』を使うべきだと思います）。
また、同日SerachConsoleのデータが更新されたため、経過を記録します。リダイレクト確認は徐々に進行しており、5月に勘違いにより設定したcanonicalページも再クロールが始まっています。
24/07/11時点の状況
未登録ページ16,701件が、16,622件に減少しました。Googleデータベースからどのページが消滅したのか特定するのに時間がかかりましたが、結論から言うと「サイトマップ」「参照元」の両方を失ったページでした。
すべてのダメページを「URLがGoogleに認識されていません」にするべく動いてきたわけですが、ようやくゴールにたどり着くページが出てきました。
今回のダメページはすべて「*.php/1000」が発生源ですから、当該ページの場合は参照元ページに「sibo.php/1000」があったはずです。しかし、「sibo.php/1000」のリダイレクトが確認され、「sibo.php/esdl.php」への内部リンクが確認できず、宙ぶらりんになった結果データベースから削除されることになりました。
一方で「/1000をrobots.txtでクロール禁止にするとどうなるだろう」と実験を行ったページがあります。具体的には「es_chosho.php/1000」のクロールを禁止することで、「es_chosho.php/*.php」を宙ぶらりんにしようとしたわけです。
確かに「参照元」は消えているのですが、「URLがGoogleに認識されていません」にはなっていません。ここから推察されるのは、robots.txtによって参照元の存在が保留されているため、「参照元が消えたという最終判断ができない」のであろうと思われます（robots.txtでのクロール禁止は、当該ページの不存在を表す行為ではないため）。
ここに至るまでの具体的な方法を次にまとめます。
重複コンテンツを生じさせている不正な外部リンクを否認する
すべての低品質・重複コンテンツをリダイレクトないし削除する
上記URLをすべてサイトマップで送信しクロールを促す
「送信済み」になったURLはサイトマップから削除する
robots.txtは使わない
現状、この手順が最速かと思います。GoogleデータベースからURLを削除するには「宙ぶらりんにする」ことが重要ですので、「参照元ページ」になっているものを優先的にクロールさせて、Googleが認識したURLは「サイトマップから削除」することが必要です。
24/07/14時点の状況
未登録ページが半減しました。前回更新時は16,622件あった未登録ページですが、14日夜の更新で7,993件まで減少しました。
消滅したURLはほぼすべて「クロール済み - インデックス未登録」に計上されていたもので、こちらが9,758件から1,199件まで減少しています。
別で運営しているゲームサイトのほうは「リダイレクト・404処理」以外は特に何もしていないのですが、そちらも同様に「インデックス未登録」のみ大幅減少していました。つまり、重複コンテンツはデータベースから消滅していないということです。
このことから、低品質コンテンツと重複コンテンツは別々のアルゴリズムが働いていることがわかります。
さて、今回消滅したURLの特徴は、次の3点をすべて満たしたことです。
「クロール済み - インデックス未登録」に計上されていたもの
参照元のリダイレクト・削除がGoogleに認識されて1ヶ月が経過したもの
最終クロールから6ヶ月が経過したもの
上述の通り、「重複コンテンツ」や「参照元のリダイレクト・削除がGoogleに認識されていないもの」は未だデータベースに残っています。今後はこちらを優先的にクロール促進しようと思います。
24/07/17時点の状況
未登録ページがさらに1,000件減り、「低品質」「重複」のページが約2,800件にまで減少しました。
今回は重複コンテンツが多く処理されましたが、気になるのは「リダイレクト」が500件近く増加していることです。7月11日より301をやめて410に切り替えていますから、今回の増加はそれ以前のPC用・その他botのクロールを今さら反映したということになります。
1ヶ月間スマートフォン用botのクロールがなければ、先遣部隊としてクロールしたPC用・その他botのデータで更新されるということでしょうか。
また、前回データが7/13、今回が7/16のものですが、削除認識件数が3日で421件とかなり早めです。404や301に比べて、410は「再確認のためのクロール」が非常に少ないようです。410設定から5日経ちましたが、二度目のクロールがまだない状況です。
未処理ページが約2800件ありますが、すべての削除を認識させるにもそう時間はかからなそうです。