Xとは何か(What Is X)のページ:構造とサンプル
40〜60語で質問に回答し、例や境界を通して概念を説明し、用語集とのカニバリゼーションを防止する「What Is」ページを構築します。
「What Is」ページは、名前付きの質問に答えるページです。主題を40〜60語の自己完結型の文章で定義し、その後、単純な意味から正確な境界、目的、仕組み、例、誤り、除外事項、関連概念へと展開します。最初の段落で読み終えるかもしれない好奇心旺盛な読者や、主題を正確に説明できるようになるまで読み続ける読者に対応します。
目的: 読者に完全なフィールドガイドを強制することなく、馴染みのない概念や曖昧な概念を明確なメンタルモデルに変換すること。
読者の質問: 「Xとは何か、実際にはどういう意味か、そして混同しがちなものとはどう違うのか?」
この認知段階(アウェアネス)のフォーマットは、 SEO投稿タイプシステムに属します。定義クエリには明確な回答の形が必要だからです。冒頭が回答であり、以降の各セクションは、その回答をより正確で、有用で、誤用しにくくすることによって存在価値を得ます。
回答する質問
読者が辞書的な一文だけを求めていることは稀です。クエリは2〜3語かもしれませんが、実際の質問は通常、以下の順序で展開します:
- 「Xとは平易な英語で何か?」
- 「正確には何がXに該当するのか?」
- 「Xはなぜ存在し、どのような問題を解決するのか?」
- 「Xはどのように機能するのか?」
- 「具体的な状況でXはどのように見えるのか?」
- 「人々はなぜXを誤解したり誤用したりするのか?」
- 「Xに近いが、実際にはXではないものは何か?」
- 「次に理解すべき関連アイデアはどれか?」
このページは2つの読み取りモードをサポートします:最初の40〜60語での完全な回答と、その定義と決して矛盾しない深い説明です。
この投稿タイプを使用するタイミング
短いリファレンス定義と質問主導の説明は、異なる情報問題を解決します。 用語集ページは用語に固定されています:正規の意味、用法、別名、関係性を提供し、サイトの他の場所から訪れた読者にも役立ちます。「What Is」ページは質問に固定されています:文脈、起源、影響、例、誤解、概念が重要である理由を説明する余地があります。
この区別は、一般的な情報アーキテクチャのエラーを防ぎます:同じ約束をする2つのページ。キーワードカニバリゼーションは、複数のページが実質的に同じクエリと目的で競合し、どれが正規ページか不明瞭になるときに発生します。各フォーマットに異なる役割を割り当てることで回避してください。
両方のページを持つのは、用語に安定したリファレンスが必要で、より完全な説明に対する需要がリサーチで確認され、説明ページが深さラダーを完成できる場合のみにしてください。用語集には「Xの定義」、別名、簡潔な区別を任せてください。「What Is」ページには、なぜ存在するのか、仕組み、例、誤り、結果を任せてください。双方向にリンクし、用語集を用語リファレンス、説明ページをより深い解説としてラベル付けしてください。
| このタイプを選択 | 読者の主な目的が次の場合 | 期待される回答の形 | 使用すべきでない場合 |
|---|---|---|---|
| What Is ページ | 概念を基本から理解する | 40〜60語の回答と、深さラダー、例、境界、関連概念 | 短いリファレンス定義を繰り返すだけになる場合 |
| 用語集エントリ | 用語を調べ、正規の意味を確認する | 簡潔な定義、別名、用法、近い用語 | 文脈、仕組み、歴史、影響が本当の価値である場合 |
| アルティメットガイド | 複数のサブトピックを持つ広範な主題を習得する | 包括的な階層、エビデンス、ツール、判断、次のアクション | 1つの質問と1つの中心概念が範囲を定義する場合 |
| ハウツーガイド | 手順を完了し、結果を確認する | 前提条件、順序付きステップ、チェックポイント、トラブルシューティング | 読者が最初に必要なのは指示ではなく理解である場合 |
最適なビジネスタイプ
このフォーマットはビジネスモデル全体で有用ですが、緊急度は均一ではありません。コマーシャルページが意味をなす前に、カテゴリ、方法、技術的メカニズム、馴染みのない購入者の問題を説明する必要性がどれだけ頻繁にあるかでランク付けしてください。
- SaaS。 SaaS企業は多くの場合、新しいカテゴリや技術的能力を販売します。説明ページは、製品、ユースケース、比較ページの前に見込み客が必要とするモデルを構築します。教育的なままで、すぐに売り込みに転じないようにしてください。
- B2Bサービス。 購入者は、方法、リスク、規制、サービスモデルに関する共通の語彙を、プロバイダを評価する前に必要とします。明確な説明ページは、主題に関する専門性も示します。
- メディアパブリッシャーとアフィリエイト。 耐久性のある説明ページはトピックカバレッジをサポートし、比較記事やリスト記事に、背景知識のない読者のための正確な行き先を提供します。
- Eコマース。 買い物客は、素材、規格、仕組み、フィット感、互換性の用語を選択前に理解する必要がある場合があります。資格のある読者を製品に誘導する前に、カテゴリを教育してください。
- マーケットプレイス。 取引モデル、参加者の役割、信頼メカニズム、カテゴリ用語を説明してください。買い手と売り手の質問を混在させるのではなく、対象となる参加者を明示してください。
- ローカルサービス。 馴染みのない診断、方法、法的概念、技術用語に対して選択的に使用してください。馴染みのあるサービスは通常、サービスページが必要です。
検索意図
検索意図とは、クエリの背後にある目的です。「Xとは何か」の場合、支配的な意図は情報収集です:読者は評価や行動の前に意味を求めています。検索修飾子は必要な深さを明らかにします。「X 意味」はコンパクトなリファレンスで許容されるかもしれません。「Xとは何か、どのように機能するのか」は仕組みを求めます。「マーケティングにおけるXとは何か」はドメインの境界を追加します。「X 例」は抽象概念を問題にします。
草案を作成する前に、現在の 検索エンジン結果ページとAI回答をレビューしてください。回答の形は主題や市場によって変化するからです。結果が定義で始まるか、リファレンスソースを好むか、図を含むか、フォローアップ質問を露出するかを記録してください。AI回答については、定義、保持された修飾語、引用、ニアミスの対比を記録してください。
レビューを使用して、最低限の回答契約と未回答のニーズを特定してください。ランキングコピーを模倣するためではありません。H1の直後に1つの直接回答を置き、そこに必須の修飾語を含めてください。抽出によって後の注意事項から分離される可能性があるからです。
ページ構造
範囲は制御値であり、割り当てではありません。深さとは、新しい形容詞で定義を繰り返すことではなく、異なる質問を解決することを意味します。
| セクション | 語数範囲 | 目的 | ステータス |
|---|---|---|---|
| 直接定義 | 40〜60 | H1に完全に回答し、主題、カテゴリ、識別特徴、必須の修飾語を明示する | 必須 |
| 平易な言葉による説明 | 80〜150 | 定義を日常言語に翻訳するが、正確な用語は置き換えない | 必須 |
| 正確な定義と範囲 | 120〜220 | 何が該当するか、定義が適用される場所、どの境界条件が重要かを述べる | 必須 |
| 存在理由 | 150〜250 | 概念を有用にした問題、制限、または歴史的条件を説明する | 必須 |
| 仕組み | 250〜450 | メカニズムやシーケンスを概念レベルで説明する(タスクチュートリアルではない) | 必須 |
| 1つの規律あるアナロジー | 60〜120 | 1つのメンタルモデルを提供し、アナロジーが正確でなくなる点を明示する | 条件付き:仕組みが抽象的すぎる場合に使用 |
| 具体例 | 180〜300 | 1つの現実的なケースを、入力からメカニズム、観察可能な結果まで追跡する | 必須 |
| 誤解されやすい点 | 150〜250 | 一般的な推論、実装、解釈のエラーを修正する | 必須 |
| そうではないもの | 150〜250 | 2〜5のニアミス混乱を明確な対比で解消する | 必須 |
| 影響 | 150〜300 | 概念が理解された後、読者、組織、システムに何が変わるかを説明する | 条件付き:結果が重大な場合に使用 |
| 関連概念 | 100〜180 | 前提条件、兄弟概念、次のステップの概念との関係を定義する | 必須 |
| FAQ | 200〜400 | 見出しの繰り返しではない、5〜8の残された質問に回答する | 必須 |
| CTA | 30〜80 | 認知段階の読者にマッチした1つの次のアクションを提供する | 必須 |
アナロジーは正確さと引き換えに親しみやすさを得ます。1つ使用し、「アナロジー」とラベル付けし、その限界を明示してください。比較を積み重ねるとメカニズムが不明瞭になります。
必須要素
再利用可能な要素には正規の仕様があり、通常のセクションにはありません。例、「そうではないもの」リスト、図は、新しい要素タイプとして発明されることなく、構造要件として残ります。
| 要素 | 常時または条件付き | 正確な位置 | 理由 |
|---|---|---|---|
| 直接回答ブロック | 常時 | H1の直後 | ナビゲーション、場面設定、プロモーションが回答を遅らせる前にクエリを満たす |
| 定義ボックス | 常時、直接回答と統合 | 同じ冒頭位置;1つのボックス、繰り返しブロックではない | この投稿タイプでは、定義と直接回答は同じ役割を果たし、1つの正規表現を共有する必要がある |
| 注釈付きスクリーンショット | 条件付き | ユーザーインターフェースまたは観察可能な視覚状態を説明する最初の文章の隣 | 曖昧なインターフェース参照を検証可能な証拠に変える;抽象的なメカニズムの場合は代わりに概念図を使用する |
| 関連コンテンツブロック | 常時 | 関連概念の後、FAQまたはCTAの前 | このページをその質問の範囲を超えて拡張することなく、用語集リファレンス、より広範なガイド、または手順を提供する |
| FAQ構造 | 常時 | 主要な説明の後、CTAの前 | メインの深さラダーの一貫性を保ちながら、実際のフォローアップ質問を解決する |
| CTAブロック | 常時 | 最後のオーサード要素 | 説明をセールスコピーで中断するのではなく、情報を得た読者に1つの関連する継続を提供する |
| フロントマター仕様 | 常時 | ドキュメントメタデータ、レンダリング本文の前 | ページに安定したエンティティ、タクソノミー、スキーマ入力、同期されたFAQレコードを与える |
フロントマター
エンティティは質問の表現ではなく主題です。「What Is Content Pruning?」の場合は entity = "content-pruning" を使用し、entity = "what-is-content-pruning" は使用しないでください。タイトルは変更されてもエンティティは安定したままです。
プライマリスキーマタイプとして Article を使用し、サポートされている場合は about を通じて主題を特定してください。可視回答、フロントマター、構造化出力が一致し、現在のポリシーが許可する場合にのみ FAQPage を追加してください。記事全体を DefinedTerm としてマークしないでください。これは質問主導の記事であり、概念レコードそのものではありません。
| フィールド | 必須値またはルール |
|---|---|
title | 自然な質問タイトル:What Is [X]? または What Does [X] Mean? |
seoTitle | プライマリ質問と有用な差別化要因;機械的に同義語を積み重ねない |
entity | 正規の主題識別子、正規化され安定している、例:content-pruning |
description | 150〜160文字;ページが説明する内容を回答し、クリックする理由を与える |
type | academy |
playbookPillar | この仕様では post-type;制作された記事ではサイトの通常のタクソノミーを使用する |
playbookFamily | definition-and-entity |
journeyStage | awareness |
elements | 実際に存在するレンダリング要素の順序付きリスト |
businessTypes | 主題が実際にサービスを提供するモデルのみ、優先順位順 |
schemaType | Article;該当する場合は追加で FAQPage ノード |
date および lastmod | 公開日と重要なレビュー日;意味、例、境界が変わったときに lastmod を更新 |
keywords | 編集範囲に使用される6〜8の自然なバリエーションとドメイン修飾語(繰り返しではない) |
[[lnks]] | すべての内部本文リンクに1レコード、アンカーテキストは text と完全に一致 |
[[faq]] | 5〜8レコード、可視の質問と回答と同一 |
完全な例
このコピーペースト可能なスケルトンは実際の主題を使用しています。各括弧で囲まれたコンテンツ契約をリサーチしたコピーに置き換えてください。冒頭の定義はすでに必要な長さを示しています。
# What Is Content Pruning?
Content pruning is the deliberate process of removing, merging, redirecting, or substantially improving pages that no longer serve a useful audience or business purpose. It is not indiscriminate deletion: each URL is evaluated against evidence, site structure, and future value before a team decides to keep, update, consolidate, redirect, or retire it.
## Content pruning in plain English
[Explain how pages become outdated or overlapping and why pruning chooses a useful future state rather than merely reducing URL count.]
## The precise definition and scope
[Define the evaluated unit, evidence window, possible actions, and approval boundary. Distinguish pruning from routine edits and technical cleanup.]
## Why content pruning exists
[Explain how facts, products, and page purpose change, and why leaving every URL untouched has a maintenance cost.]
## How content pruning works
[Describe inventory, evidence gathering, classification, action selection, dependency review, publication, and monitoring. Reserve execution details for a how-to.]
### Analogy: tending a reference library
[Map page maintenance to tending a reference library, then state the limit: URLs have links, redirects, search history, and conversion paths.]
## A concrete content-pruning example
[Trace three overlapping articles through evidence review, merge, redirect, and monitoring decisions.]
## Where teams get content pruning wrong
[Explain deleting by traffic alone, ignoring seasonality or links, merging different intents, and making changes without a baseline.]
## What content pruning is not
- It is not deleting every low-traffic URL; some pages serve narrow but important audiences.
- It is not rewriting every old article; unchanged pages may still be accurate and useful.
- It is not a one-time purge; the library needs a review cadence and decision history.
- It is not a substitute for fixing crawl, indexing, measurement, or product problems.
## What content pruning changes
[Explain clearer topic ownership, current answers, simpler maintenance, and better reader routes without promising rankings.]
## Related concepts
[Relate consolidation, redirects, audits, information architecture, and governance; link only to destinations with distinct jobs.]
## FAQ
[Add five to eight residual questions about evidence windows, redirects, seasonality, approval, monitoring, and reversal.]
## Decide the next action
[Offer one continuation: a related concept, procedural guide, or inventory evaluation.]
デザイン例
ギャラリーは階層をテストするものであり、装飾ではありません。すべてのキャプチャは同じコンテンツプルーニングの例を使用し、H1の直後に回答を配置します。
正確なファイルが存在する場合のみコメントを置き換えてください。図は関係性やフローを説明する必要があります。装飾は要件を満たしません。
品質チェックリスト
レビューアは、各基準を可視コピーに対してチェックでき、作成者の意図から適合性を推測する必要はありません。
- 最初の40〜60語が、前置き、未定義の代名詞、次の段落への依存なしにH1に回答している。
- 冒頭の回答が、主題のカテゴリ、識別特徴、意味を変える修飾語を明示している。
- 平易な言葉による説明と正確な範囲が、互いを言い換えるのではなく、異なる価値を追加している。
- ページがラダーを完了している:回答、定義、目的、仕組み、例、誤り、除外、関連概念。
- 1つの具体例が、認識可能な入力、メカニズム、結果を通じて概念を追跡している。
- アナロジーは明示的にラベル付けされ、1回のみ使用され、その限界が続いている。
- 「そうではないもの」が2〜5の真のニアミスを対比し、決定的な違いを説明している。
- 関係性やフローが密な説明を必要とする場合に図が含まれ、そのキャプションが本質的な意味を伝えている。
- 用語集とWhat Isページの両方が存在する場合、異なるタイトル、プライマリクエリ、スコープ、内部リンクの役割を持っている。
- 変更される可能性のある事実の主張にはすべて、制作エビデンス記録に出典と確認日がある。
- 5〜8のFAQが残された質問に回答し、フロントマターレコードと完全に一致している。
- 最終CTAが1つの認知段階に適した次のアクションを提供している。
よくある間違い
- 定義を遅らせること。 回答の前にストーリー、トレンドの主張、セールスの導入を置くと、フォーマットの中心的な約束を破ります。
- 循環定義を書くこと。 「AI可視性とは、AIにおいてどれだけ可視的であるか」は、ラベルを繰り返すだけで意味を追加しません。
- 専門用語を専門用語で定義すること。 冒頭の用語は馴染みがあるか、インラインで定義されるか、直後に紹介される必要があります。
- 用語集記事を2回公開すること。 両方のページが同じクエリとセクションを所有している場合、語数が多いだけでは説明ページにはなりません。
- 「仕組み」をチュートリアルに変えること。 詳細なステップ、前提条件、トラブルシューティングは手順系の兄弟ページに属します。
- アナロジーを積み重ねること。 限界を明示した1つのラベル付きアナロジーを使用してください。
- 除外事項を省略すること。 「そうではないもの」がないと、読者はもっともらしいが間違ったニアミスの解釈を持ち帰る可能性があります。
- 関係性なしに関連用語を列挙すること。 それぞれが前提条件、コンポーネント、兄弟、代替、結果のいずれかを明示してください。
- 普遍的な利益を主張すること。 名前付き条件の下で結果を説明してください。ランキング、収益、安全性、コンプライアンスを約束しないでください。
内部リンク
What Is ページは、その概念を使用する用語集エントリ、ガイド、製品教育、ユースケース、比較、アカデミードキュメンテーションからリンクを受けるべきです。概念が必要になる最初の有用なリンクを配置し、説明的なアンカーテキストを使用してください。
読者の次の未解決の目的に従って外部にリンクしてください:
- 正規の用語、別名、簡潔なリファレンスについては用語集にリンクする。
- 周辺分野のより広範なガイドにリンクする。
- 理解が完了し、次の質問が「どうやってやるのか?」になったら手順にリンクする。
- 教育的な説明がその関連性を明確にした後にのみ、製品やユースケースにリンクする。
- 前提条件と隣接概念に、その関係性を明示してリンクする。クロージングブロックには2〜4つを選択する。
用語集のリファレンス機能、アルティメットガイドの幅広さ、ハウツーの手順を複製しないでください。用語集と説明ページを双方向に接続し、「Xの仕組み」や「Xの定義と用語」などの明確な約束をしてください。
結果の測定方法
回答の発見、正しい理解、有用な継続を測定してください。公開前に、プライマリクエリ、意味とドメインのバリエーション、2〜3のニアミス質問のベースラインを測定してください。AmICitedの プロンプトトラッキングを使用して、AI回答がエンティティに言及し、その修飾語を保持しているかを確認してください。
ソース・引用インテリジェンスをレビューして、ページ自体がそれらのプロンプトに対して引用されているか、別のサイトが定義、例、対比に使用されているかを確認してください。 AmICited Cockpitで、可視性と引用の動きを、オーガニックインプレッション、エンゲージされた訪問、選択された関連ページへの移動、最終CTAアクションと比較してください。修飾語を剥奪したりエンティティを混乱させる引用は、ブランドが言及されていてもクリーンな成功ではありません。
SEO結果フレームワークを使用して、定義された観察期間の後にアクションを選択してください:維持、冒頭の回答のリフレッシュ、例の強化、境界の明確化、重複ページの統合、内部リンクルートの変更。タイミングだけでこのページにコマーシャル成果を帰属させないでください。その認知段階の役割は、後のページがコンバージョンする前に貢献することがよくあります。
FAQ
「What Is」ページの長さはどのくらいにすべきですか?
深さラダーを完成させる最短の長さにしてください。ほとんどの主要な主題は約1,200〜2,500語を必要としますが、範囲、曖昧さ、有用な例の数は固定された合計語数よりも重要です。
「What Is」ページと用語集エントリの違いは何ですか?
用語集エントリは用語の安定したリファレンスです。「What Is」ページは質問に回答し、概念が存在する理由、仕組み、例、誤り、境界、影響を展開できます。
同じトピックに用語集エントリと「What Is」ページの両方を持つことはできますか?
はい。読者が正規の用語リファレンスと、質問主導の本格的な説明の両方を必要とする場合です。各ページに異なる役割を与え、異なるプライマリクエリを使用し、双方向にリンクしてください。
「What Is」ページにステップを含めるべきですか?
対象の仕組みを説明するためにステップが必要な場合にのみ、短いプロセス概要を含めてください。手順の完了が読者の主な目的であれば、別のハウツーガイドを公開してください。
直接回答と定義ボックスは互いに内容を繰り返すべきですか?
いいえ。「What Is」ページでは両者が同じ冒頭の役割を果たすため、H1の直後に1つの40〜60語の定義ボックスに統合してください。
「What Is」ページにFAQスキーマは必要ですか?
自動的には必要ありません。実際に残された疑問がある場合にのみ5〜8の可視FAQを書き、実装が可視回答と現在の検索エンジンポリシーに一致する場合にのみFAQPageスキーマを追加してください。
ページの残りの部分より先に最初の回答を構築する
読者の正確な質問から始め、40〜60語の回答を草案し、単独でコピーしても成立するかテストしてください。その後、深さラダーを使用してその回答を証明、例示、修飾、接続してください。 AmICited Cockpitを開いて、公開前に質問とそのニアミスバリエーションのベースラインを測定してください。
よくある質問
深さラダーを完成させる最短の長さにしてください。ほとんどの主要な主題は約1,200〜2,500語を必要としますが、範囲、曖昧さ、有用な例の数は固定された合計語数よりも重要です。
用語集エントリは用語の安定したリファレンスです。「What Is」ページは質問に回答し、概念が存在する理由、仕組み、例、誤り、境界、影響を展開できます。
はい。読者が正規の用語リファレンスと、質問主導の本格的な説明の両方を必要とする場合です。各ページに異なる役割を与え、異なるプライマリクエリを使用し、双方向にリンクしてください。
対象の仕組みを説明するためにステップが必要な場合にのみ、短いプロセス概要を含めてください。手順の完了が読者の主な目的であれば、別のハウツーガイドを公開してください。
いいえ。「What Is」ページでは両者が同じ冒頭の役割を果たすため、H1の直後に1つの40〜60語の定義ボックスに統合してください。
自動的には必要ありません。実際に残された疑問がある場合にのみ5〜8の可視FAQを書き、実装が可視回答と現在の検索エンジンポリシーに一致する場合にのみFAQPageスキーマを追加してください。
このセクションの他のチュートリアル
実践する準備はできましたか?
無料チェック · 7日間お試し · クレジットカードが必要