Google検索結果からフラグメント/ハッシュURLを削除する方法は？
私の古いサイトは、!なしでURLを書くために使用されていました。
例：www.example.com/#/products
しかし、次のようにURLに!を含めるように変更してから6か月以上が経過しています。
www.example.com/#!/products
ただし、残念ながら、Googleの検索結果にはまだ古いURLスキーマが表示されます。
Googleが無効なURLについて不平を言うので、Google削除ツールに（ウェブマスターツールを介して）入力してwww.example.com/#/productsを削除する方法はありません。
www.example.com/#/productsとGoogleを削除して、代わりに結果に/#!/productsが含まれているものを表示するだけです。
最初に、ハッシュを使用して古いURLを削除する手間をかける必要がありません。コンテンツが新しいハッシュバンURLの下で適切にクロールされ、インデックスに登録されると、すぐに置き換えられます。
ライブサイトに対するトラブルシューティングを行わない限り、問題が何であるかは完全には明らかではありませんが、これらの手順が解決策の発見に役立つことを願っています。
一般的な問題を排除することから始めます。
GooglebotがHTMLスナップショットにアクセスしているかどうかを確認します
AJAXクロール可能性の全体的な考えは、製品の画像、説明、および仕様にインデックスを付けることです。 GoogleのAJAXクロール機能の仕様 の適切な指示に従っていると想定しているため、GooglebotがHTMLスナップショットを表示できることを確認する必要があります。 Googleに正しいHTMLスナップショットが表示されない場合、これが、作成した新しいハッシュバングURLを反映するためにGoogleがインデックスを更新していない理由です。
Googleウェブマスターツール（GWT）を使用して、「クロール"Fetch as Google」セクションに移動します。次に、Goolgebotfetchとrenderに完全な_escaped_fragment_ URL => www.example.com/?_escaped_fragment_=productsをレンダリングさせます。すべて順調であれば、ステータスが「完了」と表示されます。ステータスをクリックして、特定の製品のHTMLスナップショットを表示することもできます。
ステータスに「Not Found」または「Blocked」が表示されている場合、それがおそらくGoogleがインデックス内のURLを更新していない理由です。
"Blocked"の場合、robots.txtファイルにGooglebotがHTMLスナップショットにアクセスできないようにするルールがあることを意味します。
それが "Not Found"の場合、それはおそらくHTMLのサーバー側レンダリングに？_escaped_fragment_ =で適切なルートリクエストにnginxを設定していないことを意味しますスナップショット。
"Partial"が表示される場合、ステータスをクリックして、Googlebotからブロックされているさまざまなリソースを確認する必要があります。ただし、基本的に、ページのGoogleのレンダリングのサムネイル画像に適切なコンテンツが表示されない場合、Googleがレンダリングする必要のあるリソースをブロックしている可能性がありますコンテンツを出力します。
AngularがHREFのHashBang URLをレンダリングしているかどうかを確認します
レンダリングされたページのサムネイルが正しい場合、Googlebotはサーバー側でレンダリングされたHTMLを表示でき、_escaped_fragment_リクエストのルーティングが正しいことを確認しました。これは、Googlebotが新しいハッシュバンURLを発見していないように見えるため、フロントエンドを指します。
アクセスログの簡単なチェックは、この問題の確認に役立ちます。 Splunk、LogStash、または適切なole grepが手元にある場合は、次の基準を持つリクエストを検索する必要があります。
- ユーザーエージェントに「googlebot」が含まれています
- リクエストURLに「？_escaped_fragment_ = products」が含まれています
- iPのリクエストは「66.249」で始まります
基本的に、すべての 検証されたGooglebotリクエスト を探します。 Googlebotのほとんどは66.249.*.*から来ています。
GWTの「クロール"クロール統計」にリストされている1日あたりのクロールされたページ数と比較して多くのリクエストが表示されない場合、Googlebotはアンカータグのhref属性でハッシュバンURLを表示できない可能性があります。
ChromeまたはFirefoxでwww.example.com/#!/productsおよびInspect Elementに移動する場合、レンダリングされたHTMLに明確なアンカータグがあることを確認する必要があります。 hashbangバージョンのURLを含むhrefを使用します。そうでない場合は、Angularを再構成して再構成する必要があります。
そこに表示される場合は、www.example.com/#!/productsまたはホームページのような、hashbang URLにリンクするhref属性を持つアンカータグを持つ別のページを取得してレンダリングする必要があります。
ステータスをクリックしてページの「レンダリング済み」バージョンを表示すると、デフォルトの「レンダリング」タブの横にある「フェッチ」タブをクリックして、HTTP応答ヘッダーと結果のHTMLを表示できます。
[フェッチ]タブの適切な場所にハッシュバン参照が見つからない場合は、Angularスタックをステップ実行して、切断が発生している場所を確認する必要があります。 GooglebotによってブロックされているアセットファイルでJavaScriptリダイレクトを実行している可能性が高く、更新された参照が表示されない可能性があります。
他のすべてが失敗した場合
上記のいずれでもない場合は、Google自体のバグである可能性が高くなります。これは実際に時々発生し、Google社員は賢い人ですが、時々間違っていることもあります。
Googleウェブマスターフォーラム：クロール、インデックス、ランキング にジャンプしてください。フォーラムに頻繁にアクセスする多くのGoogle社員の1人が調査してくれることを願っています。
代替ソリューション
したがって、すべてのことを言って完了した後、_escaped_fragment_標準を使用しないことを強くお勧めします。 Googleが公開したものであり、Bingに採用されていますが、サイトがそれを正しく実装していることはめったになく、インデックス付きページのトップ検索結果にハッシュバンURLが表示されることはほとんどありません。
エンジニアリングの時間とリソースがある場合は、pushState（）の使用に移行することをお勧めします。 pushStateを使用すると、クライアント側とサーバー側の両方のリクエストを処理するためにルートにロジックを追加する必要がありますが、標準タグを使用することで、？_ escaped_fragment_オーバーヘッドをいじる必要がなくなります。
Angular + pushStateは、最もよく文書化されたものではありませんが、スタックの残りの部分によっては、いくつかの良い投稿があります。
最後に、私は過度に自己宣伝したくありませんが、これらのことが進むにつれて、会話は最終的に「事前レンダリング」対「サーバー側」レンダリングにつながります。 SMX Advancedでのトーク いくつかの一般的なAJAXクロール性の問題をカバーしました。スライド34にジャンプすると、長所と短所のいくつかを見ることができます。また、スライド49および50には、他のいくつかの優れたAngular + SEO投稿への参照があります。
Googleウェブマスターのツールを使用してからしばらく経ちましたが、ウェブサイトのインデックスページを削除するツールがあることを覚えています。
**そうするには、ウェブサイトを特定のウェブマスターのツールアカウントにリンクする必要があります...
https://www.google.com/webmasters/tools/dashboard
ログインするか、新しいアカウントを作成します（上記のWebサイトにリンクします）
googleインデックスをクリックして、[URLの削除]を選択します
最初のページで、削除するすべてのURLを挿入します。...**
URLを変更した場合は、古いURLを新しいURLに301リダイレクトする必要があります。これを行うと、ウェブサイトのクロール速度に応じて1か月程度以内にGoogleのインデックス登録ステータスが自動的に更新されます。
301リダイレクトの完全なガイドを次に示します