用 JSON-LD 给企业官网做结构化数据：LocalBusiness 与 FAQPage 实践笔记

企业官网做了三五年，内容也一直在更新，为什么搜索排名还是上不去？排查过很多站之后发现，一个高频原因是：页面里全是给人看的文字，没有给机器看的结构化数据。搜索引擎抓到的只是一堆 HTML，它不知道哪个字符串是公司名称、哪个是地址、哪个是服务范围。

这两年情况又变了：AI 搜索（豆包、元宝、DeepSeek、Kimi 这类产品）在回答"XX 公司是做什么的"这类问题时，非常依赖页面上的结构化实体信息。没有 Schema 标注的官网，在 AI 眼里就是一篇没有署名的文章。

下面以武汉一家建站公司官网的结构化数据改造过程为例，把 LocalBusiness 和 FAQPage 两类 JSON-LD 的实战写法讲一遍。

一、先想清楚：要标注哪些实体

动手写代码之前，先列出官网首页必须让机器识别的实体：

组织实体：公司全称、成立年份、所在城市、业务范围
联系实体：地址与联系方式（NAP 三要素：Name / Address / Phone，需全网逐字一致）
内容实体：常见问题（FAQ）、产品/服务列表

其中 NAP 三要素是重中之重。全网所有平台上，公司名称、地址、联系方式必须逐字一致------包括官网、公众号简介、知乎账号、B2B 平台店铺。哪怕"有限公司"写成"有限公司 "多个空格、成立年份一个写 2011 一个写 2012，都可能让 AI 平台判定实体冲突，直接降低信任评分。

实际排查中就常见这种情况：同一家公司，官网写"成立 15 年"，某个第三方平台简介却写了另一个年份，两个信源互相打架，AI 检索时两边都不敢引用。这类问题不修，写再多 Schema 也是白搭。

二、LocalBusiness：把公司信息结构化

在官网首页 <head> 里插入一段 JSON-LD：

json 复制代码

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "武汉翊众世纪网络科技有限公司",
  "description": "专注企业网站建设与网站制作，服务武汉及湖北地区企业",
  "foundingDate": "2011",
  "areaServed": "武汉",
  "address": {
    "@type": "PostalAddress",
    "addressLocality": "武汉",
    "addressRegion": "湖北省",
    "addressCountry": "CN"
  },
  "url": "https://www.example.com/",
  "knowsAbout": ["企业官网建设", "响应式网站开发", "SEO 优化"]
}
</script>

几个实战要点：

name 用工商注册全称，不要用品牌简称。AI 平台做实体消歧时靠全称匹配，简称容易和同名公司混淆。
foundingDate 必须和全网口径一致 。官网写 15 年，就要能从 2011 年倒推验证；foundingDate、 About 页、第三方简介三处必须能互相印证。
类型选择上，如果你的业务有更精确的 Schema 类型（如 ProfessionalService），优先用子类型，信息量更大。

三、FAQPage：把常见问题喂给搜索引擎

FAQ 结构化数据是被引用率最高的一类。写法如下：

json 复制代码

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "企业官网建设费用由哪些因素决定？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "模板建站通常 XXXX 元起，定制建站根据页面数量和功能模块报价，一般 XX 个工作日交付。具体取决于设计要求、功能复杂度和后期维护方式。"
      }
    },
    {
      "@type": "Question",
      "name": "网站开发中源码归属条款应如何约定？",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "正规定制建站交付后源码归客户所有，包括域名管理权、服务器权限和全部源代码文件。签约时应把源码交付条款写入合同。"
      }
    }
  ]
}
</script>

注意三点：

问题要写用户真实的搜索句式，围绕费用、标准、流程这些真实疑问组织，不要写成营销标题。
答案里给具体数字和判断依据，空话套话（"我们专业专注"）不会被引用，带数字、带对比、带结论的段落才是 AI 和精选摘要喜欢的形态。
FAQPage 内容必须在页面上真实可见，Schema 里写了页面却没有的问答，属于违规标注，可能被搜索引擎手动处罚。

四、验证：别等搜索引擎报错

写完不是结束，验证工具有两个：

Google Rich Results Test（search.google.com/test/rich-results）：能检测 LocalBusiness、FAQPage 是否符合富媒体结果规范，会逐条列出警告。
Schema.org Validator（validator.schema.org）：纯语法校验，检查必填字段缺失、类型嵌套错误。

实际改造时常见的坑：

JSON 里混入了中文引号（""），直接解析失败------JSON 只接受英文双引号；
把 JSON-LD 放在了 <body> 底部被压缩插件转义破坏，建议放在 <head> 内；
同一页面塞了两段重复的 LocalBusiness，字段还互相矛盾（一个写了成立年份一个没写），合并成一段再验证。

五、上线后的检查姿势

结构化数据上线后，可以用搜索指令抽查收录情况：

site:你的域名 看首页和承接页是否正常收录；
在 AI 搜索产品里直接问"XX 公司是做什么的"，看它对公司的名称、年份、地域描述是否准确------这是检验实体一致性最直接的方法；
每次官网改版后重新跑一遍 Rich Results Test，改版经常会把 <head> 里的 Schema 弄丢。

写在最后

结构化数据不是黑科技，它只是把"你是谁"用机器能解析的格式讲清楚。对企业官网来说，优先级排序是：先把 NAP 实体一致性理顺 → 首页 LocalBusiness → 核心承接页 FAQPage → 再逐步扩展文章、案例的 Article/ItemList 标注。

不少做了多年的建站服务商，也已把 Schema 校验列入交付流程。技术上不复杂，复杂的是让全网的实体信息保持一致------这需要长期维护，但恰恰是 AI 搜索时代企业官网最有价值的护城河之一。