この記事
の翻訳の
最初の部分では 、ウェブマスターが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は実際のユーザーではないことを忘れないでください。リンクやボタンを「クリック」したり、フォームに記入したりしないことは当然と考えてください。 この事実は多くの実際的な結果をもたらします:
- オンラインストアがあり、一部のテキストが「詳細...」などのボタンの下に隠れていても、対応するボタンをクリックするまでDOMに存在しない場合、Googleはこれらのテキストを読みません。 メニューに同じように表示されるリンクにも同じことが当てはまります。
- すべてのリンクには
href
パラメーターが含まれている必要があります。 onClick
イベントのみに依存している場合、Googleはそのようなリンクを受け入れません。
これはジョンミュラー
によって確認されています。
上記を確認するジョン・ミュラーのコメントサイト調査にChrome 41を使用したこと
に関する以前の
記事の 1つに、Googleのインデックスシステムの可用性についてメニューを確認するプロセスを示す短いガイドがあります。 この資料をよく理解することをお勧めします。
リンクで#アイコンを使用する
JSフレームワークが
#
記号を使用してURLを作成することは今でも一般的な習慣です。 Googlebotがそのようなリンクを処理しないという本当の危険があります。
以下に例を示します。
- 不正なURL:example.com/#/crisis-center/
- 不正なURL:example.com#URL
- 適切なURL:example.com/crisis-center/
これは、
#!
文字シーケンスの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開発者にどのように影響しますか?
- Googleは、独自のリソースでサイトページを作成します。 これは、開発者がGoogleにそのような技術的能力があることを確認する必要があることを意味します。
- 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.ioBingはこのサイトのコンテンツを見ないようです!
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.ioTwitterで、Angular.ioチームに
目を向け、Bingなどの検索エンジンでサイトのインデックスを作成できるようにする予定があるかどうかについて質問しましたが、この資料を書いている時点ではまだ回答がありません。
実際、前述のことから、新しいWebテクノロジーをサイトに導入するために、Bingやその他の検索エンジンを忘れないでください。 ここでは、同形JavaScriptと予備レンダリングの2つのアプローチをお勧めします。
事前レンダリングと同形JavaScript
Googleがクライアントでレンダリングされているサイトのインデックス作成に問題があることに気付いた場合は、事前レンダリングを使用するか、サイトを同形JavaScriptアプリケーションに変換することを検討してください。
どのアプローチが良いですか?
- 事前レンダリングは、検索エンジンがWebサイトのページを正しく形成できないことに気づき、この操作を自分で実行するときに使用されます。 ロボットがサイトにアクセスするとき、ページのHTMLコピーを与えるだけです(JSコードは含まれません)。 同時に、ユーザーはJS機能を備えたページのバージョンを取得します。 ページのコピーはボットのみが使用し、一般ユーザーは使用しません。 ページを事前にレンダリングするには、外部サービス(prerender.ioなど)を使用するか、サーバー上のユーザーインターフェイスなしでPhantomJSやChromeなどのツールを使用できます。
- 同型JavaScriptも人気のあるハイキングです。 これを使用すると、検索エンジンとユーザーの両方が、最初にページをロードするときに、必要なすべてのデータを取得します。 次に、このプリロードされたデータを処理するJSスクリプトがロードされます。 これは、一般ユーザーと検索エンジンの両方に適しています。 このオプションの使用をお勧めします。Googleでもサポートしています。
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サイトを優先しました。 これはなぜですか? いくつかの仮定を提示します。
- 仮説1 Googleのアルゴリズムは、両方のサイトをテストサイトとして分類し、それらに固定ランタイムを割り当てました。 6ページのインデックス作成や20秒の作業時間(すべてのリソースの読み込みとページの作成)のようなものにできるとしましょう。
- 仮説2 Googlebotは両方のサイトをテストとして分類しました。 JSサイトの場合、彼はリソースのロードに時間がかかりすぎたため、単純にスキャンしなかったことに気付きました。
上記のウェブサイトへの多くの高品質の実際のリンクがあります。 多くの人が喜んでインターネット上のリンクを共有しました。 さらに、オーガニックトラフィックを受け取りました。 ここで、テストサイトと実際のサイトをどのように区別するかという疑問が生じます。 これは簡単な作業ではありません。
クライアントでレンダリングされる新しいWebサイトを作成すると、私たちとまったく同じ状況に陥る可能性が高くなります。 この場合、Googlebotは単にクロールしません。 ここから理論が終わり、実際の問題が始まります。 さらに、ここでの主な問題は、Webサイト、オンラインストア、またはクライアント側レンダリングを使用する会社のページが検索結果で高い位置を占める場合、実際の例がないことです。 したがって、JavaScript機能に満ちたサイトが、同等のHTMLと同じくらい高い検索順位を獲得することを保証できません。
ほとんどのSEO専門家はすでにこれを知っていると思われ、大企業はこれらの問題に対処するために特定の資金を向けることができます。 しかし、手段も知識もない中小企業はどうでしょうか? これは、クライアント側の視覚化を使用する小さなファミリーレストランサイトのようなものにとっては本当の危険です。
まとめ
簡潔に要約すると、次のリストの結論と推奨事項を要約しています。
- GoogleはウェブサイトのレンダリングにChrome 41を使用しています。 このバージョンのChromeは2015年にリリースされたため、最新のJavaScript機能をすべてサポートしているわけではありません。 Chrome 41を使用して、Googleがページを適切に処理できるかどうかを確認できます。 Chrome 41の使用の詳細については、 こちらをご覧ください 。
- 通常、サイトページのソースHTMLコードのみを分析するだけでは不十分です。 代わりに、DOMを見てください。
- Googleは、JavaScriptレンダリングを広範囲に使用する唯一の検索エンジンです。
- Googleキャッシュを使用して、Googleがページのコンテンツをどのようにインデックス付けするかを確認しないでください。 キャッシュを分析することにより、ブラウザがGooglebotが収集したHTMLデータをどのように解釈するかのみを確認できます。 これは、インデックスを作成する前にGoogleがこのデータを処理する方法とは関係ありません。
- 取得ツールとレンダリングツールを定期的に使用します。 ただし、タイムアウトに依存しないでください。 インデックスを作成するとき、まったく異なるタイムアウトが適用される場合があります。
site
コマンドを学習しsite
。- ユーザーがマウスクリックでこのメニューを呼び出す前でも、DOMにメニュー項目が存在することを確認してください。
- Googleのアルゴリズムは、このリソースを処理してページを形成する適切性の観点から、リソースの価値を判断しようとしています。 これらのアルゴリズムによると、リソースに価値がない場合、Googlebotはリソースをダウンロードできません。
- Web開発者は、スクリプトの実行速度を確保するよう努力する必要があります(多くの実験は、Googleがダウンロードフェーズを含むスクリプトの結果を5秒以上待つことはほとんどないことを示しています)。また、スクリプトを最適化してください。原則として、ほとんどのスクリプトは改善および改善できます!
- GoogleがJavaScriptを使用してページを形成できない場合、最初に読み込まれたHTMLのインデックスを作成することがあります。この方法では、Googleは空白のページをインデックスに登録するため、これは単一ページのアプリケーションに非常に悪い影響を与える可能性があります。
- 検索結果で高い地位を占めるクライアントのレンダリングツールを使用するサイトの実際の例はほとんどありません。どうしてそう思いますか?
SEO , ( !) Google , JavaScript , , HTML. , , SEO- , JS- , , , . , SEO JavaScript- . - . , , JavaScript, , SEO .
親愛なる読者! , , , JS-?