Chris Green によるエッジでの SEO について知っておくべき 5 つのこと

公開: 2022-08-10

今日は、コーヒーやウィスキーをすすりながら思慮深くあごひげを掻くのを楽しむ縄跳びを使ってエッジでより多くのビジネスを行うことによって、SEO ライフの質を向上させる方法を見ていきます。おそらく理想的には、アイリッシュコーヒーです。彼は検索問題のトレーナーであり、スピーカーであり、ソルバーでもあります。 In Search SEO ポッドキャスト、シニア SEO コンサルタント、Chris Green へようこそ。

5 つのタスクは次のとおりです。

分割テスト
リダイレクト管理
ボットアクセスロギング
サイトマップ構築・管理
コンテンツの挿入

クリス：私を迎えてくれてありがとう、デビッド。

D: chris-green.net で Chris を見つけることができます。それで、クリス、あなたはそれを聞いていませんが、あなたはいつも危機に瀕していますか?

セ：わかりません。何十年も SEO を行ってきた人は、少し緊張していると思います。簡単に言えば、イエスです。長い答えは、場合によって異なります。待ってください、それは別の短い答えです。私はペンギンとパンダが動き始めた頃に SEO を始めました。正直に言うと、そこから回復したことはないと思います。

D: かなり前にエッジについておしゃべりしたのを覚えています。あなたは確かに、このトピックに関する著名な思想家の 1 人です。ですから、これについて議論するためにあなたがいるのは素晴らしいことです. そして今日は、エッジでより適切に処理できる 5 つの SEO タスクを共有します。最初に、SEO 分割テストから始めます。

1.SEOスプリットテスト

C: つまり、SEO 内でのテストがようやく少し増えました。また、SEO をテストする方法は複数あります。SEO を実際に簡単にデプロイして、Analytics でチェックして、機能したか、機能しなかったかなどです。これは、理論上、SEO に携わる私たち全員が行うべき最も簡単な方法です。しかし、「エッジ」が機能する方法は、グループ内のページの 50% に効果的に変更を展開し、Google がテストページにアクセスし、次にコントロール/変更されていないページにアクセスできるようにすることです。実際にコードベースを変更したり、サーバーや CMS に追加の要件を追加したりすることです。これは、これらのページにさまざまなバージョンを表示するという別のレイヤーを追加するようなもので、プロセスのさまざまな時点で実行できます。

そのため、エッジにより、サーバーから送信されたかのように見えます。これは、Google がそれを単なるコードであるかのように取得するため、インデックス作成に最適です。クライアントでこのテストを行うこともできます。したがって、基本的に信頼性が低い JavaScript を使用することで機能しますが、Google に重点を置いています。そのため、エッジによって処理が速くなり、得られる結果がより信頼できるものになります。完璧ではありませんが、はるかに優れており、より堅牢です。

D: では、ほとんどの SEO は独自のスクリプトを考え出すか、単純なスクリプトを使用してこれらの分割テストを実行しますか? または、エッジと組み合わせて使用することをお勧めする専門のスプリットテストソフトウェアはありますか?

C: 崇高なものからばかげたものまで行くことができます。エッジについて話しているだけなら、確立されたスペースにはおそらく一握りのプレーヤーがいると思います. そのため、正式には ODN である Search Pilot は、文字通りエッジインフラストラクチャ上に構築されています。彼らは、それらすべてを制御できるメタ CMS を構築しました。そして、その上に、非常にスマートな分析と分析方法論をすべて取り入れました。これを所有または開始することについて、私はまったく主張できません。それからはほど遠い。彼らは最大のパイオニアの一部です。しかし、さまざまな種類のエッジインフラストラクチャ (Akamai、Cloudflare、Fastly) のエッジでできることは、スクリプトを自分で作成できることです。エッジについて話している場合、これらのテストを実行するために必要なのは、コントロールページとなるページ、つまりテストとなるページです。そして、テストバージョンに効果的に変更を加えるスクリプトです。そして、その複雑さは、テストがどれほど複雑かによって異なります。たとえば、ページタイトルを書き換えるだけの場合、これは非常に簡単な作業になります。私はエンジニアではありません。私は時々自分の利益のためにうるさすぎるSEOですが、これらのこと、特にCloudflareでは、おそらく最もアクセスしやすい要素の1つです. 私自身とサイモン・トンプソンは何年も前に、ツール・スパークと呼ばれるエージェンシーが構築したツールを使用していましたが、それはベータ版であり、コンセプトの証明であることが判明しました。しかし、それは Cloudflare のインフラストラクチャの上にありました。繰り返しになりますが、その時点では本質的に無料でエッジに分割テストを展開できますが、それはサンドボックスのようなものになってしまいました. そのため、エンタープライズレベルのソフトウェアをそのまま使用して、独自のソフトウェアを構築できます。そして、これを実行できる新しいプラットフォームがいくつかあります。しかし、SEO として、自分が構築しているスタックとは何かを考える必要があると思います。他に誰を参加させる必要がありますか? リスクを軽減する必要があり、権利を公開して履歴を変更する必要がある場合は、エンタープライズオプションを選択します。ブートストラップされているが、本当にテストしたい人がいる場合は、エッジでまっすぐに構築してください。労働者向けのコードを書ける人を見つければ、何かをテストできます。

D: エッジでの分割テストについて 3 時間ほど話せた気がします。しかし、エッジでより優れた効果的なものとして推奨される 2 番目の領域であるリダイレクト管理に移りましょう。

2. リダイレクト管理

C: ええ、通常、リダイレクトの管理は大変です。なぜなら、大規模な Web サイトや多数の異なるインフラストラクチャがある場合、さまざまなリダイレクトがどこで制御および管理されているか、どのような順序で起動されるか、それらが複雑かどうかなどを把握するのは悪夢だからです。 . そして事実上、すべての大企業がその問題を抱えています。そして、大きな問題の 1 つは、1 回のリダイレクトアクションで異なるサーバー間または異なる CDN レイヤー間を人が行き来することであり、これは非効率的です。したがって、CDN を経由してサーバーに移動すると、サーバーは別の場所に移動する必要があると言い、別の場所に移動すると別の場所にリダイレクトされます。これは非常に効率が悪く、コストがかかり、管理する悪夢。

現在、CDN またはエッジが置かれている場所のために、ユーザーが最初に遭遇するのはそれです。そこですべてのリダイレクトを管理し、その時点で変更を平坦化することを確認すると、比較的簡単に実行できます...まず、リダイレクトの数を減らすことができます。第 2 に、リダイレクトされる前にオリジンサーバーに到達しません。したがって、実際にはオリジンへのトラフィックのレベルを下げると、そのサーバーから直接、リダイレクトがはるかに迅速に行われます。最後に、規律があり、それを正しく実装していれば、異なるプラットフォームに関係なく、すべてのリダイレクトを確認する必要がある場所が 1 か所だけになります。そして、そのシンプルさは、チームに規律を植え付けるとき、正直に言うと少し簡単になります.

D: 3 つ目は、ボットのアクセスログです。

3. ボットアクセスロギング

C: ボットアクセスロギングは興味深いものです。ログファイルの監査を試みたことがあり、分析を行うにはアクセスログが必要だと言った場合は、DevOps などに行くと、彼らはあなたに困惑した様子を見せるか、次のように言うでしょう。いいえ、それは大きすぎます。保存しないか、1 日分を保存します。または、お持ちいただけますが、長い列にお並びください。それは本当に挑戦的です。さらに、キャッシングで CDN を実行している場合、サーバーアクセスログがすべてのボットトラフィックを受信しない可能性があります。したがって、ログは完全ではありません。 CDN を通過するものはすべて、キャッシュされているかどうかに関係なく、すべてのトラフィックによって取得されます。また、エッジを使用してこのログデータを効果的に保存し、それを Sumo ロジックや別の種類のストレージなどのサービスにストリーミングする場合は、そのデータを見つけようとするのではなく、エッジですべて吸い上げる機会があります。あなたのサーバーから。しかし、その時点で正しい種類の論理的根拠またはロジックでワーカーを作成している場合は、必要なボットトラフィックのみをキャプチャするように設定できます。通常は Googlebot や検索エンジンボットですが、IP アドレスを検証して、なりすましではないことを確認したり、必要なアクセスデータのみを収集したりして、ストレージスペースを大幅に削減することができます。たとえば、Content King などの一部のツールは、一部の CDN と直接やり取りして、そのレベルから直接データを収集できます。したがって、適切なレベルのアクセス権があり、DevOps が「はい」と答えたと仮定すると、それらのログを直接収集し始めることができます。つまり、技術的な SEO 分析を比較的少ない労力で行うことができます。

D: ログファイルを確認するだけで価値がある、またはすべての SEO がログファイルを確認する必要があるページに関して、特定のサイズの Web サイトはありますか?

C: 経験則として、Web サイトが 10,000 ページ未満の場合、私はすぐにログに頼ったり調べたりしない傾向があります。主に、それらにアクセスすることは悪夢だからです。そのデータに簡単にアクセスでき、簡単に分析できれば…Deep Crawl のような大規模な SaaS クローラーはすべて、ログファイルを分析できます。そのデータを取得して分析できるなら、やってみましょう。しかし、ページ数が 10,000 ページ未満で、そのデータを取得するのが面倒だとしても、それほど動揺することはありません。ページ数は任意ですが、100 万以上のページがある場合、logfile には多くの情報と洞察が含まれており、それによっていくつかの優れた増分勝利が得られます。その下では、おそらくそれだけの価値はありません。 D: そして 4 番目に、エッジで実行するのがより効果的なタスク、サイトマップの構築/管理です。

4. サイトマップの構築・管理

C: これはユニークなものです。最近、いくつかのプロジェクトで、サイトマップの生成にさまざまなサービスやさまざまなシステムからページをプルする必要があり、時代遅れであり、機能せず、すべてを再構築するためのエンジニアリングが非常に困難であるなどでした。 SaaS クローラーから API データをプルするサービスを構築しました。インデックス可能なページを取り込み、エッジで XML サイトマップを構築し、そのエッジポイントでホストします。私たちはクローラーを効果的に使用して毎日サイトをクロールしており、毎日新しいサイトマップを構築および再生成し、エッジに公開しています. これは、サードパーティに追加の要件を課す、過度に設計されたソリューションだと言う人もいるかもしれません。私も同意しますが、場合によっては、他のコンテンツ API や他のサービスを要求せずに、単一の信頼できるサイトマップを 1 か所で作成することが非常に理にかなっています。データはクリーンではなく、フィルタリングが必要になることがよくあります。そして、エッジでホストするマイクロサービスを効果的に作成することは、はるかに安価で、はるかに速く、より堅牢でした. 明らかに、それに対する正しい答えは、最初から正しく構築することですが、それは単純に選択肢ではありませんでした。

D: 最初から正しく構築することについて話しています。 XML サイトマップの作成を自動化することに危険はありますか? あまりにも多くのゴミを含めるには？

子：はい。実際、それはどこでも起こることがわかりました。 CMS で作業したことがある場合は、サイトマップをクロールしてテストページを見たことがあるかもしれません。そこでは、誰かがいくつかのページを作成し、それをサイト構造に配置せず、そこにそのまま残しました。また、サイトマップを構築するロジックが、インデックス可能かどうか、およびこれらすべての他の要素とフィルターをチェックしていない場合でも、他の方法で公開される可能性があります。したがって、WordPress を使用している場合は、Yoast が多くの面倒な作業を行ってくれることを知っています。 WordPress は以前よりもコア部分で多くのことを行っていると思います。しかし、明らかに、Drupal のような CMS はそれを処理しません。また、他のさまざまな理由で、サイトマップに入れたくないページを人々が欲しがる場合もよくあります。繰り返しになりますが、それは、あなたがその上に乗っていることを確認しているだけであり、私が重要だと思うフィルターを構築していることです。ファンタジーでは、見られたくないだけのデータを Google にフィードしている可能性があります。しかし、繰り返しになりますが、エッジで行うことは、非常に迅速で軽量なソリューションです。

D: そして 5 番目はコンテンツの注入です。そこではどのような内容について話しているのですか？

5. コンテンツの挿入

C: Web およびデジタル指向のあらゆるもの。これは、エッジを使用してコンテンツを追加し、そのコンテンツがクライアントではなくサーバーからのものであるかのように見えるという意味で、分割テストと少し重複しています。たとえば、ブログに関するサブドメインまたはサブディレクトリの議論に関与したことがあり、ブログを適切なインフラストラクチャから引き出すことができない場合は、CDN を使用してコンテンツを効果的につなぎ合わせることができます。このシステムからヘッダーをプルしますが、そのシステムからブログコンテンツをプルします。そして、非常に迅速かつ効率的に実行できるエッジで。その多くはキャッシュされ、エッジでつなぎ合わされます。そして、それがユーザーに表示されるまでに、このハイブリッドコンテンツを 2 つの異なるシステムから効果的に取得しています。そして公平を期すために、それはオリジンでできることであり、適切な傾向と構築可能性を備えています. しかし、エッジでそれを行う場合、さまざまなシステムからプルすることはほとんど問題ではありません。引き込む必要があるものを明確に識別できる限り、それを効果的に行うためのコードを書くことができます。それは非常にパフォーマンスが高く、非常に迅速に行われ、必要なものが得られます。

D: 昔、フレームと PHP インクルードを使用してコンテンツを組み込んだことを覚えています。そして、どちらもこれを行うための非常に古い方法です。他のソースまたは他の Web サーバーからコンテンツを挿入することの欠点はありますか? それを行うことで潜在的なSEOのマイナス面はありますか?

C: 重要なのは、これらのアセットが他の URL で利用可能であり、それらにインデックスを付けることができる場合、固有のリスクがあるということです。自分がやろうとしていることを認識していれば、同様に簡単に防ぐことができます。場合によっては、あるページにヘッダーを配置し、別のページに本文を配置して同じページに表示するという従来のフレームセット方式ではなく、他のサービスからのデータフィードを使用してそれらをつなぎ合わせることができます。それを非常に簡単に構築して、それが起こらないようにすることができます。重要なのは、これら 2 つのソースからコンテンツを確実に受信し、確実にキャッシュする必要があることだと思います。エッジとより複雑なエンジニアリングタスクは、CDN が機能しなくなった場合に発生することが多いと思います。フォールバックとは何ですか? そして、その複雑さはさまざまです。あなたが大規模な組織で、99.99 のようなかなりのアップタイムが必要な場合は、他の CDN を構築してフォールバックできると思います。ただし、たとえば、CDN に依存してつなぎ合わせを行っている場合、CDN にいくつかの問題があり、それらのページの一部が機能しないことがあります。しかし、Cloudflare がダウンすると、インターネットの半分がダウンします。このような場合、問題は、混乱が解消された後に Google に来てもらい、後でもう一度確認してもらうための適切な対応を Google に提供しているのかということです。

エッジに関連するものは何でもそう思いますが、最大の不安は、このサードパーティサービスが失敗した場合にどうなるかということです。しかし、これは Web インフラストラクチャの悪夢です。自分のオフィスにサーバーを持っていても、それを保護することはできず、それについて満足しています. どう考えてもかなり古臭いです。しかし、ゼロリスクのホスティング方法はありません。他の人に転ぶことができます。したがって、デュアル CDN 戦略を持つことができます。あるレイヤーに Akamai を配置し、別のレイヤーに Fastly を配置することができます。 Akamai に障害が発生した場合、Fastly に渡されます。逆の場合も同様です。それは信じられないほど洗練されています。そして、それはエッジケースのエッジケースです。しかし、自分が何をしているのかを知っていて、それを正しく指定していれば、これらのほとんどを防ぐことができます。

D: 実際に 100% のアップタイムを保証する方法についてのウェビナーディスカッションパネルを期待しています。それは興味深いでしょう。

C: 可能性はあります。これまで以上に可能性があります。Cloudflare と Akamai、または Cloudflare と Fastly、Similarweb を組み合わせると、かなり近づくことができると思います。これは非常に興味深いことです。

D: では、パレートピクルスで締めくくりましょう。パレートは、20% の努力から 80% の結果を得ることができると言っています。適度な労力で信じられないほどの結果が得られる、お勧めの SEO アクティビティを 1 つ挙げてください。

The Pareto Pickle - 変更の公開

C: これは私のエッジリストに入るところだったのですが、完全ではなく、少しハッキーです。そのため、本質的にこれを好まない人もいますが、何かを成し遂げるためにエッジを使用します。そこで、Meta CMS について簡単に説明しました。これは、Search Pilot チームと John Avildsen が世界に示すのに役立ちましたが、エッジを使用して、そうでなければ開発キューでスタックする変更を公開できます。そして、それを完成させ、稼働させ、概念を証明し、技術的負債のリスクを無視し、煩わしい DevOps を少しの間無視するという考えは、どちらも要因であるためです。しかし、SEO のすべての価値は、それがライブであり、そのコンテンツが実行され、エッジがそれを短縮できることです。そして、それはきれいではありませんし、正しい方法でもありません。しかし、いくつかのコンテンツの変更をライブにプッシュすることは、代替案が 6 か月待っていてそれが実現しない場合に、キューを回避することで大きな成果をもたらします。

D: 私はあなたのホストである David Bain です。 Chris さん、In Search SEO ポッドキャストをご利用いただきありがとうございます。

C: 私を迎えてくれてありがとう、デビッド。

D: 聞いてくれてありがとう。以前のエピソードをすべてチェックして、rankranger.com でランクレンジャープラットフォームの無料トライアルにサインアップしてください。