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

今週、ジョンはニューヨークのビッグアップルにいます。 GoogleのJavaScriptチームのMartinSplitt、Chris Love、Lily Ray、Marie Haynes、Dave Minchala、QuasonCarterが左から右にIRLに参加しました。 今週は、Cloudfare、QRG、およびNew PageSpeedToolについていくつかのすばらしい質問がありました。 ビデオと完全なトランスクリプトへのリンクは以下にあります！

Cloudflareは時々Googlebotをブロックしますか？

7:58

「ええ、現時点ではCloudflareでどのように設定されているかはわかりませんが、過去にはGooglebotを偽造している人々をブロックしていたことは知っています。カエルか何か-私がGooglebotユーザーエージェントを使用していると言うと、彼らはそれをブロックします。たとえば、これは正当なGooglebotではないと言うことができるからです。私たちはそれをブロックできます。しかし、ほとんどの場合、彼らは通常のGooglebotを認識し、それを通常どおりクロールさせるのに十分な練習をしてください。」

概要：テスト時に、CloudflareがGooglebotをブロックしているように見える場合があります。 ここで起こりそうなことは、CloudflareがGooglebotのふりをしている人々をブロックしているということです。 そのため、Screaming Frogなどのツールを使用し、ユーザーエージェントとしてGooglebotを選択した場合、Cloudflareを使用してサイトをクロールできない可能性があります。

不自然なリンクはまだアルゴリズム的にサイトを傷つけることができますか？ もしそうなら、否認ツールの使用は助けになりますか？

14:01

「それは良い質問だったと思います。ですから、私の観点からすると、一方では、間違いなく手動のアクションがある場合です。また、あなたがしたい場合もあります。多くの手動アクションを見ると、Webスパムチームがこれを今見た場合、手動アクションが提供されます。手動アクションの方が問題であると言う場合があります。時間であり、それが行われたものに基づいているようなものではありません-私は知りません-それが数年前に明らかに行われた場所であり、それは境界線ではありませんでしたが、あなたがそれを見るようなものたとえば、Webスパムチームの誰かがこれをヒントとして受け取った場合、彼らは手動でアクションを実行します。それは間違いなく、私がそれをクリーンアップして、それに対する否認のようにするようなものです。特定のタイムラインのようなものがあるかどうかを判断するのは難しいですが、一般的に、ウェブスパムチームがこれを見て、たとえば、物事は進んでいると言った場合、これは明らかにdでした数年前の1つ。 それは完全に悪意のあるものではありませんでした。 そうすれば、彼らはおそらくそのために手動の行動を取ることはないでしょう。 「」

そして、私はあなたがおそらくこれに答えることができないと思いますが、たとえば、私たちが手動のアクションを取得しなかった、または彼らが手動のアクションを取得しなかったと言うような方法はありますか？ それらのリンクはアルゴリズム的にそれらを傷つけることができますか？ 一部のサイトで改善が見られているように感じているので、否認した後です。 だから、繰り返しますが、私はそれが常にあることを知っています-それは決して白黒ではありません。

それは間違いなく当てはまります。 ですから、私たちのアルゴリズムを見ると、ここでは非常に悪いリンクがたくさんあることがわかります。ウェブサイトの一般的なリンクに関しては、もう少し慎重になるかもしれません。 したがって、それをクリーンアップすると、アルゴリズムがそれを調べて、「ああ、ある種の」と言います。それで問題ありません。 悪くない。

概要： SEO専用に作成されたリンクがあり、それらが多数ある場合、Googleのアルゴリズムがすべてのリンクを信用しない可能性があります。 このような場合は否認するのが最善です。

Googleのアルゴリズムは出版社のEATをどのように測定しますか？

33:40

「わかりません。アルゴリズムで理解するのはおそらく難しいと思います。また、技術的なことを行う必要がある場合は、お知らせします。したがって、著者のマークアップなどがある場合は、ある時点で、このようなものに役立つと思われる場合は、それを確実に引き出します。しかし、多くのことは、私たちが理解しようとしている、よりソフトな品質要因であり、技術的なものではありません。 「行っているか行っていないかのどちらかです。それは、ユーザーがこれをどのように見るかを理解しようとするようなものです。したがって、私が指摘できる具体的なことは何もありません。」

概要： Googleが注目している「ソフト品質要因」はたくさんあります。 ユーザーの視点から物事を見てください。 また、著者のマークアップは、Googleが物事をよりよく理解するのに役立つ可能性があります。

品質評価者のガイドラインに何かが含まれている場合、Googleがこれをアルゴリズムに反映することを望んでいると想定するのは合理的ですか？

34:44

一般的には、それを目指すのは良い習慣だと思います。 Googleがアルゴリズムの要素として使用する可能性のあるものに焦点を当てすぎないようにし、それをもっと詳しく見ていきます。これはWebに適していると考えているため、その方向に進んでこれらを実行します。ある種のもの。 ランクを上げるためだけに良いウェブサイトを作っているわけではありませんが、検索結果に表示されるときは、人々に良い体験をしてもらいたいので、良いウェブサイトを作っています。 そして、彼らは私のウェブサイトに戻ってきて、多分彼らは何かを買うでしょう。 だから、それは私が見る方向のようなものであり、ランク付けするためにこれを行うのではなく、ウェブ上で健全で長期的な関係を築くためにこれを行うのです。

概要：ユーザーにとって何が最善かを考えてください。 QRGに含まれるすべてのものが現在Googleのアルゴリズムに反映されているわけではありませんが、これらはすべて、全体的な品質を向上させるための優れたステップです。

音声検索結果でサイトが上位に表示されるようにするためのスキーマはありますか？

36:10

知らない。 手に負えないことは何も思いつかない。 したがって、使用できる読みやすいマークアップがあります。これはおそらく合理的です。ページのどこに意味があるかを調べてみてください。 まだすべての場所で使用するわけではないと思います。

概要：話すことができるマークアップは、まだすべての地理的な場所で使用されているわけではありません。 しかし、これは始めるのに良い場所です。

注目のスニペットを獲得するためのヒント

38:03

しかし、特に注目のスニペットには、それに固有のマークアップはないと思います。 つまり、ページに明確な構造がある場合、それは私たちに大いに役立ちます。 ページ上のテーブルのように認識できれば、それをはるかに簡単に引き出すことができます。 一方、派手なHTMLとCSSを使用してテーブルのように見せても、実際にはテーブルではない場合、それを引き出すのは非常に困難です。

概要：注目のスニペットを獲得するために追加できるマークアップはありません。 ただし、hタグと通常のHTMLテーブルを適切に使用すると非常に役立ちます。

ロケーションスキーマをすべてのページに追加する必要がありますか？

50:47

回答51:42-私が知る限り、それは単なるホームページです。 知らない。 知っている人はいますか？

リズ51：4からの回答7-通常、組織と企業の1ページだけであると想定されています。 それは一般的に推奨事項です。

MARTIN SPLITT 52:00-どちらでも構いません-持っているすべてのページに配置しないのと同じように、どのページでも構いません。もっと重要なことだと思います。 ニュースサイトの場合は、連絡先ページや概要ページなどに配置するのが理にかなっていると思います。 ショップやレストランのウェブサイトでは、ホームページに載せても大丈夫でしょう。

ヨハネ52:20-この場合も、ホームページや連絡先ページのような場所で見つけることができる必要があるので、私たちにとってはそれほど重要ではないと思います。 しかし、他の場所にある場合でも、何も変わりません。 したがって、比較しない大きな点は、レビューマークアップです。このマークアップでは、サイトのすべてのページの星と検索結果を取得することを期待して、Webサイトのすべてのページに会社のレビューのように表示されることがあります。 そして、それは私たちにとって悪いことです。 しかし、連絡先情報をマークアップしている場合は、それは-問題はありません。

要約：それは実際には問題ではありません。 連絡先ページと、おそらくあなたのアバウトページとホームページにあるはずです。 サイト全体にロケーションスキーマがあることは問題ではありませんが、おそらく必要ではありません。

Lighthouseに基づく新しいPageSpeedInsightsツールは、Webサイトのスコアリング時に非常に厳しいのはなぜですか？

53:05

マリー・ヘインズ：それは私の質問ではありませんが、コンテキストを与えるために、ページ速度の新しいLighthouseデータは、PageSpeedInsightsが以前よりもはるかに厳しいものです。 したがって、Page Speed Insightsでスコアが80のようなものは、Lighthouseでは赤の29になる可能性があります。 いい質問ですね。 モバイルでは、非常に遅いサイトが降格される可能性があることがわかっているため、これが原因である可能性があります。 それで、灯台テストで赤字になっている場合、降格を引き起こす可能性があるため、本当に改善する必要があると言ってもいいですか、それともカットオフがありますか？

回答54:07-したがって、外部ツールの1対1のマッピングはなく、ソーシャルに使用するすべてのものがあります。 ええ、それは本当に言うのが難しいですが、検索では、実際の、それが何であるか、LighthouseテストのようなラボテストデータとChromeUXレポートデータを組み合わせて使用​​しようとします。私たちが測定しているのは、ウェブサイトのユーザーに表示されるものです。

MARTIN SPLITT 55:37-たとえば、Lighthouseが中央値側の3G接続を具体的に測定していることを確認することも重要です。つまり、中性能の電話のようです。 したがって、基本的に、最近のApple McIntoshまたは最近の高速Windowsコンピュータを使用していて、オフィスで有線接続やWi-Fi接続のように非常に優れている場合は、もちろん、読み込み時間は2秒ですが、自分の携帯電話を実際に持っている実際のユーザーは、おそらくそれを見ていません。 したがって、ウェブサイトを高速化することは決して害にならないようなケースの1つですが、これは、必ずしも1つをマッピングしていない非常に具体的なメトリックを使用しているため、内部の観点からどのように見えるかを言うのは本当に難しいです。ツールが公開しているものの1つ....もちろん、ユーザーがWebサイトを永遠に待つことを望まないため、これを修正することが重要です。 それはあなたを傷つけるでしょう。 それはあなたのユーザーを傷つけるでしょう。 それは検索であなたを傷つけるでしょう。 しかし、私はお金を払っていません-私はただツールを見ると言うでしょう。 ツールがあなたがうまくやっているとあなたに言っているなら、あなたはそれについてあまり心配するべきではありません。 ツールがあなたが本当に良くないことをしているとあなたに言っているなら、私はそれがなぜ言うのかを理解するのに費やされた時間だと思います-例えば、それが言うことが関連しているなら、それは無駄です。 むしろ、サイトを高速化することを検討する必要があります。

モバイルのパフォーマンスは、ユーザーだけでなく他のすべてにとっても非常に重要な要素です。 だから私はあなたのウェブサイトが実際の条件でうまく機能することを確認すると思います。 たぶん、安い電話を手に入れて、時々ウェブサイトを試してみてください。そうすれば、それは私がやりたいことであり、私が一緒に働いていた開発チームと一緒にGoogleに参加する前はそうしていました。 私は、この電話でこのWebサイトを使用しますか？ ああ、これはひどいようなものでした。 私は、うーん、そうだね、だから多分私たちはそれについて何かをすべきだろう。

JOHN-Chromeでは、設定してさまざまな接続速度を試すことができます。 モバイルエミュレータ。 それは本当に良いことだと思います。また、ユーザーベースも見てください。 人々がハイエンドのiPhoneでのみあなたのウェブサイトを使用していることがわかっている場合は、分析データを見てください。おそらく、人々がランダムな地方の接続からサイトに接続していることを確認している場合よりも問題は少ないでしょう。遅く、そして彼らはローエンドのデバイスを持っています、そして多分それはもっと多いです。

概要： Lighthouseは3G接続の速度を測定するため、ほとんどのサイトは、ほとんどのセッションでここに表示されるよりもはるかに高速に動作します。 注：このハングアウトが終了した後、マーティンは、ランクの降格の可能性に関して最も重要なのは「最初の満足のいくペイント」であると続けました。

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

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

ビデオと完全なトランスクリプト

質問1 :32 -SEOがより正確に、より自信を持ってビジネスに報告できるように、テストに関するガイダンスや視点がこれ以上あるかどうか疑問に思いました。 これを試してみたところ、インパクトがありました。 そして、Googleが推奨するような、確実な方法でそれを行いました。

回答3:20-それで、私の観点から、私はより技術的なタイプのものを品質タイプの変化の種類から分離しようとしています。 したがって、本当に明確な技術的なことであれば、それが機能するかどうかをテストすることができます。 それは種類の問題ではなく、機能しないのですが、特にレンダリングを見ているとき、またはGoogleが実際にこのコンテンツをインデックスに登録できるかどうかを見ているとき、これらの技術的なことの多くは、動作するか動作しないかのどちらかです。 トリッキーになるのは、それに関するすべてのことです。インデックスが付けられていますが、ランキングにはどのように表示されますか？ そして、その多くについて、それを実際にテストする絶対的な方法はないと思います。 テストサイトを作成するなど、孤立した状況でテストし、推奨事項を設定した場合、テストサイトが通常のWebサイトと同じように機能するとは限りません。 テストサイトの場合など、単純なことがある場合もありますが、これとこれに多くの時間を費やすことは意味がないと思われるため、完全なレンダリングを行わない可能性があります。たとえば、誰も見ていないためです。 検索結果に表示されることはありませんが、なぜそんなに多くのリソースをその背後に置く必要があるのでしょうか。 一方、通常のWebサイトでそれを行った場合、動作は大きく異なります。 ですから、それはあなたが何をすべきか、何をすべきでないかについての明確なガイダンスが実際にはないということです。 Webサイトが表示されている一般的な傾向、それらのクエリで表示されているランキングの変化を見て、そこでベストプラクティスを適用しようとするようなもののようです。

質問5: 21-それで、もし-具体的な例-それを使って-多分それは役に立つでしょう、それでタイトルタグテストのようなものでしょ？ もしあなたがそれをしているのなら、もしあれば、私たちは何を探すべきですか？ それとも、解きほぐすために注目すべきことがありますか？これは私たちのテストによるものですか、それともサーバー、アルゴ、競争力のあるダイナミクスに関する何かの変化によるものですか？ [笑い]私たちがそれらの外部性を見るために他のことをしていると仮定します。

回答5:56-タイトルタグの変更は、実際にはかなり複雑だと思います。Googleは、実際に提供しているタイトルタグを、ランク付けのために使用するという相互作用があります。一方、検索結果に表示するため。 デスクトップとモバイルの場合と同様に、スペースの量が異なるため、表示されるタイトルタグがわずかに異なる場合があります。 ユーザーはさまざまな方法でそれに応答する可能性があります。 したがって、同じ方法でランク付けすることもできますが、ユーザーは、これはすばらしいページだと思うかもしれません。 上位に表示します。または、すばらしいページのように見えるので、検索結果でクリックします。 そして、あなたはより多くのトラフィックを持っています。 しかし、ランキングは実際には同じです。 それで、それは良いことのようですか？ おそらく、私は推測します。 ランキングを見ているだけなら、それは、まあ、何も変更していないように見えます。トラフィックが増えただけです。

しかし、それはそこにその種の流れのような多くの異なる側面があるものです。 つまり、SEOとしては、何が起こったのかを技術的に理解するだけでなく、ユーザーが変化にどのように反応するかについて、マーケティングと品質をより深く理解することが役立つと思います。はユーザーに影響を与える可能性のある長期的な変更です。ユーザーがそれに関連する何かを検索している状況で、私たちのサイトが最も関連性の高いサイトとして表示されるようにするには、どうすればそれを推進できますか。 そして、それはテストするのが本当に難しいことだと思います。 何年にもわたって実践してきた従来のマーケティングでも、これが実際に大きな影響を与えているのかどうかなど、テストするのは本当に難しいのです。 それは彼らが全体像を見たり、ユーザー調査をしたりすることになるものであり、それはあなたがSEOとしても行うことができます。 ごめん。 [笑い]

質問7:58-もっと直接的な質問があります。 ですから、私たちのサイトの多くはCloudflareを利用しており、それらがGooglebotを直接ブロックしていることに気づきましたね。 しかし、それは私たちのランキングや可視性などにはあまり影響を与えていません。 では、たとえば、別のボットを使用してGooglebotの外部のインデックスを直接クロールする方法を理解しようとしているのですが、CDNがボットをブロックするのを邪魔しているときに、それについてどのように考える必要がありますか？

回答8:33-ええ、現時点ではCloudflareでどのように設定されているかはわかりませんが、過去には、Googlebotを偽造している人々をブロックしていたことは知っています。 ですから、あなたが自分の、Screaming Frogなどを使用している場合、私はGooglebotユーザーエージェントを使用していると言うと、彼らはそれをブロックします。 Googlebot。 それをブロックすることができます。 しかし、ほとんどの場合、彼らは通常のGooglebotを認識し、それを通常どおりにクロールさせるのに十分な練習をしていると思います。

質問9:02-ええ、面白かったです。 他の機関の多くの同僚に連絡を取り、彼らは自分のサイトでも同様の状況を再現していたからです。 同様に、Cloudflare内にサポートチケットがあり、GooglebotまたはGooglebotスマートフォンから直接レンダリングしようとしたときにもブロックされていました。

回答9:21-はい、そうです。 まあ、回避策はありません。 たとえば、Webサイトが私たちをブロックしている場合、私たちはちょっと立ち往生しています。 しかし、通常、Cloudflareのようなサービスがデフォルトで私たちをブロックしている場合、それは多くのWebサイトに影響を及ぼします。 そして、私たちはそれに気付くでしょう。 私たちはおそらくそのようなことについてCloudflareに連絡するでしょう。 おそらく彼らは異なるサービス層を持っているのかもしれません。 つまり、下位層にいる場合は無料サービスのようですが、トラフィック量には制限があります。 彼らがそのようなものを持っているかどうかはわかりません。 これは私が他のホスティング業者で見たものです。無料のデフォルトホスティングを設定している場合、トラフィックの上限が設定されているだけで、物事がブロックされることがあります。

MARTIN SPLITT：ランキングなどの統計では、すぐにはわからない場合があります。 基本的に、私たちがあなたからのコンテンツを持っている場合、そして基本的に、ウェブサイトはそうではありません-ブロックされたものによっては、この場合、私がそれを見たことがないからです。 そして、Cloudflareの背後でいくつかのWebサイトを運営していますが、問題はありません。 しかし、繰り返しになりますが、私は無料プランを利用しているため、巨大なWebサイトを持っていないか、大量のトラフィックが好きではありません。 それは-しかし、あなたが私たちの側でエラーのようにならなければ、それは-私たちが最後に見たコンテンツを保持しているということかもしれません。 そして、それはちょうど良いランクです、そしてそれは大丈夫です。

回答12:09-ええ、あなたのような場合に何が起こるかは、クロールを遅くすることだと思います。 そして、インデックスでより多くフェッチできるコンテンツを保持しようとし、少し長く再クロールします。 しかし、それはまた、あなたがあなたのウェブサイトに変更を加えた場合、私たちがそれを拾うのにもっと時間がかかることを意味します。 AMPのように、大幅に再クロールする必要がある場合、またはサイト全体にそのようなものを追加する場合は、すべて時間がかかります。 したがって、通常のGooglebotでクロールできないことが本当に定期的に見られる場合は、それをホストと一緒に取り上げて確認できるようにします。

質問14 :01-すばらしい。 だから私は否認ツールについて質問があります。 そのため、リンク監査を希望する人が常にいます。 そして、ペンギン4.0以来、Gary Illyesが言った2016年9月、そしてあなたも言ったと思います。たとえば、Googleは不自然なリンクを無視するのが得意です。 そのため、当時の私の考えは、不自然なリンクを手動で処理しない限り、否認ツールを使用して、すでに無視しているリンクを無視するようにGoogleに依頼する必要はないということでした。 ですから、私たちは積極的にリンクを構築し、物事を操作しようとしている、不自然なリンクであるサイトにのみそれを推奨してきました。 しかし、私はウェブマスターの間で非常に多くの混乱があると思います。なぜなら、私はいつも人々を見て、監査するために、つまり正しいリンクを否認するために莫大なお金を請求しているからです。 ですから、もう少し詳しく説明していただければ幸いです。 たとえば、数年前にSEO会社を雇ったビジネスオーナーがいて、そのSEO会社がリンクのためだけにたくさんのゲスト投稿を行った場合などです。中程度の品質でしたが、私が言っていることを知っていれば、超スパムではなく、Googleがそれらのリンクを無視していると確信できますか？ それとも、私たちは入って否定するべきですか？

回答15 :22-それは良い質問だったと思います。 ですから、私の観点からすると、一方では、間違いなく手動アクションがある場合があります。 しかしまた、多くの手動アクションも見たい場合は、Webスパムチームがこれを今見れば、手動アクションが得られると言えます。 あなたが言うような場合、まあ、手動のアクションは時間の問題であり、それが行われたことに基づいているようなものではありません-私は知りません-それが明らかに2、3年行われた場所以前、それは一種の境界線ではありませんでした。 しかし、あなたがそれを見て、ウェブスパムチームの誰かがこれをヒントとして得た場合、彼らは手動の行動を取るだろうと言うようなものです、そしてそれは間違いなく私がそれをきれいにしてやるようなものですそのための否認のように。 ええ、特定のタイムラインのようなものがあるかどうかを言うのは難しいと思います。 しかし、一般的に、ウェブスパムチームがこれを見て、たとえば、物事は進んでいると言った場合。 これは明らかに数年前に行われました。 それは完全に悪意のあるものではありませんでした。 そうすれば、彼らはおそらくそのために手動の行動を取ることはないでしょう。

質問16:43-そして、おそらくこれに答えることはできないと思いますが、たとえば、手動アクションを取得しなかった、または手動アクションを取得しなかったなどの方法はありますか。 それらのリンクはアルゴリズム的にそれらを傷つけることができますか？ 一部のサイトで改善が見られているように感じているので、否認した後です。 だから、繰り返しますが、私はそれが常にあることを知っています-それは決して白黒ではありません。

回答17 :03-それは間違いなく当てはまります。 ですから、私たちのアルゴリズムを見ると、ここでは非常に悪いリンクがたくさんあることがわかります。ウェブサイトの一般的なリンクに関しては、もう少し慎重になるかもしれません。 したがって、それをクリーンアップすると、アルゴリズムがそれを調べて、「ああ、ある種の」と言います。それで問題ありません。 悪くない。

質問17 :24-手動操作を防ぐためだけに基本的に否認するのは良いことですよね？

回答17 :29 -Webスパムチームが現在の状況に基づいて手動で対応することが本当に明らかな場合は、それを否認します。

質問17:37-それで、グーグルのように考えるのは良いことです-グーグルスパムチームの誰かが、これを見たらどうするかと思うように。

回答17:47-ええ。

質問17:48-しかし、問題はほとんどの人が知らないということです。 つまり、平均的なビジネスオーナーは、Webスパムチームがどのリンクを使用するかを知りません。つまり、ガイドラインはありますが、それは非常に重要です。それらを解釈するのは困難です。 つまり、私にはいくつかの懸念がありますが、私の主な懸念は、リンク監査に莫大なお金を費やしている人々がいて、それだけの価値はないと思うことです。 一方で、リンク監査を行っておらず、その恩恵を受ける可能性のある一部のサイトを否認している可能性があります。 ですから、私はあなたが言ったことは私たちがそうするのに大いに役立ったと思います-あなたが知っている、それは良いことです。

回答18 :22-ええ、大多数のサイトでは、過去にいくつかの悪いアドバイスに従ったようなものが通常の組み合わせであり、先に進んだようなものであり、今ではかなり自然なことだと思います。そうすれば彼らは本当にそれをする必要はありません。 これがすべての目標の一種であり、そのため、否認ツールは検索コンソールの主な機能とは異なります。 明示的に探します。 ほとんどのサイトでは、リンクにそれほど集中する必要がないため、これはすべて意図的に行われます。 でも、否認ツールについて私が好きなのは、これについて心配している場合でも、そこに行って、「OK」のようになることができるということです。前に、そして私はそれについて本当に心配しています。 そうすれば、私の観点からは、それらを否認することは問題ではありません。 私は外に出て、具体的にそのすべてのものを検索することはしませんでした。 しかし、あなたがそれについて知っていて、あなたがそれについて本当に心配しているなら、あなたはそれの世話をすることができます。

質問19:27-クライアントのWebサイトの1つについて質問があります。 つまり、彼らはクラブを持っています-彼らはニューサウスウェールズ州の3つの都市にクラブを持っています。 また、各クラブのWebサイトにはサブドメインがあります。 これで、Webサイトにページを追加すると、サブドメインごとにページが作成されます。 最近、彼らはクラブの活動に関するページを追加し、このページをすべてのサブドメインに追加しました。 つまり、ページのタイトルが異なることを除いて、すべてのサブドメインが同じコンテンツを持っていることを意味します。 シドニーの--に追加するときに、タイトルタグに場所の名前を追加するためです。 Newcastleに追加すると、タイトルタグにNewcastleが追加されますが、ページの残りのコンテンツは同じです。 それでは、50のサブドメインがあり、タイトル以外は同じコンテンツを持つ50のページが作成されているため、問題になるのでしょうか。

回答20:36-それは少し非効率的なことのように聞こえます、私は推測します。 つまり、あなたはすでにそれを持ち出していると言っているようなものです、これは別の方法で行うことができる何かのようです。 同じコンテンツを持つサブドメインが50個あり、タイトルタグを変更するだけの場合は、本当に役立つコンテンツをたくさん提供していない可能性があります。 つまり、それは私が言う状況です。さらに多くのサブドメインにわたって物事を薄めるよりも、物事を組み合わせて本当に強力なページを作成する方が理にかなっています。

質問21:44-1つのページを作成してから、他の場所のページへの正規URLを使用するのはどうですか。 1つのページを作成して、そのアクティビティについて説明します。このリンクを、他の場所のページへの正規URLとして使用します。

回答22:10-場所-ええ。 あなたは再び物事を組み合わせているので、それは理にかなっていると思います。 次に、一連の希薄なページではなく、1つの強力なページを作成します。

質問22 :20-誰かがWebサイトにアクセスし、場所を選択するとどうなるかという理由で、特定の場所を指定したサブドメインにその人を自動的にリダイレクトします。 そのため、そのサブドメインにページが必要です。 そのため、1ページを保持し、正規URLを追加すると、現時点で唯一の選択肢になります。

回答23:08-わかりました。ただし、サイトに技術的な理由でページを追加する必要がある個別のページがあり、正規のページを配置する場合は、それが良いアプローチだと思います。

質問23:21-それは次のようになります-異なる場所に複数のフランチャイズがあり、フランチャイズごとに本質的に同じコンテンツを持つビジネスは、異なる都市や町などにあり、あなたからの漏斗のようなものです視点を1ページに戻しますか？

回答23:34-特定の場所でその種のビジネスを探している人々と、そのビジネスに関するある種の情報ページを直接バランスさせるため、これは常に少し注意が必要だと思います。 ですから、それはビジネスのためにそれを分離することが時々理にかなっている何かです。 ある種の一般的な情報を中央の場所に置き、同じようにすることが理にかなっている場合があります。たとえば、住所や営業時間などに焦点を当てた場所のランディングページなどです。

質問24 :12-ええ、私は-あなたが言っていた標準的なポイントに関して、関連する質問があります。 これは私のチームと私が何年もの間持っていた質問です。 そして、私たちはまだ解決策を正確に知りません。 したがって、多数の製品と多数のカテゴリを含む大規模なeコマースサイトを扱っている場合。 たとえば、さまざまなフィルタやファセットがあり、ページのコンテンツをわずかに変更するような性質のものがありますが、独自のURLを持つことを正当化するには不十分なカテゴリページを使用しているとします。 ただし、特定のフィルターを使用する場合は、サイトのURLを使用することを正当化する場合があります。 では、そのような状況でクロールをどのように処理しますか？ 正規タグは機能しますか？ インデックスが作成された1つのページを作成するだけの包括的なソリューションですか？ または、特定のファセットやフィルターのインデックスを作成しない、またはロボットを使用する、または大規模なeコマースサイトでそれをどのように制御するかを確認する必要がありますか？

回答24:57-それは注意が必要です。 現時点では、それについて明確なガイダンスはないと思います。 つまり、これらのさまざまな種類の方法すべてが理にかなっているのです。 一般的に、私はそのためにrobots.txtを使用しないようにしています。なぜなら、発生する可能性があるのはURLを見つけることだからです。 何があるのか​​わかりません。 したがって、サーバーに過度の負荷をかけている問題が実際に発生していない限り、インデックスなし、relcanonicalなどを使用するようにしています。 たぶん、robots.txtを使用するのではなく、ある種の目標到達プロセスへの内部リンクでrel no-followを使用して、インデックスをクロールする必要があるものを少し明確にします。 しかし、いつインデックスレベルのページに結合するか、いつインデックス作成をブロックするか、いつ1つの正規URLのようにソフトにガイドするかについての決定は、非常に難しい場合があります。

質問25:53-ページの内容があまりにも異なる場合、カノニカルが無視されることがあるため。

回答25:57-その通りです。 内容が異なる場合は、まあ、これらは異なるページであると言えます。 カノニカルは使用しないでください。 あなたが言うかもしれないが、まあ、これは本当に私が索引付けしたくないものです。 たぶん、インデックスなしは、正規のものよりも理にかなっているでしょう。 両方を組み合わせることもできます。 言うのは本当に難しいので、それらを組み合わせることはお勧めしません、まあ、どういう意味ですか？ これらは同じだと言っていますが、1つはインデックス可能で、もう1つはインデックス化できないので、同じではありません。 しかし、それは私が一年の間に何がそこで働くことができるかについてのいくつかの明確なガイダンスを持っていると私が想像する何かです。 しかし、特に非常に大規模なeコマースサイトでは、クロール側が非常に困難になる可能性があります。

質問26:46-最近、数人の顧客と一緒に理解しようとしているシナリオがあります。 私たちは、HTTPをまだ使用しているサイトを本質的にジャンクできず、ページがしばらく更新されておらず、コンテンツが古く、古く、一般的に見捨てられているように見える理由を解明しようとしています。ちょっと薄いので、私はそれについていくつかの理論を持っています。 その一部は、おそらく、それがインデックスに含まれているので、すべての種類の信頼係数が構築されていることだと思います。 そして、それらを外すのはちょっと難しいです。 That's part of my theory on that. So I'm just trying to figure out what's going on because I know HTTPS is a factor. I don't know how much of a factor it can be, but I also think the age might be part of the problem of trying to provide that newer, fresher content that-- in most cases, what we have done over last year is a lot more thorough than what was written, say 10, 12 years ago. So we're trying to figure out why is it taking so long to essentially move ahead of those pages in a lot of cases.

Answer 27:46 - So HTTPS is a ranking factor for us. But it's really kind of a soft ranking factor. It's really a small thing.

Question 27:55 - One of the things I've noticed about when I encounter sites that are still using HTTP is they haven't really-- they haven't been updated, in general, in two or three years, usually. So to me, it's kind of like they've almost been abandoned. To me I'm looking at it as a signal of freshness and stuff like that.

Answer 28:10 - Yeah, I mean, freshness is always an interesting one, because it's something that we don't always use. Because sometimes it makes sense to show people content that has been established. If they're looking at kind of long-term research, then like some of this stuff just hasn't changed for 10, 20 years.

Question 28:30 - I'll give you a pragmatic examples since I'm a web developer. I see pages that were written, say in 2006 or 2007. They haven't actually been changed, but the web standards, web specifications, or just the general way of handling those things has evolved. But that page is still written as if it's 2006. And yet I've got something that's fresher, you know, that's more in depth and things like that, and I'm like at number 11. They're sitting at number four, for example, like, why are they still up there, you know?

Answer 28:59 - Yeah. It's hard to say without looking at the specific cases. But it can really be the case that sometimes we just have content that looks to us like it remains to be relevant. And sometimes this content is relevant for a longer time. I think it's tricky when things have actually moved on, and these pages just have built up so much kind of trust, and links, and all of the kind of other signals over the years, where like, well, it seems like a good reference page. But we don't realize that, actually, other pages have kind of moved on and become kind of more relevant. So I think long-term, we would probably pick that up. But it might take a while.

I don't know if we call it trust or anything crazy like that. It's more-- it feels more like we just have so many signals associated with these pages, and it's not that-- like, if they were to change, they would disappear from rankings. It's more, well, they've been around. They're not doing things clearly wrong or for as long time, and people are maybe still referring to them, still linking to them. Maybe they're kind of misled in kind of linking to them because they don't realize that, actually, the web has moved on. Or maybe, I don't know, a new PHP version came out, and the old content isn't as relevant anymore. But everyone is still linking to, I don't know, version 3 or whatever.

Question 30:42 - But I've also seen that kind of in the health and fitness space as well, you know, like workout types were more popular 10 years ago, but the particular, you know, approach to it isn't necessarily as popular now or been kind of proven to not necessarily be as good. You know, it's just some other general observations I've made too.

Answer 31:06 - Yeah, I think it's always tricky because we do try to find a balance between kind of showing evergreen content that's been around and kind of being seeing more as reference content and kind of the fresher content and especially when we can tell that people are looking for the fresher content. But we'll try to shift that as well. So it's not something that would always be the same.

Question 32:20 - "We have a large e-commerce site that's not in the mobile-first index yet. We know we serve different HTML for the same URL, depending on the user agent. Could this harm us?

Answer 32:38 - So you don't have a ranking bonus for being in the mobile-first index. So it's not that you need to be in there. But it's more a matter of when we can tell that a site is ready for the mobile-first index, then we'll try to shift it over. And at the moment, it's not at the stage where we'd say, we're like flagging sites with problems and telling them to fix things. But more where we're just trying to get up to the current status and say, OK, we've moved all of the sites over that we think are ready for mobile-first indexing. And kind of as a next step, we'll trying to figure out the problems that people are still having and let them know about these issues so that they can resolve them for mobile-first indexing. So it's not that there is any kind of mobile-first indexing bonus that's out there. It's more that we're, step by step, trying to figure out what the actual good criteria should be.

Question 33:40 - Given that the search quality guidelines are an indication of where Google wants its algorithm to go, how does the current algorithm handle measuring the expertise and credibility of publishers?

Answer 33:59 - I don't know. I think that's probably hard to kind of figure out algorithmically. And if there were any kind of technical things that you should do, then we would let you know. So if there are things like authorship markup that we had at some points that we think would be useful for something like this, we would definitely bring that out there. But a lot of things are really more kind of soft quality factors that we try to figure out, and it's not something technical that you're either doing or not doing. It's more, like, trying to figure it out how a user might look at this. So not anything specific that I could point at.

Question 34:44 - Is that reasonable to assume that if something is in the Quality Raters' Guidelines that Google-- I mean, that's what Ben Gomes said, right? That's where the Google wants the algorithm to go. So I mean, we may be guilty putting too much emphasis on the Quality Raters' Guidelines, but it's all good stuff in there, right? So is it reasonable to make that assumption? Like, if it's in there, we should aim for that sort of standard of quality?

Answer 35:09 - I think, in general, it's probably good practice to aim for that. I avoid trying to focus too much on what Google might use as an algorithmic factor and look at it more as-- we think this is good for the web, and, therefore, we will try to kind of go in that direction and do these kind of things. So not so much it's like I'm making a good website just so that I can rank better, but I'm making a good website because when I do show up in search, I want people to have a good experience. And then they'll come back to my website, and maybe they'll buy something. So that's kind of the direction I would see that, not as, like, do this in order to rank, but do this in order to kind of have a healthy, long-term relationship on the web.

Question 36:10 - Is there a particular type of schema that is more likely to obtain featured snippets of voice search results?

Answer 36:18 - I don't know. I can't think of anything offhand. So there is the speakable markup that you can use, which is probably reasonable to-- kind of look into to see where it could make sense on a page. I don't think we'll use that in all locations yet.

Question 36:41 - Is that the goal to us it in more locations?

Answer 36:47 - I believe-- I guess. I mean, it's always a bit tricky because, sometimes, we try them out in one location, and we try to refine it over time. And usually, that means we roll it out in the US, and where we can kind of process the feedback fairly quickly, we can look to see how it works, how sites start implementing it or not. And based on that, we can refine things and say, OK, we're doing this in other countries, and other languages, and taking it from there. But it's not always the case that that happens. Sometimes it happens that we keep it in the US for a couple of years, and then we just said, oh, actually, this didn't pan out the way that we wanted it. So we'll try something new, or we'll give it up. Yeah. But a lot of the structured data types, we do try to roll out in other countries, other languages. I imagine the speakable markup is tricky with regards to the language. So that's something more where we'd say, well, Google Assistant isn't available in these languages. So, like, why do we care what markup is actually used there.

I don't know how many places this system is available yet. Maybe that's everywhere now. But featured snippets, in particular, I don't think we have any type of markup that's specific to that. So that's something where if you have clear kind of structure on the page, that helps us a lot. If we can recognize like tables on a page, then we can pull that out a lot easier. Whereas if you use fancy HTML and CSS to make it look like a table, but it's not actually a table, then that's a lot harder for us to pull out.

Question 38:37 - John, do internal links help with featured snippets if you have an anchor? Sorry, not an internal, like, an anchor like-- do you think that that would help?

Answer 38:48 - I don't know. I do know we sometimes show those anchor links in search as a sub site link-type thing. But I don't know if that would work for featured snippets.

Question 39:04 - Does cross domain site map submissions still work when 301 redirecting to an external sitemap file URL?

Answer 39:16 - Hopefully.

Question 39:17 - What about using meta-refresh? This was something that was recommended by a video hosting company. People said, we'll host the site map on our site, but, you know, the XML file will metarefresh over to our site where all the links are located.

Answer 39:33 - I don't think that would work. So sitemap files are XML files, and we process those kind of directly.

So if you do something that's more like a JavaScript redirect or that uses JavaScript to get us the sitemap content, then that would work. It would really need to be a server-side redirect. What you can also do is use the robots.txt file to specify a sitemap file on a different host. That also confirms to us that actually you told us specifically to use a sitemap file from there. So I probably use something like that more than any kind of a redirect. I imagine the 301 server-side redirect would work. But, no, I don't know, you should be able to see some of that in Search Console too, like, if we're picking the sitemap up in the index composition tool, you can pick the sitemap file, then that's a pretty clear sign that we can process that.

質問42:29-それは旅行のための旅行代理店のウェブサイトについてでした。 検索都市で最も安いホテルトップ10のように、動的コンテンツを表示するために内部検索を選択します。 したがって、ページフレームは瞬時に読み込まれます。 ただし、検索が実行されてから30秒以内に、最も安いホテルの上位10件の結果が動的に読み込まれます。これは、ウェブサイトがこの検索を後ろで実行し、結果を比較して絞り込んで、検索者に最も安い上位10件をリストする必要があるためです。ホテル。 したがって、それらをリストするのに少し時間がかかります。 そのため、現在、Googlebotはページの背景のみを認識しています。 次に、これらの10個の空のプレースホルダーは、内部検索が実行された後、結果が少し遅れて読み込まれる場所でした。 これは旅行ウェブサイトが可能な限り新鮮で正確な情報を提供する傾向であるため、Googleがこれについて何をしているのかを考えています。 もちろん、私がそう言うかもしれないが、他のすべてのウェブサイトが今日グーグルのために行っているように、これらのページにいくつかの静的コンテンツをリストすることができます。 しかし、そのようなものは、ほとんどのユーザーが今見たいもの、新鮮で安価なものについての目的を打ち破ります。

回答44:00-したがって、そこにロードされない場合、インデックスを作成することはできません。 しかし、通常、それはJavaScriptを処理できないか、JavaScriptのコンテンツに実際にアクセスすることをブロックされているという問題です。 だから、それはあなたがうまくいく方法でできることです。 それが決して機能しないのは設計によるものではありません。 これは、モバイルフレンドリーテストなどを使用して詳細を掘り下げ、JavaScriptエラーが含まれているかどうか、ブロックされているかどうかを確認し、そこから改良することができるものです。 したがって、それは不可能ではありませんが、少し手間がかかります。

質問44:42-ジョン、私はグーグルから何もブロックされていないことを確認してそれを掘り下げます。 Googleに実行してほしいのは、動的コンテンツがページに読み込まれるのを少し待つことだけです。 これは次のステップです。このページは無限のスクロールのようなものではありませんが、たとえばFacebookの場合、結果は10ページに制限されています。 だからそれは有限です。 限られています。 問題は、Googleが動的コンテンツを少し待つ必要があるということです。 私はあなたに例を与えるだけです。 しかし、野生には他にもたくさんの例があると確信しています。 そして、これは人々がどういうわけか物事を分類し、時間がますます少なくなるために動的コンテンツを見る傾向があるため、人々はウェブサイトに費やす時間がますます少なくなり、できるだけ早く見つけたいと思っています私がそう言うかもしれないなら、完璧な結果。 皆さんがこの機能強化に目を向けているのではないかと思いました。

回答45:55-レンダリングを少し待ちます。 しかし、人々がせっかちであるならば、それはあなたがとにかくより速くあるべきであるというサインです。 とにかくそれを調べるところです。 しかし、スクリーンショットを見ると、そこにあるすべてのアイテムが灰色のボックスでブロックされているように思います。 ですから、それはおそらく単なるタイムアウトというよりも、技術的な問題のように感じます。

MARTIN SPLITT ：うん。 たとえば、JavaScriptなどを使用している場合でも、問題なくインデックスに登録される動的コンテンツがたくさん見られます。 したがって、タイムアウトになると、検索にかかる時間の点で問題が発生する可能性があり、それは実際には他の場所にも反映される可能性があります。 コンテンツが終了するまでしばらく待ちます。

質問46 :48-できますか-時間枠を教えていただけますか？ どれくらい待ちますか？

MARTIN SPLITT ：それは本当に、本当にトリッキーです。なぜなら、基本的に-つまり、時間枠を提供できない理由は、時間のためです-そして、これは本当に奇妙に聞こえるでしょう、そして私に少し耐えてください。 Googlebotsレンダリングの時間は特別であり、必ずしもアインシュタインの原則に従うとは限りません。 [笑い]それで、私はあまり多くを言うことができません。 私が言えることは、ネットワークがビジーで、ネットワークがボトルネックである場合、私たちはおそらく待っていますが、私たちはそれほど長く待つだけです。 したがって、1分または30秒ほどかかる場合は、おそらくその間にタイムアウトになります。 しかし、難しいことはありません。10秒と言えば、うまくいくかもしれませんし、うまくいかないかもしれません。 30秒と言えば、うまくいくかもしれないし、うまくいかないかもしれません。 だから私はむしろ数字を言いたくない。 私が言いたいのは、できるだけ早くそれを取り入れるようにしてください。 また、すばやく取得できない場合は、検索結果をキャッシュして、検索が多かれ少なかれ、またはページ上で結果を生成することが多かれ少なかれ瞬時になるようにしてみてください。 または、この回避策となる可能性のある動的レンダリングを自分の側で試してください。 また、サーバー側に配置して、基本的に最初のパスでできるだけ多くのコンテンツを生成するようにすることもできます。 これは、特に低速のネットワークを使用している場合に、ユーザーにもメリットがあります。 そうそう。 申し訳ありませんが、簡単な答えはありませんが、Googlebotでの時間はファンキーです。

回答49:29-おそらくウェブサイトが実際に何をしているのかによると思います。 レンダリングの速度で注意が必要なことの1つは、サーバーから送信される多くのものをブラウザーよりも多くキャッシュできることです。これは、これらの多くにインデックスを使用できるためです。 そのため、JavaScriptが私たちの側でキャッシュされている場合は、それをフェッチする必要がない場合があります。 次に、時間をもう一度比較すると、ユーザーに表示されるものとは一致しません。 webpagetest.orgに表示されるものとは一致しません。 ですから、これは本当にトリッキーです。時間がかかることがわかっている部分については、もう少し辛抱強くなります。 しかし、テストするのは難しいです。 そのため、これらのテストツールはすべて、可能な限り多くのエラーを表示して、まったく機能しないかどうかを判断できるようになっています。 それは時々機能しますか、そして時々どこで問題が発生しますか？

質問50:29-非常に大規模なWebサイトの場合、XMLサイトマップ内のURLの順序は重要ですか？

回答50:34-いいえ。私たちは気にしません。 これはXMLファイルです。 すべてのデータを取得します。 一度に処理します。

質問50:44-では、サイトマップの優先度パラメータについてはどうでしょうか。

回答50:47-私たちはそれをまったく使用していません。 これは、最初は、ページをクロールする頻度を把握するのに役立つかもしれないと考えていました。 しかし、ウェブマスターに聞いてみると、彼らはまるで、すべてが優先事項であることがわかります。 それが最も重要です。 また、サイトマップの変更頻度も同様です。たとえば、人々は常に変化しているように言っていますが、最後に更新されたのは昨年です。 したがって、変更の頻度と日付があれば、とにかく日付からその情報を取得します。 したがって、変更頻度は無視します。
質問51:35-企業スキーマをホームページ、連絡先ページ、またはすべてのページに追加する必要がありますか？

回答51:42-私が知る限り、それは単なるホームページです。 知らない。 知っている人はいますか？

リズ51：4からの回答7-通常、組織と企業の1ページだけであると想定されています。 それは一般的に推奨事項です。

MARTIN SPLITT 52:00-どちらでも構いません-持っているすべてのページに配置しないのと同じように、どのページでも構いません。もっと重要なことだと思います。 ニュースサイトの場合は、連絡先ページや概要ページなどに配置するのが理にかなっていると思います。 ショップやレストランのウェブサイトでは、ホームページに載せても大丈夫でしょう。

ヨハネ52:20-この場合も、ホームページや連絡先ページのような場所で見つけることができる必要があるので、私たちにとってはそれほど重要ではないと思います。 しかし、他の場所にある場合でも、何も変わりません。 したがって、比較しない大きな点は、レビューマークアップです。このマークアップでは、サイトのすべてのページの星と検索結果を取得することを期待して、Webサイトのすべてのページに会社のレビューのように表示されることがあります。 そして、それは私たちにとって悪いことです。 しかし、連絡先情報をマークアップしている場合は、それは-問題はありません。
質問53:05-私たちが使用しているGoogleWebサイトの速度テストでは、ページの読み込み時間が非常に遅くなっていますが、海外の同僚と行った独立したテストでは、ページの読み込み時間が非常に速いことがわかりました。 この誤った記録によるGoogleの測定値は、Googleアルゴリズムでのサイトのランク付けに影響しますか？

マリー・ヘインズ：それは私の質問ではありませんが、コンテキストを与えるために、ページ速度の新しいLighthouseデータは、PageSpeedInsightsが以前よりもはるかに厳しいものです。 したがって、Page Speed Insightsでスコアが80のようなものは、Lighthouseでは赤の29になる可能性があります。 いい質問ですね。 モバイルでは、非常に遅いサイトが降格される可能性があることがわかっているため、これが原因である可能性があります。 それで、灯台テストで赤字になっている場合、降格を引き起こす可能性があるため、本当に改善する必要があると言ってもいいですか、それともカットオフがありますか？

回答54:07-したがって、外部ツールの1対1のマッピングはなく、ソーシャルに使用するすべてのものがあります。 ええ、それは本当に言うのが難しいですが、検索では、実際の、それが何であるか、LighthouseテストのようなラボテストデータとChromeUXレポートデータを組み合わせて使用​​しようとします。私たちが測定しているのは、ウェブサイトのユーザーに表示されるものです。

MARTIN SPLITT 55:37-たとえば、Lighthouseが中央値側の3G接続を具体的に測定していることを確認することも重要です。つまり、中性能の電話のようです。 したがって、基本的に、最近のApple McIntoshまたは最近の高速Windowsコンピュータを使用していて、オフィスで有線接続やWi-Fi接続のように非常に優れている場合は、もちろん、読み込み時間は2秒ですが、自分の携帯電話を実際に持っている実際のユーザーは、おそらくそれを見ていません。 したがって、ウェブサイトを高速化することは決して害にならないようなケースの1つですが、これは、必ずしも1つをマッピングしていない非常に具体的なメトリックを使用しているため、内部の観点からどのように見えるかを言うのは本当に難しいです。ツールが公開しているものの1つ....もちろん、ユーザーがWebサイトを永遠に待つことを望まないため、これを修正することが重要です。 それはあなたを傷つけるでしょう。 それはあなたのユーザーを傷つけるでしょう。 それは検索であなたを傷つけるでしょう。 しかし、私はお金を払っていません-私はただツールを見ると言うでしょう。 ツールがあなたがうまくやっているとあなたに言っているなら、あなたはそれについてあまり心配するべきではありません。 ツールがあなたが本当に良くないことをしているとあなたに言っているなら、私はそれがなぜ言うのかを理解するのに費やされた時間だと思います-例えば、それが言うことが関連しているなら、それは無駄です。 むしろ、サイトを高速化することを検討する必要があります。

モバイルのパフォーマンスは、ユーザーだけでなく他のすべてにとっても非常に重要な要素です。 だから私はあなたのウェブサイトが実際の条件でうまく機能することを確認すると思います。 たぶん、安い電話を手に入れて、時々ウェブサイトを試してみてください。そうすれば、それは私がやりたいことであり、私が一緒に働いていた開発チームと一緒にGoogleに参加する前はそうしていました。 私は、この電話でこのWebサイトを使用しますか？ ああ、これはひどいようなものでした。 私は、うーん、そうだね、だから多分私たちはそれについて何かをすべきだろう。

JOHN-Chromeでは、設定してさまざまな接続速度を試すことができます。 モバイルエミュレータ。 それは本当に良いことだと思います。また、ユーザーベースも見てください。 人々がハイエンドのiPhoneでのみあなたのウェブサイトを使用していることがわかっている場合は、分析データを見てください。おそらく、人々がランダムな地方の接続からサイトに接続していることを確認している場合よりも問題は少ないでしょう。遅く、そして彼らはローエンドのデバイスを持っています、そして多分それはもっと多いです。