• -10%
Schema.org для PrestaShop – дані JSON-LD Pro | PrestaDev
Schema.org для PrestaShop – дані JSON-LD Pro | PrestaDev
Schema.org для PrestaShop – дані JSON-LD Pro | PrestaDev
Schema.org для PrestaShop – дані JSON-LD Pro | PrestaDev
Schema.org для PrestaShop – дані JSON-LD Pro | PrestaDev
Schema.org для PrestaShop – дані JSON-LD Pro | PrestaDev

Структуровані дані Schema.org (JSON-LD) Pro для PrestaShop

Module version: 1.3.7

PrestaShop compatibility: 1.7.x 8.x 9.x 1.6.x

Файл модуля оновлено: 2026-09-14 15:37:28

Дані товару оновлено: 2026-09-14 17:21:00


1 Відгуки

PD Schema.org Pro додає до вашого магазину PrestaShop повні структуровані дані Schema.org у форматі JSON-LD, завдяки чому Google краще розуміє пропозицію, бренд і структуру магазину. Модуль підтримує ключові типи схем (зокрема Product, BreadcrumbList, Organization, LocalBusiness, WebSite) та дозволяє очистити наявні мікродані із шаблону, щоб уникнути дублювання. Працює в середовищі multistore, не потребує ручних змін у файлах і сумісний із популярними модулями відгуків, полегшуючи впровадження оцінок і «зірочок» у результатах пошуку.

У разі наявності неповних структурованих даних або їх повної відсутності в шаблоні та модулях шаблону, вищезазначений модуль є для вас найкращим рішенням!

Тип ліцензії / оновлення
133,20 zł
108,29 złnetto 148,00 zł -10%
Lowest price in last 30 days before discount: 148,00 zł

опис

Найважливіші функції модуля

Єдиний граф JSON-LD і контроль опублікованих сутностей

  • Єдиний документ JSON-LD. Модуль складає увімкнені дані в один граф Schema.org з @context і @graph, замість створювати окремий фрагмент JSON для кожного типу даних.
  • Зв’язки через @id. Сутності можуть посилатися одна на одну, наприклад пропозиція товару на організацію, а сторінка — на сайт і навігаційні крихти.
  • Генерування на боці PHP. JSON будується класом модуля і кодується через json_encode(); шаблон отримує готову розмітку .
  • Рендеринг після підготовки сторінки. Модуль використовує displayFooter, щоб мати доступ до даних видимого списку товарів і питань FAQ, переданих до Smarty.
  • Незалежні перемикачі. Organization, LocalBusiness, Product, BreadcrumbList, WebSite, WebPage, CheckoutPage, ContactPage, SearchResultsPage, Article, CollectionPage і FAQPage вмикаються незалежно.

Organization, OnlineStore і комерційні дані

  • Тип організації. Можна налаштувати сутність як OnlineStore, OnlineBusiness, Organization, Corporation або Store.
  • Джерело даних компанії. Назва, адреса і контакт можуть використовувати налаштування магазину PrestaShop або значення, введені вручну в модулі.
  • Ідентифікація суб’єкта. Модуль підтримує, зокрема, юридичну назву, альтернативні назви, опис, логотип, зображення, адресу, e-mail, телефон, профілі sameAs, ІПН, VAT ID, код ISO 6523, GLN і дату заснування — якщо дані будуть заповнені.
  • Контактні точки. У розширеній конфігурації можна додати повторювані канали зв’язку з типом контакту, телефоном, e-mail, мовами й зоною обслуговування.
  • Комерційні умови. Для організації можна налаштувати правила повернення, служби доставки та рівні програми лояльності. Дані публікуються лише тоді, коли адміністратор надасть повні, правдиві значення.

LocalBusiness для стаціонарних точок і локального обслуговування

  • Одна точка або багато філій. Базові поля створюють сутність LocalBusiness за замовчуванням, а повторюваний список філій дозволяє опублікувати окремі сутності зі стабільними ідентифікаторами.
  • Адреса і локальні дані. Для локації можна вказати тип діяльності, назву, бренд, адресу, телефон, e-mail, адресу сторінки, код філії, ціновий діапазон, зону обслуговування, прийняті способи оплати та валюти.
  • Координати і карта. Доступні поля широти та довготи, адреси карти й адрес зображень.
  • Стандартні та особливі години. Модуль підтримує години роботи за днями тижня, а також рядки з діапазоном дат для сезонного або виняткового графіка.
  • Валідація адреси. Для вручну налаштованої активної локації потрібні повні адресні дані: вулиця, місто, поштовий індекс і дволітерний код країни ISO.

Товар, пропозиція і варіанти

  • Product або ProductGroup. Товар без доступних варіантів отримує сутність Product; товар із доступними комбінаціями може бути описаний як ProductGroup із сутностями hasVariant.
  • Дані, отримані з PrestaShop. Модуль використовує назву, опис, категорію, зображення, артикул SKU, MPN, EAN-13, UPC, виробника, вагу, розміри, ціну, валюту, наявність і стан товару — коли вони доступні та застосовні.
  • Пропозиції, залежні від можливості купівлі. Сутність Offer додається лише тоді, коли каталог не працює в режимі каталогу, товар можна замовити і ціна видима на сторінці товару.
  • Варіанти з власною адресою. Кожен опублікований варіант отримує зв’язок із комбінацією PrestaShop; коли генератор URL повертає одну канонічну адресу, модуль додає параметр id_product_attribute.
  • Мапування характеристик варіанта. Групи атрибутів можна призначити властивостям, таким як колір або розмір, а інші осі варіантів передаються як additionalProperty з публічною назвою атрибута.
  • Дані, що розширюють товар. Розширена конфігурація дозволяє мапувати характеристики товару на властивості, матеріал, візерунок, сертифікати та енергетичні дані. Модуль також передає ціну за одиницю, коли дані одиниці та коефіцієнта в товарі дозволяють її обчислити.
  • GTIN і фото. Builder перевіряє правильність довжини та контрольної цифри GTIN, а дані зображень товару охоплюють доступні зображення товару, а не лише обкладинку.
  • Межа кількості варіантів. Ліміт за замовчуванням становить 100 комбінацій на магазин, а абсолютний технічний ліміт — 250. Після його перевищення модуль не будує розширений ProductGroup з усіма варіантами, щоб не роздувати відповідь сторінки.
  • Доставка і повернення. Можна передати деталі доставки та політику повернення на рівні організації або ввімкнути окреме перевизначення для пропозицій товару.

Сторінки, контент і видимі елементи магазину

  • BreadcrumbList. Модуль будує навігаційні крихти з видимої навігації, а коли вони недоступні, застосовує підтримку сторінок товару, категорії, виробника, постачальника, CMS і розпізнаних сторінок блогу.
  • WebSite на головній сторінці. Сутність WebSite публікується для головної сторінки магазину після її ввімкнення.
  • WebPage і спеціальні сторінки. Модуль створює WebPage з типом, підібраним до поточного контролера, а окремі перемикачі підтримують CheckoutPage, ContactPage і SearchResultsPage.
  • Article. Інтеграція стосується записів із ph_simpleblog і smartblog; може передавати заголовок, опис, зображення, дати та автора, видимого на сторінці.
  • CollectionPage. Для списків категорії, виробника, постачальника, новинок, акцій і бестселерів модуль будує список видимих товарів. Ліміт позицій налаштовується від 1 до 200, за замовчуванням 50.
  • FAQPage з контенту, видимого користувачеві. Питання та відповіді отримуються виключно з даних, переданих поточною відрендереною сторінкою під ключами pd_faqs, product_faqs або faqs.

Панель адміністратора і підтримка даних

  • Робоча область і попередній перегляд. Панель модуля групує налаштування схем і містить попередній перегляд згенерованого JSON-LD на основі поточної конфігурації.
  • Контроль збереження. Модуль валідує, зокрема, обов’язкові дані ручної організації, e-mail, коди країн, HTTP(S)-адреси, числові діапазони, години, повторювані рядки та конфігурацію доставки й повернень.
  • Multistore. Конфігурація зберігається в контексті магазину; кожен магазин може публікувати власні дані компанії, локації та комерційні дані.
  • Видалення старішого JSON-LD. Інструменти модуля можуть створити резервну копію та видалити виявлені старіші фрагменти JSON-LD з файлів теми або модулів, а потім відновити вибрані дані з архіву.

Значення для SEO і GEO — без необґрунтованих обіцянок

JSON-LD передає пошуковим системам і системам обробки даних структуровану інформацію про магазин, компанію, товари, локації та видимий контент. Для GEO важлива узгодженість назв, адрес, контактів, зон обслуговування і профілів із реальними даними підприємства; модуль не заповнює їх за адміністратора і не перевіряє їхню правдивість поза валідацією формату. Структуровані дані не замінюють якість сторінки, доступність контенту, індексацію, політику пошукової системи чи конфігурацію Google Search Console. Результат слід перевіряти на опублікованій сторінці конкретного магазину після ввімкнення відповідних сутностей і заповнення даних.

Важливі межі роботи

  • Модуль не надсилає дані до Google, не заявляє адреси до індексу і не примушує до розширених результатів.
  • Він не керує контентом FAQ. Файл faq.json є матеріалом для імпорту питань і відповідей; сам модуль Schema.org не зчитує його безпосередньо під час генерування сторінки.
  • FAQPage, CollectionPage і Article залежать від даних, фактично доступних на поточній сторінці, та від підтримуваних інтеграцій.
  • Нестандартна тема або модуль, який не викликає displayFooter або не передає видимі дані до Smarty, потребує перевірки в конкретному магазині.
  • Версія 1.3.6 декларує сумісність із PrestaShop 1.7.0.0–9.99.99; середовище PHP водночас має відповідати вимогам використовуваної версії PrestaShop.


Посилання на демо модуля:

Демо панелі адміністратора:
https://moduly-prestashop.eu/znaczniki-rozszerzone/admin-dev

Демо фронтальної панелі:
https://moduly-prestashop.eu/znaczniki-rozszerzone

Перевірка коректності роботи структурованих даних:
https://validator.schema.org

Посібники та документація

Ознайомтеся з контекстом впровадження та обмеженнями, описаними в посібнику. Детальний обсяг цього продукту ви знайдете в описі вище.

Деталі продукту

Підтримка Prestashop 9.x
Так
Підтримка Prestashop 8.x
Так
Підтримка Prestashop 1.7.x
Так
Підтримка Prestashop 1.6.x
Так
Модульні переклади
EN, ENG
Безкоштовна підтримка
Так
Безкоштовні оновлення (1 рік)
Так
Легко встановлюється
Так
PDSOP-FULL

Changelog

Release history for this product. Expand an entry to see what changed.

  • poprawiono regex-y do czyszczenia mark-upu Json LD z plików modułów

  • dodano obsługę PrestaShop 9.x wraz z nowym systemem tłumaczeń w modułach
  • poprawiono escapowanie zmiennych podczas tworzenia markupu JSON-LD w tpl-u w skrajnych przypadkach mogło to powodować rozsypanie się struktury naszego JSON-LD i błędy podczas walidacji

FAQ

Find answers to the most common questions about this product.

Модуль створює структуровані дані Schema.org у форматі JSON-LD для увімкнених елементів магазину та поточної сторінки. Він може описувати, зокрема, організацію, місцезнаходження, товар, варіанти, пропозицію, хлібні крихти, вебсайт, сторінку, запис блогу, список товарів і видимі запитання FAQ. Кожен тип даних потрібно окремо увімкнути та правильно налаштувати.

Ні. Модуль надає технічну розмітку JSON-LD, але рішення щодо індексації, способу інтерпретації даних і відображення розширеного результату належить пошуковій системі. Структуровані дані не замінюють доступний контент, коректну індексацію, якість сторінки ані відповідність даних компанії дійсності.

Модуль будує єдиний документ JSON-LD з контекстом https://schema.org і графом @graph. Окремі сутності поєднуються за допомогою сталих ідентифікаторів @id, наприклад, організація може бути вказана як продавець пропозиції товару. JSON формується та кодується в PHP, а шаблон отримує готовий тег script type application/ld+json.

Модуль повертає готову розмітку в хуку displayFooter. Такий момент генерування дає змогу використати дані видимого списку товарів і FAQ, передані до Smarty поточною відрендереною сторінкою. Тема або нестандартний контролер мають викликати цей хук, щоб розмітка була відображена.

Окремі перемикачі охоплюють Organization, LocalBusiness, Product, BreadcrumbList, WebSite, WebPage, CheckoutPage, ContactPage, SearchResultsPage, Article, CollectionPage і FAQPage. Увімкнення однієї сутності не запускає автоматично решту. Модуль будує лише ті вузли, для яких виконані умови сторінки та доступні необхідні дані.

У конфігурації організацію можна позначити як OnlineStore, OnlineBusiness, Organization, Corporation або Store. Вибір має відповідати фактичному характеру суб’єкта. Модуль не визначає тип автоматично на підставі галузі магазину.

Для організації можна вибрати джерело даних зі стандартних налаштувань магазину PrestaShop або ввести значення вручну в модулі. Ручна назва організації є обов’язковою мовою за замовчуванням, якщо вибрано ручне джерело ідентифікації. Ручна електронна адреса перевіряється як адреса електронної пошти.

Після заповнення модуль може передати юридичну назву, альтернативні назви, опис, логотип, зображення, адресу, електронну пошту, телефон, профілі sameAs, NIP, VAT ID, код ISO 6523, GLN і дату заснування. Також можна додати контактні пункти. Порожні дані не є корисною підставою для їх додавання, тому слід публікувати лише актуальну інформацію.

Так. У розширеній конфігурації організації доступні повторювані рядки політик повернення, послуг доставки та рівнів програми лояльності. Рядки проходять валідацію перед збереженням. Умови мають відповідати фактичним правилам магазину, оскільки модуль не отримує їх автоматично з регламенту або від перевізника.

LocalBusiness використовується для опису реальної точки діяльності або локального обслуговування. Може містити назву, адресу, контактні дані, тип діяльності, години роботи, координати, карту, зону обслуговування, дані про оплату та валюти, а також зображення. Не слід включати цю схему для вигаданої адреси або точки, якої не існує.

Так. Розширена конфігурація дає змогу додати багато філій; кожен рядок стає окремою сутністю LocalBusiness із власним стабільним ідентифікатором. Філія може перевизначити, зокрема, назву, адресу, контактні дані, координати, адресу мапи та адресу сторінки. Якщо ви не додасте філії, модуль використовує дані розташування за замовчуванням.

Активний LocalBusiness із ручним джерелом адреси вимагає вулицю, місто, поштовий індекс і дволітерний код країни ISO. Код країни перевіряється щодо країн, доступних у PrestaShop. Якщо вибрано джерело даних магазину, модуль використовує відповідні налаштування конкретного магазину.

Так. Модуль зберігає поля годин для окремих днів тижня, а розширена конфігурація дозволяє додавати рядки з днями, годиною відкриття і закриття, а також датами дії. Діапазон дат використовується, наприклад, для опису сезонних або виняткових годин. Години повинні мати правильний формат.

Створення Product або ProductGroup потрібно увімкнути. Модуль формує дані лише для активного товару, пов’язаного з поточним магазином і доступного для поточного клієнта. Сторінка товару має правильно оброблятися PrestaShop і темою.

Якщо товар має доступні комбінації, що вкладаються в ліміт варіантів, модуль створює ProductGroup з hasVariant. В іншому разі формується окремий Product. Таке обмеження захищає сторінку від дуже великого графа та надмірної кількості зчитувань для товару з численними комбінаціями.

Значення конфігурації за замовчуванням становить 100 комбінацій на магазин. Адміністратор може змінити його, але модуль технічно обмежує значення максимумом у 250. Після перевищення ліміту повний ProductGroup з hasVariant не будується.

Залежно від доступності модуль використовує назву, опис, категорію, усі зображення, SKU, MPN, EAN-13, UPC, виробника, ціну, валюту, наявність, стан, масу та розміри. Також він передає дату закінчення дії ціни, якщо вона випливає з поточних правил ціноутворення товару або комбінації. Порожні або невідповідні дані не слід штучно заповнювати лише заради розмітки.

Пропозиція додається тоді, коли магазин не працює в режимі каталогу, товар можна замовити, а ціна відображається на сторінці. Пропозиція може містити ціну, валюту, наявність, стан, продавця, ціну за одиницю, а також налаштовані дані доставки та повернення. Модуль не створює пропозицію для товару, який магазин не надає для покупки.

Builder перевіряє правильність підтримуваних номерів GTIN, зокрема довжину та контрольну цифру. EAN-13 і UPC використовуються лише тоді, коли проходять цю валідацію. Модуль не присвоює номери GTIN і не замінює правильні каталожні дані виробника.

Кожен опублікований варіант пов’язаний з ідентифікатором комбінації PrestaShop. Якщо генератор адрес повертає ту саму канонічну адресу для всіх комбінацій, модуль додає або оновлює параметр id_product_attribute. Завдяки цьому дані варіанта та його пропозиція вказують на вибрану комбінацію.

Так. У конфігурації можна призначити групи атрибутів до властивостей Schema.org, наприклад color або size. Непризначені осі варіантів можуть бути описані як additionalProperty з публічною назвою групи атрибутів. Зіставлення слід адаптувати до фактичного значення атрибута в каталозі.

Так. Модуль дозволяє зіставляти характеристики товару з additionalProperty, material, pattern, сертифікатами та даними про споживання енергії. Також можна передати ціну за одиницю, якщо товар має одиницю та коефіцієнт, що дають змогу її обчислити. Властивості повинні походити з фактично заповнених даних товару.

Модуль передає сукупну оцінку та список відгуків лише тоді, коли в розпізнаній інтеграції доступні затверджені дані відгуків про товар. Він не створює оцінки чи відгуки самостійно. Публікація даних повинна відповідати відгукам, які фактично видимі та доступні в магазині.

Послуги доставки та політики повернення можна налаштувати на рівні Organization. Якщо товар не має власної політики повернення, його пропозиція може посилатися на політики повернення організації; деталі доставки додаються безпосередньо до пропозиції лише після ввімкнення та повного заповнення перевизначення доставки товару. Модуль не обчислює вартість доставки для конкретного кошика і не синхронізує правила магазину автоматично.

Так, після ввімкнення BreadcrumbList модуль використовує видиму навігацію «хлібних крихт». Якщо її немає в даних сторінки, він підтримує, зокрема, товар, категорію, виробника, постачальника, CMS і розпізнані сторінки блогу. Некоректні елементи без назви або адреси HTTP(S) пропускаються.

WebSite публікується на головній сторінці магазину після ввімкнення цієї сутності. Може містити назву, опис, альтернативні назви, мову, профілі sameAs і посилання на організацію як видавця. Модуль не додає застарілий SearchAction.

Окрім загальної WebPage, доступні перемикачі CheckoutPage для підтримуваних контролерів замовлення, ContactPage для сторінки контактів, а також SearchResultsPage для сторінки пошуку. Модуль підбирає тип сторінки до контролера та отримує її поточні метадані. Кожна з цих схем потребує ввімкнення в конфігурації.

Так, інтеграція Article охоплює ph_simpleblog на контролері single та smartblog на контролері details. Модуль може передавати заголовок, опис, зображення, дату публікації, дату зміни та автора, доступного в даних видимого запису. Інші системи блогів не підтримуються автоматично цією інтеграцією.

CollectionPage може бути побудована для категорії, виробника, постачальника, новинок, знижених цін і бестселерів. До списку потрапляють товари, видимі на поточній сторінці, які мають назву та URL-адресу. Ліміт елементів встановлює адміністратор у діапазоні від 1 до 200, а значення за замовчуванням — 50.

FAQPage не будується з довільного тексту або лише з самого файлу імпорту. Модуль зчитує лише масив запитань і відповідей, переданий поточною відрендереною сторінкою до Smarty як pd_faqs, product_faqs або faqs. Запитання та відповідь мають бути непорожніми, щоб їх було додано до FAQPage.

Ні. Файл faq.json має формат імпорту запитань і відповідей для системи FAQ, а pdschemaorgpro не зчитує його безпосередньо під час генерування JSON-LD. Щоб було створено FAQPage, запитання мають бути імпортовані або введені у використовуваній системі FAQ і фактично передані та видимі на відповідній сторінці.

Так. Налаштування конфігурації зберігаються в контексті магазину, тому окремі магазини можуть мати власні дані організації, місцезнаходження, товарів і торгових правил. Перед збереженням слід перевірити активний контекст магазину в панелі PrestaShop.

Так. Валідація охоплює залежно від розділу, зокрема, обов’язкові поля, електронні адреси, коди країн ISO, адреси HTTP(S), невід’ємні числа, діапазони, години та рядки повторюваних даних. Некоректні дані повідомляються в панелі конфігурації. Однак валідація формату не підтверджує, що бізнес-інформація є правдивою.

Так. Панель адміністрування містить попередній перегляд згенерованого JSON-LD, підготовленого на основі поточної конфігурації. Попередній перегляд полегшує контроль налаштувань, але остаточну перевірку слід виконати на опублікованій сторінці відповідного магазину, оскільки частина даних залежить від контексту сторінки, товару, списку або FAQ.

Модуль містить інструменти для створення резервної копії та очищення виявлених застарілих фрагментів JSON-LD з файлів теми або модулів. Також він дає змогу відновити вибрані дані з архіву. Операцію слід виконувати свідомо після перевірки копії та діапазону файлів, оскільки вона стосується наявної реалізації магазину.

Ні. Модуль генерує розмітку JSON-LD на сторінках магазину; не надсилає адреси до індексу, не публікує дані через API Google і не підключається до Search Console. Можливий моніторинг індексації або валідація в зовнішніх інструментах залишаються поза межами модуля.

Модуль дає змогу передавати структуровані локальні дані, такі як назва, повна адреса, телефон, координати, карта, години роботи, зона обслуговування та офіційні профілі. Для GEO ключовою є відповідність цих даних реальній компанії та вмісту сторінки. Сам розмітка не гарантує цитування системами AI або видимості у згенерованих відповідях.

Версія 1.3.6 декларує сумісність із PrestaShop від 1.7.0.0 до 9.99.99. Необхідна версія PHP також залежить від використовуваної версії PrestaShop та її серверного середовища. Після встановлення або оновлення слід перевірити результат на реальних сторінках і у використовуваній темі.

Відгуки (1)

1 Відгуки
Działa zgodnie z opisem polecam.
Potwierdzam działa zgodnie z dokumentacja Schema.org dla produktów, sklepu, organizacji, itd.
за Shopstar на 2026-01-29