Локалізація розмітки схеми для електронної комерції — це про те, щоб ваші структуровані дані говорили мовою ваших клієнтів і пошукових систем. Для міжнародних інтернет-магазинів, особливо тих, що орієнтуються на різні регіони, як-от ЄС, Південно-Східна Азія чи Близький Схід, локалізація схеми є ключовою для того, щоб допомогти пошуковим системам надавати правильні розширені фрагменти залежно від мови, регіону та валюти користувача.
Локалізуючи ключові типи схем, як-от інформація про товар, ціноутворення та дані про бізнес, ви підвищуєте видимість, довіру та коефіцієнти конверсії на різних ринках. У цій статті розглядається, які елементи схеми потрібно локалізувати, поширені помилки, яких слід уникати, та найкращі практики, які допоможуть вашому міжнародному сайту електронної комерції працювати якнайкраще.
Важливість локалізації схеми для вашого електронного магазину
Локалізація схеми гарантує, що ваші структуровані дані відповідають мові, валюті та культурному контексту кожного ринку, який ви обслуговуєте. Це підвищує вашу видимість у місцевих результатах пошуку та покращує досвід користувачів у різних регіонах.
- Покращує місцеве SEO – Коли розмітка schema використовує локалізовану мову, валюту та поля, специфічні для регіону, пошукові системи краще розуміють і зіставляють ваш контент із місцевими пошуковими намірами.
- Забезпечує точні розширені фрагменти – Розширені фрагменти, такі як ціни, наявність товару та відгуки, відображатимуть місцевий контекст користувача, зміцнюючи довіру та підвищуючи показники кліків.
- Покращує багатомовний досвід користувачів – Локалізована схема допомагає забезпечити узгодженість між видимим вмістом сторінки та структурованими даними за ним, уникаючи плутанини для міжнародних відвідувачів.
- Підтримує регіональну відповідність і очікування – Різні регіони можуть мати специфічні вимоги до даних (наприклад, ПДВ у ЄС або зони доставки в Південно-Східній Азії), які можна врахувати через схему.
- Підвищує коефіцієнт конверсії на цільових ринках – Користувачі, які бачать знайому мову, валюту та контактну інформацію в результатах пошуку, з більшою ймовірністю довірятимуть вашому сайту та взаємодіятимуть із ним.
Ключові типи схем електронної комерції, які потребують локалізації
Розмітка Schema — це тип структурованих даних, що додається до HTML-коду вашого вебсайту та допомагає пошуковим системам зрозуміти контекст вашого вмісту. Для електронної комерції вона забезпечує розширені результати, як-от рейтинги товарів, ціни, наявність тощо, завдяки чому ваші оголошення вирізняються в пошуку. Якщо ви орієнтуєтеся на міжнародні ринки, простого використання schema недостатньо — її також потрібно локалізувати.
Нижче наведено ключові типи схем, які потребують ретельної локалізації для успішної глобальної електронної комерції.
Товар
Схема Product надає структуровану інформацію, таку як назва продукту, опис, артикул, бренд, зображення та відгуки. Під час локалізації цієї схеми важливо точно перекладати назви та описи продуктів, не просто дослівно, а так, щоб вони відповідали культурним і мовним нормам кожного ринку.
Кілька ключових елементів потрібно адаптувати до кожного цільового ринку, щоб належно локалізувати схему Product. Ці елементи виходять за межі базового перекладу — культурна адаптація, відповідність місцевим очікуванням і узгодження з SEO для конкретної мови. Ось ключові аспекти схеми Product, які слід локалізувати.
- назва: Перекладіть назву продукту, щоб зберегти значення та привабливість місцевою мовою. Уникайте дослівних перекладів, які можуть заплутати або ввести в оману місцеву аудиторію.
- опис: Локалізуйте описи, звертаючи увагу на тон, одиниці вимірювання (наприклад, дюйми проти сантиметрів) та термінологію, звичну для регіональних аудиторій.
- зображення: Хоча це не текстовий елемент, локалізовані зображення можуть відображати культурні вподобання. Наприклад, зображення одягу на ринках Близького Сходу можуть вимагати більш стриманих візуальних матеріалів.
- brand: Якщо бренд має різні назви в різних регіонах або якщо суббренди більш упізнавані локально, переконайтеся, що поле бренду це відображає.
- sku: Хоча він часто є однаковим у всьому світі, якщо ви використовуєте регіональні коди або ідентифікатори продуктів, оновіть sku відповідно до місцевого каталогу.
- review and aggregateRating: Ці елементи також можуть виграти від локалізації. Якщо відгуки клієнтів включено до схеми, переконайтеся, що вони написані місцевою мовою та відображають відгуки клієнтів, специфічні для регіону.
- пропозиції (вбудовані в Product): Це включає ціноутворення та доступність, які мають відображати місцеву валюту, формати та рівні запасів. Також розгляньте адаптацію priceValidUntil до місцевих циклів продажів.
Наприклад, продукт «Winter Coat – Arctic Series» англійською може бути локалізовано як «Chaqueta Invernal – Serie Ártica» іспанською. На арабських ринках не лише назву й опис потрібно перекласти арабською, але й може знадобитися адаптувати зображення та ключові характеристики відповідно до того, що вважається привабливим або скромним.
Якщо не локалізувати схему Product, може виникнути невідповідність між тим, що показано в пошуковому фрагменті, і тим, що є на фактичній сторінці товару, що підриває довіру та знижує показник кліків. Адаптуючи схему товару для кожного регіону, ви забезпечуєте узгодженість, кращу відповідність 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"
}
}
Ось приклад розмітки схеми Product, яка з’являється онлайн під час пошуку товару.
Ціноутворення та валюта
Ціноутворення є однією з найчутливіших частин інформації для онлайн-покупців. Схема Offer, яка зазвичай вбудована у схему Product, містить ключові поля, як-от price, priceCurrency та availability. Локалізація валюти й ціноутворення є критично важливою, особливо коли ваш сайт орієнтований на регіони, які не використовують долари США, євро чи інші стандартні валюти за замовчуванням.
Наприклад, якщо ви продаєте на Близькому Сході, ваша схема має відображати ціни в AED або SAR, використовуючи відповідний код валюти ISO 4217, як-от «priceCurrency»: «AED». Крім того, формат ціни має відповідати регіональним звичаям — у деяких країнах як десятковий розділювач використовують коми замість крапок або ставлять символ валюти після суми, а не перед нею.
Неправильні або загальні коди валют у розмітці схеми можуть призвести до оманливих розширених фрагментів, заплутати покупців і навіть до санкцій пошукових систем за неузгодженість даних. Ваша схема має синхронізуватися з тим, що бачать користувачі на клієнтській частині, і відображати конверсійні курси в реальному часі або локалізовані стратегії ціноутворення. Адаптація цієї схеми для кожної мови або регіонального субдомену є важливою для забезпечення точності подання на вашому багатомовному вебсайті. Ключові елементи схеми ціноутворення, які потрібно локалізувати.
- ціна: Числове значення ціни, відформатоване для місцевого регіону (наприклад, 99,99 замість 99.99).
- priceCurrency: Використовуйте правильний код валюти ISO 4217 (наприклад, AED, SAR, JPY тощо).
- Розміщення символу валюти: Адаптуйте символ до місцевих звичаїв (наприклад, «99 ر.س» замість «SAR 99»).
- availability: Використовуйте локалізовану мову або мітки, якщо це можливо (наприклад, «In Stock» → «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"
}
Ось приклад розмітки схеми ціноутворення та валюти, яка з’являється онлайн під час пошуку продукту.
Інформація про бізнес і контакти
Схеми Organization та ContactPoint визначають ідентичність вашого бізнесу та способи зв’язку з вами для клієнтів. Локалізація тут передбачає не лише переклад—вона вимагає адаптації робочих годин, мов підтримки та способів зв’язку відповідно до місцевих очікувань.
Локалізуючи схему бізнесу та контактів, ви підвищуєте довіру та допомагаєте пошуковим системам відображати точні контактні дані в результатах пошуку (особливо на мобільних пристроях). Це також допомагає голосовому пошуку та інтелектуальним асистентам надавати правильні відповіді про бізнес залежно від місцезнаходження. Добре локалізована схема гарантує, що клієнти бачать правильні варіанти зв’язку в потрібний момент, відповідно до їхньої мови, регіону та бажаних способів комунікації.
Ключові елементи схем Organization і ContactPoint, які потрібно локалізувати, включають.
- назва: Перекладіть або адаптуйте назву бізнесу, якщо ви використовуєте локальну ідентичність бренду в різних регіонах.
- Тип контакту: Використовуйте локалізовані терміни для типів підтримки (наприклад, «servicio al cliente» іспанською).
- telephone: Додайте місцеві номери підтримки з належними міжнародними форматами.
- areaServed: Вкажіть цільовий регіон за допомогою кодів ISO, щоб забезпечити географічну відповідність.
- availableLanguage: Вкажіть, якими мовами може спілкуватися ваша команда підтримки (наприклад, англійська, арабська, французька).
- contactOption: Додайте специфічні для регіону способи зв’язку, як-от WhatsApp, WeChat або локальні чат-інструменти.
- 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"]
}
}
Деталі доставки
Очікування та правила доставки значно відрізняються від країни до країни. Використовуючи такі типи схеми, як DeliveryTimeSettings, ShippingDeliveryTime або OfferShippingDetails, які є специфічними для регіону, ви можете повідомляти не лише про наявність і орієнтовні терміни доставки, але й про регіони обслуговування, тарифи на доставку та час обробки — усе це має бути локалізовано для кожного ринку. Елементи схеми доставки, які потребують локалізації, включають.
- shippingDestination: регіон або країна обслуговування.
- deliveryTime: орієнтовний час доставки в місцевому форматі (наприклад, 2 дні проти 5-7 робочих днів).
- shippingRate: вартість доставки в місцевій валюті.
- transitTimeLabel: мітка, яка використовується для опису часу доставки (наприклад, «Експрес», «Звичайна» або «Доставка протягом 24 годин»).
- handlingTime: час обробки до початку доставки.
Наприклад, клієнт у Німеччині може очікувати доставку протягом 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 Search або Google Maps значною мірою залежить від добре локалізованої схеми LocalBusiness. Особливо коли користувачі шукають своєю місцевою мовою або в своєму регіоні, наявність правильної інформації підвищує видимість і зміцнює довіру. Ключові елементи схеми LocalBusiness, які потребують локалізації, включають:.
- name: назва бізнесу перекладається, якщо це доречно для місцевого контексту.
- адреса: адреса, відформатована відповідно до місцевих конвенцій, включно з addressLocality, addressRegion, postalCode та addressCountry.
- телефон: номер телефону з правильним кодом країни та місцевим форматуванням.
- 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-адреса має вказувати на правильну локалізовану версію кожної сторінки.
- position: Відображає рівень у ланцюжку навігації (зазвичай залишається незмінним, але має відповідати локалізованій структурі).
{
"@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» у французькій версії сайту, а поля «name» і «description» у схемі Product мають відображатися французькою. Без цього пошукові системи можуть не показувати ваші локалізовані оголошення в результатах пошуку належним чином.
Ігнорування локалізації мови та валюти призводить до поганих попередніх переглядів розширених фрагментів, знижує показники кліків і навіть може порушувати настанови щодо точності структурованих даних. Завжди адаптуйте свою схему відповідно до мови та регіону, використовуючи hreflang та регіональні субдомени або шляхи.
Неналежне оновлення кодів валют
Багато хто забуває оновити код валюти в розмітці схеми, навіть коли продавці використовують правильний локалізований символ валюти на фронтенді. Schema.org використовує стандартизовані коди ISO 4217 (наприклад, «USD» для долара США або «JPY» для японської єни), і невідображення їх належним чином у «priceCurrency» призводить до пошкоджених або оманливих розширених результатів.
Наприклад, якщо ваш магазин в ОАЕ показує ціни в дирхамах, але все ще використовує «priceCurrency»: «USD» у схемі, Google може неправильно витлумачити ціну товару або взагалі вирішити не показувати її. Гірше того, клієнт може припустити, що товар дешевший або дорожчий через неправильний валютний контекст, що призводить до високого показника відмов або покинутих кошиків.
Завжди перевіряйте значення валют у вашій схемі, особливо для магазинів із кількома валютами, які використовують геолокацію або перемикачі валют. Узгодження візуальної та структурованої інформації про валюту покращує вигляд у пошуку та довіру клієнтів.
Пропуск полів схеми, специфічних для регіону
Ще одна помилка — використання загальної схеми для різних регіонів без урахування регіональних елементів, як-от «shippingDestination», «areaServed» або «availableAtOrFrom». Ці поля мають вирішальне значення для передачі інформації про логістику та зону обслуговування, особливо в міжнародних перевезеннях або локалізованій підтримці клієнтів.
Наприклад, покупці в Австралії повинні бачити орієнтовний час доставки та варіанти доставки відповідно до місцевих стандартів (наприклад, «shippingDestination»: { «@type»: «DefinedRegion», «name»: «Australia» }). Пропуск таких деталей може змусити пошукові системи припустити, що ви не доставляєте туди, що вплине на видимість у локальному пошуку.
Крім того, такі поля, як «areaServed» та «availableAtOrFrom», допомагають показати ваш бізнес у пошукових запитах «поруч зі мною» або за регіоном. Якщо ви не використовуєте ці поля схеми на регіональних сторінках, ви, ймовірно, втрачаєте можливості локалізованого пошуку.
Ігнорування підтримки мов з письмом справа наліво
Мови, як-от арабська та іврит, читаються справа наліво (RTL), і нездатність адаптувати розмітку схеми з урахуванням цього може спричинити проблеми з читабельністю та SEO. Хоча схема не відображається візуально, вона все одно має відображати мовний контекст, щоб відповідати досвіду на сторінці та мовному таргетуванню пошуку.
Наприклад, поля «name» та «description» у схемі продукту на арабській сторінці мають бути належно перекладені та закодовані з використанням правильного формату Unicode. Крім того, сама сторінка повинна використовувати lang=”ar” та dir=”rtl” в HTML, і схема має відповідати цьому.
Ігнорування підтримки RTL призводить до неузгодженості між візуальним і структурованим вмістом, що може заплутати користувачів і вплинути на право на розширені результати. Завжди переконайтеся, що як мова, так і напрямок читання відображені в структурі схеми.
Відсутні перекладені навігаційні ланцюжки
Навігаційні ланцюжки слугують навігаційними підказками та значно сприяють внутрішньому лінкуванню й SEO. Поширеною помилкою в локалізації схеми є збереження схеми навігаційного ланцюжка мовою оригіналу, навіть коли видимий шлях навігації перекладено.
Наприклад, якщо ваша сторінка показує «Inicio > Moda Femenina > Vestidos» (іспанською «Головна > Жіноча мода > Сукні»), ваша схема BreadcrumbList має точно це відображати. Використання «name»: «Home» замість «Inicio» створює розрив і може негативно вплинути на те, як Google інтерпретує структуру сайту.
Кожен рівень навігаційного ланцюжка («name») має бути локалізований, а відповідний «item» має посилатися на локалізовану URL-адресу. Підтримка всього в узгодженому стані забезпечує послідовність для користувачів і сканерів, підвищуючи видимість та індексацію.
Повторне використання однієї й тієї ж схеми для всіх мов
Найбільш згубною помилкою є використання універсального підходу до схеми для всіх мов. Повторне використання одних і тих самих структурованих даних без адаптації вмісту, валюти, мови та регіонального контексту зводить нанівець усю мету локалізації.
Кожна локалізована версія вашого сайту повинна мати схему, що відображає місцевий вміст і метадані. Наприклад, якщо у вас є окремі сторінки продуктів для англійської та французької мов, їхня схема Product повинна мати перекладені «name», «description», «priceCurrency» і навіть URL-адреси, специфічні для мови.
Ігнорування цієї практики може призвести до конфліктних сигналів для пошукових систем, низької якості сніпетів або навіть ручних санкцій за введення в оману структурованих даних. Найкраща практика — підтримувати окремі схеми для кожного мовного субдомену або версії з тегом hreflang, гарантуючи, що структуровані дані відповідають мові та регіону, яким вони призначені.
Найкращі практики локалізації розмітки схеми для електронної комерції
Розмітка Schema відіграє вирішальну роль у тому, як пошукові системи інтерпретують і відображають ваш контент. За належної локалізації вона підвищує вашу видимість у локальних результатах пошуку, покращує показник кліків і вдосконалює досвід покупок для користувачів у всьому світі.
Ось найкращі практики, яких має дотримуватися кожен глобальний бізнес електронної комерції, щоб отримати максимум від локалізації.
Використовуйте схему, специфічну для мови, на кожній сторінці
Кожна мовна версія вашого вебсайту повинна містити розмітку схеми цією конкретною мовою. Якщо ви використовуєте субдомени або підпапки (наприклад, example.com/en/ для англійської та example.com/de/ для німецької), кожна з них повинна містити унікальну схему, відповідну мові.
Якщо ваша німецька сторінка досі використовує схему англійською, Google може мати труднощі з розумінням локального контексту сторінки, а користувачі можуть вважати цей досвід невідповідним їхнім очікуванням, наприклад, як показано нижче.
Країна | Поле схеми | Локалізоване значення |
/fr/сторінка-продукту | «назва» | «Veste d’hiver pour homme» |
«опис» | «Тепла куртка для французької зими» | |
«inLanguage» | «fr» |
Локалізуйте назви та описи продуктів
Назви та описи продуктів не повинні лише перекладатися та культурно адаптуватися. Фрази, які звучать привабливо в одній країні, можуть не викликати відгуку в іншій. Використовуйте природну мову для місцевої аудиторії та узгоджуйте її з їхньою купівельною поведінкою.
Покладайтеся на носіїв мови або місцевих експертів, щоб уникнути незграбних формулювань чи незрозумілих повідомлень. Такі поля, як назва, опис і бренд у вашій схемі, мають відображати місцеву мову та вподобання.
Мова | ім'я | опис |
Англійська | “Чоловіча елегантна куртка” | «Стильна куртка, ідеальна для зими» |
Японська | «メンズウィンタージャケット» | «Це стильна куртка, ідеальна для зими» |
Встановіть точну ціну та валюту
Ціна — делікатна тема в електронній комерції. Не просто візуально конвертуйте валюти на своєму сайті — переконайтеся, що ваша схема точно відображає правильну валюту, використовуючи код ISO 4217 у полі priceCurrency. Ціни також мають бути відформатовані відповідно до місцевих конвенцій, включаючи десяткові та тисячні розділювачі.
Не показуйте лише долари США в усіх мовних версіях, оскільки це може заплутати користувачів або підірвати довіру. Якщо ви використовуєте конвертацію валют у реальному часі, переконайтеся, що ваша схема синхронізована. Наприклад.
Країна | ціна | валютаЦіни | Місцевий формат |
Японія | 4500 | Японська єна | ¥4,500 |
Саудівська Аравія | 180 | SAR | 180 р.с |
Локалізувати інформацію про бізнес
Контактна інформація бізнесу, як-от адреси, номери телефонів і години роботи, має бути локалізована за регіоном. Використовуйте місцеві формати для таких полів, як addressLocality, postalCode та addressCountry. Додавайте міжнародні коди набору до номерів телефонів, щоб користувачам було легше з вами зв’язатися.
Такі поля, як openingHoursSpecification, мають відображати місцеві часові пояси та ділові практики. Ці деталі допомагають зміцнити довіру та покращити вигляд вашого бізнесу в місцевих результатах пошуку. Наприклад.
Країна | addressLocality | поштовийІндекс | формат годин роботи |
Іспанія | Барселона | 08001 | Пн–Пт 09:00–18:00 |
Таїланд | Чіангмай | 50000 | Пн–Сб 10:00–19:00 |
Структура схеми для мов з письмом справа наліво
Мови, як-от арабська та іврит, пишуться справа наліво (RTL). Хоча сам JSON-LD не залежить від візуального форматування, будь-яке поле схеми, що містить видимий текст—наприклад, name, description або breadcrumb—має відображати правильну мову та напрямок, щоб уникнути розбіжностей між вмістом і розміткою.
Якщо ваша сторінка арабською, але схема все ще містить англійські значення або контент зліва направо, це може заплутати як користувачів, так і пошукові системи. Завжди переконайтеся, що HTML містить lang=”ar”, а поля структурованих даних локалізовано відповідно.
Поле | Нелокалізований (LTR/англійська) | Локалізовано (RTL/арабська) |
ім'я | Зимова куртка | Зимове пальто |
опис | Тепле пальто на зиму | معطف دافئ مثالي لفصل الشتاء |
навігаційний ланцюжок | Головна > Одяг > Куртки | الرئيسية > الملابس > المعاطف |
Автоматизуйте локалізацію схем за допомогою Linguise
Локалізація розмітки схеми вручну для багатьох мов може бути складною, особливо при керуванні сотнями динамічних сторінок товарів. Видимий вміст і структуровані дані, включаючи схеми Product, Offer, BreadcrumbList і LocalBusiness, повинні бути перекладені. Без належної локалізації розширені сніпети можуть не відображати правильну мову, валюту або структуру для кожного регіону.
Linguise пропонує автоматичний переклад — рішення, що поширюється на структуровані дані, перекладаючи розмітку схеми та ваш контент. За допомогою його Live Editor ви можете вручну налаштовувати вміст схеми, як-от назви продуктів, описи чи значення бренду, щоб вони точно відображали місцевий контекст. Це особливо корисно під час локалізації полів схеми Product, які потребують культурних нюансів і адаптації ключових слів для регіонального SEO.
Крім того, Linguise підтримує переклад посилань і медіа, що дозволяє локалізувати URL-адреси навігаційних ланцюжків, внутрішні посилання та навіть посилання на зображення. Це гарантує, що всі елементи, навігаційні шляхи, ресурси та структуровані дані—узгоджені з правильною мовною версією, допомагаючи пошуковим системам надавати користувачам у всьому світі точніші та релевантніші розширені результати.
Conclusion
Локалізація розмітки схеми є критично важливою для міжнародних компаній електронної комерції, які прагнуть покращити видимість у місцевих результатах пошуку, покращити розширені фрагменти та забезпечити користувачам безперебійний багатомовний досвід. Від назв продуктів і цін до деталей доставки та бізнес-інформації — кожен елемент структурованих даних має відповідати мові, культурі та очікуванням кожного цільового ринку.
Щоб спростити цей процес, розгляньте використання Linguise—рішення для перекладу, яке не лише автоматизує переклад контенту, а й адаптує вашу схему розмітки, посилання та медіа для кожної мови. Завдяки таким функціям, як Live Editor та переклад URL-адрес і зображень, використання Linguise може допомогти всьому вашому сайту—як видимий контент, так і структуровані дані—бути повністю локалізованими та готовими до SEO.
