あるクライアントが18ヶ月間「プロのエージェンシーによってSEO最適化された」というサイトを送ってくれたことがあります。ランキングは横ばい。トラフィックは前年比で低下。エージェンシーのレポートは47ページで、「ブランドボイスの一貫性」についてのセクションが含まれていました。含まれていなかったのは、3,400ページが200ステータスコードを返しながらもメタにnoinexタグが埋め込まれているという事実です。3,500ページ以上。消えました。見えない状態です。エージェンシーはサイトを実際にクロールしたことがありませんでした。
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.
もう一つ：Configuration > Custom Extractionで、HTMLソースから生の<title>タグとメタディスクリプションを直接抽出するルールを設定します。なぜか？WordPressサイト、特にYoastとページビルダーを一緒に実行しているサイトは、2つのtitleタグを出力することがあるからです。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 Mediaは中規模の家具小売業者である約8,000のURLを持つeコマースクライアントを担当しました。彼らの開発チームは2年間、リダイレクトをアドホックで処理していました。4ホップまでの19のリダイレクトチェーンが見つかりました。ページAがページBにリダイレクトされ、ページBがページCにリダイレクトされ、ページCがページDにリダイレクトされました。Googleは10ホップまで追跡できると言っていますが、実際のところ、2ホップを超えるものはすべてクロール予算を浪費し、リンクエクイティを希釈します。すべてを単一ホップリダイレクトに絞りました。これだけで——コンテンツ変更なし、リンク構築なし——6週間以内に3つのカテゴリーページをページ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.
タブを処理する順序
- レスポンスコード → 3xx — リダイレクトチェーンとループ — redirect chains and loops
- レスポンスコード → 4xx — 破損ページ（内部リンク数でフィルタリングして優先順位を付ける） — broken pages (filter by inlinks to prioritise)
- インデックス可能性 → インデックス不可 — noindex、他所を指すカノニカル、robots.txtでブロック — noindex, canonicals pointing elsewhere, blocked by robots.txt
- ページタイトル — 欠落、重複、60文字以上 — missing, duplicated, over 60 characters
- メタディスクリプション — 欠落または重複（ランキング要因ではないが、クリックスルーレートに影響） — 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
- ディレクティブ → カノニカル — これらが実際のインデックス可能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がインデックス登録しないことに決めたページ（クロール済みだがインデックスなし、noindexedなど） — 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ページ未満なら、クロールバジェットは問題ではありません。心配する必要はありません。
ただし約10,000 URLs を超えると――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年に公開されたブログ記事で、それ以降のコンテンツからリンクされたことがないもの
- 内部リンクが数十本入ってきているのに、GSCのトラフィックが非常に低いページ — ページ自体に問題があるのであって、リンク数の問題ではないケースが多い
---
Core Web Vitals: データを読む、パニックするな
Search ConsoleにはCore Web Vitalsレポートがある。実ユーザーのChrome UX Reportデータから取得するもので、これはフィールドデータ — 実際のデバイスで実際のユーザーがアクセスしたものであり、ラボシミュレーションではない。単発の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を「良好」「改善が必要」「不良」の3段階に分類し、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 ステータスを表示しているのに GSC ではページがインデックスされていないと表示されるのはなぜですか？
ほぼ常に以下の3つのいずれかです：noindexメタタグ、noindex HTTPヘッダー、または他の場所を指すcanonicalタグです。Search ConsoleのURL検査ツールでURLを実行すれば、正確に何が見つかったかが表示されます。このツールは過小評価されていますが、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レンダリングモードを持っています。JS多用のサイトの場合は有効にしてください。遅くなります — かなり遅くなりますが — 初期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つのツール。スプレッドシート。数時間。それが本当にすべてです。高額なプラットフォームには存在価値があります — 私は反対ではありません — しかし、より多くを支払うことがより多く見つけることを意味すると仮定するサイト所有者を見すぎてきました。問題はほぼ常に基本にあります。実際に見てくれる誰かが必要なだけです。