JavaScript SEO: Οι Παγίδες που Κρύβει ένα React/Next.js Site

Η Googlebot βλέπει μερικές φορές μια εντελώς κενή σελίδα εκεί που εσείς βλέπετε ένα πλήρες website.

Το ψέμα που λέμε στους εαυτούς μας για το "η Google τρέχει JavaScript πια"

Το 2018 η Google ανακοίνωσε επίσημα ότι ο crawler της τρέχει JavaScript. Η βιομηχανία το άκουσε ως "το JavaScript SEO δεν είναι πια πρόβλημα" και προχώρησε. Λάθος συμπέρασμα, σωστό γεγονός. Η Google όντως τρέχει JavaScript, μέσα από μια δεύτερη φάση rendering, ξεχωριστή από την αρχική σάρωση HTML, που ονομάζεται εσωτερικά "δεύτερο κύμα ευρετηρίασης". Αυτό που δεν έγινε ποτέ ευρέως γνωστό είναι πόσο αργό, ασυνεπές, και εύκολο να αποτύχει είναι αυτό το δεύτερο κύμα.

Το πρώτο κύμα διαβάζει το HTML που στέλνει ο server, χωρίς να εκτελεί τίποτα. Αν το site σας εξαρτάται εξ ολοκλήρου από client-side JavaScript για να "γεμίσει" το περιεχόμενο (ένα React SPA με άδειο <div id="root"> στην αρχική απόκριση), το πρώτο κύμα βλέπει ένα σχεδόν κενό έγγραφο. Το πραγματικό περιεχόμενο υπάρχει μόνο στο δεύτερο κύμα, το οποίο μπαίνει σε ουρά ξεχωριστή, με δικό της crawl budget, και μπορεί να καθυστερήσει από ώρες μέχρι εβδομάδες ανάλογα με την αυθεντία του domain σας.

Αυτό είναι το κεντρικό σημείο που λείπει από τις περισσότερες συζητήσεις για JavaScript SEO: δεν είναι θέμα "λειτουργεί ή δεν λειτουργεί". Είναι θέμα καθυστέρησης, αξιοπιστίας, και σπατάλης crawl budget σε δύο περάσματα αντί για ένα.

Τα τρία σενάρια rendering, και ποιο σας αφορά

Client-Side Rendering (CSR)

Ο server στέλνει σχεδόν κενό HTML. Ο browser κατεβάζει το JavaScript bundle, το εκτελεί, και "χτίζει" τη σελίδα τοπικά. Είναι το προεπιλεγμένο μοντέλο ενός καθαρού React SPA χωρίς πρόσθετη υποδομή. Λειτουργεί άψογα για τον χρήστη μετά το πρώτο φόρτωμα. Είναι το χειρότερο δυνατό σενάριο για SEO, γιατί κάθε crawler, όχι μόνο η Google αλλά και τα bots των AI μηχανών αναζήτησης, πρέπει να περάσει από το δεύτερο, αργό, αναξιόπιστο κύμα rendering για να δει οτιδήποτε.

Server-Side Rendering (SSR)

Ο server εκτελεί το JavaScript πριν στείλει την απάντηση, οπότε το HTML που φτάνει στον crawler περιέχει ήδη το πλήρες περιεχόμενο. Αυτό είναι το μοντέλο που χρησιμοποιεί το Next.js από προεπιλογή για τις περισσότερες σελίδες. Ο crawler βλέπει πλήρες περιεχόμενο στο πρώτο πέρασμα, χωρίς να χρειάζεται δεύτερο κύμα rendering.

Static Site Generation (SSG) / Incremental Static Regeneration (ISR)

Το πιο γρήγορο σενάριο: το HTML παράγεται εκ των προτέρων, κατά το build, και σερβίρεται ως στατικό αρχείο μέσω CDN. Καμία εκτέλεση JavaScript δεν χρειάζεται καν να συμβεί για να δει ο crawler το περιεχόμενο. Το ISR προσθέτει τη δυνατότητα να ανανεώνεται αυτό το στατικό περιεχόμενο περιοδικά χωρίς πλήρες rebuild. Τη χρησιμοποιούμε σε πολλά projects πελατών όπου το περιεχόμενο αλλάζει καθημερινά αλλά όχι σε πραγματικό χρόνο.

Η σωστή απόφαση δεν είναι "SSR πάντα" ή "SSG πάντα". Είναι ανά σελίδα: μια σελίδα προϊόντος με σταθερό περιεχόμενο θέλει SSG. Ένας πίνακας ελέγχου χρήστη πίσω από login δεν χρειάζεται καν να νοιάζεται για SEO, άρα CSR είναι μια χαρά εκεί. Το λάθος που βλέπουμε συχνά είναι η εφαρμογή ενός μόνο μοντέλου σε ολόκληρο το site, χωρίς διάκριση ανά τύπο σελίδας.

Πέντε συγκεκριμένα προβλήματα που εμφανίζονται σε πραγματικά audits

1. Meta tags που τοποθετούνται client-side

Αν ο τίτλος, η περιγραφή, ή το canonical tag μιας σελίδας τοποθετούνται μέσω JavaScript μετά το mount ενός component, ο crawler του πρώτου κύματος δεν τα βλέπει καθόλου. Αυτό είναι ιδιαίτερα επικίνδυνο για social media crawlers (Facebook, LinkedIn, X) που συνήθως δεν εκτελούν καθόλου JavaScript. Ένα link που μοιράζεστε εμφανίζεται χωρίς τίτλο, χωρίς περιγραφή, χωρίς εικόνα προεπισκόπησης.

2. Lazy-loaded περιεχόμενο πίσω από interaction

Περιεχόμενο που φορτώνει μόνο μετά από click σε "Δείτε Περισσότερα" ή scroll σε συγκεκριμένο σημείο, μπορεί να μην φορτώσει ποτέ κατά το rendering pass της Google, γιατί ο crawler δεν προσομοιώνει πάντα κάθε πιθανή αλληλεπίδραση χρήστη.

3. Infinite scroll χωρίς pagination fallback

Το infinite scroll είναι εξαιρετικό UX και καταστροφικό για SEO αν είναι η μοναδική μέθοδος πλοήγησης. Χωρίς παραδοσιακά paginated URLs (?page=2, ?page=3) που ο crawler μπορεί να ακολουθήσει ανεξάρτητα, το περιεχόμενο πέρα από την πρώτη "σελίδα" ουσιαστικά δεν υπάρχει για τη μηχανή αναζήτησης.

4. Hydration mismatches που σπάνε το render

Όταν το HTML που παράγει ο server διαφέρει από αυτό που παράγει το JavaScript κατά το hydration στον browser, το React ρίχνει σφάλμα και μπορεί να ξαναχτίσει ολόκληρο το DOM από την αρχή client-side. Σε ακραίες περιπτώσεις, αυτό σημαίνει ότι ο crawler βλέπει σωστό περιεχόμενο στο πρώτο πέρασμα (το SSR HTML), αλλά το δεύτερο κύμα rendering, που εκτελεί πλήρως το JavaScript, βλέπει κάτι διαφορετικό ή σπασμένο. Αυτό είναι, ειρωνικά, ένα πρόβλημα που μεγαλώνει όσο πιο "σωστά" προσπαθεί κανείς να κάνει SSR χωρίς να προσέχει τη συνέπεια server/client.

5. Robots.txt που μπλοκάρει το JavaScript bundle

Σπάνιο αλλά καταστροφικό όταν συμβαίνει: ένα robots.txt που αποκλείει το directory /_next/static/ ή αντίστοιχο. Ο crawler δεν μπορεί καν να κατεβάσει το JavaScript, άρα το δεύτερο κύμα rendering αποτυγχάνει εξ ολοκλήρου. Το ελέγχουμε ρητά σε κάθε xml sitemap robots.txt audit, γιατί είναι εύκολο λάθος να προστεθεί κατά λάθος όταν κάποιος αντιγράφει ένα robots.txt template από άλλο site.

Γιατί το Core Web Vitals score δεν εγγυάται καλό JavaScript SEO

Ένα site μπορεί να έχει άριστο core web vitals τι είναι σκορ (γρήγορο LCP, χαμηλό CLS, καλό INP) και ταυτόχρονα να έχει σοβαρά προβλήματα ευρετηρίασης, γιατί τα Core Web Vitals μετρούν την εμπειρία ενός πραγματικού browser που εκτελεί πλήρως το JavaScript. Δεν μετρούν τι βλέπει ο crawler στο πρώτο πέρασμα rendering.

Αυτά είναι δύο ξεχωριστά προβλήματα που συχνά μπερδεύονται. Ένα site μπορεί να «τρέχει» άψογα και να «ευρετηριάζεται» άσχημα ταυτόχρονα. Το τεστ που χρησιμοποιούμε για να τα ξεχωρίσουμε: ανοίγουμε το εργαλείο "URL Inspection" του Google Search Console, ζητάμε live test, και συγκρίνουμε το rendered HTML που επιστρέφει με αυτό που βλέπει ένας πραγματικός επισκέπτης. Αν διαφέρουν σε βασικό περιεχόμενο (τίτλο, κύριο κείμενο, εσωτερικά links), έχετε JavaScript SEO πρόβλημα, ανεξάρτητα από το πόσο γρήγορο είναι το site.

Το δικό μας site ως παράδειγμα ελεγμένο

Δεν χρειάζεται να μαντέψουμε πώς αντιμετωπίζεται σωστά αυτό: το site της Distarter είναι χτισμένο σε Next.js με server-side rendering ως προεπιλογή, όχι client-side. Κάθε σελίδα περιεχομένου, όπως αυτή που διαβάζετε τώρα, στέλνεται στον crawler ήδη πλήρως διαμορφωμένη από τον server, με τίτλο, περιγραφή και κείμενο μέσα στην πρώτη απόκριση HTML, όχι μετά από ένα δεύτερο πέρασμα JavaScript. Αυτό δεν είναι θεωρητικό: μπορείτε να το επαληθεύσετε μόνοι σας απενεργοποιώντας το JavaScript στον browser σας και φορτώνοντας οποιαδήποτε σελίδα του site. Το βασικό περιεχόμενο παραμένει ορατό.

Είναι το ίδιο μοτίβο που βλέπουμε σε portfolio projects όπως το Armakatone, όπου το Lighthouse SEO score φτάνει 100/100 σε desktop ακριβώς επειδή δεν υπάρχει κενό ανάμεσα σε αυτό που "βλέπει" ο επισκέπτης και σε αυτό που παραδίδεται στον server κατά το πρώτο αίτημα.

Πώς ελέγχουμε ένα JavaScript-heavy site σε audit

Τέσσερα βήματα, με αυτή τη σειρά προτεραιότητας:

1. "View Source" σύγκριση. Ανοίγουμε το πηγαίο HTML (όχι το Inspector του browser, το πραγματικό view-source) και ελέγχουμε αν το κύριο περιεχόμενο υπάρχει ήδη εκεί, πριν εκτελεστεί οτιδήποτε JavaScript.
2. URL Inspection στο Search Console. Συγκρίνουμε το rendered HTML που βλέπει η Google με το πραγματικό site.
3. Disable JavaScript test. Απενεργοποιούμε πλήρως το JavaScript στον browser και πλοηγούμαστε στο site. Αν λείπει βασική πλοήγηση ή περιεχόμενο, το ίδιο συμβαίνει και σε crawlers που δεν εκτελούν JavaScript, όπως πολλά social media bots.
4. Robots.txt έλεγχος για μπλοκαρισμένα assets. Επιβεβαιώνουμε ότι τα JavaScript bundles και τα API endpoints που τροφοδοτούν το περιεχόμενο δεν είναι αποκλεισμένα.

Πόσο σας κοστίζει σε πραγματικό χρόνο: το timeline ενός καθυστερημένου δεύτερου κύματος

Ας βάλουμε νούμερα στο πρόβλημα, γιατί η αφηρημένη έννοια "καθυστέρηση" δεν πείθει κανέναν να αλλάξει κώδικα.

Ένα site με χαμηλή αυθεντία domain (νέο, λίγα backlinks, μικρή ιστορία crawling) που δημοσιεύει μια σελίδα εξ ολοκλήρου εξαρτημένη από client-side rendering βλέπει συνήθως το εξής μοτίβο στο Search Console: το πρώτο κύμα crawling καταγράφει τη σελίδα μέσα σε ώρες, αλλά η αναφορά "Coverage" τη δείχνει ως "Discovered - currently not indexed" ή, χειρότερα, ευρετηριασμένη με μηδενικό ουσιαστικό περιεχόμενο. Το δεύτερο κύμα rendering, αυτό που πραγματικά εκτελεί το JavaScript και βλέπει το κείμενο, μπορεί να καθυστερήσει 5 έως 15 ημέρες σε ένα domain χαμηλής αυθεντίας. Έχουμε δει και περιπτώσεις όπου ξεπέρασε τις τρεις εβδομάδες σε ιδιαίτερα αδύναμα domains με αργό server.

Η πρακτική συνέπεια: αν ένας ανταγωνιστής με SSR ή SSG δημοσιεύσει το ίδιο θέμα την ίδια μέρα με εσάς, το δικό του περιεχόμενο μπορεί να εμφανιστεί στα αποτελέσματα μέσα σε 24-48 ώρες, ενώ το δικό σας περιμένει ακόμα το δεύτερο πέρασμα. Σε ανταγωνιστικά θέματα, όπου η "φρεσκάδα" περιεχομένου παίζει ρόλο στην κατάταξη, αυτό το παράθυρο των 10-15 ημερών δεν είναι λεπτομέρεια. Είναι όλη η διαφορά ανάμεσα στο να πιάσετε το πρώτο κύμα ενδιαφέροντος για ένα θέμα και στο να φτάσετε όταν έχει ήδη κατασταλάξει η κατάταξη γύρω από τον ανταγωνιστή σας.

Το αντίθετο σενάριο το βλέπουμε σε δικά μας projects με SSR από προεπιλογή: μια νέα σελίδα δημοσιεύεται, το Search Console τη δείχνει πλήρως ευρετηριασμένη με το σωστό κείμενο μέσα σε ώρες, όχι ημέρες, ακριβώς επειδή δεν υπάρχει δεύτερο κύμα να περιμένει κανείς. Δεν είναι θέμα τύχης domain authority. Είναι θέμα αρχιτεκτονικής που αφαιρεί ολόκληρο το βήμα καθυστέρησης από την εξίσωση.

Βήμα-βήμα: πώς μεταφέρετε ένα CSR React site σε υβριδικό rendering χωρίς να ξαναγράψετε τα πάντα

Δεν χρειάζεται να ρίξετε ολόκληρο το site για να διορθώσετε αυτό το πρόβλημα. Η μετάβαση γίνεται σταδιακά, με αυτή τη σειρά:

1. Καταγράψτε κάθε σελίδα και ταξινομήστε την. Στατικό περιεχόμενο (blog, υπηρεσίες, portfolio) πάει σε μία κατηγορία. Δυναμικό περιεχόμενο που αλλάζει συχνά (τιμές, διαθεσιμότητα) σε άλλη. Οτιδήποτε είναι πίσω από login δεν χρειάζεται καν να μπει στη συζήτηση. Το SEO δεν το αφορά ποτέ.
2. Ιεραρχήστε με βάση την αξία, όχι τη δυσκολία. Οι σελίδες με το μεγαλύτερο οργανικό δυναμικό (landing pages, κατηγορίες προϊόντων, άρθρα με keyword στόχευση) μεταφέρονται πρώτες, ανεξάρτητα από το πόσο "εύκολο" φαίνεται τεχνικά.
3. Μεταφέρετε αυτές τις σελίδες σε SSR ή SSG. Σε ένα framework σαν το Next.js, αυτό σημαίνει static generation στο build ή server-side data fetching πριν την απόκριση, όχι πλέον fetch μέσα σε useEffect μετά το mount.
4. Ρυθμίστε ISR revalidation ανάλογα με τη συχνότητα αλλαγής. Μια σελίδα υπηρεσιών που αλλάζει σπάνια μπορεί να ανανεώνεται κάθε ώρα. Μια σελίδα τιμών θέλει revalidation on-demand, ακριβώς τη στιγμή που αλλάζει η τιμή, όχι σε τυχαίο χρονικό παράθυρο.
5. Επαληθεύστε με view-source μετά από κάθε μετάβαση, όχι μόνο οπτικά στον browser. Αν το κείμενο δεν είναι εκεί στο raw HTML, η μετάβαση απέτυχε, ανεξάρτητα από το πόσο σωστά φαίνεται στο DevTools.
6. Παρακολουθήστε το Search Console Coverage εβδομαδιαία κατά τη διάρκεια του rollout, όχι μόνο μία φορά στο τέλος. Η ευρετηρίαση αντιδρά με καθυστέρηση, και το πρώτο σημάδι επιτυχίας είναι η μείωση των σελίδων σε "Discovered - currently not indexed".

Το τμήμα του site που παραμένει CSR (πίνακες ελέγχου, εσωτερικά εργαλεία) δεν χρειάζεται καμία από αυτές τις αλλαγές. Και αυτό είναι το σημείο που πολλές ομάδες προγραμματιστών ξεχνούν: δεν είναι κάθε γραμμή κώδικα SEO πρόβλημα, μόνο αυτή που καθορίζει τι βλέπει η μηχανή αναζήτησης.

Το λάθος που κάνουν οι περισσότερες agencies: ελέγχουν το λάθος πράγμα

Η πιο συχνή διαβεβαίωση που ακούμε από πελάτες που ήρθαν από άλλη agency: "Μας είπαν ότι το site μας είναι εντάξει, το έλεγξαν με Lighthouse". Το πρόβλημα είναι δομικό: το Lighthouse, όπως και κάθε εργαλείο που τρέχει μέσα σε πραγματικό browser (Chrome DevTools, PageSpeed Insights στην προεπιλεγμένη λειτουργία του), εκτελεί πλήρως το JavaScript πριν μετρήσει οτιδήποτε. Βλέπει, δηλαδή, ακριβώς το αντίθετο σενάριο από αυτό που βλέπει ο crawler στο πρώτο πέρασμα. Ένα site μπορεί να πάρει 95/100 στο Lighthouse και ταυτόχρονα να στέλνει ένα σχεδόν κενό έγγραφο HTML στην πρώτη αίτηση. Τα δύο εργαλεία απλά δεν μετράνε το ίδιο πράγμα, όσο κι αν μοιάζουν να το κάνουν.

Η δεύτερη παγίδα είναι η υπόθεση ότι "αφού βάλαμε meta tags με το next/head (ή αντίστοιχη βιβλιοθήκη), τελειώσαμε". Αν αυτά τα tags τοποθετούνται μέσω client-side component που τρέχει μετά το mount, ο έλεγχος δεν αρκεί: χρειάζεται επιβεβαίωση ότι εμφανίζονται ήδη στο πρώτο HTML που στέλνει ο server, όχι απλώς κάπου στο DOM όταν η σελίδα έχει ήδη φορτώσει πλήρως στον browser. Το να δείξεις σε έναν πελάτη "κοιτάξτε, υπάρχει τίτλος" ανοίγοντας τα DevTools δεν αποδεικνύει τίποτα για το τι βλέπει πρώτα ο crawler.

Η αντίρρηση "Το site μας κατατάσσεται μια χαρά" και γιατί κρύβει το πραγματικό πρόβλημα

Συχνά ακούμε: "Δεν έχουμε πρόβλημα, εμφανιζόμαστε πρώτοι όταν κάποιος γράφει το όνομά μας στη Google". Αυτό είναι αλήθεια και ταυτόχρονα εντελώς άσχετο. Μια αναζήτηση branded ("Distarter", "όνομα εταιρείας") βασίζεται σε αυθεντία domain και σε σήματα εκτός σελίδας, όχι σε αυτό που περιέχει η ίδια η σελίδα. Ακόμα και ένα site με μηδενικό ορατό περιεχόμενο στο πρώτο κύμα μπορεί να καταταχθεί πρώτο για το ίδιο του το όνομα, γιατί κανείς άλλος δεν ανταγωνίζεται γι' αυτόν τον όρο.

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

Το edge case που αλλάζει τους κανόνες: React Server Components και streaming SSR

Η νεότερη γενιά του App Router στο Next.js εισάγει μια αχνή αλλά σημαντική διαφοροποίηση: με streaming SSR και Suspense boundaries, ο server μπορεί να στείλει το αρχικό "κέλυφος" HTML αμέσως, και να ακολουθήσουν επιπλέον κομμάτια περιεχομένου σε επόμενα chunks της ίδιας HTTP σύνδεσης, καθώς ολοκληρώνονται αργά data fetches. Το καλό νέο: αυτό δεν είναι το ίδιο πρόβλημα με το CSR, γιατί όλο το περιεχόμενο παραμένει server-rendered. Δεν χρειάζεται δεύτερο κύμα crawling για να εμφανιστεί.

Το σημείο προσοχής είναι διαφορετικό: αν το κύριο περιεχόμενο SEO αξίας (ο τίτλος H1, το κύριο σώμα κειμένου) τοποθετηθεί μέσα σε ένα Suspense boundary που περιμένει ένα αργό API call, υπάρχει ρίσκο ο crawler να "κόψει" τη σύνδεση πριν ολοκληρωθεί το streaming, ανάλογα με τα timeouts που εφαρμόζει. Η πρακτική οδηγία: το πιο σημαντικό περιεχόμενο για SEO πρέπει να είναι μέρος του άμεσου flush, όχι πίσω από ένα loading skeleton που περιμένει τη βραδύτερη πηγή δεδομένων της σελίδας. Το ελέγχουμε ρητά σε κάθε technical seo audit που κάνουμε πλέον σε projects με App Router, γιατί είναι αρκετά νέο ζήτημα ώστε οι περισσότερες ελληνικές agencies να μην το έχουν καν προσέξει ακόμα.

Το πρακτικό συμπέρασμα για μια νέα build απόφαση

Αν είστε στη φάση επιλογής framework, η ερώτηση δεν είναι "React ή όχι React". Είναι "ποιο rendering μοντέλο χρησιμοποιεί το framework μου από προεπιλογή, και μπορώ να το αλλάξω ανά σελίδα όταν χρειάζεται". Το Next.js δίνει αυτή την ευελιξία εγγενώς: SSG για στατικό περιεχόμενο, SSR για δυναμικό, ISR για κάτι ενδιάμεσο. Ένα καθαρό React SPA χτισμένο με Create React App ή Vite χωρίς πρόσθετη υποδομή rendering δεν σας δίνει αυτή την επιλογή καθόλου, και αυτό εξηγεί εν μέρει γιατί οι next.js vs wordpress ταχύτητα συγκρίσεις δεν λένε ολόκληρη την ιστορία. Το θέμα δεν είναι μόνο ταχύτητα, είναι το τι βλέπει ο crawler στο πρώτο δευτερόλεπτο.

Το ίδιο ζήτημα rendering επηρεάζει και το πώς σας "διαβάζουν" τα AI συστήματα αναζήτησης σήμερα. Ένα ChatGPT ή Perplexity bot που κάνει fetch σε ένα URL συχνά δεν εκτελεί JavaScript καθόλου, συνθήκη που εξηγούμε αναλυτικά στο άρθρο για το markdown ai parsing. Αν το site σας εξαρτάται από client-side rendering, ένα AI σύστημα που προσπαθεί να σας παραθέσει ως πηγή μπορεί απλά να μη βρει τίποτα να διαβάσει.

Το τεστ που τρέχουμε σε κάθε νέο πελάτη πριν από οτιδήποτε άλλο

Πριν προτείνουμε οποιαδήποτε αλλαγή στο πώς να κάνω πιο γρήγορο το site μου, ελέγχουμε πρώτα αν το βασικό περιεχόμενο είναι καν ορατό χωρίς JavaScript. Η ταχύτητα δεν έχει σημασία αν το περιεχόμενο που θέλετε να κατατάξει η Google απλά δεν υπάρχει στο πρώτο πέρασμα rendering. Είναι το πιο θεμελιώδες τεστ που κάνουμε, και το πιο συχνά παραλειπόμενο από agencies που εστιάζουν αποκλειστικά σε metrics ταχύτητας χωρίς να ελέγχουν τι βλέπει πραγματικά ο crawler.