Το canonical tag είναι πρόταση προς τη Google, όχι εντολή. Η Google το αγνοεί συχνότερα απ' όσο νομίζετε.
Η λέξη-κλειδί που κρύβεται μέσα στο όνομα
Canonical σημαίνει "επίσημο, αναγνωρισμένο ως αυθεντικό". Οι περισσότεροι το ακούνε και υποθέτουν ότι πρόκειται για εντολή: βάζεις μια ετικέτα, η Google την υπακούει, τέλος. Δεν είναι έτσι, και αυτή η παρανόηση είναι ο λόγος που τόσα sites έχουν σπασμένη υλοποίηση χωρίς να το ξέρουν.
Το rel="canonical" είναι υπόδειξη, όχι directive. Η Google το λαμβάνει υπόψη μαζί με άλλα σήματα (εσωτερικά links, το sitemap, τα redirects, ακόμα και το πόσο πανομοιότυπο είναι πραγματικά το περιεχόμενο δύο σελίδων) και αποφασίζει μόνη της ποια σελίδα θα δείξει ως "canonical" στα αποτελέσματα αναζήτησης. Αν τα σήματα είναι αντικρουόμενα, η Google αγνοεί την ετικέτα σας και διαλέγει μόνη της. Αυτό εκπλήσσει σχεδόν κάθε ιδιοκτήτη site την πρώτη φορά που το μαθαίνει.
Η ερώτηση λοιπόν δεν είναι "πώς βάζω canonical tag". Είναι "πώς στέλνω αρκετά συνεπή σήματα ώστε η Google να μην έχει λόγο να διαφωνήσει μαζί μου".
Τι κάνει πραγματικά το canonical tag
Ένα website σχεδόν πάντα δημιουργεί πολλαπλές διευθύνσεις URL για το ίδιο περιεχόμενο, συχνά χωρίς να το καταλαβαίνει κανείς. Παραδείγματα που βλέπουμε κάθε εβδομάδα σε audits:
example.gr/proiontaκαιexample.gr/proionta/(με και χωρίς κάθετο)example.gr/proionta?sort=priceκαιexample.gr/proionta?sort=name(παράμετροι φιλτραρίσματος)example.gr/proiontaκαιexample.gr/en/products(γλωσσικές εκδόσεις χωρίς σωστό hreflang)- HTTP και HTTPS εκδόσεις της ίδιας σελίδας ταυτόχρονα ζωντανές
Χωρίς canonical tag, η Google βλέπει αυτές τις εκδόσεις σαν ξεχωριστές σελίδες με πανομοιότυπο ή σχεδόν πανομοιότυπο περιεχόμενο: δηλαδή duplicate content. Το αποτέλεσμα δεν είναι ποινή, όπως πολλοί φοβούνται. Είναι κάτι πιο ύπουλο: η "αξία" της σελίδας (backlinks, click-through, χρόνος παραμονής) μοιράζεται ανάμεσα σε πολλαπλά URLs αντί να συγκεντρώνεται σε ένα. Μια σελίδα με 10 backlinks χωρισμένα σε 3 εκδόσεις URL καταλήγει αδύναμη και στις τρεις.
Το canonical tag λέει στη Google: "όλες αυτές οι εκδόσεις είναι το ίδιο πράγμα, συγκέντρωσε την αξία εδώ". Αν λειτουργήσει σωστά, εξοικονομεί εσάς από μια δεύτερη δουλειά: να διαχειρίζεστε duplicate content διόρθωση μέσω πιο επεμβατικών μεθόδων όπως redirects.
Self-referencing canonicals: το αόρατο θεμέλιο
Η πιο σημαντική, και πιο παραμελημένη, χρήση του canonical tag είναι η πιο βαρετή: κάθε σελίδα πρέπει να έχει canonical tag που δείχνει στον εαυτό της. Όχι μόνο οι "προβληματικές" σελίδες με duplicate ρίσκο: όλες.
Γιατί; Επειδή οι παράμετροι URL δημιουργούνται με τρόπους που δεν ελέγχετε πάντα εσείς. Κάποιος μοιράζεται ένα link με UTM parameters για tracking καμπάνιας (?utm_source=facebook), ένα άλλο εργαλείο προσθέτει session ID, ένα τρίτο προσθέτει affiliate tag. Χωρίς self-referencing canonical, κάθε μία από αυτές τις παραλλαγές είναι τεχνικά ξεχωριστό URL στα μάτια ενός crawler. Με self-referencing canonical, όλες επιστρέφουν αυτόματα στην "καθαρή" έκδοση.
Αυτό είναι το πρώτο πράγμα που ελέγχουμε σε κάθε technical audit, πριν κοιτάξουμε οτιδήποτε πιο σύνθετο.
Cross-domain canonicals: όταν το περιεχόμενο υπάρχει αλλού
Λιγότερο συχνή, αλλά εξίσου χρήσιμη περίπτωση: όταν δημοσιεύετε το ίδιο περιεχόμενο σε δύο διαφορετικά domains, για παράδειγμα ένα δελτίο τύπου που ανεβαίνει και στο δικό σας site και σε ένα portal ειδήσεων. Το cross-domain canonical στέλνει στη Google το σήμα "η αυθεντική εκδοχή είναι εδώ, στο δικό μου domain, όχι εκεί".
Αυτό απαιτεί συνεργασία και των δύο πλευρών: αν το portal δεν σέβεται το αίτημα, η Google μπορεί να διαλέξει το δικό του URL ως canonical, ειδικά αν το portal έχει μεγαλύτερη αυθεντία. Είναι ένα ακόμα παράδειγμα του γιατί το canonical tag είναι πρόταση και όχι νόμος.
Canonical vs 301 redirect vs noindex: τρία εργαλεία, τρεις σκοποί
Η σύγχυση ανάμεσα σε αυτά τα τρία είναι το πιο συχνό λάθος που βλέπουμε σε audits πελατών που ήρθαν από άλλο agency ή από αυτοδιαχειριζόμενο WordPress.
Χρησιμοποιήστε 301 redirect όταν η παλιά σελίδα δεν πρέπει να υπάρχει καθόλου πια, π.χ. μετά από αλλαγή δομής URL, ή κατά τη διάρκεια ενός migration website seo. Το redirect είναι οριστικό: ο χρήστης και ο crawler και οι δύο καταλήγουν στη νέα διεύθυνση.
Χρησιμοποιήστε canonical tag όταν και οι δύο εκδόσεις πρέπει να παραμείνουν προσβάσιμες, π.χ. μια σελίδα προϊόντος που εμφανίζεται και κάτω από δύο διαφορετικές κατηγορίες με δύο URLs. Ο χρήστης μπορεί να επισκεφτεί οποιαδήποτε εκδοχή, αλλά η Google συγκεντρώνει την αξία σε μία.
Χρησιμοποιήστε noindex όταν θέλετε η σελίδα να μην εμφανίζεται καθόλου στα αποτελέσματα αναζήτησης, αλλά να παραμένει προσβάσιμη σε χρήστες και crawler, π.χ. σελίδες φίλτρων εσωτερικού αναζήτησης, ή σελίδες "ευχαριστούμε" μετά από φόρμα.
Το λάθος που καταστρέφει sites: να βάζετε canonical tag σε μια σελίδα ΚΑΙ noindex ταυτόχρονα, δίνοντας αντικρουόμενα σήματα. Η Google σε αυτή την περίπτωση συχνά αγνοεί και τα δύο και αποφασίζει μόνη της, κάτι που σημαίνει ότι χάσατε τον έλεγχο ακριβώς στο σημείο που προσπαθούσατε να τον ασκήσετε.
Canonical chains: το λάθος που κανείς δεν βλέπει μέχρι να είναι αργά
Ένα canonical chain συμβαίνει όταν η σελίδα Α δείχνει canonical στη σελίδα Β, η οποία με τη σειρά της δείχνει canonical σε μια σελίδα Γ. Η Google επίσημα υποστηρίζει ότι ακολουθεί την αλυσίδα μέχρι το τέλος, αλλά στην πράξη η αξιοπιστία του σήματος πέφτει με κάθε επιπλέον κρίκο. Το βλέπουμε συχνά μετά από επαναλαμβανόμενες αλλαγές δομής URL χωρίς καθαρισμό: κάθε migration προσθέτει έναν ακόμα κρίκο στην αλυσίδα, κανείς δεν επιστρέφει να τη διορθώσει, και μετά από τρία-τέσσερα χρόνια το site έχει αλυσίδες πέντε επιπέδων που κανείς στην ομάδα δεν θυμάται γιατί υπάρχουν.
Η λύση είναι μηχανική, όχι εννοιολογική: κάθε φορά που αλλάζετε δομή URL, ενημερώνετε όλα τα canonical tags να δείχνουν απευθείας στην τελική διεύθυνση, όχι στην προηγούμενη. Ένα καλό technical audit ελέγχει αυτό ρητά, ακολουθώντας κάθε canonical μέχρι το τέλος της αλυσίδας του.
Πώς το canonical tag συνδέεται με το internal linking
Υπάρχει μια λεπτή αλλά σημαντική σχέση ανάμεσα στο canonical tag και στην εσωτερική διασύνδεση seo του site σας. Αν όλα τα εσωτερικά σας links δείχνουν προς την παράμετρο-εκδοχή ενός URL, ενώ το canonical tag δείχνει προς την καθαρή εκδοχή, στέλνετε αντικρουόμενα σήματα εξουσίας: τα links "ψηφίζουν" για μια σελίδα, το canonical tag "ψηφίζει" για άλλη.
Ο κανόνας που εφαρμόζουμε: όλα τα εσωτερικά links πρέπει να δείχνουν απευθείας στην canonical εκδοχή του URL, ποτέ σε παραλλαγές με παραμέτρους. Αυτό φαίνεται προφανές γραμμένο εδώ. Είναι σπάνιο στην πράξη, ειδικά σε e-shops όπου τα links προς κατηγορίες προϊόντων παράγονται δυναμικά από φίλτρα και συχνά κουβαλάνε τις παραμέτρους του φίλτρου μέσα στο ίδιο το URL του link.
Τι ελέγχουμε σε κάθε technical audit
Το τεστ canonical tags που τρέχουμε σε κάθε νέο πελάτη έχει πέντε βήματα, με αυτή τη σειρά:
- Self-referencing canonicals σε όλες τις βασικές σελίδες. Ελέγχουμε ότι κάθε σελίδα δηλώνει τον εαυτό της.
- Συνέπεια με το sitemap. Κάθε URL στο sitemap πρέπει να είναι η canonical εκδοχή του, όχι μια παραλλαγή. Ασυνέπεια εδώ είναι από τα πιο συχνά λάθη σε αυτόματα παραγόμενα sitemaps.
- Συνέπεια με τα εσωτερικά links. Όπως περιγράφηκε παραπάνω.
- Έλεγχος για canonical chains. Ακολουθούμε κάθε canonical μέχρι το τελικό URL.
- Έλεγχος αντικρουόμενων σημάτων με noindex/redirects. Καμία σελίδα δεν πρέπει να έχει canonical tag προς μια διεύθυνση που είναι ταυτόχρονα noindex ή redirected αλλού.
Αυτά τα πέντε βήματα λύνουν το 95% των προβλημάτων canonical που συναντάμε. Το υπόλοιπο 5% είναι εξειδικευμένες περιπτώσεις: πολυγλωσσικά sites όπου το canonical μπερδεύεται με το hreflang, ή JavaScript-rendered σελίδες όπου το canonical tag τοποθετείται client-side και ο crawler δεν προλαβαίνει πάντα να το διαβάσει πριν αποφασίσει.
Ένα παράδειγμα από την πράξη
Σε ένα audit που κάναμε πρόσφατα, ένα e-shop είχε την ίδια σελίδα προϊόντος προσβάσιμη μέσω τεσσάρων διαφορετικών URLs: μία για κάθε κατηγορία στην οποία ανήκε το προϊόν. Καμία δεν είχε canonical tag. Το αποτέλεσμα: η Google είχε ευρετηριάσει και τα τέσσερα URLs ξεχωριστά, το κάθε ένα με 1-2 backlinks, και κανένα δεν κατατασσόταν στην πρώτη σελίδα αποτελεσμάτων για το βασικό keyword του προϊόντος.
Η διόρθωση ήταν μία γραμμή κώδικα ανά σελίδα προϊόντος: self-referencing canonical στην "πρωτεύουσα" κατηγορία του προϊόντος, με τις υπόλοιπες τρεις URLs να δηλώνουν κανονικά αυτή την πρωτεύουσα εκδοχή. Μέσα σε έξι εβδομάδες, η Google είχε συγκεντρώσει την αξία, και η σελίδα προϊόντος ανέβηκε από τη σελίδα 3 στη θέση 6 των αποτελεσμάτων. Καμία αλλαγή στο περιεχόμενο. Καμία νέα σελίδα. Μόνο η σωστή δήλωση ποια εκδοχή μετράει.
Το βασικό συμπέρασμα
Το canonical tag δεν είναι κάτι που ρυθμίζετε μία φορά και ξεχνάτε. Είναι ζωντανό μέρος της αρχιτεκτονικής του site σας, που πρέπει να παραμένει συνεπές με το sitemap, με τα εσωτερικά links, και με κάθε αλλαγή δομής URL που κάνετε. Αν αναρωτιέστε πόσο συχνά αξίζει να το ελέγχετε, η απάντηση εξαρτάται από το πόσο συχνά αλλάζει η δομή του site σας, αλλά η σχετική ερώτηση για canonical tags στη σελίδα FAQ μας δίνει το ελάχιστο πλαίσιο ελέγχου που εφαρμόζουμε σε κάθε πελάτη, ανεξαρτήτως μεγέθους site.
Το λάθος με τη σελιδοποίηση: όταν το canonical εξαφανίζει σελίδες που έπρεπε να υπάρχουν
Το πιο συχνό λάθος canonical που βλέπουμε δεν είναι απουσία tag. Είναι λάθος στόχος. Πολλά CMS, ειδικά WooCommerce και custom κατασκευές χωρίς σωστή ρύθμιση, βάζουν αυτόματα canonical σε κάθε σελίδα 2, 3, 4 μιας κατηγορίας προϊόντων να δείχνει πίσω στη σελίδα 1. Η λογική πίσω από αυτή τη ρύθμιση φαίνεται λογική με την πρώτη ματιά: «όλες οι σελίδες είναι η ίδια κατηγορία, άρα ας συγκεντρωθεί η αξία στην πρώτη». Στην πράξη κάνει το ακριβώς αντίθετο από αυτό που θέλετε.
Ένα παράδειγμα με νούμερα: μια κατηγορία με 96 προϊόντα, 12 ανά σελίδα, άρα 8 σελίδες συνολικά. Αν οι σελίδες 2 έως 8 δηλώνουν canonical προς τη σελίδα 1, η Google αντιμετωπίζει τα προϊόντα 13 έως 96 ως περιεχόμενο «δευτερεύον», σε πολλές περιπτώσεις δεν τα ευρετηριάζει καθόλου ως ξεχωριστές διαδρομές αναζήτησης, γιατί η canonical δήλωση της σελίδας τα παραπέμπει αλλού. Το προϊόν στη σελίδα 6 δεν κατατάσσεται ποτέ για το δικό του, μοναδικό keyword, όσο καλή περιγραφή κι αν έχει.
Η σωστή ρύθμιση είναι πιο βαρετή απ' όσο θα θέλατε: κάθε σελίδα σελιδοποίησης έχει self-referencing canonical, όχι canonical προς τη σελίδα 1. Η σελίδα 1, η σελίδα 2, η σελίδα 8 είναι όλες ξεχωριστές, έγκυρες σελίδες με δικό τους δικαίωμα ευρετηρίασης. Αν θέλετε επιπλέον να συγκεντρώσετε signal, η λύση δεν είναι canonical: είναι μια σελίδα «προβολή όλων» (view-all) με τα 96 προϊόντα, την οποία τότε μπορείτε να ορίσετε ως canonical στόχο, αν πραγματικά φορτώνει αποδεκτά γρήγορα.
Αυτό συνδέεται άμεσα με το πώς η Google αντιμετωπίζει το crawl budget σε μεγάλες κατηγορίες προϊόντων, κάτι που αναλύουμε πλήρως στον οδηγό xml sitemap robots.txt. Ο κανόνας που εφαρμόζουμε σε κάθε e-shop: σελιδοποίηση σημαίνει self-referencing canonical σε κάθε σελίδα, ποτέ συγκέντρωση προς τη σελίδα 1, εκτός αν υπάρχει πραγματική view-all εναλλακτική.
Canonical και hreflang: πότε τσακώνονται
Δύο ετικέτες που θα έπρεπε να συνεργάζονται αθόρυβα, και αντ' αυτού μπερδεύουν η μία την άλλη σε σχεδόν κάθε πολυγλωσσικό site που ελέγχουμε.
Το hreflang λέει στη Google «αυτή η σελίδα είναι η ελληνική εκδοχή, αυτή η αγγλική, δείξε στον καθένα τη σωστή». Το canonical λέει «αυτή είναι η αυθεντική εκδοχή, αγνόησε τις υπόλοιπες». Πρόβλημα: αν η ελληνική σελίδα έχει canonical προς την αγγλική (συνηθισμένο λάθος όταν κάποιος αντιγράφει template χωρίς να αλλάξει το tag), το hreflang λέει στη Google «δείξε ελληνικά σε ελληνόφωνους» ενώ το canonical λέει «η αγγλική είναι η μόνη πραγματική σελίδα». Η Google, αντιμέτωπη με αντικρουόμενα σήματα, συχνά αγνοεί εντελώς το hreflang cluster και δείχνει μόνο την canonical εκδοχή σε όλες τις γλώσσες. Ακριβώς το αντίθετο από αυτό που θέλατε όταν επενδύσατε σε μετάφραση.
Ο κανόνας είναι απλός αλλά παραβιάζεται συνέχεια: κάθε γλωσσική εκδοχή έχει self-referencing canonical στον εαυτό της, ποτέ σε άλλη γλώσσα. Το hreflang δουλεύει σε ξεχωριστό επίπεδο: δηλώνει τη σχέση ανάμεσα σε ισοδύναμες σελίδες, δεν υποκαθιστά ποτέ το canonical, και δεν πρέπει ποτέ να έρχεται σε αντίθεση μαζί του.
Το βλέπουμε συχνότερα σε sites που πρόσθεσαν δεύτερη γλώσσα αργότερα, πάνω σε υπάρχουσα δομή, χωρίς να ξαναδούν τα canonical tags της πρωτότυπης γλώσσας. Ένα site με 400 ελληνικές σελίδες πρόσθεσε αγγλική εκδοχή για 120 από αυτές. Οι 120 αγγλικές σελίδες είχαν σωστό self-referencing canonical. Αλλά κανείς δεν είχε ελέγξει αν οι αντίστοιχες 120 ελληνικές σελίδες συνέχιζαν να δηλώνουν σωστά τον εαυτό τους: δύο από αυτές είχαν παλιό canonical προς μια εκδοχή που δεν υπήρχε πια. Αποτέλεσμα: hreflang cluster σπασμένο σε δύο σημεία, και η Google έδειχνε την αγγλική σελίδα σε ελληνόφωνες αναζητήσεις για έξι εβδομάδες πριν το εντοπίσουμε.
Ο έλεγχος που κάνουμε τώρα σε κάθε πολυγλωσσικό audit: ανοίγουμε κάθε ζεύγος hreflang και επιβεβαιώνουμε ότι το canonical κάθε σελίδας δείχνει στον εαυτό της, όχι στο ζευγάρι της.
Η ένσταση που ακούμε συνέχεια: «Δεν έχω πρόσβαση στον κώδικα»
Κάθε φορά που εξηγούμε ένα πρόβλημα canonical σε πελάτη με WordPress ή custom CMS χωρίς developer διαθέσιμο, ακούμε την ίδια ένσταση: «Ωραία, αλλά εγώ δεν μπορώ να αγγίξω τον κώδικα». Η ένσταση είναι δικαιολογημένη ανησυχία, όχι εμπόδιο.
Στην πράξη, σχεδόν κανένα σύγχρονο site δεν χρειάζεται να αγγίξει HTML template για να διορθώσει canonical tags. Στο WordPress, plugins όπως το Yoast SEO ή το Rank Math εκθέτουν το canonical field απευθείας στον επεξεργαστή κάθε σελίδας: αλλαγή χωρίς μία γραμμή κώδικα. Σε Shopify, το canonical διαχειρίζεται αυτόματα η ίδια η πλατφόρμα για τις περισσότερες περιπτώσεις, με εξαιρέσεις μόνο σε custom apps. Σε custom React/Next.js εφαρμογές, το canonical είναι συνήθως μία μεταβλητή σε ένα shared component του head: μία αλλαγή, όχι εκατό.
Το πραγματικό πρόβλημα πίσω από αυτή την ένσταση δεν είναι τεχνική δυσκολία. Είναι ότι κανείς δεν έχει ξεκαθαρίσει ποιος είναι υπεύθυνος να το ελέγχει τακτικά. Ένα site με σωστά canonical tags σήμερα μπορεί να έχει λάθος tags σε έξι μήνες, απλά επειδή κάποιος πρόσθεσε νέα σελίδα με το λάθος template, ή ένα plugin ενημερώθηκε και άλλαξε προεπιλεγμένη συμπεριφορά χωρίς προειδοποίηση.
Η απάντηση που δίνουμε: δεν χρειάζεστε developer μόνιμα στη διάθεσή σας, χρειάζεστε έναν έλεγχο τριών λεπτών κάθε φορά που δημοσιεύετε νέα σελίδα: άνοιγμα view-source, αναζήτηση «canonical», επιβεβαίωση ότι δείχνει στη σωστή διεύθυνση. Αυτό δεν απαιτεί κώδικα. Απαιτεί συνήθεια. Ένας πελάτης μας εφάρμοσε αυτόν τον έλεγχο σε κάθε δημοσίευση blog, και σε δεκαοκτώ μήνες δεν είχε ούτε ένα λάθος canonical, όχι επειδή προσέλαβε νέο developer, αλλά επειδή ο έλεγχος έγινε μέρος της checklist δημοσίευσης, στο ίδιο σημείο με τον έλεγχο ορθογραφίας.
Τι αλλάζει όταν το site έχει 500.000 URLs αντί για 500
Όλα όσα περιγράψαμε παραπάνω ισχύουν εξίσου σε ένα site 20 σελίδων και σε ένα site μισού εκατομμυρίου. Αλλά η κλίμακα αλλάζει το πώς τα ελέγχετε, όχι το τι ελέγχετε.
Σε ένα site 20 σελίδων, ελέγχετε κάθε canonical tag με το χέρι, μία-μία, μέσα σε μισή ώρα. Σε ένα site με 500.000 URLs (τυπικό μέγεθος για ένα μεγάλο e-shop με φίλτρα, χρώματα, μεγέθη) ο χειροκίνητος έλεγχος είναι αδύνατος. Χρειάζεστε crawl με εργαλείο όπως το Screaming Frog, ρυθμισμένο να εξάγει το canonical κάθε URL δίπλα στο ίδιο το URL, και μετά μια στήλη σύγκρισης: «canonical == URL;» true/false. Σε ένα υγιές μεγάλο site, αυτό το ποσοστό πρέπει να είναι πάνω από 95% true για σελίδες που θέλετε ευρετηριασμένες. Αν είναι κάτω από 80%, κάτι συστηματικό είναι σπασμένο: συνήθως ένα template φίλτρου που παράγει χιλιάδες URLs χωρίς σωστή δήλωση.
Δεύτερη αλλαγή στην κλίμακα: το κόστος ενός λάθους πολλαπλασιάζεται. Σε site 20 σελίδων, ένα σπασμένο canonical επηρεάζει μία σελίδα. Σε site 500.000 URLs, ένα λάθος στο template μιας κατηγορίας φίλτρων μπορεί να επηρεάσει 50.000 URLs ταυτόχρονα, γιατί όλα παράγονται από τον ίδιο κώδικα. Αυτό σημαίνει ότι σε μεγάλη κλίμακα, ο έλεγχος canonical δεν είναι πια θέμα σελίδας: είναι θέμα template. Ελέγχετε ένα αντιπροσωπευτικό δείγμα ανά τύπο σελίδας (προϊόν, κατηγορία, φίλτρο, αναζήτηση), όχι κάθε URL ξεχωριστά, γιατί αν το δείγμα είναι σωστό, όλο το template είναι σωστό.
Τρίτη αλλαγή: η συχνότητα ελέγχου πρέπει να ανέβει. Σε μικρό site, έλεγχος δύο φορές τον χρόνο αρκεί. Σε μεγάλο e-shop με συνεχείς αλλαγές φίλτρων και νέα προϊόντα καθημερινά, ένα αυτοματοποιημένο crawl πρέπει να τρέχει εβδομαδιαία, με ειδοποίηση αν το ποσοστό «canonical == self» πέσει κάτω από ένα προκαθορισμένο όριο. Δείτε πόσο συχνά αξίζει να τρέχετε αυτόν τον έλεγχο στο πόσο συχνά seo audit χρειάζεστε.