რა არის სტრუქტურირებული მონაცემები? Schema Markup მარტივად

სტრუქტურირებული მონაცემები არის მცირე კოდის ბლოკი ვებგვერდზე, რომელიც ხილულ შინაარსს სტანდარტულ ფორმატში ახასიათებს საძიებო სისტემებისთვის — მაგალითად: „ეს გვერდი არის პროდუქტი სახელად Lavender Candle, მისი ღირებულებაა $24 და მარაგში გაქვთ.“ Google-ის აღწერით, ეს არის სტანდარტიზებული ფორმატი, რომელიც გვერდის შესახებ ინფორმაციას აწვდის და მის შინაარსს აკლასიფიცირებს. სწორად გაკეთებული, ის ეხმარება საძიებო სისტემებს გვერდის გაგებაში და შეუძლია გვერდი გახადოს შესაფერისი უფრო მდიდარი შედეგებისთვის, როგორიცაა ფასები, რეიტინგები ან ივენთების თარიღები, რომლებიც პირდაპირ შედეგის ქვეშ ჩანს.

რატომ არის მნიშვნელოვანი AI-ით აშენებისას

საძიებო სისტემები კარგად კითხულობენ გვერდებს, მაგრამ მაინც უწევთ გამოცნობა. „24“ არის ფასი, რაოდენობა თუ თარიღი? „Riverside Hall“ არის ადგილი თუ ადამიანის სახელი? სტრუქტურირებული მონაცემები ამ გამოცნობას აშორებს.

AI-ით აგებული საიტებისთვის ორი პრაქტიკული საკითხია:

• ეს არის კოდი, არა შინაარსი, ამიტომ მარტივად დავიწყებულია. AI-ბილდერი ჩვეულებრივ არ დაამატებს მას, სანამ არ სთხოვთ, და როცა დაამატებს, ის უნდა შეესაბამებოდეს იმას, რაც გვერდზე რეალურად ჩანს.
• მარტივია შეცდეს ისე, რომ სწორად გამოიყურებოდეს. AI შეიძლება გამოიგონოს ხუთვარსკვლავიანი რეიტინგი, დაამატოს მარკაპი შინაარსისთვის, რომელიც არ ჩანს, ან გამოიყენოს ტიპი, რომელსაც Google აღარ აჩვენებს. Google-ის წესები მკაცრია სიზუსტეზე, და შეცდომაში შემყვანი მარკაპი შეიძლება უგულებელყოფილი ან დასჯილი იყოს.

მცირე, ზუსტი და თქვენს რეალურ შინაარსთან შესაბამისი სტრუქტურირებული მონაცემები ღირს ქონას. ბევრი გამოგონილი მარკაპი კი უარესია, ვიდრე არცერთი.

ყოველდღიური ანალოგია

წარმოიდგინეთ პროდუქტი სუპერმარკეტში. შეფუთვას აქვს ფერადი დიზაინი და სარეკლამო ტექსტი — ეს არის თქვენი ვებგვერდი ისე, როგორც ადამიანები ხედავენ. მაგრამ უკანა მხარეს არის სტანდარტული კვების ეტიკეტიც: იგივე ველები, იგივე თანმიმდევრობით, ყველა პროდუქტზე. მის სწრაფად წაკითხვა და პროდუქტების შედარება ნებისმიერს შეუძლია.

სტრუქტურირებული მონაცემები თქვენი გვერდის კვების ეტიკეტია. დიზაინი შეიძლება იყოს ნებისმიერი; ეტიკეტი სტანდარტიზებულია, რათა მანქანებმა მას საიმედოდ წაიკითხონ. და კვების ეტიკეტივით, ისიც უნდა იყოს გულწრფელი იმის შესახებ, რაც შიგნითაა.

როგორ მუშაობს სტრუქტურირებული მონაცემები

სტრუქტურირებულ მონაცემებს ორი ნაწილი აქვს:

1. ლექსიკონი — სიტყვები, რომლითაც საგნები აღიწერება. ყველაზე გავრცელებულია schema.org, საერთო ლექსიკონი ისეთი ტიპებით, როგორიცაა Product, LocalBusiness, Event, Article, Recipe და Organization, და თვისებებით, როგორიცაა name, price, address და startDate.
2. ფორმატი — როგორ იწერება ეტიკეტები გვერდში. Google სამ ფორმატს უჭერს მხარს: JSON-LD, Microdata და RDFa. ის გვირჩევს JSON-LD-ს, რომელიც არის JSON ბლოკი <script> ტეგში, ხილული HTML-ისგან გამოყოფილად.

საძიებო სისტემები კითხულობენ ბლოკს, იგებენ გვერდზე არსებულ ობიექტებს და — თუ გვერდი აკმაყოფილებს მოთხოვნებს — შეიძლება აჩვენონ rich result: საძიებო ჩანაწერი დამატებითი დეტალებით.

სამუშაო მაგალითი: სანთლების მაღაზიის პროდუქტის გვერდი

თქვით, რომ აშენებთ ონლაინ მაღაზიას და ერთი გვერდი ყიდის ლავანდის სანთელს. ხილულ გვერდზე ჩანს სახელი, ფოტო, აღწერა, ფასი ($24.00) და „მარაგშია“.

ამ გვერდის JSON-LD შეიძლება ასე გამოიყურებოდეს:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Lavender Soy Candle",
  "image": "https://www.examplecandles.com/images/lavender.jpg",
  "description": "Hand-poured soy candle with lavender essential oil. Burns for about 40 hours.",
  "sku": "CAN-LAV-01",
  "brand": { "@type": "Brand", "name": "Example Candles" },
  "offers": {
    "@type": "Offer",
    "url": "https://www.examplecandles.com/candles/lavender",
    "price": "24.00",
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock"
  }
}

ის მოთავსებულია HTML-ში <script type="application/ld+json">…</script> ტეგის შიგნით.

ნახეთ, რა არ არის აქ: aggregateRating არ არის, რადგან მაღაზია გვერდზე შეფასებებს არ აჩვენებს. რეიტინგის დამატება, რომელსაც ვიზიტორები ვერ ხედავენ, Google-ის წესებს არღვევს.

ახლა იგივე მაღაზიის საკონტაქტო გვერდს შეუძლია აღწეროს თავად ბიზნესი:

{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "Example Candles",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "12 Market Street",
    "addressLocality": "Bristol",
    "postalCode": "BS1 1AA",
    "addressCountry": "GB"
  },
  "telephone": "+44 117 000 0000",
  "openingHours": "Mo-Sa 10:00-17:00"
}

ისევ, თითოეული მნიშვნელობა ემთხვევა იმას, რაც გვერდზე ჩანს.

შემოწმება. ჩასვით ცოცხალი URL Google-ის Rich Results Test-ში, რათა ნახოთ, აკმაყოფილებს თუ არა გვერდი Google-ის rich results-ის მოთხოვნებს და ხომ არ აკლია რამე სავალდებულო. ზოგადი schema.org შემოწმებისთვის გამოიყენეთ Schema Markup Validator. გაშვების შემდეგ Search Console აჩვენებს შეცდომებს მთელ საიტზე.

წესები, რომლებიც სასარგებლოა ცოდნად

Google-ის სტრუქტურირებული მონაცემების დოკუმენტაციიდან:

• მარკირება მხოლოდ იმას, რაც მომხმარებელს ხილული აქვს. ნუ დაამატებთ სტრუქტურირებულ მონაცემებს ინფორმაციაზე, რომელიც გვერდზე არ ჩანს, მაშინაც კი, თუ ის ზუსტია.
• ჩართეთ სავალდებულო თვისებები. თითოეული rich result ტიპი ჩამოთვლის სავალდებულო ველებს; თუ რომელიმე აკლია, გვერდი არ აკმაყოფილებს მოთხოვნებს.
• შესაბამისობა არ არის გარანტია. სწორი მარკაპი გვერდს ხდის შესაბამისს rich result-ისთვის, მაგრამ არ იძლევა დარწმუნებას, რომ მას მიიღებს.
• Rich result-ის ტიპები იცვლება. Google ზოგიერთ ფუნქციას დროთა განმავლობაში წყვეტს. მაგალითად, მისი FAQ rich results შემოიფარგლებოდა კარგად ცნობილი სახელმწიფო და ჯანმრთელობის საიტებით, და Google აცხადებდა, რომ 2026 წლის მაისიდან ისინი საძიებოში აღარ გამოჩნდებოდა. სანამ კონკრეტული rich result-ისთვის ააწყობთ, შეამოწმეთ Google-ის მიმდინარე search gallery.
• ნუ შექმნით გვერდებს მხოლოდ მარკაპის შესანახად.

გამოყენებული ტერმინები

გავრცელებული შეცდომები და მცდარი წარმოდგენები

• „სტრუქტურირებული მონაცემები ზრდის რეიტინგებს.“ მისი მთავარი ღირებულებაა გაგება და rich result-ის შესაბამისობა, და არა რეიტინგის მალსახმობი გზა.
• შეფასებებისა და რეიტინგების გამოგონება. ყალბი ან დაუდასტურებელი რეიტინგები არღვევს Google-ის წესებს და ადამიანებს შეცდომაში შეჰყავს.
• მარკაპი, რომელიც გვერდს არ ემთხვევა. თუ JSON-LD-ში ფასია $24, გვერდზე კი $29, ეს პრობლემაა.
• ფარული შინაარსი. ვიზიტორებისთვის უხილავი ტექსტის მარკირება წესებს არღვევს.
• მარკაპის ყველა გვერდზე კოპირება. Product ბლოკი პროდუქტის გვერდებზე უნდა იყოს, მთავარ გვერდზე ან ბლოგზე არა.
• მოძველებული ფუნქციებისთვის აშენება. შეამოწმეთ, რომ rich result, რომელსაც ითხოვთ, ჯერ კიდევ არსებობს.
• მარკაპის დამატება მხოლოდ ბრაუზერში. თუ საიტი ყველაფერს JavaScript-ით ხატავს, Google შეიძლება მაინც იპოვოს, მაგრამ JSON-LD სერვერის მიერ გაგზავნილ HTML-ში ჩასმა უფრო საიმედოა.
• ტესტირების გამოტოვება. ერთი დაკარგული მძიმე მთელ ბლოკს არაწასაკითხს ხდის.

რა სთხოვოთ AI-ბილდერს

• „დაამატე JSON-LD სტრუქტურირებული მონაცემები schema.org ტიპებით, რომლებიც შეესაბამება თითოეულ გვერდს: Product პროდუქტის გვერდებზე, LocalBusiness საკონტაქტო გვერდზე, Article ბლოგის პოსტებზე.“
• „გენერირება მოახდინე მნიშვნელობებისთვის იმავე მონაცემებიდან, რომელსაც გვერდი აჩვენებს, რათა ისინი ყოველთვის ემთხვეოდეს.“
• „არ დაამატო რეიტინგები, შეფასებები ან ნებისმიერი თვისება, რომელიც გვერდზე არ ჩანს.“
• „ჩადე JSON-LD სერვერზე რენდერებულ ან წინასწარ რენდერებულ HTML-ში.“
• „ჩართე Google-ის rich result-ის ყველა სავალდებულო თვისება იმ ტიპისთვის და მითხარი, რომლები გამოიყენე.“
• „მომეცი URL-ების სია, რომლებიც Rich Results Test-ში უნდა შევამოწმო.“

რომ ნახოთ, სად ჯდება ეს დიდ სურათში, იხილეთ რა არის SEO, რა არის საიტის რუკა და ტექნიკური მიმოხილვა SEO AI-ით აშენებული ვებსაიტებისთვის.

სტრუქტურირებული მონაცემები Mythex-ში

Mythex სტრუქტურირებულ მონაცემებს ავტომატურად არ ამატებს; თქვენ ითხოვთ მას ჩატში, და აგენტი მას თქვენი აპის კოდში წერს. უთხარით, რომელი გვერდები წარმოადგენს პროდუქტებს, ივენთებს ან თქვენს ბიზნესს, და სთხოვეთ JSON-LD-ის გენერირება იმავე მონაცემებიდან, რომელსაც გვერდი აჩვენებს. დოკუმენტაციის რეცეპტი SEO თქვენი გამოქვეყნებული აპისთვის შეიცავს ფრაზას „Do not invent fake review schema“, რაც კარგი რჩევაა ყველა prompt-ში. რადგან ნაგულისხმევი დაყენება კლიენტის მხარეს რენდერებული single-page აპია, თუ SEO მნიშვნელოვანია, სთხოვეთ წინასწარ რენდერებული ან სტატიკურად მოსახერხებელი სტრუქტურა, შემდეგ გამოაქვეყნეთ და შეამოწმეთ ცოცხალი URL-ები.

კითხვები