Имам JSON-LD маркировка (според указанията на Google) за:

  • Website с лого
  • LocalBusiness с AggregateRating и Reviews
  • Breadcrumbs

Изведнъж разбрах, че всяка схема има преведено копие за всеки език, на който е преведен уебсайтът. Всичко е наред с Breadcrumbs, но не е така с, да речем, LocalBusiness тъй като сега има дубликати с дублирани рейтинги.

Не намерих много официална документация от Google за това как да се справя с маркирането на множество езици (всичко, което намерих, беше свързано със страницата и съдържанието, а не за маркиране; използване hreflang и карти на сайта, за да казват на Google за преведени страници, не е същото като създаването на LocalBusiness json-ld, те се обработват по различен начин).

Каква би била най-добрата стратегия за преведени схеми?

  1. Запазете един LocalBusiness схема на един език и да премахнете преведени копия?
  2. Продължавайте да превеждате LocalBusiness схеми с @SameAs сочи към оригиналната схема? Ако е така, може ли Google да разбере, че те са преводи?
  3. Съхранявайте множество схеми на различни езици с един и същ @id и оставете Google да избере една или да различи преведени копия?
  4. Направете ги уникални? Създавайте различни @id за всеки преведен LocalBusiness?

  • Кои части на LocalBusiness са преведени? Предполагам, че повечето съдържание е еднакво на всички езици (име, адрес, телефонен номер и т.н.).
  • @unor с изключение на телефонни номера и имейли всичко е преведено: име, алтернативно име, описание; сайтът е на 3 езика и имам 3 копия на всяка схема
  • Виждал съм само изпълнения, където езикът на стойностите на свойствата на структурираните данни с очаквана / задължителна стойност на типа данни „text“ съответства на езика на съдържанието на html документа, където са внедрени структурирани данни. Във всички тези случаи, когато езикът на уебсайта не е английски, е имало несъответствие: стойностите на структурираните данни, които са предварително дефинирани от речника на Schema, са на английски език, а други стойности на структурирани данни, които трябва да бъдат текстови, са на езика на уебсайта.

бих запазил LocalBusiness на един език навсякъде, но на различни езикови версии на вашия сайт бих добавил определение на езика, като това:

<script type='application/ld+json'> { '@context': 'http://schema.org', '@type': 'LocalBusiness', 'mainEntityOfPage': { '@type': 'WebPage', 'url': 'http://example.com/de/', 'inLanguage': 'de' } } </script> 

Използвайте като url този, който използвате в атрибута hreflang, така че няма да има несъответствие.

  • така че, това е вариант 2: използвайте същото @id за всяко копие на, т.е. LocalBusiness и добавете inLanguage; има ли пример от реалния живот на една и съща маркировка на множество езици?
  • Какво подкрепя тази идея? Това само вашето въображение ли е? Някакви приемливи препоръки?

(Доколкото ми е известно, Google Търсене не публикува насоки за такъв случай.)

Не мисля, че би било полезно да се премахнат структурираните данни от преведените страници.

Потребителите (независимо дали хората или ботовете), които се интересуват от структурирани данни, не е задължително да обхождат страницата и на други езици. Тези потребители дори не биха забелязали, че предоставяте структурирани данни.

Търсачка, която реши да покаже богат резултат за вашата страница, може да се интересува да го покаже и за вашите преведени страници. И ако го направи и ако разширеният резултат включва предоставен от автора текст, търсачката вероятно ще покаже разширения резултат само на преведени страници, ако данните са на езика на страницата.

JSON-LD @id

Тъй като това е същата организация, @id трябва да е същото.

Това е една от основните цели на @id, за да се предаде, че различните възли (евентуално на различни сайтове / страници, на различни езици и т.н.) са около едно и също лице.

JSON-LD @language

JSON-LD ви позволява да зададете езика на низовите стойности с @language. (Това също би ви позволило да имате един възел, който съдържа данните на всички езици.)

Но поне SDTT на Google не изглежда да поддържа @language. Не е ясно дали това важи и за самото търсене на Google. Ако приемем, че Google Търсене не поддържа @language, би трябвало да е добре да предоставите такива езикови анотации така или иначе, тъй като те вероятно ще бъдат игнорирани.

Schema.org inLanguage

Както отбелязва Евгений, Schema.org определя inLanguage свойство, което ви позволява да посочите езика на творческите произведения (не на LocalBusiness себе си).

Можете да предоставите този имот на всеки WebPage и / или на всеки език WebSite вещ.

Schema.org workTranslation/translationOfWork

За да предаде това WebPage (и вероятно също WebSite) елементите са / имат преводи, можете да използвате workTranslation/translationOfWork свойство от разширението bib на Schema.org.

е работил за вас: Charles Robertson | Искате ли да се свържете с нас?