结论是json-ld为当前首选，因其不侵入dom、易维护、搜索引擎抓取率高；microdata因依赖可见元素、易出错、难迁移而不推荐。
直接说结论：微格式（如 hCard、hAtom）在现代 SEO 实践中已基本被 Schema.org 的 JSON-LD 方式取代；如果你不是维护老旧站点或对接特定第三方工具，itemscope + itemtype 这类 Microdata 写法也不推荐作为首选——<script type="application/ld+json"></script> 才是当前最稳妥、最易验证、搜索引擎抓取率最高的接入方式。
为什么别用 Microdata 做主结构化数据标记
Microdata 看似“嵌入 HTML 更自然”，但实际落地时问题集中：
- 必须严格依附于可见 DOM 元素，
itemprop不能脱离itemscope容器，否则 Google 直接忽略 - 嵌套复杂对象（比如
author是Person类型）时，HTML 层级容易混乱，稍一错位就失效 - 时间、价格等字段需配合
<time datetime="..."></time>或<meta content="...">，但很多 CMS 输出不规范，datetime值缺失或格式错误（如写成"2024-05-20"而非"2024-05-20T00:00:00+08:00"） - 页面改版时，前端模板里散落的
itemprop极难批量清理或迁移，容易残留过期字段
<script type="application/ld+json"></script> 怎么放才不被忽略
Google 明确表示：该 script 块必须是纯 JSON，且不能被 JS 动态插入。常见失效原因不是语法错，而是加载时机和位置问题：
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- 放在
顶部或开头均可，但不要塞进其他<script></script>标签内部（比如写在某个初始化函数里） - 绝对不要用 JS 拼字符串后
document.write()或innerHTML注入——Google 抓取时通常不执行 JS，这类动态注入大概率丢失 - JSON 中所有 URL 必须是完整 HTTPS 地址，
"logo": "./logo.png"或"url": "/about"都会触发 “Invalid URL” 错误 - 如果页面有多个实体（如首页同时描述
WebSite和Organization），必须用数组包裹：[{ "@type": "WebSite", ... }, { "@type": "Organization", ... }]
怎么选对 @type 和必填字段
乱填 Article 或 WebPage 几乎没效果。关键看页面真实内容，且每个类型有硬性字段要求：
- 企业官网首页 → 用
Organization，至少含name、url、sameAs（或logo+image） - 产品详情页 → 用
Product，必须有name、offers（内含price和priceCurrency）、image - 博客文章页 → 用
BlogPosting，缺headline、datePublished、author（且author要是带@type的对象）就会被判定为不完整 - 查字段要求别翻文档——直接打开
https://schema.org/Product，右侧 “Properties” 列表中标 * 的就是强制项
最容易被忽略的是时间格式和 URL 完整性。哪怕 JSON 结构完全正确，datePublished 写成 "2026-06-22"（没时间）或 "Jun 22, 2026"（非 ISO 8601），Google Search Console 就标红报错；sameAs 数组里混进一个 http:// 开头的链接，整段标记也会被弃用。这些细节不校验，加了等于没加。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
