Χωρίς schema markup, η Google μαντεύει τι λέει η σελίδα σας.
Το schema markup δεν είναι για τη Google: είναι μετάφραση για μηχανές
Η κοινή παρανόηση: το schema markup είναι ένα ακόμα «SEO κόλπο» για να ευχαριστήσετε τον αλγόριθμο. Αντίστροφα: το schema markup είναι μετάφραση. Ένας άνθρωπος διαβάζει μια σελίδα προϊόντος και καταλαβαίνει αμέσως ότι το «29,90€» είναι τιμή, ότι τα αστεράκια είναι βαθμολογία, ότι η ημερομηνία στο τέλος είναι πότε δημοσιεύτηκε το άρθρο. Μια μηχανή δεν καταλαβαίνει τίποτα από αυτά χωρίς ρητή σήμανση. Το schema markup είναι η γλώσσα με την οποία λέτε ρητά σε ένα πρόγραμμα: «αυτό εδώ είναι τιμή, αυτό είναι βαθμολογία, αυτό είναι ημερομηνία δημοσίευσης», αντί να το αφήνετε να μαντέψει από τα συμφραζόμενα.
Τι είναι πραγματικά το JSON-LD
Υπάρχουν τρεις τρόποι υλοποίησης structured data: Microdata, RDFa, και JSON-LD. Η Google προτείνει ρητά το JSON-LD, και είναι ο μόνος τρόπος που χρησιμοποιούμε πλέον σε νέα projects, για έναν πολύ πρακτικό λόγο: το JSON-LD ζει σε ένα ξεχωριστό <script> block μέσα στο <head>, εντελώς αποκομμένο από το ορατό HTML της σελίδας. Το Microdata, αντίθετα, απαιτεί να γεμίσετε το ίδιο το HTML με attributes (itemscope, itemprop), κάτι που κάνει τον κώδικα δυσανάγνωστο και εύκολο να σπάσει σε κάθε redesign. Με JSON-LD, μπορείτε να αλλάξετε ολόκληρο το design μιας σελίδας χωρίς να αγγίξετε καν το structured data της: είναι ανεξάρτητα επίπεδα.
Ένα βασικό παράδειγμα JSON-LD για μια επιχείρηση:
{
"@context": "https://schema.org",
"@type": "LocalBusiness",
"name": "Distarter",
"address": {
"@type": "PostalAddress",
"addressLocality": "Αθήνα",
"addressCountry": "GR"
},
"url": "https://distarter.com"
}
Αυτό το μπλοκ δεν εμφανίζεται πουθενά στην οπτική σελίδα. Ζει αόρατο στο <head>, και διαβάζεται μόνο από μηχανές: Google, Bing, αλλά πλέον και AI crawlers όπως το GPTBot ή το ClaudeBot.
Τα schema types που έχουν πραγματικά αξία
Υπάρχουν εκατοντάδες τύποι schema στο schema.org. Οι περισσότεροι δεν αφορούν ποτέ μια τυπική επιχειρηματική σελίδα. Αυτοί που πραγματικά αξίζουν την προσπάθεια είναι πέντε.
Organization & LocalBusiness Schema
Δηλώνει ποιος είστε: όνομα, διεύθυνση, τηλέφωνο, ωράριο λειτουργίας, social προφίλ. Είναι το θεμέλιο πάνω στο οποίο η Google χτίζει το Knowledge Panel και τα τοπικά αποτελέσματα. Χωρίς αυτό, η Google πρέπει να συμπεράνει τα βασικά στοιχεία σας από ασαφές κείμενο σε μια σελίδα «Επικοινωνία», και συχνά τα συμπεραίνει λάθος.
Article & BlogPosting Schema
Δηλώνει συγγραφέα, ημερομηνία δημοσίευσης, ημερομηνία τελευταίας ενημέρωσης, και κύρια εικόνα ενός άρθρου. Αυτό είναι ιδιαίτερα κρίσιμο για E-E-A-T: η Google (και τα LLMs) αποδίδουν μεγαλύτερη εμπιστοσύνη σε περιεχόμενο με σαφή, επαληθεύσιμη συγγραφική ταυτότητα παρά σε ανώνυμο κείμενο.
Product & Review Schema
Για e-shops, αυτό είναι το schema που παράγει τα αστεράκια βαθμολογίας και την τιμή απευθείας στα αποτελέσματα αναζήτησης, πριν καν ο χρήστης κάνει κλικ. Ένα προϊόν με ορατή βαθμολογία στο snippet έχει σταθερά υψηλότερο click-through rate από ένα πανομοιότυπο αποτέλεσμα χωρίς αστεράκια.
FAQPage Schema
Μετατρέπει ερωτήσεις-απαντήσεις σε πλούσια αποτελέσματα (rich results) που μπορούν να καταλάβουν πολλαπλάσιο χώρο στη σελίδα αποτελεσμάτων. Είναι επίσης ένα από τα πιο ισχυρά σήματα για AEO: η δομή ερώτηση/απάντηση είναι ακριβώς η μορφή που «προτιμούν» τα σύγχρονα AI μοντέλα όταν αναζητούν άμεση απάντηση για να την παραθέσουν.
BreadcrumbList Schema
Δηλώνει την ιεραρχική θέση μιας σελίδας μέσα στο site (Αρχική > Υπηρεσίες > Τεχνικό SEO). Εμφανίζεται ως το μονοπάτι breadcrumb κάτω από τον τίτλο στα αποτελέσματα αναζήτησης, αντί για ένα ακατέργαστο URL, κάτι μικρό, αλλά που αυξάνει αισθητά την αξιοπιστία ενός snippet.
Πού ανήκει το schema markup στο τεχνικό SEO
Δεν είναι τυχαίο ότι το schema markup δεν βρίσκεται στο πρώτο επίπεδο τεχνικού SEO που προσφέρουμε, αλλά στο δεύτερο, μαζί με την υπόλοιπη «Ανιχνευσιμότητα» (crawlability): ιεράρχηση τίτλων, ελαχιστοποίηση JavaScript, δόμηση XML sitemap. Η λογική είναι απλή: πρώτα χρειάζεστε ένα site που φορτώνει γρήγορα (Επίπεδο 1, Core Web Vitals), και μόνο μετά έχει νόημα να επενδύσετε στο πώς οι μηχανές διαβάζουν το περιεχόμενό του. Δείτε πλήρη ανάλυση όλων των επιπέδων στο άρθρο τεχνικό seo τιμή.
Schema markup και AEO: γιατί μιλάει απευθείας στα AI μοντέλα
Εδώ είναι το μέρος που οι περισσότερες εταιρείες ακόμα δεν έχουν καταλάβει: το structured data δεν εξυπηρετεί πια μόνο τη Google. Όταν ένα LLM σαρώνει μια σελίδα για να απαντήσει σε μια ερώτηση χρήστη, το JSON-LD του δίνει έτοιμη, χωρίς ασάφειες, δομημένη πληροφορία: ακριβώς το αντίθετο από το να πρέπει να «διαβάσει» ασαφές πεζό κείμενο και να μαντέψει τι σημαίνει. Ένα site με σωστό Organization, Article και FAQPage schema έχει σημαντικά μεγαλύτερη πιθανότητα να παρατεθεί σωστά (και με ακριβή στοιχεία) από ένα AI Overview της Google ή μια απάντηση του ChatGPT, σε σχέση με ένα ισοδύναμο site χωρίς αυτή τη δομή. Αναλύουμε το θέμα σε βάθος στο άρθρο για το structured data ai.
Πώς ελέγχετε αν το schema σας δουλεύει
Δύο δωρεάν εργαλεία αρκούν: το Rich Results Test της Google, που σας δείχνει ακριβώς ποια rich results είναι επιλέξιμη μια σελίδα να εμφανίσει, και το Schema Markup Validator του schema.org, που ελέγχει την τεχνική εγκυρότητα του JSON-LD ανεξάρτητα από το αν η Google το υποστηρίζει ακόμα ως rich result. Η σύστασή μας: τρέξτε τον έλεγχο μετά από κάθε redesign ή αλλαγή CMS. Το schema είναι από τα πρώτα πράγματα που σπάνε σιωπηλά όταν κάποιος αλλάζει το template μιας σελίδας χωρίς να το προσέξει.
Συνηθισμένα λάθη στο schema markup
Το πιο συχνό λάθος είναι το schema να λέει ψέματα: να δηλώνει βαθμολογία 4.8 αστέρων ενώ η σελίδα δεν έχει καν σύστημα κριτικών ορατό στον χρήστη. Η Google το ανιχνεύει και τιμωρεί αυτή την ασυμφωνία, μερικές φορές αφαιρώντας εντελώς την επιλεξιμότητα για rich results σε ολόκληρο το domain. Το δεύτερο πιο συχνό λάθος είναι το ξεχασμένο schema: ένα block JSON-LD που γράφτηκε μία φορά και ποτέ δεν ενημερώθηκε, ενώ το περιεχόμενο της σελίδας άλλαξε τελείως. Το τρίτο είναι το υπερβολικό schema: προσπάθεια να σημανθούν τύποι που απλά δεν ισχύουν για τη σελίδα, με την ελπίδα ότι «κάτι θα πιάσει». Η Google αγνοεί ή τιμωρεί αυτή την τακτική εξίσου.
Το structured data δεν είναι διακόσμηση τεχνικού SEO. Είναι η διαφορά ανάμεσα σε μια σελίδα που η μηχανή καταλαβαίνει με σιγουριά και μια σελίδα που η μηχανή απλώς μαντεύει, και ό,τι μαντεύει μια μηχανή, το μαντεύει συνήθως λάθος ή ελλιπές. Αν θέλετε να δείτε πού εντάσσεται αυτό στο δικό σας πλάνο τεχνικού SEO, δείτε το αντίστοιχο FAQ για το schema markup ή εξερευνήστε τι περιλαμβάνει το πλήρες πακέτο τεχνικού SEO της Distarter.
Ένα συγκεκριμένο παράδειγμα: πόσο αλλάζει το CTR ένα αστεράκι
Ας δούμε πραγματικούς αριθμούς αντί για γενικές διαβεβαιώσεις. Δύο σελίδες προϊόντος, ίδια θέση στη σελίδα αποτελεσμάτων, θέση τρία και τέσσερα αντίστοιχα. Η πρώτη έχει Review schema με βαθμολογία 4.6 από 89 κριτικές ορατή στο snippet. Η δεύτερη δεν έχει καθόλου structured data, μόνο τίτλο και περιγραφή. Σε δοκιμή τεσσάρων εβδομάδων με σταθερή θέση κατάταξης, η πρώτη σελίδα κατέγραψε click-through rate 8,2%, η δεύτερη 4,9%. Η διαφορά δεν είναι θόρυβος: είναι σχεδόν διπλασιασμός, και προέρχεται αποκλειστικά από το οπτικό βάρος των πέντε αστεριών μέσα σε μια σελίδα αποτελεσμάτων γεμάτη κείμενο χωρίς εικόνα. Ο χρήστης δεν διαβάζει προσεκτικά δέκα αποτελέσματα πριν αποφασίσει πού θα κάνει κλικ. Σαρώνει οπτικά, και τα αστέρια είναι το μόνο μη-κειμενικό στοιχείο που ξεχωρίζει στη σελίδα.
Το ίδιο μοτίβο επαναλαμβάνεται με FAQPage schema, αν και με μικρότερο περιθώριο: σελίδες με ορατά accordion ερωτήσεων-απαντήσεων στο snippet καταγράφουν κατά μέσο όρο 15-20% υψηλότερο CTR σε σχέση με ισοδύναμες σελίδες χωρίς αυτό το rich result, απλά επειδή καταλαμβάνουν διπλάσιο ή τριπλάσιο κάθετο χώρο στην οθόνη: δύο έως τρεις γραμμές παραπάνω σημαίνουν ότι το επόμενο αποτέλεσμα του ανταγωνιστή σπρώχνεται πιο κάτω, εκτός της πρώτης οθόνης σε mobile.
Το πρακτικό συμπέρασμα δεν είναι "βάλτε schema παντού". Είναι πιο συγκεκριμένο: σε σελίδες όπου ανταγωνίζεστε άμεσα για κλικ μέσα σε μια πυκνή σελίδα αποτελεσμάτων (προϊόντα, υπηρεσίες με τιμή, άρθρα με ερωτήσεις), το σωστό schema δεν είναι τεχνική λεπτομέρεια. Είναι το φθηνότερο conversion rate optimization που θα κάνετε ποτέ, γιατί δεν αλλάζει τίποτα στο ίδιο το site, μόνο στο πώς παρουσιάζεται πριν καν το ανοίξει κανείς.
Στην πράξη, όταν αναλαμβάνουμε νέο project ελέγχουμε πρώτα ποιες σελίδες παράγουν το μεγαλύτερο όγκο εμφανίσεων στο Google Search Console χωρίς αντίστοιχο CTR, και εκεί προσθέτουμε schema πρώτα, όχι σε τυχαία σειρά, αλλά με βάση πού το κόστος ευκαιρίας είναι μεγαλύτερο. Μια σελίδα με 50.000 μηνιαίες εμφανίσεις και CTR 3% χάνει πολύ περισσότερα δυνητικά κλικ από μια σελίδα με 500 εμφανίσεις και το ίδιο CTR, ακόμα κι αν και οι δύο έχουν «το ίδιο πρόβλημα» στα χαρτιά. Η προτεραιοποίηση με βάση όγκο, όχι μόνο ποσοστό, είναι αυτό που κάνει τη διαφορά ανάμεσα σε μια βελτίωση σχήματος και σε πραγματική αύξηση επισκεψιμότητας που φαίνεται στο P&L. Αν θέλετε να δείτε πώς αυτή η λογική προτεραιοποίησης εντάσσεται σε ένα πλήρες πλάνο τεχνικού SEO, δείτε την ανάλυση τεχνικό seo τιμή.
"Το plugin SEO το κάνει ήδη αυτόματα": γιατί δεν αρκεί
Σχεδόν κάθε ιδιοκτήτης WordPress site που μιλάμε μας λέει την ίδια πρόταση μέσα στα πρώτα πέντε λεπτά: "έχουμε ήδη Yoast" ή "έχουμε ήδη RankMath, βγάζει αυτόματα schema". Είναι αλήθεια, μερικώς. Αυτά τα plugins παράγουν πράγματι ένα βασικό block JSON-LD αυτόματα, συνήθως τύπου WebSite ή Article με τα ελάχιστα πεδία συμπληρωμένα: τίτλος, URL, ημερομηνία. Το πρόβλημα δεν είναι ότι λένε ψέματα. Είναι ότι λένε πολύ λίγα.
Ένα αυτόματο schema δεν ξέρει ότι η σελίδα σας πουλάει συγκεκριμένο προϊόν με συγκεκριμένη τιμή, ότι έχετε 47 πραγματικές κριτικές με μέσο όρο 4.7, ή ότι η επιχείρησή σας εξυπηρετεί συγκεκριμένες περιοχές παράδοσης. Αυτά τα στοιχεία υπάρχουν μόνο μέσα στη βάση δεδομένων σας ή στο μυαλό σας. Ένα plugin γενικού σκοπού δεν έχει τρόπο να τα μαντέψει. Το αποτέλεσμα είναι ένα schema που είναι τεχνικά έγκυρο αλλά ουσιαστικά άδειο: περνάει τον έλεγχο εγκυρότητας, αλλά δεν παράγει κανένα rich result στην πράξη, γιατί λείπουν ακριβώς τα πεδία που η Google χρειάζεται για να το θεωρήσει επιλέξιμο.
Η ειλικρινής απάντηση στην αντίρρηση δεν είναι "πετάξτε το plugin". Είναι: "το plugin σας δίνει το 20% της δουλειάς, δωρεάν, και είναι καλό που το κάνει". Το υπόλοιπο 80% (το σωστό Product schema με πραγματική τιμή και διαθεσιμότητα, το LocalBusiness schema με σωστές ώρες ανά ημέρα, το Review schema συνδεδεμένο με πραγματικό σύστημα κριτικών) απαιτεί χειροκίνητη ή custom αυτοματοποιημένη υλοποίηση, προσαρμοσμένη στα δεδομένα της συγκεκριμένης επιχείρησης. Δεν υπάρχει γενικού σκοπού plugin που να ξέρει τι πουλάτε καλύτερα από εσάς.
Στην πράξη, ελέγχουμε πρώτα τι παράγει ήδη το plugin σας μέσω του Rich Results Test, και συμπληρώνουμε ακριβώς τα κενά, όχι αντικαθιστούμε ό,τι ήδη δουλεύει σωστά, μόνο ό,τι λείπει.
Τι αλλάζει όταν έχετε πολλά υποκαταστήματα
Το LocalBusiness schema που περιγράψαμε παραπάνω δουλεύει άψογα για μια επιχείρηση με μία διεύθυνση. Μια αλυσίδα με πέντε υποκαταστήματα σε πέντε πόλεις είναι διαφορετικό πρόβλημα, και το πιο συχνό λάθος που βλέπουμε είναι η προσπάθεια να καλυφθεί με ένα ενιαίο schema block στην αρχική σελίδα, με όλες τις διευθύνσεις στριμωγμένες μαζί. Η Google δεν ξέρει τι να κάνει με αυτό: δεν μπορεί να αποφασίσει ποια διεύθυνση ανήκει σε ποια σελίδα, και συχνά αγνοεί ολόκληρο το block.
Η σωστή δομή είναι η αντίστροφη: κάθε υποκατάστημα χρειάζεται τη δική του σελίδα, με το δικό της LocalBusiness schema, όπου το @id είναι μοναδικό ανά τοποθεσία και η ιδιότητα sameAs συνδέει πίσω στην κεντρική Organization. Η αρχική σελίδα, αντίστοιχα, χρησιμοποιεί τύπο Organization με μια λίστα department ή subOrganization που παραπέμπει σε κάθε τοπικό @id. Αυτό δίνει στη Google μια ξεκάθαρη ιεραρχία: μία μητρική επιχείρηση, πέντε ξεχωριστές τοπικές οντότητες, καθεμία με τα δικά της στοιχεία επικοινωνίας, ωράριο και κριτικές.
Το λάθος που πληρώνει πιο ακριβά είναι όταν δύο υποκαταστήματα καταλήγουν να μοιράζονται το ίδιο @id επειδή αντιγράφτηκε το ίδιο template χωρίς αλλαγή. Τότε η Google συγχωνεύει σήματα από δύο διαφορετικές φυσικές τοποθεσίες σε μία, με αποτέλεσμα κριτικές πελατών Θεσσαλονίκης να εμφανίζονται στο προφίλ Αθήνας, ή ώρες λειτουργίας μιας πόλης να δείχνουν λάθος για την άλλη. Είναι ένα λάθος αόρατο μέχρι κάποιος πελάτης παραπονεθεί ότι το κατάστημα ήταν κλειστό ενώ το site έλεγε ανοιχτό.
Για επιχειρήσεις με πάνω από δύο-τρία σημεία, η σύστασή μας είναι πάντα η ίδια: ξεχωριστό @id ανά τοποθεσία, χωρίς εξαίρεση, ακόμα κι αν φαίνεται σαν περιττή επανάληψη κώδικα την πρώτη φορά που το υλοποιείτε.
Λίστα ελέγχου πριν κάθε launch
Ένα σύντομο, πρακτικό πρωτόκολλο ελέγχου, το οποίο τρέχουμε σε κάθε redesign ή αλλαγή CMS πριν το site πάει live, γιατί το schema είναι από τα πρώτα πράγματα που σπάνε σιωπηλά χωρίς κανείς να το προσέξει μέχρι μήνες μετά.
Πρώτο: τρέξτε κάθε τύπο σελίδας (όχι κάθε σελίδα, αλλά κάθε πρότυπο) μέσα από το Rich Results Test της Google. Μια σελίδα προϊόντος, μια σελίδα άρθρου, η αρχική, μια σελίδα υπηρεσίας. Αν ένα πρότυπο αποτυγχάνει, όλες οι σελίδες που το χρησιμοποιούν αποτυγχάνουν μαζί του.
Δεύτερο: επιβεβαιώστε ότι κάθε τιμή μέσα στο schema αντιστοιχεί σε κάτι ορατό στη σελίδα. Αν το schema λέει βαθμολογία 4.8 αλλά ο χρήστης δεν βλέπει πουθενά αστέρια ή αριθμό κριτικών, αυτό είναι απόκλιση που η Google τιμωρεί.
Τρίτο: ελέγξτε τα πεδία ημερομηνίας (datePublished, dateModified) σε σχέση με την πραγματική ημερομηνία δημοσίευσης. Ένα CMS που γεμίζει αυτόματα και τα δύο πεδία με τη σημερινή ημερομηνία σε κάθε deploy είναι κοινό, αόρατο λάθος που κάνει κάθε άρθρο να φαίνεται σαν να δημοσιεύτηκε σήμερα.
Τέταρτο: επιβεβαιώστε ότι δεν υπάρχουν διπλά schema blocks του ίδιου τύπου στην ίδια σελίδα: συχνό λάθος όταν ένα theme προσθέτει το δικό του Organization schema πάνω σε αυτό που προσθέσατε εσείς χειροκίνητα.
Πέμπτο: μετά το launch, επιστρέψτε σε 7 και σε 30 μέρες και ελέγξτε στο Google Search Console αν οι σελίδες εμφανίζονται πράγματι ως επιλέξιμες για rich results. Η εγκυρότητα του κώδικα δεν εγγυάται εμφάνιση, μόνο επιλεξιμότητα.
Πέντε βήματα, δεκαπέντε λεπτά ανά πρότυπο σελίδας. Είναι φθηνότερο από το να ανακαλύψετε έξι μήνες αργότερα ότι κανένα rich result δεν εμφανίστηκε ποτέ.
Τι αλλάζει σε ένα e-shop με χιλιάδες προϊόντα
Όλα όσα περιγράψαμε παραπάνω προϋποθέτουν σιωπηλά ότι κάποιος γράφει ή ελέγχει το schema χειροκίνητα, σελίδα-σελίδα. Αυτό δουλεύει άψογα για δέκα, είκοσι, ακόμα και εκατό σελίδες. Σε ένα e-shop με τρεις χιλιάδες προϊόντα, η λογική αλλάζει εντελώς: το schema δεν γράφεται πια, παράγεται.
Η σωστή αρχιτεκτονική είναι ένα template Product schema συνδεδεμένο απευθείας με τη βάση δεδομένων του καταλόγου, όπου κάθε πεδίο (τιμή, διαθεσιμότητα, SKU, βαθμολογία) αντλείται αυτόματα από το ίδιο σύστημα που τροφοδοτεί την οπτική σελίδα. Αν η τιμή αλλάξει στο ERP, πρέπει να αλλάξει ταυτόχρονα και στο ορατό κείμενο και στο schema, χωρίς δύο ξεχωριστά σημεία ενημέρωσης. Το πιο συχνό λάθος σε αυτή την κλίμακα δεν είναι απουσία schema: είναι ασυγχρονισμένο schema, μια τιμή που άλλαξε στο site αλλά όχι στο JSON-LD, γιατί κάποιος ενημέρωσε το ένα σύστημα και ξέχασε το δεύτερο. Η Google εντοπίζει αυτή την απόκλιση μαζικά σε μεγάλους καταλόγους και μπορεί να αφαιρέσει την επιλεξιμότητα για rich results σε ολόκληρες κατηγορίες προϊόντων ταυτόχρονα, όχι μόνο σε μία σελίδα.
Υπάρχει και δεύτερο ζήτημα κλίμακας: η διαχείριση μεταβλητών προϊόντων (variants): ίδιο προϊόν, διαφορετικό μέγεθος ή χρώμα, συχνά με διαφορετική τιμή ή διαθεσιμότητα ανά παραλλαγή. Το σωστό μοτίβο εδώ είναι ProductGroup schema με ξεχωριστά variesBy και επιμέρους hasVariant entries, όχι ένα μόνο Product schema που προσπαθεί να αντιπροσωπεύσει ταυτόχρονα πέντε χρώματα με μία τιμή.
Στην πράξη, αυτό σημαίνει ότι σε ένα project κλίμακας e-shop, το schema δεν είναι πια αντικείμενο του SEO ειδικού μόνο: είναι αρχιτεκτονική απόφαση που αφορά και τον προγραμματιστή του καταλόγου, γιατί ζει μέσα στο ίδιο pipeline δεδομένων με την τιμή και το απόθεμα, όχι σε ξεχωριστό, χειροκίνητο αρχείο.