JSON-LD Schema.org: რომელი ტიპები ავირჩიო
ქეისი ერთ-ერთი პროექტიდან. ლენდინგი ხუთი კითხვით FAQ-სექციაში გვერდის ბოლოში. იჯდა Google-ში წელიწადნახევარი, იმპრესიები მოდიოდა, CTR დაახლოებით 1,8% — სტანდარტული კომერციული მოთხოვნისთვის მეხუთე პოზიციაზე.
დავამატე FAQPage schema. უბრალოდ შევფუთე იგივე ხუთი კითხვა და პასუხი JSON-LD ბლოკში, ჩავსვი <head>-ში. ტექსტს გვერდზე არ შევხებივარ, ერთ ასოსაც კი.
სამ კვირაში Google-მა SERP-ში დაიწყო ამ კითხვების აკორდეონის ჩვენება პირდაპირ snippet-ის ქვეშ. გასაშლელი პლუსები, პასუხები ჩანდა კლიკის გარეშე. ჯერ მხოლოდ ერთ მოთხოვნაზე, შემდეგ სამზე, შემდეგ შვიდზე. CTR თვის განმავლობაში 1,8%-დან 3,9%-მდე გაიზარდა. პოზიცია არ შეცვლილა — მეხუთე როგორც მეხუთე. უბრალოდ snippet-მა გამოშვებაში სამჯერ მეტი ადგილი დაიჭირა.
ეს არის rich results. Google შენს გვერდს გამოშვებაში სხვანაირად რენდერავს, ვიდრე მეზობლებს — შეფასებების ვარსკვლავები, ბარათი ნაბიჯებით, კითხვების აკორდეონი, breadcrumbs გრძელი URL-ის ნაცვლად. და ყველაფერი, რაც საჭიროა — სწორად მოვნიშნოთ კონტენტი schema.org-ით, რომ Google-მა გაიგოს, რა გაქვს გვერდზე და დათანხმდეს ამის განსაკუთრებული გზით ჩვენებაზე.
Schema.org — ეს არ არის პირდაპირ რანჟირებაზე. ეს არის იმაზე, თუ როგორ გაჩვენებენ, როცა უკვე გამოშვებაში ხარ. და იმაზე, რომ Google-მა საერთოდ გაიგოს, რა გაქვს გვერდზე — არ გამოიცნოს, არამედ ზუსტად იცოდეს.
რა არის Schema.org და JSON-LD
Schema.org — ეს არის სემანტიკური მარკაპის ტიპებისა და თვისებების საერთო ლექსიკონი ვებისთვის. შექმნილია 2011 წელს Google-ის, Microsoft-ის, Yahoo-ს და Yandex-ის ერთობლივად. ამჟამად შეიცავს დაახლოებით 800 ტიპს: Person, Organization, Article, Product, Event, Recipe, Movie, MusicAlbum, MedicalCondition — ყველა არსებით მოვლენაზე, რომელიც შეიძლება იყოს გვერდზე, არის თავისი ტიპი თავისი თვისებების ნაკრებით.
არსებობს მარკაპის სამი ფორმატი: Microdata, RDFa და JSON-LD. Microdata და RDFa ჩაშენებულია HTML-თეგებში ატრიბუტებით itemprop, itemscope, property — ანუ ნიშნავენ თვით კონტენტს ადგილზე. JSON-LD — ეს არის ცალკე <script type="application/ld+json"> ბლოკი, რომელიც არ ერევა HTML-ში. უბრალოდ სუფთა JSON, რომელიც აღწერს გვერდს პარალელურად.
Google ოფიციალურად რეკომენდაციას უწევს JSON-LD-ს. სამი მიზეზია. პირველი: ადვილია მხარდაჭერა — მარკაპი არ არის მიბმული HTML-ის სტრუქტურასთან, შეგიძლია შეცვალო ვერსტა schema-ს გატეხვის გარეშე. მეორე: შესაძლებელია პროგრამული გენერაცია — Next.js-ში ან ნებისმიერ სხვა ფრეიმვორკში ჩაისმის metadata API-ით ან dangerouslySetInnerHTML-ით. მესამე: ადვილია ვალიდაცია — Google Rich Results Test ზუსტად JSON-LD ბლოკებს კითხულობს.
Schema-ს გარეშეც Google მაინც გაიგებს, რა გაქვს გვერდზე. მან იცის ჩვეულებრივი HTML-ის წაკითხვა, ხედავს H1-ს, ხედავს ფასებს, ხედავს თარიღებს. მაგრამ ის გამოიცნობს. schema-სთან ერთად ის არ გამოიცნობს — ის ზუსტად იცის. ეს არის Product ბლოკი price: 1990-ით, availability: InStock-ით, brand: Apple-ით. ყოველგვარი ორაზროვნების გარეშე.
და მთავარი — მხოლოდ სწორი schema-ით Google-ს აქვს უფლება აჩვენოს rich results: შეფასებების ვარსკვლავები შედეგის ქვეშ, FAQ-აკორდეონი, HowTo ბარათი, breadcrumbs SERP-ში, ვიდეოს preview. მარკაპის გარეშე ეს არ იქნება იდეალურ გვერდზეც კი.
რომელი ტიპები მივცეთ თითოეულ გვერდს
Website — მთავარზე. ერთი sitewide ბლოკი, აღწერს თვით საიტს: სახელი, URL, პოტენციურად SearchAction — თუ გაქვს საკუთარი ძებნა საიტზე, Google-მა შეიძლება გამოიყვანოს ის პირდაპირ SERP-ში როგორც „search box". ეს ბლოკი ისმება ერთხელ მთავარზე, არ დუბლირდება სხვა გვერდებზე.
Organization — sitewide, ყველა გვერდზე. კომპანიის სახელი, ლოგო (სურათის URL მინიმუმ 112×112 პიქსელი), საკონტაქტო მონაცემები, sameAs — ბმულების მასივი შენს სოცქსელებზე და პროფილებზე (Twitter, LinkedIn, Facebook, Wikipedia, Crunchbase). ეს არის საბაზო სიგნალი Knowledge Panel-ისთვის — იმ ბარათისთვის SERP-ის მარჯვნივ, რომელიც ბრენდით გამოჩნდება. Organization-ის გარეშე Google ვერ ხვდება, რომ შენი რამდენიმე დომენი და ანგარიში — ეს ერთი არსებაა.
BreadcrumbList — ყველა გვერდზე, რომელიც პირველ დონეზე ღრმაა. აღწერს გზას მთავარიდან მიმდინარე გვერდამდე: მთავარი → ბლოგი → კატეგორია → ეს სტატია. Google ამ გზას SERP-ში გრძელი URL-ის ნაცვლად რენდერავს — გამოიყურება უფრო სუფთად, იჭერს მეტ ადგილს, გამოირჩევა მეზობლებში. უმარტივესი schema-ტიპი და ერთ-ერთი ყველაზე შესამჩნევი გაუმჯობესება გამოშვებაში. უნდა იყოს ყველაფერზე, რაც არ არის მთავარი.
BlogPosting — ბლოგის სტატიებისთვის. ველები: headline (სათაური), author (Person ტიპით და ბმულით ავტორის პროფილზე), datePublished, dateModified, image (გარეკანის URL), wordCount, articleSection, keywords. ოპციურად speakable — მიუთითებს, რომელი ნაწყვეტების წაკითხვა შეუძლია ხმოვან ასისტენტს. BlogPosting-ის გარეშე Google ხვდება, რომ ეს სტატიაა, მაგრამ არ იცის, ვინ არის ავტორი და როდის განახლდა — ეს კი E-E-A-T სიგნალებია.
Article / NewsArticle — ზოგადი სტატიებისა და სიახლეებისთვის. Article — მშობელი ტიპი, BlogPosting და NewsArticle მისგან მემკვიდრეობით მიიღება. NewsArticle გამოიყენება საინფორმაციო პუბლიკაციებისთვის — ეს არის სიგნალი Google News-ისთვის. თუ Google News-ში არ ხარ რეგისტრირებული — ჩვეულებრივ აყენე BlogPosting ან Article, NewsArticle-ს ნუ მოამარგებ.
FAQPage — გვერდებისთვის კითხვებითა და პასუხებით. ბლოკის შიგნით — Question-ების მასივი, თითოეულში acceptedAnswer Answer ტიპით. Google ამას რენდერავს როგორც გასაშლელ აკორდეონს SERP-ში. მუშაობს მხოლოდ მაშინ, თუ კითხვები რეალურად მსგავსია მომხმარებლისა — „რა არის X?", „რა ღირს Y?", „როგორ გავაკეთო Z?". მარკეტინგული „რატომ ვართ ჩვენ უკეთესები?" — Google უგულებელყოფს.
HowTo — ნაბიჯ-ნაბიჯ გზამკვლევებისთვის. შიგნით — HowToStep-ების მასივი, თითოეულზე text, image, ოპციურად name და url. დამატებით totalTime, tool, supply (ხელსაწყოები და მასალები). Google რენდერავს ბარათს ნაბიჯებითა და სურათებით პირდაპირ SERP-ში. მუშაობს მხოლოდ რეალურად ნაბიჯ-ნაბიჯ ინსტრუქციებზე — „როგორ შევცვალო ბატარეა", „როგორ მოვაწყო როუტერი". არა „10 რჩევას"-ის ტიპის სტატიებზე — იქ ნაბიჯების თანმიმდევრობა არ არის.
Product — საქონლისთვის. price, priceCurrency, availability (InStock / OutOfStock / PreOrder), brand, sku, gtin, condition. შიგნით — aggregateRating (საშუალო შეფასება და მიმოხილვების რაოდენობა) და review (ცალკეული მიმოხილვები). Google აჩვენებს ვარსკვლავებს, ფასს და ხელმისაწვდომობას პირდაპირ SERP-ში. e-commerce-ზე — ეს must-have-ია, Product schema-ს გარეშე საქონლის გვერდები გამოშვებაში გაცილებით ცუდად გამოიყურება, ვიდრე კონკურენტებთან.
Event — ღონისძიებებისთვის. startDate, endDate, location (Place ტიპით და მისამართით), performer, organizer, offers (ბილეთები ფასით). Eventstatus — EventScheduled / EventPostponed / EventCancelled / EventMovedOnline. Google რენდერავს ღონისძიების ბარათს SERP-სა და Google Events-ში, აჩვენებს თარიღს, ადგილს და ღილაკს ბილეთის შესაძენად.
VideoObject — ვიდეოსთვის. name, description, thumbnailUrl, uploadDate, duration, contentUrl ან embedUrl. Google აჩვენებს ვიდეოს preview-ს SERP-ში ხანგრძლივობის დროით. მუშაობს იმ შემთხვევაშიც, თუ ვიდეო YouTube-ზე არ არის ატვირთული — საკუთარ CDN-ზე, Vimeo-ზე, სადაც გინდა. VideoObject-ის გარეშე Google შეიძლება საერთოდ ვერ მიხვდეს, რომ გვერდზე ვიდეოა.
WebApplication / SoftwareApplication — ონლაინ-ხელსაწყოებისა და აპლიკაციებისთვის. applicationCategory, operatingSystem, offers (ფასი ან freemium), featureList, aggregateRating. Google ხვდება, რომ შენ არ გაქვს სტატია, არამედ ხელსაწყო — და აჩვენებს შესაბამის სიგნალებს. ვიყენებ ჩემი ყველა SaaS-გვერდისთვის ინტერაქტიული ჩეკერებით.
Person — ავტორის გვერდებისა და about-გვერდებისთვის. name, image, jobTitle, worksFor, sameAs (ბმულები ავტორის პროფილებზე სოცქსელებში, LinkedIn-ში, Twitter-ში). ეს არის E-E-A-T სიგნალი: Google-მა იცის, ვინ არის ავტორი, ვინ მუშაობს, სად შეიძლება მისი პოვნა. აკავშირებ Person-ს BlogPosting-ის author-თან — იღებ დაკავშირებულ გრაფს ავტორი-სტატიები.
Review / AggregateRating — მიმოხილვები. Review — ცალკეული მიმოხილვა reviewBody-ით, ratingValue-ით, author-ით და datePublished-ით. AggregateRating — აგრეგირებული შეფასება ratingValue-ით და reviewCount-ით. Google აჩვენებს ვარსკვლავებს შედეგის ქვეშ SERP-ში. მუშაობს საქონელზე, მომსახურებაზე, რეცეპტებზე, წიგნებზე, ფილმებზე. არ მუშაობს „საშუალოდ საიტზე" — საჭიროა მიბმა კონკრეტულ გვერდთან კონკრეტული შესაფასებელი კონტენტით.
გავრცელებული შეცდომები
Schema არ შეესაბამება ხილულ კონტენტს. ყველაზე საშიში შეცდომა. შენ მონიშნე FAQPage ხუთი კითხვით, მაგრამ გვერდზე ეს კითხვები დამალულია, ან საერთოდ არ არის, ან სხვა ტექსტითაა დაწერილი. Google ამას წაიკითხავს. თუ შეუსაბამობა სისტემურია — მოდის manual action: „სტრუქტურირებული მონაცემები არ შეესაბამება კონტენტს". Snippet-ები ითიშება მთელ დომენზე. აღდგენას თვეები სჭირდება. წესი მარტივია: schema-ში ზუსტად ის, რასაც მომხმარებელი ხედავს გვერდზე. არც მეტი, არც ნაკლები.
დუბლები სხვადასხვა @id-თ. ერთ გვერდზე ორი Organization ბლოკი სხვადასხვა @id-ით. ერთი header.tsx-დან, მეორე layout.tsx-დან, დაგავიწყდა ძველის წაშლა. Google ხედავს, რომ საიტს თითქოს ორი სხვადასხვა ორგანიზაცია აქვს, იბნევა, შეიძლება ორივე უგულებელყოს. შეამოწმე Rich Results Test-ით — ის აჩვენებს ყველა ნაპოვნ ბლოკს. უნდა იყოს ერთი Organization, ერთი Website, ერთი Article — თითო თითოეული ტიპის.
გატეხილი JSON. ზედმეტი მძიმე ბოლო ველის შემდეგ, დაუხურავი ფრჩხილი, არასწორი ტიპის ბრჭყალები. JSON იშლება მთლიანად, არა ნაწილი — Google ვერ პარსავს ბლოკიდან არაფერს. განსაკუთრებით სასაცილოა, როცა JSON-LD-ს ცვლადებიანი შაბლონით სვამ — ერთი არაეკრანირებული ბრჭყალი სტატიის title-ში და ბლოკი მკვდარია. ყოველთვის გაიარე ვალიდაცია https://search.google.com/test/rich-results-ით ჩასწორების შემდეგ.
FAQPage მარკეტინგული „კითხვებით". „რატომ ღირს ჩვენი არჩევა?", „რა უპირატესობებია?", „რა გვაქცევს განსაკუთრებულად?" — Google ამას ხედავს და არ აჩვენებს. ალგორითმი სპეციალურადაა გაწვრთნილი მარკეტინგის გამოსაკვეთად. FAQPage მუშაობს, როცა კითხვები ჰგავს იმას, რასაც მომხმარებელი რეალურად ბეჭდავს ძებნაში: „რა ღირს მიერთება?", „რამდენი დრო სჭირდება მიწოდებას?", „შესაძლებელია საქონლის დაბრუნება?". საინფორმაციო, კონკრეტული, ერთ თემაზე.
HowTo არა ნაბიჯ-ნაბიჯ გზამკვლევზე. Google რენდერავს HowTo-ს ბარათად ნაბიჯებით — ამიტომ მოითხოვს, რომ ნაბიჯები მართლაც თანმიმდევრული და დამოუკიდებელი იყოს. „SEO-ს 10 რჩევა" — ეს არ არის HowTo, ეს სიაა. „როგორ მოვაწყო SSL-სერთიფიკატი" ხუთი ნაბიჯით — ეს HowTo-ა. თუ HowTo-ს რჩევების სიაზე გადააფარებ — Google ან უგულებელყოფს, ან უარეს შემთხვევაში manual action-ს გასცემს შეცდომაში შემყვან მარკაპზე.
Schema სტატიებზე author-ისა და datePublished-ის გარეშე. BlogPosting ავტორის გარეშე — ეს არ არის BlogPosting. Google ამას ვალიდურ სტატიად არ თვლის, არ აჩვენებს Top Stories-ში, არ ითვალისწინებს E-E-A-T სიგნალად. მინიმუმი: headline, author (Person name-ით), datePublished, image. ამ ოთხი ველის გარეშე ბლოკი უსარგებლოა.
როგორ დავამატოთ და შევამოწმოთ
JSON-LD — ეს არის inline <script type="application/ld+json">, რომელიც ისმება <head>-ში ან <body>-ში. Google ორივეგან პარსავს, ეფექტში სხვაობა არ არის. ჩვევით აყენებენ <head>-ში, რადგან ეს მეტამონაცემებია.
Next.js-ში ორი გზაა. პირველი — metadata API, App Router-დან დაწყებული. layout.tsx-ში ან page.tsx-ში ექსპორტი გააქვს ობიექტი metadata, მასში შეგიძლია დაამატო ბლოკი other → JSON-LD. მოსახერხებელია ტიპური შემთხვევებისთვის — Organization, Website. მეორე — dangerouslySetInnerHTML-ით თვით გვერდზე. ქმნი JS-ობიექტს, აკეთებ JSON.stringify-ს, სვამ <script>-ში. მოსახერხებელია დინამიური schema-სთვის — BlogPosting კონკრეტული სტატიისთვის, Product კონკრეტული საქონლისთვის, FAQPage CMS-ის მონაცემებით.
დამატების შემდეგ — სავალდებულო შემოწმება. ორი ხელსაწყო:
— Google Rich Results Test — https://search.google.com/test/rich-results. სვამ URL-ს ან ნედლ კოდს. Google აჩვენებს, რომელი ტიპები იპოვა, რომელი ველებია ვალიდური, რომელი rich results-ია ხელმისაწვდომი ამ გვერდისთვის. თუ ჩვენებს „No items detected" — schema ან არ ჩაიტვირთა, ან არავალიდურია.
— Schema.org Validator — https://validator.schema.org. უფრო მკაცრი, ამოწმებს თვით schema.org-ის სპეციფიკაციასთან შესაბამისობას. გამოსადეგია, როცა აყენებ ეგზოტიკურ ტიპს, რომელსაც Google ჯერ არ უჭერს მხარს rich results-ისთვის, მაგრამ რომელიც სემანტიკურად კორექტულია.
გამოქვეყნების შემდეგ — მონიტორინგი Google Search Console-ში. სექცია Performance → Search Appearance. Google ყოფს შენს იმპრესიებს snippet-ის ტიპის მიხედვით: ჩვეულებრივი ტექსტი, FAQ rich result, HowTo rich result, sitelinks. ჩანს, რომელი ტიპები რეალურად მუშაობს, რომელი — არ იძლევა ეფექტს. თუ დაამატე FAQPage და ორი თვის შემდეგ Search Appearance-ში არ გამოჩნდა „FAQ rich result" — ნიშნავს, Google-მა შენი მარკაპი არ მიიღო, ან კითხვებმა ხარისხის ფილტრი ვერ გაიარა.
შედეგი
პრიორიტიზაცია CTR-სა და მოცვაზე ეფექტის მიხედვით:
- BreadcrumbList — ყველაფერზე, რაც არ არის მთავარი. უმარტივესი ტიპი, შესამჩნევი ეფექტი SERP-ში, არანაირი რისკი. თუ schema არსად არ გაქვს — ამით დაიწყე.
- Organization და Website — sitewide. ერთხელ მოაწყვე, მუშაობს მთელ საიტზე. საბაზო სიგნალი Knowledge Graph-ისთვის და ბრენდ-გამოშვებისთვის.
- BlogPosting / Product / Event — per-page. შესაბამისი ტიპის თითოეულ გვერდზე. ეს არის E-E-A-T სტატიებისთვის და rich results საქონლისა და ღონისძიებებისთვის.
- FAQPage — სადაც შესაფერისია. თუ რეალურად გაქვს FAQ-ბლოკი მომხმარებლის კითხვებით. ნუ აიძულებ აკორდეონის გულისთვის.
- HowTo — მხოლოდ რეალურ ნაბიჯ-ნაბიჯ გზამკვლევებზე. ყველაზე მკაცრი ტიპი ხარისხის თვალსაზრისით, მაგრამ ყველაზე შესამჩნევი rich result.
- VideoObject, Review, Person — წერტილოვნად. კონკრეტული კონტენტისთვის: ვიდეო-გვერდები, მიმოხილვები, ავტორის გვერდები.
Schema.org — ეს არის იმის მართვა, როგორ ხედავს და აჩვენებს Google შენს საიტს. თავისთავად schema ტოპ-10-ში არ წაგიყვანს. მაგრამ როცა ტოპ-10-ში ხარ — schema ზრდის CTR-ს rich results-ის ხარჯზე, და ზოგადი პოზიცია 3-6 თვის შემდეგ უკვე ამ სიგნალზე იზრდება. ეს არის ერთ-ერთი SEO 2026-ის 30 ფაქტორიდან, რომელსაც აფასებენ ნაკლებად. ყველა იწვალებს meta description-ით და canonical-თეგებით, ავიწყდებათ, რომ rich results — ეს არის +50-200% snippet-ის ხილვადობაში გამოშვებაში, იმავე პოზიციაზე.
დაიწყე BreadcrumbList-ით და Organization-ით. დაამატე BlogPosting სტატიებზე. შემდეგ — სიტუაციის მიხედვით.