あるクライアントが18ヶ月間「プロのエージェンシーによってSEO最適化された」というサイトを送ってくれたことがあります。ランキングは横ばい。トラフィックは前年比で低下。エージェンシーのレポートは47ページで、「ブランドボイスの一貫性」についてのセクションが含まれていました。含まれていなかったのは、3,400ページが200ステータスコードを返しながらもメタにnoinexタグが埋め込まれているという事実です。3,500ページ以上。消えました。見えない状態です。エージェンシーはサイトを実際にクロールしたことがありませんでした。
重要なポイント：Screaming Frog のクロール結果を Search Console のデータと照合することで、どのサイトの技術的 SEO 問題もほぼ発見できます。派手なツールよりも、手法の方が重要です。A Screaming Frog crawl cross-referenced with Search Console data still finds most technical SEO problems on any site; the method matters more than exotic tooling.
1週間で修正しました。Screaming FrogとGoogle Search Consoleを使って。
テクニカルSEOの面白さはここなんです。それについて話すのではなく、実際にデータを見る人に報酬を与えるんです。正直なところ、Seahawk経由で監査する90%のサイトについて、Ahrefs、Semrush、大手プラットフォームは必要ありません。パフォーマンスに本当に悪影響を及ぼしている問題を見つけるのに。2つのツール。1つのプロセス。これです。Seahawk, I don't need Ahrefs, Semrush, or any of the big platforms to find the problems that are genuinely hurting performance. Two tools. One process. Here it is.
---
何かをクロールする前に、Screaming Frogを正しくセットアップしてください
ほとんどの人はScreaming Frogを開いてURLを貼り付け、スタートボタンを押します。50ページのブログであればそれでいいでしょう。しかしそれより大きなサイトであれば、間違ったデータを得るために40分間クロールを待つことになります。
クローリング速度よりもコンフィギュレーションの方が重要です
最初にすることは：Configuration > Spiderに行き、正しいプロトコルをクロールしているか確認します。サイトがHTTPS上にある場合（そうであるべき）、正規HTTPSホームページから開始します。特別に監査したい場合を除き、PDF、画像、動画などの特定のファイルタイプのクロールをオフにします。クロール時間が半減します。Configuration > Spider and make sure I'm crawling the correct protocol. If the site is on HTTPS (it should be), I'm starting from the canonical HTTPS homepage. I also turn off crawling of certain file types, PDFs, images, videos, unless I specifically want to audit those. It halves the crawl time.
次に、Configuration > Respect Canonical Tagsをオフに設定します。直感的でないことは分かっていますが、正規化されたすべてのURLを見ることで、正規化が実際に正しく機能しているか監査したいのです。Screaming Frogが正規化されたページをスキップすると、それらが存在することを絶対に知ることができません。Configuration > Respect Canonical Tags to off. Counter-intuitive, I know. But I want to see every canonicalised URL so I can audit whether the canonicalisation is actually correct. If Screaming Frog skips canonicalised pages, you'll never know they exist.
もう1つ：Configuration > Custom Extractionで、HTML ソースから生の<title>とメタディスクリプションを直接抽出するルールを設定します。なぜでしょう？WordPressサイト、特にYoastとページビルダーを一緒に実行しているサイトの中には、2つのタイトルタグを出力するものがあるためです。Screaming Frogのデフォルト列には最初のタイトルタグだけが表示されます。抽出ルールはすべてを表示します。Configuration > Custom Extraction, I set up an extraction rule to pull the raw <title> and meta description directly from the HTML source. Why? Because some WordPress sites, particularly ones running Yoast alongside a page builder, output two title tags. Screaming Frog's default column only shows you the first one. The extraction rule shows you everything.
---
最初のパス：クロールデータで確認するべきもの
クロールが完了したら、壊れたリンクから始めません。みんな壊れたリンクから始めます。私はResponse Codesタブから始めて、3xxリダイレクトでフィルタリングします。Response Codes tab and filter for 3xx redirects.
2021年、Seahawkは中規模家具小売業者であるeコマースクライアントを引き受けました。約8,000のURL数です。彼らの開発チームは2年間、リダイレクトをその場で対応していました。19のリダイレクトチェーンが見つかり、その中には4ホップ長のものもありました。ページAはページBにリダイレクトされ、ページBはページCにリダイレクトされ、ページCはページDにリダイレクトされました。Googleは最大10ホップまで追うと言っていますが、実際には2ホップを超えるものはすべてクロール予算を浪費し、リンク評価を希薄化させます。すべてを1ホップリダイレクトに統合しました。これだけで、コンテンツ変更なし、リンク構築なし、3つのカテゴリーページが6週間以内にページ3からページ1に移動しました。Google says it follows up to 10 hops, but in practice, anything beyond two hops wastes crawl budget and dilutes link equity. We collapsed everything to single-hop redirects. That alone, no content changes, no link building, moved three category pages from page 3 to page 1 within six weeks.
タブを処理する順序
- Response Codes → 3xx、リダイレクトチェーンおよびループ, redirect chains and loops
- Response Codes → 4xx、壊れたページ（インリンク数で優先順位付け）, broken pages (filter by inlinks to prioritise)
- Indexability → Non-Indexable、noindex、他の場所を指すキャノニカル、robots.txtでブロック, noindex, canonicals pointing elsewhere, blocked by robots.txt
- Page Titles、欠落、重複、60文字超過, missing, duplicated, over 60 characters
- Meta Description、欠落または重複（ランキング要因ではありませんが、クリック率が重要）, missing or duplicated (not a ranking factor, but click-through matters)
- H1が不足している、重複している、またはページごとに複数ある, missing, duplicated, or more than one per page
- 画像→代替テキスト欠落、特に製品サイトでのクイックウィン, quick win, especially for product sites
- ディレクティブ→Canonical タグ、これらが実際にインデックス可能なURLと一致しているか確認, check these match the actual indexable URL
その順序は意図的だ。構造的な問題（リダイレクト、破損ページ）からページ上の問題へと進める。破損したリダイレクトチェーンを修正すると、そのチェーン内のすべてのページが対象になる。欠落したメタディスクリプションを修正すると、1ページだけが対象になる。
---
Search Consoleでのレイヤリング：ここから面白くなる
Screaming Frogはサイト上に何があるかを教えてくれる。Search ConsoleはそのサイトについてGoogleが何を考えているかを教えてくれる。この2つのデータセット間のギャップが、本当の問題が潜んでいる場所だ。
カバレッジを開く（または新しいインターフェースではインデックス登録 → ページ）。4つのことを見ている：Coverage (or Indexing → Pages in the newer interface). You're looking at four things:
- エラー、Googleがインデックスしようとしたが読み込めなかったページ, pages Google tried to index and couldn't
- 警告付き有効、多くの場合「送信されたURLが正規URLとして選択されていない」というもので、対処が必要な混乱状態, often "Submitted URL not selected as canonical," which is a mess you need to untangle
- 除外、Googleがインデックスしないことを選択したページ（クロール済みだがインデックス未対応、noindex指定など）, pages Google chose not to index (crawled but not indexed, noindexed, etc.)
- 有効、Googleがインデックス済みのページ, pages Google has indexed
「除外」バケットは悪用されることがほとんどないほど活用されていません。ほとんどの人はそれを無視します。私はそこに直行します。「クロール済み、現在インデックス未対応」でフィルターします。これはGoogleが言っていることです：このページを見つけた、読んだ、そしてインデックスする価値がないと判断した、ということです。これはほぼ常に薄いコンテンツの問題です。あるいは本来は問題ないページだが、別のページと似すぎている場合もあります。これはファセットナビゲーションやタグアーカイブで起こる典型的な問題です。I found this page, I read it, and I decided it wasn't worth indexing. That's almost always a thin content problem. Or it's a page that's genuinely fine but is too similar to another page, a classic issue with faceted navigation or tag archives.
GSC除外をScreaming Frogクロールと照合する
Screaming FrogのクロールをCSVにエクスポートする。Search ConsoleからURLを「除外」にエクスポートする。両方をGoogle Sheetsに読み込んでVLOOKUPを実行する。Screaming Frogクロールに出現し、GSC除外リストにも出現するあらゆるURLは、優先的な調査対象だ。and in the GSC excluded list is a priority investigation.
Pythonスクリプトを使おうとする人は多いですが、別にそこまでする必要はありません。Sheetsの VLOOKUP なら4分で同じ答えが出ます。
---
クロールバジェット：サイトが本当に大きい場合だけ問題になる
正直に言いましょう。サイトが1,000ページ未満なら、クロールバジェットは問題ではありません。心配する必要はありません。
ただし、URLが約10,000を超えると、多くのWooCommerceやMagentoストアは製品バリエーションとフィルター済みURLからこの状態に陥りますが、クロール予算が響いてきます。Google Search Centralのクロール予算に関するドキュメントは、実際に彼らが書いた中でも最も分かりやすいものです。きちんと読む価値があります。Google Search Central documentation on crawl budget is actually one of the clearer things they've written. Worth reading properly.
Search Console にある2つのレバーは、クロール統計レポートと URL インスペクションツールです。クロール統計では、Google の90日間のクロール活動が表示されます：1日あたりのクロールページ数、応答時間、応答コード。特定の日付で404スパイクが見られたら、それはデプロイメントがうまくいかなかったということです。平均クロール時間が2秒を超えているなら、問題はあなたの SEO ではなく、サーバーです。Crawl Stats report and the URL Inspection tool. Crawl Stats shows you Google's crawl activity over 90 days: pages crawled per day, response times, response codes. If you see a spike in 404s on a specific date, that's a deployment that went wrong. If average crawl time is above 2 seconds, your server is the problem, not your SEO.
---
内部リンク：エージェンシーが常に見落とすもの
Seahawkで100以上のサイト監査を行った経験がありますが、クライアントはリンク構築、ゲスト投稿、デジタルPRなどに実のお金を使っていて、内部リンクが指していない孤立したページがありました。Googleはサイト構造を通じて見つけられないものを優先順位付けすることはできません。orphaned pages that no internal link pointed to. Google can't prioritise what it can't find through your site structure.
Screaming Frog で、クロールを Inlinks = 0 でフィルタします。内部リンクがゼロのページはすべて孤立ページです。Search Console のインデックス済みページと相互参照してください。ページがインデックスされているが内部リンクがない場合、Google は XML サイトマップまたは外部バックリンクを通じてそれを見つけたということです。それは脆弱です。関連するページから内部リンクを付けると、Google に対して「このページは重要である」という構造的シグナルを与えることになります。Inlinks = 0. Any page with zero internal links is an orphan. Cross-reference it against Search Console's indexed pages. If the page is indexed but has no internal links, it means Google found it through an XML sitemap or an external backlink. That's fragile. Give it an internal link from a relevant page and you're giving Google a structural signal that this page matters.
内部リンク構造で気をつけている点をいくつか挙げる
- ページネーションページが商品ページや記事ページにリンクしているのに、それらのページがカテゴリーページへのリンクを返していない
- 2019年に公開されたブログ記事で、それ以降のコンテンツからリンクされたことがないもの
- 内部リンクが数十本あるのに Google Search Console でのトラフィックが非常に低いページは、リンク元の問題ではなく、ページ自体に問題があることが多い。
---
Core Web Vitals: データを読む、パニックするな
Search Console には Core Web Vitals レポートがある。これは実ユーザーの Chrome UX Report データ、つまりフィールドデータ（実際のユーザーが実際のデバイスから取得したデータ）を参照しており、ラボシミュレーションではない。1 回限りの Lighthouse 実行結果より意味がある。Core Web Vitals report. It pulls from real-user Chrome UX Report data, which is field data, actual users on actual devices, not a lab simulation. This is more meaningful than what you'd get from a one-off Lighthouse run.
レポートは 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 から見えない状態が続いていました。彼らが気付くまでです。yourdomain.com/robots.txt . Read every line. I have seen, with my own eyes, a live production site with Disallow: / in the robots.txt. Not a staging site. Production. A seven-year-old business. Their developer had copied the staging robots.txt during a migration and never checked it. They had been essentially invisible to Google for four months before they noticed.
Search Console でサイトマップに移動する。何が送信されているかを確認する。Google が最後にサイトマップを取得した時刻を確認する。1 週間以上サイトマップが取得されていなければ、何かが壊れている。送信された URL 数とインデックス登録済みの URL 数も比較する。4,000 個の URL を送信しているのに 1,200 しかインデックスされていないなら、それは技術的な修正の話ではなく、コンテンツの品質について議論すべき問題だ。Sitemaps. Check what's been submitted. Check the last time Google fetched it. If the sitemap hasn't been fetched in over a week, something is broken. Also check the submitted URL count vs the indexed URL count, if you've submitted 4,000 URLs and only 1,200 are indexed, that's a conversation you need to have about content quality, not about technical fixes.
---
FAQ
Screaming Frog の有料版は必要ですか？
無料版は 500 URL に制限されている。監査する価値がある大抵のサイトはそれ以上なので、有料ライセンスが必要だ。執筆時点で年間 £259。これはエージェンシー業務の 1 時間分の費用程度だ。買え。£259 per year as of writing. That's about the price of a single hour of agency time. Buy it.
技術監査はどのくらいの頻度で実行すべきですか？
定期的にコンテンツを公開したり、製品を頻繁に変更したりしているアクティブなサイトの場合、四半期ごとをお勧めします。より小規模で静的なサイトの場合、年2回で問題ありません。監査を1回実行して「完了」と考えるのは、車のオイルを1回交換して永遠に走り続けると期待するようなものです。
Screaming Frog は 200 ステータスを表示しているが、Google Search Console ではページがインデックスされていないのはなぜか？
ほぼ常に 3 つのいずれかが原因だ：noindex メタタグ、noindex HTTP ヘッダー、または別の場所を指しているカノニカルタグ。Search Console の URL インスペクション ツールで URL を実行すれば、Google が何を見つけたかが正確にわかる。このツールは過小評価されている。Google が最後にクロールしたページのバージョン（レンダリングされた HTML を含む）が表示され、基本的な HTTP リクエストでは検出できない JavaScript で挿入された noindex タグまで捕捉できる。last crawled version of the page, including the rendered HTML, which catches JavaScript-injected noindex tags that a basic HTTP request wouldn't see.
JavaScriptでレンダリングされるサイトはどうですか？
Screaming Frog の Configuration > Spider > Rendering に JavaScript レンダリングモードがある。JavaScript が多いサイトではこれをオンにする。かなり遅くなるが、初期 HTML ロード後に JavaScript で挿入されるコンテンツやリンクの問題を検出する唯一の方法だ。React や Next.js サイトの場合は、常に JS レンダリングモードでクロールする。Configuration > Spider > Rendering. Turn it on for JS-heavy sites. It's slower, significantly slower, but it's the only way to catch issues with content or links that are injected by JavaScript after the initial HTML loads. For a React or Next.js site, always crawl in JS rendering mode.
Google Search Consoleはキーワードリサーチに十分ですか？
既存ページがランク付けされているクエリを見つけるなら、そう、優れている。新しいキーワード機会を発見するなら、いや、別のものが必要だ。ただし、それは技術監査の範囲外だ。existing pages rank for, yes, it's excellent. For discovering new keyword opportunities, no, you'll need something else. But that's out of scope for a technical audit.
---
2 つのツール。スプレッドシート。数時間。本当にこれだけで足りる。高額なプラットフォームにも役割はあり、私はそれらに反対ではないが、高い料金を払えばより多くが見つかると仮定するサイト所有者を何度も見てきた。問題はほぼ常に基本にある。誰かが実際に見てくれるだけでいいのだ。