多语言网站经常会遇到一个问题：中文页面使用北京时间，英文页面面向美国用户，那么结构化数据中的发布日期、更新时间和活动时间，是否也要跟着语言版本调整？

判断标准不是页面使用中文还是英文，而是结构化数据描述的是“同一个时间点”，还是“不同地区各自发生的时间”。语言、国家和时区是三个不同概念，不能简单地根据hreflang值直接增加或减少几个小时。

不同语言网站如何设置结构化数据中的日期和时区

先看时间代表什么

结构化数据中的时间大致可以分为两类。

  • 绝对时间：文章发布、页面更新、直播开始、订单截止等实际发生的时间点。

  • 当地时间：门店营业时间、当地活动时间、线下服务时间等与具体地点绑定的时间。

绝对时间可以换算为不同时区，但换算后仍然是同一时刻。当地时间则应以实际地点为准，不能因为页面翻译成另一种语言，就改成访问者所在地区的时间。

例如，北京时间2026年7月28日20点，与纽约夏令时2026年7月28日8点，以及UTC时间2026年7月28日12点，表示的是同一个时刻：

2026-07-28T20:00:00+08:00
2026-07-28T08:00:00-04:00
2026-07-28T12:00:00Z

这三种写法都可以使用，但同一页面内应保持统一，避免正文显示一个时间，结构化数据又表示另一个时间。

语言不决定时区

hreflang中的语言和地区代码用于说明页面面向哪些语言或区域用户，不负责定义页面的时区。

例如，以下页面可能分别面向不同用户：

  • zh-CN：简体中文页面。

  • en-US：面向美国用户的英文页面。

  • en-GB：面向英国用户的英文页面。

这些页面可以使用不同的可见日期格式，但不代表结构化数据必须填写三个不同的实际发布时间。

中文页面可以显示“2026年7月28日”，美国页面可以显示“July 28, 2026”，英国页面可以显示“28 July 2026”。文字格式已经本地化，但底层时间仍可以指向同一发布时间。

文章时间怎么处理

Article、NewsArticle和BlogPosting中常见的时间属性包括：

  • datePublished：文章首次发布的日期和时间。

  • dateModified：文章最近一次有实质内容修改的日期和时间。

Google建议这些属性使用ISO 8601格式，并尽量提供准确的时区。如果不提供时区，搜索引擎可能按照抓取程序使用的时区解释时间，容易造成日期偏差。

较完整的写法如下：

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "多语言网站结构化数据设置方法",
  "inLanguage": "zh-CN",
  "datePublished": "2026-07-28T20:00:00+08:00",
  "dateModified": "2026-07-29T10:30:00+08:00"
}

也可以统一保存为UTC：

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Structured Data for Multilingual Websites",
  "inLanguage": "en-US",
  "datePublished": "2026-07-28T12:00:00Z",
  "dateModified": "2026-07-29T02:30:00Z"
}

以上两个示例中的发布时间和修改时间分别表示同一时刻，只是时区表达方式不同。

同步发布保持一致

如果中文、英文和日文版本同时上线，它们的datePublished应表示同一个发布时间。可以全部使用UTC，也可以分别使用页面面向地区的时区，但换算后必须是同一时刻。

实际项目中，更推荐所有语言版本的JSON-LD统一使用UTC：

"datePublished": "2026-07-28T12:00:00Z"

页面上向用户展示日期时，再根据站点语言和业务设置转换格式。这样可以避免模板之间出现固定加八小时、减五小时等混乱逻辑。

如果各页面使用当地时区，也要保证时间能够正确换算：

中文页面：
"datePublished": "2026-07-28T20:00:00+08:00"

美国页面：
"datePublished": "2026-07-28T08:00:00-04:00"

不能只替换时区标识，却不改变小时数。例如将20点后的“+08:00”直接改成“-04:00”，会把发布时间向后推迟12小时，已经不再是同一时刻。

延迟翻译单独记录

多语言页面不一定同时上线。中文原文可能在7月28日发布，英文翻译在8月3日才正式公开。这种情况下，不建议为了让所有语言版本看起来一致，机械复制原文的发布时间。

更合理的处理方式取决于页面如何向用户说明日期。

如果英文页面把自己视为8月3日新发布的翻译页面，可以设置：

"datePublished": "2026-08-03T09:00:00Z"

如果页面明确显示原文发布日期，并将翻译上线视为一次更新，也可以保留原始datePublished，同时把翻译上线或后续修改时间写入dateModified。

"datePublished": "2026-07-28T12:00:00Z",
"dateModified": "2026-08-03T09:00:00Z"

两种处理方式没有必要强行统一，重点是结构化数据要与页面中用户能够看到的日期含义一致。不要让页面显示8月3日发布，而JSON-LD却无说明地标记为7月28日。

跨越零点很正常

同一时刻转换到不同时区后，可能出现不同日期。此时不同语言或地区页面显示不同日期并不一定是错误。

例如某篇文章在北京时间7月29日凌晨1点发布：

北京时间：2026-07-29T01:00:00+08:00
伦敦夏令时：2026-07-28T18:00:00+01:00
UTC时间：2026-07-28T17:00:00Z

中文页面显示7月29日，英国页面显示7月28日，仍然可以表示同一时刻。不能为了让所有页面日期相同，而故意改变实际发布时间。

如果网站只显示年月日而不显示具体时间，需要特别留意这种跨日情况。Google允许可见页面只展示日期，但结构化数据仍可以提供更精确的时间和时区。

活动时间按地点设置

Event结构化数据中的startDate和endDate应以活动实际发生地的时间为基础，并带上正确的UTC偏移。

例如活动在纽约当地时间2026年11月5日晚上7点开始，应填写纽约当时适用的时区偏移，而不是根据页面语言转换成北京时间：

{
  "@context": "https://schema.org",
  "@type": "Event",
  "name": "New York Marketing Conference",
  "startDate": "2026-11-05T19:00:00-05:00",
  "endDate": "2026-11-05T22:00:00-05:00"
}

中文页面、英文页面和西班牙语页面都可以使用相同的活动时间。页面正文可以附加北京时间换算，方便中国用户理解，但Event中的核心时间应准确描述活动发生时间。

如果同一场线上活动针对多个地区分别举办，例如亚洲场、欧洲场和美洲场，那么它们属于不同场次，应分别创建Event对象，而不是只通过翻译页面改变时间。

营业时间不能换算

LocalBusiness中的openingHoursSpecification表示门店所在地的营业时间。它通常填写当地钟表时间，不应根据网站访问者所在国家进行换算。

例如东京门店每天上午10点营业，无论页面是中文、英文还是日文，都应保持：

"openingHoursSpecification": {
  "@type": "OpeningHoursSpecification",
  "dayOfWeek": [
    "Monday",
    "Tuesday",
    "Wednesday",
    "Thursday",
    "Friday"
  ],
  "opens": "10:00",
  "closes": "20:00"
}

如果美国站和日本站对应的是两家不同门店，则应为每个门店分别输出LocalBusiness数据，并填写各自地址、电话和当地营业时间。

不能因为英文页面面向美国用户，就把东京门店的10点换算成美国前一天晚上的时间。openingHoursSpecification描述的是门店门口时钟所显示的营业时间。

夏令时需要动态处理

美国、加拿大、英国和部分欧洲国家会使用夏令时。同一个地区在一年中可能分别使用不同的UTC偏移。

以纽约为例：

  • 冬季标准时间通常使用-05:00。

  • 夏季夏令时间通常使用-04:00。

如果活动发生在夏季，却一直固定输出-05:00，结构化数据会偏差一小时。因此，不能只在模板中为某个国家写死一个偏移值。

较稳妥的做法是在后台保存以下信息：

  • 原始UTC时间。

  • 活动或业务所在地的IANA时区，例如America/New_York。

  • 页面展示所需的语言和日期格式。

生成JSON-LD时，由程序根据具体日期计算当时正确的UTC偏移。这样能够自动处理夏令时开始和结束。

仅有日期无需换算

部分结构化数据属性只需要Date，而不是DateTime。例如某些有效期、发布日期或季节性营业日期只填写：

2026-12-25

这种值表示一个日历日期，没有小时、分钟和时区。没有具体时刻时，不要自行补充午夜时间：

不建议无依据改成：
2026-12-25T00:00:00Z

增加午夜时间后，转换到其他时区可能变成前一天，从而改变原本的日期含义。属性允许使用Date时，只掌握日期就使用YYYY-MM-DD即可。

页面时间保持一致

Google会综合页面可见日期和结构化数据判断发布时间。为了减少误判，以下位置的日期含义应保持一致：

  • 文章标题附近的可见发布日期。

  • Article中的datePublished和dateModified。

  • HTML中的time元素。

  • Open Graph或其他页面元数据。

  • XML站点地图中的lastmod。

  • 页面内容中的更新说明。

这里的“一致”不是要求字符串完全相同，而是要求它们表达相同事实。中文页面可以使用中文日期格式，JSON-LD使用ISO 8601，只要代表相同日期或时间即可。

站点地图中的lastmod表示页面最后一次重要修改时间，不应因为模板更新时间、统计代码变化或每日构建而不断刷新。

推荐的处理流程

多语言站点可以采用以下方式管理时间：

  1. 数据库统一保存UTC时间，避免不同语言模板分别计算原始时间。

  2. 同时保存事件或门店对应的实际时区，而不是只保存固定偏移。

  3. JSON-LD优先输出ISO 8601，并明确添加Z或UTC偏移。

  4. 页面可见日期根据语言和地区进行格式化。

  5. 同步发布的翻译页面使用同一时间点。

  6. 延迟发布的翻译页面按照真实上线情况记录。

  7. 活动时间以活动地点为准，营业时间以门店所在地为准。

  8. 上线前使用结构化数据测试工具检查字段和格式。

例如后台可以统一保存：

published_at_utc = 2026-07-28T12:00:00Z

中文页面显示：

2026年7月28日 20:00

美国页面显示：

July 28, 2026, 8:00 AM

两个页面的JSON-LD都可以直接使用原始UTC值，从而减少重复换算和时区错误。

常见设置错误

多语言结构化数据中较常见的问题包括：

  • 根据hreflang机械增加或减少固定小时数。

  • 修改时区后没有同步修改具体时间。

  • 所有美国页面全年固定使用-05:00，忽略夏令时。

  • 把活动时间转换成页面语言所在国家的时间。

  • 把海外门店营业时间转换成网站服务器时间。

  • 页面可见日期与datePublished含义不一致。

  • 只有日期时强行补充00:00:00。

  • 翻译页面尚未上线，却提前填写未来发布时间。

  • 模板改动后自动更新所有页面的dateModified。

判断是否需要调整结构化数据时间，可以归结为一个原则：语言版本只改变表达方式，时区决定时间如何显示，业务事实决定时间本身是什么。只要先确定结构化数据描述的真实事件，再选择带时区的ISO 8601格式，多语言页面之间通常不需要人为制造不同时间。

参考资料

  1. Google文章结构化数据说明

  2. Google网页发布日期设置指南

  3. Google活动结构化数据时间规范

  4. Google本地商家结构化数据说明

  5. Google多语言页面hreflang指南

  6. Schema.org DateTime数据类型