WooCommerce και Agentic Commerce SEO: Πρακτικός οδηγός για e-shops και digital agencies

Ένα WooCommerce e-shop δεν προετοιμάζεται για τις μηχανές αναζήτησης, τα AI engines και τα μελλοντικά συστήματα Agentic Commerce με την εγκατάσταση ενός ακόμη plugin.

Χρειάζεται ένα συνεπές commerce data system, στο οποίο τα στοιχεία των προϊόντων, οι παραλλαγές, οι τιμές, το απόθεμα, τα product feeds, τα structured data και το checkout αντλούν αξιόπιστες πληροφορίες από καθορισμένες πηγές.

Στην πράξη, πολλά WooCommerce e-shops διαθέτουν σωστά σχεδιασμένες σελίδες προϊόντων, αλλά στέλνουν διαφορετικά δεδομένα στο Google Merchant Center, στο Skroutz, στο BestPrice ή στα structured data. Ένα plugin μπορεί να χρησιμοποιεί το SKU ως αναγνωριστικό, ένα δεύτερο να διαβάζει το EAN από custom field και ένα τρίτο να δηλώνει διαφορετική διαθεσιμότητα από αυτή που βλέπει ο επισκέπτης.

Αυτές οι ασυνέπειες δυσκολεύουν όχι μόνο την Google και τις πλατφόρμες σύγκρισης τιμών, αλλά και κάθε AI system που προσπαθεί να καταλάβει:

• ποιο προϊόν πωλείται,
• ποιες παραλλαγές διαθέτει,
• σε ποια τιμή προσφέρεται,
• αν βρίσκεται σε απόθεμα,
• ποιο κατάστημα το διαθέτει,
• αν ο χρήστης μπορεί πραγματικά να ολοκληρώσει την αγορά.

Το άρθρο απευθύνεται σε digital agencies που δημιουργούν ή υποστηρίζουν WooCommerce e-shops, σε developers που συνδέουν το WooCommerce με ERP και marketplaces και σε ιδιοκτήτες e-shops που θέλουν να γνωρίζουν τι πρέπει να ζητούν από τους συνεργάτες τους.

Δεν επαναλαμβάνει γενικά τι είναι το Agentic Commerce SEO. Εφαρμόζει τις βασικές αρχές του ειδικά στο περιβάλλον του WooCommerce.

Τι πρέπει να υποστηρίζει ένα WooCommerce e-shop

Ένα σωστά οργανωμένο WooCommerce e-shop πρέπει να διατηρεί καθαρή και σταθερή ροή εμπορικών δεδομένων.

Το σύστημα πρέπει να γνωρίζει:

• ποιο είναι κάθε προϊόν,
• ποια προϊόντα αποτελούν variations του ίδιου parent product,
• ποιο SKU αντιστοιχεί σε κάθε προϊόν ή variation,
• ποιο GTIN ή EAN έχει αποδώσει ο κατασκευαστής,
• ποια τιμή ισχύει,
• ποιο απόθεμα είναι πραγματικά διαθέσιμο,
• ποια χαρακτηριστικά διαφοροποιούν τα variations,
• ποιο plugin στέλνει δεδομένα σε κάθε κανάλι,
• ποιο component παράγει τα structured data,
• ποιο σύστημα ενημερώνει το stock,
• ποια plugins επηρεάζουν το checkout.

Το digital agency πρέπει να σχεδιάσει αυτή τη ροή πριν εγκαταστήσει plugins και δημιουργήσει integrations.

Ο ιδιοκτήτης του e-shop δεν χρειάζεται να κατανοεί κάθε τεχνική λεπτομέρεια. Πρέπει όμως να γνωρίζει:

• ποιο σύστημα αποτελεί την κύρια πηγή των δεδομένων,
• ποιος ευθύνεται για κάθε integration,
• πού εμφανίζονται τα errors,
• τι θα παραλάβει στο τέλος της συνεργασίας.

Το WooCommerce πρέπει να λειτουργεί ως οργανωμένη εμπορική βάση και όχι απλώς ως συλλογή σελίδων προϊόντων.

Product attributes στο WooCommerce: η βάση για variations, filters και feeds

Τα product attributes περιγράφουν χαρακτηριστικά όπως:

• χρώμα,
• μέγεθος,
• υλικό,
• χωρητικότητα,
• ισχύς,
• φύλο,
• μοντέλο,
• συμβατότητα,
• τεχνικές προδιαγραφές.

Στο WooCommerce, τα categories, τα tags και τα attributes εξυπηρετούν διαφορετικούς ρόλους. Τα attributes οργανώνουν συγκεκριμένα χαρακτηριστικά και μπορούν να χρησιμοποιηθούν για variations, filters και mappings προς εξωτερικά κανάλια.

Global attributes ή attributes μόνο για ένα προϊόν;

Το WooCommerce επιτρέπει δύο βασικούς τρόπους καταχώρισης attributes:

1. Global attributes, τα οποία δημιουργούνται κεντρικά και επαναχρησιμοποιούνται σε πολλά προϊόντα.
2. Attributes που προστίθενται μόνο σε ένα συγκεκριμένο προϊόν.

Το digital agency πρέπει να χρησιμοποιεί global attributes όταν ένα χαρακτηριστικό:

• εμφανίζεται συστηματικά σε πολλά προϊόντα,
• δημιουργεί variations,
• χρησιμοποιείται στα φίλτρα,
• εξάγεται σε product feeds,
• αντιστοιχίζεται με ERP ή marketplace,
• χρειάζεται συνεπή ονοματολογία.

Για παράδειγμα, ένα κατάστημα υποδημάτων δεν πρέπει να καταχωρίζει το μέγεθος ως ελεύθερο κείμενο σε κάθε προϊόν. Πρέπει να δημιουργήσει global attribute «Μέγεθος» και να χρησιμοποιεί ελεγχόμενες τιμές, όπως 40, 41, 42 και 43.

Ένα attribute που αφορά μόνο ένα συγκεκριμένο προϊόν μπορεί να παραμείνει product-specific. Το agency πρέπει όμως να εξετάσει αν το χαρακτηριστικό θα χρειαστεί αργότερα σε φίλτρο, feed ή integration.

Η ονοματολογία πρέπει να παραμένει συνεπής

Οι διαφορετικές μορφές της ίδιας τιμής δημιουργούν διαφορετικά δεδομένα.

Για παράδειγμα:

• Μπλε,
• μπλε,
• Blue,
• Navy,
• Σκούρο μπλε.

Ένας άνθρωπος μπορεί να καταλάβει ότι κάποιες τιμές περιγράφουν παρόμοια χρώματα. Ένα feed plugin, ένα ERP ή ένα AI system μπορεί να τις αντιμετωπίσει ως διαφορετικές έννοιες.

Το agency πρέπει να ορίσει:

• αποδεκτές ονομασίες,
• γλώσσα καταχώρισης,
• χρήση κεφαλαίων και πεζών,
• μονάδες μέτρησης,
• κανόνες για συντομογραφίες,
• κανόνες για πολλαπλές τιμές,
• υπεύθυνο για τη δημιουργία νέων attribute terms.

Η συνέπεια αποκτά ακόμη μεγαλύτερη σημασία όταν το ίδιο WooCommerce catalog τροφοδοτεί Google, Skroutz, BestPrice και άλλες πλατφόρμες.

Τα κρίσιμα attributes πρέπει να εμφανίζονται στη σελίδα

Ένα e-shop δεν πρέπει να διατηρεί σημαντικά χαρακτηριστικά μόνο στο backend ή μόνο μέσα σε ένα feed.

Το product page πρέπει να εμφανίζει τις πληροφορίες που χρειάζεται ο χρήστης για να καταλάβει και να επιλέξει το προϊόν. Τα feeds και τα structured data πρέπει να συμφωνούν με το ορατό περιεχόμενο. Αναλυτικές πληροφορίες για την ποιότητα των product data για AI agents διαβάστε στο άρθρο Product Data Quality για AI Agents.

Αν ένα feed δηλώνει ότι ένα laptop διαθέτει 16 GB RAM, ενώ η σελίδα αναφέρει 8 GB, το e-shop δημιουργεί μια σοβαρή ασυνέπεια.

Τι πρέπει να ελέγχει το digital agency

Το agency πρέπει να δημιουργήσει ένα attribute framework που να καθορίζει:

• τα υποχρεωτικά attributes ανά κατηγορία,
• τις επιτρεπόμενες τιμές,
• τα attributes που δημιουργούν variations,
• τα attributes που εμφανίζονται στα φίλτρα,
• τα attributes που εξάγονται στα feeds,
• τις αντιστοιχίσεις με τα εξωτερικά κανάλια,
• τη διαδικασία δημιουργίας νέων values,
• τον υπεύθυνο ενημέρωσης.

Ο ιδιοκτήτης του e-shop πρέπει να λάβει αυτές τις οδηγίες σε απλή και εφαρμόσιμη μορφή. Διαφορετικά, οι επόμενες εισαγωγές προϊόντων μπορούν να ακυρώσουν την αρχική οργάνωση.

Variable products και variations στο WooCommerce

Το WooCommerce χρησιμοποιεί variable products για προϊόντα που διατίθενται σε διαφορετικές επιλογές, όπως χρώμα, μέγεθος, υλικό ή χωρητικότητα.

Το parent product περιγράφει το βασικό προϊόν. Κάθε variation περιγράφει μια συγκεκριμένη αγοραζόμενη επιλογή.

Παράδειγμα:

• Parent product: Ανδρικό παπούτσι Model X
• Variation 1: Μαύρο, μέγεθος 42
• Variation 2: Μαύρο, μέγεθος 43
• Variation 3: Λευκό, μέγεθος 42

Το WooCommerce επιτρέπει σε κάθε variation να έχει δική της τιμή, εικόνα, SKU, απόθεμα και GTIN, UPC, EAN ή ISBN. Variations χωρίς τιμή δεν εμφανίζονται ως διαθέσιμα στο κατάστημα.

Κάθε variation πρέπει να αντιστοιχεί σε πραγματική επιλογή

Το digital agency δεν πρέπει να δημιουργεί αυτόματα κάθε πιθανό συνδυασμό όταν η επιχείρηση δεν διαθέτει όλα τα αντίστοιχα προϊόντα.

Αν ένα παπούτσι κυκλοφορεί:

• σε μαύρο χρώμα στα μεγέθη 40–45,
• σε λευκό χρώμα μόνο στα μεγέθη 40–42,

το WooCommerce δεν πρέπει να δημιουργήσει λευκά variations για τα μεγέθη 43–45.

Οι ανύπαρκτοι συνδυασμοί μπορούν:

• να περάσουν στα feeds,
• να εμφανίσουν λανθασμένη διαθεσιμότητα,
• να δημιουργήσουν προβλήματα στο stock,
• να οδηγήσουν τον χρήστη σε μη αγοραζόμενη επιλογή.

Τι πρέπει να ορίζεται σε επίπεδο variation

Όταν οι επιλογές διαφέρουν πραγματικά, κάθε variation πρέπει να διαθέτει:

• μοναδικό SKU,
• ξεχωριστό GTIN ή EAN, όταν ο κατασκευαστής έχει αποδώσει διαφορετικό κωδικό,
• σωστή τιμή,
• ξεχωριστό stock,
• σχετική εικόνα,
• βάρος ή διαστάσεις, όταν αλλάζουν,
• τα attributes που την προσδιορίζουν.

Ένα συχνό πρόβλημα εμφανίζεται όταν το agency καταχωρίζει ένα EAN μόνο στο parent product, παρότι κάθε μέγεθος ή χρώμα διαθέτει διαφορετικό barcode.

Το stock πρέπει να ενημερώνεται στο σωστό επίπεδο

Το WooCommerce μπορεί να διαχειριστεί stock στο parent product ή στα variations.

Το agency πρέπει να επιλέξει το επίπεδο που αντιστοιχεί στην πραγματική λειτουργία της επιχείρησης.

Αν το ERP παρακολουθεί το απόθεμα ξεχωριστά για κάθε μέγεθος, χρώμα ή άλλη παραλλαγή, πρέπει να ενημερώνει και το αντίστοιχο stock κάθε variation στο WooCommerce. Αν στέλνει μόνο το συνολικό απόθεμα του parent product, το WooCommerce μπορεί να εμφανίζει ως διαθέσιμη μια συγκεκριμένη παραλλαγή που έχει ήδη εξαντληθεί.

Το agency πρέπει να ελέγξει:

• ποιο identifier χρησιμοποιεί το ERP,
• αν το ERP αναγνωρίζει το variation ID ή το SKU,
• αν ενημερώνει το parent ή το variation,
• πόσο συχνά εκτελείται το sync,
• τι συμβαίνει όταν το sync αποτυγχάνει.

Το default variation χρειάζεται συνειδητή επιλογή

Το WooCommerce επιτρέπει στο κατάστημα να ορίσει default επιλογές για ένα variable product.

Το agency δεν πρέπει να επιλέγει default variation μηχανικά.

Ένα ακατάλληλο default variation μπορεί:

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

Σε προϊόντα όπου η επιλογή μεγέθους, χρώματος ή συμβατότητας αποτελεί κρίσιμη απόφαση, το e-shop μπορεί να απαιτεί από τον χρήστη να επιλέξει variation πριν προσθέσει το προϊόν στο καλάθι.

SKU, GTIN και EAN στο WooCommerce

Το SKU και το GTIN δεν εξυπηρετούν την ίδια λειτουργία.

Το SKU αποτελεί τον εσωτερικό κωδικό αποθέματος. Το e-shop ή το ERP μπορεί να δημιουργήσει τη δική του λογική SKU.

Το GTIN αποτελεί το διεθνές αναγνωριστικό προϊόντος. Ανάλογα με το προϊόν και την αγορά, μπορεί να εμφανίζεται ως EAN, UPC ή ISBN.

Το e-shop δεν πρέπει να τοποθετεί το εσωτερικό SKU στο πεδίο GTIN μόνο και μόνο για να συμπληρώσει ένα υποχρεωτικό feed field.

Το WooCommerce διαθέτει native πεδίο GTIN

Το WooCommerce εισήγαγε στο core το Global Unique ID field από την έκδοση 9.2. Το πεδίο υποστηρίζει GTIN, UPC, EAN ή ISBN και λειτουργεί σε products και variations. Το Google for WooCommerce προτείνει πλέον το ενσωματωμένο πεδίο ως βασική λύση για το GTIN mapping προς το Merchant Center.

Επομένως, ένα νέο WooCommerce e-shop δεν χρειάζεται υποχρεωτικά ξεχωριστό plugin μόνο για να δημιουργήσει πεδίο EAN.

Το agency πρέπει πρώτα να ελέγξει:

• την έκδοση του WooCommerce,
• αν το feed plugin διαβάζει το native field,
• αν το ERP μπορεί να το ενημερώσει,
• αν παλιότερα custom fields περιέχουν ήδη κωδικούς,
• αν χρειάζεται migration από legacy meta field.

Πότε μπορεί να χρειαστεί custom field

Ένα custom field μπορεί να παραμένει αναγκαίο όταν:

• ένα παλιό integration δεν υποστηρίζει το native field,
• το ERP γράφει σε συγκεκριμένο meta key,
• το e-shop διατηρεί περισσότερους τύπους identifiers,
• το feed plugin δεν έχει προσαρμοστεί,
• η επιχείρηση χρειάζεται ειδική λογική mapping.

Σε αυτή την περίπτωση, το agency πρέπει να τεκμηριώσει:

• το meta key,
• το format,
• το source of truth,
• ποια plugins το διαβάζουν,
• ποιος το ενημερώνει,
• τι θα συμβεί σε μελλοντικό migration.

Συχνά λάθη σε SKU και GTIN

Τα συχνότερα προβλήματα περιλαμβάνουν:

• ίδιο SKU σε διαφορετικά variations,
• ίδιο EAN σε διαφορετικά προϊόντα,
• SKU καταχωρισμένο ως GTIN,
• κατασκευασμένο EAN για προϊόν χωρίς GTIN,
• διαφορετικό GTIN στο WooCommerce και στο feed,
• GTIN αποθηκευμένο μόνο μέσα στις ρυθμίσεις ενός plugin,
• legacy custom field που συνεχίζει να τροφοδοτεί παλιό feed.

Το agency πρέπει να πραγματοποιεί περιοδικά export των προϊόντων και να ελέγχει μαζικά τους identifiers. Το WooCommerce διαθέτει ενσωματωμένο CSV importer και exporter για προϊόντα, attributes, categories και εικόνες, ο οποίος μπορεί να υποστηρίξει audits, migrations και μαζικές διορθώσεις.

Το WooCommerce ως source of truth

Το e-shop πρέπει να διατηρεί κάθε βασική πληροφορία σε ένα καθορισμένο σημείο.

Η τιμή δεν πρέπει να ενημερώνεται χειροκίνητα:

• στο WooCommerce,
• στο Google feed,
• στο Skroutz plugin,
• στο BestPrice plugin.

Το ίδιο ισχύει για:

• το GTIN,
• το stock,
• το brand,
• τα κρίσιμα attributes,
• τις βασικές εικόνες.

Η σωστή αρχιτεκτονική ακολουθεί την παρακάτω λογική:

1. Το WooCommerce ή το ERP διατηρεί τη βασική πληροφορία.
2. Τα plugins διαβάζουν την πληροφορία.
3. Τα mappings τη μετατρέπουν στη μορφή που απαιτεί κάθε κανάλι.
4. Τα feeds ή τα APIs τη διανέμουν.
5. Τα diagnostics εντοπίζουν τις ασυνέπειες.

Πότε χρειάζονται channel-specific overrides

Ορισμένα κανάλια απαιτούν διαφορετικές τιμές ή ειδικά πεδία.

Ένα e-shop μπορεί να χρειάζεται:

• διαφορετικό marketplace title,
• Google product category,
• Skroutz category path,
• διαφορετικό availability mapping,
• ειδική εικόνα,
• αποκλεισμό συγκεκριμένων προϊόντων,
• διαφορετικό shipping field.

Τα overrides δεν αποτελούν πρόβλημα όταν το agency τα ελέγχει και τα τεκμηριώνει.

Γίνονται πρόβλημα όταν:

• κανείς δεν γνωρίζει ότι υπάρχουν,
• αποθηκεύονται μόνο μέσα σε ένα plugin,
• δεν εξάγονται,
• χάνονται κατά την αλλαγή plugin ή agency,
• υπερισχύουν χωρίς έλεγχο των βασικών WooCommerce fields.

Ο παρακάτω πίνακας δείχνει πώς τα βασικά πεδία του WooCommerce μπορούν να αντιστοιχίζονται στο Google Merchant Center, στο Skroutz, στο BestPrice και στα structured data, ώστε το e-shop να διατηρεί ένα καθαρό source of truth για τα product data.

Σημείωση: Το SKU είναι εσωτερικό αναγνωριστικό του
καταστήματος ή του ERP. Το MPN είναι ο κωδικός που έχει αποδώσει ο
κατασκευαστής. Το SKU μπορεί να χρησιμοποιηθεί ως βάση ενός σταθερού product
ID, αλλά δεν πρέπει να δηλώνεται ως MPN, εκτός αν αποτελεί πράγματι τον
επίσημο Manufacturer Part Number.

Διευκρίνιση: Οι παραπάνω αντιστοιχίσεις είναι ενδεικτικές. Τα ακριβή πεδία, οι ονομασίες και η υποχρεωτικότητά τους μπορούν να διαφέρουν ανά κατηγορία προϊόντων, feed plugin και τρέχουσες προδιαγραφές κάθε καναλιού.

Σε mobile: σύρετε τον πίνακα οριζόντια για να δείτε όλες τις
στήλες.

Πώς επιλέγουμε feed plugin για WooCommerce

Το agency δεν πρέπει να επιλέγει feed plugin μόνο από τον αριθμό εγκαταστάσεων, τις αξιολογήσεις ή μια λίστα με τα «καλύτερα WooCommerce plugins».

Πρέπει να αξιολογεί αν το plugin καλύπτει το πραγματικό catalog, τα integrations και τις ανάγκες συντήρησης του e-shop.

API sync ή αρχείο feed;

Ένα WooCommerce e-shop μπορεί να διανέμει product data μέσω:

• API connection,
• XML feed,
• CSV feed,
• scheduled export,
• συνδυασμού διαφορετικών μεθόδων.

Το Google for WooCommerce χρησιμοποιεί άμεσο product sync με το Merchant Center, ενώ άλλες λύσεις παράγουν feed αρχείο προϊόντων και variations.

Για το Skroutz και το BestPrice, τα ελληνικά e-shops χρησιμοποιούν συχνά XML feeds.

Το κατάστημα μπορεί επομένως να χρειάζεται διαφορετική τεχνική λύση για κάθε κανάλι.

Τι πρέπει να υποστηρίζει το feed plugin

Το agency πρέπει να ελέγχει αν το plugin υποστηρίζει:

• simple και variable products,
• ξεχωριστά IDs για variations,
• native WooCommerce GTIN field,
• custom fields,
• brand, MPN και GTIN,
• category mapping,
• attribute mapping,
• regular και sale prices,
• tax configuration,
• stock και backorders,
• excluded products,
• variation images,
• διαφορετικά feeds ανά χώρα ή κανάλι,
• scheduled updates,
• diagnostics,
• logs,
• μεγάλα catalogs.

Τι πρέπει να ελέγχεται πριν από την εγκατάσταση

Πριν εγκαταστήσει ένα plugin, το agency πρέπει να αξιολογεί:

• πόσο συχνά ενημερώνεται,
• αν υποστηρίζει την τρέχουσα έκδοση WooCommerce,
• αν λειτουργεί σωστά με variable products,
• αν υποστηρίζει το native GTIN field,
• αν παρέχει αναλυτικά logs,
• αν επιτρέπει export ή τεκμηρίωση των mappings,
• αν εξαρτάται από proprietary cloud service,
• τι συμβαίνει όταν λήξει η συνδρομή,
• αν συνεχίζει να λειτουργεί ή σταματά να παράγει feed,
• αν επιτρέπει migration σε άλλη λύση,
• αν διαθέτει επαρκή τεχνική υποστήριξη,
• αν δημιουργεί data lock-in.

Το agency πρέπει επίσης να καθορίσει exit plan.

Αν το plugin σταματήσει να υποστηρίζεται, το κατάστημα πρέπει να γνωρίζει:

• πού βρίσκονται τα custom mappings,
• πώς θα εξαχθούν,
• ποια WooCommerce fields χρησιμοποιούνται,
• ποιο feed URL πρέπει να αντικατασταθεί,
• πόσο επηρεάζονται Google, Skroutz και BestPrice.

Τι πρέπει να ελέγχεται μετά την εγκατάσταση

Η σωστή ρύθμιση μέσα στο WordPress admin δεν εγγυάται σωστό feed.

Το agency πρέπει να ελέγχει το πραγματικό XML, CSV ή API output.

Πρέπει να επιλέγει τουλάχιστον:

• ένα simple product,
• ένα variable product,
• ένα προϊόν σε προσφορά,
• ένα out-of-stock προϊόν,
• ένα προϊόν χωρίς GTIN,
• ένα προϊόν με ειδικό shipping rule.

Για κάθε προϊόν πρέπει να συγκρίνει:

• WooCommerce backend,
• product page,
• feed output,
• Merchant Center ή marketplace listing,
• structured data.

Google Merchant Center και WooCommerce

Το Google Merchant Center λειτουργεί ως distribution και quality-control layer για τα product data.

Το WooCommerce e-shop μπορεί να συνδεθεί μέσω του Google for WooCommerce ή μέσω ανεξάρτητου feed plugin.

Google for WooCommerce ή ανεξάρτητο feed plugin;

Το επίσημο Google for WooCommerce προσφέρει:

• product sync,
• σύνδεση με Merchant Center,
• attribute mapping,
• διαχείριση βασικών product data.

Ένα ανεξάρτητο feed plugin μπορεί να προσφέρει:

• περισσότερα κανάλια,
• μεγαλύτερο έλεγχο του XML,
• custom rules,
• country-specific feeds,
• πιο σύνθετα exclusions.

Το agency πρέπει να αποφεύγει δύο παράλληλες συνδέσεις που στέλνουν τα ίδια προϊόντα χωρίς σαφή λόγο.

Διαφορετικά, το Merchant Center μπορεί να λάβει:

• διπλές πηγές,
• διαφορετικά IDs,
• αντικρουόμενα product data,
• διαφορετική συχνότητα ενημέρωσης.

Το attribute mapping πρέπει να ξεκινά από το WooCommerce

Το Google for WooCommerce μπορεί να αντιστοιχίζει WooCommerce attributes με Google Merchant Center attributes και να εφαρμόζει rules σε επίπεδο category.

Τα category-level rules συμπληρώνουν πεδία στα οποία δεν έχει ήδη οριστεί τιμή. Οι τιμές που καταχωρίζονται σε επίπεδο μεμονωμένου προϊόντος υπερισχύουν των global attribute rules.

Ενδεικτικές αντιστοιχίσεις:

• WooCommerce product ή variation ID → id
• Product name → title
• Product description → description
• Product URL → link
• Main image → image_link
• Price → price
• Sale price → sale_price
• Stock status → availability
• Global Unique ID → gtin
• Brand field ή taxonomy → brand
• Parent grouping → item_group_id

Το agency πρέπει να ελέγχει το πραγματικό αποτέλεσμα και όχι μόνο τη θεωρητική αντιστοίχιση.

Price και availability mismatch

Τα mismatches δημιουργούνται συχνά από:

• καθυστερημένο feed refresh,
• προβληματικό WordPress cron,
• caching,
• λανθασμένο tax configuration,
• sale price με λάθος ημερομηνίες,
• stock στο parent αντί στο variation,
• αποτυχημένο ERP sync,
• διαφορετικό νόμισμα,
• dynamic pricing plugin.

Το Merchant Center δεν λειτουργεί μόνο ως εργαλείο προώθησης. Τα diagnostics μπορούν να αποκαλύψουν προβλήματα στην ίδια την WooCommerce υλοποίηση.

Η μετάβαση στο Merchant API απαιτεί ενημερωμένο connector

Η Google και το WooCommerce προετοιμάζουν τη μετάβαση από το legacy Content API for Shopping στο Google Merchant API. Η επίσημη τεκμηρίωση του Google for WooCommerce αναφέρει ότι η σχετική προσαρμογή βρίσκεται σε εξέλιξη και ότι το extension θα πρέπει να παραμένει ενημερωμένο.

Τα agencies πρέπει:

• να παρακολουθούν τις ανακοινώσεις migration,
• να ενημερώνουν το connector,
• να ελέγχουν τα sync logs μετά από major updates,
• να αποφεύγουν παλιές οδηγίες που βασίζονται αποκλειστικά στο Content API.

Τα νέα commerce fields αυξάνουν τις απαιτήσεις ευελιξίας

Τα product data specifications εξελίσσονται και μπορούν να προσθέσουν νέα πεδία, relationships και AI-oriented commerce capabilities.

Ένα WooCommerce e-shop δεν χρειάζεται να εγκαταστήσει βιαστικά ένα «AI feed plugin».

Πρέπει όμως να επιλέξει αρχιτεκτονική που επιτρέπει:

• νέα custom fields,
• πρόσθετα mappings,
• supplemental product data,
• relationships μεταξύ προϊόντων,
• ασφαλή επέκταση χωρίς αλλαγή ολόκληρου του catalog model.

WooCommerce feeds για Skroutz και BestPrice

Το ίδιο product catalog μπορεί να τροφοδοτεί Google, Skroutz και BestPrice, αλλά κάθε κανάλι εφαρμόζει τις δικές του προδιαγραφές.

Το digital agency δεν πρέπει να αντιγράφει τυφλά το Google mapping σε ένα Skroutz ή ένα BestPrice feed.

WooCommerce και Skroutz XML

Το Skroutz δέχεται product catalog μέσω XML Feed ή Products API. Το XML πρέπει να περιλαμβάνει τα απαιτούμενα product attributes και να χρησιμοποιεί σταθερό unique identifier.

Το agency πρέπει να ελέγχει τουλάχιστον:

• unique ID,
• product name,
• product URL,
• image URL,
• price,
• availability,
• manufacturer,
• MPN,
• EAN,
• category,
• color,
• size.

Τα color variations χρειάζονται σταθερό unique ID

Για τα WooCommerce προϊόντα με color variations, το Skroutz προτείνει unique ID στη μορφή:

parent product ID-attribute term ID

Η σύσταση αυτή αποτυπώνεται στην επίσημη τεκμηρίωση του Skroutz.

Το agency δεν πρέπει να αλλάζει αυθαίρετα τη λογική των product IDs, των SKUs ή των variation IDs μετά την αρχική ενεργοποίηση του e-shop. Αν χρειάζεται αλλαγή, πρέπει να υπάρχει migration plan, ώστε το Google Merchant Center, Skroutz, BestPrice, ERP, feeds και structured data να συνεχίσουν να αναγνωρίζουν σωστά τα ίδια προϊόντα.

Μια αλλαγή ID μπορεί να κάνει την πλατφόρμα να αντιμετωπίσει υπάρχουσες προσφορές ως νέα προϊόντα.

Οι εικόνες και τα URLs πρέπει να παραμένουν προσβάσιμα

Το XML μπορεί να είναι σωστό, αλλά η πλατφόρμα δεν θα αξιοποιήσει τα δεδομένα αν:

• το CDN μπλοκάρει τον crawler,
• το firewall εφαρμόζει υπερβολικό rate limiting,
• τα image URLs απαιτούν authentication,
• τα product URLs δημιουργούν redirect chains,
• το XML URL απαιτεί cookies,
• οι εικόνες αλλάζουν συνεχώς URL.

Το agency πρέπει να ελέγχει τις HTTP αποκρίσεις και όχι μόνο να ανοίγει τις σελίδες στον browser του.

WooCommerce και BestPrice XML

Το BestPrice επιτρέπει στο κατάστημα να ορίσει το κόστος αποστολής:

• ανά προϊόν στο XML,
• μέσω κανόνων στην Πλατφόρμα Συνεργατών,
• με συνδυασμό των δύο μεθόδων.

Όταν ο κανόνας εξαρτάται από το βάρος, το XML πρέπει να περιλαμβάνει το αντίστοιχο Weight. Όταν το XML περιλαμβάνει συμπληρωμένο Shipping, το BestPrice χρησιμοποιεί τη συγκεκριμένη τιμή για το προϊόν.

Το agency πρέπει να γνωρίζει αν τα μεταφορικά προκύπτουν από:

• WooCommerce shipping rules,
• custom feed rule,
• βάρος,
• BestPrice Partner Platform,
• product-specific exception.

Όταν το κατάστημα προσθέσει για πρώτη φορά το πεδίο Shipping, το BestPrice ζητά ενημέρωση μέσω support ή ticket για να ενεργοποιήσει την εμφάνιση των δεδομένων.

Structured data στο WooCommerce

Πολλά e-shops εγκαθιστούν ένα schema plugin χωρίς να ελέγξουν τι παράγει ήδη το WooCommerce, το theme ή το SEO plugin.

Το βασικό ερώτημα δεν είναι:

«Έχουμε schema plugin;»

Το σωστό ερώτημα είναι:

«Τι structured data λαμβάνουν οι μηχανές αναζήτησης και τα AI systems στο συγκεκριμένο product page;»

Οι πολλαπλές πηγές μπορούν να δημιουργήσουν conflicts

Ένα WooCommerce e-shop μπορεί να παράγει Product structured data από:

• WooCommerce core,
• SEO plugin,
• dedicated schema plugin,
• theme,
• feed extension,
• custom JSON-LD.

Όταν δύο components περιγράφουν το ίδιο προϊόν, μπορούν να εμφανιστούν:

• duplicate Product entities,
• διαφορετικές τιμές,
• διαφορετικά IDs,
• διαφορετικό availability,
• διαφορετικό brand,
• conflicting reviews,
• διαφορετική λογική για variations.

Το digital agency πρέπει να ελέγχει το τελικό output

Ο έλεγχος πρέπει να περιλαμβάνει:

1. Το ορατό περιεχόμενο του product page.
2. Το rendered HTML.
3. Το JSON-LD.
4. Το Rich Results Test.
5. Το Schema Markup Validator.
6. Το product feed.
7. Το Merchant Center.

Ένα valid schema δεν είναι απαραίτητα σωστό schema.

Μπορεί να περάσει τον τεχνικό έλεγχο και ταυτόχρονα να περιγράφει:

• λάθος τιμή,
• λάθος variation,
• παλιό stock status,
• διαφορετικό GTIN από το feed.

Variable products και ProductGroup

Η Google υποστηρίζει structured data για product variants με το ProductGroup και properties όπως hasVariant, variesBy και productGroupID. Η υλοποίηση πρέπει να συνδέει καθαρά τα variations με το parent product.

Στο WooCommerce, το agency πρέπει να ελέγχει:

• αν το schema περιγράφει το parent ή το selected variation,
• ποια τιμή εμφανίζει,
• ποιο availability δηλώνει,
• ποιο GTIN χρησιμοποιεί,
• αν συμφωνεί με το feed και το ορατό περιεχόμενο.

Performance και crawlability σε WooCommerce e-shops

Η σωστή δομή των δεδομένων δεν αρκεί όταν οι μηχανές και τα εξωτερικά συστήματα δεν μπορούν να προσπελάσουν αξιόπιστα τις σελίδες.

Τα WooCommerce e-shops συχνά επιβαρύνονται από:

• σύνθετα themes,
• page builders,
• variation scripts,
• recommendation engines,
• filters,
• tracking scripts,
• review widgets,
• μεγάλα catalogs,
• βαριά feed generation,
• πολλές scheduled actions.

Τα προϊόντα πρέπει να ανακαλύπτονται μέσω πραγματικών links

Τα product pages πρέπει να συνδέονται από τα categories, τα subcategories και τα υπόλοιπα σημεία πλοήγησης.

Η Google συστήνει crawlable HTML links και ξεχωριστά URLs για τις σελίδες pagination. Σε JavaScript υλοποιήσεις, το sitemap ή το Merchant Center feed μπορεί να βοηθήσει στην ανακάλυψη των προϊόντων, αλλά δεν αντικαθιστά μια σωστή crawlable δομή.

Το agency πρέπει να ελέγχει αν:

• όλες οι βασικές κατηγορίες συνδέονται,
• τα product pages συνδέονται από categories,
• τα pagination links είναι crawlable,
• τα προϊόντα δεν εμφανίζονται μόνο μετά την εφαρμογή φίλτρου,
• το infinite scroll παρέχει προσβάσιμο pagination,
• το sitemap περιλαμβάνει τα canonical product URLs.

Faceted navigation και ανεξέλεγκτα URLs

Το faceted navigation είναι η πλοήγηση με φίλτρα σε ένα e-shop, όπως brand, τιμή, μέγεθος, χρώμα, διαθεσιμότητα ή άλλα product attributes. Βοηθά τον χρήστη να περιορίσει γρήγορα τα προϊόντα που τον ενδιαφέρουν, αλλά από πλευράς SEO χρειάζεται προσεκτικό έλεγχο.

Ο λόγος είναι ότι τα φίλτρα μπορούν να δημιουργήσουν χιλιάδες διαφορετικά URLs από συνδυασμούς όπως:

• χρώμα,
• μέγεθος,
• brand,
• price range,
• availability,
• sorting,
• τεχνικά ή εμπορικά attributes.

Για παράδειγμα, μια κατηγορία όπως “ανδρικά sneakers” μπορεί να δημιουργήσει URLs για “Nike”, “μαύρο”, “μέγεθος 42”, “κάτω από 100 €”, “άμεσα διαθέσιμο” και πολλούς συνδυασμούς αυτών των φίλτρων.

Αυτό δεν είναι πάντα πρόβλημα. Κάποια filtered pages μπορεί να έχουν πραγματική αξία για αναζητήσεις, όπως “μαύρα ανδρικά sneakers Nike”. Όμως πολλές άλλες σελίδες φίλτρων δεν προσφέρουν νέο χρήσιμο περιεχόμενο. Δημιουργούν duplicate ή near-duplicate URLs, καταναλώνουν crawl resources και δυσκολεύουν τις μηχανές αναζήτησης να ξεχωρίσουν ποιες σελίδες αξίζει να ανιχνεύσουν και να ευρετηριάσουν.

Το agency πρέπει να αποφασίσει ποιες filtered pages:

• προσφέρουν πραγματικό search value,
• αξίζει να γίνουν indexable landing pages,
• πρέπει να δείχνουν με canonical στο βασικό category page,
• πρέπει να αποκλείονται από το crawl όταν δημιουργούν άχρηστους συνδυασμούς,
• πρέπει να παραμένουν διαθέσιμες μόνο για τη διευκόλυνση των χρηστών.

Στόχος δεν είναι να καταργηθούν τα φίλτρα. Στόχος είναι να μη μετατρέπονται τα φίλτρα σε ανεξέλεγκτη παραγωγή URLs που μπερδεύουν τη Google, σπαταλούν crawl budget και αποδυναμώνουν τα σημαντικά category και product pages.

WooCommerce crawlability checklist

Το agency πρέπει να πραγματοποιεί ξεχωριστό crawlability check πριν από το go-live και μετά από σημαντικές αλλαγές σε theme, filters, CDN ή security plugins.

Product discovery

• Συνδέονται τα προϊόντα από crawlable category pages;
• Χρησιμοποιούν τα links κανονικό href;
• Εμφανίζονται orphan products;
• Ανακαλύπτονται προϊόντα που βρίσκονται σε pagination;
• Υπάρχουν προϊόντα διαθέσιμα μόνο μέσω internal search αλλά όχι μέσα από κατηγορίες, φίλτρα, internal links ή XML sitemap;

XML sitemap

• Περιλαμβάνει τα canonical product URLs;
• Αφαιρεί discontinued ή noindex προϊόντα;
• Περιλαμβάνει λανθασμένα parameter URLs;
• Ενημερώνεται μετά από αλλαγές στο catalog;

Canonical URLs

• Δηλώνει κάθε product page το σωστό canonical;
• Δημιουργούν τα tracking parameters εναλλακτικά indexable URLs;
• Αντιμετωπίζονται σωστά τα variation URLs;
• Συμφωνούν canonical, feed URL και Merchant Center landing page;

Pagination και filters

• Διαθέτει κάθε paginated page ξεχωριστό URL;
• Παραμένουν crawlable τα pagination links;
• Δημιουργούν τα filters ανεξέλεγκτα combinations;
• Έχουν οριστεί κανόνες indexation για σημαντικά filtered pages;

Product και image access

• Επιστρέφουν τα product pages HTTP 200;
• Είναι προσβάσιμα τα βασικά product images;
• Μπλοκάρει το CDN εξωτερικούς crawlers;
• Απαιτούν τα image URLs cookies ή προσωρινά tokens;

Errors και redirects

• Υπάρχουν 404 ή soft 404 product pages;
• Υπάρχουν redirect chains;
• Ανακατευθύνονται discontinued products χωρίς σχετικό replacement;
• Εμφανίζονται server errors ή timeouts;
• Επιστρέφει το feed URLs που δεν λειτουργούν πλέον;

Bot access

• Επιτρέπεται η πρόσβαση των απαραίτητων search και marketplace bots;
• Εφαρμόζει το WAF υπερβολικά αυστηρούς περιορισμούς αιτημάτων (rate limits) που εμποδίζουν το crawling;
• Μπλοκάρει το robots.txt κρίσιμα resources;
• Καταγράφονται τα blocked requests στα logs;

WooCommerce performance: τι πρέπει να ελέγχει το agency

Η απόδοση δεν αφορά μόνο τα Core Web Vitals.

Ένα αργό ή ασταθές WooCommerce environment μπορεί να προκαλέσει:

• timeout κατά τη δημιουργία feed,
• αποτυχημένο stock sync,
• καθυστερημένα scheduled actions,
• server errors σε crawlers,
• αποτυχία checkout,
• παλιές τιμές και διαθεσιμότητα σε marketplaces.

Μεγάλος αριθμός variations

Ένα variable product με πολλές εκατοντάδες combinations μπορεί να επιβαρύνει:

• το product editing screen,
• τα variation queries,
• το frontend variation selector,
• τα feeds,
• τα imports και exports,
• το stock sync.

Το agency πρέπει να εξετάσει αν όλοι οι συνδυασμοί αποτελούν πραγματικά αγοραζόμενα variations.

Σε ορισμένες περιπτώσεις, πρέπει να χωρίσει ένα υπερβολικά μεγάλο variable product σε περισσότερα λογικά προϊόντα, χωρίς να θυσιάσει τη σχέση μεταξύ τους.

Autoloaded options και wp_options

Themes και plugins αποθηκεύουν settings, cached data και άλλες πληροφορίες στο wp_options.

Όταν υπερβολικά πολλά δεδομένα έχουν ενεργοποιημένο autoload, το WordPress τα φορτώνει σε κάθε page request. Αυτό μπορεί να αυξήσει τον χρόνο απόκρισης και το database load. Η επίσημη WooCommerce τεκμηρίωση επισημαίνει επίσης ότι το object caching μπορεί να μειώσει τις επαναλαμβανόμενες αναγνώσεις από τη βάση.

Το agency πρέπει να ελέγχει:

• το συνολικό autoloaded data size,
• εγκαταλειμμένα options από παλιά plugins,
• μεγάλα serialized values,
• options που δημιουργούνται ξανά,
• αν το hosting υποστηρίζει persistent object cache.

Δεν πρέπει να διαγράφει options χωρίς backup και χωρίς να γνωρίζει ποιο plugin τα χρησιμοποιεί.

Transients και object caching

Το WooCommerce και τα plugins χρησιμοποιούν transients για να αποθηκεύουν προσωρινά δεδομένα.

Τα προβλήματα εμφανίζονται όταν:

• ληγμένα transients συσσωρεύονται,
• cache layers διατηρούν παλιά prices,
• cached stock status δεν ανανεώνεται,
• object cache και page cache εφαρμόζουν διαφορετικούς κανόνες,
• cache invalidation δεν λειτουργεί μετά από ERP sync.

Το agency πρέπει να ελέγχει αν η cache επιταχύνει το site χωρίς να εμφανίζει παλιές εμπορικές πληροφορίες.

WordPress cron και Action Scheduler

Το WooCommerce και πολλά extensions χρησιμοποιούν το Action Scheduler για background tasks, όπως webhooks, emails, subscription actions και άλλες προγραμματισμένες διαδικασίες. Το WooCommerce Status επιτρέπει τον έλεγχο completed, pending και failed actions.

Στο Agentic Commerce SEO context, η συσσώρευση πολλών εκκρεμών ή αποτυχημένων scheduled actions μπορεί να καθυστερήσει:

• product feed refresh,
• stock update,
• ERP import,
• webhook delivery,
• email επιβεβαίωσης,
• marketplace sync.

Το agency πρέπει να ελέγχει:

• τον αριθμό pending actions,
• την ηλικία του παλαιότερου pending action,
• failed actions,
• επαναλαμβανόμενα errors,
• memory limits,
• cron configuration,
• αν χρειάζεται πραγματικό server cron αντί του WP-Cron.

Μεγάλα catalogs και feed generation

Ένα feed plugin μπορεί να λειτουργεί σωστά σε 500 προϊόντα και να αποτυγχάνει σε 50.000 προϊόντα ή σε χιλιάδες variations.

Το agency πρέπει να μετρά:

• τον χρόνο δημιουργίας του feed,
• τη χρήση μνήμης,
• το μέγεθος του αρχείου,
• τη διάρκεια κάθε batch,
• το ποσοστό αποτυχημένων exports,
• αν χρησιμοποιείται incremental update,
• αν η δημιουργία feed επηρεάζει το checkout ή το frontend.

HPOS και extension compatibility

Το High-Performance Order Storage αλλάζει τον τρόπο αποθήκευσης των orders και στοχεύει σε καλύτερη κλιμάκωση της order management λειτουργίας. Τα extensions που διαβάζουν ή γράφουν order data πρέπει να υποστηρίζουν το HPOS και να δοκιμάζονται πριν από την ενεργοποίηση ή τη μετάβαση.

Το HPOS επηρεάζει κυρίως:

• ERP connectors,
• fulfillment plugins,
• payment gateways,
• order exports,
• reporting,
• checkout extensions.

Δεν διορθώνει από μόνο του τα product data ή τα feeds, αλλά αποτελεί κρίσιμο compatibility check για ένα σύγχρονο WooCommerce stack.

Checkout plugins στο WooCommerce

Το WooCommerce υποστηρίζει διαφορετικές checkout υλοποιήσεις, όπως το classic checkout και τα Cart and Checkout Blocks.

Δεν υποστηρίζουν όλα τα extensions κάθε checkout implementation με τον ίδιο τρόπο.

Το WooCommerce ζητά από τους extension developers να δηλώνουν compatibility και συστήνει manual testing για τον εντοπισμό interoperability issues.

Ποια plugins μπορούν να επηρεάσουν το checkout

Το agency πρέπει να ελέγχει:

• payment gateways,
• invoice και VAT fields,
• courier integrations,
• address validation,
• consent tools,
• discount plugins,
• loyalty systems,
• custom checkout fields,
• one-page checkout,
• fraud prevention,
• cart recovery.

Ένα plugin μπορεί να λειτουργεί στο classic checkout αλλά να μην υποστηρίζει πλήρως τα Checkout Blocks.

Η δήλωση compatibility δεν αντικαθιστά τη δοκιμή

Το agency πρέπει να εκτελεί πραγματικές δοκιμές σε staging και να καλύπτει:

• guest checkout,
• logged-in customer,
• mobile checkout,
• διαφορετικά payment methods,
• διαφορετικά shipping zones,
• coupons,
• δωρεάν μεταφορικά,
• failed payment,
• επιστροφή από payment gateway,
• αλλαγή stock κατά το checkout,
• order confirmation,
• transactional email.

Για τον αναλυτικό έλεγχο του καλαθιού, των πληρωμών, των στοιχείων αποστολής, της επιβεβαίωσης του χρήστη και της ασφαλούς ολοκλήρωσης της αγοράς, δείτε τον οδηγό μας για το Checkout Readiness για Agentic Commerce.

Stock sync μεταξύ WooCommerce, ERP, POS και marketplaces

Το e-shop πρέπει να ορίσει ένα σύστημα ως source of truth για το stock.

Αυτό μπορεί να είναι:

• το WooCommerce,
• το ERP,
• το POS,
• το warehouse management system,
• το middleware.

Το digital agency πρέπει να αποφεύγει μια αρχιτεκτονική στην οποία δύο συστήματα ενημερώνουν ταυτόχρονα την ίδια ποσότητα χωρίς κανόνες προτεραιότητας.

Το sync χρειάζεται σταθερό identifier

Τα συστήματα μπορούν να αναγνωρίζουν ένα προϊόν μέσω:

• WooCommerce product ID,
• variation ID,
• SKU,
• GTIN,
• ERP code.

Το agency πρέπει να επιλέξει identifier που:

• παραμένει μοναδικός,
• δεν αλλάζει κατά το redesign,
• υπάρχει και είναι καταχωρισμένος και στα δύο συστήματα, για παράδειγμα στο WooCommerce και στο ERP,
• διαχωρίζει σωστά τα variations.

Το WooCommerce REST API υποστηρίζει products, product variations, attributes και orders, ενώ τα webhooks μπορούν να ειδοποιούν εξωτερικά συστήματα όταν αλλάζουν products, orders ή άλλα entities.

Για μια αναλυτικότερη παρουσίαση του τρόπου με τον οποίο τα APIs και τα commerce protocols επιτρέπουν σε εξωτερικά συστήματα και AI agents να προσπελαύνουν προϊόντα, τιμές, απόθεμα, καλάθι και παραγγελίες, δείτε τον οδηγό μας για τα APIs και Commerce Protocols για Agentic Commerce.

Πώς δημιουργείται το overselling

Το overselling μπορεί να προκύψει όταν:

• το ERP ενημερώνει το stock αραιά,
• το marketplace δέχεται παραγγελία πριν από το επόμενο sync,
• το WooCommerce διαχειρίζεται stock στο parent,
• το ERP διαχειρίζεται stock στο variation,
• ένα webhook αποτυγχάνει,
• δύο plugins γράφουν διαφορετικές ποσότητες,
• η cache εμφανίζει παλιά availability,
• το feed συνεχίζει να δηλώνει διαθέσιμο εξαντλημένο προϊόν.

Το agency πρέπει να καθορίζει:

• συχνότητα sync,
• κατεύθυνση ενημέρωσης,
• retry policy,
• error logs,
• alerts,
• reconciliation process,
• fallback όταν το ERP δεν ανταποκρίνεται.

Conflicts από πολλά WooCommerce plugins

Ο αριθμός των plugins δεν αποτελεί μόνος του αξιόπιστο κριτήριο ποιότητας.

Ένα e-shop μπορεί να λειτουργεί σωστά με αρκετά plugins όταν κάθε plugin:

• εξυπηρετεί σαφή λειτουργία,
• παραμένει ενημερωμένο,
• έχει ελεγχθεί,
• δεν επεμβαίνει στα ίδια δεδομένα με άλλη λύση.

Αντίθετα, δύο plugins μπορούν να δημιουργήσουν σοβαρό conflict όταν επηρεάζουν το ίδιο field, output ή process.

Συχνές κατηγορίες conflicts

Τα συχνότερα προβλήματα περιλαμβάνουν:

• δύο feed plugins που στέλνουν τα ίδια προϊόντα,
• WooCommerce, theme και SEO plugin που παράγουν διαφορετικό Product schema,
• δύο stock connectors,
• πολλαπλά analytics plugins που καταγράφουν διπλές αγορές,
• δύο plugins που προσθέτουν τα ίδια checkout fields,
• cache plugin που αποθηκεύει δυναμική τιμή ή stock,
• security plugin που μπλοκάρει APIs και webhooks,
• optimization plugin που καθυστερεί scripts του checkout.

Τα conflicts δεν εξαρτώνται μόνο από τον συνολικό αριθμό των WooCommerce plugins. Εμφανίζονται κυρίως όταν δύο ή περισσότερα plugins διαχειρίζονται τα ίδια δεδομένα, παράγουν το ίδιο output ή τροποποιούν την ίδια λειτουργία του e-shop.

Σε mobile: σύρετε τον πίνακα οριζόντια για να δείτε όλες τις στήλες.

Πώς γίνεται σωστό conflict testing

Το agency πρέπει:

1. Να αναπαράγει το πρόβλημα.
2. Να καταγράψει συγκεκριμένο URL, προϊόν ή order.
3. Να δημιουργήσει backup.
4. Να χρησιμοποιήσει staging.
5. Να ελέγξει logs και scheduled actions.
6. Να απενεργοποιήσει plugins ανά λειτουργική ομάδα.
7. Να δοκιμάσει default theme, όταν χρειάζεται.
8. Να επαναλάβει ακριβώς το ίδιο test case.
9. Να καταγράψει το πραγματικό conflict.
10. Να επιβεβαιώσει τη λύση πριν ενημερώσει το production site.

Η γενική διατύπωση «φταίνε τα πολλά plugins» δεν βοηθά τον ιδιοκτήτη ούτε τον επόμενο developer.

Plugin governance

Κάθε agency πρέπει να διατηρεί plugin register με:

• όνομα plugin,
• λειτουργία,
• υπεύθυνο,
• license owner,
• δεδομένα που διαβάζει,
• δεδομένα που αλλάζει,
• εξωτερικές συνδέσεις,
• compatibility με HPOS,
• compatibility με Checkout Blocks,
• known conflicts,
• update process,
• replacement plan.

Πριν εγκαταστήσει νέο plugin, πρέπει να απαντήσει:

• Ποια ανάγκη καλύπτει;
• Υπάρχει ήδη plugin που καλύπτει την ίδια λειτουργία;
• Ποια δεδομένα θα αλλάζει;
• Πώς θα αφαιρεθεί;
• Μπορούμε να εξαγάγουμε τις ρυθμίσεις;
• Ποιος κατέχει τη συνδρομή;
• Τι θα συμβεί αν σταματήσει η υποστήριξη;

Agency handover: τι πρέπει να παραδοθεί μαζί με το WooCommerce e-shop

Το agency handover δεν πρέπει να περιορίζεται στην παράδοση ενός administrator password.

Ο ιδιοκτήτης πρέπει να παραλαμβάνει:

• το e-shop,
• τους λογαριασμούς,
• τα integrations,
• τα mappings,
• τις άδειες χρήσης,
• την τεκμηρίωση,
• τη γνώση που χρειάζεται για να συνεχίσει τη λειτουργία.

Ownership των λογαριασμών

Ο πελάτης πρέπει να διατηρεί την ιδιοκτησία των βασικών accounts:

• domain registrar,
• DNS,
• hosting,
• WordPress,
• Google Merchant Center,
• Search Console,
• analytics,
• Skroutz,
• BestPrice,
• payment gateways,
• CDN,
• security services,
• plugin licenses, όπου είναι εφικτό.

Το agency πρέπει να χρησιμοποιεί ξεχωριστό account και όχι κοινόχρηστους κωδικούς.

Δεν χρειάζεται κάθε συνεργάτης Administrator access. Το agency πρέπει να αποδίδει τον κατάλληλο ρόλο ανάλογα με τις εργασίες, όπως Shop Manager για καθημερινή διαχείριση του καταστήματος, όταν δεν απαιτείται πλήρης διαχειριστική πρόσβαση.

Product data documentation

Το handover πρέπει να εξηγεί:

• ποια attributes χρησιμοποιούνται,
• ποια είναι global,
• ποια attributes δημιουργούν variations,
• πού αποθηκεύεται το SKU,
• πού αποθηκεύεται το GTIN,
• ποιο πεδίο χρησιμοποιεί το ERP,
• ποια fields είναι υποχρεωτικά ανά κατηγορία,
• ποιοι κανόνες ονοματολογίας ισχύουν.

Feed documentation

Για κάθε feed πρέπει να καταγράφονται:

• κανάλι,
• plugin ή integration,
• feed URL ή API connection,
• product ID logic,
• mappings,
• exclusions,
• custom rules,
• refresh frequency,
• logs,
• υπεύθυνος,
• validation process.

Schema documentation

Το handover πρέπει να αναφέρει:

• ποιο component παράγει το Product schema,
• ποια schema functions έχουν απενεργοποιηθεί,
• αν υπάρχει custom JSON-LD,
• πώς αντιμετωπίζονται τα variations,
• πώς γίνεται το validation,
• πότε πραγματοποιείται επανέλεγχος.

Stock και checkout integrations

Το agency πρέπει να παραδώσει:

• source of truth για το stock,
• sync direction,
• identifier,
• API και webhook ownership,
• retry logic,
• error logs,
• alerts,
• payment methods,
• shipping integrations,
• custom checkout fields,
• χρήση classic checkout ή Checkout Blocks,
• test scenarios.

Technical handover

Το WooCommerce System Status Report συγκεντρώνει πληροφορίες για το WordPress, το WooCommerce, τον server, τη βάση, το theme, τα plugins και τα scheduled actions. Αποτελεί χρήσιμο μέρος του handover, αλλά δεν αντικαθιστά την αναλυτική τεκμηρίωση.

Το technical package πρέπει να περιλαμβάνει:

• System Status Report,
• plugin register,
• theme και child theme,
• custom code,
• repository ή version history,
• scheduled actions,
• server cron jobs,
• backup policy,
• staging access,
• update procedure,
• rollback procedure,
• known issues,
• open technical debt.

Εκπαίδευση του ιδιοκτήτη και της ομάδας του

Η τεκμηρίωση δεν αρκεί όταν κανείς στην επιχείρηση δεν γνωρίζει πώς να τη χρησιμοποιήσει.

Το agency πρέπει να εκπαιδεύσει τον ιδιοκτήτη ή την ομάδα του στα καθημερινά tasks.

Η εκπαίδευση πρέπει να καλύπτει:

• πώς δημιουργείται ένα νέο simple product,
• πώς δημιουργείται ένα variable product,
• πώς προστίθεται ένα variation,
• πού καταχωρίζονται SKU και GTIN,
• πώς επιλέγονται τα υπάρχοντα global attributes,
• πότε δεν πρέπει να δημιουργείται νέο attribute term,
• πώς ενημερώνεται η τιμή και το stock,
• πώς ελέγχεται ένα failed feed,
• πού εμφανίζονται scheduled-action errors,
• ποια αλλαγή απαιτεί agency ή developer.

Το agency πρέπει να διαχωρίζει:

Αλλαγές που μπορεί να κάνει με ασφάλεια η επιχείρηση

• ενημέρωση περιγραφής,
• αλλαγή τιμής,
• ενημέρωση stock,
• προσθήκη εγκεκριμένων attribute values,
• αντικατάσταση εικόνας με τις σωστές προδιαγραφές.

Αλλαγές που χρειάζονται τεχνικό έλεγχο

• εγκατάσταση plugin,
• αλλαγή feed plugin,
• δημιουργία νέου GTIN field,
• αλλαγή SKU logic,
• αλλαγή stock source of truth,
• αλλαγή checkout,
• τροποποίηση schema,
• αλλαγή URL structure,
• αλλαγή cache ή security rules.

WooCommerce Agentic Commerce SEO pre-launch checklist

Πριν από το go-live, το digital agency πρέπει να ελέγχει συστηματικά τα product data, τα feeds, τα structured data, την crawlability, το checkout και τις integrations του WooCommerce e-shop. Το παρακάτω pre-launch checklist βοηθά το agency και τον ιδιοκτήτη του e-shop να επιβεβαιώσουν ότι οι βασικές λειτουργίες έχουν δοκιμαστεί.

Σε mobile: σύρετε τον πίνακα οριζόντια για να δείτε όλες τις στήλες.

Τα συχνότερα λάθη σε WooCommerce υλοποιήσεις

Attributes ως ελεύθερο κείμενο

Το e-shop δεν μπορεί να χρησιμοποιήσει αξιόπιστα τα ίδια values σε variations, filters και feeds.

Ίδιο GTIN σε διαφορετικά variations

Τα feeds και οι πλατφόρμες δεν μπορούν να διαχωρίσουν σωστά τις αγοραζόμενες επιλογές.

Διαφορετικά IDs ανά feed

Το agency δυσκολεύεται να συνδέσει diagnostics, conversions και stock updates με το σωστό προϊόν.

Πολλαπλά Product schema outputs

Οι μηχανές λαμβάνουν αντικρουόμενες πληροφορίες για τιμή, stock ή product identity.

Stock ενημερωμένο μόνο στο ERP

Το product page, το feed και το marketplace συνεχίζουν να εμφανίζουν παλιά διαθεσιμότητα.

Feed με αραιή ενημέρωση

Το προϊόν μπορεί να εξαντληθεί ή να αλλάξει τιμή πριν από το επόμενο refresh.

Product και image URLs μπλοκαρισμένα

Το XML παραμένει διαθέσιμο, αλλά το κανάλι δεν μπορεί να επαληθεύσει το προϊόν.

Checkout plugin χωρίς πλήρη compatibility

Το checkout μπορεί να λειτουργεί σε desktop αλλά να αποτυγχάνει σε mobile, σε συγκεκριμένη πληρωμή ή στα Checkout Blocks.

Custom mappings χωρίς documentation

Η επόμενη αλλαγή plugin ή agency ακυρώνει ρυθμίσεις που κανείς δεν γνώριζε.

Μεγάλα autoloaded data

Παλιά options, plugins και serialized settings μπορούν να επιβαρύνουν κάθε page request και να καθυστερούν product pages, feeds και checkout.

Accounts στο όνομα του agency

Ο πελάτης χάνει τον έλεγχο του Merchant Center, των marketplaces ή των plugin licenses όταν λήξει η συνεργασία.

Τι πρέπει να ζητήσει ο ιδιοκτήτης ενός WooCommerce e-shop

Ο ιδιοκτήτης δεν χρειάζεται να γνωρίζει κάθε τεχνική λεπτομέρεια.

Πρέπει όμως να ζητά σαφείς απαντήσεις:

• Ποιο σύστημα αποτελεί το source of truth για τα προϊόντα;
• Πού αποθηκεύονται το SKU και το GTIN;
• Ποιο plugin παράγει κάθε feed;
• Πώς ενημερώνεται το stock;
• Ποιο component παράγει το Product schema;
• Πώς εντοπίζονται τα feed errors;
• Ποιος ελέγχει το Merchant Center;
• Ποιος κατέχει τους λογαριασμούς;
• Μπορούν να εξαχθούν τα mappings;
• Τι συμβαίνει αν λήξει ένα plugin subscription;
• Τι θα παραδώσει το agency;
• Πώς δοκιμάζονται τα updates;
• Πώς επανέρχεται το site μετά από πρόβλημα;
• Ποια εκπαίδευση θα λάβει η ομάδα;

Τι πρέπει να τεκμηριώσει το digital agency

Το digital agency πρέπει να παραδίδει μια WooCommerce εγκατάσταση που μπορεί να ελεγχθεί, να συντηρηθεί και να εξελιχθεί.

Πρέπει να τεκμηριώνει:

• το product data model,
• τα global attributes,
• τη λογική των variations,
• το default variation strategy,
• τα SKU και GTIN fields,
• τα feed mappings,
• το schema ownership,
• το stock sync,
• τα checkout plugins,
• τις scheduled actions,
• τα cache rules,
• τα εξωτερικά integrations,
• τα accounts,
• τα licenses,
• το testing process,
• το handover process,
• την εκπαίδευση του πελάτη.

Αυτή η τεκμηρίωση δεν αποτελεί πρόσθετη πολυτέλεια. Αποτελεί μέρος της ποιότητας του e-shop.

Το WooCommerce πρέπει να λειτουργεί ως ενιαίο commerce data system

Ένα WooCommerce e-shop δεν γίνεται έτοιμο για το Agentic Commerce SEO επειδή εγκατέστησε feed plugin, schema plugin ή «AI plugin».

Γίνεται πιο αξιόπιστο όταν:

• οργανώνει σωστά τα product attributes,
• διαχωρίζει καθαρά τα variations,
• χρησιμοποιεί σωστά SKU και GTIN,
• διατηρεί ένα source of truth,
• στέλνει συνεπή feeds,
• παράγει καθαρά structured data,
• ενημερώνει έγκαιρα το stock,
• επιτρέπει την πρόσβαση στα product pages,
• διατηρεί σταθερό checkout,
• ελέγχει την απόδοση,
• περιορίζει τα plugin conflicts,
• παραδίδει πλήρη τεκμηρίωση και εκπαίδευση.

Τα search engines, τα marketplaces και τα AI systems δεν βλέπουν τις ρυθμίσεις μέσα στο WordPress admin.

Βλέπουν το τελικό αποτέλεσμα:

• τη σελίδα,
• το feed,
• το schema,
• την τιμή,
• τη διαθεσιμότητα,
• τη δυνατότητα ολοκλήρωσης της αγοράς.

Για αυτό, τα digital agencies πρέπει να σχεδιάζουν το WooCommerce ως ενιαίο σύστημα εμπορικών δεδομένων.

Οι ιδιοκτήτες e-shops πρέπει να απαιτούν συνέπεια, έλεγχο και πραγματική ιδιοκτησία των λογαριασμών και των δεδομένων τους.

Εάν επιθυμείτε να αξιολογήσετε αν το WooCommerce e-shop σας διαθέτει συνεπή product data, feeds, structured data, stock integrations και checkout, διαβάστε το άρθρο Agentic Commerce Readiness Audit για E-shop.

Συχνές ερωτήσεις για το WooCommerce και το Agentic Commerce SEO

Τι σημαίνει Agentic Commerce SEO για ένα WooCommerce e-shop;

Agentic Commerce SEO για ένα WooCommerce e-shop σημαίνει ότι το κατάστημα οργανώνει τα product data, τα feeds, τα structured data, το stock και το checkout με τρόπο που επιτρέπει στις μηχανές αναζήτησης, στα AI systems και στα commerce platforms να καταλαβαίνουν αξιόπιστα τα προϊόντα.

Δεν αφορά μόνο το περιεχόμενο του product page. Αφορά τη συνέπεια ολόκληρης της ροής, από το WooCommerce backend έως το Google Merchant Center, το Skroutz, το BestPrice και τα υπόλοιπα integrations.

Χρειάζεται ένα WooCommerce e-shop ειδικό AI plugin;

Όχι. Ένα WooCommerce e-shop δεν γίνεται έτοιμο για Agentic Commerce με την εγκατάσταση ενός plugin που χρησιμοποιεί τον όρο AI.

Προτεραιότητα έχουν:

• η σωστή δομή των προϊόντων,
• τα συνεπή attributes,
• τα σωστά SKU και GTIN,
• τα αξιόπιστα feeds,
• τα καθαρά structured data,
• το ενημερωμένο stock,
• το σταθερό checkout.

Ένα plugin μπορεί να βοηθήσει μια συγκεκριμένη λειτουργία, αλλά δεν διορθώνει μόνο του μια ασυνεπή αρχιτεκτονική.

Ποια είναι η διαφορά μεταξύ global και custom attributes στο WooCommerce;

Τα global attributes δημιουργούνται κεντρικά και μπορούν να χρησιμοποιηθούν σε πολλά προϊόντα, variations και filters.

Τα custom product attributes προστίθενται σε ένα συγκεκριμένο προϊόν.

Ένα agency πρέπει να χρησιμοποιεί global attributes όταν ένα χαρακτηριστικό επαναλαμβάνεται, δημιουργεί variations ή χρειάζεται mapping προς feeds και marketplaces.

Ποια είναι η διαφορά μεταξύ SKU και GTIN ή EAN;

Το SKU αποτελεί εσωτερικό κωδικό που δημιουργεί το κατάστημα ή το ERP.

Το GTIN αποτελεί διεθνές αναγνωριστικό προϊόντος. Το EAN είναι μία μορφή GTIN.

Το κατάστημα δεν πρέπει να χρησιμοποιεί το SKU ως GTIN. Αν ο κατασκευαστής δεν έχει αποδώσει GTIN, το e-shop δεν πρέπει να κατασκευάζει αυθαίρετο κωδικό.

Διαθέτει το WooCommerce ενσωματωμένο πεδίο για GTIN ή EAN;

Ναι. Οι σύγχρονες εκδόσεις του WooCommerce διαθέτουν Global Unique ID field για GTIN, UPC, EAN ή ISBN.

Το agency πρέπει να ελέγχει αν το feed plugin και το ERP διαβάζουν ή ενημερώνουν το συγκεκριμένο native field πριν εγκαταστήσει επιπλέον GTIN plugin.

Πρέπει κάθε variation να έχει ξεχωριστό SKU και GTIN;

Κάθε variation πρέπει να έχει ξεχωριστό SKU όταν αποτελεί διαφορετική αγοραζόμενη επιλογή και το stock παρακολουθείται ανεξάρτητα.

Πρέπει επίσης να έχει ξεχωριστό GTIN όταν ο κατασκευαστής έχει αποδώσει διαφορετικό barcode στη συγκεκριμένη επιλογή, όπως διαφορετικό μέγεθος ή χρώμα.

Δεν πρέπει να αντιγράφεται μηχανικά το GTIN του parent product σε όλα τα variations.

Τι είναι το default variation και γιατί χρειάζεται έλεγχο;

Το default variation είναι η επιλογή που εμφανίζει αρχικά το WooCommerce σε ένα variable product.

Ένα λανθασμένο default variation μπορεί να εμφανίζει λάθος εικόνα, τιμή ή επιλογή. Σε προϊόντα όπου το μέγεθος ή η συμβατότητα αποτελεί κρίσιμη απόφαση, το e-shop μπορεί να αφήνει τον χρήστη να επιλέξει ο ίδιος πριν προσθέσει το προϊόν στο καλάθι.

Μπορεί ένα feed plugin να εξυπηρετεί Google, Skroutz και BestPrice;

Μπορεί, εφόσον υποστηρίζει σωστά τις διαφορετικές προδιαγραφές και επιτρέπει ξεχωριστά mappings ανά κανάλι.

Το agency δεν πρέπει να θεωρεί ότι ένα κοινό feed configuration αρκεί για όλες τις πλατφόρμες.

Πρέπει να ελέγχει ξεχωριστά:

• product IDs,
• categories,
• availability,
• variations,
• shipping,
• εικόνες,
• required fields.

Πώς επιλέγεται το κατάλληλο WooCommerce feed plugin;

Το agency πρέπει να αξιολογεί:

• υποστήριξη simple και variable products,
• native GTIN field,
• custom mappings,
• category mapping,
• logs,
• update frequency,
• μεγάλα catalogs,
• δυνατότητα export των ρυθμίσεων,
• κόστος συνδρομής,
• proprietary dependencies,
• migration και exit plan.

Η τελική επιλογή πρέπει να βασίζεται στο πραγματικό output και όχι μόνο στη σελίδα παρουσίασης του plugin.

Γιατί εμφανίζονται price και availability mismatches στο Merchant Center;

Τα mismatches μπορούν να προκύψουν από:

• καθυστερημένο feed refresh,
• προβληματικό cron,
• cache,
• dynamic pricing,
• λανθασμένες ημερομηνίες προσφοράς,
• stock στο parent αντί στο variation,
• αποτυχημένο ERP sync,
• διαφορετικό tax ή currency setup.

Το agency πρέπει να συγκρίνει product page, WooCommerce backend, feed και Merchant Center.

Χρειάζεται ξεχωριστό feed για το Skroutz και το BestPrice;

Συνήθως χρειάζεται τουλάχιστον ξεχωριστό configuration, ακόμη και όταν το ίδιο plugin παράγει και τα δύο feeds.

Οι πλατφόρμες έχουν διαφορετικές απαιτήσεις για:

• unique IDs,
• categories,
• availability,
• variations,
• shipping,
• weight,
• product titles.

Μπορούν να λειτουργούν ταυτόχρονα πολλά schema plugins;

Τεχνικά μπορούν, αλλά συχνά δημιουργούν duplicate ή conflicting Product entities.

Το agency πρέπει να ορίσει ποιο component παράγει το βασικό Product structured data και να απενεργοποιήσει overlapping λειτουργίες όταν χρειάζεται.

Ο έλεγχος πρέπει να γίνεται στο τελικό rendered JSON-LD.

Πώς ελέγχεται το crawlability ενός WooCommerce e-shop;

Το agency πρέπει να ελέγχει:

• HTML links προς προϊόντα,
• category structure,
• pagination,
• XML sitemap,
• canonical URLs,
• faceted navigation,
• product και image access,
• 404 και redirects,
• server errors,
• WAF και CDN blocks.

Πρέπει επίσης να ελέγχει αν τα marketplace bots μπορούν να προσπελάσουν το XML, τα product pages και τις εικόνες.

Πώς επηρεάζει το performance το Agentic Commerce SEO;

Η κακή απόδοση μπορεί να προκαλέσει:

• αργά product pages,
• server errors,
• αποτυχημένο feed generation,
• καθυστερημένο stock sync,
• προβλήματα στο checkout,
• παλιές τιμές και availability.

Τα agencies πρέπει να ελέγχουν όχι μόνο τα Core Web Vitals αλλά και το cron, το Action Scheduler, το autoloaded data, την cache, τα transients και τη διάρκεια των feed exports.

Τι είναι το Action Scheduler και γιατί είναι σημαντικό;

Το Action Scheduler διαχειρίζεται background tasks πολλών WooCommerce plugins.

Μπορεί να χρησιμοποιείται για:

• webhooks,
• imports,
• exports,
• feed updates,
• emails,
• subscriptions,
• άλλες προγραμματισμένες εργασίες.

Μια ουρά με failed ή παλιά pending actions μπορεί να σημαίνει ότι κρίσιμα δεδομένα δεν ενημερώνονται εγκαίρως.

Ποιο σύστημα πρέπει να αποτελεί το source of truth για το stock;

Η επιχείρηση πρέπει να επιλέξει ένα βασικό σύστημα, όπως το WooCommerce, το ERP, το POS ή ένα warehouse management system.

Δεν υπάρχει μία σωστή επιλογή για όλα τα e-shops.

Το σημαντικό είναι να οριστούν:

• η κατεύθυνση του sync,
• το κοινό identifier,
• η συχνότητα,
• το retry policy,
• το error handling,
• η διαδικασία reconciliation.

Πόσα plugins θεωρούνται πολλά σε ένα WooCommerce e-shop;

Δεν υπάρχει ένας ασφαλής αριθμός για όλα τα e-shops.

Το βασικό πρόβλημα δεν είναι μόνο ο αριθμός, αλλά το overlap.

Δύο plugins μπορούν να δημιουργήσουν σοβαρό conflict όταν:

• γράφουν στο ίδιο stock,
• παράγουν το ίδιο schema,
• στέλνουν το ίδιο feed,
• τροποποιούν τα ίδια checkout fields,
• καταγράφουν διπλά conversions.

Τι πρέπει να περιλαμβάνει το agency handover;

Το handover πρέπει να περιλαμβάνει:

• ownership των accounts,
• product data model,
• attributes και variations,
• SKU και GTIN logic,
• feed mappings,
• schema ownership,
• stock integrations,
• checkout setup,
• plugin register,
• licenses,
• backups,
• staging,
• rollback procedure,
• γνωστά προβλήματα,
• εκπαίδευση της ομάδας.

Ποιοι λογαριασμοί πρέπει να ανήκουν στον ιδιοκτήτη του e-shop;

Ο ιδιοκτήτης πρέπει να διατηρεί τον έλεγχο τουλάχιστον για:

• domain,
• DNS,
• hosting,
• WordPress,
• Merchant Center,
• Search Console,
• analytics,
• Skroutz,
• BestPrice,
• payment gateways,
• plugin subscriptions όπου είναι εφικτό.

Το agency πρέπει να έχει ξεχωριστό access και όχι να κατέχει τους βασικούς λογαριασμούς.

Πόσο συχνά πρέπει να ελέγχεται ένα WooCommerce e-shop;

Το agency πρέπει να πραγματοποιεί έλεγχο:

• πριν από το go-live,
• μετά από major WooCommerce update,
• μετά από αλλαγή theme,
• μετά από αλλαγή feed ή schema plugin,
• μετά από σύνδεση ERP,
• μετά από σημαντική αύξηση του catalog,
• όταν εμφανιστούν feed errors ή stock mismatches.

Ο έλεγχος δεν πρέπει να αποτελεί αποκλειστικά ετήσια διαδικασία. Τα κρίσιμα diagnostics, logs και scheduled actions χρειάζονται τακτική παρακολούθηση.

Πηγές

WooCommerce

• Managing Product Categories, Tags and Attributes
• Variable Products
• Product CSV Importer and Exporter
• GTIN Documentation – Google for WooCommerce
• Google for WooCommerce
• Google for WooCommerce Attribute Mapping
• WP_options Table and Site Speed
• WooCommerce Scheduled Actions
• A Large Store’s Guide to Enable HPOS on WooCommerce
• High Performance Order Storage
• Compatibility and Interoperability for WooCommerce Extensions
• Getting Started with Cart and Checkout Extensibility
• WooCommerce REST API v3
• WooCommerce Webhooks
• How to Test for Plugin and Theme Conflicts
• Understanding the WooCommerce System Status Report

Google Merchant Center και Google Search

• Product Data Specification
• About Unique Product Identifiers
• Merchant Listing Product and Offer Structured Data
• Product Variant Structured Data: ProductGroup and Product
• Help Google Understand Your Ecommerce Website Structure
• Ecommerce URL Structure Best Practices
• Pagination, Incremental Page Loading and Their Impact on Google Search
• Managing Crawling of Faceted Navigation URLs
• Troubleshoot Google Search Crawling Errors

Skroutz

• Products Overview – Skroutz Developer
• XML Data Feed Specification – Skroutz Developer

BestPrice

• Πως μπορώ να ορίσω το κόστος αποστολής για τα προϊόντα μου;
• Πώς θα προσθέσω το κόστος αποστολής ενός προϊόντος (Shipping) στο XML αρχείο μου;
• Ενημέρωσα το αρχείο XML και το πεδίο “Shipping”. Πότε θα εμφανιστεί το κόστος αποστολής;