seo-audit-full

seo-audit-full — 高度な包括的 SEO 監査

このスキルは、seo-audit-full ディレクトリから単一ページの包括的な SEO 監査を実行します。 URL のみが指定された場合に seo-audit にルーティングすることはありません。

---

このスキルを使用するタイミング

ユーザーが次のいずれかを依頼した場合は、seo-audit-full を使用します。

• 「seo-audit-full」
• 「包括的な SEO 監査」
• 「高度な SEO 監査」
• 「テクニカル SEO 監査」
• 「詳細な監査」
• 「包括的な SEO レビュー」
• 「すべてを監査」

URL のみのリクエストも有効です。外部データセットが提供されていない場合は、 公開シグナルを使ったワークフロー全体を実行し、レポートに不足しているデータソースを明記してください。

---

想定される入力

入力	必須	備考
ページ URL	はい	監査対象となる主要なページ
主要キーワード	推奨	コンテンツの関連性スコアが向上します
PageSpeed API キー	はい	PageSpeed の全監査チェックに必要です。最初に確認し、キーなしで PageSpeed を実行しないでください。
生の HTML またはページコンテンツ	任意	提供された場合、コンテンツチェックの精度が向上します
GSC／クロール／アナリティクスデータ	任意	提供された場合は含め、提供されていない場合は利用不可と記載します
競合ベンチマークデータ	任意	提供された場合は含めます

包括的な監査の開始時に、ユーザーに PageSpeed Insights API キーを確認してください。

For PageSpeed checks, please provide a Google PageSpeed Insights API key.
Get one here: https://developers.google.com/speed/docs/insights/v5/get-started
Open "Acquiring and using an API key" → "Get a Key".
If you do not provide one, I will stop before running the full audit because
PageSpeed is a required full-audit module.

--api-key、PAGESPEED_API_KEY、または GOOGLE_PAGESPEED_API_KEY で提供された PageSpeed API キーがない場合は、seo-audit-full の PageSpeed チェックを実行しないでください。キーが見つからない場合は、PageSpeed データが不足した状態で完全なレポートを生成せず、処理を中断してユーザーに設定を依頼してください。

---

アーキテクチャ：Full = Core + Performance + Advanced

┌─────────────────────────────────────────────────────────────┐
│  seo-audit-full Workflow                                    │
│                                                             │
│  Phase 1: Run core scripts (./scripts/)                     │
│  ┌──────────────────────────────────────────────────────┐   │
│  │  check-site.py      → robots.txt, sitemap, 404, URL  │   │
│  │  check-page.py      → title, H1, meta desc, slug     │   │
│  │  check-schema.py    → JSON-LD validation              │   │
│  │  fetch-page.py      → raw HTML for analysis           │   │
│  └──────────────────────────────────────────────────────┘   │
│                          ↓                                  │
│  Phase 2: Run performance + full-only scripts (./scripts/)  │
│  ┌──────────────────────────────────────────────────────┐   │
│  │  check-pagespeed.py → Lighthouse scores + metrics     │   │
│  │  check-social.py    → OG Tags + Twitter Card          │   │
│  │  (more scripts added here as modules grow)            │   │
│  └──────────────────────────────────────────────────────┘   │
│                          ↓                                  │
│  Phase 3: LLM-only advanced checks                         │
│  ┌──────────────────────────────────────────────────────┐   │
│  │  E-E-A-T content quality scoring                      │   │
│  │  Duplicate content signals                            │   │
│  │  Anchor text quality assessment                       │   │
│  └──────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────┘

---

出力

テンプレート assets/report-template.html に内容を入力して、高度な包括的 SEO 監査レポートを作成し、 ファイルに保存してください。HTML をそのままターミナルに出力してはいけません。

ファイル名： reports/<hostname>-<slug>-full-audit.html

https://example.com/blog/best-tools → reports/example-com-blog-best-tools-full-audit.html
https://example.com/                → reports/example-com-full-audit.html

保存後、ユーザーに次のように伝えてください：

✅ Full Report saved → reports/example-com-full-audit.html
   Open it now? (yes / no)

「はい」の場合 → 実行：open reports/example-com-full-audit.html

テンプレートのプレースホルダー — それぞれ個別に入力してください。

プレースホルダー	内容
{{summary_verdict}}	実行したチェックの総数と、失敗／警告／合格の数を示す一文
{{summary_critical_html}}	重大な項目ごとに <li> を記述するか、該当なしの場合は <li class="summary-empty">None</li>
{{summary_warnings_html}}	警告項目ごとに <li> を記述するか、該当なしの場合は <li class="summary-empty">None</li>
{{summary_passing_html}}	合格したチェックごとに <li> を記述するか、該当なしの場合は <li class="summary-empty">None</li>
{{pagespeed_checks_html}}	check-pagespeed.py の出力を使った PageSpeed モジュール全体
{{site_checks_html}}	サイトレベルのチェックテーブル
{{eeat_checks_html}}	E-E-A-T 信頼性ページのテーブル
{{page_checks_html}}	Full のみの追加項目を含む、ページレベルのチェックテーブル
{{priority_actions_html}}	優先度順のアクションリスト
{{insights_html}}	任意の調査結果を順に説明するカード

---

スクリプト

このディレクトリから完全版のスクリプトを実行してください。すべての出力は構造化 JSON です。証拠としてそのまま使用してください。

依存関係： pip install requests

フェーズ 1：コアスクリプト

# 1. site-level checks (robots.txt + sitemap.xml + 404 + URL canonicalization)
python scripts/check-site.py https://example.com

# 2. page-level checks (H1, title, meta description, canonical, URL slug)
python scripts/check-page.py https://example.com --keyword "primary keyword"

# 3. fetch raw HTML for downstream scripts
python scripts/fetch-page.py https://example.com --output /tmp/page.html

# 4. JSON-LD schema validation
python scripts/check-schema.py --file /tmp/page.html

フェーズ 2：Full のみのスクリプト

# 5. PageSpeed / Lighthouse checks
python scripts/check-pagespeed.py https://example.com --strategy mobile --timeout 180 --api-key "USER_PROVIDED_KEY"
# If no key was provided, do not run this command. Ask the user to configure a PageSpeed API key first.

# 6. Social tags: OG + Twitter Card validation
python scripts/check-social.py --file /tmp/page.html
# Or directly from URL:
python scripts/check-social.py https://example.com

各スクリプトは、すべて合格または警告の場合は終了コード 0、失敗またはエラーがある場合は 1 で終了します。

PageSpeed の実行には 200 秒かかることがあります。デフォルトでは 180 秒のタイムアウトを設定してください。それでもタイムアウトする場合は、Page Speed モジュールを error として記録し、PageSpeed API がタイムアウトしたことを明記してください。これをページパフォーマンスの失敗が確認されたものとして扱わないでください。 キーが提供された後に Google がクォータまたは API キーのエラーを返して PageSpeed が失敗した場合は、監査を続け、次の案内を記載して PageSpeed モジュールを error として出力してください。 https://developers.google.com/speed/docs/insights/v5/get-started → 「API キーの取得と使用」→「キーを取得」から PageSpeed API キーを取得してください。

---

対象範囲 — Full 監査チェックのホワイトリスト

Full では、独自のコアチェックと、以下で ★ が付いた Full のみの項目を実行します。

サイト全体のチェック（{{site_checks_html}} 内）

主なチェック項目：

• サイトマップ URL 一覧 · ステージングサブドメインのインデックス登録 · robots.txt · sitemap.xml · 404 の処理 · URL の正規化 · i18n / hreflang

ステージングサブドメインのインデックス登録ルール：

• robots.txt を確認する前に、一般的なステージング／テスト用ホストを確認します：test., staging., dev., preview., beta., uat.
• ステージング／テスト用サブドメインが一般公開され、本番サイトとよく似ており、認証、noindex、またはクロールをブロックする robots.txt で保護されていない場合は、不合格とします。
• ステージング／テスト用サブドメインが一般公開されているものの、類似性またはインデックス保護を確認できない場合は、警告とします。
• 一般公開されたステージング／テスト用サブドメインが検出されない場合、または検出されたステージングホストが認証、200 以外のアクセス、noindex、または Disallow: / で保護されている場合は、合格とします。
• 影響として、インデックス登録可能なページが重複することを説明します。Google は test.example.com と www.example.com を、別個ながら非常によく似た URL として扱う場合があり、ランキングシグナルが分散し、本番サイトと競合する可能性があります。
• 推奨される修正方法：まず Basic Auth／パスワード保護を追加します。さらに、ステージングホストで User-agent: * と Disallow: / を使ってクローラーをブロックします。ページに引き続きアクセスできる場合は、ページ単位で noindex を追加します。

サイトマップ URL 一覧のルール：

• {{site_checks_html}} の最初のモジュールとして、クロール可能性テーブルより前に配置します。
• 独立したテーブルとして表示し、列は「ディレクトリ · URL 数 · ページタイプ · 代表的なページ」とします。
• check-site.py の sitemap_inventory 出力を使って、第 1 階層のディレクトリ、URL 数、推定されるページタイプ、代表的な URL を 1 つまとめます。
• これはサイト全体のマップとして扱い、単一ページの SEO 監査における合否判定とはしません。
• サイトマップ URL を解析できない場合を除き、ステータスには info を使用します。より詳しい根拠なしに、ディレクトリ内の URL 数が多いか少ないかを理由としてサイトにペナルティを課さないでください。
• 次のステップとして、ユーザーが /blog/、/tools/、/alternatives/、/templates/、/use-cases/ などの主要ディレクトリから代表的なサンプル URL を選び、さらに詳しい完全監査を続けられることを必ず記載します。

ページ速度のチェック（{{pagespeed_checks_html}} 内）

完全監査のみ：

• Lighthouse のカテゴリ別スコア：パフォーマンス · アクセシビリティ · ベストプラクティス · SEO
• ラボ指標：FCP · LCP · TBT · CLS · Speed Index
• 最終 URL とスクリーンショットの利用可否

E-E-A-T チェック（{{eeat_checks_html}} 内）

基本チェック：

• About Us · Contact · Privacy Policy · Terms of Service · Media/Partners（存在する場合のみ）

Contact の判定ロジック（Contact の行のみ）：

• 専用の /contact ページは必須ではありません
• 次のいずれかの方法で連絡できる場合は合格です：専用の問い合わせページ（HTTP 200）· 連絡先情報が記載された About ページ · フッター／ナビゲーションの mailto、メールアドレス、ソーシャルリンク、問い合わせフォーム
• サイト内のどこにも連絡手段がない場合に限り不合格です
• About またはフッター／ナビゲーションに連絡先情報が記載されている場合、/contact がないことだけを理由に不合格にはしません

E-E-A-T のインフラストラクチャルール — 信頼性を示す各ページを 2 つのレイヤーで確認：

• レイヤー 1 — 存在： 信頼性を示すページの URL が HTTP 200 を返す（Contact には上記の Contact 固有ルールを適用）
• レイヤー 2 — 到達可能性： フッターまたはメインナビゲーションからリンクされている

ページ	必須
About Us	はい
Contact	はい — 専用ページは任意。About またはフッター／ナビゲーションの連絡先情報があれば満たします
Privacy Policy	はい
Terms of Service	はい
Media / Partners	いいえ — 存在する場合のみ含めます

ステータスのルール（About、Privacy、Terms、Media/Partners）：

• ページが存在しない（200 以外）→ 不合格
• ページは存在するが、フッター／ナビゲーションからリンクされていない → 警告
• ページが存在し、フッター／ナビゲーションからリンクされている → 合格
• 任意のページが存在しない → スキップし、行に含めない

Contact 固有のルール：

1. 一般的なパス（/contact、/contact-us）を確認します — HTTP 200 なら「存在」とみなします
2. 問い合わせページがない場合は、About ページ本文にメールアドレス、ソーシャルリンク、または連絡先情報があるか確認します
3. ホームページのフッターとナビゲーションも確認し、mailto:、表示されているメールアドレス、ソーシャルリンク、または問い合わせフォームを探します
4. いずれかの連絡手段が見つかった場合、「存在」は合格です
5. どこにも連絡先情報が見つからない場合に限り、「存在」は不合格です
6. フッター／ナビゲーションに問い合わせページへのリンクまたは連絡先情報がある場合、「到達可能性」は合格です
7. About ページの本文からのみ連絡でき、フッター／ナビゲーションから直接アクセスできない場合、「到達可能性」は警告です
8. About またはフッターに連絡先情報がある場合、/contact の作成を推奨しないでください

ページ単位のチェック（{{page_checks_html}} 内）。次の順序で出力してください：

基本チェック： URL スラッグ · タイトルタグ · メタディスクリプション · H1 タグ · canonical タグ · 画像の代替テキスト · 単語数 · キーワードの配置 · 見出し構造 · 内部リンク · スキーマ（JSON-LD）

スキーマ（JSON-LD）のルール：

• スキーマは、存在の有無だけでなく品質も確認してください。
• JSON-LD の解析可能性、想定される @type、必須フィールド、推奨されるリッチリザルト用フィールド、ネストされたフィールド、主要タイプの競合を検証してください。
• JSON-LD が無効な場合、想定されるスキーマタイプがない場合、必須フィールドが欠けている場合、またはローカライズされたスキーマが明らかに誤った言語／URLを示している場合は不合格です。
• 推奨フィールドが欠けている場合、ネストされたフィールドが不完全な場合、多言語ページに inLanguage がない場合、またはローカライズされたスキーマを完全に確認できない場合は警告です。
• 想定されるスキーマタイプがあり、必須フィールドがそろい、競合がなく、該当する場合はローカライズされたスキーマが現在のページの言語／URLと一致している場合に限り合格です。
• 多言語ページでは、各言語版に対応する独自のスキーマを設定してください。inLanguage は各言語と一致させ、存在する場合は言語固有の headline／description を設定し、url／mainEntityOfPage は現在のローカライズされた canonical URL を指すようにしてください。

★ フル版のみの追加項目：

• OG タグ — og:title、og:description、og:image、og:type、og:url の有無と妥当性
• Twitter Card — twitter:card のタイプ、title／description／image（OG のフォールバック検出を含む）

---

スクリプトの JSON 出力の使用方法

すべての監査モジュールで同じルールを適用します。各フィールドの status をレポートのチェック表に直接対応させてください。

• status → pass ／ warn ／ fail ／ error → レポートのバッジ
• detail → Evidence 行の出発点
• 追加で確認可能な証拠がない限り、スクリプトの出力と矛盾する内容を記載しないでください

check-site.py の出力について：

• staging_subdomains.status → Staging Subdomain Indexation 行のステータス
• staging_subdomains.detail → Staging Subdomain Indexation 行の詳細
• staging_subdomains.public_hosts → 公開されているステージング／テストホストの証拠
• staging_subdomains.similar_hosts → 本番環境に類似したステージングの重複に関する失敗の証拠
• robots.status → robots.txt 行のステータス
• sitemap.status → sitemap.xml 行のステータス
• sitemap_inventory.status → Sitemap URL Inventory モジュールのステータス
• sitemap_inventory.directories[] → path、url_count、page_type、example_url を含む表の行
• sitemap_inventory.detail → インベントリ表の下に記載する短い説明

check-schema.py の出力について：

• status → Schema (JSON-LD) 行のステータス
• detail → Schema (JSON-LD) 行の詳細
• parse_errors → JSON-LD の形式不正に関する失敗の証拠
• schemas[].fields_missing → 必須のスキーマフィールドの欠落に関する失敗の証拠
• schemas[].recommended_missing と schemas[].nested_issues → 警告の証拠
• localized_schema.status → 多言語スキーマの言語／URL の整合性ステータス
• localized_schema.issues → スキーマの言語または URL の不一致に関する証拠

check-social.py の出力について：

• og.status → OG Tags 行のステータス
• twitter_card.status → Twitter Card 行のステータス
• og.fields.* → 詳細セルに記載する個々のフィールドの詳細
• twitter_card.fields.* → フォールバックフィールドに注意して記載する個々のフィールドの詳細

check-pagespeed.py の出力について：

• status → Page Speed 全体のステータス
• category_status → Lighthouse Scores バッジのステータス
• metric_status → Core Lab Metrics バッジのステータス
• final_url → Final URL 行
• categories.performance.score → Performance スコア
• categories.accessibility.score → Accessibility スコア
• categories["best-practices"].score → Best Practices スコア
• categories.seo.score → SEO スコア
• compact_metrics.fcp.display_value → FCP
• compact_metrics.lcp.display_value → LCP
• compact_metrics.tbt.display_value → TBT
• compact_metrics.cls.display_value → CLS
• compact_metrics.si.display_value → Speed Index
• screenshot が真値 → スクリーンショットを利用可能

Lighthouse Scores バッジには、全体の status を使用しないでください。カテゴリスコアの Lighthouse しきい値は、90～100 が pass、50～89 が warn、0～49 が fail です。例：Performance が 60、Accessibility が 84、Best Practices が 100、SEO が 100 の場合、category_status は warn です。LCP または Speed Index が基準を満たさない場合、Lighthouse Scores パネルが warn のままでも、metric_status と全体の status が fail になることがあります。

{{pagespeed_checks_html}} 内では、スコア／メトリクスカードの後に、短い Priority Actions リストを含めてください。PageSpeed の失敗または警告フィールドに基づき、簡潔な項目を 2～4 件記載します。

• LCP が遅い → ヒーロー画像などのメディアを最適化し、重要な画像をプリロードして、レンダリングを妨げる CSS を削減する
• Speed Index が遅い → 重要度の低いスクリプトの実行を遅らせ、ファーストビューの JS／CSS を削減する
• TBT が高い → 長時間タスクを分割し、サードパーティのタグを遅延させる
• Performance スコアが警告／失敗 → Lighthouse で最も改善効果の大きい項目を優先する

公式の診断リンクを必ず含めてください。 https://pagespeed.web.dev/

---

LLM レビューの指示

LLM による基本レビュー

レポートを作成する前に、llm_review_required: true のすべてのフィールドを確認してください。 H1 の意味的な判断、Title のキーワード位置、URL Slug の評価、Meta Description の品質について、明示的な判断を記載する必要があります。

Full のみの LLM チェック

OG Tags の品質（必ずレビュー）：

og:title   : Does it differ meaningfully from <title>? It should be optimized for social sharing.
og:description : Is it compelling for social feeds? Different focus than meta description is OK.
og:image   : Is the URL an actual image path (not a page URL)?

Twitter Card の完全性：

If twitter:card is "summary_large_image", twitter:image (or og:image fallback) must be
at least 300x157px. Flag if the image URL looks like a small icon or favicon.

---

推奨ワークフロー

1. 対象範囲全体を確認する — これは完全な監査であることを確認します
2. 主要キーワードを推定する — ユーザーから指定がない場合は、ページの H1、タイトル、最初の段落を読みます
3. フェーズ 1：コアスクリプトを実行する — check-site → check-page → fetch-page → check-schema
4. フェーズ 2：完全監査のみのスクリプトを実行する — PageSpeed API キーが存在することを確認してから、check-pagespeed → check-social を実行します
5. コアチェック — 404 の処理、URL の正規化、E-E-A-T の信頼性を示すページ、i18n/hreflang
6. PageSpeed チェック — Lighthouse のカテゴリスコアとラボ指標を要約します
7. LLM 専用の高度なチェック — E-E-A-T のコンテンツ品質、重複コンテンツの兆候、アンカーテキストの品質
8. 調査結果を要約する — 根拠／影響／修正の形式
9. 優先アクション — 影響度が最も高い修正を 5 件、工数／影響度タグ付きで示します
10. レポートを生成する — reports/<hostname>-<slug>-full-audit.html に保存します

---

レポート詳細の記述ルール

書式を厳守してください。

合格 → 短いフレーズを 1 つ。リストや詳述は不要です。

警告 → <div class="detail-issue"> を 1 つ使い、箇条書きは最大 2 件にします。<div class="detail-fix"> を 1 つ使います。

不合格 → 警告と同じ形式です。正確な失敗内容から始めます。

---

必須の調査結果形式

**Finding: [Finding Title]**

- **Evidence:** [Observable fact, data point, or marked assumption]
- **Impact:** [SEO / UX consequence]
- **Fix:** [Actionable recommendation with example]

優先アクションには、工数／影響度タグを追加します。

1. [High Impact / Low Effort] Fix og:image — social shares currently show no preview.

---

参考ファイル

• 詳細な監査モジュールとフィールド定義：references/REFERENCE.md
• 最終 HTML レポートのテンプレート：assets/report-template.html
• PageSpeed 検証スクリプト：scripts/check-pagespeed.py
• ソーシャルタグ検証スクリプト：scripts/check-social.py
• コアスクリプト：scripts/（check-site、check-page、check-schema、fetch-page）