Η Google μπορεί να αγνοεί το 90% ενός μεγάλου website για μήνες, και δεν έχει καμία σχέση με το πόσο καλό είναι το περιεχόμενό του.
Το crawl budget δεν είναι τιμωρία, είναι λογιστική
Υπάρχει μια εικόνα στο μυαλό πολλών ιδιοκτητών sites: η Google σαν μια κακιά δασκάλα που μοιράζει "προσοχή" ανάλογα με το πόσο καλό παιδί ήσουν. Έγραψες πολύ περιεχόμενο; Σε ανταμείβει με περισσότερες σελίδες crawled. Έκανες κάτι λάθος; Σε τιμωρεί κρατώντας τον Googlebot μακριά.
Αυτό είναι διασκεδαστικό αφήγημα. Είναι και εντελώς λάθος.
Το crawl budget είναι λογιστική, όχι ηθική. Η Google διαθέτει πεπερασμένους πόρους (servers, δίκτυο, χρόνο) για να ανακαλύψει τρισεκατομμύρια URLs στο web κάθε μέρα. Πρέπει να αποφασίσει πού θα ξοδέψει αυτούς τους πόρους. Η απόφαση δεν βασίζεται σε "καλή συμπεριφορά". Βασίζεται σε δύο απλές μεταβλητές: πόσο γρήγορα απαντάει ο server σας, και πόσο αξίζει, ιστορικά, να επιστρέφει ο Googlebot στο site σας.
Αυτό είναι το σημείο που χάνεται στις περισσότερες εξηγήσεις: το crawl budget δεν είναι κάτι που "κερδίζεις". Είναι κάτι που σπαταλάς ή δεν σπαταλάς. Η δουλειά σας δεν είναι να πείσετε τη Google να σας δώσει περισσότερο. Είναι να σταματήσετε να την αναγκάζετε να ξοδεύει το budget σε σελίδες που δεν έχουν καμία αξία.
Ο επίσημος ορισμός, χωρίς το μάρκετινγκ γύρω του
Η Google ορίζει το crawl budget ως συνδυασμό δύο εννοιών: crawl rate limit (πόσες ταυτόχρονες συνδέσεις μπορεί να ανοίξει ο Googlebot χωρίς να ρίξει τον server σας) και crawl demand (πόσο "θέλει" η Google να επισκεφθεί ξανά τις σελίδες σας, βάσει δημοφιλίας και φρεσκάδας περιεχομένου). Το πρώτο είναι τεχνικό όριο. Το δεύτερο είναι αξιολόγηση αξίας.
Το σφάλμα που κάνουν οι περισσότεροι: ασχολούνται μόνο με το δεύτερο (θέλουν "πιο συχνό crawling") ενώ αγνοούν το πρώτο, που είναι συχνά το πραγματικό εμπόδιο. Αν ο server σας απαντάει σε 3 δευτερόλεπτα αντί για 300 χιλιοστά του δευτερολέπτου, ο Googlebot κόβει αυτόματα τον ρυθμό crawling, όχι επειδή σας τιμωρεί, αλλά επειδή δεν θέλει να σας ρίξει το site.
Πότε το crawl budget είναι πραγματικό πρόβλημα (και πότε είναι χάσιμο χρόνου)
Εδώ είναι η αλήθεια που κανείς δεν θέλει να ακούσει: αν το site σας έχει κάτω από 1.000 σελίδες, το crawl budget δεν σας αφορά. Καθόλου. Ο Googlebot μπορεί να ανακαλύψει και να ξανα-επισκεφθεί 1.000 URLs μέσα σε λίγες ώρες, ακόμα κι αν ο server σας δεν είναι ιδιαίτερα γρήγορος.
Το πραγματικό κατώφλι: γύρω στις 10.000 μοναδικές σελίδες
Η Google το έχει πει ανοιχτά: το crawl budget γίνεται σχετικό ζήτημα σε sites με δεκάδες χιλιάδες URLs: e-shops με χιλιάδες προϊόντα και φίλτρα, sites με user-generated content, μεγάλα news portals, ή directories. Αν διαχειρίζεστε ένα εταιρικό site 40-80 σελίδων, ένα blog με 200 άρθρα, ή ένα portfolio 10 case studies, η ενασχόληση με το crawl budget είναι το τεχνικό ισοδύναμο του να ανησυχείτε για τη χωρητικότητα του αεροδρομίου όταν οδηγείτε ποδήλατο.
Αυτό δεν σημαίνει ότι η ταχύτητα του server δεν έχει σημασία: έχει, πάντα, για άλλους λόγους (Core Web Vitals, εμπειρία χρήστη). Σημαίνει ότι αν κάποιος σας πουλάει "βελτιστοποίηση crawl budget" για ένα μικρό site, σας πουλάει άγχος, όχι λύση.
Πού εμφανίζεται πραγματικά
Τα sites όπου το crawl budget γίνεται πρόβλημα έχουν ένα κοινό χαρακτηριστικό: παράγουν URLs αυτόματα, συχνά χωρίς να το καταλαβαίνει κανείς. Ένα e-shop με φίλτρα χρώματος, μεγέθους και τιμής μπορεί να δημιουργήσει 50.000 μοναδικά URLs από 500 πραγματικά προϊόντα. Ένα ημερολόγιο εκδηλώσεων μπορεί να παράγει μια σελίδα για κάθε ημέρα, επ' άπειρον, στο μέλλον. Αυτά είναι τα sites που πρέπει να διαβάσουν το υπόλοιπο άρθρο. Τα υπόλοιπα μπορούν να προχωρήσουν στο επόμενο τεχνικό ζήτημα της λίστας τους.
Τα σημάδια ότι πραγματικά σπαταλάτε crawl budget
Αν είστε σε ένα από τα μεγάλα sites που περιγράψαμε, να τι πραγματικά αδειάζει το budget σας.
Faceted navigation και παράμετροι URL
Το πιο κοινό έγκλημα. Κάθε συνδυασμός φίλτρου (χρώμα=κόκκινο&μέγεθος=Μ&ταξινόμηση=τιμή) δημιουργεί ένα νέο URL που ο Googlebot μπορεί να ανακαλύψει μέσω εσωτερικών links, ακόμα κι αν το περιεχόμενο είναι ουσιαστικά το ίδιο με 30 άλλα URLs. Η Google crawl-άρει, βλέπει duplicate content, δεν το ευρετηριάζει, αλλά έχει ήδη ξοδέψει τον πόρο του crawl για να το ανακαλύψει. Το budget χάθηκε πριν καν φτάσουμε στο ζήτημα ευρετηρίασης.
Σελιδοποίηση χωρίς σωστή διαχείριση
Το page 2, 3, 4... 400 μιας κατηγορίας προϊόντων. Αν δεν υπάρχει σωστή στρατηγική canonical ή αν κάθε σελίδα σελιδοποίησης είναι τεχνικά ευρετηριάσιμη ξεχωριστά, δημιουργείτε εκατοντάδες URLs χαμηλής αξίας που ανταγωνίζονται τους πραγματικούς πόρους crawling.
Soft 404 και λεπτό περιεχόμενο
Σελίδες που "υπάρχουν" τεχνικά (επιστρέφουν κωδικό 200) αλλά δεν έχουν ουσιαστικό περιεχόμενο: προϊόντα εκτός αποθέματος χωρίς redirect, κενές σελίδες κατηγορίας, αναζητήσεις εσωτερικού site που ευρετηριάστηκαν κατά λάθος. Ο Googlebot τις επισκέπτεται ξανά και ξανά, ελπίζοντας να βρει κάτι χρήσιμο, και συνεχίζει να σπαταλά budget σε αυτές μέχρι να αποφασίσει ότι δεν αξίζει τον κόπο, οπότε μειώνει τη συχνότητα crawling σε ολόκληρο το site, όχι μόνο στις προβληματικές σελίδες.
Καθυστερημένο JavaScript rendering
Αν το περιεχόμενό σας φορτώνει μέσω client-side JavaScript, ο Googlebot πρέπει να κάνει δύο περάσματα: πρώτα κατεβάζει το HTML, μετά το βάζει σε ουρά για rendering σε δεύτερο χρόνο. Αυτό δεν διπλασιάζει απλώς τον χρόνο, πολλαπλασιάζει τους πόρους που χρειάζεται για να καταλάβει τι υπάρχει στη σελίδα σας. Αναλύουμε αυτό το πρόβλημα σε βάθος στο άρθρο για τα προβλήματα javascript seo, όπου δείχνουμε πώς η καθυστέρηση rendering μπορεί να αφήσει ολόκληρα τμήματα ενός site ουσιαστικά αόρατα για εβδομάδες.
Πώς το μετράμε πραγματικά (όχι με μαντεψιά)
Το Crawl Stats report στο Search Console
Αυτό είναι το πρώτο σημείο ελέγχου, και το πιο παραμελημένο. Δείχνει το πλήθος αιτημάτων crawl ανά ημέρα, τον μέσο χρόνο απόκρισης, και τα responses ανά τύπο (200, 301, 404, 500). Αν βλέπετε απότομη αύξηση σε 404 ή 500 responses, ή αν ο μέσος χρόνος απόκρισης ανεβαίνει πάνω από 500ms, έχετε ήδη την απάντηση γιατί το crawling επιβραδύνεται.
Ανάλυση server logs
Το Search Console σας δίνει δείγμα. Τα πραγματικά server logs σας δίνουν όλη την αλήθεια: ακριβώς ποια URLs επισκέπτεται ο Googlebot, πόσο συχνά, και ποιο ποσοστό των crawls πηγαίνει σε σελίδες που δεν έχουν καμία οργανική αξία. Σε ένα audit που κάναμε πρόσφατα σε ένα site με φιλτραρισμένη πλοήγηση, το 68% των Googlebot requests πήγαιναν σε URL παραμέτρων που δεν έπρεπε καν να υπάρχουν ευρετηριάσιμα. Αυτό δεν είναι εξαίρεση, είναι ο κανόνας σε κάθε μεγάλο e-shop που δεν έχει ελεγχθεί ποτέ σε αυτό το επίπεδο.
Πώς το διορθώνουμε
Το robots.txt δεν είναι πάντα η λύση: μπορεί να είναι το πρόβλημα
Η πιο κοινή "διόρθωση" είναι να μπλοκάρετε τα προβληματικά URLs στο robots.txt. Λειτουργεί μερικές φορές, αλλά έχει μια παγίδα: αν το URL έχει ήδη backlinks ή εσωτερικά links, η Google μπορεί να το κρατήσει στο index χωρίς περιεχόμενο (βλέπετε "no information is available" στα αποτελέσματα), επειδή το robots.txt εμποδίζει το crawling αλλά όχι την ευρετηρίαση. Σε πολλές περιπτώσεις, ένα σωστά δομημένο noindex tag είναι πιο αποτελεσματικό από ένα disallow. Πώς να δομήσετε σωστά αυτά τα αρχεία, χωρίς να μπλοκάρετε κατά λάθος πράγματα που θέλετε να ευρετηριαστούν, το εξηγούμε αναλυτικά στον οδηγό xml sitemap robots.txt.
Consolidate με canonical tags, όχι απαγορεύσεις
Για τις παραλλαγές παραμέτρων που έχουν πραγματικό, μοναδικό περιεχόμενο αλλά ίδια δομή, το σωστό εργαλείο είναι το rel=canonical προς την "καθαρή" έκδοση του URL. Αυτό λέει στη Google "ναι, ξέρω ότι υπάρχει αυτό το URL, αλλά η αυθεντική έκδοση είναι εκείνη εκεί", χωρίς να εμποδίζετε καν το crawling.
Βελτιώστε τον χρόνο απόκρισης του server
Το πιο underrated fix. Αν ο server σας απαντάει σε 200ms αντί για 2 δευτερόλεπτα, ο Googlebot μπορεί κυριολεκτικά να κάνει 10 φορές περισσότερα requests στο ίδιο χρονικό παράθυρο που του διαθέτει. Δεν χρειάζεται να πείσετε κανέναν για τίποτα. Απλώς αφαιρείτε το εμπόδιο.
Κλαδέψτε ή ανακατευθύνετε το low-value περιεχόμενο
Μερικές φορές η σωστή απάντηση δεν είναι τεχνική διόρθωση, είναι διαγραφή. Αν έχετε 3.000 σελίδες προϊόντων εκτός stock εδώ και δύο χρόνια, δεν χρειάζονται canonical tags. Χρειάζονται 410 (Gone) ή ένα σωστό redirect σε σχετική κατηγορία.
Migrations και crawl budget: το ξεχασμένο ρίσκο
Όταν μεταφέρετε ένα site (αλλαγή domain, αλλαγή πλατφόρμας, αναδιοργάνωση URLs), δημιουργείτε στιγμιαία δύο σετ URLs που ανταγωνίζονται για crawl budget: τα παλιά (που πρέπει να ανακατευθυνθούν σωστά) και τα νέα (που πρέπει να ανακαλυφθούν γρήγορα). Αν η μετάβαση δεν είναι καλά σχεδιασμένη, ο Googlebot ξοδεύει μεγάλο μέρος του διαθέσιμου budget σε redirects και 404s αντί να ανακαλύπτει το νέο σας περιεχόμενο. Έχουμε γράψει αναλυτικό οδηγό για το πώς να αποφύγετε ακριβώς αυτό στο migration website seo, με τη σειρά ενεργειών που ελαχιστοποιεί την απώλεια κατάταξης.
Οι AI crawlers άλλαξαν το παιχνίδι
Μέχρι πρόσφατα, "crawl budget" σήμαινε αποκλειστικά Googlebot. Αυτό δεν ισχύει πια. GPTBot, ClaudeBot, PerplexityBot και άλλοι AI crawlers επισκέπτονται τώρα τα sites με δικά τους πρότυπα συχνότητας, και πολλά από αυτά δεν σέβονται τους ίδιους κανόνες crawl-delay που έχει μάθει να σέβεται η Google εδώ και 20 χρόνια. Ένα site με χαλαρό robots.txt μπορεί ξαφνικά να δει τραφικ crawling να τριπλασιάζεται από bots που δεν είχε καν καταγράψει ποτέ. Το πώς να ρυθμίσετε σωστά αυτούς τους νέους crawlers, ώστε να επωφεληθείτε από την ορατότητα σε AI αναζητήσεις χωρίς να επιβαρύνετε τον server σας, το αναλύουμε στο robots.txt ai bots, ένα θέμα που, ειλικρινά, ελάχιστες ελληνικές επιχειρήσεις έχουν καν σκεφτεί μέχρι σήμερα.
Το πραγματικό μάθημα
Το crawl budget δεν είναι αρρώστια. Είναι σύμπτωμα. Αν το site σας το έχει, το πρόβλημα δεν είναι "η Google δεν μας δίνει αρκετό χρόνο", είναι "παράγουμε πολύ σκουπίδι URLs και δεν καθαρίζουμε πίσω μας". Η λύση δεν είναι να παρακαλέσετε για περισσότερο budget. Είναι να χρειάζεστε λιγότερο.
Ένα site με 500 πραγματικές, καθαρές σελίδες που φορτώνουν σε 400ms η καθεμία θα ευρετηριαστεί πλήρως πριν προλάβει η Google να ολοκληρώσει το πρώτο πέρασμα σε ανταγωνιστή με 50.000 φιλτραρισμένα URLs και server που απαντάει σε 3 δευτερόλεπτα. Δεν είναι θέμα τύχης. Είναι θέμα αρχιτεκτονικής.
Ένα Παράδειγμα με Αριθμούς: Πόσο Πραγματικά Κοστίζει το Σπάταλο Crawling
Ας το κάνουμε συγκεκριμένο. Ένα e-shop με 800 πραγματικά προϊόντα δημιουργεί, μέσω φίλτρων χρώματος, μεγέθους και ταξινόμησης, περίπου 45.000 μοναδικά URLs, τυπικός αριθμός για faceted navigation χωρίς έλεγχο. Αν ο Googlebot διαθέτει, ενδεικτικά, 8.000 requests την ημέρα για αυτό το domain (αριθμός που φαίνεται στο Crawl Stats report), χρειάζεται περίπου 5,6 ημέρες μόνο για να ανακαλύψει όλα τα URLs μία φορά, και αυτό προϋποθέτει μηδενική επανάληψη, κάτι που δεν συμβαίνει ποτέ στην πράξη.
Στην πραγματικότητα, ο Googlebot δεν επισκέπτεται κάθε URL μία φορά και προχωράει. Επιστρέφει, ελέγχει για αλλαγές, ξαναχτίζει την ουρά προτεραιότητας. Αν το 85% αυτών των 45.000 URLs είναι παραλλαγές φίλτρων χωρίς μοναδικό περιεχόμενο (38.250 URLs), αυτό το κομμάτι απορροφά τη μερίδα του λέοντος από το καθημερινό budget, αφήνοντας ελάχιστο χώρο για τα 800 πραγματικά προϊόντα και τις κατηγορίες που πραγματικά θέλετε να κατατάσσονται. Το αποτέλεσμα που βλέπουμε συχνά σε τέτοια audits: νέα προϊόντα χρειάζονται 3-4 εβδομάδες για να ευρετηριαστούν πρώτη φορά, ενώ σε ένα καθαρό site με την ίδια δομή θα έπαιρνε 2-3 ημέρες.
Τώρα το αντίστροφο σενάριο: αν μπλοκάρετε τις 38.250 παραλλαγές μέσω canonical tags και robots.txt συνδυαστικά, το ίδιο budget των 8.000 requests την ημέρα καλύπτει πλέον 6.750 πραγματικά χρήσιμα URLs (800 προϊόντα + κατηγορίες + σελίδες περιεχομένου) μέσα σε λιγότερο από μία ημέρα, με πολλαπλά περάσματα την εβδομάδα. Δεν αλλάξατε τίποτα στον server. Δεν πείσατε τη Google για τίποτα. Απλά σταματήσατε να τη στέλνετε σε 38.250 σελίδες που δεν έπρεπε ποτέ να υπάρχουν ευρετηριάσιμα. Αυτός είναι ο πολλαπλασιαστής που κανείς δεν εξηγεί με αριθμούς, και είναι ο λόγος που η "βελτιστοποίηση crawl budget" είναι, στην ουσία, αφαίρεση, όχι προσθήκη.
Το Λάθος που Ακυρώνει τη Δική σας Λύση: Noindex Πίσω από Disallow
Υπάρχει ένα τεχνικό λάθος τόσο συχνό που αξίζει δική του ενότητα: να βάζετε ταυτόχρονα ένα URL σε disallow στο robots.txt ΚΑΙ να έχετε noindex tag μέσα στη σελίδα, ελπίζοντας ότι τα δύο μαζί λειτουργούν "πιο δυνατά". Συμβαίνει το αντίθετο. Το robots.txt εμποδίζει τον Googlebot να επισκεφθεί καν τη σελίδα, που σημαίνει ότι ποτέ δεν διαβάζει το noindex tag που βρίσκεται μέσα σε αυτήν. Το αποτέλεσμα: η σελίδα μπορεί να παραμείνει ευρετηριασμένη επ' αόριστον, βασισμένη σε παλιά δεδομένα ή σε backlinks, ενώ εσείς πιστεύετε ότι την έχετε αφαιρέσει διπλά ασφαλισμένη.
Η σωστή σειρά είναι ακριβώς αντίστροφη από τη διαίσθηση: πρώτα αφήνετε τη σελίδα crawlable (όχι disallow), με το noindex tag ενεργό, μέχρι η Google να την ξανα-επισκεφθεί και να διαβάσει το tag και να την αφαιρέσει από το index. Μόνο ΜΕΤΑ από αυτή την αφαίρεση (και μπορείτε να το επιβεβαιώσετε στο Search Console, αναφορά Pages, φιλτραρισμένο σε "Excluded by noindex tag") μπορείτε να προσθέσετε το disallow, αν θέλετε επιπλέον να εξοικονομήσετε crawl budget σε αυτό το URL στο μέλλον. Η αντιστροφή αυτής της σειράς είναι η πηγή ενός μεγάλου ποσοστού των "γιατί η παλιά μας σελίδα ακόμα εμφανίζεται στη Google" ερωτημάτων που δεχόμαστε.
Ένα δεύτερο, συγγενικό λάθος: πολλά sites βάζουν disallow σε ολόκληρους φακέλους (π.χ. /wp-admin/, σωστό) αλλά ξεχνούν ότι ο ίδιος κανόνας μπλοκάρει και legitimate assets μέσα στον φάκελο (CSS, JavaScript, εικόνες) που ο Googlebot χρειάζεται για να αποδώσει σωστά τη σελίδα και να καταλάβει αν είναι mobile-friendly. Ένα γρήγορο τεστ: ανοίξτε το εργαλείο URL Inspection στο Search Console και ελέγξτε αν το rendered screenshot δείχνει τη σελίδα σωστά ή "σπασμένη" χωρίς στυλ. Αν είναι σπασμένη, κάποιο robots.txt rule μπλοκάρει πόρους που δεν έπρεπε.
Τι Αλλάζει Πραγματικά σε ένα Site με Εκατομμύρια Σελίδες
Όλα όσα περιγράψαμε παραπάνω ισχύουν σε ένα site 10.000-100.000 σελίδων. Σε ένα marketplace ή directory με πάνω από 1 εκατομμύριο URLs (σκεφτείτε ένα site αγγελιών ή ένα ταξιδιωτικό site με σελίδα ανά συνδυασμό πόλης-ημερομηνίας) η λογική δεν αλλάζει, αλλά τα εργαλεία που χρειάζεστε αλλάζουν εντελώς. Το Search Console Crawl Stats report, που αρκεί για ένα μεσαίο site, γίνεται ανεπαρκές: δείχνει δείγμα, όχι το σύνολο, και σε αυτή την κλίμακα το δείγμα κρύβει περισσότερα προβλήματα απ' όσα αποκαλύπτει.
Σε αυτή την κλίμακα, η ανάλυση server logs δεν είναι πλέον προαιρετική βελτίωση, είναι προϋπόθεση. Χρειάζεστε αυτοματοποιημένο pipeline που κατηγοριοποιεί καθημερινά κάθε Googlebot request ανά τύπο σελίδας, ώστε να βλέπετε σε πραγματικό χρόνο αν το budget κατευθύνεται σε νέο περιεχόμενο ή σε παλιά, χαμηλής αξίας σελίδες. Μια τεχνική που χρησιμοποιείται σχεδόν αποκλειστικά σε αυτή την κλίμακα είναι το dynamic rendering: να σερβίρετε προ-αποδομένο HTML ειδικά στον Googlebot ενώ οι πραγματικοί χρήστες παίρνουν την πλήρη JavaScript εμπειρία, κάτι που σε ένα site 500 σελίδων θα ήταν υπερβολική πολυπλοκότητα, αλλά σε ένα site 5 εκατομμυρίων σελίδων μπορεί να είναι η διαφορά ανάμεσα σε πλήρη ευρετηρίαση και μόνιμα ημιτελή κάλυψη.
Υπάρχει και μια δεύτερη αλλαγή κλίμακας που αγνοείται συχνά: η ιεράρχηση. Σε 500 σελίδες, όλες αξίζουν σχεδόν την ίδια προσοχή crawling. Σε 5 εκατομμύρια, πρέπει να αποφασίσετε ενεργά ποιο 10% φέρνει το 90% της οργανικής αξίας (συνήθως οι σελίδες με πραγματική ζήτηση αναζήτησης) και να κατευθύνετε το εσωτερικό linking, τα sitemaps, και το crawl budget ειδικά προς αυτές, αφήνοντας τις υπόλοιπες να ευρετηριαστούν με φυσικό, πιο αργό ρυθμό. Η αρχιτεκτονική εδώ δεν είναι πια «καθαρίστε τα σκουπίδια», είναι «κατασκευάστε ρητή ιεραρχία προτεραιότητας», κάτι που απαιτεί πολύ διαφορετικό επίπεδο τεχνικού σχεδιασμού από ό,τι ένα τυπικό εταιρικό site.