mcpField
S
seo-technical

seo-technical

github.com/shawnpangマーケティング・グロース370185 回インストール33 週間前に更新
リポジトリ

seo-technical について

seo-technicalは、サイト運営者やSEO担当者向けのテクニカルSEO監査スキルです。クロール、インデックス、表示速度、構造化データ、AIクローラーを評価し、100点満点のスコアと優先度・工数付きの改善案を提示します。

主な機能

  1. 019つのテクニカルSEO領域を監査
  2. 02100点満点で評価し項目別に採点
  3. 03優先順位付きの改善項目を作成
  4. 04JavaScript描画とインデックスを確認
  5. 05robots.txtのAIクローラー設定を確認

活用シーン

  1. 01既存サイトのテクニカルSEO監査
  2. 02インデックスや順位の問題を調査
  3. 03Core Web Vitalsと表示速度の改善
  4. 04新規サイトや移行のSEO準備

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/shawnpang/startup-founder-skills --skill seo-technical

インストール後、Claude Code で/seo-technicalを入力して読み込まれたか確認します。

詳細

SEO テクニカル

使用する場面

  • 既存サイトのテクニカル SEO 監査を実施する場合。
  • ページがインデックスに登録されない、またはランキングされない原因を診断する場合。
  • Core Web Vitals やページ速度を最適化する場合。
  • サイト構造(サイトマップ、robots.txt、正規化)を設定する場合。
  • 構造化データ/スキーママークアップを実装する場合。
  • robots.txt を通じて AI クローラーのアクセスを管理する場合。
  • 新しいサイトの公開や移行に向けて SEO 対応を準備する場合。
  • JavaScript のレンダリングとインデックス登録への影響を確認する場合。

必要なコンテキスト

  • startup-context から:製品の説明、ターゲットオーディエンス、主要キーワード、現在のドメインとサイト構造。
  • ユーザーから:サイト URL、Google Search Console データへのアクセス(可能な場合)、懸念のある具体的なページ、既知の問題、技術スタック(静的サイト、SPA、WordPress など)、過去にサイト監査を実施したかどうか。

ワークフロー

9つの技術的な観点から監査します。カテゴリー別の内訳とともに、100点満点で採点します。

  1. クロール可能性の監査 — 基盤となる項目です。検索エンジンがサイトをクロールできなければ、ほかの対策は意味がありません。
    • robots.txt に意図しない disallow ルールがないか確認します。
    • XML サイトマップが存在し、Search Console に送信され、最新の状態に保たれているか確認します。
    • クロールエラー(4xx、5xx ステータスコード)を特定します。
    • 孤立ページ(内部リンクが一つもないページ)を確認します。
    • リダイレクトチェーンを監査し、1回の転送にまとめます。3回以上のチェーンはクロールバジェットを無駄にし、リンクエクイティを希薄化させます。
    • 10,000ページ以上のサイトでは、クロールバジェットの効率を分析し、価値の低いページをインデックスから削除します。
  2. インデックス登録の監査 — クロールされたページが実際にインデックス登録されているか確認します。
    • site:domain.com の検索結果と想定されるページ数を比較します。
    • 意図せず適用された noindex タグがないか確認します。
    • 重複コンテンツの問題と canonical タグの不足を特定します。
    • 除外される可能性のある低品質なコンテンツのページがないか確認します。
    • Search Console のインデックスカバレッジレポートで、除外されたページを確認します。
  3. セキュリティと HTTPS — HTTPS はランキングシグナルであり、信頼性を確保するために必要です。
    • HTTP から適切にリダイレクトされ、すべてのページで HTTPS が使われているか確認します。
    • 混在コンテンツの問題がないか確認します。
    • SSL 証明書と HSTS ヘッダーを検証します。
  4. URL 構造 — 短く説明的で、ハイフン区切りのパラメーターのない URL にします。
    • サイト全体で URL のパターンを統一します。
    • URL の差異(末尾のスラッシュ、www の有無)による重複コンテンツがないようにします。
    • すべてのページに自己参照の canonical タグを設定します。
  5. モバイル最適化 — 2024年7月時点で、Google はモバイル版 Googlebot のユーザーエージェントのみを使って、すべてのウェブサイトをクロールし、インデックス登録しています。モバイルファーストは必須です。
    • モバイルとデスクトップでコンテンツが一致している必要があります。
    • モバイル対応のテストツールで確認します。
    • レスポンシブデザインを採用し、横スクロールが発生せず、タップ対象が適切なサイズであることを確認します。
  6. Core Web Vitals — Google はこれらをランキングシグナルとして使用します。現在の目標値は次のとおりです。
    • LCP(最大コンテンツ描画時間): 2.5秒未満を目標とします。改善策:ヒーロー画像を最適化する、遅延読み込みを実装する、CDN を使用する、サーバーの応答時間を短縮する。
    • INP(次の描画までのインタラクション): 200ms 未満を目標とします。INP は2024年3月に FID に代わりました。改善策:JavaScript の実行時間を短縮する、長いタスクを分割する、イベントハンドラーを最適化する。
    • CLS(累積レイアウトシフト): 0.1 未満を目標とします。改善策:画像や埋め込みコンテンツに明示的な寸法を設定する、既存コンテンツの上にコンテンツを挿入しない、font-display: swap を使用する。
    • レンダリングを妨げる CSS/JS、最適化されていない画像、過剰なサードパーティ製スクリプトがないか確認します。
  7. 構造化データ — リッチリザルトを表示するためのスキーママークアップを実装します。
    • ホームページに Organization スキーマを設定します。
    • コンテンツページに Article/BlogPosting スキーマを設定します。
    • 商品ページに Product スキーマを設定します。
    • 適用できる場合は FAQ スキーマを設定します(SERP の表示領域を広げます)。
    • ナビゲーションをわかりやすくするため、BreadcrumbList スキーマを設定します。
    • Google のリッチリザルトテストで検証します。
  8. JavaScript のレンダリング — SPA や JavaScript を多用するサイトでは重要です。
    • canonical タグ、robots ディレクティブ、構造化データは、サーバー側で最初にレンダリングされる HTML に含めます。JavaScript で挿入した場合、Google が確実に処理できないことがあります。
    • 重要なコンテンツで、サーバーサイドレンダリングまたは事前レンダリングが設定されているか確認します。
    • Googlebot が実際に認識する内容と、ユーザーに表示される内容を比較します。
  9. AI クローラーの管理 — robots.txt による AI クローラーの管理は、2025〜2026年における重要な検討事項です。
    • GPTBot(OpenAI)、ClaudeBot(Anthropic)、PerplexityBot、Bytespider(ByteDance)、Google-Extended
    • Google-Extended をブロックしても、Google 検索のインデックス登録や AI Overviews には影響しません。影響するのは Gemini のトレーニングデータのみです。
    • ビジネス上のニーズに基づいて、クローラーごとに許可、ブロック、またはレート制限を決定します。

出力形式

100点満点でスコアを付けた、優先順位付きの監査レポート:

  • 重大な問題(インデックス登録を妨げる、またはランキングを大幅に下げる問題):直ちに修正
  • 影響の大きい改善(ランキングを大きく改善するもの):2週間以内に修正
  • 中程度の改善(段階的な向上が見込めるもの):30日以内に修正
  • 優先度の低い改善(小規模な最適化):都合のよいときに対応

各項目には、問題点、ランキングに影響する理由、修正方法、推定作業量(低/中/高)を記載します。

フレームワークとベストプラクティス

  • canonical タグは提案ではなく指示です:Google はヒントとして扱いますが、適切に実装された canonical は大半のケースで反映されます。各ページには必ず自己参照 canonical を設定し、重複ページには優先するバージョンを canonical として指定してください。
  • JavaScript SEO:canonical、robots、構造化データなどの重要なメタデータは、サーバーで初期レンダリングされる HTML に含める必要があります。Google は JavaScript をレンダリングできますが、遅延や信頼性の問題があります。
  • モバイルファーストは完了しています:2024年7月以降、「デスクトップインデックス」はありません。Google がインデックスに登録するのはモバイル版です。コンテンツの完全な同等性は必須です。
  • INP が FID に取って代わりました:FID は2024年9月までに Chrome のツールから完全に削除されました。パフォーマンスの最適化では、FID ではなく INP(200ms 未満)を目標にしてください。
  • クロールバジェット:1万ページ未満のサイトでは、問題になることはほとんどありません。大規模なサイトでは、価値の低いページを削除し、リダイレクトチェーンを修正することを優先してください。
  • 国際サイト向けの hreflang:正しく実装するか、まったく実装しないでください。エラーがあると、hreflang タグがない場合よりもインデックス登録に悪影響を及ぼします。
  • ログファイル分析:サーバーログからは、クロールしてほしいページと、Googlebot が実際にクロールしているページを確認できます。これはクロール可能性を示す確かな根拠です。
  • 速度は同点の場合の決め手です:それだけでランキングが劇的に変わることはほとんどありませんが、ユーザーの行動指標(直帰率、サイト滞在時間)に影響し、間接的にランキングに影響します。
  • E-E-A-T のシグナルは重要です:資格を明記した著者プロフィール、概要ページ、連絡先情報、信頼できる情報源へのリンク、HTTPS、プライバシーポリシー、利用規約を整備してください。

関連スキル

  • content-strategy — 監査でコンテンツの不足や内容の薄いページが見つかり、より広範なコンテンツ計画が必要な場合
  • landing-page — 主要なランディングページで CRO とオンページ SEO の両方の最適化が必要な場合

例

例1:完全な監査

「サイトを公開してから6か月が経ちますが、Google でほとんど表示されません。SEO を監査してもらえますか?」

良い出力:9つすべての観点を対象にした、100点満点のスコア付き構造化監査。robots.txt が /blog/ ディレクトリをブロックしていること、サイトマップがないこと、複数のページで title タグが重複していること、最適化されていないヒーロー画像が原因でモバイルの Core Web Vitals が不合格(LCP が4.2秒)であること、canonical タグと構造化データがサーバーでレンダリングされるのではなく JavaScript 経由で挿入されていること、AI クローラーのポリシーが定義されていないことを特定します。修正項目を重大、高、中、低に分類し、作業量の見積もりとともに優先順位を付けて提示します。

例2:具体的な問題

「ブログ記事のランキングは良好でしたが、先月トラフィックが40%減少しました。」

良い出力:まず Search Console のデータ確認(手動による対策、クロールエラー、インデックス登録状況の変化)から始め、アルゴリズムアップデートの時期、類似記事間のコンテンツカニバリゼーション、誤って設定された noindex や壊れた canonical、Core Web Vitals の悪化(特に JavaScript を多用したデプロイ後の INP)、被リンクの喪失、モバイルでのレンダリングの問題を調べる診断チェックリスト。原因を特定するために収集すべき具体的なデータと手順も提案します。

コメント