cs-seo-website

CodeSpring ウェブサイトの SEO オペレーター

CodeSpring のマーケティングサイトでの作業に使用します。対象は、robots／サイトマップ／canonical、Search Console のエクスポート、ドキュメント／チュートリアル、Vibe Code Library、製品一覧、紹介リンク、オーガニック成長のレポートです。

このスキルの対象は CodeSpring のウェブサイトリポジトリ（VolkisAI/codespring-webinar）であり、CodeSpring の顧客プロジェクトではありません。目標は、見栄えだけのドメイン評価（DR）ではなく、質の高いオーガニックトラフィックとコンバージョンです。

運用原則

サードパーティの権威性指標は診断には使えますが、それ自体でページのランキングが上がるわけではありません。次の順序で優先してください。

1. Google がクロール、インデックス登録、内容の理解をできるページ。
2. 実際の検索意図を既存の検索結果より的確に満たすページ。
3. トピックに関連する内部リンクと、明確なコンバージョン経路。
4. 真摯な言及、レビュー、インテグレーション、編集記事での参照。
5. ブランド名を含まないインプレッション、質の高い訪問、登録の測定。

DR やランキングの結果を約束したり、主にランキング操作を目的とするリンクを購入したり大量送信したりしないでください。適切なユーザーを呼び込む場合、nofollow の言及にも価値があります。

ブランチとリリースのモデル

まずウェブサイトリポジトリの AGENTS.md を読んでください。これは運用上の契約であり、このスキルより優先されます。

• main：ライブブランチです。app/sitemap.ts、app/robots.ts、app/layout.tsx、lib/site-links.ts、templates/、docs/*.md など、共有 SEO ファイルの変更が許可されている唯一のブランチです。
• blog：app/blog/**、content/blog/**、public/blog/** のみ。
• library：Vibe Code Library が所有するパスのみ。
• docs：ドキュメントのルート／コンポーネントのパスのみ。
• marketing：マーケティングが所有するパスのみ。

dev を再作成したり、ウェブサイトリポジトリで場当たり的な fix/seo-* ブランチを使ったり、main に直接コミットまたはプッシュしたりしないでください。各領域のブランチは origin/main から分岐し、main 宛てのドラフト PR を 1 つだけ維持します。また、各セッションでは編集を始める前に、必ず origin/main をマージしてください。共有 SEO ファイルの変更が必要な場合は、レビュー担当者による確認に向けて、独立した小規模な main 専用 PR とします。

git fetch origin --prune
git switch blog  # or library, docs or marketing
git merge origin/main
git status --short --branch

まだ存在しない領域ブランチを新規作成する場合は、AGENTS.md の指示どおりに origin/main から作成してください。npx tsc --noEmit、rm -rf .next out && npm run build、node --test tests/*.mjs を実行してください。変更のないベースラインテストが失敗した場合は、内容をそのまま報告し、全テストスイートに合格したと主張しないでください。完了を報告する前にプッシュし、リモートの SHA を確認してください。

1. テクニカル SEO のベースライン

コンテンツを作成したり掲載先を探したりする前に、ライブのルート および origin/main 上の実装を確認してください。

• canonical ホストを 1 つに統一し、もう一方のホストは CDN／ホスティングのレイヤーで恒久的にリダイレクトする。
• 有効な 200 text/plain の /robots.txt があり、サイトマップの宣言を含んでいる。
• 有効な 200 XML の /sitemap.xml があり、canonical でインデックス登録を意図した URL のみを含んでいる。
• タイトル、メタディスクリプション、canonical URL、内容のある本文をサーバー側でレンダリングする。
• コンバージョン専用、プレビュー、アカウント、重複するルートには意図的に noindex を設定する。
• JavaScript を使用せずにクローラーがたどれる内部リンクを設置する。
• 適用箇所では、正確でユーザーに見えるコンテンツだけを対象とした構造化データを使用する。
• Search Console のドメインプロパティを設定し、サイトマップを送信し、URL 検査で確認する。

静的 Next.js エクスポートでは、app/robots.ts と app/sitemap.ts が公開ファイルを生成します。S3／CloudFront が静的ファイルを配信している場合、ホストのリダイレクトは Next.js のソースだけでは解決できません。配信レイヤーで手順を文書化し、適用してください。

本番環境へのデプロイ後の受け入れテスト：

curl -sSIL https://codespring.app/
curl -sSIL https://www.codespring.app/     # expect 301 to the matching bare-host URL
curl -sSI https://codespring.app/robots.txt
curl -sSI https://codespring.app/sitemap.xml
curl -sS https://codespring.app/robots.txt
curl -sS https://codespring.app/sitemap.xml

2. Search Console → コンテンツの改善サイクル

Search Console のクエリエクスポートを、バックログの情報源として扱います。一般的なキーワードリストだけをもとに、ページのトピックを選ばないでください。

1. エクスポートを取り込み、クエリ、ページ、クリック数、表示回数、CTR、平均掲載順位、国、期間の列を保持します。
2. クエリを検索意図ごとに分類します。ブランド、比較、チュートリアル／問題解決、製品／カテゴリ、サポート／ドキュメントです。
3. 次のいずれかに該当する語句を優先します。
   • 表示回数が有意に多い一方、CTR／掲載順位が低い語句。
   • CodeSpring の製品に合致する、明確な商用意図／問題解決意図を持つ語句。
   • 改善できる現実的な見込みがある既存ページ。
4. すべてのページ概要で、対象とする検索意図、読者が達成したいこと、独自の根拠／例、タイトル、H1、構成案、内部リンク、CTA、スキーマの判断、成功指標を定義します。
5. 公開し、ページが本当に準備できている場合に限りインデックス登録をリクエストして、その後14／28／56日目に確認します。公開数ではなく、表示回数、CTR、コンバージョンに基づいてページを改善します。

月次スコアカード：

非ブランド表示回数 | 非ブランドクリック数 | 上位20件のクエリ | インデックス済み URL 数 | 質の高いオーガニックセッション数 | オーガニック経由の登録数 | 参照ドメイン数 | 参照経由の登録数。

3. 先回り型の日次コンテンツデスク

各営業日の開始時に、創業者がレビューできる SEO デスクを運用します。目標は完全に執筆された、異なるレビュー用ページを5件作成することであり、概要を5件作成することでも、自動公開 URL を5件作成することでもありません。各ページはそれぞれ、固有の検索意図、独自の価値、需要の根拠、カニバリゼーションがないこと、現実的なコンバージョン経路を満たす必要があります。これらの条件を正直に満たせるページが3件または4件だけの場合は、その完成したページを提出し、残りの枠を見送った理由を説明します。これにより、迅速な制作のリズムを保ちながら、CodeSpring が大量生成コンテンツやドアウェイページに頼るのを防ぎます。

まず Search Console を使い、次にキャッシュ済みの月次 DataForSEO データセットを使い、ライブ SERP は候補を絞った後にのみ確認します。Instagram、TikTok、YouTube、営業電話は、言い回し、質問、異論を知るための定性的な情報源として扱い、動画1本につきランディングページを1つ作る指示として自動的に扱わないでください。既存の正規ページがすでに検索意図を満たしている場合は、そのページを改善します。

毎朝、次を行います。

1. 商用比較、問題起点のガイド、有用なツール／テンプレート、正規ページの更新、実績／ドキュメント／ストーリー関連の中から、5件の機会に優先順位を付けます。
2. 読みやすい完全なページを最大5件作成します。根拠とコンテンツの条件を満たせない枠は見送ります。
3. レビューブランチをプッシュし、各ページにつき、直接開けることを確認済みの Vercel ルートを1つ提示します。localhost は使いません。
4. 対象クエリ、SERP の不足点、独自の価値、CodeSpring の立ち位置、CTA、必要な判断事項を1つ明記した簡潔なレビューパケットを Sebastian に送ります。
5. 創業者の YouTube 動画によって根拠や教育的な価値が大きく高まるページを1件または2件選びます。
6. 特に理由がない限り、動画のデモはシンプルにします。認証、データベース、バックエンド、決済、デプロイは使わず、1画面のユーティリティ、ローカルデータを使った操作、1つのワークフロー、または現行インターフェースの比較を使います。
7. サムネイル候補を作成するのは、ページと動画の切り口が承認された後に限ります。
8. フィードバックを反映してプレビューを更新し、明示的な承認を得た場合に限りマージします。AWS 本番環境へのデプロイは別に管理します。

すべての機会とページについて、次の段階を通じて進捗を追跡します。

機会 → 概要作成 → レビュー → 修正 → 承認 → マージ → AWS デプロイ待ち → 公開済み／確認済み → 14／28／56日目のレビュー

リモートレビュー URL を提示するか、アクセスできない理由を明示しない限り、朝の作業は完了ではありません。Vercel プレビューを公開済み、または本番稼働中と呼んではいけません。ページ数のノルマを、固有の検索意図、有用性、独自の根拠、品質より優先してはいけません。

選定、構築、動画、インデックス登録、測定に関する全ワークフローは、references/daily-seo-content-desk.md を参照してください。日次の成果物は templates/morning-seo-review.md を使って作成します。

4. コンテンツシステム

チュートリアルとドキュメント

製品が実際に解決できる問題を扱うチュートリアルを作成してください。たとえば、AIで構築するアプリの計画、要件のPRDへの落とし込み、プロジェクトやタスクの順序付け、コードベースのインポート、コーディングエージェントとの接続などです。読者が得られる成果を最初に示し、実際の手順や例を紹介してから、明確なCodeSpringへのCTAにつなげてください。

ありきたりなAI関連の内容や、キーワードだけを少し変えた記事を大量に作成しないでください。独自の例や内部リンクを含む質の高いチュートリアルを1本作るほうが、内容の薄い記事を量産するより効果的です。

意味を損なわず、初心者向けに書く

平易な英語で書くことは、すべての考えをできるだけ少ない言葉に切り詰めることではありません。文の長さや読みやすさの評価は確認のための目安であり、達成すべきノルマではありません。何が変わり、何が壊れ、なぜその教訓が重要なのかを読者が理解できるだけの背景を残してください。

• 普通の言葉を使ってください。機能については、誰かが完成したと言えるではなく、完了したと表現してください。
• 主語、動作、結果を明確にしてください。メイン画面は動いた。空のフォーム、保存の失敗、次の手順は動かなかった。のような圧縮した表現は避け、因果関係が伝わる例に書き直してください。
• 語数を減らすために、複数の状態を1文に詰め込まないでください。同じ階層に3つ以上の確認項目がある場合は、導入文を置いて箇条書きにしてください。
• 実際の順序を示してください。何を構築したか、最初は何が動いていたか、その後何が変わったか、何が壊れたか、そしてどの受け入れ確認やテストで後退を検出できたかを説明してください。
• たとえば、CSVのアップロードが動いていたものの、その後のデータ処理の変更でアップロードが壊れ、新しい作業を加えた後も元のアップロードテストに合格する必要があることを説明してください。
• 説明には段落を使い、並列する確認項目、エッジケース、手順、結果には箇条書きを使ってください。長い文章の塊は初心者向けではありません。
• 声に出して読んでください。文法的には短くても、抜けているつながりを推測しないと理解しにくい文は、さらに短くするのではなく書き直してください。
• 創業者の一人称による教訓は、Sebastianのフィードバック、一次情報の動画、通話の記録、またはCodeSpringで記録された経験に基づくものに限ってください。ページを個人的に見せるために経験を捏造してはいけません。

比較記事とガイドページ

比較ページは、ランディングページの機能一覧ではなく、編集記事として扱います。

1. まず、実際の検索結果ページの例を確認します。 検索順位の高いページを精査し、構成、読者の疑問、不足している根拠を把握します。文章、画像、根拠のない主張をコピーせず、参考にしてください。
2. 読者を起点にします。 読者がどのような状況にあり、どんな問題を抱え、どのような選択をしようとしているのかを冒頭で説明します。比較の意図に答える前に、CodeSpring を紹介しないでください。
3. 記事として必要な要素を含めます。 著者が Sebastian の場合は、目に見える著者名と写真、更新日、読了時間を掲載します。長いページには、リンク付きの章ナビゲーションを設けます。
4. 比較する製品ごとにセクションを設けます。 Claude Code、Codex、Cursor などの製品が得意とすること、適しているユーザー、なお必要となるコンテキストを説明します。後半に CodeSpring の独立したセクションを設け、その後、公平な表または選択手順で選択肢を要約します。
5. 装飾的な代替品ではなく、実際のビジュアルを使います。 他社製品ごとに、その製品の公式公開製品ページまたはドキュメントから取得した最新のスクリーンショットを使用します。最適化した画像をローカルに保存し、出典 URL と日付を記録し、意味のある代替テキストを追加し、キャプションを公式の出典にリンクします。実際の UI 画面がある場合、検索結果のサムネイル、AI で描き直したインターフェース、汎用的なテキストブロック図は決して使用しないでください。
6. 実際の CodeSpring 製品アセットを再利用します。 図を新たに作成する前に、現在のホームページと public/ ライブラリを確認します。サイトで承認済みの実際のマインドマップ、生成された PRD、ジャーニー／マップ、かんばんボードのスクリーンショットを優先します。プレースホルダーのアーキテクチャブロックは、該当する製品 UI に置き換えます。
7. 比較表はひと目で把握できるようにします。 各製品名には、公式または承認済みのロゴを一貫したサイズで添えます。説明文は記事本文よりやや小さくし、各セルは長い段落ではなく、短い箇条書き形式で示します。ロゴは製品を識別するためのものであり、推奨を意味するものではありません。
8. 内部リンクをわかりやすく配置します。 読者に製品の説明が必要な箇所では、CodeSpring への言及をホームページにリンクします。マインドマップ、PRD、かんばんボードなどのトピックに関する語句は、それぞれのドキュメントページにリンクします。リンク先のすべてを検証してください。リンクは、ホバーしなくてもリンクだとわかるよう、コントラストのあるアクセスしやすい色と下線を使います。最後の CTA は明確にします。他社製品のスクリーンショットのキャプションと出典は、公式ページにリンクします。
9. 根拠を正直に示します。 同じタスク、環境、評価方法を記録していない場合、実機でのベンチマーク結果を主張しないでください。そのページが性能ベンチマークではなく、選択ガイドである場合は、その旨を明記します。
10. 記事全体を検証します。 スクリーンショットが自然なサイズで表示されること、ロゴが判読できること、章のアンカーが機能すること、モバイル／デスクトップのレイアウトが読みやすいこと、メタデータ／canonical／schema が正しいこと、すべての主張に目に見える根拠があることを確認します。

レビューには、レビュアーが実際にアクセスできる場合、Vercel PR プレビューを使用できます。本番環境への反映は、引き続き手動の AWS ワークフローで行います。プレビューには REVIEW と表示し、LIVE / VERIFIED と表示しないでください。また、Vercel のプレビューによって AWS の本番環境が変更されたと決して示唆しないでください。

Vibe Code Library

専用の feat/codespring-vibe-code-library ブランチと戦略ドキュメントを使用します。アプリのページがインデックス登録可能になるのは、独自の範囲を定めた評価、現実的な中核ループ、明確な境界と対象外項目、機能グループ、独自の FAQ、出典／レビュー日、役立つ関連リンクを備えた場合に限ります。下書きページはサイトマップに含めません。

ライブラリのコンバージョン用アセットは、汎用的なディレクトリ一覧ではありません。範囲を定めた代替品を構築するための、誠実な計画／プロンプト／マップであり、実際の CTA リンク先が必要です。

5. 掲載とメンション

ディレクトリを利用する前に、製品プロフィール一式を作成してください。

• 製品名と正規 URL
• 60 ワードの説明文と 160 文字の説明文
• ポジショニング／カテゴリ
• ロゴ、スクリーンショット、承認済みのデモリンク
• 提出時点で正確な価格、サポート、創業者に関する情報
• UTM タグ付きの紹介 URL
• 担当者、承認状況、根拠となる情報源

適格性の判断基準

次のいずれかを満たす場合にのみ、掲載を利用してください。

• 関連する購入者／開発者コミュニティにリーチできる
• 誠実なレビュー／連携／パートナープロフィールである
• 編集者による発見や紹介トラフィックを生み出せる
• 実際のコミュニティの反応が得られる製品ローンチである

「dofollow backlinks」の販売、大量のリンク交換、説明文の自動生成、低品質な大量投稿を主なサービスとするサイトは却下してください。承認と会社管理の認証情報なしに、アカウントの作成、掲載料の支払い、主張の公開、レビューの依頼を行わないでください。

すべての候補を台帳で管理してください。

source | relevance | reason | proposed URL | rel | cost | owner | approval | submitted | live listing | referral sessions | sign-ups | review date

ステータスラベルは次のいずれかを正確に使用してください。DRAFT、AWAITING APPROVAL、SUBMITTED、LIVE、REJECTED。公開掲載と外部リンクを確認するまでは、投稿を公開済みバックリンクと呼ばないでください。

6. レビューとリリースのチェックリスト

• 最初に公開中のサイトと origin/main のソースを確認する。
• インデックス可能な各ページに、検索意図と独自の根拠がある。
• 日々の作業目標は、完全に執筆されたレビュー記事を 5 本作成すること。各記事が個別にカニバリゼーション回避と独自価値の基準を満たし、保留した枠には明確な理由がある。
• 朝に完成した各ページには、直接開いて確認できる Vercel のレビュールートと、具体的な創業者への判断依頼が 1 つある。
• 動画の概要書は価値の高いページ 1〜2 本に限定し、意図的に範囲をシンプルにし、ページのレビューを妨げない。
• canonical、タイトル、説明文、サーバー側でレンダリングされるリンク、サイトマップへの掲載を確認する。
• 新しい Vibe Code ページがコンテンツ基準を満たしている。
• 掲載が関連性／品質の基準を満たし、承認を得ている。
• 編集ページでは記事の構成、ファーストパーティのスクリーンショット、承認済みのロゴ、画像の出所、実際の CodeSpring 製品アセットを使用する。
• 比較表は簡潔で見やすく、内部リンクはホバーなしで見え、関連するホームページまたはドキュメントのルートを参照している。
• UI に変更がある場合は、モバイル／デスクトップとテーマを確認する。
• npx tsc --noEmit、npm run build、node --test tests/*.mjs が成功する。または、変更のない既存の失敗を正確に報告する。
• ブランチをプッシュし、リモートの SHA を確認し、main をターゲットとするドラフト PR を作成する。
• レビュー用プレビューと AWS の本番ステータスを分けて報告する。
• 承認と AWS での確認後、サイトマップ／内部リンク／Search Console のインデックス登録に関する引き継ぎ情報を提供する。クロールのリクエストによってインデックス登録が保証されるような表現は決してしない。