site-launch-checklist

Name: site-launch-checklist
Author: samber

github.com/samberテスト・品質2414.8k 回インストール4 週間前に更新

リポジトリ

site-launch-checklist について

ウェブサイトの公開準備と設定を監査する対話型ワークフローです。Cloudflare DNS、Vercel ホスティング、PostHog、法務面を中心に、新しいサイトを公開するチームを支援します。

主な機能

01対話型の公開判断チェックポイント
02SLC に基づく公開準備ゲート
0310段階の監査と検証
04サイト種別に応じたスキル選定
05トーン設定と文章推敲の指針

活用シーン

01サイトが公開可能な状態かの評価
02新規サイトやドメイン移行の計画
03公開項目の段階的な確認と修正
04プロジェクトに合うスキル群の選定

インストール

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

$npx skills add https://github.com/samber/cc-skills --skill site-launch-checklist

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

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

assets/

weekly-seo-antigravity.md

weekly-seo-claude-code.md

weekly-seo-copilot-cli.md

weekly-seo-gemini-cli.md

weekly-seo-opencode.md

weekly-seo-vibe-prompt.md

weekly-seo-vibe.toml

evals/

evals.json

references/

decisions.md

directory-list.md

positioning-variations.md

submission-tracker-template.csv

templates.md

weekly-seo-agent.md

詳細

質問： 環境の質問ツールを使ってユーザーに質問してください。プレーンテキストの文章で質問してはいけません。一度に1つの質問をし、タップできる選択肢を2～4個提示して、回答を待ってください。環境に質問ツールがない場合は、同じ選択肢を示して、文章で一度に1つずつ質問してください。

サイト公開チェックリスト

新しいWebサイトを公開するための、公開前監査とセットアップのワークフローです。Cloudflare DNS、Vercelホスティング、PostHog、法的事項を前提としています。

対話のスタイル（最初に読む）

このスキルは意図的に対話形式になっています。決めつけず、積極的に質問してください。ユーザーは入力するのではなく、タップして回答します。

実行開始時には、必ず次の質問をこの順番で一度に1つずつ行ってください。

サイトの種類：doc-site | marketing/lead-gen | SaaS-app | training/paid-course | personal-portfolio
移行：greenfield-new-domain | migration-need-301-redirects | replacing-existing-on-same-domain
多言語対応：single-locale | en | fr+en | other-multi
PostHog のセットアップ：hogpost.samber.dev | set-up-new-proxy | skip-PostHog
AI スクレイパーのポリシー：use-default-for-site-type | customize-per-bot | block-all
ブラウザーツールの利用可否：claude-chrome-extension | playwright | neither-skip-browser-checks

各フェーズを通じて、意思決定の場面では必ず質問してください。 以下の項目も含まれます。

Sentry、BetterStack、Crisp をインストールするかどうか（サイトの種類によって異なります。必ず明示的に質問してください）
www と apex のどちらを正規URLにするか（多くのサイトでは apex ですが、必ず質問してください）
ユーザーが customize-per-bot を選択した場合、許可する AI ボット
CSP の厳格さのレベル：strict-default-src-none | balanced-allow-self | permissive-for-marketing
フェーズ全体をスキップするかどうか（例：フランス向けでないサイトではフェーズ3をスキップ）

ユーザーから明示的な入力を得る前に、意思決定の場面を先に進めてはいけません。確認を挟まずに長いチェックリストを提示することが目的ではありません。

ユーザーの明示的な確認なしに、MCP サーバーやスキルをインストールしてはいけません。 npx skills add、claude mcp add、または同等のインストールコマンドを実行する前に、必ず質問ツールを使って確認してください。スキル選択のワークフローで厳選されたサブセットが提案された場合も同様です。

このスキルの使い方

セッション開始時の上記の質問を行います。
フェーズ1～10を順番に進めます。各フェーズでは、以下を行います。a. 項目を一覧表示し、スキップする項目があるか尋ねます。b. 残りの各項目について、検証コマンド（下記の「検証ツール」を参照）を実行します。c. 合格／不合格を報告します。不合格の場合は、今すぐ修正するか、後で対応するかをユーザーに尋ねます。
最後に、フェーズごとにまとめた状況報告を作成し、ブロッカー、推奨する修正、任意の改善点を明確に分けて記載します。

フェーズ 0：ローンチ準備のゲート

ほかのフェーズに進む前に、必ず実施してください。 製品は自らマーケティングをしてくれません。しかし、準備が整っていない製品もマーケティングにはつながりません。ローンチの仕組みが成果をもたらすのは、ローンチする価値のあるものをローンチする場合だけです。

両極端の失敗パターンが、ローンチを台無しにします。

ステルスモード — ローンチが遅すぎる状態です。「しゃれた服を着た先延ばし」です。製品が完璧になるのを待ちながら、非公開のまま磨き続けます。いつまでも出荷されず、誰にも存在を知られません。
「機能をあと 1 つだけ」 — いつまでもローンチしない状態です。ローンチ予定日が決まるたびに、もう 1 つ機能を加えるために延期されます。スコープは際限なく膨らみ、ローンチは実現しません。

中間の道が、SLC — シンプル、愛される、完成している（Jason Cohen）です。これは、最小限ではあるものの愛されない、必要最低限の MVP を出荷することへの解毒剤です。誰も欲しがらない試作品をローンチしてはいけません。肥大化した何でもアプリを待ち続けてもいけません。ローンチ可能な v1 とは、次のようなものです。

シンプル — _1 つ_のことをします。多くのことを中途半端にするのではありません。明確な役割を 1 つ、うまく果たします。
愛される — 単に我慢して使うのではなく、人々が_使いたい_と思うものです。MVP は「フィードバックをもらうため」に、削ぎ落とした体験をユーザーに我慢してもらうものです。SLC は、ユーザー自身が選んで使いたいと思うものを提供します。失ったら悲しむ人が誰もいないなら、まだ愛されているとは言えません。
完成している — 明らかな穴のある試作品ではなく、その 1 つのことを_一通り_体験できます。より大きな約束の予告編ではなく、選んだスコープの中で完成している状態です。

ゲート： まだシンプル、愛される、完成している、の条件を満たしていない場合、スコープの追加が不足しているときだけ「機能をあと 1 つだけ」の状態です。それ以外はステルスモードなので、出荷すべきです。1 つのことが愛され、完成している状態になるまでスコープを削り、それをローンチしてください。SLC なら、完璧なローンチをいつまでも待つのではなく、今すぐ本当のローンチができます。

フェーズを実行する前の簡単なチェック：

明確に定義された 1 つのことを実行できますか？（シンプル）
対象ユーザーは、ただ我慢するのではなく、_自ら選んで_使いたいと思いますか？（愛される）
その 1 つのことを一通り体験でき、明らかな未完成部分はありませんか？（完成している）
この基準を超えて磨き続けていますか？ → やめてください。ステルスモードです。出荷しましょう。
まだスコープに新しいものを追加していますか？ → やめてください。「機能をあと 1 つだけ」の状態です。SLC に戻るまで削減しましょう。

ディレクトリへの登録準備状況（directory-submissions スキルより）： 次の 9 つの質問を確認してください。1 つでも「いいえ」があれば、準備は整っていません。まず不足しているものを作るのを手伝いましょう。

製品は一般に公開されていますか（パスワードの壁がありませんか）？
料金ページはありますか（「ベータ期間中は無料」でも可）？
プライバシーポリシーと利用規約は公開されていますか？
ロゴのアセットは PNG と SVG、正方形、ファビコンの形式でそろっていますか？
実際のスクリーンショットが 5～8 枚と、60～90 秒のデモ動画がありますか？
ランディングページは GEO に対応していますか（H1 は 1 つ、階層は順序どおり、FAQ スキーマ、構造化データ）？
代替製品のページが 3 つ以上、ユースケースのページが 3 つ以上公開され、インデックスされていますか？
（カテゴリに該当する場合）テンプレートギャラリーまたはリードマグネットのアセットがありますか？
G2 にレビューを投稿できるベータ版または早期ユーザーが少なくとも 20 人いますか？

1～7 のいずれかが「いいえ」の場合は、ローンチを進められません。8～9 のいずれかが「いいえ」の場合は、ローンチはできますが、Tier 2 のレビュー価値と Typeform 形式の複利効果を失います。

ORB チャネル戦略（launch スキルより）： ローンチマーケティングを 3 種類のチャネルに分けて構成します。最終的には、すべてをオウンドチャネルにつなげてください。

オウンドチャネル

チャネルを自分で所有します（ただし、オーディエンスを所有するわけではありません）。アルゴリズムやプラットフォームのルールに左右されず、直接アクセスできます。

メールリスト、ブログ、ポッドキャスト、ブランドコミュニティ（Slack、Discord）、ウェブサイト／製品
オーディエンスに応じて 1～2 つから始めます： 業界に質の高いコンテンツが不足している → ブログ。直接の更新情報を求める人が多い → メール。エンゲージメントが重要 → コミュニティ

レンタルチャネル

可視性を提供するものの、自分では管理できないプラットフォームです。アルゴリズムは変化し、ルールは変わり、広告費が必要な場面は増えていきます。

ソーシャルメディア（Twitter/X、LinkedIn、Instagram）、アプリストア、YouTube、Reddit
正しい使い方： オーディエンスが活動しているプラットフォームを 1～2 個選びます。オウンドチャネルへのトラフィック誘導に使います。唯一の戦略として頼らないでください

借りたチャネル

他者のオーディエンスを活用し、最も難しい部分である「認知されること」を近道しましょう。

ゲストコンテンツ（ブログ記事、ポッドキャストのインタビュー、ニュースレターでの紹介）
コラボレーション（ウェビナー、共同マーケティング、SNSのアカウント引き継ぎ）
講演の機会（カンファレンス、パネルディスカッション、オンラインサミット）
インフルエンサーとのパートナーシップ
積極的に動きましょう： オーディエンスがフォローしている業界のリーダーをリストアップ → 双方にメリットのあるコラボレーションを提案 → SparkToro や Listen Notes などのツールを使って、オーディエンスの重なりを探します

審査を通過したら、以下のフェーズに進みます。

コピーライティングの文体とヒューマナイズの工程

すべてのサイトには、目に見えるマーケティングコピー（ヒーローセクション、機能紹介、CTA、メタディスクリプション、OG ディスクリプション、ブログ記事、404 ページのテキスト）があります。公開前には、次の 2 つの仕上げが必須です。

1. サイトごとに一度だけ `TONE.md` を定義する

ユーザーに次のように尋ねます：「このサイトにはすでに TONE.md がありますか？」（yes-already-exists | no-create-from-template | skip-use-default）。

作成する場合は、.agents/TONE.md またはリポジトリのルートにある TONE.md に保存します。構成については references/templates.md の「TONE.md template」セクションを参照してください。

TONE.md には、文体（簡潔、逆張りなど）、禁止する表現（例：「delve」「crucial」、em ダッシュ、AI らしい書き出し）、好みの文の長さ、読者の読解レベル、ユーザー自身の文章から抜き出した良い例と悪い例を記載します。

2. 対応する言語でヒューマナイズの工程を実行する

コピーを作成する各工程の後（コピーライティングスキルを使った場合、手作業の場合、Claude が直接作成した場合を問わず）、ヒューマナイザーを実行して AI らしいパターンを取り除きます。

セッションの開始時に、サイトの主要なオーディエンスの言語がまだ分かっていなければ、ユーザーに尋ねます。

english-global → npx skills add https://github.com/blader/humanizer --skill humanizer
french → samber/cc-skills@humaniseur-fr（フランス語専用のカスタムヒューマナイザー）または同等のフランス語調整済みスキルを使用します
other → 利用可能であれば対応するヒューマナイザーをインストールします。なければ、スキルが言語に応じた短いアンチパターンのチェックリストをその場で作成します

次の内容にヒューマナイザーを適用します：ヒーローコピー、機能の説明、CTA ボタン、メタディスクリプション、OG／Twitter カードの説明、ブログ記事、メール登録の確認メッセージ、404 ページのテキスト。法的ページ（mentions légales、CGV）は、厳格な文言要件があるため対象外とします。

3. コピーライティングスキルを呼び出す際は、必ず TONE.md を参照する

コピーライティングまたはコンテンツ作成のサブスキル（スキル選択のワークフローに従って呼び出し時に選択）に作業を委任する場合は、プロンプトのコンテキストに TONE.md を含めます。文体の制約を明示して、「.agents/TONE.md に従ってください。記載されたパターンを避けてください。作成後にヒューマナイザーを適用してください」と伝えます。

ブラウザー操作の優先事項

多くのチェックには実際のブラウザーが必要です（Lighthouse の実行、securityheaders.com のスキャン、opengraph.xyz の検証、Twitter カードバリデーター、モバイルビューポート、スクリーンリーダーの簡易テスト、Network タブの調査）。

常に Claude Chrome 拡張機能を優先してください。 Chrome 拡張機能が利用できない場合に限り、Playwright に切り替えます。どちらも利用できない場合は、ブラウザーチェックをすべてスキップするか、利用可能になるまで待つかをユーザーに尋ねます。

検証ツール

ほとんどのチェックは、サードパーティーのサービスを使わずにコマンドラインから実行できます。各フェーズでこれらのツールをその場で使います。Cloudflare／Vercel／Google のダッシュボードに表示される情報だけを信用せず、curl で検証してください。

DNS（フェーズ 1）：

dig +short A example.com                          # A record
dig +short AAAA example.com                       # AAAA (IPv6)
dig +short MX example.com                         # MX (mail)
dig +short TXT example.com                        # SPF + verification TXT
dig +short TXT _dmarc.example.com                 # DMARC
dig +short TXT default._domainkey.example.com     # DKIM (selector varies)
dig +short CAA example.com                        # CAA
dig +dnssec example.com | grep RRSIG              # DNSSEC active

TLS／HTTPS（フェーズ 1）：

curl -sIL https://example.com | head             # follow redirects
curl -sI https://www.example.com                 # check www handling
openssl s_client -showcerts -connect example.com:443 < /dev/null 2>/dev/null | openssl x509 -noout -dates

ヘッダー（フェーズ 4）：

curl -sI https://example.com | grep -iE 'content-security-policy|strict-transport-security|x-frame-options|x-content-type-options|referrer-policy|permissions-policy'
# Full header dump:
curl -sI https://example.com
# External graders:
curl -s "https://api.securityheaders.com/?q=https://example.com&followRedirects=on&hide=on" -I | grep -i 'x-grade'

SEO ファイル（フェーズ 5）：

curl -s https://example.com/robots.txt
curl -sI https://example.com/sitemap.xml
curl -s https://example.com/sitemap.xml | head -40
curl -s https://example.com/llms.txt
# Schema (JSON-LD):
curl -s https://example.com/ | grep -A 50 'application/ld+json'
# hreflang:
curl -s https://example.com/ | grep -i hreflang

Open Graph とソーシャル（フェーズ 6）：

curl -s https://example.com/page | grep -iE 'og:|twitter:|<title|name="description"'

ファビコンとマニフェスト（フェーズ 7）：

curl -sI https://example.com/favicon.ico
curl -sI https://example.com/favicon.svg
curl -sI https://example.com/apple-touch-icon.png
curl -s https://example.com/manifest.json | jq .

404／500／リダイレクト：

curl -sI https://example.com/this-does-not-exist
curl -sIL https://example.com/old-url     # verify 301 chain

該当するコマンドを必ず実行し、報告時には出力をユーザーに貼り付けてから、すぐに修正するか、後で対応するかを尋ねます。

フェーズ 1：ドメインとインフラストラクチャ

ドメインが Cloudflare にある場合、この作業の大部分は Cloudflare のダッシュボードからワンクリックで行えます。

最初に確認します：「ドメインはすでに Cloudflare 上にあり、以前のローンチ時の標準設定が適用されていますか？」（yes-standard | yes-needs-review | no-fresh-setup）

チェックリスト：

バックアップ

ローンチ時にバックアップを設定しなければ、その後も設定することはありません。今すぐ設定してください。

ユーザーに確認します：「このアプリが書き込むデータストアはどれですか？」（database-only | database-plus-file-storage | file-storage-only | stateless-no-persistent-data）。stateless-no-persistent-data の場合、このセクションはスキップしてください。

データベース：

プロバイダー側で毎日の自動バックアップを有効化（Neon、Supabase、PlanetScale、Railway、RDS にはそれぞれワンクリックで切り替える設定があります）。バックアップパネルを開き、直近のバックアップ日時が新しいことを確認します。
保持ポリシーを 30 日以上に設定
利用可能な場合はポイントインタイムリカバリ（PITR）を有効化（Neon、Supabase、RDS はいずれも対応しています）
オフサイトコピー：プロバイダーがプライマリと同じリージョンにバックアップを保存する場合は、クロスリージョンレプリケーションを設定するか、別のストレージアカウント（S3、R2、GCS）に毎晩エクスポートします。
ローンチ前にリストア訓練を実施：新しいバックアップを選び、ステージングデータベースにリストアして、行数とサンプルクエリを確認します。テストしていないバックアップはバックアップとはいえません。

ファイルストレージ（該当する場合 — S3、R2、GCS、Cloudflare Images）：

プライマリバケットでバージョニングを有効化
クロスリージョンレプリケーション、またはセカンダリバケットへの定期同期を設定します。Backblaze B2 は、オフサイトコピー向けの安価で信頼性の高い選択肢です（S3/GCS のデータ転送料金より大幅に安価です）。rclone を使って、毎日の cron で S3/R2/GCS から B2 に同期します。
ライフサイクルルール：古いバージョンを 30 日後に低コストのストレージへ移行し、90 日後に削除します（コスト許容度に応じて調整してください）。

シークレット／環境変数：

すべての環境変数を文書化し、シークレットマネージャー（1Password、Doppler、Vault、または同等のもの）に保存します。誰かのノートパソコンにある .env ファイルには保存しないでください。
確認：今夜、すべてのエンジニアのマシンが壊れたとしても、新しいチームメンバーがシークレットマネージャーと git だけを使って、本番環境をゼロから復旧できますか？

監視：

毎日のバックアップジョブが失敗した場合にメールまたは Slack で通知するアラートを設定します。ほとんどのプロバイダーが標準で対応しています。バックアップパネルを閉じる前に設定してください。

フェーズ 2：分析と可観測性

サードパーティ連携の多くは、Cloudflare または Vercel を使ってワンクリックで設定できます。

条件付きのツール（Crisp、Sentry、BetterStack）については、サイトの種類ごとにユーザーへ確認してください。 可観測性のティアの一覧は references/decisions.md を参照してください。

常時有効：

Google Analytics 4：プロパティを作成し、測定 ID を埋め込み、CNIL の同意取得後にのみ有効化
PostHog：ユーザーの以前の回答に基づいて設定します：
- hogpost.samber.dev の場合：クライアントに api_host: "https://hogpost.samber.dev" を設定し、CORS で新しいドメインが許可されていることを確認します（ブラウザーコンソールまたは curl -H "Origin: https://newsite.com" -I https://hogpost.samber.dev/decide でテストします）
- set-up-new-proxy の場合：next.config.js に us.i.posthog.com と us-assets.i.posthog.com へのパス書き換えを追加し、api_host: "/ingest" を指定してクライアントを初期化します
- skip-PostHog の場合：スキップします
Google Search Console：サイトの所有権を確認済み（DNS TXT または HTML ファイル）、サイトマップを送信済み
Bing Webmaster Tools：サイトの所有権を確認済み、サイトマップを送信済み、ルートに /{key}.txt 形式で IndexNow キーファイルを配置済み（curl -sI https://example.com/{key}.txt で確認します）
Ahrefs：トラッキング用にサイトをダッシュボードへ追加済み
サイトを内部統計スプレッドシートに追加します（該当する場合は PostHog プロパティレジストリと GitHub Sponsors トラッキングシートにも追加します）

ブランドのモニタリング（Google Alerts）：

各アラートには次の設定を使用します：頻度：1 日 1 回 | ソース：自動 | 件数：すべての結果 | 地域：すべての地域

alerts.google.com で、キーワードごとにアラートを 1 件設定します：

ドメイン名（例：example.com）
ブランド名または製品名（複数語の場合は引用符で囲みます。例："My Brand"）
サイトでプロジェクトについて解説している場合は、主要な機能名またはライブラリ名
競合ブランド名（任意 — ユーザーに確認します：yes-monitor-competitors | skip）

ユーザーに尋ねます：「モニタリングする追加のキーワードはありますか？」（product-name-only | domain-plus-brand | full-set-with-competitors | custom-list）

開発者コミュニティのモニタリング（F5bot）— 開発者を対象とする doc-site と SaaS-app 向け：

F5bot（f5bot.com）は、Reddit、Hacker News、Lobste.rs でキーワードへの言及をモニタリングし、メールアラートを送信します。無料で、API は不要です。

f5bot.com/add で、キーワードを 1 行に 1 つずつ設定します：

ブランド名または製品名
ドメイン名（リンクの共有を検出します）
主要な機能名またはライブラリ名
該当する場合は、よくあるスペルミス

競合分析（marketing/lead-gen、SaaS-app、training/paid-course のみ）：

コピーの作成、広告の設定、コンテンツの計画を行う前に競合分析を実施し、市場ですでに効果を上げているもの（ポジショニング、メッセージングの切り口、CTA のパターン、価格の見せ方、コンテンツ戦略）を把握します。

利用可能な場合は、ディープリサーチツールまたはツールチェーン内の競合分析スキルを使用します。次の内容を尋ねます：

「分析したい競合の名前や URL はすでにありますか？」（yes-provide-list | no-discover-for-me | skip）
yes-provide-list の場合：ユーザーに名前または URL を 2～5 件貼り付けてもらいます（自由記述）
「どの情報を抽出しますか？」（positioning-and-messaging | pricing-strategy | content-and-seo | full-spectrum）

分析結果を次の項目に反映します：

フェーズ 5 のキーワード戦略（競合が上位表示されているものの、自社が上回る、または別の切り口から狙える検索クエリを対象にします）
TONE.md のトーン調整（カテゴリー内で主流のトーンと意図的に差別化します）
フェーズ 6 の OG コピーと CTA の文言（効果が実証された表現の型を参考にし、文言をそのまま模倣しないようにします）
後続で実行するコピーライティングのサブスキル（競合の概要をコンテキストとして渡します）

条件付き（ユーザーに確認。サイトの種類ごとのデフォルトは references/decisions.md を参照）：

Crisp
Sentry
BetterStack

フェーズ 3：法務・コンプライアンス（FR）

最初に「このサイトはフランス法の適用対象ですか？」と尋ねます（yes-FR-operator-or-audience | no-EU-only | no-non-EU）。該当しない場合は、GDPR または同等の規制が適用されるかを確認し、それに応じて調整します。

FR のサイトの場合：

Mentions légales ページ（必須。記載漏れ 1 件につき最大 75k€ の罰金）
商業活動がある場合は CGV（Conditions Générales de Vente）
プライバシーポリシー
利用規約
CNIL に準拠した Cookie 同意機能。GA4、PostHog、Crisp、Sentry のスクリプト読み込みを同意取得までブロックすること（トラッカーを常に読み込むバナーだけでは不十分です）。CMP（Axeptio、Tarteaucitron、またはカスタム実装）を使用します。ブラウザーの Network タブで、明示的な同意より前にトラッカーが動作しないことを確認します。

フェーズ 4：セキュリティ

詳細な監査は trailofbits/skills に委任します。以下は必ず合格すべきチェックリストです。

最初に CSP の厳格さのレベルを確認します（strict-default-src-none | balanced-allow-self | permissive-for-marketing）。各レベルの CSP テンプレートについては references/templates.md を参照してください。

フェーズ 5：SEO・GEO

完全な監査は AgriciDaniel/claude-seo に委任します。以下は監査の進行管理用チェックリストです。

robots.txt、llms.txt、manifest.json のテンプレートについては references/templates.md を参照してください。サイトの種類ごとの AI スクレイパーポリシー一覧については references/decisions.md を参照してください。

リンク先ページ戦略（directory-submissions スキルより）： 被リンクが一般的なホームページに向かうだけでは、ディレクトリに登録しても効果はありません。ディレクトリに登録する前に、次のリンク先ページを作成してください。

1. 代替サービスのページ（最も投資対効果が高い）

競合サービスの代替ページは**5～15％**のコンバージョン率を達成し、購買意欲の高い検索クエリでは15～30％に達することもよくあります。主要な競合ごとに1ページ作成します。

/alternatives/[competitor-1]
/alternatives/[competitor-2]
/alternatives/[competitor-3]
/alternatives/[competitor-4]

各ページには、率直な機能比較表、「Xを当社より選ぶべき場合」、「Xより当社を選ぶべき場合」、価格比較、3～5件のユースケース例、スキーマを使った充実したFAQが必要です。**重要：**正直であること。AI エンジンは競合の機能に関する主張を相互参照し、虚偽を述べるページの検索順位を下げます。

2. ユースケース／ICP のページ

ICP ごとに専用のランディングページを用意します。

/for/[audience] — コーチ、代理店、Eコマース、SaaS、コンサルタントなど
/use-cases/[use-case] — リードの適格性評価、オンボーディング、製品のレコメンデーションなど

3. テンプレート／アセットギャラリー（該当する場合）

Typeform のテンプレートライブラリは、ブランド名を含まないオーガニック登録を30,000件、年間LTVで300万ドル生み出しました。その手法は次のとおりです。

/templates/[slug] に、インデックス可能なテンプレートページを1つずつ作成します。
キーワードを含む H1、150語以上の説明、スクリーンショット、「使用するタイミング」、「このテンプレートを使う」CTAを掲載します。
各ページの下部に関連テンプレートを配置します（内部リンクによってSEO効果が積み上がります）。
30日目までに100件、90日目までに300件を作成するのが現実的な目標です。

4. 自社で執筆した「おすすめ」リスト記事

自社のカテゴリーについて、率直なまとめ記事を執筆します：/blog/best-[category]-tools-2026。自社製品と10社の競合を取り上げ、実際のレビューを掲載します。これらの記事はカテゴリー関連の検索クエリで上位に表示されるだけでなく、AI エンジンが引用する代表的な参照先にもなります。

5. インテグレーションページ（インテグレーションの提供開始後）

インテグレーションごとに、/integrations/[partner] にランディングページを1つ作成します。Zapier の手法にならいます。Zapier はプログラマティックなインテグレーションページから月間約260万件のオーガニック訪問を獲得しており、これはオーガニックトラフィック全体の約15％にあたります。

**GEO（生成エンジン最適化）：**2026年には、「ツールを調べる」検索クエリの30～50％が、従来の検索ページを一切経由せずに ChatGPT、Claude、Perplexity、Google AI Overviews 上で行われます。

ページを引用してもらうための施策

**各ページの H1 は1つにし、見出しの階層を順番どおりにします。**引用率は2.8倍高くなります。引用されるページの87％では、H1が1つだけ使われています。
**引用可能な統計を含む、情報密度の高い事実に基づくコンテンツを作成します。**AI エンジンは、曖昧な主張より具体的な数値（「Xより3倍高速」など）を好みます。
**すべてのランディングページにFAQスキーマを設定します。**AI エンジンは、回答の抽出に FAQPage JSON-LD を重視します。
**比較表を掲載します。**抽出しやすく構造化されており、AI の回答に必要な情報そのものです。
最初の100語以内に、「それが何か」を明確に説明する段落を入れます。
**Reddit と Hacker News で引用されるようにします。**Claude と Perplexity はこれらを重点的にインデックスします。r/SaaS や HN での自然な言及は、学習データの材料になります。
独自調査を公開します。「[対象]を10,000件分析し、Xが分かりました」は、そのテーマについて執筆する人にとって主要な引用元になります。
**Crunchbase、LinkedIn の会社ページ、Wikidata の項目を登録します。**この3つはいずれも AI の学習コーパスに取り込まれます。
**該当する場合は、A/B グレードの MCP レジストリ（特に Glama）に掲載します。**LLM は MCP に関する質問に回答する際、これらを参照します。

効果測定

毎月、ChatGPT、Claude、Perplexity に「おすすめの[カテゴリー]ツールは何ですか？」と質問し、製品がどこに表示されるかを手作業で確認して記録します。無料の GEO トラッキングツール（GeoTracker、llmrefs）を使えば、この作業を自動化できます。

フェーズ 6：Open Graph とソーシャルプレビュー

すべての OG タグと Twitter タグを、次のコマンドで確認します：curl -s URL | grep -iE 'og:|twitter:'

og:title、og:description、og:url、og:type、og:site_name
og:image は 1200×630px、絶対 URL を指定し、og:image:width と og:image:height を宣言し、og:image:alt を設定します
ページごとに og:image を設定し、グローバルに 1 つだけ設定することは避けます。ドキュメントサイトではページタイトルから動的に生成します。ブログ記事では記事ごとにカスタム画像を用意します。
多言語対応の場合は、各言語に og:locale と og:locale:alternate を設定します
Twitter Cards：twitter:card=summary_large_image、twitter:title、twitter:description、twitter:image、twitter:site（ハンドル）
Claude Chrome 拡張機能を使って opengraph.xyz で検証します（Facebook、LinkedIn、Slack、Discord、WhatsApp のプレビューを確認できます）
Twitter のカードバリデーターで検証します
手動で確認します：URL を LinkedIn の DM、Slack チャンネル、Discord、iMessage に貼り付けます。すべてでプレビューが正しく表示される必要があります。

フェーズ 7：ファビコンと Web マニフェスト

manifest.json のテンプレートについては、references/templates.md を参照してください。

1 つの 1024×1024 のソース PNG から、realfavicongenerator.net または favicon.io を使って生成します。

最新環境での最低限のセット：

/favicon.ico（16/32/48 の複数解像度）。curl -sI https://example.com/favicon.ico で確認します。
ダークモード用の埋め込み <style>@media (prefers-color-scheme: dark) { ... }</style> を含む /favicon.svg。curl -sI https://example.com/favicon.svg で確認します。
/favicon-96x96.png（PNG のフォールバック）
/apple-touch-icon.png は 180×180px、透明部分なし、不透明な背景にします。curl -sI で確認します。
/web-app-manifest-192x192.png（Android PWA アイコン）
/web-app-manifest-512x512.png（Android スプラッシュ画面）
両方の PNG を参照する /manifest.json。theme_color、background_color、name、short_name、display を設定します。curl -s https://example.com/manifest.json | jq . で確認します。

省略（非推奨）：

mstile-*.png（Windows タイル）
safari-pinned-tab.svg（macOS Big Sur 以降は非推奨）
favicon-16x16.png / favicon-32x32.png（.ico と .svg で対応）

HTML head の確認：

curl -s https://example.com/ | grep -iE 'rel="icon"|rel="apple-touch-icon"|rel="manifest"'

フェーズ 8：品質ゲート

addyosmani/web-quality-skills に委任します。このスキルでは、パフォーマンス、アクセシビリティ、SEO、ベストプラクティスにわたる 150 以上の Lighthouse 監査を扱います。

Unlighthouse によるサイト全体のクロール：npx unlighthouse --site {site} — すべてのページをクロールし、それぞれで Lighthouse を実行します。URL ごとのチェックに先立ち、いずれかの指標で 90 未満のページを洗い出します。
モバイルモードで Lighthouse の 4 指標すべてを確認し、それぞれ 90 以上を目標にします（パフォーマンス、アクセシビリティ、ベストプラクティス、SEO）
デスクトップモードで Lighthouse の 4 指標すべてを確認し、それぞれ 95 以上を目標にします
Core Web Vitals のフィールドデータ（PageSpeed Insights 経由の CrUX）：LCP < 2.5s、INP < 200ms、CLS < 0.1 を、モバイルとデスクトップの両方で達成します
アクセシビリティ（web-quality-skills による WCAG 2.2 AA）：すべてのインタラクティブ要素でキーボード操作が可能であること、フォーカスリングが見えること、テキストのカラーコントラストが ≥4.5:1 であること、すべての画像に alt があること、見出しの階層が順序どおりであること（H1 → H2 → H3）、アイコンのみのボタンに ARIA ラベルがあること
実機のモバイルデバイスでテストします（devtools エミュレーターだけでは不十分です）。実機のモバイルビューポートで Claude Chrome 拡張機能を使うか、BrowserStack を使用します。
クロスブラウザーのスモークテスト：最新の安定版 Chrome、Safari、Firefox
印刷用スタイルシートの動作を確認します（Cmd+P でレイアウトが崩れないこと）

フェーズ 9：エコシステム内の相互リンク

所有するプロパティ間で相互にリンクします。複数のドメインを所有する場合に効果の高い SEO 施策です。

ユーザーに次のように尋ねます：「この新しいサイトとテーマ上の関連性が高い、エコシステム内の他のドメインを挙げてください。」その後、それぞれについて次の作業を行います。

テーマ上の関連性がある場合、既存サイト（フッター／ナビゲーション／「その他のプロジェクト」セクション）から新しいサイトへのリンクを追加します
ライブラリのドキュメントを掲載している場合、該当する GitHub リポジトリの README に新しいサイトへのリンクを追加します
相互リンクを確認します。追加した各リンクが、適切な場合にリンク元へ戻るリンクを指していることを確認します
新しいサイトが Go ライブラリのドキュメントを掲載している場合、関連ライブラリのドキュメントからリンクします

リンクを貼りすぎないでください。テーマ上の関連性がある場合にのみ、相互リンクしてください。ロギングライブラリのドキュメントサイトから、自転車に関する個人ブログへリンクするべきではありません。

フェーズ 10：週次 SEO メンテナンスサブエージェントの設定

公開後、Hermes や Claude Cowork Routine などのスケジュールされたバックグラウンドエージェントを設定し、週次で SEO の健全性を監視して、対応事項を提示します。

各ハーネスに対応する具体的な設定を記載したエージェント定義の全文については、references/weekly-seo-agent.md を参照してください。ご利用の環境に合ったブロックをコピーし、指定された場所（サイトのリポジトリ、または専用の運用リポジトリ）に配置します。エージェントは次の MCP コネクター（または同等の API 呼び出し）を使用します。

Ahrefs MCP（バックリンク、ランキング、キーワード）
PostHog MCP（分析データの相関、AI ボットのトラフィック）
ウェブ検索（SERP の監視、競合他社の確認）
Google Search Console（コミュニティ MCP、またはサービスアカウントの認証情報を使った curl 経由）

ファイルを作成する前に、question ツールを使って次のように尋ねます：「週次 SEO エージェントを今すぐ設定しますか？」（yes-create-agent-file | yes-but-defer | skip-for-now）。

MCP が利用できない場合は、Claude for Chrome 拡張機能を使用します。

フェーズ 11：ディレクトリへの登録作業

directory-submissions スキルのディレクトリ登録ワークフローを実行します。これは配信の基盤となるレイヤーであり、戦略のすべてではありません。

ステップ 1：ティアを選ぶ（references/directory-list.md より）

ティア	時期	例	目安件数
ティア 1 — 主要ローンチ	ローンチ週のみ	Product Hunt（中核）、BetaList、HN Show HN、Fazier、DevHunt	約 15
ティア 2 — スタートアップ／SaaS	第 1 週＋随時	AlternativeTo、SaaSHub、G2、Capterra、F6S、SourceForge、Slashdot	約 50
ティア 3 — AI ディレクトリ	第 1〜3 週	TAAFT、Futurepedia、Toolify、Future Tools、aitools.inc、AIStage	約 40
ティア 4 — エージェント／MCP レジストリ	第 1〜3 週（MCP の場合）	Glama、APITracker、LF MCP Registry、AI Agents List	約 10
ティア 5 — ノーコードディレクトリ	第 1〜3 週（ノーコードの場合）	NoCodeFinder、No Code MBA、We Are No Code、MakerPad	約 8
ティア 6 — 「ベスト」系リスト記事	随時アプローチ	DR 40 以上のブログ記事へのコールドアプローチ	約 10 件の掲載
ティア 7 — インテグレーションマーケットプレイス	インテグレーションの提供開始時	Zapier、HubSpot、Slack、Airtable、Notion	約 5
ティア 8 — プロフィール／コンテンツプラットフォーム	随時	GitHub、WordPress.com、Substack、Dev.to、SlideShare、Behance	約 50
ティア 9 — 地域ビジネスディレクトリ	随時（該当する場合）	Manta、Hotfrog、Locanto、MerchantCircle	約 20
ティア 10 — フォーラム／コミュニティ	随時（まず参加）	SitePoint、GrowthHackers、Warrior Forum、Designer News	約 13
ティア 11 — プレスリリース／記事サイト	ローンチ時および節目	PRLog、PR.com、EzineArticles、Feedspot	約 25
ティア 12 — ソーシャルブックマーク	随時	Scoop.it、Diigo、Pearltrees	約 5
ティア 13 — ニッチ分野のディレクトリ	分野が合致する場合	Justia（法律）、Porch（住宅）、LandBook（デザイン）など	約 20

**選別ルール：**製品との適合性が本当に高い場合にのみ登録してください。適合しないカテゴリに無理に登録すると、初回登録の優位性を損ない、モデレーターに却下されます。

ステップ 2：ティアごとにアセットのバリエーションを準備する

各ティアについて、（references/positioning-variations.md を参考に）異なる説明文のバリエーションを準備します。

タグライン：10 語未満
短い説明：60 文字
長い説明：150 語
カテゴリタグ：5～8 個
ロゴアセット
スクリーンショット＋デモ動画の URL
創業者のストーリー（2～3 文）

重要： すべてのディレクトリに同じ長い説明文をコピー＆ペーストしないでください。ティアごとに、冒頭の文、機能の強調点、対象読者の示し方を変えてください。AI エンジンはコンテンツを相互参照し、重複コンテンツの評価を下げます。

ステップ 3：トラッカーを使って一括送信する

トラッカーのスプレッドシート（references/submission-tracker-template.csv）を用意します。左から右へ順番に進めてください。1 バッチあたり 2～3 時間が現実的です。

送信ごとに：

ティアに適したポジショニングのバリエーションをコピーします。
フォームに入力します。
アセットをアップロードします。
送信します。
日付、URL、ステータス、モデレーターからのメモを記録します。
公開されたら、バックリンクが存在し、dofollow であることを確認します：curl -sIL https://directory.com/your-listing | grep -i rel=。存在しない場合、そのリンクは dofollow です。

フェーズ 12：Product Hunt の徹底活用（主要イベント）

Product Hunt は、最も効果の高い投稿先である一方、無駄になりやすい投稿先でもあります。2026 年の PH アルゴリズムは、アップボート数よりもコメントの質を重視します。50 件のアップボートと 30 件の本物のコメントがある投稿は、200 件のアップボートと 5 件のコメントがある投稿より上位に表示されます。**失敗したローンチの 80％**は、温かいオーディエンスがいない状態でローンチしたか、フィードバックではなくアップボートを求めたことが原因です。

3 週間の準備スケジュール

21～14 日前： ハンターのアカウントを育てます。1 日 3 件のローンチにアップボートし、考えを込めたコメントをします。活動中のメーカーを 100 人以上フォローします。アカウントがアルゴリズムに本物だと認識されるよう、利用履歴を積み上げます。
14 日前： PH に「Upcoming」ページを作成します。そこへトラフィックを誘導し、「ローンチ通知を受け取る」登録者を集めます。
10 日前：（任意）ハンターを予約します。現金は支払わず、機能の提供、紹介、または知人の紹介と交換します。知名度のあるハンターは初日の勢いを約 15％高めますが、必須ではありません。
7 日前： ローンチ当日のアセットを作成します。ギャラリー画像（1270×760）、タグライン、260 文字の説明、あなたからの最初のコメント、顧客からの最初のコメントを用意します。
3 日前： メーリングリストを事前に温めます。「火曜日にローンチします。内容はこちらです。事前にお知らせをご希望の場合は返信してください。」
1 日前： 最終確認を行います。シークレットモードで製品が動作すること、動画が自動再生されること、CTA がサインアップにつながること、PH の掲載プレビューが正しく表示されることを確認します。

ローンチ当日の実行

太平洋時間の午前 12:01 にローンチします。 火曜日、水曜日、木曜日のみです。週末のローンチはトラフィックが 60～70％減少します。太平洋時間の午前 12:01 に開始すると、24 時間の枠を最大限に活用できます。
最初の 2 時間がすべてです。 アルゴリズムによる配信を促すには、最初の 2 時間に 50 人以上のサポーターが必要です。
ストーリーを添えて、最初のコメントを自分で投稿します。 なぜ作ったのか、何が違うのか、まず何を試してほしいのかを書きます。
すべてのコメントに 30 分以内に返信します。 PH はメーカーの対応の速さを評価します。
リンクを共有する先： Twitter/X のスレッド、LinkedIn の長文投稿、個人的な Slack/Discord コミュニティ、メーリングリスト、Indie Hackers、DM で連絡するすべてのパワーユーザー。
アップボートを求めてはいけません。 フィードバックを求めましょう。「応援してください！」よりも「ポジショニングについて率直な意見をぜひ聞かせてください」のほうが 3 倍高い成果につながり、アルゴリズムの操作防止フィルターにも引っかかりません。
見知らぬ人にメッセージを送ってはいけません。 コミュニティに報告され、モデレーターに投稿を非表示にされます。

ローンチ後

数字と学びをまとめたローンチ振り返りのブログ記事を書きます。自慢ではなく、正直な内容にします。2 日目に公開します。
振り返り記事を Indie Hackers と r/SaaS（プロモーションが許可されている場所）にも転載します。
Show HN への投稿は、共有できる_技術的な_切り口（アーキテクチャ、DSL、斬新なアプローチ）がある場合に限ります。一般的な「SaaS をローンチしました」という投稿は、次々と報告されます。

フェーズ 13：レビューの実践ガイド（G2 / Capterra / TrustRadius）

G2 と Capterra（2026 年 2 月時点で G2 が所有）の掲載ページは、レビューがなければ価値がありません。Grid に表示されるための目安は 10 件のレビューです。ローンチ月に「30 日で 10 件」のプロトコルを実施します。

10件のレビューを30日で獲得するプロトコル

ローンチ翌日： プロダクトで意味のあるアクションを完了したユーザーを20人特定します。
一人ひとりに個別のメールを送り、 直接レビューできるURLを記載します（これにより手間を約70％削減できます）。フォームやランディングページは使わず、直接リンクを送ります。
ささやかなお礼を用意します。 G2とTrustRadiusでは、25ドル分のAmazonギフトカードなど、少額のインセンティブが明示的に認められています。
5日後に一度だけフォローアップします。2回目のフォローアップは控えてください。相手を煩わせ、関係を損ねてしまいます。
目標： 50％のコンバージョン率で、20件の依頼から10件のレビューを獲得します。

重要な締め切り

G2のサマーレポート： 締め切りは4月28日頃です。それまでにレビュー獲得施策を実施しましょう。
G2の秋季レポート： 締め切りは7月28日頃です。
締め切りを逃すと、次のグリッド更新まで3か月待つことになります。

バッジと有料プラン

「Users Love Us」バッジは引き続き無料です。平均評価4.0以上のレビューが20件必要です。
Grid、Momentum、Index、Awardの各バッジには、有料のG2プランが必要です（2025年夏時点で年間2,999ドルから）。
初年度はG2の有料プランに費用をかけないでください。 無料掲載と「Users Love Us」バッジで十分です。

複数のプラットフォームでの展開

TrustRadiusも同様の仕組みですが、投稿数は少なめです。
Capterraは、一部のカテゴリでGartner Digital Marketsから自動同期されるため、直接対応しなくても情報が掲載される場合があります。

フェーズ14：ローンチ後の勢いを維持する

告知を公開しても、ローンチは終わりではありません。ここから、利用促進と定着に向けた取り組みが始まります。ローンチイベントを一度開催するだけでは不十分です。定期的な更新と機能のリリースによって、エンゲージメントを維持しましょう。

ローンチ直後に行うこと

新規ユーザーを支援する： 主な機能やユースケースを紹介するオンボーディングメールのシーケンスを自動化します。
ローンチを再告知する： 見逃した人にも届けられるよう、週次・隔週・月次のまとめメールに告知を含めます。
競合との差別化を図る： 自社が明らかに最適な選択肢である理由を示す比較ページを公開します。
ウェブページを更新する： サイト全体に新機能や新製品の専用セクションを追加します。
実際に試せるプレビューを提供する： Navatticなどのツールを使ったノーコードのインタラクティブデモを作成し、訪問者が登録前に試せるようにします。

告知の優先順位を決める方法

このマトリクスを使って、各更新にどれだけのマーケティング施策を行うかを決めます。

大規模な更新（新機能、製品の全面的な刷新）：

複数のチャネルを使った包括的なキャンペーン
ブログ記事、メールキャンペーン、アプリ内メッセージ、ソーシャルメディア
認知を最大限に高める

中規模の更新（新しい連携機能、UIの改善）：

対象を絞った告知
関連するセグメントへのメール、アプリ内バナー
大々的に告知する必要はありません

小規模な更新（バグ修正、小さな調整）：

変更履歴とリリースノート
プロダクトが改善されていることを伝える
マーケティングの主役にしない

告知の施策

リリースを分散させる： すべてを一度にリリースするのではなく、告知を段階的に行い、勢いを維持します。
効果の高かった施策を再利用する： 過去の告知への反応が良かった場合は、そこで得た知見を今後の更新に生かします。
関心を引き続ける： メール、ソーシャルメディア、アプリ内メッセージを継続的に活用し、改善点を紹介します。
開発が活発であることを伝える： 小さな変更履歴の更新でも、プロダクトが進化していることを顧客に思い出してもらえます。これにより定着と口コミが促され、顧客は今後もプロダクトが提供され続けると安心できます。

KPI とトラッキングダッシュボード

毎週追跡してください。数値が動かない場合は、ディレクトリへの登録を増やすのではなく、原因を調査してください。

指標	0日目	30日目の目標	90日目の目標
ドメインレーティング（DR）	0	20	30+
参照ドメイン	0	30	80+
インデックス登録済みページ	—	50	200+
1日あたりのオーガニッククリック数	0	30	200+
公開中のディレクトリ掲載数	0	50	70+
G2 のレビュー	0	10	25
Capterra のレビュー	0	5	15
AI による引用（手動確認）	0	3	15+
ディレクトリ経由の登録数	0	50	300
代替製品／ユースケースページ経由の登録数	0	20	300

やってはいけないこと

ディレクトリ登録代行サービスに料金を払わないでください（60～200 ドルのパッケージ）。そもそも無料で登録できるのがポイントです。午後の数時間でコピー＆ペーストできます。
スパムディレクトリには登録しないでください（DR が 10 未満、トラフィックがない、編集品質が低いもの）。被リンクのプロファイルを損ない、Google のスパム検出によってペナルティを受ける可能性があります。
誤ったポジショニングで登録しないでください。 ティアごとのポジショニング表を読み直してください。ありきたりな説明文では掲載の効果が薄れます。
ディレクトリを GTM のすべてだと考えないでください。 ディレクトリは基盤です。実際にコンバージョンにつながるのは、コンテンツ、コミュニティ、レビューです。
G2／Capterra のレビューを省略しないでください。 レビューがゼロの掲載は機能しません。「10-in-30」プロトコルを実施するか、登録を見送ってください。
Product Hunt でアップボートを依頼しないでください。 2026 年のアルゴリズムではペナルティの対象になります。フィードバックを求めてください。
古いディレクトリ掲載を毎週更新しないでください。 一度登録したら、四半期ごとに確認してください。
掲載先のページが存在する前に登録しないでください。 リンクの評価を受け取るには、リンク先が必要です。
ディレクトリ間で説明文を使い回さないでください。 AI エンジンは重複コンテンツを評価しません。
比較ページで嘘をつかないでください。 AI エンジンは情報を照合し、嘘の評価を下げます。
ローンチ当日の急増を重視しすぎないでください。 成長のフライホイールとなるのは、テンプレート、代替製品、レビュー、継続的なコンテンツです。PH の一日だけではありません。
Crunchbase、LinkedIn の会社ページ、Wikidata を忘れないでください。 これらは AI の学習コーパスに取り込まれ、GEO で重要な役割を果たします。
SLC のゲートを通過する前にローンチしないでください。 ステルスモードと「もう 1 つだけ機能を追加」は、どちらもローンチを失敗させます。
マーケティングコピーの人間らしさの確認を省略しないでください。 ヒーロー、CTA、メタディスクリプション、OG ディスクリプションに AI らしいパターンがあると、信頼性が損なわれます。
分析ツールは「そのまま動く」と思い込まないでください。 ローンチ前に、GA4、PostHog、GSC、Bing、Ahrefs の各連携を curl で確認してください。
バックアップの復旧訓練を怠らないでください。 テストしていないバックアップは、バックアップではありません。ローンチ前にステージング環境へ復元してください。

出力形式

一連の作業を完了したら、フェーズごとにまとめたステータスレポートを出力してください。

Phase 1: Domain & Infrastructure  [9/10 pass]
  ✓ Cloudflare proxy on
  ✓ DNS records configured
  ...
  ✗ DMARC missing. Fix: add TXT record at _dmarc.example.com with policy v=DMARC1; p=quarantine;...

Phase 2: Analytics & Observability  [6/7 pass]
  ...

続けて、次の 3 つのリストを順番に出力してください。

ブロッカー（ローンチ前に必ず修正）
推奨修正（告知前に修正すべき項目）
任意の改善（ローンチ後に実施）

最後に、次のように尋ねてください：「次はどのリストに取り組みますか？」（blockers | recommended | optional | done-for-now）。

リファレンス

references/decisions.md：サイトの種類別 AI スクレイパーポリシーマトリックス、可観測性ティアマトリックス
references/templates.md：厳格さのレベル別 robots.txt、llms.txt、manifest.json、CSP のテンプレート、セキュリティヘッダーのリファレンス
references/weekly-seo-agent.md：週次 SEO メンテナンスサブエージェントの完全な定義（MCP、タスク、出力形式）
assets/weekly-seo-*.md、assets/weekly-seo-vibe.toml：references/weekly-seo-agent.md からリンクされているハーネス別のエージェント定義ファイル。使用するハーネスに一致するものをコピーしてください
references/directory-list.md：提出時期、例、件数を含む 13 段階のディレクトリカタログ
references/positioning-variations.md：ディレクトリの各ティア向けポジショニングバリエーション集（タグライン、短文・長文の説明、カテゴリタグ）
references/submission-tracker-template.csv：ディレクトリへの提出を記録するための提出トラッカーのスプレッドシートテンプレート

Markdown 対応

ログインしてコメント

基本情報

作者: samber
リポジトリ: samber/cc-skills
カテゴリ: テスト・品質
インストール数: 4,766
GitHub スター: 241

問題を報告

パック	対象範囲	主に役立つ対象
`AgriciDaniel/claude-seo`	SEO + GEO + スキーマ + hreflang + サイトマップ監査、並列サブエージェント	すべてのサイトの種類
`addyosmani/web-quality-skills`	Lighthouse、Core Web Vitals、アクセシビリティ、パフォーマンス、ベストプラクティス	すべてのサイトの種類
`trailofbits/skills`	セキュリティ監査（OWASP、ヘッダー、依存関係）	すべてのサイトの種類
`aaron-he-zhu/seo-geo-claude-skills`	20種類のSEO+GEOスキル、CORE-EEAT + CITE フレームワーク、`/seo:` スラッシュコマンド	コンテンツ中心のサイト、競争の激しいニッチ市場
`coreyhaines31/marketingskills`	約30種類のマーケティングスキル（CRO、コピーライティング、広告、ポップアップ、メール、ペイウォールなど）	`marketing/lead-gen`、`SaaS-app`、`training/paid-course`
`jonathimer/devmarketing-skills`	33種類の開発者向けマーケティングスキル（ペルソナ、マーケティングとしてのドキュメント、技術チュートリアルなど）	開発者向けの `doc-site`、`SaaS-app`