SEO監査とWebサイトのパフォーマンステスト:それぞれが調べる内容と、両方が必要になる場面

SEO監査とWebサイトのパフォーマンステストは、よくひとまとめに語られ、混同されがちです。しかし、この2つが答える問いは別のものです。SEO監査は、検索エンジンがページを見つけ、クロールし、インデックスし、内容を理解できるかを問います。パフォーマンステストは、訪問者に対してページがどれだけ速く読み込まれ、反応するかを問います。一方は見つけてもらうための話、もう一方はクリックされたあとの話です。

このガイドでは両者を比較したうえで、テクニカルSEO監査に使えるツールとサイト監査のチェックリストを紹介し、途中で出てくる考え方、つまりよくあるSEOエラー、モバイルファーストインデックス、ユーザー体験の指標、SEOとSEMの違い、クロールバジェットを説明します。

SEO監査とパフォーマンステストの比較

2つを並べて表にまとめました。

両者が重なる部分が1つあります。Core Web VitalsはGoogleがページ体験を評価する要素の一部なので、パフォーマンスの問題がSEOの問題にもなり得ます。ただし、検索順位にとっては関連性とコンテンツの質のほうがはるかに重要です。そのため、本格的なWebサイト監査にはパフォーマンスも項目の1つとして含まれます。

どちらも、もう一方の代わりにはなりません。どれだけ高速でも、noindex が残ったままのページは検索結果にまったく表示されません。完璧にインデックスされていても、スマートフォンでメインコンテンツの表示に8秒かかるページは、せっかく獲得した訪問者を逃してしまいます。

テクニカルSEO監査に使えるツール

最初から有料のツール一式をそろえる必要はありません。以下で基本はひととおり押さえられ、ほとんどが無料です。

インデックス、クロール、リンク

• Google Search Console。 ここが出発点です。「ページのインデックス登録」レポートではどのURLがインデックスされ、ほかがなぜされていないのかがわかり、「URL検査」ではGoogleが個々のページをどう見ているかを確認できます。速度とクロールについては、「ウェブに関する主な指標」レポートと「クロールの統計情報」レポートで確認します。
• Bing Webmaster Tools。 Bing向けの同等のツールで、独自のサイトスキャン機能があります。
• サイトクローラー。 検索エンジンと同じように内部リンクをたどり、ページごとに問題を報告します。Rudraのサイトクロールはデモページから開始でき、クロールした各ページでタイトル、ディスクリプション、見出し、canonical、インデックスの指示、内部リンク切れを確認します。無料プランでは最大2サイト、1回のスキャンにつき最大10ページまで対象になります。
• 単一ページのSEOチェック。 Rudraの無料SEOチェッカーは、1ページのオンページ要素に加えて、サイトのrobots.txtとサイトマップを確認します。読み取るのはサーバーが返すHTMLなので、あとからJavaScriptで追加されるコンテンツについては、URL検査でレンダリング後のHTMLもあわせて確認してください。
• リンク切れチェッカー。 リンク切れチェッカーはページ上のリンクをテストし、読み込みに失敗している自サイトのスクリプト、画像、フォントも報告します。

表示速度と構造化データ

• PageSpeed Insights。 十分なデータがある場合は実際のChromeユーザーのフィールドデータを上部に、その下にLighthouseのラボテストの結果を表示します。
• Lighthouse。 Chrome DevToolsに組み込まれています。Rudraのサイト表示速度チェッカーはこれを代わりに実行し、合格しなかった監査項目を深刻なものから順に一覧表示します。
• リッチリザルト テスト。 構造化データによって、ページがリッチリザルトの対象になるかどうかを確認します。

有料のツール一式には、クローラーからは見えない情報が加わります。被リンクデータ、キーワード順位、競合調査などです。Rudraはこれらを扱いません。お金を払う価値が出てくるのは、技術的な基本が整ったあとであって、その前ではありません。

サイト監査チェックリスト

上から順に進めてください。前半の項目しだいで、後半の項目に意味があるかどうかが決まります。インデックスされないページをいくら磨いても意味がないからです。

クロールとインデックス

1. サイトがGoogle Search Consoleで所有権確認済みで、XMLサイトマップが送信されている。
2. robots.txt が、見つけてほしいページをブロックしていない。ステージングサイトの Disallow: / が残っているのは、サイトがいつまでも検索に出てこない原因としてよくあるものです。
3. 重要なページに、robotsメタタグや X-Robots-Tag ヘッダーによる noindex が付いていない。noindexの意味を参照してください。
4. 重要なページがHTTP 200を返し、存在しないページは、ステータス200で「見つかりません」と表示するのではなく本物の404を返している。
5. サイトマップに載っているのが、公開中でインデックス可能なURLだけである。サイトマップの問題を診断する方法を参照してください。

オンページ

1. インデックス可能なすべてのページに、固有で内容のわかるタイトルとメタディスクリプションがある。
2. 各ページに明確なH1が1つあり、そのあとにH2、H3の見出しが順序どおりに続いている。
3. 各ページのcanonicalタグが絶対URLで、優先するURLを指している。
4. HTTPがHTTPSにリダイレクトされ、www ありと www なしのどちらも、1回の転送で1つのアドレスに統一される。
5. 内部リンク切れがなく、どこからもリンクされていない重要なページがない。
6. 構造化データが正しく解析でき、ページ上に見えている内容と一致している。

表示速度とモバイル

1. フィールドデータの75パーセンタイルで、LCPが2.5秒以下、INPが200ミリ秒以下、CLSが0.1以下である。
2. 画像が圧縮され、表示サイズに合った大きさで、widthとheightが明示されている。
3. viewportメタタグが設定され、拡大しなくても文字が読め、横スクロールが発生しない。
4. モバイルページに、デスクトップページと同じコンテンツ、見出し、構造化データがある。

信頼性と動作

1. すべてのページがHTTPSで、証明書が有効であり、混在コンテンツがない。
2. フォームにラベルがあり、スマートフォンでも使える。それぞれ自分で送信して、実際に届くことを確かめる。
3. 画像に意味のあるaltテキストがあり、色のコントラストが十分である。

見つかった内容を日付とともに記録し、インデックス関連の項目から直して、修正を公開してから数週間たったら監査をもう一度行いましょう。

WebサイトによくあるSEOエラー

ほとんどのサイトで、同じ不具合が見つかります。そしてそのほぼすべてが、誰かが気づきさえすれば簡単に直せるものです。

クロールとインデックスのエラー

• 開発時の noindex やrobots.txtによるブロックの消し忘れ。 ページが検索からそのまま消えてしまうため、最も被害の大きいエラーです。
• canonicalの問題: 指定がない、相対URLになっている、複数ある、誤ったURLを指している、など。canonicalの問題を修正する方法を参照してください。
• 同じページが複数のアドレスで表示される: http と https、www の有無、トラッキングパラメータ付きなど。
• ソフト404: 「見つかりません」のページが 200 OK で返されている状態。
• 内部リンク切れとリダイレクトチェーン。 ページの名前を変えたり削除したりしたときに残ったものです。
• 孤立ページ。 どこからもリンクされておらず、クローラーがたどり着けるとしてもサイトマップ経由だけです。孤立ページの見つけ方を参照してください。
• リダイレクトされるURL、ブロックされたURL、削除済みのURLばかりのサイトマップ。

オンページとコンテンツのエラー

• タイトルやディスクリプションの重複・未設定。 全ページに同じ文言を出力するテンプレートが原因であることがよくあります。タイトルの重複を修正する方法を参照してください。
• 内容の薄いページ。 見出しと1、2行の文章しかないページです。
• 見出しの欠落や飛ばし。 H1がない、H2の直後にH4が来る、といった状態です。
• altテキストのない画像、および重要な文章を画像の中に入れてしまっているケース。
• デスクトップにはあるのにモバイルにはないコンテンツ。
• 無効な構造化データ。 解析できない、または必須のプロパティが欠けているものです。構造化データを確認する方法を参照してください。

モバイルファーストインデックスの重要性

モバイルファーストインデックスとは、Googleが主にページのモバイル版をクロールし、インデックスするという意味です。デスクトップ版はもう基準ではありません。見出し、段落、画像、構造化データのブロックがモバイルページに欠けていれば、Googleにとってはそのページに存在しないのと同じです。

これによって監査の進め方も変わります。モバイルの結果を先に確認し、モバイルサイトこそが自分のサイトだと考えてください。

• レスポンシブデザインを採用し、1つのURLがどの画面サイズにも同じHTMLを返すようにする。
• テキスト、見出し、画像、altテキスト、構造化データ、メタタグを、モバイルでもデスクトップと同じにする。小さな画面向けにページを短くしない。
• タブやアコーディオン内のコンテンツが、タップされたときに初めて取得されるのではなく、HTMLに含まれているようにする。
• viewportメタタグを設定する(コード例はこのリストの下にあります)。
• Googleがページをレンダリングするために必要なCSS、JavaScript、画像をブロックしない。
• ページを開いた直後にコンテンツを覆い隠すポップアップは避ける。
• 幅を狭めたデスクトップのウィンドウだけでなく、実際のスマートフォンの画面幅でテストする。

<meta name="viewport" content="width=device-width, initial-scale=1">

RudraのSEOチェックはviewportタグの欠落を検出します。また、モバイルチェッカーはページをスマートフォン、タブレット、デスクトップの幅でレンダリングし、画面からはみ出しているコンテンツを検出します。修正方法はWebサイトをモバイルフレンドリーにする方法をご覧ください。

Webサイトのユーザー体験を測る指標

ユーザー体験は測定できます。まずは、実際の訪問から計測されるGoogleの3つのCore Web Vitalsから始めましょう。

訪問の75%が各しきい値を満たしていれば、そのページは合格です。判定はモバイルとデスクトップで別々に行われます。結果が悪いときは、次の補助的な計測値が原因を探る手がかりになります。

• Time to First Byte (TTFB): サーバーが応答を返し始めるまでの時間。ホスティング、キャッシュ、訪問者との距離が反映されます。
• First Contentful Paint (FCP): 何かしらが最初に表示される時点。
• Total Blocking Time (TBT): 読み込み中、メインスレッドが忙しすぎて反応できない時間の合計。ラボで得られる指標のうち、INPに最も近いものです。
• Speed Index: ページの見えている部分がどれだけ速く埋まっていくか。

速度は体験の一部にすぎません。行動面はアクセス解析が補ってくれます。

• エンゲージメント率とエンゲージメント時間: 訪問者は読んでいるのか、それともすぐに離脱しているのか。
• スクロール深度: ページの肝心な部分まで到達しているか。
• コンバージョン率: 訪問者100人のうち、何人が登録、購入、問い合わせをしたか。
• フォーム離脱: フォームの入力を始めたものの、完了しなかった人の数。
• 離脱ページ: 訪問者が最も多く離れていく場所。

アクセシビリティもここに含まれます。キーボードやスクリーンリーダーで使えないページは、どれだけ速く読み込まれても良い体験とは言えません。Webサイトのアクセシビリティを改善する方法を読むか、アクセシビリティチェッカーでページをテストしてみてください。

SEOとSEM:検索での関心度と、どちらを選ぶか

SEO(検索エンジン最適化)は、検索結果で広告費のかからない掲載順位を獲得するための取り組みです。SEM(検索エンジンマーケティング)は、もともと有料と無料の両方の検索施策を指していましたが、現在の一般的な使われ方では、クリックごとに料金を支払う検索連動型広告を意味します。

Google トレンドでこの2つの語を比べると、たいてい「SEO」のほうが「SEM」よりはるかに高い関心を集めています。ただし、これは2つの業界の規模というより、言葉の使われ方を表しています。検索広告について調べたい人は、代わりに「Google 広告」や「PPC」と入力することが多いからです。Google トレンドが示すのは検索回数ではなく、0〜100の尺度で表した相対的な関心度です。語句の比較や季節的な傾向の把握に使い、数値を根拠にする前に、自分の国の最新の数字を確認してください。

ほとんどのサイトにとって妥当な順番は、まずSEO、そしてすぐにトラフィックが必要なときや、コンテンツを書く前にどの検索がコンバージョンにつながるかを試したいときに検索広告を加える、というものです。いずれにしても、最初にランディングページを監査してください。広告のクリックで着いた先が、フォームの壊れた遅いページだったら、代金を二重に払うことになります。1度目はクリック代として、2度目は獲得できなかった顧客として。

クロールバジェットとは

クロールバジェットとは、検索エンジンが一定期間内にあなたのサイトでクロールでき、かつクロールしたいと考えるURLの集合です。Googleは、これを次の2つの要素から決まるものと説明しています。

• クロール能力の上限: サーバーに過度な負荷をかけずにGooglebotがクロールできる量。応答が速く安定していれば上がり、エラーや遅い応答があれば下がります。
• クロールの必要性: Googleがあなたのページをどれだけクロールしたいか。ページの人気と更新頻度をもとに決まります。

ほとんどのWebサイトにとって、これは制約になりません。Googleのガイダンスによると、クロールバジェットが主に問題になるのは、非常に大規模なサイト(およそ100万ページ以上)、毎日更新されるページが数万あるサイト、あるいはSearch Consoleで多くのURLが「検出 - インデックス未登録」になっている場合です。数百ページ程度のサイトなら、すべてクロールされます。

それでも理解しておく価値はあります。大規模サイトでクロールバジェットを浪費させるものは、規模にかかわらず、メンテナンスが行き届いていないことの表れだからです。

• 複数のURLでアクセスできる重複ページ(トラッキングパラメータ付きのものを含む)。
• 同じコンテンツに対して際限なくURLを生み出す、絞り込みと並べ替えの組み合わせ。
• 長いリダイレクトチェーン。
• ソフト404。
• 遅い、または失敗するサーバー応答。
• リダイレクトされるURLや、すでに存在しないURLを載せたサイトマップ。

クロールを効率よく保つには、サイトマップを正確に保ち、削除したページには本物の404または410を返し、重複はリダイレクトとcanonicalタグで統合し、検索上の価値がないセクションにはrobots.txtでクローラーを入れないようにします。なお、robots.txtが止めるのはクロールであって、インデックスではありません。この違いはrobots.txtとsitemap.xmlのガイドで説明しています。

Rudraはクロールバジェットを測定しません。検索エンジンがあなたのサイトでどう時間を使っているかは検索エンジンにしかわからず、確認する場所はGoogle Search Consoleの「クロールの統計情報」レポート(「設定」内)です。自分のサイトをクロールしてわかるのは、無駄のほうです。リダイレクトチェーン、リンク切れ、タイトルの重複、正規でないURLなどです。そして、新しいページが検索に出てこない場合、その原因はクロールバジェットよりも、インデックスや品質の問題であることのほうがはるかに多いのです。

何から始めるか

1. 無料のWebサイト監査で、トップページと重要な下層ページ1つに単一ページのチェックを実行する。
2. サイトをクロールして、ページをまたいで初めて見える問題を見つける。
3. インデックスを妨げているものを直し、そのあとは重大度の高い順にリストを片づけていく。
4. 主要なテンプレートごとにラボの速度テストを実行し、フィールドデータと比較する。
5. 再スキャンして以前の結果と比べ、これを四半期ごとに繰り返す。

1つの領域だけを確認したい場合は、無料の単一ページツールでSEO、表示速度、モバイルレイアウト、リンク切れ、セキュリティをチェックできます。