Schema.org структурирани данни: практическо ръководство

Какво са Schema.org и структурираните данни?

Структурираните данни са машинночетимо описание на съдържанието в дадена страница. Те добавят контекст към информацията, която посетителят вече вижда. Например Google може да разбере, че дадена цена принадлежи на конкретен продукт, че текстът е статия и кой е авторът му или че адресът е на физически обект.

Schema.org е общ речник от типове и свойства. Често използвани типове са Organization, LocalBusiness, Product, Service, Article, Event и BreadcrumbList. Изборът трябва да следва реалното съдържание и предназначението на страницата, а не rich result, който искате да получите.

Подобрява ли Schema.org позицията в Google?

Не директно. Структурираните данни помагат на Google да разбере по-точно страницата. Това може да направи възможен разширен резултат с цена, наличност, дата на събитие или друга приложима информация, но не е гаранция за по-високо класиране.

Google не е длъжен да покаже rich result, дори маркирането да е валидно. Решението зависи от типа страница, качеството на данните, правилата на Google и конкретното търсене. Затова не е коректно да се обещава определен ръст на посещенията само след добавяне на Schema.org.

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

Кой формат за структурирани данни е най-подходящ?

Има три основни подхода: JSON-LD, Microdata и RDFa. За нов сайт или текуща техническа оптимизация обикновено избираме JSON-LD, защото е отделен от визуалния HTML и се поддържа по-лесно.

JSON-LD не променя дизайна на страницата. При статичен сайт данните могат да се зададат в шаблона. При WordPress, custom CMS или онлайн магазин е по-надеждно да се генерират от актуалните записи в системата.

При магазинът цената, валутата, наличността и продуктовото име трябва да идват от един и същ източник, от който се зареждат и на страницата. Това може да бъде каталог, ERP или API. Така промяната на цена или складова наличност не остава само в едната част на системата.

Кои типове Schema.org са полезни за българския бизнес?

Не е необходимо да добавяте всички възможни типове. По-добрият подход е всеки тип да бъде свързан с конкретен шаблон и процес в сайта.

• Organization, за фирмата като цяло: име, лого, сайт, контакти и официални профили.
• LocalBusiness, за бизнес с реален физически адрес, работно време и обслужвана локация. Не измисляйте адрес за фирма без публичен обект.
• Product и Offer, за продуктови страници с име, изображение, цена, валута и наличност, когато тези свойства са приложими.
• Service, за страници, които описват конкретна услуга. Цена се добавя само ако е публично показана и действително важи за тази услуга.
• Article или BlogPosting, за статии с автор, дата на публикуване, дата на промяна и основно изображение.
• BreadcrumbList, за логическата йерархия на страницата, например Начало → Услуги → SEO оптимизация.
• Event, за реални събития с дата, място и условия за участие, а не за обикновена промоционална страница.

За фирмен сайт обикновено са важни Organization, Service и BreadcrumbList, а LocalBusiness, само при физически обект. За онлайн магазин най-често се започва с Organization, Product, Offer и BreadcrumbList.

При B2B платформата за лабораторни консумативи на Labimex продуктовият каталог и логиката на магазина са свързани. Структурираните данни имат смисъл, когато следват тази логика, а не са добавени като отделен кодов слой, който не знае коя е актуалната цена или наличност.

Как се внедряват и проверяват структурирани данни?

1. 01
   Опишете шаблоните на сайта

   Разделете начална страница, фирмена информация, услуги, категории, продукти, статии, контакти и останалите реални шаблони. За всеки шаблон запишете какво вижда посетителят и кои свойства могат да бъдат попълнени коректно.

2. 02
   Изберете минимален набор от свойства

   Започнете с данните, които са налични и се поддържат. Не добавяйте празни или измислени стойности само за да запълните схемата. По-малко точни данни са по-добри от голям блок с противоречия.

3. 03
   Генерирайте JSON-LD от източника на данните

   При CMS или онлайн магазин подавайте данните от базата, каталога, ERP или API. Не поддържайте ръчно цена, наличност, телефон или работно време в отделен код, ако тези данни се променят на друго място.

4. 04
   Проверете синтаксиса и типа

   Използвайте Rich Results Test за конкретен URL или кодов фрагмент. Проверете и валидирането на Schema.org. Валиден JSON не означава автоматично, че сте избрали правилния тип или че страницата отговаря на условията за rich result.

5. 05
   Публикувайте и наблюдавайте

   След публикуване следете отчетите в Google Search Console. Отваряйте и самата страница, защото отчетът не замества проверката дали видимите данни и JSON-LD продължават да съвпадат.

Кои грешки най-често обезсмислят Schema.org?

Маркиране на невидимо съдържание

Често срещан пример е рейтинг с пет звезди в кода, без реални отзиви и рейтинг на страницата. Същият проблем има при скрита цена, измислена наличност или адрес, който посетителят не може да открие на сайта.

Неподходящ тип заради желания резултат

Страница за услуга не става Product, само защото искате да покажете цена. Блог статията не е продукт, а промоционалната страница не е Event без реално събитие. Типът описва предназначението на страницата.

Един и същ код навсякъде

Копирането на една схема върху всички страници води до еднакви автори, цени, адреси или описания на места, където те не са верни. Генерирайте маркирането според шаблона и конкретния запис.

Остарели данни

При магазин промяната на цена или наличност трябва да стигне едновременно до продуктовата страница и JSON-LD. При локален бизнес същото важи за телефона, адреса и работното време. Ако данните се поддържат в няколко системи, нужна е ясна синхронизация.

Технически грешки

Невалиден JSON, грешен тип данни, неправилна валута, несъществуващо изображение или страница, блокирана за обхождане, могат да попречат на резултата. Проверявайте както кода, така и достъпността и съдържанието на самия URL.

Колко струва внедряването на структурирани данни?

Цената зависи от броя шаблони, платформата и източника на данните. При малък фирмен сайт маркирането обикновено е част от техническа SEO работа. При онлайн магазин с продукти, наличности и филтри са нужни повече проверки и връзки към каталога или ERP.

Това е цена за техническа работа, а не обещание за показване на rich results. Ако сайтът има проблеми с индексирането, бавни шаблони или непълно съдържание, първо трябва да се отстранят те. При нужда от цялостна техническа работа вижте какво включва SEO оптимизацията.

Кога е по-добре да не добавяте Schema.org?

Не добавяйте маркиране само защото конкурент има такова. Ако страницата е празна, информацията е непълна или данните се променят постоянно без надежден източник, първо подредете съдържанието и процеса за актуализация.

Schema.org не заменя добрите заглавия, описанията, вътрешните връзки, навигацията и полезния текст. Не може да превърне неясна услуга или неподреден продуктов каталог в добър резултат.

Ако техническата основа не позволява надеждно генериране на данни, първо трябва да се подобри сайтът или магазинът. При магазин с ERP и API най-важното е продуктовата информация да остане еднаква във всички системи. Това е задача за API интеграции и свързване на софтуер, а не само за добавяне на код в страницата.