web-dev-qa-db-ja.com

Googleは、パーセントエンコード/デコードのみが異なるリダイレクト後にURLのインデックスを作成していませんか？

Googleのクローラーは、リダイレクト元URLとリダイレクト先URLの違いが特定の文字がパーセントエンコードされているかどうかだけである場合、リダイレクトに従うことを拒否しますか？例えば：

  • www.splunkbase.com/apps/All/4.x/Add-On/app:PDF+Report+Server+%28install+on+Linux+only%29
  • www.splunkbase.com/apps/All/4.x/Add-On/app:PDF+Report+Server+(install+on+Linux+only）

これらは両方とも、HTTP仕様に従って、有効で同等のURIですが、サイトのコードは常に各コンテンツページ（この場合は最初にリストされているURL）の「標準」URLにリダイレクトします。

Googleは明らかに（どちらのURLバリアントでも）このページのインデックスを作成していません。 "PDF Report Server（Linuxのみにインストール）" を検索すると、上記のURLはどちらも表示されません。

Googleウェブマスターツールは、URLの「デコードされた」バリアントの「リダイレクトエラー」を報告します：www.splunkbase.com/apps/All/4.x/Add-On/app:PDF+Report+Server+(install+on+Linux +のみ）

別の問題は、現在、正規化を処理するために301リダイレクトではなく302を使用していることです。リダイレクトを正規化するためにすぐに301に切り替えています。

しかし、302対301の問題は赤いニシンかもしれないと思っています。実際の根本的な問題は、Googleの目には、HTTP仕様に従って、URLをそれ自体にリダイレクトしていることです。エンコードされたURLとパーセントエンコードされていないURLは、クライアントとサーバーで同じように扱われる必要があります。

関連するスレッドを見つけました こちら 。同じ問題ではありません。リダイレクトされたURLの違いは、パーセントエンコードされた16進値の大文字/小文字のみでした。しかし、それは私たちの問題と疑わしく似ています。

最後に、私の質問：このパーセントエンコードプラスリダイレクトの問題に遭遇した人はいますか？ 301への切り替えで修正されましたか、それとももっと必要でしたか？

301-ingを超える回避策として、この場合のREL = CANONICALの使用とリダイレクトのオフから、アポストロフィ、括弧、その他の通常ではないパーセントのエスケープをオフにするためのエスケープの変更まで、さまざまなオプションを検討しています。エスケープされた文字。

長期的な修正については、次のことを検討しています。

  • このサイトのように、数値IDをキーとして使用し、タイトルの後のSEOテキストの変更を処理するためにREL = CANONICALを追加し、リダイレクトは行わない
  • 多くのブログのように、タイトルを正規のURLとして使い続け、リダイレクトを続行しますが、問題のあるすべての文字をダッシュ​​で切り替えるので、エンコード/デコードについて心配する必要はありません。
seogoogleredirectsgoogle-search-console
2
Justin Grant

これらのURLは理論的には同等であるため、リダイレクトはそれ自体へのリダイレクトと見なされる可能性が高く、これがクロールエラーの原因になります。一般に、その場合（そうだと思います）、そのレベルのURLを正規化しないことをお勧めします。URLを同じURLの別の表現にリダイレクトしません。

同様に、これら2つのURLにrel = canonicalリンク要素を使用する必要はありません。パスまたはURLパラメーターの大文字と小文字が異なるなど、代替バージョンがある場合は使用しても構いませんが、これら2つのURLに対してのみ効果はありません。

価値があるものとして、GoogleがこのようなURLをどのように認識するかをテストする簡単な方法は、ウェブマスターツールでFetch as Googlebot機能を使用することです。リダイレクトには従わないため、どのURLがフェッチされるかを正確に確認でき、さまざまなバリエーションを試して、どのように反応するかを確認できます。

関連するメモでは、ユーザーがスペースを使用するURLにリンクするのが難しい場合があるため（たとえば、URLをフォーラムにコピーして貼り付ける場合）、あなたが言及したようなURLを使用することは少し問題があるようです。適切なリンクが与えられると、Googleはそれをたどることができますが、サーバー側のソフトウェアが完全なURLを認識しない場合、そのリンクは破損する可能性があります。

4
John Mueller

まず、GoogleがいずれのURLバリアントもインデックスに登録していないという事実は、URL自体の問題を示しているわけではありません。 Googlebotがまだそのページをクロールしていないか、十分に面白いとは思わないなど、別の理由が考えられます。

いくつかの手順を提案します。

  1. リダイレクトを完全に削除する。あなたが言うように、URLはとにかく同じものとして扱われます。実際、Google Chromeは%28を(に自動的に変換します。一部のブラウザでは反対のことを行う場合があります-(を%28に変換すると、問題が発生する場合があります。
  2. 「標準」バージョンへのリンク。言い換えれば、あなたが管理しているすべてのリンクが、正しい括弧付きのバージョンを指していることを確認してください。
  3. サイトマップに正規バージョンを入れてください。 XMLサイトマップをまだお持ちでない場合は、作成してGoogleウェブマスターツールに送信してください。
  4. rel = canonicalを使用を使用して正しいURLを設定します。括弧付きのバージョンをそこに配置すると、Googleは他のバージョンではなく検索結果にそれを表示する必要があります。

最後の提案は、可能であればURLから特殊文字を削除することです。 URLはファイル名に基づいているようです。おそらく、ファイルをアップロードするときに、ウェブサイトで使用するための「スラッグ」を生成します。 pdf-report-server-install-on-linux-onlyとURLで代わりに使用します。

3
DisgruntledGoat

Apacheを使用している場合、リダイレクトを送信するのではなく、要求されたページを提供するだけで正規のURLを処理するように mod_rewrite を使用することを強くお勧めします。

あなたの根本的な問題は、あなたがUTF-8エンコーディングを必要とするウェブサイト全体でURLを使用しているという事実です。あなたのキャラクターセットを制限するために完全にきれいに見えるとは限りませんが、他のサイトがあなたのサイトへのリンクを開始すると、本当に役立つでしょう。他のサイトはURLを再エンコードする可能性が高く、気付かないうちに検索エンジンが正規化されたリンクにアクセスしようとします。

私の最善の解決策は、リンクをUTF-8文字なしのリンクに変更し、410 GONEまたは404 NOT FOUND応答を送信し、修正されたURLのヘッダーに5秒のリダイレクトを追加することです。数週間待ってください。修正されます。

もちろん、ページが古い（1年以上）場合、これは修正されない可能性があります。

（編集tidbit：410 GONEは、絶対にスパイダーされるべきではないURLで最適に動作するように思われました。たとえば、一時ファイルやセッションデータが$ _GETにあるURL。）

2
Talvi Watia