应根据用户是否需“照着做”判断：纯讲原理、架构、API设计的用Article；含明确步骤、命令、配置、预期输出的必须用HowTo，且itemtype须为完整HTTPS URL（如https://schema.org/HowTo），大小写、协议、尾缀均不可错。
技术文档指南不能用 WebPage 或 CreativeWork 敷衍标记——Google 不会因此生成富摘要；必须按内容形态选 Article（概念讲解类）或 HowTo（可执行操作类），且 itemtype 必须是完整 HTTPS URL，缺一个字符就失效。
怎么判断该用 Article 还是 HowTo
关键看用户是否要“照着做”。纯讲原理、架构图、API 设计思想的文档 → 用 https://schema.org/Article；带明确步骤、命令行、配置修改、预期输出的指南 → 必须用 https://schema.org/HowTo。后者校验极严：漏掉 step、name 或 itemListElement 中任意一项，Google Rich Results Test 就标红报错。
- 常见误判：把“Nginx 配置 TLS 1.3”这种含具体指令的页面标成
Article→ 富摘要不触发 -
HowTo要求每个步骤用- ...
itemprop="itemListElement"，不能只靠段落编号 - 若文档前半讲原理、后半教操作，建议拆成两个独立
itemscope区块，分别用Article和HowTo
itemtype 写错的三种高频失效场景
itemtype 看似简单，但 2026 年所有主流工具（Google Rich Results Test、Bing Markup Validator）已强制校验协议、大小写、尾缀。以下写法全部无效：
-
http://schema.org/HowTo—— HTTP 协议被静默丢弃 -
https://schema.org/howto—— 小写howto不匹配官方类型名（必须大写 H） -
https://schema.org/HowTo/—— 末尾斜杠仅对Question/、Answer/等少数类型有效，HowTo不接受斜杠
正确唯一写法：https://schema.org/HowTo 或 https://schema.org/Article，全大写、无空格、无路径后缀。
HowTo 必须配齐的三个字段及写法要点
即使 itemtype 和 itemscope 都对，HowTo 仍需三个强制字段才能通过校验：
-
itemprop="name"：必须是或级标题，不能塞在
Convert Markdown To HTML And PDF - Markdown和HTML、PDF互转下载实现 Markdown↔ HTML 互转，支持导出 PDF，用于用户请求的文档格式转换。
-
itemprop="step"：每个步骤必须包裹在itemprop="itemListElement"的容器中，推荐用 -
itemprop="totalTime"（可选但强推）：用标注总耗时，格式必须是 ISO 8601（如PT10M表示 10 分钟），文本描述无效
注意：articleBody 在 HowTo 中不被识别，正文内容必须全部落在 step 结构内；混用会导致字段被忽略。
嵌套作者、代码块、错误提示的正确姿势
技术文档常含作者信息、终端命令、报错截图——这些不是字符串，而是需独立声明类型的子实体：
- 作者必须用
https://schema.org/Person，不能只写名字：李四 - 命令行示例用
+itemprop="text"，但需额外声明类型：（注意是 <code>Code</code>，非 <code>ComputerLanguage</code>）
- 错误信息（如
Connection refused）若想结构化，需套https://schema.org/Message：Connection refused
所有嵌套都必须显式带 itemscope 和对应 itemtype，隔一层或只写 itemprop 就等于没写。
最易被忽略的是：技术文档里的“版本号”（如 Node.js v20.12.0）不是普通文本——若需结构化，得用 https://schema.org/SoftwareApplication 嵌套并声明 applicationCategory 和 softwareVersion，否则它只是页面上的一串字符，进不了结构化数据流。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
