Локалізація розмітки схеми для електронної комерції полягає в тому, щоб зробити ваші структуровані дані зрозумілими для ваших клієнтів та пошукових систем. Для міжнародних інтернет-магазинів, особливо тих, що орієнтовані на різні регіони, такі як ЄС, Південно-Східна Азія чи Близький Схід, локалізація схеми є ключовим фактором у наданні пошуковим системам можливості надавати потрібні розширені сниппети на основі мови користувача, регіону та валюти.
Локалізуючи ключові типи схем, такі як інформація про продукт, ціноутворення та бізнес-деталі, ви підвищуєте видимість, довіру та коефіцієнти конверсії на різних ринках. Ця стаття досліджує, які елементи схеми потрібно локалізувати, типові помилки, яких слід уникати, та найкращі практики, щоб допомогти вашому міжнародному сайту електронної комерції працювати на найвищому рівні.
Важливість локалізації схеми для вашого електронної комерції
Локалізація схеми забезпечує відповідність ваших структурованих даних мові, валюті та культурному контексту кожного ринку, який ви обслуговуєте. Це покращує вашу видимість у місцевих результатах пошуку та покращує користувацький досвід у різних регіонах.
- Підвищує локальну SEO продуктивність – Коли розмітка схеми використовує локалізовану мову, валюту та регіон-специфічні поля, пошукові системи можуть краще розуміти та зіставляти ваш вміст із локальним пошуковим запитом.
- Дозволяє точні розширені сниппети – Розширені сниппети, такі як ціни, наявність товарів і відгуки, відображатимуть локальний контекст користувача, підвищуючи довіру та покращуючи клікабельність.
- Покращує багатомовний користувацький досвід – Локалізована схема допомагає забезпечити узгодженість між видимим вмістом сторінки та структурованими даними за нею, уникаючи плутанини для міжнародних відвідувачів.
- Підтримує регіональну відповідність та очікування – Різні регіони можуть мати специфічні вимоги до даних (наприклад, ПДВ у ЄС або зони доставки в Південно-Східній Азії), які можна вирішити за допомогою схеми.
- Підвищує коефіцієнт конверсії на цільових ринках — Користувачі, які бачать знайомі мову, валюту та контактну інформацію у попередніх результатах пошуку, швидше за все довірятимуть і взаємодіятимуть з вашим сайтом.
Ключові типи схем електронної комерції, які потребують локалізації
Розмітка схеми - це тип структурованих даних, доданих до HTML-коду вашого веб-сайту, який допомагає пошуковим системам зрозуміти контекст вашого контенту. Для електронної комерції вона забезпечує багаті результати, такі як рейтинги продуктів, ціни, доступність тощо, що робить ваші списки помітними у пошуку. При орієнтації на міжнародні ринки простого використання схеми недостатньо, її також потрібно локалізувати.
Нижче наведено ключові типи схем, які потребують ретельної локалізації для успіху глобальної електронної комерції.
Product
Схема продукту надає структуровану інформацію, таку як назва продукту, опис, 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).
- Валюта ціни: Використовуйте правильний код валюти ISO 4217 (наприклад, AED, SAR, JPY тощо).
- Розміщення символу валюти: Адаптуйте символ до місцевих умов (наприклад, “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"
}
Ось приклад розмітки схеми ціни та валюти, що з'являється в Інтернеті під час пошуку продукту.
Інформація про бізнес та контакти
Схеми Organization та ContactPoint визначають ідентичність вашого бізнесу та те, як клієнти можуть зв'язатися з вами. Локалізація тут передбачає більше, ніж просто переклад — вона вимагає адаптації робочих годин, мов підтримки та методів зв'язку відповідно до місцевих очікувань.
Локалізуючи схему бізнесу та контактів, ви підвищуєте довіру та допомагаєте пошуковим системам відображати точні контактні дані у результатах пошуку (особливо на мобільних пристроях). Це також допомагає голосовому пошуку та інтелектуальним помічникам надавати коректні відповіді бізнесу на основі місцезнаходження. Добре локалізована схема забезпечує, що клієнти бачать потрібні контактні опції у потрібний час, відповідно до їхньої мови, регіону та бажаних методів зв'язку.
Ключові елементи схем організації та контактної точки для локалізації включають.
- ім'я: Перекладіть або адаптуйте назву бізнесу, якщо ви використовуєте локальну бренд-ідентичність у різних регіонах.
- Тип контакту: Використовуйте локалізовані терміни для типів підтримки (наприклад, “обслуговування клієнтів” іспанською).
- телефон: Включіть локальні номери підтримки з правильними міжнародними форматами.
- Регіон обслуговування: Визначте цільовий регіон за допомогою кодів ISO, щоб забезпечити географічну релевантність.
- доступнаМова: Вкажіть мови, якими може володіти ваша команда підтримки (наприклад, англійська, арабська, французька).
- 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, які є специфічними для регіону, ви можете повідомити не лише про доступність та очікуваний час доставки, але й про регіони обслуговування, тарифи на доставку та час обробки - все це має бути локалізовано для кожного ринку. Елементи схеми доставки, які потрібно локалізувати, включають.
- Місце доставки: регіон або країна обслуговування.
- час доставки: оцінений час доставки у локальному форматі (наприклад, 2 дні проти 5-7 робочих днів).
- ставкаДоставки: вартість доставки в місцевій валюті.
- мітка часу доставки: мітка, що використовується для опису часу доставки (наприклад, “Експрес”, “Звичайна” або “Доставка протягом 24 годин”).
- handlingTime: час обробки перед початком доставки.
Наприклад, клієнт у Німеччині може очікувати доставки протягом 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 Search або Google Maps суттєво залежить від добре локалізованої схеми 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 та покращити користувацький досвід.
Наприклад, хлібні крихти англійською, іспанською та арабською мовами
- “Головна > Чоловіча мода > Куртки”
- “Головна > Чоловіча мода > Куртки”,
- “Головна > Чоловіча мода > Пальта”.
Припустимо, що схема хлібних крихт залишається англійською, поки вміст сторінки знаходиться в іншій мові. У цьому випадку користувачі можуть зазнати плутанини, а пошукові системи можуть мати проблеми з правильним індексуванням локалізованого вмісту. Це також може зашкодити вашій стратегії внутрішнього зв'язування, оскільки хлібні крихти впливають на те, як капітал посилання протікає через ваш сайт.
Ключові елементи схеми 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”: “Австралія” }). Ігнорування таких деталей може призвести до того, що пошукові системи подумають, що ви туди не доставляєте, що вплине на видимість у локальному пошуку.
Крім того, поля на кшталт «areaServed» та «availableAtOrFrom» допомагають відображати ваш бізнес у пошуку «near me» або в регіональних пошуках. Якщо ви не використовуєте ці поля схеми на регіональних сторінках, ви, ймовірно, втрачаєте можливості локалізованого пошуку.
Ігнорування підтримки мови RTL
Мови, такі як арабська та іврит, читаються справа наліво (RTL), і нездатність налаштувати розмітку схеми відповідно до цього може спричинити проблеми з читабельністю та SEO. Хоча схема не відображається візуально, вона все одно повинна відображати контекст мови, щоб відповідати досвіду на сторінці та націлюванню мови пошуку.
Наприклад, поля «name» та «description» у схемі продукту на арабській сторінці повинні бути належним чином перекладені та закодовані з використанням правильного формату Юнікоду. Крім того, сама сторінка повинна використовувати lang="ar" та dir="rtl" в HTML, і схема повинна відповідати тому ж.
Нехтування підтримкою RTL спричиняє невідповідність між візуальним і структурованим вмістом, що може заплутати користувачів і вплинути на можливість отримання багатого результату. Завжди переконуйтеся, що і мова, і напрямок читання відображаються у структурі схеми.
Відсутні перекладені хлібні крихти
Навігаційні хлібні крихти служать навігаційними помічниками і суттєво сприяють внутрішньому лінкуванню та SEO. Однією з поширених помилок у локалізації схеми є збереження схеми навігаційних хлібних крихт у вихідній мові, навіть коли видимий шлях навігації перекладено.
Наприклад, якщо на вашій сторінці відображається «Inicio > Moda Femenina > Vestidos» (іспанською мовою «Home > Women’s Fashion > Dresses»), ваша схема BreadcrumbList має точно відображати це. Використання «ім'я»: «Home» замість «Inicio» створює розрив і може негативно вплинути на те, як Google інтерпретує структуру сайту.
Кожен рівень хлібних крихт («ім'я») має бути локалізований, а відповідний «елемент» має посилатися на локалізований URL-адресу. Збереження всього вирівняного забезпечує узгодженість для користувачів і пошукових роботів, підвищуючи видимість та індексацію.
Повторне використання тієї самої схеми для всіх мов
Найбільш руйнівною помилкою є використання універсального підходу до схеми для всіх мов. Повторне використання одних і тих же структурованих даних без адаптації змісту, валюти, мови та регіонального контексту нівелює всю мету локалізації.
Кожна локалізована версія вашого сайту повинна мати свою схему, що відображає локальний вміст та метадані. Наприклад, якщо у вас є окремі сторінки продуктів для англійської та французької мов, їх схема продукту повинна містити перекладені «name», «description», «priceCurrency» та навіть специфічні для мови URL-адреси.
Нехтування цією практикою може призвести до суперечливих сигналів пошуку, низької якості фрагментів або навіть ручних дій щодо оманливих структурованих даних. Найкраща практика полягає в підтримці окремих схем для кожного мовного піддомену або версії з тегом hreflang, що забезпечує відповідність структурованих даних мові та регіону, що обслуговується.
Найкращі практики локалізації розмітки схеми для електронної комерції
Розмітка Schema відіграє вирішальну роль у тому, як пошукові системи інтерпретують і відображають ваш контент. Якщо її правильно локалізувати, вона підвищує вашу видимість у місцевих результатах пошуку, покращує показники кліків і покращує враження від покупок для користувачів по всьому світу.
Ось найкращі практики, яких слід дотримуватися кожному глобальному бізнесу електронної комерції, щоб отримати максимальну користь від локалізації.
Використовуйте специфічну для мови схему на сторінку
Кожна версія мови вашого веб-сайту повинна містити розмітку схеми на тій конкретній мові. Якщо ви використовуєте субдомени або підпапки (наприклад, example.com/en/ для англійської та example.com/de/ для німецької), кожен повинен містити унікальну схему, відповідну мові.
Якщо ваша німецька сторінка все ще використовує схему англійською мовою, Google може мати труднощі з розумінням локального контексту сторінки, і користувачі можуть вважати, що досвід не відповідає їхнім очікуванням, наприклад, як показано нижче.
Країна | Поле схеми | Локалізоване значення |
/fr/product-page | “назва” | «Зимовий чоловічий одяг» |
«description» | “Тепла куртка для французької зими” | |
«inLanguage» | «fr» |
Локалізуйте назви та описи продуктів
Назви та описи продуктів не повинні просто перекладатися та культурно адаптуватися. Фрази, які звучать привабливо в одній країні, можуть не знайти відгуку в іншій. Використовуйте природну мову для місцевої аудиторії та адаптуйте її до їхньої поведінки під час покупок.
Довірте локалізацію фахівцям або місцевим експертам, щоб уникнути незграбних фраз або нечітких повідомлень. Поля, такі як назва, опис та бренд у вашій схемі, мають відображати місцеву мову та вподобання.
Мова | ім'я | опис |
Англійська | “Стильна чоловіча куртка” | “Стильна куртка, ідеальна для зими” |
Японська | “Чоловічі зимові куртки” | “Це стильна куртка, ідеальна для зими.” |
Встановіть точну ціну та валюту
Ціна є делікатним питанням у електронній комерції. Не просто конвертуйте валюти візуально на своєму сайті — переконайтеся, що ваша схема точно відображає правильну валюту за допомогою коду ISO 4217 у полі priceCurrency. Ціни також повинні бути відформатовані відповідно до місцевих домовленостей, включаючи десяткові роздільники та роздільники тисяч.
Уникайте відображення лише USD на всіх мовних версіях, оскільки це може заплутати користувачів або підірвати довіру. Якщо ви використовуєте конвертацію валют у режимі реального часу, переконайтеся, що ваша схема залишається синхронізованою. Наприклад.
Країна | ціна | priceCurrency | Місцевий Формат |
Японія | 4500 | JPY | ¥4,500 |
Саудівська Аравія | 180 | SAR | 180 р.с |
Локалізувати інформацію про бізнес
Контактна інформація бізнесу, така як адреси, номери телефонів та години роботи, повинні бути локалізовані за регіоном. Використовуйте локальні формати для полів, таких як addressLocality, postalCode та addressCountry. Додайте міжнародні коди набору номера до телефонних номерів, щоб користувачам було легше зв'язатися з вами.
Полі, такі як openingHoursSpecification, повинні відображати локальні часові пояси та ділові практики. Ці деталі допомагають встановити довіру та покращити зовнішній вигляд вашого бізнесу в локальних результатах пошуку. Наприклад.
Країна | місцезнаходження | поштовийІндекс | Формат години роботи |
Іспанія | Барселона | 08001 | Пн-Пт 09:00–18:00 |
Таїланд | Чіангмай | 50000 | Пн-Сб 10:00–19:00 |
Структура схеми для мов RTL
Мови, такі як арабська та іврит, пишуться справа наліво (RTL). Хоча JSON-LD сам по собі не залежить від візуального форматування, будь-яке поле схеми, що містить видимий текст — наприклад, ім'я, опис або хлібні крихти — має відображати правильну мову та напрямок, щоб уникнути невідповідностей між вмістом і розміткою.
Якщо ваша сторінка арабською мовою, але схема все ще містить англійські значення або контент зліва направо, це може призвести до плутанини як для користувачів, так і для пошукових систем. Завжди переконуйтеся, що HTML містить lang=”ar” і що поля структурованих даних локалізовані відповідно.
Поле | Не локалізовано (зліва направо/англійська) | Локалізовано (RTL/Арабською) |
ім'я | Зимовий піджакет | Зимове пальто |
опис | Теплий пальто на зиму | Тепла пальто ідеальна для зими |
хлібні крихти | Головна > Одяг > Куртки | Головна > Одяг > Пальта |
Автоматизуйте локалізацію схеми за допомогою Linguise
Локалізація розмітки схеми вручну для кількох мов може бути складною, особливо при управлінні сотнями динамічних сторінок продуктів. Видимий контент і структуровані дані, включаючи схеми Product, Offer, BreadcrumbList та LocalBusiness, повинні бути перекладені. Багаті снипети можуть не відображати правильну мову, валюту чи структуру для кожного регіону без належної локалізації.
Linguise пропонує автоматичний переклад рішення, що поширюється на структуровані дані, перекладаючи розмітку схеми та ваш вміст. Через Live Editor ви можете вручну налаштувати вміст схеми, такий як назви продуктів, описи або значення бренду, щоб вони точно відображали місцевий контекст. Це особливо корисно при локалізації полів схеми продукту, які вимагають культурного нюансу та адаптації ключових слів для регіонального SEO.
Крім того, Linguise підтримує переклад посилань та медіа, що дозволяє локалізувати URL-адреси навігаційних елементів, внутрішні посилання та навіть посилання на зображення. Це забезпечує відповідність усіх елементів, шляхів навігації, активів та структурованих даних правильній версії мови, допомагаючи пошуковим системам надавати більш точні та релевантні результати користувачам у всьому світі.
Висновок
Локалізація розмітки схеми має вирішальне значення для міжнародних електронних комерційних бізнесів, які прагнуть покращити видимість у місцевих пошукових результатах, покращити розширені сниппети та забезпечити користувачам безперебійну багатомовну взаємодію. Від назв продуктів та цін до деталей доставки та інформації про бізнес, кожен елемент структурованих даних має відповідати мові, культурі та очікуванням цільового ринку.
Щоб оптимізувати цей процес, розгляньте можливість використання Linguise—рішення для перекладу, яке не тільки автоматизує переклад контенту, але й адаптує розмітку схеми, посилання та медіа для кожної мови. Завдяки функціям, таким як Live Editor та переклад для URL-адрес і зображень, використання Linguise може допомогти зробити весь ваш сайт—видимий контент і структуровані дані однаково повністю локалізованими та готовими до SEO.
