2019年3月8日–Googleヘルプハングアウトノート

公開: 2019-03-18

今週、ジョンはページ速度、アンカーテキスト、Javaスクリプトに関するいくつかの素晴らしい質問に答えます。いつものように、完全なビデオとトランスクリプトは以下にあります！

翻訳されたコンテンツはどのように扱われますか？

0:33

そのような組み合わせのウェブサイトがあってもいいと思います。ユーザーにとっては、読みやすいようにするのが理にかなっていると思います。英語を話す人がWebサイトにアクセスした場合、ロシア語、ウクライナ語、英語のコンテンツが混在しているようなものではありません。むしろこれはすべて英語のコンテンツです。異なる言語で提供されているすべてのコンテンツではないかもしれませんが、それで問題ありません。 SEOの観点からは、翻訳を高品質のコンテンツに変えることは理にかなっています。したがって、Google翻訳を使用するだけではありません。翻訳ツールはまだそのためにますます良くなっていますが、それを手で翻訳するか、グーグル翻訳バージョンを取り、それをクリーンアップして読みやすくするなら、それはまだ良いです。これはユーザーが気付くものであり、アルゴリズムの観点からも気付くものです。これが本当に高品質のコンテンツであることがわかった場合は、検索結果でより適切に処理します。

概要：翻訳されたコンテンツがGoogle翻訳で自動翻訳されるだけでなく、他の言語でも読めることを確認してください。また、翻訳が高品質であり、ユーザーにとって価値があることを確認してください。

私のサイトがJavascriptで実行されており、コンテンツのインデックス作成時間が重要である場合、インデックス作成にかかる時間をどのように判断できますか？

3:10

したがって、一般的に、最初の部分は正しいです。静的なHTMLバージョンがある場合は、可能な限り迅速にコンテンツのインデックスを作成しようとします。次のステップは、ブラウザのようにページをレンダリングして、そのコンテンツも選択することです。インデックス作成に使用します。これらの2つを組み合わせると、通常は一緒に機能しますが、静的HTMLバージョンが（人為的に）javascriptバージョンの準備ができるまで遅れるわけではありません。したがって、その観点から、ほとんどのサイトでは、この違いがあることは重要ではなく、ページのレンダリングを開始するのにかかる時間に適用される明示的な時間はありません。それは、ページの種類、見つけたとき、見つけた方法、そのページの周りで何が起こっているかによって異なります。たとえば、これが検索で非常にすばやく表示されるものであると思われる場合は、すぐにレンダリングを試みます。ですから、考慮するのはちょっと難しいです。そこに固定番号はありません。一般に、これを大まかなガイドラインとして使用して、クライアント側のjavascriptコンテンツで何かを行う必要があるかどうかを判断します。たとえば、すばやくインデックスに登録する必要のあるニュースコンテンツがある場合、そのコンテンツを個別にレンダリングしなくても、Googleがそのコンテンツをできるだけ早くピックアップできるようにします。ニュースサイトの場合、特にすべての新しい記事にリンクしているニュースサイトのオーバーページでは、これらのページが検索エンジンに提供される静的HTMLで純粋に機能することを確認します。それは私がそれについて考える方法の一種です。コンテンツがすぐにインデックスに登録されることがどれほど重要であるかを考えてください。所要時間には決まった時間がないため、これにかかる時間ではありません。

概要：JavaScriptサイトの場合、Google Firstはページのインデックスを作成してから、JavaScriptを処理するのに時間がかかります。所要時間については決まった時間はありません。したがって、コンテンツを頻繁に更新する必要がある場合は、静的なHTMLバージョンのページを提供することをお勧めします。

両方がライブサーバーからページを取得する場合、URL検査ツールとモバイルフレンドリーテストの主な違いは何ですか？

9:16

したがって、モバイルフレンドリーテストのアイデアは、このバージョンがモバイルフレンドであるかどうかをテストすることであり、それが主な焦点の一種です。そして、ライブテストツールであるURL検査ツールは、「このページがインデックス作成でどのように機能するか」を確認するためのものです。インデックスなしの応答コードのように、通常のように適用されるものをチェックします。このページをインデックスに入れるかどうか。モバイルフレンドリーテストは、ほとんどがモバイル側に焦点を当てており、URL検査ツールは、さまざまな用途に使用できるさまざまな機能を備えたこの大きなポケットナイフのようなものです。

概要：モバイルフレンドリーテストは、サイトがモバイルでどの程度うまく機能するかを確認することですが、URL検査ツールは、インデックス応答コードがないように、インデックスが正常に機能しているかどうかを確認します。

eコマースサイトで商品ページを分割することを考えています。現在、これらは1つのページで構成可能であり、複数のバリエーションが示されています。あなたの推薦は何ですか？

18:00

私がもっと見る側面は、それらの製品を別々のページに分割することが本当に意味があるかどうかだと思います。なぜなら、あなたが取引しているのは、その製品とすべてのバリエーションに対してかなり強い1つの製品ページであるのに対し、複数のページはある種、自分たちで働き、自分たちでサポートされなければなりません。したがって、「ランニングシューズ」の非常に強力なページを1つ持つ代わりに、「青いランニングシューズ」、「赤いランニングシューズ」、「緑のランニングシューズ」のように、複数のページで戦わなければなりません。したがって、誰かが「ランニングシューズ」を検索している場合、これらの小さなページは、そのメイン製品に対して持っている1つの製品ページほど強力ではありません。ですから、私の一般的なアドバイスは、これらのバリエーションが主な製品の単なる属性であると考える場合、人々は主なコンテンツを検索してから「どの色が欲しいのか、私が製品を見つけたようなものだ」と言う傾向があるということです。欲しいのですが、好きな色を選ぶだけです。」次に、それらを共有ページに配置します。一方、人々がそのバリエーションを明示的に探していて、そのバリエーションが本当にユニークで、ある種それ自体が際立っていて、人々が「ランニングシューズが欲しい」とだけ言ってサイトにアクセスするのではなく、「この特定の種類のランニングが欲しい」と言った場合この色の靴」なら、それは別の製品として引き出す価値があるかもしれません。

要約：製品のバリエーションがそれ自体で際立っていて、人々がその特定のバリエーションを探している場合を除いて、すべてを1つの強力なページにまとめたほうがよいでしょう。そうすれば、製品ページのさまざまなバリエーションが互いに競合することはありません。

あなたのサイトのモバイル版にとって速度は重要ですか？

21:00

ですから、良い点は、ランキング要素がたくさんあることです。したがって、必ずしもすべてを完璧に行う必要はありません。しかし、これはまた、「グーグルはスピードが重要だと言っているが、ここのトップサイトはそれほど速くないので、それは重要ではないはずだ」と言うような状況に遭遇することを意味します。私たちにとってそれは間違いなく重要ですが、それはそれが他のすべてを上書きするという意味ではありません。あなたが考えることができる最速のページはおそらく空のページであると想像することができます。しかし、本当に特定の何かを検索している場合、空のページは本当にひどい検索結果になります。本当に速いですが、そこにはコンテンツがないので、ユーザーは満足しません。したがって、これらすべての要素、コンテンツ、リンク、およびこれらすべてのシグナルのバランスを取り、さまざまな要素のこの組み合わせに基づいてランキングを行う方法を見つけ出す必要があります。また、時間の経過とともに変更が加えられ、かなり迅速に変更される可能性があります。たとえば、現時点で本当に報道価値のあるものがある場合は、少し異なるサイトに、より研究的で常緑のトピックであるものを表示することを選択できます。

概要：速度は、Googleが使用するランキング要素の1つにすぎません。トップサイトが速くないかもしれないからといって、それがあなたのサイトにとって重要ではないという意味ではありません。

JSONまたはマイクロデータのmicr形式を使用する場合、Googleにはどのタイプのスキーママークアップが適していますか。どちらが望ましいですか？

22:30

現在、JSON-LDマークアップを使用しています。新しいタイプの構造化データのほとんどは、最初にJSON-LDに対応するため、私たちが好むのはそれだと思います。

概要： JSON-LDはGoogleによって推奨されています。

アンカーテキストはどのくらい重要ですか？

25:10

ですから、まず第一に、私はグーグルの特許についてあまり心配しないと思います。私たちはウェブマスターがする必要があることに必ずしも当てはまらない多くのことを特許します。ですから、エンジニアが取り組んでいるのは面白いと思いますが、それは必ずしもすぐに影響を受けるという意味ではありません。一般的なアンカーテキストに関しては、テキストに使用します。それは私たちが拾うものです。これは、リンクに関するコンテキストを提供するための優れた方法です。特にあなたのウェブサイト内で、「詳細についてはここをクリックしてください」というリンクがある場合、それは私たちにとってあまり役に立ちません。「この製品ページで詳細情報を見つけることができます」というリンクがあり、その製品の名前でそのページにリンクしているのに対し、このページは本当にこの製品に関するものである可能性があります。ですから、私は確かにあなたが使用しているアンカーテキストを、特にあなたのウェブサイトの内部で調べ続け、本当に有用でページにリンクされているものへのコンテキストを提供するアンカーテキストを提供していることを確認しようとします。

概要：アンカーテキストは、ページの内容に関するコンテキストをGoogleに提供するため、非常に重要です。「詳細についてはここをクリック」のようなアンカーテキストはGoogleに多くの情報を提供しませんが、「この製品ページに関する詳細情報を見つけることができます」のようなアンカーテキストは、このページがこの製品ページに関するものであることをGoogleに伝えます。

注：独自のリンクを作成している場合、キーワードリンクが多すぎると、手動で確認した場合にWebスパムチームに影響を与える可能性があります。

Googleはあなたのページをどのように視覚的に認識しますか？

39:00

私たちはページを視覚的に見ようとしますが、主に、折り目の上の実際のコンテンツであるか、折り目の上のスペースであるかは、1つの巨大な広告です。これは私たちが焦点を当てていることの一種であり、ページを視覚的にマッピングして表示しようとするモバイルの使いやすさに関しても、これはモバイルデバイスでうまく機能するページです。そのためには、ページをマップする必要があります。モバイルデバイスで機能する限り、一部の要素が読み取れなくても問題ありません。それらのリンクがそこにある場合、それらは適切なサイズであり、人々はそれらをクリックすることができます、そしてそれは完全に問題ありません。これを3Dテキストに変換するためにいくつかの凝ったcss変換を行っている場合、それは完全にあなた次第です。重要な部分は、テキスト自体がページに表示され、そのテキストを分割するためにあまり凝ったマークアップを行っていないことです。したがって、例として、テーブルベースのレイアウトがあり、ヒーリングを上に分割したい古いシステムの見出しがある場合、人々は個々の文字を個々のテーブルセルに入れ、私たちの観点からはマークアップを使用して切断されたチャンクに分割しているため、これが実際に1つの単語であることを確認することはほとんど不可能です。ページの観点からの解析からすると、これは非常に注意が必要です。

概要： Googleは主に、巨大な広告だけでなく、実際のコンテンツがスクロールしなければ見えない位置にあるかどうかを確認しようとします。モバイルフレンドリーの観点から、Googleは同じリンクが存在するかどうか、すべてが適切なサイズであるかどうか、そして人々がそれらのリンクをクリックできるかどうかを理解しようとします。最も重要なのは、テキスト自体がページに表示されているかどうかです。

URLをJavascriptと交換できますか？

43:00

はい、それを拾うことができます。私が思う重要な部分は、ページがロードされた後にURLをスワップアウトする必要があるということです。ユーザーが特定のアクションを実行するときにスワップアウトしないでください。たとえば、ユーザーがリンクにカーソルを合わせた後、JavaScriptを使用してURLをスワップアウトした場合、またはユーザーがリンクをクリックした後、JavaScriptを使用してURLをスワップアウトした場合、また、私たちが気付くようなものではないでしょう。しかし、ページが読み込まれた後、URLをクリーンアップするJavaScriptを実行して、適切な正規バージョンにリンクする場合は、レンダリングに関して最初に説明したように、これには少し時間がかかります。時間。したがって、すぐに取得することはできません。または、元のリンクとJavaScriptバージョンの両方を取得する可能性があります。したがって、古いバージョンが完全に削除されるわけではありません。

概要：ページが読み込まれた後にURLがスワップアウトされた場合、Googleはピックアップできます。注意すべき唯一のことは、ユーザーが特定のアクションを実行するときにURLがスワップアウトされないようにすることです。

このようなものが好きなら、私のニュースレターを気に入るはずです！

私のチームと私は毎週、最新のGoogleアルゴリズムの更新、ニュース、SEOのヒントについて報告しています。

成功！！次に、メールをチェックして、GoogleUpdateニュースレターの購読を確認します。

質問0:33-翻訳に関する質問。私が英語のコンテンツをロシア語またはウクライナ語に翻訳する場合、ほとんどの人はGoogle翻訳のみを使用し、コンテンツを入力するだけであることを知っています。しかし、母国語話者として読んだ場合、その90％は修正が必要なようです。私は2つの点に興味があります。英語、ロシア語、ウクライナ語など、他のバージョンや他の言語を自分のWebサイトに作成したい場合は、これで問題ありませんか？第二に、私のニッチについての興味深い記事を見つけて、それを翻訳したいのですが、これは良いですか？国内の読者に適応させる必要がありますか？

回答1:38-このような組み合わせのWebサイトがあるのは問題ないと思います。ユーザーにとっては、読みやすいようにするのが理にかなっていると思います。英語を話す人がWebサイトにアクセスした場合、ロシア語、ウクライナ語、英語のコンテンツが混在しているようなものではありません。むしろこれはすべて英語のコンテンツです。異なる言語で提供されているすべてのコンテンツではないかもしれませんが、それで問題ありません。 SEOの観点からは、翻訳を高品質のコンテンツに変えることは理にかなっています。したがって、Google翻訳を使用するだけではありません。翻訳ツールはまだそのためにますます良くなっていますが、それを手で翻訳するか、グーグル翻訳バージョンを取り、それをクリーンアップして読みやすくするなら、それはまだ良いです。これはユーザーが気付くものであり、アルゴリズムの観点からも気付くものです。これが本当に高品質のコンテンツであることがわかった場合は、検索結果でより適切に処理します。

質問3:10-Googleは2つのステップでコンテンツをクロールしてインデックスを作成します。 1つ目はサーバー側のレンダリングで、2つ目はクライアント側のレンダリングです。前のステートメントによると、このプロセスが完了するまでに数日または数週間かかる場合があります。 Javascriptを使用しているサイトでは、インデックス作成がタイムクリティカルである場合、深刻な問題が発生する可能性があります。どれくらいの時間がかかるかをどうやって見分けることができますか？

回答3:46-したがって、一般的に、最初の部分は正しいです。静的なHTMLバージョンがある場合は、可能な限り迅速にコンテンツのインデックスを作成しようとします。次のステップは、ブラウザのようにページをレンダリングして、そのコンテンツも選択することです。インデックス作成に使用します。これらの2つを組み合わせると、通常は一緒に機能しますが、静的HTMLバージョンが（人為的に）javascriptバージョンの準備ができるまで遅れるわけではありません。したがって、その観点から、ほとんどのサイトでは、この違いがあることは重要ではなく、ページのレンダリングを開始するのにかかる時間に適用される明示的な時間はありません。それは、ページの種類、見つけたとき、見つけた方法、そのページの周りで何が起こっているかによって異なります。たとえば、これが検索で非常にすばやく表示されるものであると思われる場合は、すぐにレンダリングを試みます。ですから、考慮するのはちょっと難しいです。そこに固定番号はありません。一般に、これを大まかなガイドラインとして使用して、クライアント側のjavascriptコンテンツで何かを行う必要があるかどうかを判断します。たとえば、すばやくインデックスに登録する必要のあるニュースコンテンツがある場合、そのコンテンツを個別にレンダリングしなくても、Googleがそのコンテンツをできるだけ早くピックアップできるようにします。ニュースサイトの場合、特にすべての新しい記事にリンクしているニュースサイトのオーバーページでは、これらのページが検索エンジンに提供される静的HTMLで純粋に機能することを確認します。それは私がそれについて考える方法の一種です。コンテンツがすぐにインデックスに登録されることがどれほど重要であるかを考えてください。所要時間には決まった時間がないため、これにかかる時間ではありません。

質問6:17-そして今、検索コンソールでのフラグの種類を理解することについての巨大な長い質問があります。「重複したGoogleはユーザーとは異なる正規を選択します」または「重複した送信されたURLで、正規の問題として選択されていません」。

【ユーザーチャイムイン】Javascriptページです。事前にレンダリングされており、すべてのコンテンツは静的HTMLに含まれていますが、Googleはまだページを実行しようとしています。そして、このeコマース環境では、独自の説明と意味のあるコンテンツを備えたこれらの独自の製品ページが、重複コンテンツとしてGoogleとしてフラグ付けされていることがわかりました。これは、ある種のJavaScriptレンダリングの失敗によるものと想定されます。この場合、Googlebotは同じエラーページなどを表示し続けるため、それらは重複していると見なされます。Webレンダリングサービスが最終的にコンテンツがGoogleボットと重複しているように見える可能性があります。

回答7:43-実際の例をいくつか見なければならないので、本当に役立つ例を送っていただければと思います。

質問8:00-Googleは進行中の問題を認識していますか？

回答8:00-いいえ…これについて他のサイトよりも不満を言っているサイトから聞いたことがあります。そのため、役立つ例をいくつか送信してください。

質問8:24-URLにフラグが付けられている場合、その分析時に発生したレンダリングについて何かを確認する方法はありますか。インデックスが作成されたもので発生したリソース読み込みエラーを確認する方法はありますか？検索コンソールにそのUIがないか、少なくとも私はそれにアクセスできません。また、インデクサーや重複検出ファインダーがコンテンツを確認したときに、コンテンツが実際にどのように表示されるかを確認できる場所はありますか。

回答8:41-現時点ではありません。それは非常に理にかなっていることです。ほとんどのサイトでは、それは重要ではありません。しかし、このような場合には、それがあれば便利です。

質問9.16-次の質問。モバイルフレンドリーテスト。インデクサーがコンテンツをどのように見るかを理解するという観点から、これを数回参照しました。ただし、リソースの読み込みでラベル付けされた他のエラーが多数あり、それらのエラーが発生する速度はドメインごとに異なるようです。では、最初の質問ですが、モバイルフレンドリーテストで見られるエラーは、インデックス作成中にサービスで発生するエラーを表していますか？または、MFテストに異なるリソース割り当てがありますか？

回答10:04-では、テストのために引き込まれた組み込みリソースについて具体的に言及していると思いますか？ JSファイルのようにCSSの異なる応答はそのようなものですか？モバイルフレンドリーテストの優先順位が通常のGoogleボットとは異なるという意味で、現時点では少し複雑な側面の1つだと思います。ライブサーバーからできるだけ早くリソースを取得しようとします。インデックス作成中に、多くのリソースをキャッシュし、キャッシュされたバージョンのページを取得します。したがって、モバイルフレンドリーテストで表示されるのは、このページをできるだけ早くレンダリングしようとし、これらのリソースを大量に取得できることですが、一部のリソースでは、基本的に、このライブをプルする機能でタイムアウトになります。サーバー。これは、モバイルフレンドリーテストで見られるエラーの大部分です。また、ライブテストを使用する場合、URLの検査ツールでは、すべてをライブでプルしようとしていると思いますが、ライブで実行できない場合もあります。そして、インデックス作成のために、私たちはそれのために利用できるより多くの、少し長い時間を持っています。したがって、これらのリソースが必要であることがわかった場合は、それらをプルし、キャッシュし、レンダリングを実行するときに使用できるようにします。つまり、これはIoTライブを行う必要がないことです。そのため、それを行うのに少し時間がかかる場合は、辛抱強く、すべてがまとまるのを待ちます。これらのリソースはすべてキャッシュできないため（たとえば、セッションIDやすべてのJS URL）、キャッシュされたバージョンを保持することが実際に可能になるというタイムアウトの側面がまだあります。後で再利用すると、何らかの理由でインデックス作成のためにフェッチできない可能性があります。つまり、特に組み込みリソースがたくさんある場合は、このような問題を診断するのは難しいと思います。私がエンジニアリングチームから一般的に得ているガイドラインは、埋め込まれたリソースが少ないことを人々に伝えるべきであり、彼らはこの問題に遭遇しない傾向があるということです。それは必ずしも簡単ではないので、一般的に私が行うことは大まかなガイドとしてモバイルフレンドリーテストを行うことです。したがって、それがMTFで機能する場合は、間違いなく安全です。この他のエラーでタイムアウトする他の問題が発生した場合でも、ほとんどの場合、それをインデックス作成に使用できます。

質問12:57-接線方向に、Webレンダリングサービスによるレンダリングのハードまたは任意のタイムアウトに注意する必要があると思います。レンダリングサービスでGooglebotがページをレンダリングするのに長い時間がかかる場合、実際にどのコンテンツが使用されるかについて明確になっていますか。元々そこにあったページのhtmlコンテンツをあきらめて使用するだけですか？最終的にレンダリングプロセスのどこまで進むことができるかについて明確にしていますか？

回答13:45-ほとんどの場合、何かが壊れたりタイムアウトしたりした場合は、その場でスナップショットを撮ります。そうですね…あなたの場合、コンテンツを事前にレンダリングしているのであれば、コンテンツがそこにあるので問題はないはずです。 eコマースサイトや非常にテンプレート化されたフレームワークを使用しているサイトで時々見られるのは、実際にURLをテストする前に重複コンテンツがあると想定する状況に遭遇することです。したがって、これは、たとえばURLパターンが表示された場合に発生する可能性があります。たとえば、さまざまなパターンやさまざまなパラメータを持つ一連のURLにアクセスし、これらのURLがすべて同じコンテンツにつながることがわかった場合、システムは「このパラメータは、その後のWebサイトにはあまり関係ありません。「すべて」とすると、これらのURLを削除する傾向があり、「このURLのセットは、すでにクロールした他のURLのセットとおそらく同じです。したがって、特にどこかで見ることができるものがある場合、私がかなり見た1つの例は、非常に多くの異なるeコマースWebサイトがあり、それらがすべて同じ製品を販売している場合です。多数のドメインでURLが同じである場合、システムは「これらのURLはすべて同じであり、すべて同じ製品につながる」と表示するため、すべてではなく、これらのドメインの1つにインデックスを付けることをお勧めします。これらのドメインの。これがあなたの場合に当てはまるかどうかわからないので、それが役立つかどうかはわかりませんが、それは私たちのシステムがWebで見つけたものに合わせて最適化しようとするもののひとつであり、他の人がウェブ上でも間違いを犯し、それを回避しようとしています。「これらの人々はすべて重複を作成していますが、これらの重複をすべてクロールする必要はありません」と表示されるため、実際のURLと思われるものに焦点を当てることができます。

質問16:22-URL検査ツールでのモバイルフレンドリーテストとライブテストをピックアップします。モバイルフレンドリーテストでは、Googlebotはライブサーバーからページを取得しようとしますが、この機能を備えたURL検査ツールとはどのように異なりますか？賢明なレンダリングやページとリソースの取得はどのように異なりますか

回答17:04-つまり、モバイルフレンドリーテストのアイデアは、このバージョンがモバイルフレンドであるかどうかをテストすることであり、それが主な焦点の一種です。そして、ライブテストツールであるURL検査ツールは、「このページがインデックス作成でどのように機能するか」を確認するためのものです。インデックスなしの応答コードのように、通常のように適用されるものをチェックします。このページをインデックスに入れるかどうか。モバイルフレンドリーテストは主にモバイル側に焦点を当てており、URL検査ツールは、さまざまな用途に使用できるさまざまな機能を備えたこの大きなポケットナイフのようなものです。

質問18:00-クライアントのeコマースサイトの1つで、一部の製品は構成可能として販売されています。つまり、製品の複数の異なるバリエーションが同じページに表示および管理されます。これらのページを分割して、それぞれが新しいURLを持つ独自の製品ページを持つようにすることを検討しています。その後、クライアントのレビューは古いページから新しい単純なページに移動されます。古いレビューの日付が新しい作成日よりも古いという事実は、ブラックハットSEOとしてマークできますか？

回答18:37-したがって、これらの製品ページに新しいレビューを追加し続けることができる限り、レビューに問題はまったくありません。私がもっと見る側面は、それらの製品を別々のページに分割することが本当に意味があるかどうかだと思います。なぜなら、あなたが取引しているのは、その製品とすべてのバリエーションに対してかなり強い1つの製品ページであるのに対し、複数のページはある種、自分たちで働き、自分たちでサポートされなければなりません。したがって、「ランニングシューズ」の非常に強力なページを1つ持つ代わりに、「青いランニングシューズ」、「赤いランニングシューズ」、「緑のランニングシューズ」のように、複数のページで戦わなければなりません。したがって、誰かが「ランニングシューズ」を検索している場合、これらの小さなページは、そのメイン製品に対して持っている1つの製品ページほど強力ではありません。ですから、私の一般的なアドバイスは、これらのバリエーションが主な製品の単なる属性であると考える場合、人々は主なコンテンツを検索してから「どの色が欲しいのか、私が製品を見つけたようなものだ」と言う傾向があるということです。欲しいのですが、好きな色を選ぶだけです。」次に、それらを共有ページに配置します。一方、人々がそのバリエーションを明示的に探していて、そのバリエーションが本当にユニークで、ある種それ自体が際立っていて、人々が「ランニングシューズが欲しい」とだけ言ってサイトにアクセスするのではなく、「この特定の種類のランニングが欲しい」と言った場合この色の靴」なら、それは別の製品として引き出す価値があるかもしれません。だから、それは私がおそらく心配するであろう区別です-私はレビューの部分についてはそれほど心配しません。

質問20:36新しい検索コンソールのマークアップスキーマ機能は、古いものと同じままですか？

回答20:50構造化データ機能に関する新しい検索コンソールの正確な計画はわかりませんが、これらすべての構造化データ機能をサポートする予定です。したがって、これらの機能は検索コンソールでわずかに異なる方法で終了する可能性があります。

質問21:00モバイル版の速度はどうですか。グリーンゾーンで速度を上げることが重要ですか。そうであれば、トップサイトの多くがまだそれほど遅いのはなぜですか。

回答21:20：良い点は、ランキング要素がたくさんあることです。したがって、必ずしもすべてを完璧に行う必要はありません。しかし、これはまた、「グーグルはスピードが重要だと言っているが、ここのトップサイトはそれほど速くないので、それは重要ではないはずだ」と言うような状況に遭遇することを意味します。私たちにとってそれは間違いなく重要ですが、それはそれが他のすべてを上書きするという意味ではありません。あなたが考えることができる最速のページはおそらく空のページであると想像することができます。しかし、本当に特定の何かを検索している場合、空のページは本当にひどい検索結果になります。本当に速いですが、そこにはコンテンツがないので、ユーザーは満足しません。したがって、これらすべての要素、コンテンツ、リンク、およびこれらすべてのシグナルのバランスを取り、さまざまな要素のこの組み合わせに基づいてランキングを行う方法を見つけ出す必要があります。また、時間の経過とともに変更が加えられ、かなり迅速に変更される可能性があります。たとえば、現時点で本当に報道価値のあるものがある場合は、少し異なるサイトに、より研究的で常緑のトピックであるものを表示することを選択できます。

質問22:30JSONまたはマイクロデータのmicr形式を使用する場合、Googleにはどのタイプのスキーママークアップが適していますか。どちらが望ましいですか？

Answer 22:48現在、JSON-LDマークアップを使用しています。新しいタイプの構造化データのほとんどは、最初にJSON-LDに対応するため、私たちが好むのはそれだと思います。

質問23:00Googleは2月または3月に大規模な更新を行いましたか？

回答：23：15わかりません。つまり、常に更新を行っています。何が重いと思うかわかりません。それはおそらくあなたのウェブサイトに依存します。あなたのウェブサイトがこれらのアップデートの1つによって強く影響を受けたなら、あなたはおそらくそれがかなり重いと思うでしょう。ウェブ全体を見ると、いつものように通常の変化のように見えるかもしれません。

質問23:24。アフィリエイトウェブサイトにとってシンコンテンツとはどういう意味ですか？

回答23:34薄いコンテンツは、他のWebサイトと比較してアフィリエイトサイトにとって何の違いも意味しません。私たちが見てきたこと、特にアフィリエイトWebサイトでは、非常に簡単に実行できるため、フィードからコンテンツを取得する傾向があります。スクリプトを使用すると、これをかなり迅速に実行できます。実行は簡単です。多くの作業を行うために2つ必要はなく、多くのURLが作成されます。しかしもちろん、ユーザーにとっても私たちにとっても、他の人と同じものを提供しているので、それほど面白くはありません。

質問24:40タブ内の非表示のコンテンツは、インデックス作成に問題がありますか？

回答24:50一般に、インデックス作成の問題ではありません。これはユーザーにとって問題になる可能性があるため、ユーザーが変換するために本当に見る必要があると思われるコンテンツがそこにある場合、それはあなたの観点からは一種の問題になります。インデックス作成に関しては、そのコンテンツを取得して表示できるので、それほど問題にはなりません。

質問25:10アンカーテキストは2019年でも重要なランキング要素ですか？多くの企業が、相関関係がないと指摘する研究を行っています。そして、Googleの特許へのリンクがあります。

回答25:30ですから、まず第一に、Googleの特許についてはあまり心配しないと思います。私たちは、ウェブマスターが行う必要のあることに必ずしも当てはまらない多くの特許を取得しています。ですから、エンジニアが取り組んでいるのは面白いと思いますが、それは必ずしもすぐに影響を受けるという意味ではありません。一般的なアンカーテキストに関しては、テキストに使用します。それは私たちが拾うものです。これは、リンクに関するコンテキストを提供するための優れた方法です。特にあなたのウェブサイト内で、「詳細についてはここをクリックしてください」というリンクがある場合、それは私たちにとってあまり役に立ちません。「この製品ページで詳細情報を見つけることができます」というリンクがあり、その製品の名前でそのページにリンクしているのに対し、このページは本当にこの製品に関するものである可能性があります。ですから、私は確かにあなたが使用しているアンカーテキストを、特にあなたのウェブサイトの内部で調べ続け、本当に有用でページにリンクされているものへのコンテキストを提供するアンカーテキストを提供していることを確認しようとします。

質問27:00DMCAプロセスの仕組みを教えてください。

回答27:01それについての詳細がわからないため、それがどのように機能するかを説明することはできません。また、これは法的な手続きであり、法的なアドバイスを提供することはできません。

Question 27:30 How does a content platform like medium get its status as content provider? When I check the transparency report for medium the status is, check a specific URL, it's hard to provide a specific status for a site like medium that has a lot of content. We're also a content provider, hosting supermarket catalogs and other PDF publications online, generated by users. So I guess the questions is how do we get that status?

More context from the person who asked the question. Basically the problem we're trying to solve is, our platform allows adding outgoing links in the catalogue and if one specific Url is flagged for going to a bad site, our entire domain is at risk and we have been blacklisted before. Basically it fits the bill because we have a large number of content and all of that is user generated, so how does one go about being in this standing?

Answer 28:48 Um, I don't know. Is it mostly in regards to the transparency report with regards to phishing or maybe malware? It sounded like originally you just want the status that's provided in the transparency report but with regards to link and the content that's provided that sounds more like it's towards phishing or spam?

We're trying to solve for the issue where the domain is blacklisted for phishing and spam. Under the hood we are solving that problem but the generic solution seems to be something like this because even if individual long-tail domains are blacklisted for a period of time our main commercial domain is sage, is that even a good assumption?

Answer 29:50 I don't know how to best attack that. So I think from my point of view, there's one thing that you could do. I don't know your website so its hard for me to say already. Make it so it's easier for us to understand which parts of our website belong together. So for example, if you have different subdomains per user then its easy for us to say, well this problem is isolated on this specific subdomain or subdirectory and then our algorithms can then focus on that on a subdomain level. Where as if all the content is within the main domain and the URL structure is a slash and then a number then its really have for our algorithms to say everything that matches this pattern is maybe phishing or spam that wasn't caught in time. The easier you can make it for us for figure out which parts belong together, which could be by user, or could be by type of content depending on how you group the content then the easier it is for us to kind of match an action that applies just to this part of the website.

Question Continued 31:33 There is no process that your aware of that you can apply or get the status of content provider? And does it actually link to having decreased risk for whole domain blacklisting?

Answer 31:46 I don't think the two side are connected, so I think that content provider status in the transparency report is something that's specific to the transparency report and wouldn't apply to the spam handling. We do have some fold here who are working on something specific for hostess or CMS providers, which I think is kind of what you fall into here. To try to give them more information on where we see spam and to better understand the grouping of content in regards to individual websites.

Question 37:00 Is it necessary to Hreflang links to paginated pages beyond page one?

Answer 37:18 So it's never necessary to add Hreflang links, that's kind of the first thing there. It's not like you will be penalized for having those links on all pages across your website, those links do help us better understand which pages belong together. HReflang links work on a per page basis so if links work well between the homepage version of your site and not between the product pages on your website that's perfectly fine. Use them for the URLs that you think need to have that connection for the language and country versions, you don't need to do that for everything. The other thing, sometimes doing Hreflang links properly is really complicated, especially if your mixing things like pagination and maybe filtering then that feels like something where you're adding so much complexity that it's unlikely you will end up with a useful result and I would just drop the hreflang links so that you don't have extra noise in search console. That's kind of the pragmatic approach that I would take there. Use Hreflang where you see that you have problems and if you don't have any problems in regards to localization then don't worry about the hreflang part.

Question 39:00 Does Google determine a page is low quality by taking into account what the pages looks like visually? I have a site that has elements that get 3D rotated when a user taps on them, when I look at this page as Googlebot, it see's these elements with the ext backwards and looks weird. Is that a problem or not?

Answer 39:20 From my point of view, that's no problem. We do try to look at the page visually but mostly with regards to, is the actual content above the fold or is the above the fold space just one giant ad. That's kind of what we focus on, also with regards to mobile friendliness we try to visual map a page and see, is this a page that would work well on a mobile device. And for that we kind of have to map out the page, its ok if some elements are unreadable as long as they work on a mobile device. If those links are there, they're the right size and people can click on them, then that's perfectly fine. If you're doing some fancy css transformation to turn this into 3d text, that's totally up to you. The important part is that the text itself is visible on the page and that you're not doing too much fancy markup to split that text up. So as an example if you have a headline in the old system where you have a table based layout and you wanted to split the healing on top, I've seem people put individual letters into individual table cells and from our point of view that makes it pretty much impossible to see that this is actually one word because you're using markup to split it up into disconnected chunks. From a parsing the page point of view that's really tricky.

Question 41:26 - I've heard that changing a title tag for page will drop in ranking temporarily is that true what if I have a number that has just changed on the page title?

Answer 41:47 - So it's not true that changing a title will automatically drop a page in ranking I don't think that would make sense. However if you change a title and you put new keywords in there then we obviously need to figure out like how we should rank that page based on that title. Where the title is is one of the things that we do look at. We do look at a lot of other things on a page as well a lot of other signals that are involved with ranking so just changing a title on its own should have a big effect over all but if you're adding something new there that wasn't there before and you want to rank for that new piece of thing there then obviously that does take a little bit of time. So if you're just changing numbers in the title then if people were searching for those old numbers or those new numbers that might be an effect that you would see. In practice people are not going to search for like number three or number five and expect your page to show up. I mean maybe there are exceptions but for the most part that's not going to be something that would affect your your pages ranking. So if you're changing numbers in a title over time I think that's perfectly fine if users are okay with that if that works for everyone.

Question 43:00 - Can Google crawl hyperlinks that we've swapped out the URL with JavaScript we do this as a workaround with our client due to CMS limitations.

Answer 43:08 - Yes we can pick that up. The important part I think is that the URL needs to be swapped out after the page is loaded. It shouldn't be swapped out when a user does a specific action. So for example if a user hovers over a link and then you use JavaScript to swap out the URL that wouldn't be something that we would notice or if a user clicks on a link and then you use JavaScript to swap out the URL then that also wouldn't be something that we would notice. But if the page loads and then you execute some JavaScript that cleans up the URL so that they link to the proper canonical versions that's perfectly fine and kind of like like we talked about in the beginning when it comes to rendering sometimes this takes a bit of time. So it's not an immediate thing that we would pick up we might or it's likely that we would pick up both of these versions both the original link that you had there as well as the JavaScript version. So it wouldn't be that the old versions would drop out completely.

Question 44:20 - Does Google understand related topics for example if I create a page about pets but I don't mention cats and dogs will that make it harder for Google to rank me?

Answer 44:35 - No I don't think that would be problematic. So it would of course make it harder to rank this page if someone searches for cats or dogs but you can create a page about pets that doesn't include all of those different types and I think that's that's pretty normal. Like there's a lot of variation of content out there and some content focuses more on on this side of the topic and some focuses more on a different part of the topic that's completely normal.

Question 45:09 - How does Google understand the quotes page given that they're technically duplicate content. Can Google tell that these are quotes pages and lots of content is also on other websites is that a bad thing or not? How does Google know?

Answer 45:30 - We do recognize when there are kind of parts of a page that are shared across other pages. So a really common situation is you have a footer on your web page that you share across a lot of pages. We can tell that this this part of text is the same as you have across other parts of your website. So what generally happens there is if someone searches for something that's in the shared piece of content we'll will try to pick the most matching page for that. If someone searches for something that's a combination of that content and something else on a page that will try to pull that best matching page. So that's the same as what would happen with these quotes pages and that if someone searches for a specific quote that you have on this page then we'll try to pick one of the many quotes pages that we have that has the same quote on it. It might be yours it might be like hundred other people, a lot of people have these quotes, and we'lll try to show that one in the search results. It's not that we would see this page as being lower quality it's just that you're competing with a lot of other sites that have the exact same quotes on it so if there is something unique that you're providing on these pages then I would make sure that that is also very visible there. So that it's easy for us to tell that well pages about this quote but also has a lot of information about other I don't know, Russian quotes or other German quotes, and we can tell this user is used to searching in Russian or German so we'll bring them to your site rather than to a generic site that has just all kinds of quotes. So the more you can bring unique value into those kind of pages more likely we'll be able to show that in the search results. But it's not necessarily something that you have to hide, we recognize these quotes we we understand that as sometimes are shared across lots of websites that's completely normal.

Question 47:40 - Suppose I started a blog the most following methodology is connecting your site map to the webmaster site from day one but what if I write 50 posts and then add a sitemap file is there any difference

回答47:54-これらの方法は両方とも機能します。したがって、サイトマップファイルは、Webサイトの新しいページと変更ページをよりよく理解するのに役立ちます。これはランキング要素ではないため、サイトマップファイルがあるからといって上位にランク付けされることはありません。これは、これらのページのどれがWebサイトで利用可能かを理解するのに役立ちますが、ほとんどの場合、特に小規模なサイトでは、通常どおりクロールできます。同様に、サイトを正常にクロールできるか、サイトマップファイルを使用してクロールするかによって、検索でのサイトの表示方法に大きな違いはありません。したがって、サイトマップファイルは、サイト内で少し低いコンテンツを変更する場合、大規模なサイトでは絶対に重要ではありません。明らかに、サイトマップファイルは、それらの変更をはるかに迅速に見つけるのに役立ちますが、始めたばかりの場合は必ずしもサイトマップファイルを持っている必要はないブログ。

質問48:50-ギリシャのホテルをウェブサイトで再販しています。ホテル向けのフレンドリーなセクションを開発しましたが、ホテルのYouTube動画を埋め込むため、ホテルのコンテンツとタイトルも複製しています。それは私たちにとって有害ですか？

回答49:10-そうですね、この種のことは、重複コンテンツに関して私たちが持っていた他の質問に戻ると思います。多くの異なるWebサイトで同じものを提供しているだけの場合は、Webサイトに独自の何かがあることを確認することに本当に集中する必要がある重複コンテンツでは、これをうまく言うのは非常に困難です。実際には、検索結果を表示するために必要なWebサイトです。ですから、他のすべてのWebサイトと同じものではなく、自分のサイトが本当にユニークで説得力のあるものであることを確認するために、一歩下がって何ができるかを考えることをお勧めします。

質問50:00-ストーリーが薄いコンテンツであり、何年も前のものであるためにリダイレクトされた場合、記事の悪影響はリダイレクトによって転送されますか？

回答50:12-必ずしもそうとは限りません。したがって、特にコンテンツに関しては、私たちが到達した最終的なページで見つけたコンテンツを調べます。したがって、コンテンツを削除した場合、何かをクリーンアップした場合、それは自動的に行われると思います。そのページをリダイレクトし、古いコンテンツが存在せず、新しいコンテンツしかない場合は、まったく問題ありません。だから、それはある種続けられるようなものではないでしょう。

質問50:45-モバイル対応バージョンのページをリンク関連の代替行為に関連付けたときに、検索コンソールがモバイル対応エラーがページのテスト破壊にあると報告するのは自然なことですか

回答50:57-つまり、通常、これらのページのどれが一緒に属しているかを明確に理解していないことを意味します。したがって、何らかの理由で、このデスクトップページがこのモバイルページに属していることがわかっているペアとしてではなく、これらのページに個別にインデックスを付けていました。そのため、代替リンクまたは関連する正規リンクをそこに設定した方法との不一致が発生する可能性があります。だから私もそれを調べますそしてもちろん他のことはレスポンシブデザインに移行するために何が必要かについても調べますURLは、すべてを不必要に複雑にするだけです。一方、レスポンシブデザイン、またはデスクトップバージョンとモバイルバージョンで同じURLを使用するだけのデザインに移行できる場合。あなたが自分自身を救うよりも多くの問題を抱えているので、この種の問題をフォローアップする代わりに、時間をかけて言うのではなく、レスポンシブデザインに移行する計画に投資して、これらに集中する必要がないようにする必要があります将来的にはもう発行されません。

質問1：01：01-他の外部リンクのようなウィキペディアリンクとグーグルヘルプ記事にnofollowを追加するのは良い考えですか？また、優れたデータハイライターが検索で有効になるまでにどのくらいの時間がかかりますか？

回答1:01：16-さて、ウィキペディアのリンクにnofollowを追加します。ウィキペディアがそれらのリンクを配置するためにあなたにお金を払っていない限り、それはあまり意味がないと思います。したがって、IIは、Webサイトに関連付けたくないリンクにnofollowを追加します。しかし、そうでなければ、それがコンテンツ内の通常のリンクであり、私は通常どおりに見えるので、ウィキペディアがそれらのリンクに対してあなたにお金を払っていない限り、私は通常私が推測するだろうと思います。また、データハイライターの場合、Webサイトのインデックスページから学習したキャッシュページに基づいており、明らかにデータを実行するマークアップに基づいているという点で、少し時間がかかる可能性のあるアルゴリズムプロセスがあります。蛍光ペンを使用すると、それを取得して新しいページに適用し、Webサイト全体で再クロールしてインデックスを再作成します。そのため、ウェブサイトでコンテンツを再クロールしてインデックスを再作成するときに、コンテンツに適用されるまでに時間がかかります。そのため、多くのページでかなり速い場合もあれば、表示されるまでに数か月かかる場合もある、決まったタイムラインがない場合もあります。そのため、ボタンを押す瞬間はありません。手動でページに追加する他の構造化データと同様に、時間がかかります。

質問1:02:58-Googleは、昨年12月の11月の終わり頃に重複コンテンツの処理を開始する方法に大幅な変更を認識して発表していますか？または、Webレンダリングサービスのビジネスの進め方や、その期間の前後でWebレンダリングとインデックス作成とクロールされたインデックス作成の関係に大きな変化がありました。これは、システムに何も変更がなく、それ以降、大きな問題が発生したためです。特に私たち自身のためだけでなく、同じ時期にこのクラスの問題について他の多くの観察結果にも気づきましたか？

回答-1：03：47-そこに何か実質的な変化があったところ。秋頃に起こったと思う唯一のことは、検索コンソールにこの機能を追加して、それらの問題を強調し始めたことです。また、強調表示すると、これらのレポートがさらに表示されるようになりました。ユーザーは、これらのURLを削除していて、それらがすべて重複していると思うのでグラフがあるようにしています。もちろん、これは新しい問題ですが、大部分は基本的に常に次のようになっています。検索コンソールでそれについて話したことはありません。そのため、検索コンソールでその機能をいつ展開し始めたかは正確にはわかりませんが、おそらく昨年の後半のようなものです。