电子商务的本地化架构标记旨在使您的结构化数据说出客户和搜索引擎的语言。对于国际在线商店，尤其是针对欧盟，东南亚或中东等不同地区的人，模式本地化是帮助搜索引擎根据用户语言，区域和货币提供正确的富摘要的关键。
通过本地化关键模式类型，例如产品信息，定价和业务详细信息，您可以在不同市场中提高可见性，信任和转换率。本文探讨了要避免的本地化的架构元素，以及最佳实践，以帮助您的国际电子商务网站表现最好。
模式本地化对您的电子商务的重要性
模式本地化可确保您的结构化数据与您所服务的每个市场的语言，货币和文化背景保持一致。这可以提高您在本地搜索结果中的可见性，并增强不同地区的用户体验。
- 提高本地SEO性能 -当架构标记使用本地语言，货币和特定区域字段时，搜索引擎可以更好地理解和匹配您的内容与本地搜索意图。
- 启用准确的丰富片段 -价格，产品可用性和评论等丰富的片段将反映用户的本地环境，建立信任并提高点击率。
- 改进多语言用户体验 -本地化架构有助于确保可见的页面内容与其背后的结构化数据之间的一致性，从而避免对国际访问者感到困惑。
- 支持区域合规性和期望 -不同地区可能具有特定的数据要求（例如欧盟中的增值税或东南亚的运输区），可以通过模式解决。
- 提高目标市场的转化率 -搜索预览中熟悉的语言，货币和联系信息的用户更有可能信任并与您的网站互动。
需要本地化的关键电子商务架构类型
架构标记是添加到网站HTML中的一种结构化数据，可帮助搜索引擎了解内容的上下文。对于电子商务，它为产品评级，价格，可用性等提供了丰富的结果，使您的列表在搜索中脱颖而出。当针对国际市场时，仅使用架构还不够，您还需要将其定位。
以下是需要仔细本地化以获得全球电子商务成功的关键模式类型。
产品
产品模式提供了结构化信息，例如产品名称，描述，SKU，品牌，图像和评论。在本地设置该模式时，必须准确地翻译产品名称和描述，而不仅仅是单词词，而是与每个市场的文化和语言规范产生共鸣的方式。
必须将几个关键要素适应每个目标市场，以正确地本地定位产品模式。这些要素超出了基本的翻译 - 文化适应，遵守当地期望以及与特定语言的SEO保持一致。这是应该本地化的产品架构的关键方面。
- 名称：翻译产品名称以保留本地语言的意义和吸引力。避免字面翻译可能会混淆或误导当地受众。
- 描述：对语调，测量单元（例如，英寸，厘米）和区域受众熟悉的术语的定位描述。
- 图像：虽然不是基于文本的局部图像可以反映文化偏好。例如，中东市场的服装图像可能需要更适度的视觉效果。
- 品牌：如果该品牌在不同地区具有不同的名称，或者在本地更容易识别子品牌，请确保品牌领域反映这一点。
- SKU：尽管在全球范围内通常是一致的，但是如果您使用区域产品代码或标识符，请更新SKU以匹配本地目录。
- 审查和汇总：这些要素也可以从本地化中受益。如果架构中包含客户评论，请确保用当地语言编写它们并反映特定地区的客户反馈。
- 优惠（嵌入产品中）：这包括定价和可用性，这些定价和可用性应反映当地货币，格式和股票水平。还要考虑将PriceValiduntil调整为当地销售周期。
例如，英语中的“冬衣 - 北极系列”产品可能被定位为西班牙语中的“ Chaqueta invernal - Serie Altica”。在阿拉伯市场中，不仅需要将名称和描述翻译成阿拉伯语，而且您可能还需要适应图像并将重点介绍为被认为具有吸引力或谦虚的内容。
无法本地化产品模式可以在搜索片段中显示的内容与实际产品页面上的内容之间造成不匹配，损害信任和损害点击率。通过为每个区域定制产品模式，您可以确保一致性，更好的SEO对齐方式以及更平滑的购物体验。
{
"@context": "https://schema.org/",
"@type": "Product",
"name": "Chaqueta Invernal – Serie Ártica",
"description": "Una chaqueta cálida ideal para el invierno, con capucha desmontable y bolsillos amplios.",
"sku": "ARCTIC-ES",
"image": "https://example.com/es/images/arctic-coat.jpg",
"brand": {
"@type": "Brand",
"name": "FrostWear"
}
}
这是搜索产品时在线出现的产品架构标记的示例。
定价和货币
定价是在线购物者最敏感的信息之一。优惠模式通常嵌入了产品模式中，包括价格，价格和可用性等关键字段。本地化货币和定价至关重要，尤其是当您的网站针对不使用美元，欧元或其他标准违约的区域时。
例如，如果您在中东出售，则您的模式应使用适当的ISO 4217货币代码（例如“ PriceCurrency”）以AED或SAR的价格反映出价格：“ AED”。此外，价格格式应遵循区域惯例 - 一些国家使用逗号而不是时期作为小数分离器，或将货币符号放在金额之后而不是之前。
模式标记中的错误或通用货币代码可能会导致误导性的片段，困惑的购物者，甚至搜索引擎罚款，以确保数据不一致。您的架构应与用户在前端看到的内容同步，并反映实时转换率或局部定价策略。通过语言或区域子域调整此模式对于确保在多语言网站上进行准确表示至关重要。定价模式中必须本地化的关键要素。
- 价格：用于本地地区格式的数值价值（例如，99,99而不是99.99）。
- PriceCurrency：使用正确的ISO 4217货币代码（例如AED，SAR，JPY等）。
- 货币符号放置：适应本地惯例（例如，“ 99部分”而不是“ SAR 99”）。
- 可用性：如果适用，请使用本地语言或标签（例如，“库存”→西班牙语中的“可配件”）。
这是针对中东市场定制定价的本地架构的示例。
{
"@context": "https://schema.org/",
"@type": "Offer",
"price": "89.99",
"priceCurrency": "EUR",
"availability": "https://schema.org/InStock",
"priceValidUntil": "2025-12-31",
"itemCondition": "https://schema.org/NewCondition",
"url": "https://example.com/es/productos/chaqueta-artica"
}
这是搜索产品时在线出现的定价和货币架构标记的示例。
业务与联系信息
组织和联系点模式定义您的业务身份以及客户如何与您联系。这里的本地化不仅涉及翻译，还需要调整营业时间，支持语言和联系方式以适应本地期望。
本地化业务并联系模式，您可以提高信任并帮助搜索引擎在SERP中显示准确的联系方式（尤其是在移动设备上）。这也有助于语音搜索和智能助手根据位置提供正确的业务响应。一个稳定的架构可确保客户在正确的时间看到正确的联系选项，并与他们的语言，区域和首选的通信方法保持一致。
组织本地化的组织和联系点模式的关键要素包括。
- 名称：如果您在不同地区使用本地品牌标识，则翻译或调整业务名称。
- ConternationPe：使用本地术语进行支持类型（例如，西班牙语中的“ Servicio al Cliente”）。
- 电话：以适当的国际格式包括当地支持号码。
- 区域：使用ISO代码指定目标区域，以确保地理 - 重点。
- 可用语言：指出您的支持团队可以处理哪种语言（例如，英语，阿拉伯语，法语）。
- 联系人：添加特定区域的联系方法，例如WhatsApp，微信或本地聊天工具。
- URL：将用户指向本地化帮助或联系页面（如果有）。
通过为每个目标区域定制每个字段，您的模式将满足本地期望，并增加相关搜索结果中的特色机会，尤其是那些依靠移动或语音交互的结果。以下是应用模式的示例。
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "YourBusiness",
"url": "https://www.yourbusiness.com",
"contactPoint": {
"@type": "ContactPoint",
"telephone": "+33-1-23-45-67-89",
"contactType": "customer support",
"areaServed": "FR",
"availableLanguage": ["en", "fr"]
}
}
运输和交货详细信息
交付期望和规则因国家 /地区而异。通过使用诸如交货时间，运输时间或特定区域特定区域的供应详细信息之类的架构类型，您不仅可以通信可用性和估计的交货时间，还可以为每个市场提供本地化的区域，运输费用和处理时间。需要本地化的运输模式元素包括。
- 运输：地区或国家 /地区。
- 交货时间：估计以本地格式的交货时间（例如，2天与5-7个工作日）。
- 运输速度：当地货币运输费率。
- Transittimelabel：用于描述交货时间的标签（例如“表达”，“常规”或“在24小时内交付”）。
- 处理时间：交货前的处理时间。
例如，德国的客户可能期望在3个工作日内交货，而在印度尼西亚，典型的估计可能是5-7天。如果运输计划未本地化，则用户可能在搜索结果中无法获得相关信息，从而使他们不愿购买。这是为德国市场本地化的供应详细信息的一个示例。
{
"@context": "https://schema.org",
"@type": "OfferShippingDetails",
"shippingDestination": {
"@type": "DefinedRegion",
"name": "Germany"
},
"deliveryTime": {
"@type": "ShippingDeliveryTime",
"handlingTime": {
"@type": "QuantitativeValue",
"minValue": 1,
"maxValue": 2,
"unitCode": "d"
},
"shippingRate": {
"@type": "MonetaryAmount",
"value": "5.00",
"currency": "EUR"
}
}
存储位置和本地业务信息
准确地在Google搜索或Google Maps中显示商店位置在很大程度上取决于稳定的本地商标模式。尤其是当用户以本地语言或区域搜索时，拥有正确的信息会提高可见度并建立信任。需要本地化的本地性格架构中的关键要素包括。
- 名称：如果与当地上下文相关，则将翻译业务名称。
- 地址：根据当地公约格式化的地址，包括地址范围内，地址区域，邮政编码和地址country。
- 电话：使用正确的国家代码和本地格式的电话号码。
- 开头指定：操作时间已调整为当地时区和业务习惯。
- 地理：商店位置的地理坐标（纬度和经度）。
- 地区：业务服务的地区或地区。
例如，这是在德国柏林经营的商店的模式片段。
{
"@context": "https://schema.org",
"@type": "LocalBusiness",
"name": "Modehaus Berlin",
"address": {
"@type": "PostalAddress",
"addressLocality": "Berlin",
"addressCountry": "DE"
},
"telephone": "+49 30 12345678",
"openingHours": "Mo-Fr 10:00-19:00"
}
以下是本地业务标记方案的示例。
面包屑导航
面包屑模式有助于定义您网站的导航结构，向用户（和搜索引擎）显示网站层次结构中的位置。尽管这似乎很简单，但在多语言电子商务网站中，本地化面包库至关重要，以确保一致性，提高SEO并增强用户体验。
例如，英语，西班牙语和阿拉伯语的面包屑
- “家>男人时尚>夹克”
- “ Inicio> Moda Masculina> Chaquetas”，
- ““الر”，>أزأزressive>أزأز援Cءء还有>الرجال>الم计”。
假设页面内容用另一种语言时，则将面包板模式留在英语中。在这种情况下，用户可能会感到困惑，搜索引擎可能难以正确地为本地化内容索引。它也可能损害您的内部链接策略，因为面包屑会影响链接权益如何流入您的网站。
需要本地化的面包屑模式中的关键要素。
- itemListelement.name：必须翻译每个面包屑级别的可见名称。
- itemListelement.Item： URL应指向每个页面的正确本地化版本。
- 位置：反映面包板小径中的水平（通常保持不变，但必须与局部结构相对应）。
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "Inicio",
"item": "https://example.com/es/"
},
{
"@type": "ListItem",
"position": 2,
"name": "Moda Masculina",
"item": "https://example.com/es/moda-masculina"
},
{
"@type": "ListItem",
"position": 3,
"name": "Chaquetas",
"item": "https://example.com/es/moda-masculina/chaquetas"
}
]
}
以下是面包屑标记方案的示例。
电子商务架构本地化的常见错误
在将电子商务网站定位架构标记时，企业通常会遇到关键但可避免的问题。许多人认为单独翻译就足够了，但是结构化数据必须完全适应每个地区的语言，货币和用户期望。这些疏忽会导致富裕的片段，搜索可见性不佳或用户混乱。
以下是模式本地化中一些最常见的错误，以及为什么避免它们会显着影响您网站的性能和用户体验。
仅使用一种语言或货币
电子商务架构本地化中最常见的失误之一是在整个网站的结构化数据中坚持使用一种语言或货币，即使是在翻译前端内容时。此不匹配使用户和搜索引擎混淆。法国的购物者可能会阅读法语的产品描述，但请参见架构仍然指美元而不是欧元，这可能会导致信任问题。
局部模式应反映翻译的内容和当地货币格式。例如，“ PriceCurrency”：“ EUR”应替换“ PriceCurrency”：在法语版本的网站上“ USD”，产品模式中的“名称”和“描述”字段应以法语出现。没有此，搜索引擎可能无法在搜索结果中准确显示您的本地化列表。
忽略语言和货币本地化会导致富裕的摘要预览，降低了点击率，甚至可能违反了结构化数据准确性的准则。Hreflang和特定于区域的子域或路径来定制每个语言和区域的模式
不正确更新货币代码
许多人忘记在架构标记中更新货币代码，即使商人在前端使用正确的本地货币符号。 Schema.org使用标准化的ISO 4217代码（例如美元的“美元”或日元的“ JPY”），并且未在“ PriceCurrency”中正确反映这些代码会导致破坏或误导性丰富的结果。
例如，如果您在阿联酋的商店在迪拉姆（Dirhams）中显示了价格，但仍使用“ PriceCurrency”：架构中的“ USD”，Google可能会误解产品价格，或者选择不显示它。更糟糕的是，由于货币环境不正确，客户可能会认为产品更便宜或更昂贵，导致跳出率或废弃的购物车。
始终在模式中仔细检查货币值，尤其是对于使用地理位置或货币切换器的多货币商店而言。对齐视觉和结构化货币信息可以改善搜索外观和客户信任。
跳过特定区域的模式字段
另一个错误是在不包含特定区域特定元素（例如“ SpieptDestatination”，“区域”或“可用的”）的情况下使用通用模式。这些领域对于传达物流和服务覆盖范围至关重要，尤其是在国际运输或本地化客户支持中。
例如，澳大利亚的购物者应根据本地标准查看运输时间估算和交货选项（例如，“ shippingdestination”：{“@type”：“定义区域”，“名称”：“澳大利亚”}）。省略此类详细信息可能会导致搜索引擎假设您没有运输在那里，从而影响当地搜索中的发现性。
此外，诸如“区域”和“可用的”等领域有助于您的业务“附近”或基于区域的搜索。如果您不在区域页面上使用这些模式字段，则很可能会错过本地化搜索机会。
忽略RTL语言支持
像阿拉伯语和希伯来语之类的语言从右到左（RTL）读取，并且未能调整模式标记以说明这一点可能会导致可读性和SEO问题。尽管架构没有在视觉上呈现，但它仍然必须反映语言上下文以匹配页面上的体验和搜索语言定位。
例如，阿拉伯语页面上产品模式中的“名称”和“描述”字段应使用正确的Unicode格式进行适当翻译和编码。此外，该页面本身应在HTML中使用lang =“ ar”和dir =“ rtl”，并且模式应匹配。
忽略RTL支持会导致视觉和结构化内容之间的不一致，可能会使用户感到困惑并影响丰富的结果资格。始终确保语言和阅读方向都反映在模式结构中。
缺少翻译的面包屑
面包屑充当导航辅助工具，并为内部连接和SEO做出了重大贡献。模式本地化的一个常见错误是将面包板模式保持原始语言，即使可见的导航路径被翻译。
例如，如果您的页面显示“ Inicio> Moda femenina> Vestidos”（西班牙语的“ Home>“女性时尚>连衣裙”），则您的面包屑架构应该准确地反映出来。使用“名称”：“家庭”而不是“ inicio”会产生断开连接，并可能对Google解释网站结构的方式产生负面影响。
每个面包屑级别（“名称”）都应定位，相应的“项目”应链接到局部URL。保持一切对齐，确保用户和爬行者的一致性，增强可见性和索引。
重复使用所有语言的同一模式
最具破坏性的错误是在所有语言中都使用一定大小的模式方法。重复相同的结构化数据，而无需调整内容，货币，语言和区域上下文会破坏本地化。
您网站的每个本地化版本都应具有反映本地内容和元数据的架构。例如，如果您有单独的英语和法语产品页面，则它们的产品模式应翻译为“名称”，“描述”，“ PriceCurrency”，甚至是特定于语言的URL。
忽略这种做法可能会导致搜索信号相互矛盾，片段质量差，甚至是为误导结构化数据而进行的手动操作。最佳实践是为每个语言子域或hreflang标记的版本维护单独的模式，以确保结构化数据与语言和所服务的区域相匹配。
用于本地电子商务的架构标记的最佳实践
模式标记在搜索引擎如何解释和显示您的内容中起着至关重要的作用。正确定位后，它会提高您在本地SERP中的可见性，提高点击率，并增强全球用户的购物体验。
这是每个全球电子商务业务应遵循的最佳实践，以充分利用本地化。
每页使用特定语言的模式
您网站的每个语言版本都应在该特定语言中包括模式标记。如果您使用子域或子文件夹（例如，example.com/en/ for English.com/de/用于德语），则每个人都应包含一个独特的语言 - 适当架构。
如果您的德语页面仍然使用英语模式，则Google可能很难理解该页面的本地上下文，并且用户可能会发现与他们的期望不一致的经验，例如如下。
国家 | 模式字段 | 本地值 |
/fr/product-page | “姓名” | “ veste d'Hiver Pour Homme” |
“描述” | “ une veste chaude pour l'hiverfrançais” | |
“语言” | “ fr” |
本地化产品名称和描述
产品名称和描述不应仅仅翻译和文化化。在一个国家中听起来有吸引力的短语可能不会引起另一个国家的共鸣。使用自然语言向当地观众使用自然语言，并与他们的购物行为保持一致。
依靠本地翻译人员或本地专家避免尴尬的措辞或不清楚的消息传递。您的模式中的名称，描述和品牌之类的字段应反映本地语言和偏好。
语言 | 姓名 | 描述 |
英语 | “男士时尚夹克” | “时尚的夹克非常适合冬天” |
日本人 | “メンズウィンタージャケット” | “冬に最适なおしゃれなジャケットです。” |
设定准确的价格和货币
价格是电子商务中敏感的话题。不要只是在您的网站上视觉上转换货币，也可以确保使用PriceCurrency字段中的ISO 4217代码准确地反映正确的货币。价格也应根据当地惯例进行格式，包括小数和千分离员。
避免在所有语言版本中仅显示美元，因为这可能会使用户感到困惑或侵蚀信任。如果您使用实时货币转换，请确保您的模式保持同步。例如。
国家 | 价格 | 票价 | 本地 格式 |
日本 | 4500 | JPY | ¥4,500 |
沙特阿拉伯 | 180 | sar | 180 |
本地化业务信息
业务联系信息，例如地址，电话号码和营业时间，必须按地区定位。使用本地格式，例如地址倾向性，邮政编码和地址country等字段。在电话号码中包括国际拨号代码，以使用户更容易与您联系。
诸如开放量规定的领域应反映当地时区和业务实践。这些详细信息有助于建立信任并改善业务在本地搜索结果中的外观。例如。
国家 | 地址局限性 | 邮政编码 | 开放hoursformat |
西班牙 | 巴塞罗那 | 08001 | mo-fr 09：00–18：00 |
泰国 | 清迈 | 50000 | mo-sa 10：00–19：00 |
RTL语言的结构模式
像阿拉伯语和希伯来语这样的语言是从右到左（RTL）写的。尽管JSON-LD本身并不依赖于视觉格式，但任何包含可见文本（例如名称，描述或面包屑）的模式字段必须反映正确的语言和方向，以避免内容和标记之间的矛盾。
如果您的页面使用阿拉伯语，但该架构仍然包含英语值或从左到右的内容，则可能会给用户和搜索引擎带来混乱。始终确保HTML包含lang =“ ar”，并且结构化数据字段已相应地定位。
场地 | 非定位（LTR/英语） | 本地化（RTL/阿拉伯语） |
姓名 | 冬季外套 | شطفو |
描述 | 冬天的温暖外套 | 假طف极， |
面包屑 | 首页>衣服>夹克 | 考虑 |
用 Linguise自动架构本地化
在管理数百个动态产品页面时，手动跨多种语言手动定位架构标记可能很复杂。必须翻译可见的内容和结构化数据，包括产品，优惠，面包屑和本地商店模式。丰富的摘要可能不会反映每个区域的正确语言，货币或结构，而无需适当的本地化。
Linguise提供了一种自动翻译解决方案，该解决方案扩展到结构化数据，将模式标记和您的内容转换。通过其实时编辑器，您可以手动微调架构内容，例如产品名称，描述或品牌价值，以确保它们准确地反映本地环境。当定位需要文化细微差别的产品架构字段和区域SEO适应关键字的产品时，这一点尤其有用。
此外， Linguise 支持链接和媒体的翻译，从而实现了面包屑URL，内部链接甚至图像参考的本地化。这样可以确保所有元素，导航路径，资产和结构化数据都与正确的语言版本保持一致，从而帮助搜索引擎为全球用户提供更准确和相关的富裕结果。
