SEO JavaScriptサイトのガイド。 パート2.問題、実験、推奨事項

この記事翻訳の最初の部分では 、ウェブマスターがGoogleの目を通して自分のリソースをどのように見ることができるか、そしてサイト開発者が見ているものが期待していない場合に取り組む価値があるものについて話しました。

画像

本日、翻訳の第2部では、Tomasz RudskyがJavaScriptベースのサイトがさらされる最も一般的なSEOエラーについて説明し、Googleの今後のAJAXクロールの影響について議論し、事前レンダリングと同形JavaScriptについて話し、インデックス作成実験の結果を共有します。 ここで、さらに、彼はさまざまなタイプのサイトのランキング機能のトピックに触れ、Google以外にもJSベースのWebページを処理する必要がある他の検索エンジンがあることを思い出してください。

ページの正常な形成に必要なリソースについて


あなたの意見では、Googlebotが特定のページを処理できるが、このページが本来のようにインデックスされていないことが判明した場合、ページを形成するために必要な外部および内部リソース(JSライブラリなど)が利用可能であることを確認してください検索ロボット。 彼が何かをロードできず、ページを正しく再作成できない場合は、インデックスを作成することもできません。

Google Search Consoleの不定期の使用について


以前に安定して確実に機能していたサイトの評価が急激に低下した場合、Googleがサイトを適切に処理できるかどうかを確認するために、前述のFetch and Renderツールを使用することをお勧めします。

一般に、検索エンジンによる適切な処理の可能性を確認するために、サイトページの任意のセットでFetch and Renderを使用すると便利な場合があります。


Robots.txtによってブロックされたリソースのリスト

危険なイベントonClick


Googlebotは実際のユーザーではないことを忘れないでください。リンクやボタンを「クリック」したり、フォームに記入したりしないことは当然と考えてください。 この事実は多くの実際的な結果をもたらします:


これはジョンミュラーによって確認されています。


上記を確認するジョン・ミュラーのコメント

サイト調査にChrome 41を使用したことに関する以前の記事の 1つに、Googleのインデックスシステムの可用性についてメニューを確認するプロセスを示す短いガイドがあります。 この資料をよく理解することをお勧めします。

リンクで#アイコンを使用する


JSフレームワークが#記号を使用してURLを作成することは今でも一般的な習慣です。 Googlebotがそのようなリンクを処理しないという本当の危険があります。

以下に例を示します。


これは、 #!文字シーケンスのURLには適用されないことに注意してください#! (いわゆるhashbang)。

おそらく、これはすべて重要ではないと判断するでしょう。 確かに-大したこと-アドレスに1つだけ余分な文字。 ただし、これは非常に重要です。

ジョン・ミュラーをもう一度引用します。

「(...)私たちの観点から、ここで#記号のようなものが見られる場合、これはその後に続くものが重要でないことを意味します。 ほとんどの場合、コンテンツのインデックスを作成するとき、そのようなことは無視します(...)。 このコンテンツを実際に検索に表示する必要がある場合、より静的に見えるリンクを使用することが重要です。」

その結果、Web開発者はリンクがexample.com/resource#dsfsdようなものに見えないようにする必要があると言えexample.com/resource#dsfsd 。 このようなリンクを形成するフレームワークを使用する場合、それらのドキュメントを参照する必要があります。 たとえば、Angular 1はデフォルトで#記号を使用するアドレスを使用します。 これを修正するには、 $locationProvider適宜設定します 。 ただし、たとえば、Angular 2では、追加設定なしで、Googlebotがよく理解しているリンクを使用します。

遅いスクリプトと遅いAPIについて


JavaScriptベースのサイトの多くは、Googleがスクリプトの動作を待つ時間が長すぎるため(ロード、解析、実行を待つことを意味する)、インデックス作成の問題が発生します。 スクリプトが遅いと、Googlebotがサイトをクロールするための予算をすぐに使い果たしてしまう可能性があります。 スクリプトを高速化すると、Googleがスクリプトをダウンロードするのにそれほど長く待つ必要がなくなります。 これについてもっと知りたい人のために、ページレンダリングプロセスの最適化に関するこの資料をよく理解することをお勧めします。

JavaScriptに基づくサイトの機能を考慮した、不十分な検索エンジン最適化とSEO


ここでは、最高の検索エンジン最適化サイトにも影響を与える可能性のある問題を提起したいと考えています。


SEOおよびJS機能を使用したSEOへの従来のアプローチ

JavaScript機能に基づくSEOは、従来の検索エンジン最適化に基づいていることを覚えておくことが重要です。 言葉の通常の意味で適切な最適化を達成しないと、JSの機能を考慮してサイトを最適化することは不可能です。 SEOの問題に遭遇したとき、JSに関連していると最初に感じるかもしれませんが、実際には、問題は従来の検索エンジン最適化にあります。

Justin Briggsが記事「 JavaScriptのSEOのコア原則 」の「JavaScriptの制限とSEOの混同」のセクションで既に完全に説明しているため、このような状況の詳細は説明しません。 この便利な記事を読むことをお勧めします。

Googlebotは2018年第2四半期からAJAXクロールを使用しません


Googleは、2018年の第2四半期から、AJAXスキャン(AJAXクロールスキーム)を使用しないことを発表しました。 これは、GoogleがAjax(非同期JavaScript)を使用したサイトのインデックス作成を停止するということですか? いいえ、そうではありません。

GoogleがJSを使用するサイトが増えているが、そのようなサイトを適切に処理できないことに気付いた当時、AJAXスキャンが登場したことは言及に値します。 この問題を解決するために、ウェブマスターは、検索ロボット用に設計された、JSスクリプトを含まない特別なバージョンのページを作成するように求められました。 これらのページのアドレスに_=escaped_fragment_=を追加する必要がありました。

実際には、ユーザーはexample.com本格的で快適なバージョンで作業し、Googlebotはexample.comようなリンクにつながるサイトのそれほどきれいではない同等物にアクセスしexample.com?_=escaped_fragment_= (ちなみに、まだ非常に人気があります)ボットの材料準備アプローチ)。

仕組みは次のとおりです(Googleブログからの画像)。


ユーザー用とボット用のサイトの異なるバージョン

このアプローチのおかげで、ウェブマスターは1石で2羽の鳥を殺すことができました。両方のユーザーが満足し、検索ロボットが満足しています。 ユーザーにはJavaScript機能を備えたバージョンのサイトが表示され、通常のHTMLとCSSのみを取得するため、検索エンジンはこのサイトのページに正しくインデックスを付けることができます。

AJAXスキャンの問題について


Ajax Crawling Schemeの問題は、ユーザーと検索ロボットが異なるバージョンのサイトを取得するため、インデックスサイトに関連する問題を分析することが非常に難しいことです。 さらに、一部のウェブマスターは、検索ロボット向けのページのバージョンの準備に問題がありました。
Googleが、2018年の第2四半期から、ウェブマスターがウェブサイトの2つの異なるバージョンを作成する必要がなくなったと言った理由は次のとおりです。


AJAXスキャン無効メッセージ

これはWeb開発者にどのように影響しますか?

  1. Googleは、独自のリソースでサイトページを作成します。 これは、開発者がGoogleにそのような技術的能力があることを確認する必要があることを意味します。
  2. Googlebotは_=escaped_fragment_=を含むリンクへのアクセスを停止し、一般ユーザー向けの同じ資料のリクエストを開始します。

さらに、開発者はサイトをBingやその他の検索エンジンからアクセスできるようにする方法を見つける必要があります。Bingやその他の検索エンジンは、JavaScriptベースのサイトの処理に関してはまだGoogleに遅れています。 可能なソリューションには、サーバーレンダリング(ユニバーサルJavaScript)、または奇妙なことに、Bingbotの古いAJAXスキャンの継続的な使用があります。 これについては以下で説明します。

Googleはページ処理に最も高度なブラウザーを使用しますか?


Googleが最新のテクノロジーをサポートするためにサイト処理サービスを更新するかどうかは不明です。 これが行われることを願うばかりです。

GoogleがJSに基づいてページを処理することを望まない人や、事前に準備されたページのみを含むコンテンツについてはどうでしょうか?


私はこれについて多くのことを考えたので、JavaScript SEOフォーラムのJohn MuellerにUser-Agentを使用してGooglebotを見つけて、事前に準備したバージョンのサイトを提供できるかどうかを尋ねることにしました。


Googlebot専用に準備されたサイトのバージョンに関するジョンミュラーへの質問

彼の答えは次のとおりです。


ジョン・ミュラーの答え

ジョンは、開発者がUser-Agentヘッダーを確認し、事前に準備したページのHTMLスナップショットを提供することで、自分のサイトがGooglebotをクロールすることを確認できることに同意します。 これに加えて、ページの事前レンダリングが正しく機能することを確認するために、ページスナップショットを定期的にチェックすることをお勧めします。

Bingを忘れないでください!


GooglebotがJSフレームワークに基づいてサイトを理想的に処理し、あなたがそれで問題を抱えていないことを想像してください。 これは、そのようなサイトのインデックス作成に関連するすべての問題を忘れることができるということですか? 残念ながら、そうではありません。 米国では、インターネットユーザーの約3分の1を使用しているBing検索エンジンを思い出してください。

現在、BingがJavaScriptをまったく処理していないと想定するのが賢明です(高格付けページでBingがJSを処理しているという噂がありますが、これらの噂の確認は見つかりませんでした)。

興味深い研究についてお話ししましょう。

Angular.ioは、Angular 2+の公式Webサイトです。 このサイトの一部のページは、単一ページのアプリケーションとして作成されています。 つまり、HTMLソースコードにはコンテンツが含まれていません。 そのようなページをロードした後、外部JSファイルがロードされ、それによってページのコンテンツが形成されます。


ウェブサイトAngular.io

Bingはこのサイトのコンテンツを見ないようです!


BingはAngular.ioサイトのコンテンツを表示しません

このサイトは、Bingの「Angular」キーワードで2番目にランクされています。

Angular 4クエリについてはどうですか。 再び-AngularJS.orgサイトの下の2番目の位置(これは公式のAngular 1サイトです)。 「Angular 5」のリクエストで-再び2番目の位置。

BingがAngular.ioで動作できないことを証明する必要がある場合は、 siteコマンドを使用して、このサイトからテキストの一部を見つけてください。 あなたは成功しません。


チェックするテキストの断片を選択する


サイトを検索するときにテキストが見つかりませんでした

私にとって、これは奇妙です。 Angular 2の公式Webサイトは、Bingbotロボットによって正常にクロールおよびインデックス登録できないことが判明しています。

Yandexはどうですか? Yandexで「Angular」という単語を検索すると、Angular.ioは上位50の結果にさえ含まれません。


YandexのウェブサイトAngular.io

Twitterで、Angular.ioチームにを向け、Bingなどの検索エンジンでサイトのインデックスを作成できるようにする予定があるかどうかについて質問しましたが、この資料を書いている時点ではまだ回答がありません。

実際、前述のことから、新しいWebテクノロジーをサイトに導入するために、Bingやその他の検索エンジンを忘れないでください。 ここでは、同形JavaScriptと予備レンダリングの2つのアプローチをお勧めします。

事前レンダリングと同形JavaScript


Googleがクライアントでレンダリングされているサイトのインデックス作成に問題があることに気付いた場合は、事前レンダリングを使用するか、サイトを同形JavaScriptアプリケーションに変換することを検討してください。

どのアプローチが良いですか?



Googleは同形JavaScriptを推奨しています

ただし、ここには1つの問題があります。それは、多くの開発者が同形JavaScriptアプリケーションを正しく作成できないことです。

サーバー側のレンダリングに興味がある場合は、使用しているJSフレームワークのドキュメントを参照してください。 たとえば、Angularの場合、 Angular Universalを適用できます。 Reactを使用している場合は、 ドキュメントを読み、Udemyでこのチュートリアルを参照してください

React 16(11月にリリース)はサーバーレンダリング業界に多くの改善をもたらしました。 これらの改善点の1つはRenderToNodeStream関数で、サーバーレンダリングプロセス全体を簡素化します。

サーバーレンダリングの一般的なアプローチについて説明する場合、重要な推奨事項を1つ挙げます。 サイトをサーバーにレンダリングしたい場合、開発者はDOMに直接影響する関数の使用を避ける必要があるという事実から成ります。

可能な限り、DOMを直接操作する前によく考えてください。 ブラウザのDOMとの対話が必要な場合は、Angular Rendererまたはレンダリング抽象化を使用してください。

GooglebotはHTMLサイトとJSサイトを同じように扱いますか?


Elephateでは、HTMLのみを使用するサイトとJavaScriptベースのサイトをクロールする際に、Googlebotがリンクの検索とリンクのナビゲートをどの程度進めることができるかを調べるための実験を行いました。

この研究は驚くべき結果をもたらしました。 HTMLサイトの場合、Googlebotはすべてのページのインデックスを作成できました。 ただし、JSに基づいてサイトを処理する場合、Googlebotが2番目のレベルに到達することすら非常に一般的でした。 5つの異なるドメインで実験を繰り返しましたが、結果は常に同じでした。


JSベースのHTMLおよびインデックス作成実験

Bartosh GoralevichはGoogleのJohn Mullerに目を向け、問題の原因について質問しました。 ジョンは、GoogleがJavaScriptによって生成されたリンクを見ていることを確認しましたが、「 Googlebotはそれらをクロールしようとしません。 」 彼は次のように付け加えました 。「特にアルゴリズムのURLの値がわからない場合は、すべてのURLをクロールしないか、すべてをすばやくクロールしません。 コンテンツの価値は、テストサイトの曖昧な側面です。」

このトピックを詳しく調べたい場合は、 この資料をご覧になることをお勧めします。

テストサイトのインデックス作成実験の詳細


上記の実験に関する私のアイデアの一部を共有したいと思います。 したがって、調査対象のサイトは実験目的でのみ作成されましたが、同じアプローチを使用してサイトを埋めていることに注意してください。 つまり、それらのテキストは、人工知能技術に基づいた興味深いコンテンツジェネレーターであるArticooloを使用して作成されました。 彼は私の文章よりも間違いなく優れたかなり良いテキストを作成します。

Googlebotは非常によく似た2つのWebサイトを受け取り、そのうちの1つだけをクロールし、JSを使用するサイトよりもHTML Webサイトを優先しました。 これはなぜですか? いくつかの仮定を提示します。


上記のウェブサイトへの多くの高品質の実際のリンクがあります。 多くの人が喜んでインターネット上のリンクを共有しました。 さらに、オーガニックトラフィックを受け取りました。 ここで、テストサイトと実際のサイトをどのように区別するかという疑問が生じます。 これは簡単な作業ではありません。

クライアントでレンダリングされる新しいWebサイトを作成すると、私たちとまったく同じ状況に陥る可能性が高くなります。 この場合、Googlebotは単にクロールしません。 ここから理論が終わり、実際の問題が始まります。 さらに、ここでの主な問題は、Webサイト、オンラインストア、またはクライアント側レンダリングを使用する会社のページが検索結果で高い位置を占める場合、実際の例がないことです。 したがって、JavaScript機能に満ちたサイトが、同等のHTMLと同じくらい高い検索順位を獲得することを保証できません。

ほとんどのSEO専門家はすでにこれを知っていると思われ、大企業はこれらの問題に対処するために特定の資金を向けることができます。 しかし、手段も知識もない中小企業はどうでしょうか? これは、クライアント側の視覚化を使用する小さなファミリーレストランサイトのようなものにとっては本当の危険です。

まとめ


簡潔に要約すると、次のリストの結論と推奨事項を要約しています。


SEO , ( !) Google , JavaScript , , HTML. , , SEO- , JS- , , , . , SEO JavaScript- . - . , , JavaScript, , SEO .

親愛なる読者! , , , JS-?

Source: https://habr.com/ru/post/J351058/


All Articles