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

このウェブマスターヘルプハングアウトの自宅でジョンミューラーに参加します。 ページ速度、hreflang、およびバックリンクについていくつかのすばらしい質問がありました。 ビデオと完全な文字起こしは、私たちの夏の後に見つけることができます。 これが気に入ったら、週刊ニュースレターに登録することを検討してください。 今週の最高のSEO記事を簡単に消化できるバイトにまとめます。

タグマネージャーを介してjson -- ldを使用する際の問題を説明できますか？

11:18

ですから、私たちが話したことは、かなりの回数であり、これらのたまり場もたくさんあると思います。これについても、バリーを含むさまざまな人々からの新しいブログ投稿が書かれています。 しかし、本質的には、タグマネージャーからコンテンツを取得できるということは、JavaScriptプロセスをタグマネージャーからスクリプトファイルにレンダリングし、そこに書き込みを出力して、インデックス作成側を含めることができる必要があることを意味します。 つまり、これはシステムにとって常に多くの作業を必要とし、すべてのページに対して常に行うことではありません。特に、ページが同じであることがわかった場合、システムがそれを正当化するのは難しいことです。このJavaScriptもすべて処理する必要があります。 さらに、多くのテストツールはタグマネージャーを処理せず、出力も行わないため、ツールがこのマークアップが正しく機能していることを確認するのは非常に困難です。 検索で処理されるまでに時間がかかるため、少し不安定な場合があり、いつでもそのようにインデックス付けされているものが正確にわからない場合があります。 ですから、これらはすべて、私の観点から、他の目的でタグマネージャーを使用することが問題ない理由です。 これを検索用の構造化データ用のJsonLDにも使用するのは問題ありませんが、検索用の特に構造化データ用の優れたアプローチではないことを覚えておく価値があります。 これらは、構造データをWebページに直接提供するためのはるかに簡単な方法であり、メンテナンスが容易になり、すべてをテストするための追跡が容易になります。 だから私はそれをすることをお勧めします、私はあなたがこれのためにここでタグマネージャーを使うことができないと言っているわけではありませんあなたは確かにそれを使うことができますそして私たちはそれを拾い上げて使うために最善を尽くしますそしてそれは完全ではありません構造データを実際にページに直接提供する場合と同じレベルの速度と柔軟性、セキュリティ。

概要： Google Tag Managerを介してJSON-LDやその他の構造化データを使用することは可能ですが、これは最善のアプローチではありません。 グーグルがタグマネージャーからコンテンツをプルするために、JavaScriptをレンダリングする必要があります。 タグマネージャーからスクリプトを処理し、書き込みを出力してからインデックスを作成します。 構造化データをページに直接提供する簡単な方法があり、Googleで簡単に利用できます。

Googleは検索に表示するURLをどのように選択しますか？

15:20

したがって、この種の質問は、Googleが検索に表示するURLをどのように選択するかという一般的な質問になります。この場合、画像1のランディングページのように、すべてのページを表示するようにrelcanonicalが設定されているという側面があります。これらのページは同等ではないことを意味します。 ですから、私たちがそれを拾い上げて使用するのは、一種のヒットまたはミスです。それは、覚えておくべき1つの側面だと思います。 もう1つ覚えておくべきことは、これらのページが同等であると見なされる可能性があることを理解している場合でも、これらのページのどれが実際の正規であるかを判断するために複数の要因を使用することです。 そのために、rel canonicalを使用し、何かがある場合はリダイレクトを使用します。 サイトマップやhreflangリンクなどを使用する内部外部リンクを使用します。これらはすべて、これらのURLのどれを表示する必要があるか、および指定した正規URLが残りのURLでは決して使用しないものであるかどうかを理解するのに役立ちました。あなたのウェブサイトの場合、おそらく、そのリンクrelを正規化することは、Webマスターが実際にそのように意味していなかった間違いであり、正規化として別のURLを選択する必要があるかもしれません。 ですから、ここで何が起こるかは、rel canonicalを無視するか、他の既存のページの1つを選択するか、それが内部で強くリンクされているようなページの1つであると思います。ウェブサイト。 したがって、この特定の設定があなたの場合にはそれほど有用ではないと思います。

概要：Googleは、rel canonical、redirects、internal linking、sitemaps、 hreflangを使用してURLを理解し、Googleが表示する必要があります。 ただし、指定された正規URLがサイトの他の部分で使用されないものである場合、Googleはrel正規URLを無視し、内部で高度にリンクされている別のページを選択する場合があります。

一般的な編集者ユーザーではなく、ブログ投稿に作成者を含めるのは良い考えですか？

17:38

誰が最初に記事を書いたかを知っていて、それを著者のランディングページのように扱うことができる場合は特に、それは良い動きだと思います。それは良い動きだと思います。 純粋なユーザーの観点からでも、誰かがあなたのWebサイトにアクセスし、突然、これらの記事が単なる編集者ではなくバリーによって書かれたものであり、その著者のランディングページがある場合は、それがより良いことを示している可能性があります。ユーザーが拾うものである可能性があるユーザー、または著者のランディングページにアクセスして、この著者が実際にこの分野の専門家であり、そこで数年間活動していることを確認するユーザー。一般的に、そしてグーグルのランキングに関しては、それが直接的な影響を与えるかどうかを言うのは難しい。 しかし、少なくとも間接的な影響は、ユーザーがあなたのコンテンツをより推奨されているように信頼するかもしれないということです。

要約：はい！ 著者のランディングページを持つことは、著者のEATを示す方法です。 また、一般的な「編集者」または「管理者」を使用するのではなく、一般的なユーザーエクスペリエンスを向上させます。

UIを他の言語に翻訳できるが、ユーザー生成コンテンツなどの補足コンテンツが別の言語のままである場合の推奨事項は何ですか？

21:48

したがって、これは特にユーザー生成コンテンツでかなり発生します。 したがって、フォーラムやブログなどがあり、人々が1つの言語でコメントしているが、UIを他の言語に変更できるように設定している場合。 次に、UIがフランス語またはドイツ語である可能性があるが、コンテンツがスペイン語である可能性があるという状況がすぐに発生します。たとえば、全員がスペイン語でコメントしているため、これは基本的に複数の方法で処理できます。 つまり、私の正規バージョンはスペイン語バージョンであり、すべてがスペイン語バージョンと同じであり、実行できる1つのオプションであると言えます。 これらのバージョン間のhreflangアノテーションを使用して、これが私のコンテンツの最もフランス語のバージョンであり、メインコンテンツがフランス語ではなく、UIがフランス語であるため、ページに移動するユーザーがナビゲートできるようになります。私のウェブサイトはあなたにできることです。 そして本質的に、それらはあなたがあなたの好みが何であるかについてもう少し私たちに知らせるためにあなたがそこに提供することができるさまざまなバリエーションです。 実用的な観点からは、検索でどのように表示されるかに関しては、最終的にはあなた次第です。 したがって、フランス語のユーザーがサイトにアクセスして、スペイン語のコンテンツとフランス語のUIを含むページにアクセスし、これらのバージョン間で必ずhreflangアノテーションを使用すると便利だと思われる場合。 UIがフランス語であっても、メインコンテンツがスペイン語である場合、フランスのユーザーがサイトをナビゲートするのにまったく問題があると思われる場合は、スペイン語のUIをインデックスに登録したままスペイン語バージョンを保持するのが理にかなっています。 ですから、最終的にはあなた次第です。どちらも完璧な解決策ではないと思います。 コンテンツがどれだけ均一であるかによって、インデックスを作成する言語バージョンと、ユーザーが検索結果に表示することを期待するバージョンをどれだけ明確に理解できるかに少し依存する場合があります。 したがって、たとえば、非常に国際的なフォーラムで、さまざまな言語で投稿する場合は、このUIバージョンのみをインデックスに登録するように言うのは難しいかもしれませんが、すべてのUIバージョンをインデックスに登録するのは理にかなっています。 もちろん、すべてのUIバージョンにインデックスを付けることの欠点は、サイトが突然持つURLの数が増えることです。 つまり、もっと多くのクロールが必要であり、それが大規模なユーザー生成コンテンツサイトである場合は、クロールする必要があります。一方、ユーザー生成コンテンツのすべてをクロールしてから、それぞれの倍数をすべてクロールする必要があります。言語バージョン。これが役立つかどうかはわかりませんが、Webサイトをクロールしすぎると、検索結果に新しいコンテンツがすぐに表示されなくなる可能性があります。 それは、そこにある種の重荷となる何か他のものです。 数千の記事について話しているだけなら、それはそれほど問題ではないかもしれません。

概要：正規バージョンとして1つの言語バージョンを選択するか、それらの言語バージョン間にhreflangアノテーションを追加できます。

自分のサイトにリンクしている多数のランダムなURLを否認する必要がありますか？

27:58

いいえ、それは本質的に正しい行動であり、特にそれが本当に心配していることである場合はそうです。 ですから、ほとんどのWebサイトでは、外に出て、不気味で奇妙なものを否認することは意味がないと思います。ほとんどの場合、それらを無視しているからです。 したがって、特にリンクに関しては、それを見ると、ウェブサイトチームの誰かがこれを手動で見ると、これは私たちが愚かなことをしていると思います。おそらく、彼らを否定したり、削除したりするのは正しい動きだと思いますが、それ以外の場合は、それが単なる気まぐれなリンクであり、誰かがツールを実行してこのフォーラムに大量のリンクをドロップした他の何百万ものリンクがあるように見えますが、それは私たちのアルゴリズムがすでに理解していることです。 だから、それは私が心配しないことではありません。

概要：Googleは、無視するリンクを見つけるのが得意です。 しかし、否認することになると、後悔するよりも安全である方が良いです。

Googleにとってページ速度はどれほど重要ですか？

42:30

現在の方針は何ですか？ スピードは私たちにとって非常に重要なことであり、ユーザーに大きな影響を与えるので、私は個人的に非常に真剣に取り組んでいます。スピードの良いところは、そこにかなり客観的な対策を提供するさまざまなツールがあることだと思いますあなたが実際に取り組むことができること。 私たちの多くやSEOに関する他の問題に関しては、コンテンツの品質がわかりません。その速度などは、非常に測定可能であり、作業できるものであり、また、そうする必要があります。私たちが使用しているものは、ウェブサイト内でのユーザーの行動から直接影響を受けます。 つまり、速度が重要であるとGoogleの観点から言うと、ランクトラッカーであるだけでなく、ユーザーがWebサイトにアクセスし、Webサイトがそれらのユーザーの読み込みに数秒長くかかったときに直接表示されるものです。あなたのウェブサイトで全く異なった反応をするでしょう、そしてあなたはあなたがあなたのウェブサイトで顧客を定義するけれどもあなたは彼らを顧客に変えるのにより多くの問題を抱えるでしょう。

概要：Googleに関しては、速度は非常に重要です。 これは、簡単に追跡でき、簡単に実行できる1つのメトリックです。 サイトのパフォーマンスと、ページの速度を上げるために何ができるかについての優れた洞察を提供する優れたツールがあります。

Google広告の料金を支払った場合、ランキングは良くなりますか、それとも悪くなりますか？

47:24

ですから、この質問は時々受けますが、ここでの質問は、私のランキングは影響を受けますが、良い部分または悪い部分は、Google広告を使用するとランキングが上がらないという人もいます。 Google広告を使用するとランキングが下がると言う人もいます。これは、より多くの広告を購入してほしいためですが、どちらも当てはまりません。 したがって、Google広告の検索結果は、Google広告を使用するかどうかに完全に依存せず、Webサイトで使用するテクノロジーに完全に依存しません。 したがって、分析などのようなものを使用する場合は、完全にあなた次第です。 あなたがAdSenseまたはこれらの他の広告ネットワークのいずれかで完全にあなた次第で収益化するならば。 したがって、Webサイト内でGoogle製品を使用するかどうかに関係なく、Webサイトに他のGoogleサービスを使用するかどうかは完全にあなた次第です。 それは私たちがこれらのサービスを独立させたいと思っていることです。これがGoogleサービスが優れていない特定の理由であると言えば、私はそれを使いたくないので、他のものを自由に使ってください。 私たちは、あなたがあなたのウェブサイトに集中することとあなたがあなたのユーザーにとって正しいと思うことをすることとこの特定の製品を使わなければならないことの間で立ち往生しているような箱にあなたを入れたくありません。 ですから、私たちがこれらを結び付けないのは実際のところであり、それを明示的に行い、これらがうまく機能することを確認するために懸命に取り組んでいます。

概要：Google広告はオーガニックランキングに影響を与えません。

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

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

フルビデオとトランスクリプト

質問1:14-2週間前、私たちのWebサイトはGoogleのトラフィックの94％を一晩で失いました。 過去20年間一貫した検索トラフィックがあり、大きな変更はありません。クラウドフェアなどのCDNを介してIPSまたはSSLを共有する技術的なものが、アルゴリズムによってトラフィックを大幅に減少させる可能性があると想定しています。 さらに深く掘り下げてみると、同じIP上に非常に危険なコンテンツが含まれていると思われるサイトがいくつか見つかりました。 テーマを変更して専用の証明書を取得することはできますが、それでもトラフィックは減少します。ここで何が起こる可能性がありますか？

回答2:01-しかし、一般的に、他のサイトが同じIPアドレスでホストされているという理由だけで、懸念の理由にはなりません。 したがって、特に大規模なホスティング業者では、共有IPアドレスはCDNではかなり一般的です。共有IPアドレスは非常に一般的です。 また、多くのCDNにはさまざまな国にエンドポイントがあり、そこでアクティブになっているさまざまなWebサイトとエンドポイントを共有しているため、これは変化します。 したがって、基本的にユーザーとドイツでは、たとえば米国のユーザーとは異なるIPアドレスが表示される可能性がありますが、一般に、これはIPアドレスを共有する非常に一般的な方法であり、問​​題になることはありません。 初期の頃、これは日付とホストを認識するのに時々非常に役立つものでした。 1つのIPアドレスと静的アドレスを持つ9000のサイトを見て、それらがすべてスパムであり、同じホスト上に他の2つのWebサイトがある場合、それを理解するのは難しいかもしれませんが、これら2つのサイトは本当に完全になりますか？これらの9,000の他のサイトと比較して別々のサイト。 これは、アルゴリズムにとっては厄介な状況です。 しかし、このようなほとんどの場合、さまざまな種類のサイトが混在しているため、さまざまな国のさまざまな言語のさまざまなサイト、さまざまなターゲットユーザー、いくつかのスパムサイト、同じIPアドレスの非スパムサイト、すべてが完全に問題ありません。 したがって、このIPアドレスに問題となるスパムサイトが1つあるため、それは私たちが言う理由にはなりません。 ですから、このウェブサイトで何が起こったのか具体的にはわかりませんが、一般的に、私たちのウェブサイトの側面は、何年もの間検索でうまくいっていたのですが、それはあなたにとって良いことだと言う傾向がありますサイトですが、それは必ずしも私たちが常にそのように保つものではありません。

つまり、サイトが過去にうまく機能していて、検索が引き続きうまくいくとは限らないからといって、一方ではユーザーの期待が変化し、他方ではGoogleのアルゴリズムが変化します。 したがって、これらのことは常に変化する可能性があり、状況が大幅に変化することがあり、この特定のWebサイトが悪いアルゴリズムであると言うことは少なくなりますが、ユーザーの期待に応えられなかった可能性があることを認識したと言えます。私たちは、ユーザーが期待するものとは一致しない方法で物事を行ってきたため、アルゴリズムが変更され、ユーザーや関連性の高い結果を検索結果に戻そうとします。 だから、それはウェブサイトの種類に応じて常に遊ぶことができるものです。

質問5:49-かなり前に、私たちを上回っているように見えたサイトについて、基本的に私たちのコンテンツを盗み、著作権を侵害しないように変更して、私たちを上回っています。 振り返ってみると、このパターンに気づき、サイトを再設計し、品質を向上させ、ランキングを向上させてからコピーし、次の1、2か月以内にランキングを開始するように思われる調査を行いました。私たちとそれは、どういうわけかアルゴリズムが混乱しているように見え、私たちの代わりにコンテンツの発信者であり、結果としてランキングで私たちを抑制していることでそのサイトのクレジットを与えています。

回答6:37-わかりません。サイトを調べて、そこで何が起こっているのかを正確に確認する必要があります。 つまり、アルゴリズムの観点から言うと、これはちょっとトリッキーです。私たちのアルゴリズムのように、これらのクエリでは常にサイトよりもそのサイトを選択します。 しかし、私が一般的に目指しているのは、これらのサイトがコンテンツをコピーしている場合、コンテンツをコピーしないように促すために、根本的にそれに取り組む方法を見つけようとすることです。 したがって、DMCAの苦情のようなものを調べてみてください。それがあなたのケースに関連しているかどうかはわかりませんが、検索でこれらのバージョンのどれを推測する必要がない方法でそれを処理しようとするものは何でもあります。コンテンツはそれらのクエリに対してランク付けされている必要があります。

質問11:18-タグマネージャーを介してjson-ldを使用する際の問題を説明できますか？ タグマネージャーは、検索コンソールとおそらく分析を検証するために使用されるため、十分に安定していることは確かです。

回答11:33-ですから、私たちが話したことは、かなりの回数であり、これらのたまり場もたくさんあると思います。これについても、バリーを含むさまざまな人々からの新しいブログ投稿が書かれています。 しかし、本質的には、タグマネージャーからコンテンツを取得できるということは、JavaScriptプロセスをタグマネージャーからスクリプトファイルにレンダリングし、そこに書き込みを出力して、インデックス作成側を含めることができる必要があることを意味します。 つまり、これはシステムにとって常に多くの作業を必要とし、すべてのページに対して常に行うことではありません。特に、ページが同じであることがわかった場合、システムがそれを正当化するのは難しいことです。このJavaScriptもすべて処理する必要があります。 さらに、多くのテストツールはタグマネージャーを処理せず、出力も行わないため、ツールがこのマークアップが正しく機能していることを確認するのは非常に困難です。 検索で処理されるまでに時間がかかるため、少し不安定な場合があり、いつでもそのようにインデックス付けされているものが正確にわからない場合があります。 ですから、これらすべての理由から、私の観点からは、タグマネージャーを他の目的に使用しても問題ありません。 これを検索用の構造化データ用のJsonLDにも使用するのは問題ありませんが、検索用の特に構造化データには最適なアプローチではないことを覚えておく価値があります。 これらは、構造データをWebページに直接提供するためのはるかに簡単な方法であり、メンテナンスが容易になり、すべてをテストするための追跡が容易になります。 だから私はそれをすることをお勧めします、私はあなたがこれのためにここでタグマネージャーを使うことができないと言っているわけではありませんあなたは確かにそれを使うことができますそして私たちはそれを拾い上げて使うために最善を尽くしますそしてそれはそうではありません構造データを実際にページに直接提供する場合とまったく同じレベルの速度と柔軟性、セキュリティ。

質問14:00-クライアントは、301ではなく302を使用して移動することでHTTPSの移行を行いましたか？それを301に変更する必要がありますか？ これが永続的なリダイレクトであることをGoogleが理解するのにどのくらい時間がかかりますか？

回答14:14-おそらく、多くの人がサイトの移動にリダイレクトの間違ったタグを使用していることを認識し、それを適切に把握しようと取り組んでいます。 何が起こっているかをすばやく確認する方法は、検索コンソールでチェックインして、適切にインデックスが作成されているかどうかを確認することです。 したがって、新しいドメインが正常に機能している場合は、おそらくすでに問題ありません。 とはいえ、このような問題や、修正が簡単で大きな影響を与える可能性があると思われるWebサイト上のその他の技術的な問題を認識した場合は、先に進んで修正します。 特に間違ったリダイレクトタイプは、ほとんどのWebサイトでhtaccessファイルが1行変更されたようなものです。 だから、それは本当に簡単に修正できるものです。 あなたがそれを間違った方法で解釈する検索エンジンについて心配する必要がないように。

質問15:20-私たちの画像ギャラリーには/gallery/ image1、/ image2、/ image 3のような画像の一意のURLがあり、ギャラリー/ view allを追加して、これを正規URLとして使用したいのですが、このリンクはありませんサイトのどこでもそれを行うことができますか？ ビューはすべて、読者に表示される必要がありますか？

回答15:46-この種の質問は、Googleが検索に表示するURLをどのように選択するかという一般的な質問になります。この場合、画像1のランディングページのように、relcanonicalがに設定されているという側面があります。すべてのページを表示すると、これらのページは同等ではないことを意味します。 ですから、私たちがそれを拾い上げて使用するのは、一種のヒットまたはミスです。それは、覚えておくべき1つの側面だと思います。 もう1つ覚えておくべきことは、これらのページが同等であると見なされる可能性があることを理解している場合でも、これらのページのどれが実際の正規であるかを判断するために複数の要因を使用することです。 そのため、rel canonicalを使用します。何かある場合は、リダイレクトを使用します。 サイトマップやhreflangリンクなどを使用する内部外部リンクを使用します。これらはすべて、これらのURLのどれを表示する必要があるか、および指定した正規URLが残りのURLでは決して使用しないものであるかどうかを理解するのに役立ちました。あなたのウェブサイトの場合、おそらく、そのリンクrelを正規化することは、Webマスターが実際にそのように意味していなかった間違いであり、正規化として別のURLを選択する必要があるかもしれません。 ですから、ここで何が起こるかは、rel canonicalを無視するか、他の既存のページの1つを選択するか、それが内部で強くリンクされているようなページの1つであると思います。ウェブサイト。 したがって、この特定の設定があなたの場合にはそれほど有用ではないと思います。

質問17:38-他の言語や国に提供したいコンテンツがたくさんあるが、メインコンテンツではなく、これまでのところインターフェースを翻訳しただけのサイトに対するあなたの推奨事項は何ですか。

回答17:55-つまり、これは特にユーザー生成コンテンツでかなり発生します。 したがって、フォーラムやブログなどがあり、人々が1つの言語でコメントしているが、UIを他の言語に変更できるように設定している場合。 次に、UIがフランス語またはドイツ語である可能性があるが、コンテンツがスペイン語である可能性があるという状況がすぐに発生します。たとえば、全員がスペイン語でコメントしているため、これは基本的に複数の方法で処理できます。 つまり、私の正規バージョンはスペイン語バージョンであり、すべてがスペイン語バージョンと同じであり、実行できる1つのオプションであると言えます。 これらのバージョン間のhreflangアノテーションを使用して、これが私のコンテンツの最もフランス語のバージョンであり、メインコンテンツがフランス語ではなく、UIがフランス語であるため、ページに移動するユーザーがナビゲートできるようになります。私のウェブサイトはあなたにできることです。 そして本質的に、それらはあなたがあなたの好みが何であるかについてもう少し私たちに知らせるためにあなたがそこに提供することができるさまざまなバリエーションです。 実用的な観点からは、検索でどのように表示されるかに関しては、最終的にはあなた次第です。 したがって、フランス語のユーザーがサイトにアクセスして、スペイン語のコンテンツとフランス語のUIを含むページにアクセスし、これらのバージョン間で必ずhreflangアノテーションを使用すると便利だと思われる場合。 UIがフランス語であっても、メインコンテンツがスペイン語である場合、フランスのユーザーがサイトをナビゲートするのにまったく問題があると思われる場合は、スペイン語のUIをインデックスに登録したままスペイン語バージョンを保持するのが理にかなっています。 ですから、最終的にはあなた次第です。どちらも完璧な解決策ではないと思います。 コンテンツがどれだけ均一であるかによって、インデックスを作成する言語バージョンと、ユーザーが検索結果に表示することを期待するバージョンをどれだけ明確に理解できるかに少し依存する場合があります。 したがって、たとえば、非常に国際的なフォーラムで、さまざまな言語で投稿する場合は、このUIバージョンのみをインデックスに登録するように言うのは難しいかもしれませんが、すべてのUIバージョンをインデックスに登録するのは理にかなっています。 もちろん、すべてのUIバージョンにインデックスを付けることの欠点は、サイトが突然持つURLの数が増えることです。 つまり、もっと多くのクロールが必要であり、それが大規模なユーザー生成コンテンツサイトである場合は、クロールする必要があります。一方、ユーザー生成コンテンツのすべてをクロールしてから、それぞれの倍数をすべてクロールする必要があります。言語バージョン。これが役立つかどうかはわかりませんが、Webサイトをクロールしすぎると、検索結果に新しいコンテンツがすぐに表示されなくなる可能性があります。 それは、そこにある種の重荷となる何か他のものです。 数千の記事について話しているだけなら、それはそれほど問題ではないかもしれません。

質問21:25-ブログの投稿が一般的な編集者ユーザーによって書かれたものとしてマークされた当初から、eコマースWebサイトと一緒にブログを実行しています。 品質ガイドラインとEATを見て、エディターを投稿者の本名に置き換えたいのですが、この種の操作はポジティブですか、それともスパムが発生する可能性がありますか？

回答21:48-誰が最初に記事を書いたかを知っていて、それを著者のランディングページのように扱うことができる場合は特に、それは良い動きだと思います。それは良い動きだと思います。 純粋なユーザーの観点からでも、誰かがあなたのWebサイトにアクセスし、突然、これらの記事が単なる編集者ではなくバリーによって書かれたものであり、その著者のランディングページがある場合は、それがより良いことを示している可能性があります。ユーザーが拾うものである可能性があるユーザー、または著者のランディングページにアクセスして、この著者が実際にこの分野の専門家であり、そこで数年間活動していることを確認するユーザー。一般的に、そしてグーグルのランキングに関しては、それが直接的な影響を与えるかどうかを言うのは難しい。 しかし、少なくとも間接的な影響は、ユーザーがあなたのコンテンツをより推奨されているように信頼するかもしれないということです。

質問22:58-デスクトップバージョンとアンプバージョンのスキーママークアップ。デスクトップバージョンがマイクロデータを使用して実装されていても、アンプバージョンがjson-ldを使用している場合は問題ありませんか？

回答23:09-確かにそれはまったく問題ありません。 ここで使用されている形式や形式に関しては、問題はありません。覚えておくべきことは、ある種の構造化データはjson-ldでしか利用できないということだけです。 そのため、使用している構造化データのタイプを再確認する必要があるかもしれませんが、同じデスクトップモバイル内であっても、あるバージョンのサイトで1つのタイプの構造データを使用し、別のバージョンで別のタイプを使用している場合がありますアプリのバリエーション、それは確かに可能です。たとえば、ブログがある場合、ウェブサイトとeコマースサイトの製品ディレクトリで、eコマースサイトにjson-ldを使用するレビューがあり、ブログでマイクロデータを使用している記事のマークアップ、それがそれを行う正しい方法であるかどうかはわかりませんが、それは完全に問題ありません。

質問24:19-隠しコンテンツの表示について：なしGoogleのサポートは大丈夫で、白い背景の白いフォントまたはフォントサイズゼロはガイドラインに違反すると述べていますが、表示：なしはどうですか？

回答24:32-隠されたコンテンツは、一般的に私たちが評価するものではありません。 特に、ページ自体には実際には表示されないキーワードをGoogleのインデックスにプッシュしようとしているサイトとして出くわします。 だから、それは私が本当に避けたいものです。 レスポンシブデザインについておっしゃいましたが、残りの質問は、ここで関係する1つの側面だと思います。 したがって、レスポンシブデザインを使用して、このコンテンツをモバイルユーザーまたはデスクトップユーザーに表示する場合は、まったく問題ありません。 しかし、このコンテンツが基本的に常に白地にゼロまたは白のフォント、黒地に黒のフォントのように見えない場合、これらは私たちのシステムが取り上げるようなものであり、おそらくこのテキストはそれほど関連性がないでしょうそうでなければ、実用的な観点から、このようなものから手動でアクションを実行することはおそらくないでしょう。 しかし、これを理解しようとする以外に、検索に関しては、そのコンテンツの価値を下げようとします。 そのため、スニペットに表示される可能性が低くなり、それらのページで本当に重要なものとして扱われる可能性が低くなります。

質問25:55-リンクの手動アクションの後、再検討リクエストが受け入れられたが、トラフィックの潜在的なランキングを取り戻さなかった場合、Googleはドメインをどのくらいの期間扱いますか？

回答26:08-手動操作が解決された場合、そのサイトはその手動操作なしで検索で表示されるようになります。 したがって、ここで1つの例外があります。純粋なスパムの理由でサイトが削除された場合、そのサイトは基本的にインデックスから完全に削除されます。 だから、それをオンに戻してもう一度表示できるわけではありません。実際に再クロールする必要があり、そのサイトを処理するのに数週間かかることもありますが、他のすべての手動アクションでは、手動アクションが解決されると、以前の状態に戻ったのは、グーグルが恨みを抱いていて、ここに手動のアクションがあったと言っているわけではないので、本当に解決されていることに特に注意する必要があります。 もちろん、リンクに関しては、不自然なリンクが原因でサイトが検索結果で人為的にランク付けされていて、手動でアクションを実行し、これらの不自然なリンクを削除して修正した場合、もちろん、サイトが人為的に上位にランク付けされることはありません。それらの不自然なリンクは今やなくなっています。 したがって、そのようなものを解決した後に可視性の変化が見られるのは完全に正常なことです。同様に、Webサイト上の他の事柄が原因でサイトが不自然に表示され、それらの他の事柄を削除することで解決した場合、明らかにあなたのサイトは再び自然に見えるようになりますが、削除したものが原因で不自然に見えることはないので、注意が必要です。

Question 27:59 - In looking at some of our backlink profile we had found, I don't even know how our links ended up on these pages, like on pages that have just like 7,000 links and things like that. We disavowed them when we found them. Is there anything we need to be concerned about other than doing that with when we find stuff like that?

Answer 28:20 - No that's that's essentially the right move to do and especially if it's something that you're really worried about. So I think for most websites it doesn't make sense to go out there and disavow things that are just like iffy and weird because for the most part we just ignore those. So in particular with regards to links, if it's something that when you look at it you say well this could be seen as these links be being bought by us, like naturally placed there by us, if someone from the website team were to take a look at this manually and they would assume that, this is us doing something stupid, that's the kind of thing where I'd say probably disavowing them or getting them removed would be the right move there but otherwise if it's just an iffy link and it looks like it's something like there are millions of other links on there someone ran a tool and dropped tons of links into this forum then that's something our algorithms have figured out already. So that's not something I wouldn't worry about.

Question 30:06 - What do you suggest to tackle a low traffic, low quality pages on a site? There lots of suggestions regarding content pruning what recommendations do you have regarding that?

Answer 30:20 - So I think first off the assumption that a page that has low traffic is also low quality is something that I would question and sometimes pages just have low traffic because a lot of people search for them but they're still a really good truck pages. So II would question kind of the assumption that you can just go into analytics and sort of your pages by a number of page views and delete all of the lowest pages there because I don't think that necessarily picks up like that these pages are really low quality or not. So that's kind of a first assumption there, if you know your website then obviously you can combine different metrics to try to figure out where the low quality pages are but I would still recommend making sure that these are really low quality pages before you take any kind of harsh action on those pages. And then as a next step if you do know that these are low quality pages when whenever I talk to our engineers from the quality team they tell us not to tell web masters to just go off and delete those pages but instead to going to improve them. So if you know that they're low quality pages that probably means you know what is missing and that probably means you know there are ways to kind of make these higher quality pages. So that's kind of the direction I would take there and not just delete things that are low quality but figure out a way to make them more high quality instead. So that could be by combining pages maybe it's something where you see this one-page, its kind of thin but it matches this your page and you have otherwise on your website maybe combining them makes sense. So 301 redirecting them to kind of one shared URL instead that might be an option. Rewriting them to be higher quality is obviously a good idea obviously takes work so it's not this one simple magic trick to make number one. Then finally if it's really something that you can't resolve at all or that is such a big mass of pages that are low quality that you can't really fix then maybe deleting them is it right. So those are kind of the different variations there that are available but again I would strongly question the the assumption that low traffic equals low quality. So if you're looking even looking at a larger site don't just assume that because something has low traffic is sign that it's not important for your website or for the rest of the web.

Answered Cont' 34:03 - Yeah so I think one way you could look at this is to say given this state of content that you have what would be your preferred new website look like? So kind of saying like assuming I had all of this content and I had to create a new website out of it what would it look like and then to try to find a way to migrate your existing content into this new structure that you have in mind and like I said it could improve include combining pages, combining maybe tens of different pages together into one stronger page, it could be deleting pages where you say, well these don't make any sense for my website anymore maybe it was something that users cared about a couple years ago but now, I don't know, nobody is playing ingress anymore so all of those ingress pages on my website I have to make a hard decision and delete them. I can see the shocked faces everywhere in here now. But these kind of things happen over time and it makes sense to clean things up over time and sometimes it means deleting, sometimes that means combining, sometimes that just means rewriting and cleaning up. So it's it's hard to have one one answer that works for every side in every situation.

Question 36:36 - How to fix the crawl frequency of low priority pages within a website? Will Google crawl more of such pages because the quantity of these pages is more compared to the important pages?

Answer 36:49 - So I think this was your question as well in general you don't need things the the crawl rate of pages unless these are pages that are being changed more frequently than the crawl rate. So if you have an article that you wrote and it's being crawled once every three months and you're never changing this article that's that's perfectly fine we don't need to crawl it more often. There is no ranking bonus for being crawled more often. So crawling from our site is more of a technical thing where we say, this page has changed we should find a way to pick up this change as quickly as possible. It's not that we would say well the stage has been crawled twice in the last week therefore we will rank it higher those are completely separate parts of our algorithms.

Question 37:48 - I was checking the log files and 90% of our crawl budget is going to those specific URLs only and only 10% is crawling my product pages. So I was wondering I could make them crawl less frequently for those specific sections and maybe Google can start crawling or kind of giving more importance to my other sections of a set?

Answer 38:18 - Okay so you actually want to do the opposite which is I think a good move too. To have those pages crawled less frequently. So from from our point of view there's really no way to do that. So it's something that you would need to almost attack from the other way around to say, that I think these are other pages that are important on my website and therefore I'll link them prominently within my website. I'll make sure that all of my other pages refer to those pages, that they're specifying the sitemap file with the last modification page that we can confirm. So all of those signals to help us understand we need to be able to crawl these pages more frequently because there are changes on these pages. On the other hand if there are no changes on these pages we don't really to recall them for more free company so that's kind of be the other aspect there. If these are pages that are important for you but they are not changing frequently then there's no need to artificially force them to be crawled more often.

Question 40:11 - Can you tell if with redirection only link penalty passes or link penalty and content penalties both pass for example at website with pure spam manual action is redirected to another site so technically the URLs will be a soft 404, will it affect the redirected website?

Question 40:37 - So I'm not quite sure with which part of this question you're you're kind of focusing on. On the one hand if a random spammy website redirects to your website that's usually something we can recognize and just ignore. On the other hand if yours is that spammy website and you're redirecting to another website to try to escape that penalty then probably we will be able to follow that site migration and apply that manual action or algorithmic action to the new website as well. So my recommendation there would be instead of trying to get away by doing fancy redirects or other types of site moves. I would recommend just cleaning up the issues so that you don't have to worry about those anymore. So if there are link actions with regards to that website then clean up those those links so that you're in a clean state again. The reconsideration process is great for that because someone from the web spam team will take a manual look at your website and they'll say, this looks good this is fine like. You did good work and clean things up it's clear that you understand what you should be doing now so we can remove them. So I think that's really useful to have there from a practical point of view. So that would be kind of my recommendation if you're the website that has this problem. On the other hand if like I mentioned some random website redirects to your website and that's usually something that we can recognize, this is not a normal site move this is just the read website redirecting to you to another website and we can get that.

Question 42:30 - John two quick general questions one related to site load speed, we've read and heard various things including recently people saying that like every microsecond counts and things like that, what is the current policy I know in the past you said as long as it's not ridiculously long to load you're fine?

Answer 42:53 - What is the current policy? So speed is something that does matter quite a bit to us and it has a big effect on users so that's something that I would personally take quite seriously and I think the the nice part about speed is there various tools that gives you pretty objective measures there that you can actually work on. With regards to a lot of us or other issues around SEO like, I don't know the quality of their content things like that speed is something that that is quite measurable and something that you can kind of work on, and it should also be something we're used a direct effect from your users behavior within your website. So it's not just something that from from Google's point of view like we say speed is important it is rank tracker but it's something that you will see directly when users come to your website and your website is suddenly taking a couple seconds longer to load those users will react quite differently on your website and you'll have more trouble converting them into customers however you define customers on your website.

Question 44:08 - From the standpoint of like if it's 1.1 seconds versus 1.2 second that kind of thing would would you say that that's very important to try to really optimize those?

Answer 44:21 - I think the tricky part with speed is there's so many different measures in the meantime that it's hard for me to say like, load time is the only thing you should be thinking about, but there ways to to kind of determine how quickly the page is is generally accessible. How quickly they the content is visible on the page, even kind of ignoring the aspect that maybe the rest of the page below the fold is still rendering and still takes a bit of time to actually be ready, maybe the part that users care about is actually visible fairly quickly. So from from that point of view usually small differences are less of a thing but kind of like I mentioned speed is something where you can use these different tools who could come up with a different metrics and you can focus on those metrics and try to improve those and you can measure that yourself and you can kind of work on that without having to go through various Google tools and waiting for things to update in the index in these tools.

Question 45:47 - Can I use Google official videos in my blog or can I only link to them for example Matt Cutts videos about SEO. I will use Adsense on the blog when I have enough adsense my blog will be complete in 6 months.

Answer 46:03 - I don't think there are any restrictions with regards to embedding videos for a channel but if there were no restrictions then I think the embed option YouTube wouldn't be available there. So if the embed option is there then then go for it. I think in in general I'd be cautious about using just a video as the primary piece of content on a web page and you should really work to kind of use the video in a way that supports your primary content but not that it replaces your primary. So for example I wouldn't take any of these videos and just put them on a blog post and add a title to them and expect them to show up highly in search. But if you have specific content around that video if you have a transcription of that many don't you have some comments to that transcription to the content that are shown in the video or you're using that video as kind of a point of reference with regards to your content and I think that's a perfectly fine approach. But just purely using a video on a page is something that atleast in a web search point view makes it really hard for us to determine what is actually useful on this page and why should we show it in the search results.

Question 47:27 - If I pay for Google Ads will my ranking be better or worse?

回答47:34-私たちは時々この質問を受け取ります、そしてここでの質問は次のようなものです、私のランキングは影響を受けますが、良い部分または悪い部分は、あなたのランキングが得られないと言う人もいます。 Google広告を使用すると、より多くの広告を購入してほしいので、どちらも当てはまらないため、Google広告を使用するとランキングが下がると言う人もいます。 したがって、Google広告の検索結果は、Google広告を使用するかどうかに完全に依存せず、Webサイトで使用するテクノロジーに完全に依存しません。 したがって、分析などのようなものを使用する場合は、完全にあなた次第です。 あなたがAdSenseまたはこれらの他の広告ネットワークのいずれかで完全にあなた次第で収益化するならば。 したがって、Webサイト内でGoogle製品を使用するかどうかに関係なく、Webサイトに他のGoogleサービスを使用するかどうかは完全にあなた次第です。 それは私たちがこれらのサービスを独立させたいと思っていることです。これがGoogleサービスが優れていない特定の理由であると言えば、私はそれを使いたくないので、他のものを自由に使ってください。 私たちは、あなたがあなたのウェブサイトに集中することとあなたがあなたのユーザーにとって正しいと思うことをすることとこの特定の製品を使わなければならないことの間であなたが立ち往生しているような箱に入れたくありません。 ですから、私たちがこれらを結び付けないのは実際のところであり、それを明示的に行い、これらがうまく機能することを確認するために懸命に取り組んでいます。