<time> 标签必须带合法 ISO 8601 格式的 datetime 属性才具备机器可读性,否则仅作普通文本显示;推荐使用 datetime="YYYY-MM-DD"(纯日期)或 datetime="YYYY-MM-DDTHH:MM:SS+08:00"(含时区)。
不加 datetime 属性的 <time> 标签对搜索引擎、屏幕阅读器和结构化数据提取基本无效,文章发布时间这类关键信息必须带合法 ISO 8601 值。
<time> 必须配 datetime 才算真正生效浏览器不会校验 datetime 内容,但 Google 搜索、RSS 解析器、JSON-LD 提取工具等都只认这个属性。没它,<time>2024年5月20日</time> 和普通 <span> 没区别——只是文本,不是时间。
datetime 是唯一被机器读取的字段;标签内文字纯属人类展示,可任意本地化(如“五月二十日”“昨天”)<time>2024-05-20</time>(无属性)→ 机器无法识别为日期,SEO 富摘要大概率丢失发布时间<time datetime="2024/05/20">2024年5月20日</time> → 格式非法,ISO 8601 不接受斜杠分隔,解析失败datetime 的合法格式有哪些,怎么选发布时间最常用的是带时区的完整时间戳,尤其当内容可能被全球用户或聚合工具消费时。仅日期够用,但加时分秒+时区能避免歧义。
datetime="2026-04-15" —— 简洁,语义明确,适合大多数中文站点datetime="2026-04-15T10:17:00+08:00" —— 注意 T 是分隔符,+08:00 表示东八区,不可省略datetime="2026-04-15T02:17:00Z" —— Z 表示零时区,比 +00:00 更通用datetime="2026-04-15 10:17"(缺 T)、datetime="2026/04/15"(斜杠)、datetime="今天"(口语化)→ 全部不被标准工具识别很多开发者把 <time> 当作“加个样式标签”,结果破坏了语义完整性。发布时间这类信息对 SEO 和可访问性敏感,细节错一点,机器就读不准。
立即学习“前端免费学习笔记(深入)”;
<time>:❌ <time datetime="2026-04-15">发布于:2026年4月15日</time> → “发布于:”会被当成时间一部分,语义污染发布于:<time datetime="2026-04-15">2026年4月15日</time>
datetime 值:服务端渲染时就该写死,否则爬虫首次抓取可能拿到空值或默认时间<meta> 或 JSON-LD 中的时间不一致:比如 <time datetime="2026-04-15"> 与 <meta property="article:published_time" content="2026-04-14"> 对不上,Google 可能拒用富摘要如果你的网站面向单一地区(比如只服务中国大陆用户),+08:00 是稳妥选择;但如果内容会被 RSS 聚合、被海外用户订阅,或者你用 Schema.org 标记,就必须显式声明时区。
datetime="2026-04-15T10:17:00")→ 解析器按本地时区解释,不同地区用户看到的“发布时间”可能差一天+08:00 明确表示北京时间 → 机器统一按东八区理解,不会漂移Z 表示 UTC → 适合后端统一存 UTC 时间,前端再转换显示,但要求前后端时间逻辑严格对齐datetime 却写 "2026-04-15T02:17Z"(即北京时间 10:17),但没标时区 → 机器可能误判为 UTC 时间,导致展示成 4 月 14 日最容易被忽略的其实是“语义边界”:只要 <time> 里包了非时间内容,它的机器可读性就打折。发布时间这种强结构化字段,宁可多套一层 <span> 做样式,也别让“更新于”“发布于”之类的字眼污染 datetime 的纯净性。