seo-technical-audit

出力例：examples/seo-technical-audit-linear-app-20260514/TECH-AUDIT.md

技術監査

ドメインを対象に、一度で実施する技術 SEO 監査です。SE Ranking の監査データを取得し、指摘事項を分野（クロール可能性、インデックス登録可能性、セキュリティ、モバイル、構造化データなど）ごとに分類して、それぞれの分野で重大度順に並べ、影響度 × 作業量で順位付けした修正項目のトップ 10 を作成します。

前提条件

• SE Ranking MCP サーバーが接続されていること。
• Claude の WebFetch ツールが利用可能であること（robots.txt とサイトマップの有無を確認するために使用します）。
• ユーザーが対象ドメイン（例：example.com）を指定すること。任意で対象国も指定できます（デフォルトは us、監査ページ数の上書き指定は任意で、デフォルトでは既存の監査の上限を使用します）。

プロセス

1. 対象を検証し、事前チェックを行います。 標準的な 3 段階の事前チェック（クレジット残高、Firecrawl の利用可否、Google API）については、skills/seo-firecrawl/references/preflight.md を参照してください。このスキル固有の注意事項：

   • 続行する前に、ドメインを正規化します（プロトコルと末尾のスラッシュを削除します）。
   • このスキルで推定される SE Ranking のコスト：既存の監査の再チェックは低コストですが、新しい監査の作成は大幅にコストが高く、ページ数によって異なります。実施を決める前にコストを提示します。
   • Firecrawl：任意です。利用可能な場合は、ステップ 8（最新シグナルのチェックリスト）で 5 つのサンプル URL と /robots.txt を確認します。使用量は約 6 Firecrawl クレジットです（上限あり）。利用できない場合はステップ 8 をスキップします。その場合、JS レンダリング後の canonical/noindex の差異、X-Robots-Tag ヘッダー、AI クローラー向け robots ルールの分析は利用できませんが、技術監査の成果物全体は作成されます。Firecrawl が利用可能な場合でもステップ 8 をスキップするには、--no-firecrawl を渡してください（クレジットを節約できます）。
   • Google API：ティア 0 ではステップ 8b（CrUX のフィールドデータ）が利用可能になり、ティア 1 ではさらにステップ 8c（トラフィック上位 5 ページの URL ごとの GSC 検査）も利用可能になります。完全な手順とティアごとの分岐については、skills/seo-google/references/cross-skill-integration.md の「seo-technical-audit」を参照してください。

2. 監査を検索または作成します DATA_listAudits

   • ドメインの監査一覧を取得します。
   • 最近の監査（30 日未満）がある場合は、それを使用します。
   • 30 日を超えている場合は、DATA_recheckAudit を実行して更新します。
   • 監査がない場合は、DATA_createStandardAudit で新しい監査を作成する前にユーザーに確認します（クレジットを消費します）。
   • レポートを取得する前に、DATA_getAuditStatus が done を返すまで待ちます。

3. 監査レポートを取得します DATA_getAuditReport

   • 主な指標：クロールしたページ数、ヘルススコア、重大度別の問題総数。
   • カテゴリ別（クロール可能性、インデックス登録可能性、モバイル、セキュリティ、構造化データなど）に分類された問題。

4. 問題ごとのページ一覧を取得します DATA_getAuditPagesByIssue

   • 重大な各問題（重大度 ≥ 中、件数 ≥ 5）について、影響を受ける URL を取得します。
   • これにより、実行可能な修正項目の一覧を作成します。

5. 重要な URL を相互参照します DATA_getIssuesByUrl

   • トラフィック上位 5 ページ（DATA_getDomainKeywords のページ集計から取得します。キーワードデータがない場合は、ホームページと主要なランディングページを使用します）について、該当 URL のすべての問題を取得します。
   • これにより、重要な 1 ページに多くの問題が集中しているケースを検出できます。

6. WebFetch で妥当性を確認します

   • /robots.txt と /sitemap.xml を直接取得します。
   • 監査結果が、これらの重要なファイルの実態と一致していることを確認します（監査結果は同日中のデプロイを反映できていない場合があります）。
   • 拡張セキュリティヘッダー。 ホームページとサンプル URL 3 件（ステップ 5 のトラフィック上位のランディングページ。キーワードデータがない場合は、ホームページと主要なランディングページを使用）を WebFetch で取得し、レスポンスヘッダーを確認して、次のいずれかに該当する場合は指摘します。
     • csp_missing — Content-Security-Policy がありません。
     • xframe_missing — X-Frame-Options がありません（参考情報。CSP の frame-ancestors が優先されます）。
     • xcontent_missing — X-Content-Type-Options が nosniff に設定されていません。
     • referrer_policy_missing — Referrer-Policy がありません。
     • hsts_no_preload — Strict-Transport-Security はありますが、preload ディレクティブがなく、かつドメインが Chromium の HSTS プリロードリストに登録されていません。
   • references/severity-mapping.md の § Security に従って指摘事項を対応付け、evidence/02-issues-by-category/security.md に記載します（また、TECH-AUDIT.md の「By category → Security」セクションにもインラインで記載します）。

7. references/severity-mapping.md を使って分類し、優先順位を付けます

   • 各問題コードを重大度、修正方法、工数の見積もりに対応付けます。
   • 各指摘事項をスコア化します：重大度 × 影響を受けるページ数 / 工数。
   • 修正項目の上位 10 件のリストを作成します。

8. 最新シグナルのチェックリスト mcp__firecrawl-mcp__firecrawl_scrape

   • SE Ranking の監査クローラーは JS を実行せず、ページごとのレスポンスヘッダーも公開しません。このステップでは、監査クローラーから見えない情報を明らかにします。
   • Firecrawl が利用できる場合（約 6 Firecrawl クレジット、上限厳守）：監査対象からサンプル URL を 5 件選びます。トラフィックの多いランディングページや、noindex／canonical の問題がすでに検出されているページを優先してください。それぞれについて、次を確認します。
     • JS レンダリング後の canonical と初期 HTML の canonical の不一致（js_canonical_mismatch）。 metadata.canonical（JS レンダリング後）と監査で記録された canonical を比較します。不一致があれば報告してください。Google の 2025 年 12 月の JavaScript SEO ガイダンスによると、生 HTML の canonical と JS で挿入された canonical が異なる場合、Google はどちらを採用する可能性もあり、canonical の判断が不確定になります。JS で挿入された canonical の変更は、JS への依存度が高いサイトのインデックス登録に気付かれないまま悪影響を及ぼすことがあります。
     • JS レンダリング後の noindex。 レンダリング後の metadata.robots に noindex が含まれていないか確認します。監査では検出できない、クライアント側でのみ挿入される noindex を見つけます。
     • X-Robots-Tag ヘッダー。 metadata からレスポンスヘッダーを読み取ります。HTTP 層に noindex／nofollow／none のディレクティブがあれば報告してください。
     • 2025 年 12 月の JS SEO リスク検出（Google の 2025 年 12 月の JavaScript SEO ガイダンス — 静的クローラーでは検出できない 4 つのリスク）：
       • リスク 1 — レンダリング予算の不足（js_render_budget）。 初期 HTML とレンダリング後の HTML の本文サイズを比較します。JS の実行後にレンダリング後の HTML が初期 HTML の 50% 未満になるページを報告してください。これは、ページの実際のコンテンツが読み込まれる前に Google がレンダリング予算を使い果たす可能性を示します。
       • リスク 2 — ハイドレーションの不一致。 上記の js_canonical_mismatch で検出済みです。理由：2025 年 12 月のガイダンスによると、Google はどちらの canonical を採用する可能性もあるため、わずかな差異でも、単なる整合性の問題ではなく、実際のランキングに影響するリスクになります。
       • リスク 3 — CSR の落とし穴（js_csr_meta_drift）。 初期 HTML の <title>、<h1>、<meta name="description"> を、JS レンダリング後の DOM 内の同じ項目と比較します。不一致があれば報告してください。Google はレンダリング後にのみ表示されるコンテンツを確実にはインデックス登録しないため、初期値が空または誤っている場合、その値がインデックス登録される可能性があります。
       • リスク 4 — JS エラーによるソフト 404（js_soft_404）。 レンダリング後のページで、本文テキストが 500 文字未満なのに HTTP レスポンスステータスが 200 のものを報告してください。このパターンは、Google がソフト 404 とみなす JS のレンダリング失敗を示します。ページは 200 を返すため「公開中」ですが、実際のコンテンツがなく「空」の状態です。
     • その後、/robots.txt に対して firecrawl_scrape をもう 1 回呼び出します（1 クレジット）。GPTBot、ClaudeBot、PerplexityBot、Google-Extended、ChatGPT-User、Bytespider、CCBot の AI クローラー向け User-Agent ルールを解析します。各エージェントに適用される許可／拒否の範囲を明らかにしてください。
   • Firecrawl が利用できない場合： このステップをスキップします。TECH-AUDIT.md に次のように記載してください：最新シグナル（JS canonical／noindex の不一致、X-Robots-Tag、AI クローラー向け robots.txt ルール、2025 年 12 月の JS SEO リスク）：スキップ — Firecrawl がインストールされていません。

8b. CrUX による CWV のフィールドデータ (google-api.json が存在する場合のみ、tier ≥ 0)

• SE Ranking の監査が報告する CWV はラボデータのみ（Lighthouse 風の推定値）です。CrUX は、Google のランキング評価に使われる、実際の Chrome ユーザーの p75 指標を返します。
• python3 scripts/pagespeed_check.py "https://{domain}" --crux-only --json を実行して、現在の p75 LCP／INP／CLS／FCP／TTFB を取得します。
• python3 scripts/crux_history.py "https://{domain}" --origin --json を実行して、指標ごとの 25 週間の推移（改善／安定／悪化）を取得します。
• CrUX にフィールドデータがない場合（「データ不足」）、その旨を明らかにして続行します。トラフィックの少ないオリジンはよくあります。
• TECH-AUDIT.md に「## Core Web Vitals（フィールドデータ）」という新しいセクションを追加し、各指標の現在の p75 値と推移を記載します。データソースには「CrUX 28-day origin」と明記してください。 8c. GSC URL Inspection による URL ごとのインデックス登録状況（google-api.json が存在し、ティアが 1 以上の場合のみ）
• 手順 5 で特定したトラフィック上位 5 ページ（キーワードデータがない場合は、ホームページと主要なランディングページ）ごとに、以下を実行します。 python3 scripts/gsc_inspect.py "{url}" --site-url "{config.default_property}" --json
• URL ごとに indexStatusVerdict、coverageState、googleCanonical（userCanonical と比較）、lastCrawlTime を記録します。
• 監査で見つかった noindex／canonical の問題と照合します。 GSC が INDEXED と報告している一方で監査が noindex を指摘している場合、監査が古いか、ディレクティブが最近追加された可能性があるため、再監査対象としてフラグを立てます。監査で問題なしと判断したページが GSC で EXCLUDED と報告された場合、SE Ranking の監査では検出できない、隠れたインデックス登録可能性の問題です。
• 重大な問題への引き上げ： トラフィック上位ページで userCanonical ≠ googleCanonical の不一致がある場合は、severity-mapping.md の既定値にかかわらず、重大度「Critical」で Top-10 の修正リストに追加します。Google が別の canonical を選択していることは、現実のランキング問題です。
• このアカウントでプロパティが GSC に確認されていない場合は、「GSC: {domain} が未確認です。Search Console に追加してください」と表示し、8c のみスキップします。
• TECH-AUDIT.md に「## インデックス登録状況の実態確認（GSC URL Inspection）」という新しいセクションを設け、トラフィック上位 5 URL ごとに、ステータス／canonical の不一致／最終クロール日時を 1 行で表示します。
• 詳細な手順と失敗パターンについては、skills/seo-google/references/cross-skill-integration.md § 「seo-technical-audit」を参照してください。

8d. IndexNow の検出 WebFetch

• 検出ロジック — IndexNow は 3 つの方法のいずれかでキーを通知します。次の順序で確認します。
  1. robots.txt のヒント： すでに取得済みの /robots.txt（手順 6）で、IndexNow: ディレクティブまたはキーのファイルパスに言及するコメントを探します。
  2. レスポンスヘッダーのヒント： ホームページの WebFetch（手順 6）から取得したレスポンスヘッダーで、x-indexnow-key、x-indexnow、x-indexnow-key-location を確認します。
  3. 標準パスの確認： (1) または (2) でキーが示された場合は、/<key>.txt に WebFetch します。どちらにもヒントがない場合は、ユーザーのドメインがほかの場所で IndexNow を示している場合（例：robots.txt に Bing Webmaster との連携が記載されている場合）に限り、標準的な場所を少数追加で確認します。
• references/severity-mapping.md § IndexNow に従って、検出結果を分類します。
  • キーがどこにも通知されていない → indexnow_no_key（Low。情報提供のみ — Bing のみが対象）。
  • キーは通知されているが、/<key>.txt の内容が通知されたキーと異なる → indexnow_key_mismatch（Medium）。
  • キーファイルが存在し、キーも一致するが、最近の送信が検出されない → indexnow_not_submitted_recently（Low。情報提供のみ）。
• 可能であれば、最後にキーをローテーションした日付を検出します。キーファイルに WebFetch し、Last-Modified レスポンスヘッダーを読み取ります（ない場合はファイルの Date ヘッダーを使用します）。
• 検出結果は evidence/02-issues-by-category/security.md に記載します（重大な検出結果がある場合は、新たに evidence/02-issues-by-category/indexnow.md を作成してもかまいません。どちらの場合も、TECH-AUDIT.md の「By category」セクションに統合します）。また、TECH-AUDIT.md の「Modern signals」セクションに行を追加し、IndexNow のステータス（設定済み：Y/N）と、検出できた場合は最後にキーをローテーションした日付を表示します。

9. TECH-AUDIT.md をまとめる

出力形式

seo-technical-audit-{target-slug}-{YYYYMMDD}/ フォルダーを作成します。

seo-technical-audit-{target-slug}-{YYYYMMDD}/
├── TECH-AUDIT.md                       (synthesised top-10 fix list + category summary — primary deliverable; inlines 01-audit-summary header + the six 02-issues-by-category/* tables under "By category")
├── issues.csv                          (every issue: code, severity, count, fix, effort — load-bearing CSV engineering pastes into Jira)
├── 03-key-pages-issues.md              (top 5 traffic pages, all their issues — load-bearing reference engineering / on-call consult per-URL)
└── evidence/
    ├── 02-issues-by-category/          (raw per-category tables — preserved in case a reader wants the unmerged view)
    │   ├── crawlability.md
    │   ├── indexability.md
    │   ├── security.md
    │   ├── mobile.md
    │   ├── structured-data.md
    │   └── content.md
    ├── 04-robots-sitemap-snapshot.md   (raw fetched files — preserved for reproducibility)
    └── 05-modern-signals.md            (JS-render canonical/noindex divergence, X-Robots-Tag, AI-crawler rules — requires Firecrawl)

最上位には、TECH-AUDIT.md、issues.csv、03-key-pages-issues.md を配置します。監査サマリーのヘッダー（01-audit-summary）は、すでに TECH-AUDIT.md のヘッダーにあります。カテゴリ別の 6 つのテーブル（02-issues-by-category/*.md）は、TECH-AUDIT.md の「By category」セクションにインラインで配置されています。再現性を確保するため、生のカテゴリファイル、robots／サイトマップのスナップショット、モダンシグナルのダンプは evidence/ に保存します。

TECH-AUDIT.md は次の構成にします。

# Technical Audit: {domain}

> Audit date {YYYY-MM-DD} · Pages crawled: {n} · Health score: {n}/100

## Summary

| Severity | Count |
|---|---|
| Critical | {n} |
| High | {n} |
| Medium | {n} |
| Low | {n} |

## Top 10 fixes (impact × effort)

| Rank | Issue | Severity | Pages | Fix | Effort |
|---|---|---|---|---|---|
| 1 | {issue name} | {severity} | {n} | {one-line fix} | {S/M/L} |
| ... |

## By category

### Crawlability ({n} issues)
- {issue name} ({n} pages) — {fix}
- ...

### Indexability ({n} issues)
- ...

### Security ({n} issues)
- ...

### Mobile ({n} issues)
- ...

### Structured data ({n} issues)
- ...

### Content ({n} issues)
- ...

### Modern signals ({n} findings — Firecrawl)
- {URL} — initial-HTML canonical `{X}` differs from JS-rendered canonical `{Y}` (`js_canonical_mismatch`)
- {URL} — JS-rendered `noindex` not visible to static crawler
- {URL} — `X-Robots-Tag: noindex` at HTTP layer
- {URL} — rendered HTML <50% of initial HTML size (`js_render_budget` — Google may stop rendering before content loads)
- {URL} — title / H1 / meta description differ between initial HTML and post-render DOM (`js_csr_meta_drift`)
- {URL} — rendered body <500 chars but HTTP 200 (`js_soft_404` — likely JS render failure, treated as soft-404 by Google)
- robots.txt — `GPTBot`: {allow / disallow `/path`}, `ClaudeBot`: {…}, `Google-Extended`: {…}, ...
- IndexNow — configured: {Y/N} · key-file: `/<key>.txt` {found / missing / mismatch} · last-key-rotation: {YYYY-MM-DD or "unknown"}
- (Or: `Modern signals: skipped — Firecrawl not installed`)

### Security headers (extended — WebFetch)

| Header | Homepage | Sample 1 | Sample 2 | Sample 3 | Issue |
|---|---|---|---|---|---|
| Content-Security-Policy | {present/absent} | … | … | … | `csp_missing` if absent |
| X-Frame-Options | {present/absent} | … | … | … | `xframe_missing` if absent (informational; CSP frame-ancestors supersedes) |
| X-Content-Type-Options | {`nosniff`/absent/other} | … | … | … | `xcontent_missing` if not `nosniff` |
| Referrer-Policy | {present/absent} | … | … | … | `referrer_policy_missing` if absent |
| HSTS preload | {preload directive Y/N · on Chromium preload list Y/N} | … | … | … | `hsts_no_preload` if not on list |

## Core Web Vitals (field data — CrUX)

| Metric | p75 (current) | 25-week trend | Threshold | Status |
|---|---|---|---|---|
| LCP | {n} ms | {improving/stable/degrading} | ≤2500 ms good · ≤4000 ms needs improvement | {pass/warn/fail} |
| INP | {n} ms | … | ≤200 ms good · ≤500 ms needs improvement | … |
| CLS | {n} | … | ≤0.1 good · ≤0.25 needs improvement | … |
| FCP | {n} ms | … | ≤1800 ms good · ≤3000 ms needs improvement | … |
| TTFB | {n} ms | … | ≤800 ms good · ≤1800 ms needs improvement | … |

Source: CrUX 28-day origin. If insufficient field data: "CrUX: insufficient data for {domain} (low-traffic origin)."
(Or: `CWV (field data): not configured — run `bash extensions/google/install.sh` for setup.`)

## Indexation reality check (GSC URL Inspection)

| URL | Status | userCanonical → googleCanonical | Last crawled |
|---|---|---|---|
| {top-traffic URL 1} | {INDEXED|EXCLUDED|...} | {URL} {→ different URL if divergent} | {YYYY-MM-DD} |
| {top-traffic URL 2} | … | … | … |
| ... |

Source: GSC URL Inspection (Tier 1). If property not verified: "GSC: {domain} not verified — add it in Search Console."
(Or: `Indexation reality check: not configured (Tier 1 setup required).`)

## Key-page deep dives

### {URL with most issues}
{n} issues found. Top fixes:
1. ...
2. ...

## Recommended cadence
Re-run this skill monthly to catch regressions, or wire `seo-drift` to baseline + diff between audits.

issues.csv の列：category,issue_code,issue_name,severity,affected_pages,suggested_fix,effort,priority_score

ヒント

• レート制限（10 req/sec）を守ってください。
• 可能な場合は既存の監査結果を再利用してください。新しい監査の作成は最もコストのかかる処理です。
• 1,000 ページのサイトを新たに監査すると、完了までに 10～30 分かかることがあります。このスキルは完了するまで DATA_getAuditStatus をポーリングします。気長にお待ちください。
• 重大度の尺度は独自のものではなく、SE Ranking の監査に基づいています。影響度 × 工数のスコアリングに一貫性を持たせるため、references/severity-mapping.md を使って対応付けてください。
• 10,000 ページを超えるサイトでは、毎回サイト全体をクロールするのではなく、重要なセクションを個別に監査することを検討してください（SE Ranking で監査 URL フィルターを設定します）。
• 回帰の追跡には seo-drift と併用してください。このスキルはスナップショット、drift は差分です。
• 孤立ページや不足ページの分析には seo-sitemap と併用してください（このスキルの監査データを使用します）。
• 修正を自動適用しないでください。このスキルが診断し、人間がどの修正をどの順番で適用するかを決定します。