资讯文章文章 · ARTICLE

目录站的结构化数据怎么标：WebSite、ItemList、BreadcrumbList

2026-10-22 约 3,148 字预计阅读 8 分钟 yiyunkj

导航站的结构化数据，绝大多数站点是空的。不是不想做，是不知道怎么标——「我这一页就是一堆链接，标什么？」

实际上，目录站是结构化数据的天然受益者：你的页面本身就是「一组有序的条目」，这正是 ItemList 要描述的东西。

这篇文章只讲三种标记，按页面类型对应，不扯理论。

一、先明确：结构化数据不直接提排名

它做三件事：

让搜索结果出现富媒体样式（面包屑、站点链接、评分星标），提高点击率
帮助搜索引擎准确理解页面结构（尤其对目录这种链接密集的页面）
在 AI 搜索构建答案时，提高被正确引用的概率

所以别指望加完排名上升。它的收益在点击率和理解准确度上，是长期的、间接的。

二、首页：WebSite + SearchAction

这是目录站最值得做的一个标记，因为能争取「站内搜索框直达」。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "name": "站点名称",
  "url": "https://example.com/",
  "potentialAction": {
    "@type": "SearchAction",
    "target": {
      "@type": "EntryPoint",
      "urlTemplate": "https://example.com/search?q={search_term_string}"
    },
    "query-input": "required name=search_term_string"
  }
}
</script>

三个容易写错的地方：

urlTemplate 里的搜索地址必须是真实可用的（打开后能返回结果页），不能是占位符。
参数名要和实际一致。如果你的搜索是 ?keyword=，就写 keyword，别照抄 q。
搜索结果页本身要允许被抓取。如果它在 robots 里被屏蔽，这个标记就失效了。

三、分类页与列表页：ItemList

这是目录站的核心。一个分类下有 30 个条目，用 ItemList 标注它们的顺序和地址。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "ItemList",
  "name": "图片压缩工具",
  "itemListOrder": "https://schema.org/ItemListOrderDescending",
  "numberOfItems": 3,
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "工具名称 A",
      "url": "https://example.com/site/tool-a/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "工具名称 B",
      "url": "https://example.com/site/tool-b/"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "工具名称 C",
      "url": "https://example.com/site/tool-c/"
    }
  ]
}
</script>

注意事项：

position 必须连续从 1 开始，不能跳号。
url 指向详情页，不是外站。这一点很多人搞错——标注的是「你站内的条目页」，不是被收录的站。
numberOfItems 要和实际条目数一致，如果只标了前 20 个，就写 20，写 300 会报错。
只标当前页可见的条目。分页的第 2 页单独标自己的那批。

关于是否标注外站链接

有些目录想用 sameAs 或直接把外站 URL 写进 url。不建议。结构化数据描述的是「这个页面上的内容实体」，你的条目页是实体，外站只是它的一个属性。要表达外站地址，用详情页里的 relatedLink 或直接不标。

四、所有层级页面：BreadcrumbList

面包屑的收益非常直接——搜索结果里会显示「首页 > 站长工具 > SEO 工具」这样的路径，比一个裸 URL 的点击率高很多。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {"@type":"ListItem","position":1,"name":"首页","item":"https://example.com/"},
    {"@type":"ListItem","position":2,"name":"站长工具","item":"https://example.com/wm/"},
    {"@type":"ListItem","position":3,"name":"SEO 工具","item":"https://example.com/wm-seo/"}
  ]
}
</script>

三个必须对齐的点：

标记里的层级 = 页面上可见的面包屑 = URL 层级，三者不一致是最常见的错误。
最后一项不要带 item（它就是当前页），但有些实现要求带，按搜索引擎的最新文档来。
分类有多级父子关系时，面包屑要把完整路径列出来，不要只写上一级。

五、详情页可以加什么

按条目类型选，不要硬套：

条目类型	推荐类型	能填的字段
软件/工具	`SoftwareApplication`	name、applicationCategory、operatingSystem、offers（价格）
企业/服务商	`Organization` 或 `LocalBusiness`	name、address、telephone、areaServed
文章/资讯	`Article`	headline、datePublished、dateModified、author
网站条目	`WebSite`	name、url、description

只填你能确认的字段。aggregateRating（评分）是高风险项——如果没有真实用户评分体系，不要编造。伪造评分一旦被发现，会失去所有富媒体展示资格。

六、四个高频错误

1. 用 JS 动态注入但页面源码里没有

很多前端框架把 JSON-LD 放在组件里，通过 JS 插入。搜索引擎虽然能执行 JS，但渲染是有成本和延迟的。最稳的做法是服务端直接输出在 HTML 里。

2. 一个页面标了多个冲突的 ItemList

有的站既有「热门推荐」又有「本页条目」，两个都标成 ItemList，导致 position 冲突。要么只标主列表，要么给每个 ItemList 加不同的 name 区分。

3. 标记内容和页面可见内容不一致

标记里有 30 个条目，页面上只显示 15 个（其余靠滚动加载）。这属于「隐藏内容」，会被判定为欺骗。只标可见的。

4. 用了已废弃的类型

BreadcrumbList 的写法、SearchAction 的支持范围，各家搜索引擎的文档都在变。每隔半年对照官方文档核对一次，不要照抄五年前的教程。

七、验证与监控

做完必须验证，不能只看代码对不对：

用富媒体搜索结果测试工具跑一遍，看有没有「严重错误」
看「可以增强」的提示，那些是可选项，按需补
上线后 2-4 周，在 Search Console 的「增强功能」报告里看实际生效情况
如果项数骤降，说明模板改坏了，回滚

八、优先级建议

如果只能做三个，按这个顺序：

BreadcrumbList——收益最直接，实现最简单，所有层级页面都加
WebSite + SearchAction——只在首页加，成本极低
ItemList——分类页和列表页加，目录站的核心标记

详情页的类型标记放在最后，因为它的字段最多、最容易出错，收益也没有前三个明显。先把基础的三个做对，比一次性全铺开却到处都是错误要好得多。