Локалізація розмітки schema для електронної комерції полягає у створенні структурованих даних, які відповідають мові ваших клієнтів та пошукових систем. Для міжнародних інтернет-магазинів, особливо тих, що працюють у різних регіонах, таких як ЄС, Південно-Східна Азія чи Близький Схід, локалізація schema є ключовим фактором у наданні пошуковим системам можливості надавати правильні розширені сниппети на основі мови користувача, регіону та валюти.
Локалізуючи ключові типи schema, такі як інформація про продукт, ціноутворення та бізнес-деталі, ви підвищуєте видимість, довіру та коефіцієнти конверсії на різних ринках. Ця стаття розглядає, які елементи schema потрібно локалізувати, яких помилок слід уникати та найкращі практики для забезпечення найкращої роботи вашого міжнародного сайту електронної комерції.
Важливість локалізації schema для вашої електронної комерції
Локалізація схеми гарантує, що ваші структуровані дані відповідають мові, валюті та культурному контексту кожного ринку, який ви обслуговуєте. Це покращує вашу видимість у результатах локального пошуку та покращує взаємодію з користувачами в різних регіонах.
- Підвищує локальну SEO продуктивність – Коли розмітка схеми використовує локалізовану мову, валюту та регіональні поля, пошукові системи можуть краще розуміти та зіставляти ваш контент із локальним пошуковим запитом.
- Дозволяє точні розширені сниппети – Розширені сниппети, такі як ціни, наявність продукту та відгуки, відображатимуть локальний контекст користувача, підвищуючи довіру та покращуючи клікабельність.
- Покращує мультилінгвальний користувацький досвід – Локалізована схема допомагає забезпечити узгодженість між видимим контентом сторінки та структурованими даними за нею, уникаючи плутанини для міжнародних відвідувачів.
- Підтримує регіональну відповідність та очікування – Різні регіони можуть мати специфічні вимоги до даних (наприклад, ПДВ у ЄС або зони доставки в Південно-Східній Азії), які можна вирішити за допомогою схеми.
- Збільшує коефіцієнти конверсії на цільових ринках – користувачі, які бачать знайому мову, валюту та контактну інформацію в попередніх переглядах пошуку, з більшою ймовірністю довірятимуть вашому сайту та взаємодіятимуть з ним.
Ключові типи схеми e-Commerce, які потребують локалізації
Розмітка схеми - це тип структурованих даних, доданих до HTML вашого веб-сайту, який допомагає пошуковим системам зрозуміти контекст вашого контенту. Для електронної комерції вона забезпечує багаті результати, такі як рейтинги продуктів, ціни, доступність та інше, що робить ваші списки помітними у пошуку. При націлюванні на міжнародні ринки простого використання схеми недостатньо, вам також потрібно локалізувати її.
Нижче наведено ключові типи схеми, які потребують ретельної локалізації для успіху глобальної електронної комерції.
Продукт
Схема продукту надає структуровану інформацію, таку як назва продукту, опис, SKU, бренд, зображення та відгуки. Під час локалізації цієї схеми важливо точно перекладати назви продуктів та описи, не просто слово в слово, а таким чином, щоб вони резонували з культурними та лінгвістичними нормами кожного ринку.
Кілька ключових елементів мають бути адаптовані до кожного цільового ринку для належної локалізації схеми продукту. Ці елементи виходять за межі простого перекладу — культурна адаптація, відповідність місцевим очікуванням та узгодження з мовно-специфічним SEO. Ось ключові аспекти схеми продукту, які слід локалізувати.
- назва: Перекладіть назву продукту, щоб зберегти сенс та привабливість у місцевій мові. Уникайте буквальних перекладів, які можуть заплутати або ввести в оману місцеву аудиторію.
- опис: Локалізуйте описи з урахуванням тону, одиниць вимірювання (наприклад, дюйми проти сантиметрів) та термінології, знайомої регіональній аудиторії.
- зображення: Хоча це не текст, локалізовані зображення можуть відображати культурні переваги. Наприклад, зображення одягу на Близькому Сході можуть вимагати більш скромних візуальних ефектів.
- бренд: Якщо бренд має різні назви в різних регіонах, або якщо суббренди більш впізнавані локально, переконайтеся, що поле бренду відображає це.
- артикул: Хоча часто використовується глобально, якщо ви використовуєте регіональні коди продуктів або ідентифікатори, оновіть артикул відповідно до локального каталогу.
- огляд та агрегований рейтинг: Ці елементи також можуть отримати користь від локалізації. Якщо відгуки клієнтів включено до схеми, переконайтеся, що вони написані місцевою мовою та відображають відгуки клієнтів, специфічні для регіону.
- пропозиції (вбудовані в Продукт): Це включає ціноутворення та доступність, які повинні відображати локальну валюту, формати та рівні запасів. Також розгляньте можливість адаптації priceValidUntil до локальних циклів продажу.
Наприклад, продукт «Зимове пальто – Арктична серія» англійською мовою може бути локалізований як «Chaqueta Invernal – Serie Ártica» іспанською. На арабських ринках не тільки назва та опис потрібно перекласти арабською, але й може знадобитися адаптувати зображення та підкреслити особливості, щоб вони виглядали привабливо або скромно.
Нелокалізація схеми продукту може створити невідповідність між тим, що показано у фрагменті пошуку, і тим, що є на фактичній сторінці продукту, що шкодить довірі та знижує коефіцієнт кліків. Налаштовуючи схему продукту для кожного регіону, ви забезпечуєте узгодженість, краще вирівнювання 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"
}
}
Ось приклад розмітки схеми продукту, яка відображається в Інтернеті під час пошуку продукту.
Ціноутворення та валюта
Ціноутворення є одним з найбільш чутливих елементів інформації для онлайн-покупців. Схема пропозиції, як правило, вбудована в схему продукту, включає ключові поля, такі як ціна, валюта ціни та доступність. Локалізація валюти та ціноутворення є надзвичайно важливою, особливо коли ваш сайт орієнтований на регіони, які не використовують USD, EUR або інші стандартні значення за замовчуванням.
Наприклад, якщо ви продаєте на Близькому Сході, ваша схема повинна відображати ціни в AED або SAR з використанням відповідного коду валюти ISO 4217, наприклад «priceCurrency»: «AED». Крім того, формат ціни повинен відповідати регіональним умовам — деякі країни використовують коми замість крапок як десяткові роздільники або розміщують символ валюти після суми замість перед нею.
Неправильні або загальні коди валют у розмітці схеми можуть призвести до оманливих розширених фрагментів, плутанини для покупців і навіть штрафів для пошукових систем за невідповідність даних. Ваша схема повинна синхронізуватися з тим, що користувачі бачать на інтерфейсі, та відображати коефіцієнти конверсії в режимі реального часу або локалізовані стратегії ціноутворення. Адаптація цієї схеми для кожної мови або регіонального піддомену є важливою для забезпечення точного представлення на вашому багатомовному веб-сайті. Ключові елементи схеми ціноутворення, які мають бути локалізовані.
- ціна: числове значення ціни, відформатоване для місцевого регіону (наприклад, 99,99 замість 99,99).
- Валюта ціни:
- Розміщення символу валюти: адаптуйте символ до місцевих умовностей (наприклад, «99 ر.س» замість «SAR 99»).
- доступність: Використовуйте локалізовану мову або мітки, якщо це можливо (наприклад, “В наявності” → “Disponible” в іспанській).
Ось приклад локалізованої схеми ціноутворення, адаптованої для Близькосхідного ринку.
{
"@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"
}
Ось приклад розмітки схеми ціни та валюти, що з'являється в мережі при пошуку товару.
Бізнес-інформація та контактна інформація
Схеми «Організація» та «Контактна точка» визначають ідентичність вашого бізнесу та те, як клієнти можуть з вами зв’язатися. Локалізація тут включає більше, ніж просто переклад — вона вимагає адаптації робочих годин, мов підтримки та способів зв’язку відповідно до місцевих очікувань.
Локалізуючи бізнес і схему контактів, ви підвищуєте довіру та допомагаєте пошуковим системам відображати точні контактні дані у SERPs (особливо на мобільних пристроях). Це також допомагає голосовому пошуку та інтелектуальним помічникам надавати коректні бізнес-відповіді на основі місцезнаходження. Добре локалізована схема забезпечує, що клієнти бачать потрібні контактні опції у потрібний час, узгоджені з їхньою мовою, регіоном та бажаними методами зв'язку.
Ключові елементи схем Організації та ContactPoint для локалізації включають.
- ім'я: Перекладіть або адаптуйте назву бізнесу, якщо ви використовуєте локальну брендову ідентичність у різних регіонах.
- типКонтакту: Використовуйте локалізовані терміни для типів підтримки (наприклад, “сервіс клієнтам” в іспанській).
- телефон: Включайте локальні номери підтримки з відповідними міжнародними форматами.
- обслуговуванаТериторія: Визначте цільовий регіон за допомогою кодів ISO, щоб забезпечити георелевантність.
- availableLanguage: Вкажіть, якими мовами може працювати ваша служба підтримки (наприклад, англійською, арабською, французькою).
- варіантКонтакту: Додайте регіонально-специфічні методи контакту, такі як WhatsApp, WeChat або локальні чат-інструменти.
- посилання: Перенаправляйте користувачів на локалізовані сторінки довідки або контакту, якщо вони доступні.
Адаптуючи кожне з цих полів для кожного цільового регіону, ваша схема відповідатиме місцевим очікуванням і збільшить шанси на відображення у відповідних результатах пошуку, особливо тих, що залежать від мобільної або голосової взаємодії. Нижче наведено приклад застосування схеми.
{
"@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"]
}
}
Деталі доставки
Очікування щодо доставки та правила суттєво відрізняються залежно від країни. Використовуючи типи схем, такі як DeliveryTimeSettings, ShippingDeliveryTime або OfferShippingDetails, які є специфічними для регіону, ви можете повідомити не лише про доступність та очікуваний час доставки, але й про регіони обслуговування, тарифи на доставку та час обробки - все це має бути локалізовано для кожного ринку. Елементи схеми доставки, які потрібно локалізувати, включають.
- shippingDestination: регіон або країна обслуговування.
- час доставки: очікуваний час доставки у локальному форматі (наприклад, 2 дні проти 5-7 робочих днів).
- shippingRate: вартість доставки в місцевій валюті.
- мітка часу доставки: мітка, що використовується для опису часу доставки (наприклад, “Експрес”, “Регулярний” або “Доставка протягом 24 годин”).
- час обробки: час обробки перед початком доставки.
Наприклад, клієнт із Німеччини може очікувати доставки протягом 3 робочих днів, тоді як в Індонезії типова оцінка може становити 5-7 днів. Якщо схема доставки не локалізована, користувачі можуть не отримувати відповідну інформацію у результатах пошуку, що робить їх вагаючимись щодо покупки. Ось приклад OfferShippingDetails, локалізованого для німецького ринку.
{
"@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 Картах сильно залежить від добре локалізованої схеми LocalBusiness. Особливо коли користувачі шукають своєю рідною мовою або в своєму регіоні, наявність правильної інформації підвищує видимість і зміцнює довіру. Ключові елементи схеми LocalBusiness, які потребують локалізації, включають.
- назва: назва компанії перекладається, якщо вона відповідає місцевому контексту.
- адреса: адреса, відформатована відповідно до місцевих домовленостей, включаючи місцевість, регіон, поштовий індекс та країну.
- телефон: номер телефону з правильним кодом країни та місцевим форматуванням.
- openingHoursSpecification: Графік роботи коригується відповідно до локальних часових поясів та ділових звичаїв.
- geo: географічні координати (широта та довгота) місця розташування магазину.
- areaServed: регіон або територія, яку обслуговує бізнес.
Наприклад, ось фрагмент схеми для магазину, що працює в Берліні, Німеччина.
{
"@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"
}
Нижче наведено приклад схеми розмітки для місцевого бізнесу.
Навігація за хлібними крошками
Схема BreadcrumbList допомагає визначити навігаційну структуру вашого веб-сайту, показуючи користувачам (та пошуковим системам), де вони знаходяться в ієрархії сайту. Хоча це може здатися простим, локалізація хлібних крошок є критично важливою для багатомовного електронного комерційного сайту, щоб забезпечити узгодженість, покращити SEO та покращити користувацький досвід.
Наприклад, хлібна крихта англійською, іспанською та арабською мовами
- “Головна > Чоловіча мода > Куртки”
- «Inicio > Moda Masculina > Chaquetas»,
- “الرئيسية > أزياء الرجال > المعاطف”.
Припустимо, схема хлібних крихт залишається англійською, тоді як вміст сторінки викладено іншою мовою. У такому випадку користувачі можуть зазнати плутанини, а пошукові системи можуть мати проблеми з правильним індексуванням локалізованого вмісту. Це також може зашкодити вашій внутрішній стратегії посилань, оскільки хлібні крихти впливають на те, як розподіляється капітал посилань на вашому сайті.
Ключові елементи схеми BreadcrumbList, які потребують локалізації.
- 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"
}
]
}
Нижче наведено приклад схеми розмітки «хлібні крихти».
Поширені помилки в локалізації схеми для електронної комерції
Під час локалізації розмітки схеми для веб-сайтів електронної комерції підприємства часто стикаються з критичними, але уникними проблемами. Багато хто вважає, що одного лише перекладу достатньо, але структуровані дані мають бути повністю адаптовані до мови, валюти та очікувань користувачів кожного регіону. Ці недоліки можуть призвести до непрацюючих розширених фрагментів, поганої видимості в пошуку або плутанини серед користувачів.
Нижче наведено деякі з найпоширеніших помилок у локалізації схеми, а також пояснення, чому їх уникнення може суттєво вплинути на продуктивність вашого сайту та взаємодію з користувачем.
Використання лише однієї мови або валюти
Одна з найпоширеніших помилок у локалізації схеми електронної комерції полягає в тому, щоб дотримуватися однієї мови або валюти на всьому сайті структурованих даних — навіть коли контент на інтерфейсі перекладено. Це невідповідність заплутує як користувачів, так і пошукові системи. Покупці у Франції можуть читати описи товарів французькою мовою, але бачити схему, яка все ще посилається на USD замість EUR, що може спричинити проблеми із довірою.
Локалізована схема повинна відображати перекладений контент та формати місцевої валюти. Наприклад, у французькій версії сайту замість «priceCurrency»: «EUR» має бути «priceCurrency»: «USD», а поля «name» та «description» у схемі продукту повинні відображатися французькою мовою. Без цього пошукові системи можуть неточно відображати ваші локалізовані оголошення в результатах пошуку.
Ігнорування локалізації мови та валюти призводить до поганих попередніх переглядів фрагментів, знижує показники кліків і може навіть порушувати рекомендації щодо точності структурованих даних. Завжди адаптуйте свою схему відповідно до мови та регіону, використовуючи hreflang та регіон-специфічні субдомени або шляхи.
Неправильне оновлення кодів валют
Багато хто забуває оновити код валюти в розмітці schema, навіть коли продавці використовують правильний локалізований символ валюти на фронтенді. Schema.org використовує стандартизовані коди ISO 4217 (наприклад, «USD» для долара США або «JPY» для японської єни), і неправильне відображення їх у «priceCurrency» призводить до некоректних або оманливих розширених результатів.
Наприклад, якщо ваш магазин в ОАЕ показує ціни в дирхамах, але все ще використовує схему «priceCurrency»: «USD», Google може неправильно інтерпретувати ціну товару або взагалі не відображати її. Гірше того, клієнт може припустити, що товар дешевший або дорожчий через неправильний валютний контекст, що призведе до показника відмов або покинутих кошиків.
Завжди перевіряйте значення валюти у вашій схемі, особливо для магазинів з кількома валютами, що використовують геолокацію або перемикачі валют. Узгодження візуальної та структурованої інформації про валюту покращує зовнішній вигляд у пошуку та довіру клієнтів.
Пропуск регіон-специфічних полів схеми
Інша помилка полягає у використанні загальної схеми для різних регіонів без включення регіон-специфічних елементів, таких як “shippingDestination”, “areaServed” або “availableAtOrFrom”. Ці поля мають вирішальне значення для інформування про логістику та охоплення послуг, особливо при міжнародній доставці або локалізованій підтримці клієнтів.
Наприклад, покупці в Австралії повинні бачити оцінки часу доставки та варіанти доставки на основі місцевих стандартів (наприклад, “shippingDestination”: { “@type”: “DefinedRegion”, “name”: “Australia” }). Якщо не вказати такі деталі, пошукові системи можуть припустити, що ви здійснюєте доставку не туди, що вплине на видимість у локальному пошуку.
Більше того, такі поля, як «areaServed» та «availableAtOrFrom», допомагають відображати ваш бізнес для пошуку «поруч зі мною» або за регіоном. Якщо ви не використовуєте ці поля схеми на регіональних сторінках, ви, ймовірно, втрачаєте можливості локалізованого пошуку.
Ігнорування підтримки мов, що читаються справа наліво
Мови, такі як арабська та іврит, читаються справа наліво (RTL), і нездатність налаштувати розмітку схеми з урахуванням цього може спричинити проблеми з читабельністю та SEO. Хоча схема не відображається візуально, вона все одно повинна відображати контекст мови, щоб відповідати досвіду на сторінці та націлюванню мови пошуку.
Наприклад, поля «назва» та «опис» у схемі продукту на арабській сторінці повинні бути належним чином перекладені та закодовані з використанням правильного формату Unicode. Крім того, сама сторінка повинна використовувати lang=»ar» та dir=»rtl» у HTML, а схема повинна відповідати цим параметрам.
Ігнорування підтримки RTL спричиняє невідповідність між візуальним і структурованим вмістом, що потенційно може заплутати користувачів і вплинути на можливість отримання багатих результатів. Завжди слідкуйте за тим, щоб і мова, і напрямок читання були відображені в структурі схеми.
Відсутні перекладені хлібні крихти
Хлібні крихти слугують навігаційними помічниками та суттєво сприяють внутрішньому лінкуванню та SEO. Однією з поширених помилок у локалізації схеми є збереження схеми хлібних крихт оригінальною мовою, навіть коли видимий шлях навігації перекладено.
Наприклад, якщо на вашій сторінці відображається “Головна > Жіноча мода > Сукні” (іспанською мовою), ваша схема BreadcrumbList має точно відображати це. Використання “name”: “Головна” замість “Inicio” створює розрив і може негативно вплинути на те, як Google інтерпретує структуру сайту.
Кожен рівень хлібних крихт (“name”) має бути локалізованим, а відповідний “item” має посилатися на локалізований URL. Збереження всього в синхронізації забезпечує узгодженість для користувачів і пошукових роботів, підвищуючи видимість та індексацію.
Повторне використання тієї ж схеми для всіх мов
Найбільш руйнівною помилкою є використання універсального підходу до схеми для всіх мов. Повторне використання одних і тих самих структурованих даних без адаптації контенту, валюти, мови та регіонального контексту нівелює всю суть локалізації.
Кожна локалізована версія вашого сайту повинна мати власну схему, що відображає локальний контент і метадані. Наприклад, якщо у вас є окремі сторінки товарів англійською та французькою мовами, їхня схема товару повинна містити перекладені «назва», «опис», «ціна/валюта» та навіть URL-адреси для певної мови.
Нехтування цією практикою може призвести до конфліктних пошукових сигналів, низької якості фрагментів або навіть ручних дій щодо оманливих структурованих даних. Найкращою практикою є підтримка окремих схем для кожного мовного піддомену або версії з тегом hreflang, що гарантує відповідність структурованих даних мові та регіону обслуговування.
Найкращі практики локалізації розмітки схеми для електронної комерції
Розмітка схеми відіграє вирішальну роль у тому, як пошукові системи інтерпретують та відображають ваш контент. За умови правильної локалізації вона підвищує вашу видимість у локальних результатах пошуку, покращує показники кліків та покращує досвід покупок для користувачів у всьому світі.
Ось найкращі практики, яких слід дотримуватися кожному глобальному бізнесу електронної комерції, щоб максимально використати локалізацію.
Використовуйте мовно-специфічну схему на сторінку
Кожна мовна версія вашого веб-сайту повинна містити розмітку схеми на тій конкретній мові. Якщо ви використовуєте субдомени або підпапки (наприклад, example.com/en/ для англійської та example.com/de/ для німецької), кожен повинен містити унікальну, мовно-відповідну схему.
Якщо ваша німецькомовна сторінка все ще використовує схему англійською мовою, Google може мати труднощі з розумінням локального контексту сторінки, і користувачі можуть вважати враження невідповідним їхнім очікуванням, наприклад, як показано нижче.
Країна | Поле схеми | Локалізоване значення |
/fr/product-page | «Ім'я» | “Veste d'hiver pour homme” |
«опис» | “Une veste chaude pour l'hiver français” | |
«Мовою» | “fr” |
Локалізуйте назви та описи продуктів
Назви та описи продуктів не повинні просто перекладатися і культурно адаптуватися. Фрази, які звучать привабливо в одній країні, можуть не знайти відгуку в іншій. Використовуйте природну мову для місцевої аудиторії та узгоджуйте зі своїми покупцями.
Покладайтеся на перекладачів-носіїв мови або місцевих експертів, щоб уникнути незручних фраз або нечітких повідомлень. Такі поля, як назва, опис і бренд у вашій схемі, повинні відображати місцеву мову та вподобання.
Мова | ім'я | опис |
Англійська | “Стильний чоловічий жакет” | “Стильний жакет, ідеальний для зими” |
Японська | “メンズゥィンタージャケット” | «冬に最適なおしゃれなジャケットです。» |
Встановіть точну ціну та валюту
Ціна є чутливою темою в електронній комерції. Не просто конвертуйте валюти візуально на своєму сайті — переконайтеся, що ваша схема точно відображає правильну валюту за допомогою коду ISO 4217 у полі priceCurrency. Ціни також повинні бути відформатовані відповідно до місцевих домовленостей, включаючи десяткові роздільники та роздільники тисяч.
Уникайте відображення лише доларів США для всіх мовних версій, оскільки це може заплутати користувачів або підірвати довіру. Якщо ви використовуєте конвертацію валют у реальному часі, переконайтеся, що ваша схема синхронізована. Наприклад.
Країна | ціна | цінаВалюта | Місцевий формат |
Японія | 4500 | JPY | ¥4,500 |
Саудівська Аравія | 180 | SAR | 180 р.с |
Локалізуйте інформацію про бізнес
Контактна інформація для бізнесу, така як адреси, номери телефонів та години роботи, має бути локалізована за регіонами. Використовуйте локальні формати для таких полів, як адреса_місцевості, поштовий_індекс та адреса_країни. Включіть міжнародні коди набору до номерів телефонів, щоб користувачам було легше зв’язатися з вами.
Такі поля, як openingHoursSpecification, повинні відображати місцеві часові пояси та ділову практику. Ці дані допомагають встановити довіру та покращити видимість вашого бізнесу в результатах локального пошуку. Наприклад.
Країна | місцезнаходження | поштовий індекс | Формат годин роботи |
Іспанія | Барселона | 08001 | Пн-Пт 09:00–18:00 |
Таїланд | Чіангмай | 50000 | Пн-Сб 10:00–19:00 |
Структура схеми для мов RTL
Такі мови, як арабська та іврит, пишуться справа наліво (RTL). Хоча сам JSON-LD не залежить від візуального форматування, будь-яке поле схеми, що містить видимий текст, такий як ім'я, опис або навігаційна лінія, має відображати правильну мову та напрямок, щоб уникнути невідповідностей між вмістом і розміткою.
Якщо ваша сторінка написана арабською мовою, але схема все ще містить англійські значення або контент з письмом зліва направо, це може призвести до плутанини як для користувачів, так і для пошукових систем. Завжди переконайтеся, що HTML містить lang=”ar” і що поля структурованих даних локалізовані відповідно.
Поле | Нелокалізований (LTR/англійська) | Локалізовано (RTL/Арабською) |
ім'я | Зимовий піджак | معطف شتوي |
опис | Тепле пальто на зиму | معطف دافئ مثالي لفصل الشتاء |
хлібні крихти | Головна > Одяг > Куртки | الرئيسية > الملابس > المعاطف |
Автоматизуйте локалізацію схеми за допомогою Linguise
Локалізація розмітки схеми вручну кількома мовами може бути складною, особливо при управлінні сотнями динамічних сторінок продуктів. Видимий контент і структуровані дані, включаючи схеми Product, Offer, BreadcrumbList і LocalBusiness, повинні бути перекладені. Багаті снипети можуть не відображати правильну мову, валюту чи структуру для кожного регіону без належної локалізації.
Linguise пропонує для автоматичного перекладу, яке поширюється на структуровані дані, перекладаючи розмітку схеми та ваш контент. За допомогою Live Editor ви можете вручну налаштувати вміст схеми, такий як назви продуктів, описи або цінності бренду, щоб забезпечити їх точне відображення місцевого контексту. Це особливо корисно під час локалізації полів схеми продукту, які потребують культурних нюансів та адаптації ключових слів для регіонального SEO.
Крім того, Linguise підтримує переклад посилань і медіа, що дозволяє локалізувати URL-адреси хлібних крихт, внутрішні посилання та навіть посилання на зображення. Це забезпечує відповідність усіх елементів, навігаційних шляхів, активів і структурованих даних правильній версії мови, допомагаючи пошуковим системам надавати більш точні та релевантні результати користувачам у всьому світі.
Висновок
Локалізація розмітки схеми має вирішальне значення для міжнародних компаній електронної комерції, які прагнуть покращити видимість у результатах локального пошуку, покращити розширені фрагменти та забезпечити користувачам безперебійний багатомовний досвід. Від назв продуктів та цін до деталей доставки та бізнес-інформації, кожен елемент структурованих даних повинен відповідати мові, культурі та очікуванням кожного цільового ринку.
Щоб оптимізувати цей процес, розгляньте можливість використання Linguise—рішення для перекладу, яке не тільки автоматизує переклад контенту, але й адаптує розмітку схеми, посилання та медіа для кожної мови. Завдяки функціям, таким як Live Editor та переклад для URL-адрес та зображень, використання Linguise може допомогти вашому всьому сайту— видимий контент і структуровані дані однаково повністю локалізовані та готові до SEO.
