Schema markup для корпоративного вебсайту
Пояснюємо, що таке schema markup, які типи розмітки обрати для корпоративного сайту та де вона справді корисна для SEO.
Що таке schema markup і де він корисний на корпоративному вебсайті
Schema markup — це спосіб додати сторінці зміст, а не лише текст. Якщо коротко відповісти на запит schema markup що це, то йдеться про підказки для пошукових систем, які читають цей зміст як структуровані дані для сайту, і це допомагає їм зрозуміти, хто ви, що пропонує сторінка та чи відповідає вона запиту. Головна сторінка компанії, сторінка послуги, сторінка контактів і сторінка статті — усі можуть отримати користь від цього додаткового шару.
Для корпоративного вебсайту головна цінність — у чіткості. Пошукова система краще розпізнає назву організації, логотип, адресу, зони обслуговування, авторство матеріалів і хлібні крихти. Це може підтримати SEO, зменшуючи кількість припущень. Також це допомагає, коли результат може отримати більш насичене відображення, хоча жодна розмітка не може примусити пошук показати його саме так.
Питання не в тому, чи додавати schema markup. Справжнє питання — де він справді виправдовує себе. Сторінка, яка простими словами пояснює ваші послуги, і сторінка з офісними даними — обидві хороші кандидати. Слабка посадкова сторінка майже без контенту — ні. Прості сторінки теж можуть містити schema, але розмітка має відповідати тому, що вже написано на сторінці.
Сприймайте це як підписи на папках у шафі для документів. Якщо на папці написано “послуга”, її вміст має виглядати як послуга. Якщо на папці написано “стаття”, сторінка має читатися як стаття. Пошукові системи не люблять ярлики, які обіцяють одне, а показують інше.
Оберіть правильні типи schema для сторінок вашого бізнесу
Більшості корпоративних вебсайтів потрібна лише невелика кількість типів schema. Почніть із тих, що відповідають вашим реальним сторінкам, і не чіпайте решту без явної потреби. Така стриманість важливіша, ніж додавання десяти різних типів просто тому, що вони існують.
| Тип schema | Найкраще використання | Коли не варто використовувати |
|---|---|---|
| Organization | Основна ідентичність компанії, логотип, офіційні соцпрофілі | Не використовуйте для сторінки філії, якщо сторінка присвячена лише локальному підрозділу |
| LocalBusiness | Фізичні офіси, магазини, локації обслуговування, місцеві контактні дані | Не для компанії без публічної локації або без локальної моделі обслуговування |
| WebSite | Ідентичність сайту на рівні головної сторінки та функція пошуку | Не на кожній сторінці як окремий блок ідентичності |
| Article | Блоги, новини, гайди, редакційний контент | Не для сторінок, які переважно є продажовим текстом |
| FAQPage | Сторінки з реальним списком запитань і відповідей | Не якщо відповіді приховані, розмиті або взагалі не оформлені як FAQ |
| BreadcrumbList | Шлях навігації, показаний на сторінці | Не якщо на сторінці немає видимих хлібних крихт |
| Service | Сторінки, що описують послугу з її обсягом, провайдером і деталями пропозиції | Не для загальної головної сторінки, яка одразу перелічує все |
Organization зазвичай є першою schema markup, яку варто додати. Вона дає пошуковим системам стабільну ідентичність самої компанії. LocalBusiness додають наступним, якщо компанія має реальний офіс, магазин, клініку, філію або місце надання послуг. Компанія з однією штаб-квартирою та трьома філіями може акуратно моделювати кожну локацію, але кожна сторінка має містити контент, який підтверджує існування цієї локації.
WebSite належить до шаблону головної сторінки, а не до сторінки послуги. Він може описувати сам сайт і, в деяких випадках, поле пошуку. Article належить до редакційних сторінок, зокрема до матеріалів-роздумів, якщо вони написані як статті, а не як продажові сторінки. Якщо ваша контент-команда щотижня публікує аналітичні матеріали, таким сторінкам зазвичай варто надавати розмітку Article.
FAQPage корисний лише тоді, коли на сторінці справді є FAQ. Чотири запитання з чесними відповідями — це нормально. Двадцять повторених запитань, скопійованих із дзвінків відділу продажів, — зазвичай ні. Пошукові системи стали менш поблажливими, коли FAQ markup використовують лише як прикрасу.
Підв’яжіть schema markup до наявних шаблонів сторінок
Найпростіший спосіб тримати schema markup під контролем — прив’язати його до шаблонів. Шаблон головної сторінки отримує одне завдання. Шаблон сторінки послуги — інше. Це робить роботу повторюваною, а це важливо, коли корпоративний сайт має 30 сторінок, а не 3. Якщо у вас уже є чіткий план корпоративного вебсайту, мапування schema стає його практичним продовженням.
На головній сторінці використовуйте Organization і WebSite. Залишайте дані прив’язаними до назви компанії, логотипа, канонічної URL-адреси і, можливо, пошукової дії, якщо внутрішній пошук справді існує. Не намагайтеся втиснути в розмітку головної сторінки всі послуги. Сторінка може згадувати послуги в тексті, але розмітка має залишатися на рівні самої сторінки.
Сторінки “Про нас” зазвичай підходять для Organization або його легшого розширення. Якщо сторінка присвячена керівництву, історії компанії чи сертифікаціям, видимий контент має вести розмітку. Сторінки контактів часто відповідають LocalBusiness, особливо якщо на них показано адресу, номер телефону, години роботи або карту. Сторінка з фразою “Зв’яжіться з нами” без адреси не є хорошим кандидатом для локальної розмітки.
Сторінки послуг — це місце, де багато команд спокушаються перегнути палицю. Сторінка послуги зазвичай має отримувати Service markup, якщо вона описує одну чітку пропозицію, її обсяг і постачальника. Якщо сторінка є меню з багатьох послуг, зберігайте розмітку стриманою і не вдавайте, що кожен підзаголовок — це окрема пропозиція, якщо це не так. Це зекономить час на виправлення пізніше.
Шаблони статей мають містити Article markup і, якщо це видно в навігації, BreadcrumbList. Таке поєднання особливо добре працює для новинних розділів і контент-хабів. Команда, що публікує дослідження або пояснювальні матеріали, може також використовувати Article для текстів на кшталт гайду про те, як додати schema markup до корпоративного вебсайту, якщо сторінка справді редакційна, а не замаскована посадкова сторінка.
Напишіть і перевірте код JSON-LD
JSON-LD — це бажаний формат для більшості робіт зі schema markup, тому що він живе в блоці script і залишається окремим від видимого тексту. Почніть із типу сторінки, а потім додайте властивості, які є обов’язковими або настійно рекомендованими для цієї schema. Залишайте дані ідентичними тому, що користувач бачить на сторінці. Одна невідповідність може перетворити чисту реалізацію на проблему з підтримкою.
Простий робочий процес виглядає так: оберіть тип schema, перерахуйте факти, які видно на сторінці, перетворіть ці факти на JSON-LD, додайте скрипт на сторінку та протестуйте результат. Це звучить банально, бо так і є. Складність — у дисципліні.
- Визначте шаблон сторінки та точний тип schema.
- Зберіть лише ті факти, які показані на сторінці.
- Напишіть коректний JSON-LD з лапками, комами та дужками на правильних місцях.
- Розмістіть скрипт у коді сторінки, зазвичай у head або body.
- Запустіть сторінку через інструмент перевірки для пошукових систем.
- Виправте синтаксичні помилки, відсутні поля або конфлікти з іншою розміткою.
Обов’язкові властивості залежать від типу schema, тож перед публікацією перевіряйте специфікацію. Для Organization звичними стартовими точками є назва та логотип. Для LocalBusiness часто очікуються адреса і контактні дані. Для Article можуть мати значення заголовок, зображення, дата публікації та автор. Якщо поле не видно на сторінці, не вигадуйте його лише для того, щоб “закрити” schema. Пошукові системи можуть порівнювати розмітку з контентом сторінки, і нісенітницю вони справді помічають.
Перевірку потрібно робити перед запуском і після змін. Спочатку протестуйте один тип сторінки, потім інший. Приклад із головною сторінкою може пройти успішно, тоді як сторінка послуги провалиться через те, що CMS не поставила закривну дужку. Такі помилки дратують, але їх легко знайти, якщо тестувати завчасно.
Додавайте schema markup у CMS або в процес розробки
Команда корпоративного вебсайту зазвичай має три варіанти: редагувати шаблони напряму, додавати поля в CMS або використовувати плагін чи модуль. Усі ці варіанти працюють, якщо за них хтось відповідає. Якщо відповідального немає, schema markup має тенденцію “розповзатися”. Сторінку редизайнять, поле зникне, і розмітка тихо зламається.
Реалізація на рівні шаблонів — найкращий варіант, коли розробник контролює кодову базу. Команда може жорстко прописати Organization на шаблоні головної сторінки, Article — на шаблоні блогу, а LocalBusiness — на сторінках локацій. Це забезпечує однаковий результат і зменшує ручну роботу для редакторів. Також це спрощує перевірки, бо один і той самий патерн з’являється на кожній сторінці одного типу. Для багатьох проєктів саме така мікророзмітка для корпоративного сайту стає найбільш керованим і стабільним підходом.
Поля CMS корисні тоді, коли контент-редакторам потрібен певний контроль. Редактор може обрати тип сторінки, задати назву локації або додати ім’я людини як автора статті. Такий підхід добре працює з CMS, яка акуратно підтримує кастомні поля. Якщо ваша контент-команда вже редагує описи послуг і посадкові сторінки, додаткові schema-поля мають відчуватися як частина того ж процесу, а не як друга робота.
Плагіни можуть бути цілком нормальним рішенням для невеликих команд, але їх потрібно контролювати. Плагін, що додає загальну schema, може вистачити для архіву статей, але він здатен створити зайвий шум на сторінках послуг або дублювати дані, які вже обробляються у шаблонах. Якщо сайт також залежить від підтримки після запуску, переконайтеся, що зміни schema входять до чеклиста підтримки. Це допоможе уникнути сюрпризів через пів року.
Для великих сайтів найкращим рішенням часто є невелика schema-бібліотека, яку підтримують розробники й наповнюють даними з CMS. Редактори змінюють текст. Розробники контролюють логіку. Таке розділення дозволяє тримати розмітку в синхроні з контентом сторінки та зменшує ризик того, що випадкове поле створить невалідний JSON-LD.
Типові помилки schema markup, які можуть зашкодити SEO
Найпоширеніша помилка — це невідповідність. На сторінці написано одне, а в розмітці — інше. Сторінка послуги, позначена як стаття, або сторінка контактів без реальних контактних даних можуть збивати пошукові системи з пантелику й послаблювати довіру до розмітки. Це не теорія — таке часто трапляється на швидко змінюваних сайтах.
Дубльована розмітка — ще одна проблема. Один плагін додає Organization, інша тема додає його знову, і в результаті ви отримуєте два конкуруючі блоки ідентичності. Це не завжди ламає сторінку, але може розмивати сигнали. Якщо schema вже є у шаблонах, не накладайте поверх другий механізм, не перевіривши результат.
Помилки вкладених даних часто трапляються в JSON-LD. Відсутня кома, зламаний масив або адреса всередині неправильного об’єкта можуть зробити блок недійсним. Одна зіпсована літера може зробити весь скрипт марним. Перевіряйте фінальний згенерований HTML, а не лише фрагмент, який вставили в поле CMS.
Пропущені обов’язкові поля легко не помітити. Блок LocalBusiness без коректної адреси або блок Article без реального заголовка може не відповідати очікуванням. Надмірна розмітка — ще одна пастка. Позначати кожну сторінку як FAQPage лише тому, що це здається корисним, може зіграти проти вас, якщо на сторінці є лише два слабкі запитання. Пошукові системи краще бачать “наповнення”, ніж багато команд очікує.
І нарешті, не змінюйте schema, не звірившись із видимою сторінкою. Якщо локація закрилася, оновіть сторінку та розмітку одночасно. Якщо послугу перейменували, JSON-LD має піти за цим. Застарілий блок розмітки — не дрібниця. Він створює невелику, але реальну проблему довіри.
Тестуйте, відстежуйте й безпечно розширюйте структуровані дані
Тестування — це не разова задача. Після розгортання перевірте, чи сторінка відповідає вимогам для rich results, якщо це доречно, і чи розмітку справді читають. Search Console або аналогічний інструмент може показати, які сторінки мають валідні елементи, попередження або помилки. Саме цей звіт варто переглядати першим, коли запускається новий шаблон.
Дивіться на закономірності, а не лише на окремі помилки. Якщо одна сторінка послуги не проходить через друкарську помилку, це швидко виправляється. Якщо не працює кожна сторінка одного шаблону, проблема, найімовірніше, в самому шаблоні. Таке розрізнення економить час і допомагає команді зосередитися на справжньому джерелі проблеми.
Розширюйте schema markup невеликими кроками. Почніть з Organization, WebSite і основних шаблонів контенту. Потім додайте LocalBusiness до сторінок локацій, Article — до редакційного контенту, а Service — там, де це справді доречно. Один сайт може додати FAQPage до десятка сторінок підтримки, інший може взагалі ніколи цього не потребувати. Обидва варіанти можуть бути правильними.
Якщо ви також відстежуєте поведінку сайту за допомогою платформи аналітики та моніторингу вебсайту, використовуйте ці звіти, щоб спостерігати за змінами трафіку після оновлень розмітки. Падіння кліків не завжди означає, що це спричинила schema, але це означає, що варто перевірити проблемні сторінки. Поєднайте це з даними про покази та покриття в Search Console, і ви отримаєте значно чіткішу картину, ніж якщо просто здогадуватиметеся.
Дисципліна впровадження важливіша за кількість. Додайте schema до одного шаблону, перевірте її, поспостерігайте кілька днів, а потім переходьте далі. Корпоративний сайт із 100 сторінками цілком можна безпечно керувати, якщо команда сприймає schema markup як частину релізного процесу, а не як разову прикрасу.
