page-metadata

SEO オンページ：ページメタデータ

メタデータのライフサイクル全体を統括します。スコープ、ルーティング、実装、検証、納品を担当し、専門スキルはそれぞれの文章作成とタグのルールを担当します。

呼び出すとき：初回の使用時に、スコープと必要な専門スキルを簡潔に伝えます。その後、独立したコピー用シートを作成するのではなく、現在の本番環境の証拠と実際の信頼できる情報源に基づいて作業します。

担当範囲と境界

項目	担当
ライフサイクル、ページ一覧、実装、検証、納品	page-metadata
<title> の作成とレビュー	title-tag
メタディスクリプションの作成とレビュー	meta-description
H1-H6 の作成と階層構造	heading-structure
Open Graph	open-graph
X/Twitter Cards	twitter-cards
Canonical URL	canonical-tag
ローカライズ	localization-strategy, translation
リリース後のクエリと CTR の観測	google-search-console

このスキルでは、メタデータの約束が満たされていることを確認するために、H1 と本文の網羅性をチェックできます。H1-H6 を書き換えてはいけません。その作業は heading-structure に依頼してください。キーワードのカニバリゼーションは報告できますが、ページの統合、ページの役割の変更、URL の削除、ターゲットキーワードの再配分を行ってはいけません。

必要な入力情報と証拠

ルートに contextus.md がある場合は読み込み、関連するモジュールのみを読み込みます。それ以外の場合は、プロジェクトのドキュメントと検証済みの製品情報を使用します。以下を確認します。

1. 対象サイト、ロケール、環境、リリースのスコープ。
2. 本番環境のナビゲーション、フッター、コンテキストリンク、インデックスまたはハブページ、robots.txt、サイトマップ、本番 URL、アプリケーションのルートからページ一覧を作成します。サイトマップは証拠の一つですが、完全な一覧である保証はありません。自動生成されるページ群が非常に大規模な場合は、すべての URL を列挙するのではなく、テンプレートと代表的な例を確認します。
3. ページの種類、固有の役割、主要な検索意図、ターゲットクエリの根拠、対象ユーザー、ページ固有の事実。
4. 現在の本番環境の出力：title、description、H1、canonical、robots、hreflang、OG、Twitter Cards、HTTP ステータス、サーバーから返された HTML。
5. 実際のメンテナンス元：フレームワークのメタデータ API、レイアウトテンプレート、ルートモジュール、静的 HTML、JSON/YAML、CMS フィールド、サーバーインジェクション、プロキシレイヤー。

ソースコードだけから現在の本番環境のメタデータを推測してはいけません。デプロイ環境と本番環境は、どちらの方向にも異なる可能性があります。

ライフサイクル

1. ページを調査して分類する

• URL とページタイプの対応表を作成し、繰り返し登場するページ群から代表的なサンプルを選びます。
• 欠落、重複、古い情報、継承、フォールバック、ロケール間でのメタデータを特定します。
• タイトルを作成する前に、テンプレートによってブランド名のサフィックスが追加されるかを確認し、重複を防ぎます。
• 古いブランド名、親製品に関する表現、廃止された機能、兄弟ページからコピーされた主張にフラグを立てます。

2. 検索意図とページの特性を確認する

• そのページ単独で何を約束し、証明できるかを確認します。
• 検証済みの製品情報と現在のページコンテンツを使用し、差別化要因を作り出さないでください。
• 入れ替えテストを適用します。タイトルまたはディスクリプションを変更せずに兄弟ページへ移せる場合、そのページ固有の情報が不足しています。
• 影響を受ける URL、重複する検索意図、根拠とともに、カニバリゼーションの可能性を報告します。報告にとどめます。

3. 専門スキルに作業を依頼する

• title に関する判断には title-tag を、ディスクリプションには meta-description を使用します。
• 見出しを実際に編集する必要がある場合のみ heading-structure を使用します。それ以外の場合は意味上の整合性をチェックします。
• ソーシャルメタデータには open-graph と twitter-cards を使用します。ソーシャル用の文章は SEO 用の文章と異なってもかまいませんが、ページの特性と主張は一貫させます。
• 該当する場合は canonical-tag、localization-strategy、translation を使用します。

4. 市場ごとにローカライズする

• ロケールごとに検索クエリの言語とインテントを調査します。ソースのメタデータを翻訳して切り詰めてはいけません。
• 用語集が存在する場合はそれを用いて、製品およびブランドの用語を意図的に維持します。
• 各ロケールの URL、canonical、hreflang セット、og:locale の関係を確認します。
• ロケールページが欠落している場合や実質的に同等でない場合は、同等性を捏造するのではなく、実装上の問題として扱います。

5. 信頼できる唯一の情報源で実装する

• 生成された出力ではなく、canonical なコードまたは CMS のフィールドを編集します。
• 別途移行タスクで変更しない限り、URL とページの同一性を維持します。
• レイアウトの継承、ルートの優先順位、テンプレートの補間、CMS のフォールバック、自動的なブランドサフィックスを考慮します。
• title、description、ソーシャルメタデータ、canonical、robots、hreflang を、文字列を同一に強制することなく内部的に一貫させます。

6. リリース前に検証する

関連する lint、型チェック、テスト、本番ビルドを実行します。次に、可能であればビルド済みアプリケーションを起動またはプレビューし、代表的な URL とロケールについて初期サーバーレスポンスの HTML を検査します。クローラーが異なる HTML を受け取る可能性がある場合、ブラウザの DOM スナップショットだけでは不十分です。

確認事項:

• 有効な title がちょうど 1 つ、意図した description が 1 つあること。
• 空、プレースホルダー、重複、二重サフィックスの出力がないこと。
• title と H1 が、同一の文言を必要とせずに同じページインテントを満たしていること。
• H2 および本文コンテンツがメタデータの約束を裏付けていること。
• canonical、robots、hreflang、OG、Twitter タグが意図した絶対 URL に解決されること。
• HTML エスケープ、ロケール出力、画像、ステータスコードが正しいこと。

7. 本番環境を検証して観察する

• デプロイ後、代表的な本番 URL を生のレスポンス HTML を使用して再確認します。
• 利用可能な場合はプラットフォームのプレビュー／デバッグツールをソーシャルタグに使用します。キャッシュされたプレビューは更新が必要な場合があります。
• 再クロール後に google-search-console を使用して、クエリの構成、表示回数、title／スニペットの挙動、CTR を観察します。ランキングや CTR の向上を約束してはいけません。

その他の技術メタデータ

• robots はページレベルのインデックス登録／スニペットの挙動を制御し、robots.txt はクロールを制御します。戦略には indexing と robots-txt を使用します。
• viewport は通常 width=device-width, initial-scale=1 を使用します。
• ドキュメントの head の早い段階で UTF-8 を宣言します。
• Hreflang アノテーションは、有効な言語コードまたは言語-地域コードを使用し、自己参照と相互参照を含め、各ロケールをそれぞれの canonical URL に一致させる必要があります。HTML、サイトマップ、または HTTP ヘッダーを一貫して使用します。

成果物

スコープとエビデンス、影響を受ける URL または URL 群、それらの真の保守ソース、有用な場合は変更前／変更後のメタデータ、未解決のブロッカー、カニバリゼーションの報告、ビルド／HTML／ロケール／本番環境の検証、およびリリース後の観察計画を提供します。

主な参照資料

• Google: title リンク
• Google: スニペットとメタディスクリプション
• Google: ローカライズ版

関連スキル

• title-tag、meta-description、heading-structure
• open-graph、twitter-cards、canonical-tag
• localization-strategy、translation
• indexing、robots-txt、google-search-console