Δύο sites με πανομοιότυπο περιεχόμενο μπορούν να έχουν εντελώς διαφορετική τύχη στη Google, μόνο επειδή διαφέρουν στο πού τρέχει το JavaScript τους.
Η ερώτηση που κρύβει τρεις διαφορετικές ερωτήσεις
"SSR ή CSR;" ακούγεται σαν μια ερώτηση τεχνολογίας. Δεν είναι. Είναι τρεις ξεχωριστές ερωτήσεις ντυμένες σαν μία: Πόσο γρήγορα βλέπει κάτι ο χρήστης; Πόσο γρήγορα βλέπει κάτι ο crawler; Και πόσο εύκολα μπορεί να κλιμακωθεί η υποδομή σας όταν χιλιάδες άνθρωποι ζητούν την ίδια σελίδα ταυτόχρονα; Η σύγχυση ξεκινάει επειδή η απάντηση σε αυτές τις τρεις ερωτήσεις δεν είναι ποτέ η ίδια. Ένα rendering μοντέλο μπορεί να είναι άριστο για τη μία και μέτριο για τις άλλες δύο.
Η βιομηχανία έχει τη συνήθεια να μιλάει για αυτό σαν φιλοσοφική επιλογή («εμείς πιστεύουμε στο SSR»), ενώ στην πραγματικότητα είναι μηχανικό πρόβλημα με μετρήσιμη απάντηση. Ποιος βλέπει πρώτος το HTML, ο browser του χρήστη ή ο server σας; Αυτή είναι όλη η ερώτηση. Ό,τι ακολουθεί (ταχύτητα, ευρετηρίαση, κόστος υποδομής) είναι συνέπεια αυτής της μίας απόφασης.
Τι είναι πραγματικά το CSR
Στο Client-Side Rendering, ο server στέλνει ένα σχεδόν άδειο έγγραφο HTML, συνήθως μια γραμμή σαν <div id="root"></div>, και ένα πακέτο JavaScript. Ο browser κατεβάζει το πακέτο, το εκτελεί, και μόνο τότε "χτίζει" την πραγματική σελίδα, τοπικά, μπροστά στα μάτια του χρήστη. Είναι το προεπιλεγμένο μοντέλο ενός καθαρού React SPA χωρίς πρόσθετη υποδομή, και λειτουργεί εξαιρετικά για ό,τι δεν χρειάζεται να ευρετηριαστεί ποτέ: ένα dashboard πίσω από login, ένα εργαλείο διαχείρισης, μια εφαρμογή που ο χρήστης ανοίγει επειδή έχει ήδη λογαριασμό, όχι επειδή την αναζήτησε στη Google.
Το πρόβλημα εμφανίζεται όταν το ίδιο μοντέλο χρησιμοποιείται για δημόσιο, ανακαλύψιμο περιεχόμενο. Ένας crawler που διαβάζει μόνο το πρώτο πέρασμα HTML βλέπει, κυριολεκτικά, τίποτα: ούτε τίτλο, ούτε κείμενο, ούτε έναν σύνδεσμο. Το πραγματικό περιεχόμενο υπάρχει μόνο αφού εκτελεστεί το JavaScript, κάτι που πολλά bots απλά δεν κάνουν, ή κάνουν με σημαντική καθυστέρηση.
Τι είναι πραγματικά το SSR
Στο Server-Side Rendering, ο server εκτελεί το ίδιο JavaScript πριν στείλει οτιδήποτε στον browser. Η απόκριση που φτάνει είναι ήδη πλήρες HTML, με τίτλο, με κείμενο, με συνδέσμους, έτοιμο να το διαβάσει οποιοσδήποτε, άνθρωπος ή μηχανή, χωρίς να χρειάζεται να εκτελέσει τίποτα πρώτα. Αυτό είναι το μοντέλο που χρησιμοποιεί το Next.js από προεπιλογή για τις περισσότερες σελίδες, και είναι ο λόγος που ένα σωστά χτισμένο Next.js site δεν έχει ποτέ το πρόβλημα του "άδειου εγγράφου".
Το κόστος του SSR δεν είναι μηδενικό. Κάθε αίτημα απαιτεί από τον server να κάνει τη δουλειά του rendering εκείνη τη στιγμή, κάτι που σημαίνει περισσότερη υπολογιστική επιβάρυνση ανά επίσκεψη σε σχέση με το να σερβίρετε ένα ήδη έτοιμο στατικό αρχείο. Για τις περισσότερες μικρές και μεσαίες επιχειρήσεις αυτό δεν είναι πρόβλημα πρακτικά: η υπολογιστική επιβάρυνση είναι μικρή σε σχέση με το όφελος ευρετηρίασης. Γίνεται ζήτημα μόνο σε πολύ μεγάλη κλίμακα κίνησης.
Οι δύο επιλογές που κανείς δεν αναφέρει πρώτα: SSG και ISR
Η συζήτηση "SSR εναντίον CSR" παραλείπει συχνά τη σωστή απάντηση για τις περισσότερες σελίδες ενός επιχειρηματικού site: το Static Site Generation. Στο SSG, το HTML παράγεται μία φορά, κατά το build, και σερβίρεται στη συνέχεια ως στατικό αρχείο μέσω CDN. Καμία εκτέλεση JavaScript δεν χρειάζεται καν να συμβεί για να το δει ο crawler, και καμία επιβάρυνση server δεν συμβαίνει ανά επίσκεψη. Είναι το γρηγορότερο δυνατό σενάριο, και ταιριάζει σε κάθε σελίδα με σταθερό περιεχόμενο: μια σελίδα υπηρεσίας, ένα άρθρο, μια σελίδα «Επικοινωνία».
Το Incremental Static Regeneration προσθέτει την ευελιξία να ανανεώνεται αυτό το στατικό περιεχόμενο περιοδικά, χωρίς πλήρες rebuild ολόκληρου του site. Μια σελίδα τιμών που αλλάζει σπάνια μπορεί να τρέχει σε ISR με revalidation κάθε ώρα· δεν χρειάζεται το κόστος του SSR σε κάθε request, ούτε τον κίνδυνο μπαγιάτικου περιεχομένου επ' αόριστον. Η σωστή απόφαση δεν είναι ποτέ "SSR παντού" ή "SSG παντού". Είναι ανά σελίδα, ανάλογα με το πόσο συχνά αλλάζει το περιεχόμενό της.
Τι βλέπει στην πράξη ένας crawler σε κάθε σενάριο
Ας το κάνουμε συγκεκριμένο, με τη σειρά που θα το έβλεπε κάποιος αν άνοιγε "view source" σε κάθε περίπτωση. Σε CSR, το view-source δείχνει μια σχεδόν κενή σελίδα: ένα container div και ένα script tag. Σε SSR, το view-source δείχνει το πλήρες περιεχόμενο, ήδη μέσα στο πρώτο αίτημα. Σε SSG, το ίδιο, αλλά χωρίς καν να χρειαστεί ο server να δουλέψει τη στιγμή του αιτήματος. Απλώς σερβίρει ένα έτοιμο αρχείο.
Η πρακτική συνέπεια για την ευρετηρίαση: μια σελίδα SSR ή SSG ευρετηριάζεται συνήθως μέσα σε ώρες από τη δημοσίευσή της, γιατί ο crawler βλέπει πλήρες περιεχόμενο στο πρώτο πέρασμα. Μια σελίδα CSR περνάει από ένα δεύτερο, ξεχωριστό κύμα rendering της Google, που μπορεί να καθυστερήσει από μέρες μέχρι τρεις εβδομάδες, ανάλογα με την αυθεντία του domain. Αναλύουμε αυτό ακριβώς το φαινόμενο, με πραγματικά χρονοδιαγράμματα από audits, στο άρθρο για τις javascript seo προβλήματα που κρύβει ένα React ή Next.js site χτισμένο απρόσεκτα.
Η ψυχολογία πίσω από το γιατί τόσες ομάδες επιλέγουν CSR παρ' όλα αυτά
Αν το SSR/SSG είναι τόσο ξεκάθαρα καλύτερο για SEO, γιατί τόσα project ξεκινούν σε καθαρό CSR; Η απάντηση δεν είναι τεχνική άγνοια. Είναι κίνητρο. Ένας developer που χτίζει ένα demo για να δείξει σε επενδυτές ή σε πελάτη νοιάζεται για το πόσο εντυπωσιακό είναι το interface σήμερα, όχι για το πόσο καλά θα ευρετηριαστεί σε έξι μήνες. Το CSR είναι πιο γρήγορο να στηθεί αρχικά, πιο εύκολο να κάνεις iterate πάνω του χωρίς να σκέφτεσαι server logic, και δίνει άμεση οπτική ικανοποίηση.
Το πρόβλημα είναι ότι αυτό το κίνητρο, η γρήγορη πρώτη εντύπωση, είναι ακριβώς αντίθετο από αυτό που χρειάζεται ένα δημόσιο, ανακαλύψιμο site. Είναι το ίδιο μοτίβο που βλέπουμε στην επιλογή CMS: μια απόφαση που εξυπηρετεί την ταχύτητα της πρώτης εβδομάδας πληρώνεται με τόκο τους επόμενους δώδεκα μήνες. Η λύση δεν είναι να αποφύγετε το React ή το CSR εντελώς. Είναι να αναγνωρίσετε ρητά ποιο κομμάτι του site σας χρειάζεται ανακαλυψιμότητα και ποιο όχι, πριν αρχίσετε να γράφετε κώδικα, όχι μετά.
Πέντε λάθη που βλέπουμε σε πραγματικά technical audits
Πρώτο: ολόκληρο το site χτισμένο σε ένα μόνο rendering μοντέλο, χωρίς διάκριση ανά τύπο σελίδας: το πιο συχνό και το πιο ακριβό λάθος, γιατί σημαίνει είτε σπατάλη server resources σε στατικό περιεχόμενο, είτε αόρατο δυναμικό περιεχόμενο.
Δεύτερο: meta tags (τίτλος, περιγραφή, canonical) που τοποθετούνται μέσω client-side component, ακόμα και σε σελίδες που κατά τα άλλα είναι SSR. Ο crawler του πρώτου περάσματος δεν τα βλέπει, ανεξάρτητα από το πόσο σωστά είναι το υπόλοιπο περιεχόμενο.
Τρίτο: hydration mismatches, δηλαδή όταν το HTML που στέλνει ο server διαφέρει από αυτό που παράγει το JavaScript στο πρώτο render του browser. Το React ρίχνει σφάλμα, και σε ακραίες περιπτώσεις ξαναχτίζει το DOM από την αρχή client-side, ακυρώνοντας μερικώς το πλεονέκτημα του SSR.
Τέταρτο: robots.txt που αποκλείει, κατά λάθος, το directory του JavaScript bundle. Σπάνιο, καταστροφικό όταν συμβαίνει, γιατί σημαίνει ότι ούτε το δεύτερο κύμα rendering μπορεί να δουλέψει.
Πέμπτο, το πιο ύπουλο: σελίδες που δείχνουν σωστό περιεχόμενο στον άνθρωπο επισκέπτη, αλλά ελέγχονται μόνο μέσω DevTools (όπου το JavaScript έχει ήδη τρέξει) και ποτέ μέσω πραγματικού view-source, που είναι αυτό που βλέπει πρώτα ένας crawler.
Πώς αποφασίζουμε ανά σελίδα, όχι ανά site
Στη Distarter δεν ξεκινάμε ρωτώντας "SSR ή CSR για αυτό το project". Ξεκινάμε καταγράφοντας κάθε τύπο σελίδας και ρωτώντας δύο πράγματα για την καθεμία: Πόσο συχνά αλλάζει το περιεχόμενό της; Χρειάζεται καθόλου να ανακαλυφθεί μέσω αναζήτησης; Μια σελίδα υπηρεσίας πάει σε SSG. Μια σελίδα με φιλτραρισμένα αποτελέσματα (π.χ. "διαμερίσματα κάτω από 200€ τη νύχτα") πάει σε SSR, γιατί το περιεχόμενο εξαρτάται από την παράμετρο αναζήτησης. Ένα εσωτερικό dashboard διαχείρισης πίσω από login δεν μπαίνει καν στη συζήτηση: SEO δεν το αφορά ποτέ, άρα CSR είναι απόλυτα αποδεκτό εκεί.
Αυτή η ανά-σελίδα λογική είναι που παράγει τα αποτελέσματα που βλέπουμε σε production: όλα τα ενεργά μας projects τρέχουν σε desktop Lighthouse Performance 93-99/100, με SEO score 100/100, ακριβώς επειδή κάθε σελίδα πήρε τη rendering στρατηγική που της ταιριάζει, όχι μια ενιαία απόφαση επιβεβλημένη σε ολόκληρο το site. Αναλύουμε πλήρως πώς αυτό μεταφράζεται σε νούμερα Core Web Vitals στον core web vitals τι είναι οδηγό μας.
Δύο edge cases που αλλάζουν τους κανόνες
Το πρώτο: streaming SSR με React Server Components. Η νεότερη γενιά του Next.js App Router μπορεί να στείλει ένα αρχικό "κέλυφος" HTML αμέσως και να ακολουθήσουν επιπλέον κομμάτια περιεχομένου σε επόμενα chunks της ίδιας σύνδεσης, καθώς ολοκληρώνονται αργά data fetches. Αυτό δεν είναι το ίδιο πρόβλημα με το CSR, αφού όλο το περιεχόμενο παραμένει server-rendered, αλλά αν το πιο σημαντικό περιεχόμενο SEO αξίας κρύβεται πίσω από ένα Suspense boundary που περιμένει αργό API, υπάρχει ρίσκο ο crawler να μην περιμένει αρκετά.
Το δεύτερο: μια migration από WordPress σε Next.js όπου η ομάδα, στη βιασύνη να παραδώσει γρήγορα, αφήνει κρίσιμες σελίδες σε καθαρό client-side fetching «προσωρινά». Το «προσωρινά» έχει την τάση να διαρκεί μήνες, και ακριβώς τη στιγμή που η μετάβαση έπρεπε να βελτιώσει την ορατότητα, το site χάνει κατάταξη επειδή κανείς δεν πρόσεξε τη διαφορά rendering. Το πλήρες πλάνο για το πώς αποφεύγεται αυτό περιγράφεται στον οδηγό migration website seo.
Το ίδιο ζήτημα, νέος αναγνώστης: πώς το «διαβάζουν» τα AI εργαλεία
Η rendering απόφαση δεν επηρεάζει μόνο τη Google. Ένα bot σαν το GPTBot ή το PerplexityBot που κάνει fetch σε ένα URL για να απαντήσει σε ερώτημα χρήστη, συχνά δεν εκτελεί καθόλου JavaScript, πολύ πιο περιοριστικά από ό,τι το δεύτερο κύμα rendering της Google. Ένα site εξαρτημένο από CSR μπορεί να είναι εντελώς αόρατο σε αυτά τα εργαλεία, ενώ ταυτόχρονα να αποδίδει αξιοπρεπώς στην κανονική Google αναζήτηση. Το δοκιμάσαμε σε πραγματικές επιχειρήσεις και τα ευρήματα ήταν ξεκάθαρα: δείτε τι βρήκαμε στο άρθρο chatgpt βλέπει το site μου. Το rendering μοντέλο σας δεν είναι πια απόφαση μόνο για τη Google. Είναι απόφαση για κάθε μηχανή που θα προσπαθήσει κάποτε να σας παραθέσει.
Λίστα ελέγχου: πώς διαγιγνώσκετε το δικό σας site σε 10 λεπτά
Ανοίξτε το πραγματικό view-source (όχι το Inspector, το ωμό HTML) σε τρεις τύπους σελίδας: αρχική, μια σελίδα υπηρεσίας ή προϊόντος, και μια σελίδα με φιλτραρισμένα αποτελέσματα αν έχετε. Ελέγξτε αν ο τίτλος, η περιγραφή και το κύριο κείμενο υπάρχουν ήδη εκεί, χωρίς να έχει εκτελεστεί τίποτα. Απενεργοποιήστε το JavaScript στον browser σας και ξαναφορτώστε τις ίδιες σελίδες. Αν λείπει βασικό περιεχόμενο ή πλοήγηση, αυτό ακριβώς βλέπει κάθε crawler που δεν εκτελεί JavaScript πλήρως. Τέλος, τρέξτε το URL Inspection tool στο Google Search Console με live test και συγκρίνετε το rendered HTML που επιστρέφει με ό,τι βλέπει ένας πραγματικός επισκέπτης. Αν διαφέρουν, έχετε πρόβλημα ανεξάρτητα από το πόσο γρήγορο δείχνει το site σε Lighthouse.
Το πρακτικό συμπέρασμα
Η ερώτηση «SSR ή CSR» δεν έχει μία σωστή απάντηση για ολόκληρο ένα site. Έχει μία σωστή απάντηση ανά σελίδα. Στατικό περιεχόμενο πάει σε SSG. Δυναμικό, εξαρτημένο από παραμέτρους περιεχόμενο πάει σε SSR. Οτιδήποτε πίσω από login δεν χρειάζεται καν να μπει στη συζήτηση SEO. Το λάθος που κοστίζει πραγματική κατάταξη δεν είναι η επιλογή ενός «λάθος» framework. Είναι η απουσία απόφασης, η προεπιλογή στο πιο εύκολο για τον developer αντί για το σωστό για τον crawler. Αν χτίζετε ή ξαναχτίζετε ένα site σήμερα, η ερώτηση που αξίζει να κάνετε δεν είναι ποιο framework χρησιμοποιεί η agency σας. Είναι αν μπορούν να σας δείξουν, σελίδα-σελίδα, ποια rendering στρατηγική εφαρμόζεται και γιατί.
Ένσταση: "Το Site μας σε React Ήδη Κατατάσσεται Καλά, Γιατί να Αλλάξουμε;"
Το ακούμε συχνά, και είναι μια δίκαιη ένσταση, γιατί βασίζεται σε πραγματική παρατήρηση, όχι σε άγνοια: πολλά καθαρά CSR sites κατατάσσονται αξιοπρεπώς σήμερα. Η Google βελτίωσε σημαντικά την ικανότητά της να εκτελεί JavaScript τα τελευταία χρόνια, και το δεύτερο κύμα rendering, όσο κι αν καθυστερεί, τελικά συμβαίνει για τις περισσότερες σελίδες.
Το πρόβλημα με αυτή τη λογική είναι ότι συγκρίνει το σήμερα με το σήμερα, όχι το σήμερα με το εναλλακτικό σενάριο. Ένα site που κατατάσσεται "καλά" σε CSR θα κατατασσόταν καλύτερα, και ταχύτερα μετά από κάθε ενημέρωση, σε SSR ή SSG. Η ερώτηση δεν είναι "λειτουργεί;" αλλά "πόσο αφήνετε στο τραπέζι χωρίς να το ξέρετε;". Δεν υπάρχει τρόπος να το μετρήσετε χωρίς A/B test στην πράξη, γιατί δεν μπορείτε να τρέξετε το ίδιο site ταυτόχρονα και στα δύο μοντέλα, και αυτή ακριβώς η αδυναμία σύγκρισης είναι που κάνει την ένσταση να φαίνεται πιο δυνατή από όσο πραγματικά είναι.
Υπάρχει και μια δεύτερη, λιγότερο ορατή πλευρά: "κατατάσσεται καλά" συνήθως σημαίνει "κατατάσσεται καλά στη Google αναζήτηση". Δεν λέει τίποτα για το πώς το βλέπουν οι AI crawlers, που έχουμε ήδη εξηγήσει ότι έχουν πολύ μικρότερη ανοχή σε JavaScript-εξαρτημένο περιεχόμενο, το ίδιο ζήτημα που αναλύουμε σε βάθος στο structured data για ai crawlers. Ένα site μπορεί να έχει καλή θέση 4 στη Google και μηδενική παρουσία σε απαντήσεις ChatGPT ή Perplexity, ταυτόχρονα, χωρίς αντίφαση, γιατί είναι διαφορετικοί crawlers με διαφορετική ανοχή.
Η ειλικρινής απάντηση, λοιπόν, δεν είναι "αλλάξτε τα πάντα αμέσως". Είναι: μετρήστε πρώτα πόσο αργά ευρετηριάζεται νέο περιεχόμενο σε σχέση με τον ανταγωνισμό σας, και ελέγξτε αν εμφανίζεστε καθόλου σε AI-παραγόμενες απαντήσεις για ερωτήματα που σας αφορούν. Αν και τα δύο δείχνουν πρόβλημα, το κόστος αλλαγής rendering μοντέλου δικαιολογείται εύκολα. Αν όχι, ίσως το site σας είναι μία από τις εξαιρέσεις, αλλά αξίζει να το επαληθεύσετε με στοιχεία, όχι να το υποθέσετε επειδή "μέχρι τώρα δεν παραπονέθηκε κανείς".
Ένα Τεχνικό Παράδειγμα με Αριθμούς: TTFB και Time to Interactive
Ας βγάλουμε τη σύγκριση από τη θεωρία με ένα συγκεκριμένο σενάριο που βλέπουμε συχνά σε audits: μία σελίδα υπηρεσίας, ίδιο περιεχόμενο, δύο υλοποιήσεις.
Στην έκδοση CSR, ο server απαντά σε περίπου 80ms με το άδειο HTML container: γρήγορο Time to First Byte, αλλά παραπλανητικό, γιατί ο browser χρειάζεται στη συνέχεια να κατεβάσει ένα JavaScript bundle συνήθως 200-400KB, να το εκτελέσει, να κάνει τα δικά του API calls για το περιεχόμενο, και μόνο τότε να ζωγραφίσει κάτι ουσιαστικό. Σε μια μέτρια σύνδεση κινητού, αυτό σημαίνει Largest Contentful Paint στα 2,5-4 δευτερόλεπτα, και Time to Interactive συχνά πάνω από 4 δευτερόλεπτα σε παλαιότερες συσκευές.
Στην έκδοση SSG της ίδιας ακριβώς σελίδας, το TTFB είναι ελαφρώς χαμηλότερο ή ίδιο (περίπου 50-100ms, γιατί σερβίρεται από CDN), αλλά το HTML που φτάνει περιέχει ήδη το πλήρες περιεχόμενο. Largest Contentful Paint πέφτει τυπικά κάτω από 1 δευτερόλεπτο, γιατί ο browser δεν περιμένει καμία εκτέλεση JavaScript για να δείξει το κύριο κείμενο, μόνο για τα διαδραστικά κομμάτια (κουμπιά, φόρμες) που φορτώνουν παράλληλα.
Η διαφορά σε ανθρώπινους όρους: 3 δευτερόλεπτα αναμονής παραπάνω σημαίνουν μετρήσιμη πτώση σε bounce rate. Η Google έχει δημοσιεύσει στοιχεία ότι η πιθανότητα εγκατάλειψης αυξάνεται κατά 32% όταν ο χρόνος φόρτωσης πάει από 1 σε 3 δευτερόλεπτα. Σε crawler όρους, η διαφορά είναι ακόμα πιο απόλυτη: ο crawler του πρώτου περάσματος βλέπει, στην πρώτη περίπτωση, ένα σχεδόν κενό έγγραφο, και στη δεύτερη, όλο το περιεχόμενο, αμέσως.
Το νούμερο που πείθει τους περισσότερους πελάτες μας δεν είναι το Lighthouse score, είναι αυτό: σε πραγματικά audits, σελίδες SSG ευρετηριάζονται κατά μέσο όρο μέσα σε 24-48 ώρες από τη δημοσίευση, ενώ αντίστοιχες σελίδες CSR στο ίδιο domain χρειάζονται 5-15 ημέρες. Στο ενδιάμεσο διάστημα, μια σελίδα CSR είναι απλά αόρατη σε αναζητήσεις που θα μπορούσε ήδη να κερδίζει.
Το Λάθος με το Infinite Scroll και τη Σελιδοποίηση Client-Side
Υπάρχει ένα μοτίβο συγκεκριμένα σε sites με μεγάλες λίστες (blog με εκατοντάδες άρθρα, e-shop με χιλιάδες προϊόντα) που δεν εμφανίζεται στα βασικά "SSR ή CSR" παραδείγματα, αλλά προκαλεί εξίσου σοβαρή ζημιά: η σελιδοποίηση ή το infinite scroll υλοποιημένο αποκλειστικά σε client-side JavaScript, πάνω σε ένα κατά τα άλλα SSR site.
Η πρώτη σελίδα μιας λίστας προϊόντων μπορεί να είναι τέλεια SSR-rendered, με τα πρώτα 20 προϊόντα ορατά στο view-source. Τα υπόλοιπα 980 προϊόντα, όμως, φορτώνουν μόνο όταν ο χρήστης κάνει scroll ή πατάει "επόμενη σελίδα", μέσω ενός API call που ενεργοποιείται από JavaScript. Ένας crawler που δεν εκτελεί αλληλεπίδραση (δηλαδή σχεδόν κάθε crawler εκτός από τον ίδιο τον browser ενός ανθρώπου) βλέπει μόνο τα πρώτα 20. Τα υπόλοιπα 980 είναι, στην πράξη, αόρατα, ανεξάρτητα από το πόσο καλό SEO markup έχει η κάθε μεμονωμένη σελίδα προϊόντος.
Το ύπουλο σε αυτό το λάθος είναι ότι η πρώτη σελίδα δείχνει άψογη σε κάθε τεστ γρήγορου ελέγχου: Lighthouse καλό, view-source καλό, meta tags σωστά. Το πρόβλημα φαίνεται μόνο όταν ελέγχετε ρητά αν οι επόμενες σελίδες της λίστας έχουν δικό τους, ανακαλύψιμο URL, ή αν υπάρχουν μόνο ως αποτέλεσμα ενός κλικ που ένας crawler δεν κάνει ποτέ.
Η σωστή λύση δεν είναι να καταργήσετε το infinite scroll, που λειτουργεί καλά για τον χρήστη. Είναι να διασφαλίσετε ότι κάθε "σελίδα" της λίστας έχει επίσης ένα πραγματικό, ανακαλύψιμο URL που επιστρέφει SSR περιεχόμενο ανεξάρτητα, ώστε ο crawler να μπορεί να βρει και να ευρετηριάσει κάθε τμήμα, ενώ ο άνθρωπος συνεχίζει να απολαμβάνει το scroll χωρίς να πατάει τίποτα. Αυτό είναι ίσως το πιο συχνό σημείο όπου ένα καλά προγραμματισμένο SSR site χάνει ξαφνικά μεγάλο κομμάτι του crawl budget του σε βαθιά κατηγορίες προϊόντων, ακριβώς το θέμα που αναλύουμε στο crawl budget seo, στενά συνδεδεμένο με το πόσο αποτελεσματικά ανακαλύπτεται μεγάλο περιεχόμενο.