关键词密度：标题承诺与正文怎样对应
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /d8cb92dc9631.html
📄
关键词密度：标题承诺与正文怎样对应
标题里出现“关键词密度”，正文就必须围绕这个指标本身展开，而不是写一篇泛泛的SEO通稿。读者看到标题后，期待的是一套可执行的判断方法：怎样确定全文围绕哪个词、怎样在标题和正文之间建立对应、怎样检查是否偏离、多人协作时怎样减少返工。对应关系的核心不是让某个词反复出现，而是让标题提出的问题在正文里被逐项回答。
准备：先把标题拆成可核对的承诺
多人协作最容易出问题的地方，是标题由一个人写、正文由另一个人写，双方对“这篇到底回答什么”理解不同。开始写正文前，先把标题拆成两到三个必须回答的子问题，写进共享文档。以“关键词密度：标题承诺与正文怎样对应”为例，可以拆成：密度指什么、标题与正文的对应如何检查、多人协作时怎样避免跑题。正文的每个<h2>至少对应其中一个子问题，不对应的小节要么删除，要么移到别的文章。
这一步的产出物是一张对应表，而不是一段说明文字。表格里列出标题承诺、对应小节、负责的人。如果某个承诺找不到负责的小节，说明标题写大了；如果某个小节找不到对应承诺，说明正文写偏了。
实施：让每个小节都回应标题里的具体对象
标题承诺与正文对应，落地时看三件事。第一，标题里的核心对象必须在正文里被直接讨论，不能只出现同义词替换。第二，每个<h2>的标题应当能独立读出它回答的是标题的哪一部分。第三，段落里的例子、清单、判断标准要服务于这个对象，而不是顺手写进来的通用知识。
以密度为例，正文应当说明：密度是某个词或短语出现次数与全文可读文字总量的比值，它只是一个描述性数字，没有适用于所有网站的固定阈值。这个判断本身就是对标题的兑现。如果正文转而大谈外链、页面速度、收录机制，读者会觉得标题和内容对不上。
多人协作时，建议在初稿阶段就做一次“标题回读”：把标题遮住，只读每个<h2>，看能否还原出文章主题。如果还原不出来，说明小节标题太泛。常见的泛标题包括“基本概念”“注意事项”“优化建议”，它们不指向任何具体对象，也不承担任何承诺。
验证：用检查项判断对应是否成立
验证不需要工具，按下面清单逐项过一遍即可。每项给出“通过”和“不通过”的判断结果，便于交付时留痕。
- 标题里的核心对象在正文首段被直接解释，而不是绕开。不通过的表现是首段只谈行业背景。
- 每个<h2>都能对应标题的一个子问题。不通过的表现是有小节与标题无关，或两个小节在回答同一个子问题。
- 正文没有把描述性指标写成硬性阈值。不通过的表现是出现“必须达到某个百分比”这类没有依据的断言。
- 例子和清单紧扣本题。不通过的表现是例子换成任何一篇SEO文章都成立。
- 结尾给出的是与本题直接相关的下一步，而不是通用总结。不通过的表现是结尾复述全文。
如果一项不通过，优先改标题或改小节标题，而不是在正文里补一段解释。补解释往往让文章更长、更散，对应关系反而更弱。
维护：把对应关系变成可复用的交付习惯
对应关系不是一次性的检查，而是协作流程的一部分。建议在共享文档里保留三样东西：标题拆解出的子问题、子问题与小节的映射、每次修改后的检查记录。这样换人接手时，不需要重新猜标题想说什么。
维护阶段还要处理一种常见情况：标题在写作过程中被改动，但正文没跟着改。判断方法是把当前标题和当前小节标题放在一起读，看是否仍然成立。如果不成立，要么把标题改回去，要么调整正文结构。不要用“标题更吸引人”作为保留不对应标题的理由，那会把返工推迟到发布之后。
下一步可以直接做一件事：打开你正在协作的那篇稿子，把标题拆成子问题，逐条标注对应的小节。找不到对应的小节标为待处理，找不到承诺的小节标为待删除或待迁移。这张标注表就是最直接的交付依据。
