Fastly で検索エンジンのランキング (SEO) を改善
SEO は曖昧な手法です。検索エンジンはベストの結果を表示することを目指し、他は皆何が「ベスト」なのかを理解しようとしています。わかっているのは、信頼性、スピード、セキュリティが大きな差を生み出すということです。Fastly ならお客様が検索結果トップに近づくお手伝いができます。
検索結果で上位になる上で最も重要なポイントは、間違いなくページの内容です。Fastly は通常、サイトの内容をお客様にお任せしていますが、まずは試してみるべきよくあるコンテンツの最適化を一部ご紹介しましょう。
重要単語を含める: 検索する際に人々が使用するであろう形式でコンテンツを説明する重要な単語を含めます。Siri や Alexa のような音声アシスタントに質問する際に使いそうな言葉も含めてください。この場合ちょっとした FAQ が最適です (実際に質問が「よくある質問！」ならば)。
マイクロデータを追加する: 自分のページにマイクロデータを追加し、人、会社、レシピなど関連するものをすべてマークアップします。詳しくは、schema.org (最近の情報で一番おもしろいのは事実確認用の ClaimReview です) をご確認ください。また、ソーシャルシェアリング用に pen Graph や、OpenGraph を採用していないネットワーク向けのマイクロデータ形式を入れても良いでしょう。
「スニペットバイト (興味を引くスニペット)」を作る:検索エンジンはコンテンツの小さな一部分を捕らえ、それがユーザーの質問に直接回答しうると判断すると検索結果の UI に直接表示します。短い文章は最も一般的なスニペットバイトですが、適切にフォーマットされていればリストやテーブルも抽出対象です。検索エンジンに自分の主要コンテンツを「盗む」ことを許すというのは逆効果に思えるかもしれませんが、クリックスルー率は上がりそうです。
長いページを記述する:検索ランキングアルゴリズムは、クローラーが他で見つけていない (つまり別サイトの単なる複製ではない) オリジナルの文章が記載された、より長くてより詳細なものを明らかに好んでいます。
LSI キーワードを入れる: 検索エンジンのオートコンプリートや「関連する検索」機能を利用する言葉、LSI キーワードを入れます。自分のサイトの重要単語をいくつか検索し、関連検索として勧められた結果を確認してみましょう。それが関連する場合はその単語を自分のページにも入れます。
サイトをレスポンシブ設計にする:検索クローラーはデスクトップとモバイルデバイスの両方でサイトを読み込むことがほとんどです。そしてどちらでも同じ内容が表示されることを期待しています。
著者名と公開日を記載する:出処を辿れるようにしておくことで評価が上がります。
ページにマイクロデータと完璧なサイズの文章を追加して「スニペットバイト」にします。
こういったことに関する詳細は SEO の専門家に尋ねるかオンラインに多数ある素晴らしいガイド (やたら見つかります) を確認してください。 上記のアドバイスの大半は Backlinko のガイドにも記載されています。素晴らしいことですね。
検索順位を決定する上で重要だけれど、皆さんが直接は影響を与えられないことに、次のようなものがあります。
滞在時間: Google の RankBrain システムでは、ユーザーがクリックしてサイトに入り検索結果ページにあまりに早く戻ってくると検索順位を下げます。これはそのサイトがユーザーを留まらせなかったのだろうと推測されます。調査によれば、検索順位の上位となるには数分のサイト滞在を目標にすべきことが示唆されています。
年数: インターネット黎明期から存在したサイトが評価されます (1994 年にドメイン登録していたというだけで、長年 Google 検索で私よりも上位にいたサイトがありました！)。
参照ドメイン: Google の pageRank システムの原則が未だに順位に大きく影響します。これは単純にどれだけの他の独自ドメインが自分のページにリンクしているかというだけです。
次に、ここからが Fastly が実際にサポートできる領域です。主な焦点はセキュリティとスピードです。より速く、安全なサイトが上位を獲得します。これこそ Fastly の取り組むべき課題です！では、Fastly のサポート方法について詳しくみていきましょう。
お客様のサイトをより安全に、接続をより安定したものに
Fastly をお客様のサイトの前に配置するだけで、すぐに受けられる SEO 上のメリットが多くあります。当社は Fastly の TLS 接続にモダン暗号を採用しており、安全で高速で最適化した HTTP を提供しています。配信元への接続が安全でなくても (これはバグです!)、その問題を修正している間の検索順位に影響が出ることはありません。
また、Fastly では Dynamic Site Acceleration (DSA) のメリットも提供しています。Fastly のエッジの場所を 2 か所 (1 つはサイト付近、もう 1 つはエンドユーザー付近) 経由させてサイトとユーザー間を接続するオリジンシールドを利用する場合、そのルートの大部分で接続を永久に開くというメリットが利用できます。
最後に、すぐに使える Fastly が HTTP ポート以外のトラフィックや無効な HTTP トラフィックからお客様のサイトを保護します。これで DDoS 攻撃の大部分を妨害し、サイトをより回復力のあるものにします。SEO対策として、検索クローラーがお客様のサイトの順位を下げるなんてあり得ません！
Client hints、IO、gzip、brotli でデータ圧縮
圧縮可能なあらゆるものを圧縮して実際の転送データ量を減らし、特に帯域幅制限のあるデバイスにおけるページ読み込みを加速させるべきです。Fastly はオンザフライの gzip と brotli 圧縮を提供しています。これは CSS や JavaScript、HTML といったテキストベースの形式に最適です。画像なら Fastly の Image Optimization サービスのほうが良いでしょう (これは gzip といった一般的な目的の圧縮には向いていません)。
特に画像は、ユーザーのデバイス特性によって異なるサイズに拡大縮小しなければならないことが多いのですが、これは検索クローラーに影響しません。Client hints の利用は、どのサイズの画像を送信すべきかや element や srcset、サイズ属性などのページソース内でレスポンシブな画像定義を使用すべきかに関するスマートな意思決定の役に立ちます。
ここで検索エンジンに重要な合理的な行動はクローラー用に圧縮率を上げることです。人間の目で画像を見るわけではないのですから。
まずは古いレスポンスを配信
Fastly のお客様がよく利用している機能が、オリジンサーバーのダウン時に古いレスポンスを配信する機能です。これにより Web サイトの外部信頼性が大幅に上がり、わずかなオリジンのダウンタイム期間で問題を修復することができます。
検索クローラーに関してはさらにもう 1 つ手段を講じることができます。検索エンジンは通常のユーザーが行わない方法でサイト内の最も人目に付かない場所や欠陥を探索する傾向があります。そのため、検索クローラーはキャッシュしていないページやキャッシュされていても古いページに遭遇する確立が高くなります。検索エンジンにとってはページの最新版を持つ必要はないと思われるので、オリジンがコンテンツの更新するのを待たずに検索クローラーに積極的に古いものを配信することが考えられます。
できるだけ多くのリクエストを標準化
古いバージョンを配信することは結構なことなのですが、まずはキャッシュする対象がなければなりません。サイト高速化に対して別の角度から取り組むなら、できるだけ多くのリクエストを標準化しましょう。
これは内部的に次のような数多くの方法で実現できます。
対応外のパスからクエリ文字列を削除し、クエリ文字列に対応するようパスのパラメーターをアルファベットにする
全パスのセグメントやクエリパラム名を小文字にする
ユーザーエージェントのような非常にきめ細かいヘッダーを排除または標準化する
さらにリダイレクトを使って外部で実行したほうが良いものもあります。
HTTP から HTTPS へ
末尾に / がないディレクトリパスに / を追加
標準的なホスト名に統一(www.example.com からexample.com など)
こういった技術をすべて組み合せることで異なる URL に同じ内容の複数のコピーがあると検索エンジンが判断することを防ぎ、キャッシュヒット率も上がります。
ポリシーヘッダーの付与
サイトの攻撃対象領域が狭くユーザーのプライバシーに敬意を払っていることを示すことで現在の順位におけるメリットは少ないかもしれませんが、今後 Web パッケージのような技術を組み合せたときにそのメリットが大きくなる可能性があります。
ここに挙げたのは主な項目のクイックチェックリストです (決して包括的なものではありません)。
Content-security-policy : 自分のページが接続できるドメインを制限します。
Referrer-policy : サードパーティサイトにリンクした際のデータ漏えいをオプトアウトします。
Feature-policy : 不要なブラウザ機能を無効化し、その他を制限します。
Strict-transport-security : ブラウザに常に TLS を使って接続するよう通知します。これによってクローラーによるリダイレクトの節約にもなります。
下記はこれらをすべて記載したものです。
クリティカルパスのキャッシュ可能性モニタリングに Server-Timing を使用
新しい HTTP の Server-Timing ヘッダーを利用すると、便利なメタデータをサーバーがブラウザに送信することができます。これで Google Analytics のようなツールにキャプチャが可能です。リクエスト単位レベルでは、特定のリクエストがドキュメントの描画に重要かどうかを Fastly が把握するのは難しいのですが、この情報はブラウザでページが解決できるものです。
Server-Timing を使用することでキャッシュ可能かどうかを示すようレスポンスに注釈を付けることができます (実際にキャッシュから配信されたかどうかはこの目的ではあまり重要ではありません)。
どうしてもクライアントサイドの JavaScript が使いたい場合は、リソース読み込みの開始時間と終了時間をすべて読み込み、重要なものを見つけ (初回レンダーか独自のユーザー中心のタイミング測定の前のものと思われます)、エッジでキャッシュ可能かを確認して、キャッシュ不可能なものだとわかったら Reporting API 標準を使用してフォーマットしたビーコンを送信します。現在の Web にはこのようにこういったデータを表すパフォーマンスや標準を評価するための豊富なツールセットがあるところが良いですね。
トップへの道を切り拓きましょう！
こういった変更が検索パフォーマンスにもたらす影響は、内容の変更とまったく同じ影響ではないかもしれません。しかしセキュリティやパフォーマンスのベストプラクティスによる効果を低く評価せず、ぜひトップを目指してください。
