あるクライアントが18ヶ月間「プロのエージェンシーによってSEO最適化された」というサイトを送ってくれたことがあります。ランキングは横ばい。トラフィックは前年比で低下。エージェンシーのレポートは47ページで、「ブランドボイスの一貫性」についてのセクションが含まれていました。含まれていなかったのは、3,400ページが200ステータスコードを返しながらもメタにnoinexタグが埋め込まれているという事実です。3,500ページ以上。消えました。見えない状態です。エージェンシーはサイトを実際にクロールしたことがありませんでした。
重要なポイント：Screaming Frog のクロール結果を Search Console のデータと照合することで、どのサイトの技術的 SEO 問題もほぼ発見できます。派手なツールよりも、手法の方が重要です。
1週間で修正しました。Screaming FrogとGoogle Search Consoleを使って。
テクニカルSEOの面白さはここなんです。それについて話すのではなく、実際にデータを見る人に報酬を与えるんです。正直なところ、Seahawk経由で監査する90%のサイトについて、Ahrefs、Semrush、大手プラットフォームは必要ありません。パフォーマンスに本当に悪影響を及ぼしている問題を見つけるのに。2つのツール。1つのプロセス。これです。
---
何かをクロールする前に、Screaming Frogを正しくセットアップしてください
ほとんどの人はScreaming Frogを開いてURLを貼り付け、スタートボタンを押します。50ページのブログであればそれでいいでしょう。しかしそれより大きなサイトであれば、間違ったデータを得るために40分間クロールを待つことになります。
クローリング速度よりもコンフィギュレーションの方が重要です
最初にすることは：Configuration > Spiderに行き、正しいプロトコルをクロールしているか確認します。サイトがHTTPS上にある場合（そうであるべき）、正規HTTPSホームページから開始します。特別に監査したい場合を除き、PDF、画像、動画などの特定のファイルタイプのクロールをオフにします。クロール時間が半減します。
次に、Configuration > Respect Canonical Tagsをオフに設定します。直感的でないことは分かっていますが、正規化されたすべてのURLを見ることで、正規化が実際に正しく機能しているか監査したいのです。Screaming Frogが正規化されたページをスキップすると、それらが存在することを絶対に知ることができません。
もう1つ：Configuration > Custom Extractionで、HTML ソースから生の<title>とメタディスクリプションを直接抽出するルールを設定します。なぜでしょう？WordPressサイト、特にYoastとページビルダーを一緒に実行しているサイトの中には、2つのタイトルタグを出力するものがあるためです。Screaming Frogのデフォルト列には最初のタイトルタグだけが表示されます。抽出ルールはすべてを表示します。
---
最初のパス：クロールデータで確認するべきもの
クロールが完了したら、壊れたリンクから始めません。みんな壊れたリンクから始めます。私はResponse Codesタブから始めて、3xxリダイレクトでフィルタリングします。
2021年、Seahawkは中規模家具小売業者であるeコマースクライアントを引き受けました。約8,000のURL数です。彼らの開発チームは2年間、リダイレクトをその場で対応していました。19のリダイレクトチェーンが見つかり、その中には4ホップ長のものもありました。ページAはページBにリダイレクトされ、ページBはページCにリダイレクトされ、ページCはページDにリダイレクトされました。Googleは最大10ホップまで追うと言っていますが、実際には2ホップを超えるものはすべてクロール予算を浪費し、リンク評価を希薄化させます。すべてを1ホップリダイレクトに統合しました。これだけで、コンテンツ変更なし、リンク構築なし、3つのカテゴリーページが6週間以内にページ3からページ1に移動しました。
タブを処理する順序
- Response Codes → 3xx、リダイレクトチェーンおよびループ
- Response Codes → 4xx、壊れたページ（インリンク数で優先順位付け）
- Indexability → Non-Indexable、noindex、他の場所を指すキャノニカル、robots.txtでブロック
- Page Titles、欠落、重複、60文字超過
- Meta Description、欠落または重複（ランキング要因ではありませんが、クリック率が重要）
- H1が不足している、重複している、またはページごとに複数ある
- 画像→代替テキスト欠落、特に製品サイトでのクイックウィン
- ディレクティブ→Canonical タグ、これらが実際にインデックス可能なURLと一致しているか確認
その順序は意図的だ。構造的な問題（リダイレクト、破損ページ）からページ上の問題へと進める。破損したリダイレクトチェーンを修正すると、そのチェーン内のすべてのページが対象になる。欠落したメタディスクリプションを修正すると、1ページだけが対象になる。
---
Search Consoleでのレイヤリング：ここから面白くなる
Screaming Frogはサイト上に何があるかを教えてくれる。Search ConsoleはそのサイトについてGoogleが何を考えているかを教えてくれる。この2つのデータセット間のギャップが、本当の問題が潜んでいる場所だ。
カバレッジを開く（または新しいインターフェースではインデックス登録 → ページ）。4つのことを見ている：
- エラー、Googleがインデックスしようとしたが読み込めなかったページ
- 警告付き有効、多くの場合「送信されたURLが正規URLとして選択されていない」というもので、対処が必要な混乱状態
- 除外、Googleがインデックスしないことを選択したページ（クロール済みだがインデックス未対応、noindex指定など）
- 有効、Googleがインデックス済みのページ
「除外」バケットは悪用されることがほとんどないほど活用されていません。ほとんどの人はそれを無視します。私はそこに直行します。「クロール済み、現在インデックス未対応」でフィルターします。これはGoogleが言っていることです：このページを見つけた、読んだ、そしてインデックスする価値がないと判断した、ということです。これはほぼ常に薄いコンテンツの問題です。あるいは本来は問題ないページだが、別のページと似すぎている場合もあります。これはファセットナビゲーションやタグアーカイブで起こる典型的な問題です。
GSC除外をScreaming Frogクロールと照合する
Screaming FrogのクロールをCSVにエクスポートする。Search ConsoleからURLを「除外」にエクスポートする。両方をGoogle Sheetsに読み込んでVLOOKUPを実行する。Screaming Frogクロールに出現し、GSC除外リストにも出現するあらゆるURLは、優先的な調査対象だ。
Pythonスクリプトを使おうとする人は多いですが、別にそこまでする必要はありません。Sheetsの VLOOKUP なら4分で同じ答えが出ます。
---
クロールバジェット：サイトが本当に大きい場合だけ問題になる
正直に言いましょう。サイトが1,000ページ未満なら、クロールバジェットは問題ではありません。心配する必要はありません。
ただし、URLが約10,000を超えると、多くのWooCommerceやMagentoストアは製品バリエーションとフィルター済みURLからこの状態に陥りますが、クロール予算が響いてきます。Google Search Centralのクロール予算に関するドキュメントは、実際に彼らが書いた中でも最も分かりやすいものです。きちんと読む価値があります。
Search Console にある2つのレバーは、クロール統計レポートと URL インスペクションツールです。クロール統計では、Google の90日間のクロール活動が表示されます：1日あたりのクロールページ数、応答時間、応答コード。特定の日付で404スパイクが見られたら、それはデプロイメントがうまくいかなかったということです。平均クロール時間が2秒を超えているなら、問題はあなたの SEO ではなく、サーバーです。
---
内部リンク：エージェンシーが常に見落とすもの
Seahawkで100以上のサイト監査を行った経験がありますが、クライアントはリンク構築、ゲスト投稿、デジタルPRなどに実のお金を使っていて、内部リンクが指していない孤立したページがありました。Googleはサイト構造を通じて見つけられないものを優先順位付けすることはできません。
Screaming Frog で、クロールを Inlinks = 0 でフィルタします。内部リンクがゼロのページはすべて孤立ページです。Search Console のインデックス済みページと相互参照してください。ページがインデックスされているが内部リンクがない場合、Google は XML サイトマップまたは外部バックリンクを通じてそれを見つけたということです。それは脆弱です。関連するページから内部リンクを付けると、Google に対して「このページは重要である」という構造的シグナルを与えることになります。
内部リンク構造で気をつけている点をいくつか挙げる
- ページネーションページが商品ページや記事ページにリンクしているのに、それらのページがカテゴリーページへのリンクを返していない
- 2019年に公開されたブログ記事で、それ以降のコンテンツからリンクされたことがないもの
- 内部リンクが数十本あるのに Google Search Console でのトラフィックが非常に低いページは、リンク元の問題ではなく、ページ自体に問題があることが多い。
---
Core Web Vitals: データを読む、パニックするな
Search Console には Core Web Vitals レポートがある。これは実ユーザーの Chrome UX Report データ、つまりフィールドデータ（実際のユーザーが実際のデバイスから取得したデータ）を参照しており、ラボシミュレーションではない。1 回限りの Lighthouse 実行結果より意味がある。
レポートは URL を LCP、FID（現在は INP に置き換わっている）、CLS で「良好」「改善が必要」「不良」にグループ化する。すべてを一度に修正しようとするな。「不良」グループでソートして、どの URL パターンに失敗ページが最も多いかを確認する。通常は単一のテンプレート、すべての商品ページの CLS 問題、またはすべてのカテゴリーページの LCP が遅い、といったことだ。テンプレートを修正すれば、数百ページが一度に直る。
苦い経験から学んだことの一つ: 広告またはクッキーバナーがあるサイトのCLS問題は、初期描画後に要素がファーストビューの上に挿入されることがほぼすべての原因だ。Screaming Frogではこれをキャッチできない。実際のページを見る必要がある。Chrome DevToolsを使い、Renderingでレイアウトシフト領域を有効にして確認する。
---
Robots.txtとサイトマップのチェック（10分で完了、数週間の無駄を防止）
yourdomain.com/robots.txt にアクセスしてください。すべての行を読んでください。私自身の目で見たことがあります。本番環境のサイトで robots.txt に Disallow: / と記載されていたのです。ステージング環境ではなく、本番環境です。7年続いている事業です。開発者がマイグレーション時にステージング用の robots.txt をコピーしたまま確認していませんでした。その結果、4ヶ月間実質的に Google から見えない状態が続いていました。彼らが気付くまでです。
Search Console でサイトマップに移動する。何が送信されているかを確認する。Google が最後にサイトマップを取得した時刻を確認する。1 週間以上サイトマップが取得されていなければ、何かが壊れている。送信された URL 数とインデックス登録済みの URL 数も比較する。4,000 個の URL を送信しているのに 1,200 しかインデックスされていないなら、それは技術的な修正の話ではなく、コンテンツの品質について議論すべき問題だ。
---
FAQ
Screaming Frog の有料版は必要ですか？
無料版は 500 URL に制限されている。監査する価値がある大抵のサイトはそれ以上なので、有料ライセンスが必要だ。執筆時点で年間 £259。これはエージェンシー業務の 1 時間分の費用程度だ。買え。
技術監査はどのくらいの頻度で実行すべきですか？
定期的にコンテンツを公開したり、製品を頻繁に変更したりしているアクティブなサイトの場合、四半期ごとをお勧めします。より小規模で静的なサイトの場合、年2回で問題ありません。監査を1回実行して「完了」と考えるのは、車のオイルを1回交換して永遠に走り続けると期待するようなものです。
Screaming Frog は 200 ステータスを表示しているが、Google Search Console ではページがインデックスされていないのはなぜか？
ほぼ常に 3 つのいずれかが原因だ：noindex メタタグ、noindex HTTP ヘッダー、または別の場所を指しているカノニカルタグ。Search Console の URL インスペクション ツールで URL を実行すれば、Google が何を見つけたかが正確にわかる。このツールは過小評価されている。Google が最後にクロールしたページのバージョン（レンダリングされた HTML を含む）が表示され、基本的な HTTP リクエストでは検出できない JavaScript で挿入された noindex タグまで捕捉できる。
JavaScriptでレンダリングされるサイトはどうですか？
Screaming Frog の Configuration > Spider > Rendering に JavaScript レンダリングモードがある。JavaScript が多いサイトではこれをオンにする。かなり遅くなるが、初期 HTML ロード後に JavaScript で挿入されるコンテンツやリンクの問題を検出する唯一の方法だ。React や Next.js サイトの場合は、常に JS レンダリングモードでクロールする。
Google Search Consoleはキーワードリサーチに十分ですか？
既存ページがランク付けされているクエリを見つけるなら、そう、優れている。新しいキーワード機会を発見するなら、いや、別のものが必要だ。ただし、それは技術監査の範囲外だ。
---
2 つのツール。スプレッドシート。数時間。本当にこれだけで足りる。高額なプラットフォームにも役割はあり、私はそれらに反対ではないが、高い料金を払えばより多くが見つかると仮定するサイト所有者を何度も見てきた。問題はほぼ常に基本にある。誰かが実際に見てくれるだけでいいのだ。