结构化数据（JSON-LD）怎么写
搜索引擎和 AI 靠它确认「你是谁、在哪、提供什么」。写对了不费力，写错了会误导。
三类标记，最小可用写法
只保留必要字段，字段越少越不容易写错。
Organization放：首页
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "你的公司名",
"url": "https://你的域名/",
"logo": "https://你的域名/images/logo.webp"
}用途：让抓取方确认站点归属主体。
LocalBusiness放：关于 / 到店页
{
"@context": "https://schema.org",
"@type": "LocalBusiness",
"name": "你的店名",
"address": "完整门牌地址",
"telephone": "+86手机号",
"openingHours": "08:00-22:30"
}用途：确认实体商家存在。地址电话必须和页面正文一致。
FAQPage放：有问答的页面
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [{
"@type": "Question",
"name": "页面上显示的原问题",
"acceptedAnswer": { "@type": "Answer", "text": "与页面一致的答案" }
}]
}用途：问答同步。答案文字必须和页面显示的一字不差，两套说法会互相抵消。
一、先写三类，就够用了
- Organization：放在首页，声明站点所属主体、名称、logo、联系方式。
- LocalBusiness：有实体地址的商家放在关于或到店页，声明地址、电话、营业时间、地理坐标。
- FAQPage：页面上有问答模块时使用，把问答同步成结构化数据。
二、写在哪儿
用 application/ld+json 的 script 标签写在页面的 head 或 body 末尾均可。一个页面可以放多个对象，用数组包裹。不要写在 robots 或通过脚本异步注入——抓取时可能读不到。
三、关键原则：与页面正文一致
结构化数据里的信息必须能在页面正文里找到对应内容。页面正文没写的营业时间，不要在结构化数据里编一个——这属于误导性标记，可能被判定为违规。
四、常见错误
- 把 Organization 和 LocalBusiness 里的地址、电话写成不同的值。
- FAQPage 里的答案与页面显示的文字不一致。
- 地址只写「湖南益阳」，缺少可核验的详细地址与邮编。
- 在多个页面重复投放同一套 LocalBusiness 且内容冲突。
五、怎么验证
用搜索引擎官方提供的结构化数据测试工具检查，重点看两项：语法是否合法、必填字段是否齐全。校验通过后再上线。
延伸阅读
写结构化数据，这几种错最常见
不是加上就有效，写错同样没用，甚至会被忽略。
- 标了与实际页面不符的类型（页面是文章却标成产品）
- 同一页面重复输出多份互相矛盾的 JSON-LD
- 把没有的信息编进去（如虚构评分、虚构地址）
- 只写 organization 不写本地信息，本地站点因此少了地域信号
- 写了但没验证：改完不看结构化数据校验工具的结果
- 字段用中文键名或自定义键名，机器读不出来
判断标准只有一条：页面上能看到的事实，才能写进结构化数据；看不到的不要编。
帮你把结构化数据写对
留下联系方式，我先看你现在的站（或你的需求），告诉你能改什么、大概多少钱，不推销。
