Structured Data για AI Crawlers: Τι Αλλάζει

Το GPTBot επισκέφτηκε το site σου 40.000 φορές τον περασμένο μήνα. Δεν είδε σχεδόν τίποτα από αυτά που πλήρωσες να σχεδιαστούν.

Τι είναι πραγματικά το structured data

Το structured data είναι κώδικας (συνήθως σε μορφή JSON-LD) που περιγράφει το περιεχόμενο μιας σελίδας σε γλώσσα που καταλαβαίνει μια μηχανή, όχι μόνο ένας άνθρωπος. Ένα άνθρωπος βλέπει "Distarter, Web Development Agency, Αθήνα" σε ωραία γραμματοσειρά. Μια μηχανή, χωρίς structured data, βλέπει μόνο κείμενο μέσα σε ένα div: δεν ξέρει αν αυτό είναι το όνομα μιας εταιρείας, ο τίτλος ενός άρθρου, ή απλώς μια τυχαία πρόταση.

Το schema.org είναι το κοινό λεξιλόγιο που συμφώνησαν η Google, η Microsoft, η Yahoo και άλλες εταιρείες πριν από πάνω από μια δεκαετία, ακριβώς για αυτόν τον λόγο. Λέει "αυτό εδώ είναι Organization, με αυτό το όνομα, αυτή τη διεύθυνση, αυτά τα στοιχεία επικοινωνίας" με τρόπο που κάθε μηχανή που ξέρει να διαβάσει schema.org μπορεί να το εξάγει αξιόπιστα, χωρίς να χρειάζεται να "μαντέψει" από το οπτικό layout.

Το κρίσιμο σημείο που πολλοί χάνουν: το structured data δεν είναι διακοσμητικό SEO trick. Είναι μετάφραση. Το site σου μιλάει ήδη μια γλώσσα: HTML, CSS, οπτική ιεραρχία. Οι μηχανές, ειδικά οι νεότερες AI μηχανές, δεν διαβάζουν αυτή τη γλώσσα με την ίδια ακρίβεια που τη διαβάζει ένας άνθρωπος. Το JSON-LD είναι το κομμάτι που λέει ρητά, χωρίς ασάφεια, τι σημαίνει το καθετί.

Αυτό γίνεται πιο σημαντικό, όχι λιγότερο, όσο περνάμε από μηχανές "ταξινόμησης" (search engines που δείχνουν λίστες) σε μηχανές "σύνθεσης" (AI μοντέλα που παράγουν μία απάντηση). Μια μηχανή ταξινόμησης μπορεί να ανεχτεί λίγη ασάφεια. Απλά θα κατατάξει τη σελίδα σου λίγο χαμηλότερα. Μια μηχανή σύνθεσης που δεν καταλαβαίνει με σιγουριά τι λέει η σελίδα σου, απλά δεν τη χρησιμοποιεί καθόλου ως πηγή.

Γιατί οι AI crawlers διαβάζουν διαφορετικά από τον Googlebot

Η κοινή υπόθεση είναι ότι όλοι οι crawlers λειτουργούν το ίδιο: επισκέπτονται μια σελίδα, τη renders, την κατανοούν. Λάθος υπόθεση, και ακριβό λάθος. Ο Googlebot έχει είκοσι πέντε χρόνια εξέλιξης πίσω του, τεράστια υποδομή rendering, και μπορεί να εκτελέσει JavaScript σχεδόν σαν πραγματικό browser πριν αποφασίσει τι λέει η σελίδα.

Το GPTBot, το ClaudeBot, το PerplexityBot (οι crawlers που τροφοδοτούν τα σύγχρονα AI μοντέλα) δεν έχουν την ίδια υποδομή rendering σε πολλές περιπτώσεις. Πολλοί από αυτούς διαβάζουν κυρίως το αρχικό HTML, χωρίς πλήρη εκτέλεση JavaScript, ή με πολύ πιο περιορισμένο budget χρόνου ανά σελίδα. Αυτό σημαίνει ότι ένα site φτιαγμένο εξ ολοκλήρου με client-side rendering, όπου το περιεχόμενο "εμφανίζεται" μόνο αφού τρέξει JavaScript στον browser, μπορεί να φαίνεται σχεδόν άδειο σε αυτούς τους crawlers, ενώ ο Googlebot το βλέπει κανονικά.

Το αντι-διαισθητικό σημείο εδώ: τα δεδομένα δομημένα σε JSON-LD δεν χρειάζονται καμία εκτέλεση JavaScript για να διαβαστούν σωστά: υπάρχουν έτοιμα, μέσα στο αρχικό HTML, ως απλό κείμενο JSON. Αυτό τα κάνει το πιο αξιόπιστο κανάλι επικοινωνίας ακριβώς με τους crawlers που έχουν τη λιγότερη υπομονή για rendering. Ενώ ένας άνθρωπος διαβάζει το οπτικό αποτέλεσμα της σελίδας σου, ένας AI crawler με περιορισμένο rendering budget διαβάζει, πρακτικά, το JSON-LD σου πρώτα και καλύτερα από οτιδήποτε άλλο.

Αυτό σημαίνει ότι η επένδυση σε structured data δεν είναι πια "καλή πρακτική για SEO": είναι το ελάχιστο για να είσαι ορατός σε ένα ολοένα μεγαλύτερο κομμάτι της κίνησης που δεν περνάει καν από παραδοσιακή αναζήτηση.

Τι άλλαξε συγκεκριμένα με τους νέους AI crawlers

Το 2023-2024 εμφανίστηκαν δεκάδες νέοι bots με ονόματα που κανείς δεν είχε ξανακούσει: GPTBot (OpenAI), ClaudeBot (Anthropic), PerplexityBot, Google-Extended, CCBot (Common Crawl, που τροφοδοτεί πολλά μοντέλα έμμεσα). Κάθε ένας έχει διαφορετική συμπεριφορά, διαφορετικό σεβασμό στο robots.txt, και διαφορετική ικανότητα rendering.

Το PerplexityBot, για παράδειγμα, δίνει ιδιαίτερη βαρύτητα σε σελίδες με σαφή structured data όταν αποφασίζει ποιες πηγές να παραθέσει με σύνδεσμο μέσα στην απάντησή του, και το Perplexity είναι από τα λίγα εργαλεία που δείχνει ρητά τις πηγές του, πράγμα που σημαίνει ότι το σωστό markup μεταφράζεται άμεσα σε ορατή, μετρήσιμη παρουσία, όχι σε αόρατη επιρροή σε ένα training set.

Το πιο πρακτικό αποτέλεσμα αυτής της αλλαγής είναι το llms.txt, ένα αρχείο παρόμοιο σε πνεύμα με το robots.txt, που ορισμένα sites (συμπεριλαμβανομένου του δικού μας) δημοσιεύουν στη ρίζα του domain για να δώσουν στα AI μοντέλα μια συμπυκνωμένη, καθαρή περίληψη του τι κάνει η επιχείρηση, χωρίς να χρειάζεται να "σκάψουν" σε δεκάδες σελίδες HTML. Δεν είναι επίσημο πρότυπο αναγνωρισμένο από όλους τους crawlers ακόμα, αλλά είναι ένα ξεκάθαρο σήμα καλής πίστης προς αυτή την κατεύθυνση, και συνδέεται άμεσα με τη λογική του structured data: δώσε στη μηχανή την απάντηση σε μορφή που δεν χρειάζεται ερμηνεία.

Ποια schema types μετράνε περισσότερο

Organization schema είναι το θεμέλιο: όνομα, λογότυπο, διεύθυνση, στοιχεία επικοινωνίας, σύνδεσμοι σε κοινωνικά προφίλ (sameAs). Χωρίς αυτό, κάθε άλλο schema στο site σου μοιάζει με μεμονωμένο νησί, χωρίς σαφή ιδιοκτήτη. Είναι το πρώτο πράγμα που προσθέτουμε σε κάθε νέο project, πριν από οτιδήποτε άλλο.

Person schema, συνδεδεμένο σε κάθε άρθρο μέσω author, δίνει όνομα και ταυτότητα σε κάθε κείμενο, και συνδέεται άμεσα με το πώς περιγράψαμε το χτίσιμο E-E-A-T σε νέα sites. Ένα Article schema χωρίς σαφές Person ως author χάνει μεγάλο μέρος της αξίας του, γιατί η μηχανή δεν μπορεί να συνδέσει το περιεχόμενο με μια αξιόπιστη πηγή.

FAQPage schema μετατρέπει ερωτήσεις-απαντήσεις σε δομή που τα AI μοντέλα μπορούν να παραθέσουν σχεδόν αυτούσια: αυτό είναι ακριβώς το είδος μορφής που βοηθάει επίσης στη λογική της θέσης μηδέν: σαφής ερώτηση, σαφής σύντομη απάντηση, μηχανικά επιβεβαιωμένη ως τέτοια.

LocalBusiness schema, για επιχειρήσεις με φυσική παρουσία, προσθέτει ωράριο, τοποθεσία, εύρος τιμών: στοιχεία που τα AI μοντέλα χρησιμοποιούν όλο και περισσότερο σε τοπικές ερωτήσεις τύπου "ποιο web agency στην Αθήνα...". Product schema, για e-commerce, προσθέτει τιμή, διαθεσιμότητα, reviews: στοιχεία που εμφανίζονται πλέον απευθείας μέσα σε AI-παραγόμενες συγκρίσεις προϊόντων.

Κοινά λάθη που ακυρώνουν το structured data

Το πρώτο λάθος: markup που δεν ταιριάζει με το ορατό περιεχόμενο. Αν το JSON-LD λέει ότι η τιμή είναι 500€ αλλά η σελίδα δείχνει 650€, αυτό δεν περνάει απαρατήρητο: οι μηχανές διασταυρώνουν structured data με ορατό κείμενο, και η ασυμφωνία λειτουργεί ως σήμα αναξιοπιστίας, όχι απλώς ως τεχνικό σφάλμα.

Το δεύτερο λάθος: υπερβολικό ή "spam" markup: προσθήκη AggregateRating με πλασματικά αστέρια, ή Review schema χωρίς πραγματικές κριτικές πίσω τους. Η Google έχει ενεργά τιμωρήσει αυτή την πρακτική εδώ και χρόνια, αφαιρώντας εντελώς τα rich results από domains που το κάνουν, και οι νεότερες AI μηχανές έχουν εξίσου χαμηλή ανοχή σε ανακρίβεια.

Το τρίτο λάθος: μη έγκυρο JSON: ένα κόμμα στη λάθος θέση, ένα τσιτάτο που δεν έκλεισε, και ολόκληρο το block schema αγνοείται σιωπηλά, χωρίς κανένα σφάλμα ορατό στον επισκέπτη. Αυτό είναι το πιο συχνό λάθος που βλέπουμε σε sites που πρόσθεσαν schema μια φορά, χειροκίνητα, χωρίς αυτοματοποιημένο έλεγχο εγκυρότητας σε κάθε deploy.

Το τέταρτο, πιο λεπτό λάθος: σελίδα με πολλαπλά, αντικρουόμενα schema types για το ίδιο περιεχόμενο, για παράδειγμα ένα άρθρο με ταυτόχρονα Article και Product schema στο ίδιο URL, χωρίς σαφή διαχωρισμό. Αυτό μπερδεύει τη μηχανή αντί να τη βοηθήσει, γιατί δεν ξέρει ποιο schema να θεωρήσει πρωτεύον.

Πώς το υλοποιούμε στην πράξη

Σε κάθε νέο project, το structured data δεν προστίθεται στο τέλος σαν "SEO touch-up": χτίζεται στο επίπεδο του template, μέσα στο ίδιο το Next.js component που renders τη σελίδα, ώστε κάθε νέα σελίδα του ίδιου τύπου (κάθε άρθρο, κάθε προϊόν, κάθε case study) να παίρνει αυτόματα το σωστό schema, χωρίς χειροκίνητη προσθήκη ανά σελίδα και χωρίς κίνδυνο να ξεχαστεί.

Χρησιμοποιούμε server-side rendering ακριβώς επειδή αυτό εγγυάται ότι το JSON-LD (και όλο το ουσιαστικό περιεχόμενο) υπάρχει ήδη μέσα στο αρχικό HTML, χωρίς να εξαρτάται από εκτέλεση JavaScript στον client. Το ίδιο πλεονέκτημα που κάνει τα sites μας γρηγορότερα κάνει και τους AI crawlers πιο σίγουρους για το τι διαβάζουν. Αυτό είναι απόφαση αρχιτεκτονικής, όχι απλώς SEO ρύθμιση, και είναι μέρος του λόγου που η ίδια η υπηρεσία ανάπτυξης ιστοσελίδων μας δεν χτίζει ποτέ σε στοίβες που βασίζονται αποκλειστικά σε client-side rendering για το κύριο περιεχόμενο.

Μετά την προσθήκη, κάθε schema περνάει από αυτοματοποιημένο έλεγχο εγκυρότητας πριν από κάθε deploy, όχι χειροκίνητο έλεγχο κάθε λίγους μήνες, αλλά μέρος του pipeline, ώστε ένα σπασμένο JSON block να μην φτάσει ποτέ σε production απαρατήρητο.

Σύγκριση: structured data για Google Search εναντίον AI crawlers

Για την παραδοσιακή αναζήτηση της Google, το structured data παράγει κυρίως "rich results": αστέρια, εικόνες, breadcrumbs μέσα στη σελίδα αποτελεσμάτων. Το όφελος είναι οπτικό και μετρήσιμο σε CTR: μια σελίδα με rich snippet παίρνει συχνά 15-30% περισσότερο κλικ από την ίδια θέση χωρίς αυτό.

Για τους AI crawlers, το όφελος δεν είναι οπτικό: δεν υπάρχει "σελίδα αποτελεσμάτων" να διακοσμηθεί. Το όφελος είναι δυαδικό: είτε η μηχανή κατανοεί με σιγουριά το περιεχόμενο και το χρησιμοποιεί ως πηγή, είτε δεν το κατανοεί με αρκετή σιγουριά και το αγνοεί εντελώς, ανεξάρτητα από το πόσο καλό είναι το ίδιο το κείμενο. Δεν υπάρχει ενδιάμεση κατάσταση "λίγο πιο ελκυστικό οπτικά".

Αυτό σημαίνει ότι η προτεραιότητα αλλάζει: για Google Search, το structured data είναι βελτιστοποίηση πάνω από ήδη καλό περιεχόμενο. Για AI crawlers, είναι προαπαιτούμενο για να θεωρηθείς καν υποψήφια πηγή. Ένα site μπορεί να έχει εξαιρετικό περιεχόμενο και μηδενική παρουσία σε AI απαντήσεις, απλά επειδή η μηχανή δεν μπόρεσε να το "διαβάσει" με αρκετή βεβαιότητα.

Τρεις οριακές περιπτώσεις

Πρώτη: sites με πολλαπλές γλώσσες, όπου το structured data υπάρχει μόνο στην προεπιλεγμένη γλώσσα και όχι στις μεταφρασμένες εκδόσεις. Αυτό σημαίνει ότι ένας AI crawler που επισκέπτεται την αγγλική έκδοση ενός ελληνικού site μπορεί να μην βρει καθόλου δομημένα δεδομένα, ακόμα κι αν η ελληνική έκδοση τα έχει πλήρη: ένα κενό που πολλά πολυγλωσσικά sites αγνοούν εντελώς.

Δεύτερη: single-page εφαρμογές όπου το schema προστίθεται δυναμικά μέσω JavaScript μετά το αρχικό φόρτωμα. Αν ένας crawler δεν εκτελεί πλήρες JavaScript, βλέπει μια σελίδα χωρίς κανένα structured data, ακόμα κι αν το developer console δείχνει ότι υπάρχει, μετά τη φόρτωση, στον browser.

Τρίτη: επιχειρήσεις που αντιγράφουν schema markup από ανταγωνιστή χωρίς να το προσαρμόσουν πλήρως, αφήνοντας παλιά ονόματα, λάθος διευθύνσεις, ή ανύπαρκτους συνδέσμους sameAs. Αυτό είναι χειρότερο από το να μην έχεις καθόλου schema, γιατί δίνει στη μηχανή λανθασμένη πληροφορία με πλήρη σιγουριά.

Λίστα ελέγχου

1. Υπάρχει Organization schema με σωστό όνομα, διεύθυνση και σύνδεσμο sameAs σε κάθε επίσημο κοινωνικό προφίλ;
2. Κάθε άρθρο έχει Article schema με Person schema ως author, όχι γενικό placeholder;
3. Οι ερωτήσεις-απαντήσεις έχουν FAQPage schema όπου υπάρχει πραγματική δομή ερώτησης-απάντησης;
4. Το JSON-LD υπάρχει μέσα στο αρχικό server-rendered HTML, όχι μόνο μετά από εκτέλεση JavaScript;
5. Έχεις τρέξει το markup από επικυρωτή εγκυρότητας πριν το production;
6. Τα στοιχεία στο schema ταιριάζουν 100% με το ορατό κείμενο της σελίδας;
7. Αν το site είναι πολυγλωσσικό, υπάρχει σωστό schema σε κάθε γλωσσική έκδοση, όχι μόνο στην προεπιλεγμένη;
8. Ελέγχεις το robots.txt σου για να δεις αν επιτρέπεις ρητά τους νεότερους AI bots (GPTBot, ClaudeBot, PerplexityBot);

Το σημείο

Το structured data δεν κάνει το site σου να φαίνεται καλύτερο σε έναν άνθρωπο. Το κάνει κατανοητό σε μια μηχανή που δεν έχει την υπομονή, ή την ικανότητα rendering, να το ανακαλύψει μόνη της. Όσο περισσότερη κίνηση περνάει από AI εργαλεία αντί από παραδοσιακές λίστες αποτελεσμάτων, τόσο πιο κρίσιμη γίνεται αυτή η μετάφραση.

Δεν χρειάζεται εντυπωσιακό σχεδιασμό για να σε "δει" ένα AI μοντέλο. Χρειάζεται σαφήνεια, σε γλώσσα που καταλαβαίνει χωρίς ερμηνεία. Το πιο όμορφο site στον κόσμο, χωρίς αυτό, παραμένει αόρατο σε ένα κομμάτι της αναζήτησης που μεγαλώνει κάθε μήνα.

Ένσταση: "Δεν Έχουμε Engineering Resources για Schema σε Κάθε Σελίδα"

Το ακούμε συχνά από ομάδες με 2-3 developers που ήδη τρέχουν πίσω από ένα roadmap γεμάτο άλλες προτεραιότητες: "Ωραία ιδέα, αλλά ποιος θα προσθέσει schema σε 400 σελίδες προϊόντων;"

Η σωστή απάντηση δεν είναι "κανείς, χειροκίνητα". Είναι ότι η ερώτηση είναι λάθος διατυπωμένη εξαρχής. Δεν προσθέτεις schema ανά σελίδα. Προσθέτεις schema ανά template, μία φορά, στο επίπεδο του component που ήδη renders κάθε σελίδα του ίδιου τύπου. Αν έχεις ένα template "ProductPage" που εμφανίζει 400 προϊόντα, το JSON-LD μπαίνει μία φορά μέσα σε αυτό το component, με τα πεδία (τίτλος, τιμή, διαθεσιμότητα) να αντλούνται από τα ίδια δεδομένα που ήδη εμφανίζει η σελίδα. Το κόστος δεν είναι 400 φορές μια εργασία. Είναι μία εργασία, που πολλαπλασιάζεται αυτόματα.

Η πραγματική δουλειά μηχανικού για ένα τυπικό site με 5-6 τύπους σελίδων (αρχική, υπηρεσία, άρθρο, προϊόν, επικοινωνία, FAQ) είναι μετρήσιμη σε ώρες, όχι εβδομάδες: 2-4 ώρες ανά τύπο σελίδας για σωστό, επικυρωμένο schema, δηλαδή συνολικά 1-3 μέρες δουλειάς ενός μεσαίου developer για ολόκληρο το site, εφάπαξ. Η συντήρηση μετά από αυτό είναι σχεδόν μηδενική, γιατί το schema ανανεώνεται αυτόματα κάθε φορά που αλλάζει το περιεχόμενο της σελίδας.

Αν πραγματικά δεν υπάρχουν καν αυτές οι 1-3 μέρες διαθέσιμες, η προτεραιοποίηση που προτείνουμε είναι: ξεκίνα από το Organization schema (μία σελίδα, όχι template, μισή μέρα δουλειάς) και το Article schema στα άρθρα με τη μεγαλύτερη κίνηση -όχι σε όλα ταυτόχρονα. Ακόμα και ημιτελής κάλυψη structured data σε 20% των σελίδων με τη μεγαλύτερη αξία παράγει μετρήσιμο αποτέλεσμα, ενώ η αναμονή για "τέλεια κάλυψη" πριν ξεκινήσεις καθόλου παράγει μηδέν.

Το ίδιο μοτίβο προτεραιοποίησης ισχύει και στην ευρύτερη απόφαση rendering που περιγράφουμε στο ssr vs csr seo -δεν χρειάζεται να ξαναχτίσεις όλο το site ταυτόχρονα, χρειάζεται να ξέρεις ποιο κομμάτι αξίζει την επένδυση πρώτο.

Ένα Πρακτικό Παράδειγμα Πριν και Μετά

Ένας πελάτης μας ήρθε με ένα site τεχνικών υπηρεσιών, 60 σελίδες, μηδενικό structured data εκτός από ένα γενικό Organization schema αντιγραμμένο από πρότυπο -λάθος διεύθυνση, ανύπαρκτο τηλέφωνο, κατάλοιπο από προηγούμενη agency που ποτέ δεν το ενημέρωσε.

Πριν την παρέμβαση, η ανίχνευση αναφοράς σε AI εργαλεία (ελέγχοντας ερωτήματα σαν "ποια εταιρεία κάνει X κοντά στο Υ") έδειχνε μηδενικές αναφορές στο Perplexity σε 15 δοκιμαστικά ερωτήματα σχετικά με τις υπηρεσίες του, παρότι το site είχε καλό, λεπτομερές περιεχόμενο -απλά η μηχανή δεν μπορούσε να το επιβεβαιώσει με σιγουριά ως αξιόπιστη πηγή, γιατί το schema έλεγε κάτι διαφορετικό από την πραγματικότητα.

Η δουλειά ήταν συγκεκριμένη: διόρθωση Organization schema με σωστά στοιχεία και σύνδεσμο sameAs σε όλα τα ενεργά κοινωνικά προφίλ, προσθήκη Person schema σε κάθε άρθρο με πραγματικό συγγραφέα, LocalBusiness schema με σωστό εύρος τιμών, και FAQPage schema στις 12 πιο κοινές ερωτήσεις πελατών, ήδη υπάρχον περιεχόμενο που απλά δεν ήταν σε μορφή που μια μηχανή μπορούσε να αναγνωρίσει ως δομημένη ερώτηση-απάντηση.

Έξι εβδομάδες μετά, οι ίδιες 15 δοκιμαστικές ερωτήσεις στο Perplexity έδειξαν αναφορά στην επιχείρηση σε 6 από τις 15, με σύνδεσμο ορατό στην απάντηση σε 4 από αυτές. Η Google Search Console έδειξε επίσης εμφάνιση rich results (FAQ snippet) σε αναζητήσεις που πριν έδειχναν μόνο τον τίτλο και την περιγραφή. Κανένα άλλο κομμάτι του site δεν άλλαξε στο διάστημα αυτό -όχι νέο περιεχόμενο, όχι νέα backlinks, μόνο η μετάφραση του ήδη υπάρχοντος περιεχομένου σε γλώσσα που η μηχανή μπορούσε να εμπιστευτεί.

Το συμπέρασμα δεν είναι ότι το schema είναι μαγικό. Είναι ότι το περιεχόμενο υπήρχε ήδη, η αξία υπήρχε ήδη, και το μόνο που έλειπε ήταν η ρητή, μηχανικά αναγνώσιμη επιβεβαίωσή της -το ίδιο περιεχόμενο, απλά μεταφρασμένο σε γλώσσα που μια μηχανή σύνθεσης καταλαβαίνει χωρίς να χρειάζεται να μαντέψει.

Το Λάθος που Ξεχνιέται: Μπαγιάτικο Schema Μετά από Αλλαγή Περιεχομένου

Όλα τα λάθη που περιγράψαμε παραπάνω συμβαίνουν τη στιγμή της προσθήκης schema. Υπάρχει ένα πέμπτο, πιο αργό λάθος που συμβαίνει μήνες μετά, αφού όλα έχουν ήδη φτιαχτεί σωστά: το schema μένει ίδιο ενώ το ορατό περιεχόμενο της σελίδας αλλάζει.

Ένα προϊόν αλλάζει τιμή στο frontend αλλά όχι στο JSON-LD, γιατί η αλλαγή έγινε χειροκίνητα σε ένα CMS πεδίο που δεν συνδέεται με το schema template -κάτι που συμβαίνει συχνότερα απ' όσο θα περίμενες σε sites όπου το schema προστέθηκε ως ξεχωριστό, στατικό κομμάτι αντί να αντλείται δυναμικά από την ίδια πηγή δεδομένων με το ορατό κείμενο. Ένα άρθρο αλλάζει συγγραφέα -φεύγει ένας copywriter, έρχεται άλλος- αλλά το Person schema συνεχίζει να δείχνει το παλιό όνομα, γιατί κανείς δεν θυμήθηκε ότι υπήρχε εκεί, αόρατο, κάτω από την επιφάνεια του CMS editor.

Είπαμε παραπάνω ότι η ασυμφωνία ανάμεσα σε ορατό κείμενο και schema λειτουργεί ως σήμα αναξιοπιστίας. Αυτό ισχύει εξίσου, ίσως περισσότερο, όταν η ασυμφωνία δεν είναι εσκεμμένο λάθος αλλά απλή παλαίωση -μια φωτογραφία στιγμής του site από έξι μήνες πριν, κολλημένη μέσα σε δομή που υποτίθεται περιγράφει το σήμερα.

Η λύση δεν είναι περισσότερος χειροκίνητος έλεγχος -αυτό ήδη αποτυγχάνει, αλλιώς δεν θα υπήρχε το πρόβλημα. Είναι αρχιτεκτονική: το schema πρέπει να αντλεί τα πεδία του από την ίδια ακριβώς πηγή δεδομένων με το ορατό κείμενο, όχι από ξεχωριστό, παράλληλο σετ τιμών που κάποιος συμπλήρωσε μία φορά. Αν η τιμή προϊόντος αλλάζει σε ένα σημείο του database, το JSON-LD πρέπει να αλλάζει αυτόματα μαζί της, χωρίς δεύτερο βήμα ενημέρωσης που κάποιος μπορεί να ξεχάσει.

Ένας απλός τριμηνιαίος έλεγχος -σύγκριση δείγματος 10 σελίδων schema με το ορατό περιεχόμενό τους- εντοπίζει αυτό το πρόβλημα πριν γίνει μοτίβο σε ολόκληρο το site, ειδικά σε sites όπου η αρχιτεκτονική δεδομένων δεν είναι ακόμα τέλεια ενοποιημένη.