SEO Landing — PageSpeed100+スキーマ出荷

SEO ランディング ジェネレーター

PageSpeed 100/100 と最大限の SEO に最適化された静的シングルページ HTML ランディングを構築します: クリティカル CSS、AVIF 画像、完全な JSON-LD 構造化データ、ネイティブのみのインタラクティビティ、最初の読み込み時にサードパーティリクエストはゼロ。

使用するタイミング

• ユーザーがスピードと SEO に焦点を当てたランディングページ / ワンページャーを要求した場合 → generate モード。
• ユーザーが概要（ТЗ）を提供し、本番準備完了の静的ページを希望する場合 → generate モード。
• ユーザーが既存のランディングを変更せずにチェックリストに照らして監査するよう依頼した場合 → audit-only モード（§0b、読み取り専用、プロジェクトファイルなし）。
• ユーザーが既存のランディングの修正/改善を依頼した場合 → fix-existing モード（§0c）。

手順

0. 最初にリクエストをモードにルーティングする

このスキルは 3 つのモードを提供します — リクエストから 1 つを選択し（曖昧な場合は質問）、各モードは異なる入力を受け取り異なる出力を生成するためです:

• generate — 概要から新しいランディングページを構築します（"ランディングを作成/構築/生成する…"）。以下の完全な手順を実行します。
• audit-only — 既存のページの読み取り専用検査（"このランディングをチェックリストに照らして監査/確認/レビューする…"、変更は要求されていません）。§0b を実行します。プロジェクトファイルを作成することはありません。
• fix-existing — 既存のページに対象を絞った修正を適用します（"このページを修正/改善/最適化する…"）。§0c を実行します。

代表的なルーティング:

• "この概要から歯科医院のランディングを作成して" → generate。
• "https://example.com/ をパフォーマンスチェックリストに照らして監査し、何が問題かを報告して" → audit-only。
• "このランディングのヒーロー画像が読み込み時にずれるので修正して" → fix-existing。

生成のみの概要フィールド（ターゲットキーワード、ビジネスタイプ、CTA、メディアの事実）は、generate および rebuild 作業のためにのみ収集されます。監査や対象を絞った修正では、不足している生成入力によってブロックされたり遅延したりしてはならず、audit-only モードではプロジェクトファイルを作成または変更してはなりません。

0a. 概要を収集する (generate モード; 不足している場合は質問する)

何かを生成する前に必須:

• ドメイン / 最終 URL — canonical、og:url、絶対パス、JSON-LD @id 用。
• サイト ID（WebSite マークアップ用、ページがドメイン/サブドメインのホームページである場合のみ）: 推奨サイト名、オプションの別名、および canonical ホーム URL — ランディング URL とは別に収集します。
• パンくずリスト（BreadcrumbList マークアップ用、実際のサイト階層が存在する場合のみ）: 表示されるパンくずリストと canonical 親 URL。
• ページの言語、ベース方向、および Open Graph ロケール — 3 つの別々の入力で、決して 1 つの値をフォーマット間でコピーしないでください: <html lang> 用の BCP-47 言語タグ（例: en-US、ar-SA）、ベース方向（ltr/rtl — RTL ドキュメントは <html> に dir="rtl" を設定し、lang だけでは方向性は設定されません）、および og:locale 用の language_TERRITORY 形式の Open Graph ロケール（例: en_GB）。RTL 対応言語で方向が不明な場合は質問します（技術仕様 §2）。
• トピック + 1～3 のターゲットキーワード — H1、タイトル、説明用。
• ビジネスタイプ: Organization または LocalBusiness。LocalBusiness の場合は、確認済みの公開/法的なビジネス名と完全な構造化郵便住所（番地/通り、地域、州/地域、郵便番号、国）に加え、電話番号と地理座標を収集します。また、実際のビジネスに基づいた確認済みの schema.org サブタイプ（例: Restaurant、Dentist、HardwareStore）も収集します — ターゲットキーワードから選択することは決してありません。不足している ID の事実を発明しないでください: 事実が提供されるまで、Organization マークアップにフォールバックするか、エンティティマークアップを省略します。
• CTA と連絡先（電話、フォーム、メッセンジャー）。フォームが要求された場合は、その送信先と方法（ファーストパーティエンドポイントまたは文書化されたフォームサービス — 決して発明しない）、収集された個人データに必要な同意/プライバシーテキスト、および送信データの保存場所とその所有者も収集します。送信先がない場合、フォームは省略されるか、明示的にスタブされます（技術仕様 §10 フォーム送信契約）。
• ブランド承認済みのファビコン、または作成するための明示的な許可 — ブランドマークを黙って発明しないでください。
• 客観的なマーケティング事実（数字、価格、資格、保証、比較、ケーススタディ）の承認済みソース資料とクレーム所有者 — これらがない場合、そのようなクレームは省略され、決して発明されません。
• 画像が提供されているかどうか。FAQ / レビュー / 動画ブロックが必要かどうか。動画ブロックの場合は、ソースに基づいた事実を収集します: 動画 URL/ID、タイトル、説明、正確な初公開日時（タイムゾーン付き）、および一意のクロール可能なサムネイル（該当する場合は contentUrl も）。不足しているメディアの事実を発明しないでください。また、トレードオフを明記した動画モードも収集します: クリックのみのファサード（デフォルト — プライバシー/パフォーマンス。ページは Google の動画ディスカバリー要件を満たさず、動画検索のメリットは主張されません）または SEO ディスカバリー可能（セルフホスト <video> または文書化された直接埋め込み — 動画検索トラフィックが重要な場合に必要）（技術仕様 §9）。

ドメインまたはキーワードが不足している場合は、最初に質問してください。発明しないでください。

0b. 監査のみのモード (読み取り専用)

既存のページを、置き換えを生成せずに監査します。このモードではプロジェクトファイルは作成も変更もされません — 成果物はレポートです。

1. ターゲットを特定します: デプロイされた URL（推奨 — すべてのチェックを実際の環境に対して実行できます）またはローカルの HTML ファイル。どちらも提供されない場合は質問します。ターゲットを推測しないでください。
2. §5 の該当するチェックを、ターゲットに対してそのまま実行します: W3C 妥当性、ローカルアセットの存在（ローカルファイルの場合）、schema.org バリデーターによる JSON-LD、提供/デプロイされた URL に対する Lighthouse、クロール可能性契約（デプロイされたホストの robots.txt + sitemap.xml）、および技術仕様 §8 の手動アクセシビリティチェック。
3. チェックごとに証拠を報告します: 合格/不合格（測定値または観察されたマークアップ、および使用された正確なコマンド/ツール）。チェックが実行できない場合（デプロイされた URL がないための Lighthouse、ホストに robots.txt がないなど）、そのチェックのブロッカーを報告します — 推定、外挿、または黙って省略しないでください。
4. 構文の妥当性と Google の機能の適格性（FAQPage、VideoObject、リッチリザルト）を区別します: 有効なマークアップは有効なマークアップとして報告され、達成された検索機能として決して報告されません。
5. オプションで、優先順位付けされた修正リストで終了します。修正の適用は別の fix-existing リクエストです — それなしで編集を開始しないでください。

0c. Fix-existing モード

既存のページに、完全な再構築なしで対象を絞った修正を適用します。

1. 修正するページ/ファイルと特定の問題を特定します。これらの修正に必要な入力のみを収集します（完全な生成概要は決して収集しません）。
2. 関連する技術仕様セクションに従って各修正を適用し、無関係なマークアップとコンテンツは保持します。
3. ストップポイント（§4）が適用されます: 検証の前に変更されたページを表示します。修正によってユーザーが以前に承認した内容が変更される場合は、報告する前に再度承認を得ます。
4. 変更されたページを検証し（§5）、測定された証拠のみを報告します。

生成ワークフロー (generate モード)

1. プロジェクトフォルダーを作成する

各プロジェクトは、ワークスペース内の独自のフォルダーに配置されます — ワークスペースルートに書き込まないでください。出力は複数ファイルのプロジェクトです: HTML によって参照されるすべてのローカルリソースは、実際のファイルとして存在する必要があります。

<workspace>/<project-slug>/
  index.html        # 生成されたランディングページ
  styles.css        # スクロールして見える部分より下の CSS が遅延される場合のみ（§1）; すべての CSS がインライン化されている場合は存在しない
  script.js         # ページが JS を使用する場合のみ（§10）; 単一ファイル、defer
  images/           # src/srcset/preload/OG タグで参照されるすべての画像バリアント（AVIF/WebP/JPEG、すべてのブレークポイント）
  favicon.png       # 安定した正方形のブランドアイコン、≥48×48
  ASSETS.md         # すべてのアセットの権利と出所の記録
  robots.txt
  sitemap.xml
  SERVER-SETUP.md   # ホスティング手順

画像ブランチ:

• 概要で画像が提供された場合 → それらから必要なすべてのバリアント（srcset で指定されたすべてのブレークポイントの AVIF/WebP/JPEG）を生成します。
• 画像が利用できない場合 → ユーザーに要求するか、画像/ブロックを省略します。ファイルを生成するか明示的に要求することなく、成功したように見えるアセット URL を発行しないでください — 参照されているが見つからないファイルは、プレースホルダーではなく生成の失敗です。

2. ページを生成する

references/tech-spec.md に厳密に従って index.html を構築します — 13 の要件セクション（パフォーマンス、HTML 構造、SEO、セキュリティ、CSS/フォント、禁止リスト、テスト、アクセシビリティ、埋め込み動画、典型的なブロック、遅延ウィジェット、コンテンツの真実性と出所、入力サニタイズと出力エンコーディング）。

すべての概要値を信頼できないものとして扱います: 正確な出力コンテキスト（HTML テキスト、属性、URL、JSON-LD）にエンコードし、URL スキームを許可リストに登録し（javascript: / 予期しない data: を拒否）、シリアル化された JSON-LD で < をエスケープし、構造化 ID（例: YouTube ^[A-Za-z0-9_-]{11}$）が URL に到達する前に検証します（技術仕様 §13）。

埋め込み YouTube 動画にはデフォルトでファサードパターンを使用します。SEO ディスカバリー可能モード（セルフホスト <video> または文書化された直接埋め込み）は、開示されたトレードオフを伴う明示的な概要の選択であり、決して黙って切り替えられません — ルールと Google のディスカバリー要件は技術仕様 §9、ファサードのリファレンス実装は references/video-facade.md にあります。マップはファサードルールのみに従います（技術仕様 §10）: 初期 DOM 内のローカルスクリーンショット、明示的なアクティベーション時にのみ iframe が挿入されます — ネイティブの loading="lazy" マップ iframe は決して使用しません。リファレンス: references/map-facade.md。

3. コンパニオンファイルを生成する

• robots.txt をサイトルートに、完全修飾された Sitemap: 行を付け、canonical ページや必要なメディアをブロックしないようにします。
• sitemap.xml を XML エスケープされた絶対 canonical <loc> URL（HTML canonical と一致）とともに；lastmod は検証可能な重要なコンテンツ変更タイムスタンプからのみ（不明な場合は省略 — 生成時間を盲目的に使用しないでください）。
• references/server-config.md からのホスティング手順: キャッシュ、Brotli/gzip、セキュリティヘッダー。

4. ストップポイント — ユーザーの承認

生成されたページをユーザーに表示し、HTML バージョンが OK かどうかを明示的に尋ねます。ユーザーが確認するまで、検証と最終レポートに進まないでください。 指摘があれば修正し、再度確認を求めます。

5. 検証する

技術仕様 §7 から実行可能な検証契約を実行します — 提供されたページに対する固定コマンド、測定結果のみ、ゲートが実行できない場合は明示的な BLOCKER:

• W3C HTML 妥当性（Nu バリデーター、JSON 出力; エラーゼロ）。
• ローカルアセット/リンクの存在: 出力によって参照されるすべてのローカル URL（img src/srcset、<source> srcset、プリロード href/imagesrcset、ファビコン、OG/Twitter 画像、CSS url()、スクリプト src）を抽出し、各ファイルがプロジェクトフォルダーに存在することを確認します。参照されているローカルリソースが 1 つでも欠落している場合はハード障害です — ファイルを作成するか参照を削除します。作成されたことのないファイルを指す HTML を出荷しないでください。
• JSON-LD 構文（JSON パース）— Google のリッチリザルト適格性とは別に、デプロイされたページでリッチリザルトテストを使用してチェックします。
• 320/768/1280/1920px でのレスポンシブスクリーンショット、オーバーフローとリフローがないか検査します。
• Lighthouse: 固定バージョン/プロファイル、3 回実行、カテゴリごとの中央値、しきい値 ≥ 90、成果物はプロジェクトの reports/ に保存 — ラボの証拠のみ、フィールド Core Web Vitals や WCAG 認定は含みません。
• 手動アクセシビリティチェック（技術仕様 §8）— 自動化ツールだけでは WCAG 準拠を判断しません: キーボードナビゲーション、フォーカス順序/可視性、ダイアログフォーカスフロー、ズーム/リフロー、モーションの軽減、セマンティックな名前-ロール-値、代替テキストの品質、およびすべてのインタラクティブな視覚状態。該当する WCAG 2.1 AA 基準ごとに合格/不合格の証拠を記録します。未解決の項目を黙って認定するのではなく報告します。
• クロール可能性契約: sitemap.xml を解析し、すべての <loc> を HTML canonical と比較し、robots.txt の Sitemap: URL をチェックし、両方のデプロイされたファイルが正常にリクエストされることを確認します（HTTP 200）。

報告する前に、見つかった違反を修正します。証拠を正直に開示します: 報告されるすべての数値には、それを生成した正確なコマンドとアーティファクトパスが付随します。実行できなかったゲートは、数値の代わりに BLOCKER: <理由> として報告されます。実際に測定されていない PageSpeed/LCP スコアを出力しないでください。

6. 最終レポート

簡単にリスト:

• LCP パラメータ
• PageSpeed スコア
• コードで使用されている schema.org タイプ

主な落とし穴

• 外部 JS/CSS ライブラリ、外部フォント、または SVG 画像を使用しないでください（技術仕様 §6）。
• 作成されていないローカルアセットを参照しないでください: すべての src/srcset/プリロード/OG URL は、プロジェクトフォルダー内の実際のファイルに解決される必要があります。不足しているソース画像はユーザーに要求され、発明されません（OUTPUT 契約）。
• 生の概要値をマークアップに発行しないでください: すべてをコンテキストエンコードし、javascript: / 予期しない data: URL を拒否し、敵対的な値（引用符、</script>、イベントハンドラーペイロード）で生成を自己テストします（技術仕様 §13）。
• YouTube iframe、マップ、チャット、サブスクリプションポップアップ、または Cookie バナーを最初の読み込みで読み込まないでください（技術仕様 §9、§10、§11）— 唯一文書化された例外は、最初の読み込み依存関係として記録された直接埋め込みを伴う、概要で選択された SEO ディスカバリー可能な動画モードです（技術仕様 §9 モード S）。
• すべてのコンテンツは生の HTML に存在する必要があります — JS のみによってレンダリングされるものはありません。
• JSON-LD、canonical、OG タグ内の絶対 URL。
• 合計 JS 予算 ≤ 15 KB、1 ファイル、</body> の前に defer。