SEOオフィスアワー、2022年1月14日

これは、2022年1月14日のジョンミューラーとのGoogleSEOオフィスアワーからの最も興味深い質問と回答の要約です。

robots.txtファイルのサイズ

00:45 「巨大なrobots.txtから生じる可能性のあるSEOの悪影響はありますか？」

ジョンは、「それに直接的なネガティブなSEOの問題はありません。 しかし、それは維持するのを非常に難しくします。 また、問題の原因となるものを誤ってプッシュするのがはるかに簡単になります。 大きなファイルだからといって問題があるわけではありませんが、問題が発生しやすくなります。」 […]

04:35 「[robots.txtファイル]を大幅に短縮する以外に、[それ]を構築するためのガイドラインはありますか？」

ジョン： 「いいえ、それは基本的にあなた次第です。 一部のサイトには大きなファイルがあります。 一部のサイトには小さなファイルがあります。 それらはすべて正常に機能するはずです。 使用しているrobots.txtパーサーのオープンソースコードがあります。 したがって、開発者にそのパーサーを実行させるか、テストできるようにセットアップすることもできます。 次に、そのパーサーを使用してWebサイトのURLをチェックし、ブロックされるURLとその変更内容を確認します。 そうすれば、ライブにする前にテストすることができます。」

また、robots.txtファイルの詳細については、 SEO向けRobots.txtの究極のガイドをご覧ください。

製品カテゴリを新しいドメインに移行する

08:56 「マルチベンダーの1つの製品カテゴリを新しいドメインまたはサブドメインに移動することを計画しています。 […]新しいドメインをランク付けする方法は？ 現在のドメインは、Googleやその他の検索エンジンで上位にランクされており、優れたオーガニック検索トラフィックを提供してくれます。 新しいドメインが現在受信しているトラフィック量を受信するまでにどのくらいの時間がかかりますか？」

ジョンは次のように答えました。 「あるドメインから別のドメインに移動していないように思われるため、その変更に一定の時間はないと思います。 あるインフラストラクチャから別のインフラストラクチャに移行しています。 そして多くの場合、それは内容が異なることを意味します。 ページの構造は、おそらくURLでさえも異なります。 そのすべてが変わる可能性があります。 そして、これらはすべて要素であり、処理に時間がかかります。 それがどれくらいかかるかに関して、それはウェブサイトに依存します。 そして、それはあなたがそのための特定のタイムラインを持つことができるということではありません。

また、これらの変更がWebサイトに全体的にプラスまたはマイナスの影響を与える可能性があることも覚えておく必要があると思います。 したがって、この種の移行を行うことは可能であり、SEOにも取り組み、ページの相互リンク、URL構造、およびページのHTML形式を改善します。 これらはすべて、Webサイトに非常に良い影響を与える可能性があります。

しかし同時に、これらのことに気をつけずに突然URLが混乱し、検索エンジンがHTMLを簡単に理解できない場合、それは悪影響を与える可能性があります。 したがって、eコマースショップをあるプラットフォームから別のプラットフォームに移行する場合、一定期間後に他のプラットフォームでも同じになると想定してはいけません。 それは似ている[または]はるかに良い[しかし]それはまたはるかに悪い可能性があります。 したがって、これらすべての詳細に注意し、必要な最終的な構造と、その移行に含めるSEO要素について考える必要があります。」

11:45 「そのインフラストラクチャを新しいドメインに移動するときに直面するマイナスの側面は何ですか？」

ジョンによれば、「[…]通常、すべてが非常によく並んでいる状況で何が起こるかは、新しいWebサイトについて学習するときから、すべてを切り替えるときまで、時間の経過とともに変動が見られます。 そして、それはあなたが検索でいくらかより少ない可視性を見るであろうと私が仮定する何かです。 しかし、それはあなたがそこに沿って行うすべての変更に依存し、それははるかに長くかかる可能性があります。 また、最終結果が以前よりもはるかに悪化したり、さらには改善したりする可能性もあります。」

アプリのリダイレクト

20:38 「アプリのようなサイトページツールからユーザーをリダイレクトするリスクは何か知っていますか？ SEOの観点からトラフィックに悪影響を及ぼしますか？ […]私たちのアプリは[モバイル版より]コンバージョン率が高いので、一部のユーザーが商品ページやカテゴリページにアクセスしたときに[…]アプリやアプリストアにリダイレクトできるのではないかと考えています。 たぶん[それは]より高いコンバージョンに貢献することができますか？」

ジョンの反応は次のとおりです。 私が一般的に気をつけているのは、ユーザーが必要に応じてアプリにアクセスできるようにすることです。 現時点では、アプリとWebページの接続について詳しくはわかりませんが、ユーザーがアプリをインストールしていることを認識できれば、スマートバナーを作成する方法があると思います。 、そこからアプリエクスペリエンスに移行するのは非常に簡単です。 しかし、AndroidとiPhoneの具体的な詳細はわかりません。 […]

一般に、検索の観点から、個々のモバイルページ、デスクトップページ、またはそこで利用できるものすべてにインデックスを付けることができれば、それはまったく問題ありません。 そして、あなたのページの人々が最終的にアプリにアクセスすることになった場合、それは私たちの観点からもまったく問題ありません。」

22:57 「あなたはサイトページのトップバナーについて話している。 もし私たちが彼らにリダイレクトを[強制]しているのなら、それはSEOやサイトにとって悪いことでしょうか？」

ジョンは次のように述べています。 頭の後ろにあるものが2つありますが、それは注意が必要なことかもしれません。

GooglebotもAndroidユーザーエージェントを使用しているため、アプリをインストールしないため、Googlebotをアプリストアまたはアプリにリダイレクトしないようにする必要があります。 だからそれは一つのことです。 もう1つは、具体的には、CoreWebVitalsに関するメトリックに関するものです。 常にモバイルユーザーをアプリから直接リダイレクトする場合、CoreWebVitalsのデータは多くありません。 また、サイトによっては、[…]ここで覚えておくべきことでもあります。 しかし、私は、[…]ユーザーをアプリにリダイレクトする場合、SEOの観点からは何も悪いことはないと思います。 使いやすさの観点から、それをオプションにすることははるかに良いです。 しかし、最終的には、それはあなたとあなたのユーザーの間です。」

Googleはページの類似性を評価できますか？

26:28 「Googleはページの類似性をどのように測定しますか？」

ジョンは言いました。 私たちはhreflangを使用して、これらのURLのどれがあなたの観点から同等であるかを理解していると思います。 そして、それらを交換します。 […]

これは、rel =” canonical”のようなものに対してのみ行い、正規URLが何であるかを理解します。 しかし、hreflangの場合、この特定のコンテンツが他の国や他の言語と同等であることを理解することは不可能だと思います。 常に可能である非常に多くの地域の違いがあります。」

スパムバックリンクをチェックする

27:22 「私たちは大きなeコマースサイトであり、何百万ものバックリンクがあります。 毎月または数か月にいくつかのスパムバックリンクをチェックする標準的な手順があります。 GoogleDisavowリストの上限がわずか2MBであることに気づきました。 私たちのファイルが制限を超えているのではないかと思います。それでは、それらのスパムバックリンクをどのように処理するのでしょうか。 […]現在、私たちが見つけたほとんどのスパムリンクは[]私たちのサイトをターゲットにして検索ページにアクセスしていますが、これは私にとって非常に奇妙なことです。」

ジョンは次のように答えました。「通常、ドメインディレクティブをできるだけ使用することをお勧めします。これにより、同じサイトからの複数のエントリを節約でき、すべてのリンクのクリーンアップに集中しすぎないようにすることができます。それは常に不可能だからです。 私はリンクにDisavowを使用することに焦点を当てます。リンクを見ると、Webサイトチームの誰かがこれを見ると、あなたがそれらを購入したか、ここで何らかの交換が行われたことを100％確信できると思います。 しかし、Webサイトが取得するこれらすべての種類のランダムなリンク、およびスパムページやコピーページ、ランダムなフォーラム投稿からでも、これらはDisavowファイルに入れる必要のあるものではありません。 […]

これがあなたの状況に当てはまるかどうかはわかりませんが、その前に[これらのリンク]は、電話番号やURLなどを含む特定のクエリで検索結果ページをターゲットにして、その電話を期待していることを確認しました番号が検索結果に表示されます。 また、検索結果ページや、クエリが長い可能性のある検索結果ページにインデックスを付けない場合、それらは自動的にインデックスに登録されません。」

トラフィックの減少とAMPページの削除

30:43 「AMPを削除した場合、トラフィックが減少すると予想されますか？」

ジョン：「これは、従来のHTMLページとAMPページがあり、それらをリンクする設定だと思います。 このようにAMPページを削除すると、3つのことが一緒になると思います。

一方では、AMPのみのページに制限されている検索機能がいくつかあります。 […]再確認する必要がありますが、現時点ではAMPページでのみ利用できる検索機能はないと思います。 したがって、その観点からは、そこで何も失うことはありません。

もう1つは、AMPページは非常に高速である傾向があるか、非常に高速なAMPページを作成する方が簡単なことです。 また、ランキング要素として速度とページエクスペリエンスを使用しているため、AMPに非常に高速なページが多数あり、AMP以外の低速のページに切り替えると、そこで効果が見られる場合があります。 もちろん、AMPではない非常に高速なページを作成することもできます。 AMPに限定されません。 だから、それは私がスピードに関するものがそこにどのように適用されるかを確認するために再確認するものです。

そして、3つ目は、[…]AMPページのランクがどういうわけか優れているというこの仮定だと思います。 そして、そうではありません。 AMPはランキング要素ではありません。 したがって、AMPページがある、またはAMPページがないという理由だけで、ランキングに変化が見られるようなものであってはなりません。 […]

通常のページが高速で同等であり、それらの通常のページに必要なすべての構造化データがあることを確認できる場合は、おそらくAMPをオフにすることができます。 そして、それは本質的に非常に似ているでしょう。 おそらく表示されるのは、一部のAMPページがまだAMPキャッシュにあり、バブルアウトするのにしばらく時間がかかる移行期間です。 ただし、一般的に、これらをオフにすることは可能です。 AMPページをオフにすることに関するヘルプセンターの記事があるので、それも再確認します。」

ナレッジパネル

35:17 「ここ数か月、Googleが特定の名前の検索についてナレッジパネルを調査していることに気づきました。同じクエリに対して、デスクトップではまったくなく、モバイルで非常に一貫して検索されています。 […]この状況で、ナレッジパネルがモバイルユーザーにサービスを提供するのに適切であるが、デスクトップユーザーにはサービスを提供しないと考えられる理由を理解することは可能ですか？ そして、ウィキペディアは、ナレッジパネルを表示するかどうかを決定する際のGoogleにとって重要な要素ですか？」

ジョンは、次のように述べています。「ナレッジパネルに関して、モバイルとデスクトップで異なる方法で行う特定のことを認識していません。 ただし、さまざまな検索機能で非常に一般的です。利用可能な不動産のデバイスタイプに応じて、一部の機能をオンにしたりオフにしたりして、次のようなものが表示されていることを確認します。使用していたクエリに基づいてユーザーに役立ちます。 その観点から、デスクトップとモバイルで異なるナレッジパネルが表示されても驚かないでしょう。 しかし、私たちが言う特定の要因はないと思います。これが、このナレッジパネルがこの時点で表示され、別の時点では表示されない理由です。

時々、この種のクエリに関して、あなたがこの変化を見ているところでは、それはちょうど境界にあるかもしれません、知識パネルを見せましょう。 そして、おそらくデバイスタイプはそれを裏返し、たとえば、最終的には「はい」または「いいえ」のようになります。 しかし、それは私がこれらを表示するか、または表示しないことに関係する1つの特定の要因があるとは思わないものです。 ナレッジパネルにはさまざまなソースを使用しています。 そして、その一部はナレッジパネルに直接表示されます。 だから、それはあなたが少しフォローアップできることの1つです。

これらのことに関して私が与えるもう一つのヒントは、知識パネルとグーグルが物事を拾うときに物事がどのように表示されるかを調べるのに多くの時間を費やしたグーグルの外部の人々がいるということです。 […]ジェイソン・バーナードは私が知っている人の一人で、これを上手くやっています。 彼は常にツイッターにナレッジパネルの周りに投稿しています。 そして多分それはあなたがそこで見ているかもしれないもののいくつかのアイデアもあなたに与えるでしょう。」

FAQリストに含める質問の数

40:41 「私のWebページには15から20のFAQがあります。 FAQスキーマにすべての質問を含める必要がありますか、それとも重要だと思う質問だけを含める必要がありますか？」

Johnによると、 「構造化データに関しては、ページに構造化データが表示されるようにしたいのですが、表示されるすべてのコンテンツを構造化データでマークアップする必要はありません。 構造化データを提供したい個々のコンテンツがページにある場合は、先に進んでそれを実行します。 ページ上のすべてのコンテンツに対してこれを行う必要はありません。 したがって、20のFAQがあり、そのうちの5つをマークアップする場合、それは完全にあなた次第です。 data-nosnippetを使用して、これらの他のアイテムの一部がスニペットに表示されないようにすることもできます。

インデックスカバレッジの問題

52:00 「1つの[問題]がクロールされています-現在インデックスが作成されておらず、[後者]が検出されています-現在インデックスが作成されていません。 どちらの場合も、ページはインデックスに登録されません。 […]Googleがコンテンツ全体をインデックスに登録していないことは知っています。 […]ホームページからのリンクや、特定のWebサイトのクエリの一部ですでにランク付けされているページからのリンクなど、これらのページを少なくとも[インデックス]で高速化するにはどうすればよいですか。 […]より多くの被リンクをもたらす可能性はありますか？」

ジョンは、次のように述べています。 そして、それはあなたが正しい軌道に乗っているように聞こえます、そしてあなたは何を期待するかを少し知っています。

私たちの観点からは、すべてのWebサイトのコンテンツにインデックスを付けるわけではない場合があり、それは私たちの側から予想されます。 したがって、コンテンツの大部分がすでにインデックスに登録されているのを目にしている場合は、正しいアプローチを取っていると思います。 しかし、それはすべてが完璧であるという意味ではありません。 そして、内部リンクのようなもの、ウェブサイトの全体的な品質が本当に良いことを確認すること-それらは大いに役立ちます。

場合によっては、Webサイト全体を見て、2番目のファイルで500ページを送信したと言うのも理にかなっているかもしれません。 そしてそれらの200は索引付けされています。 インデックスに登録されていない300ページの価値は何ですか？ そして、ウェブサイトに500のランダムなページを置くことから私ができるかもしれない何かがありますか？ たぶん[それは]より少ないページに価値を集中させるためにウェブサイト上の300の本当に良いページに減らすことですか？ 少なくともそれらのより少ないページがインデックスに登録されると、それらのページの価値の多くを取り戻すことができます。これは、それらが異なるキーワードにランク付けされているか、優先順位を付ける方法として最も気になるユーザーのために機能する可能性があります。あなたがするためにすべてをグーグルに引き渡す前にあなたの側。

それが私のアプローチです。一方では、内部リンクと全体的なWebサイトの品質にすべてが適切に揃っていることを確認します。 一方、多くのページがインデックスに登録されていない場合は、優先すべきページをGoogleに明確にする方法を見つけようとします。これにより、優先していないページが削除される可能性があります。気にするか、それはあなたのサイトにとって重要ではありません。」