JavaScript SEO: cum randează și indexează Google site-urile dinamice

JavaScript SEO înseamnă să te asiguri că Google poate vedea conținutul și linkurile unui site care se construiește în browser, nu pe server. Google poate randa JavaScript, dar o face într-o etapă separată, după crawlare, ceea ce adaugă întârzieri și riscuri. Regula practică: tot ce trebuie indexat (text, titluri, linkuri, canonical) să fie disponibil cât mai devreme, de preferat direct în HTML.

Cum procesează Google o pagină cu JavaScript

Documentația Google descrie trei faze: crawlare, randare, indexare.

1. Crawlarea. Googlebot cere URL-ul, verifică robots.txt și primește HTML-ul inițial. Din el extrage linkurile din elementele <a href>. Dacă pagina e permisă și returnează un cod 200, urmează randarea.
2. Randarea. Paginile ajung într-o coadă, apoi un Chromium fără interfață (headless) execută JavaScript și construiește pagina finală. Cât stă o pagină în coadă variază: de la câteva secunde până la mult mai mult.
3. Indexarea. Google folosește HTML-ul randat pentru a înțelege și a indexa conținutul, și pentru a descoperi noi linkuri.

De aici decurg două consecințe. Prima: ce nu apare în HTML-ul randat nu există pentru Google. A doua: totul care depinde de randare ajunge mai târziu în index decât ce este deja în HTML. Pentru un blog care publică zilnic sau un magazin cu stoc în schimbare, întârzierea poate conta.

Un detaliu util: Googlebot folosește un Chromium actualizat continuu, deci suportă API-urile moderne din browser. Problemele nu vin de la „Google nu știe JavaScript”, ci de la modul în care e scris site-ul. De aceea, randarea face parte din SEO-ul tehnic, alături de indexare, viteză și coduri de status.

Modele de randare: unde se construiește pagina

Alegerea modelului este decizia care influențează cel mai mult comportamentul în căutare. Explicații mai detaliate despre fiecare găsești în materialele web.dev.

Pe scurt: pentru paginile care trebuie să fie găsite în Google, alege SSR sau SSG. CSR pur rămâne potrivit pentru zonele care nu au rost în căutare.

Randarea dinamică

Servirea unei versiuni pre-randate doar pentru roboți (dynamic rendering) a fost un ocol popular. Documentația actuală o tratează ca soluție temporară de ocolire, nu ca practică recomandată pe termen lung, pentru că adaugă complexitate și riscul ca boții și oamenii să vadă lucruri diferite.

Ce se strică cel mai des

Linkuri care nu sunt linkuri

Googlebot descoperă adresele din elementele <a> cu atribut href. Un buton sau un <span> cu onclick nu este urmat.

<!-- Corect: crawlerul poate urma linkul -->
<a href="/servicii/audit">Audit complet</a>

<!-- Greșit: nu există adresă de descoperit -->
<span onclick="navigate('/servicii/audit')">Audit complet</span>

<!-- Greșit pentru indexare: fragmentul nu identifică o pagină separată -->
<a href="#/servicii/audit">Audit complet</a>

Pentru aplicații cu o singură pagină folosește History API, nu fragmente (#). Schema veche de crawlare AJAX (cu #!) este considerată depășită de Google încă din 2015.

Conținut care apare doar după interacțiune

Googlebot nu dă clic, nu derulează și nu completează formulare. Dacă textul important apare doar după un clic pe „Citește mai mult” sau după derulare, riști ca el să lipsească din randare. Pentru încărcarea la derulare (lazy loading) folosește mecanisme recomandate, precum IntersectionObserver sau atributul nativ loading="lazy", nu evenimente de scroll care presupun un utilizator real.

Metadate modificate prin JavaScript

Poți adăuga sau modifica titlul, canonical-ul și meta robots cu JavaScript, dar cu limite:

• dacă pagina conține noindex în HTML-ul inițial, Google poate să nu mai randeze pagina, deci nu te baza pe ștergerea lui din JavaScript;
• nu schimba canonical-ul față de cel din HTML și nu lăsa mai mult de unul pe pagină;
• cel mai sigur este să trimiți titlul, descrierea și canonical-ul chiar din server. Pentru logica canonicalelor, vezi articolul despre canonical și conținut duplicat.

Erori soft 404 în aplicații SPA

Un SPA întoarce adesea 200 pentru orice adresă, iar aplicația afișează „Pagina nu a fost găsită”. Google vede un 200 și poate trata pagina ca soft 404. Soluții: întoarce un cod 404 real de la server pentru adresele inexistente, sau redirecționează către o pagină care returnează 404, ori adaugă dinamic noindex pe pagina de eroare. Motivele frecvente de excludere din index sunt explicate în ghidul despre paginile neindexate.

Resurse blocate

Dacă robots.txt blochează fișierele JavaScript sau CSS de care depinde afișarea, Google nu poate randa corect pagina. Nu bloca directoarele de scripturi. Verifică fișierul cu generatorul de robots.txt și testează cu instrumente de inspecție.

Date care nu persistă

Googlebot nu păstrează între pagini stocarea locală, de sesiune sau cookie-urile. Dacă pagina depinde de ele ca să afișeze conținutul, va apărea goală pentru Google. Nu condiționa conținutul indexabil de permisiuni (cameră, locație): Googlebot le refuză.

Cum verifici ce vede Google: pași practici

Orice audit de JavaScript SEO începe cu o comparație: ce trimite serverul versus ce rezultă după randare.

1. Deschide codul sursă (Ctrl+U) și caută o propoziție din conținutul principal. Dacă o găsești, conținutul e în HTML. Dacă nu, el apare doar după randare.
2. Compară cu DOM-ul randat din instrumentele browserului (Inspect). Diferențele arată ce adaugă scripturile.
3. Folosește inspecția URL-ului în Search Console și apoi testul live. Vezi HTML-ul randat, captura de ecran, resursele neîncărcate și erorile din consolă.
4. Rulează un crawler cu randare JavaScript pe un eșantion de pagini și compară cu rezultatul fără randare.
5. Caută pe Google o propoziție exactă din pagină. Dacă pagina e indexată, dar propoziția nu apare, este un semn că Google poate să nu fi văzut acel text.
6. Verifică viteza. Scripturile grele afectează și experiența utilizatorilor; vezi Core Web Vitals și viteza site-ului și testează cu testul de viteză.

Simptome frecvente și cauze probabile

Când o pagină construită dinamic nu se comportă cum te aștepți în Google, tabelul de mai jos te ajută să pornești de la simptom, nu de la presupuneri.

Un exemplu de verificare în trei pași, pe o pagină de produs sau de serviciu: (1) cere URL-ul cu un client simplu, fără JavaScript, și vezi dacă numele produsului, descrierea și linkul către categorie sunt în răspuns; (2) deschide același URL în inspecția Search Console și compară HTML-ul randat; (3) schimbă o literă din adresă și verifică dacă serverul întoarce 404. Dacă oricare dintre cele trei pică, ai găsit prioritatea.

Pentru site-uri mari, merită o strategie pe șabloane: nu verifici o mie de pagini, ci un tip de pagină la un moment dat (acasă, categorie, produs, articol). Dacă șablonul e corect, mii de pagini sunt corecte; dacă e greșit, mii de pagini au aceeași problemă.

Date structurate și JavaScript

Google acceptă JSON-LD injectat prin JavaScript, dar documentația recomandă testarea atentă. Mai sigur, include-l în HTML-ul trimis de server. Dacă lucrezi cu un framework, generează blocul JSON-LD la randarea pe server. Exemple și validări găsești în ghidul de date structurate.

Dimensiunea fișierelor și performanța

Googlebot are o limită de dimensiune pentru fiecare fișier descărcat, aplicată pe datele necomprimate. Documentația actuală menționează primii 2 MB pentru fișierele obișnuite (limita pentru PDF-uri este mai mare, de 64 MB), iar limita se aplică separat fiecărei resurse referite (HTML, JavaScript, CSS). Ce depășește limita nu mai este luat în considerare la indexare. Practic: un bundle JavaScript imens, de ordinul megabiților, e problematic și pentru utilizatori, nu doar pentru Google. Împarte codul, încarcă la cerere ce nu e critic și folosește nume de fișiere cu amprentă (fingerprinting), pentru că Googlebot poate păstra fișierele în cache, iar o amprentă în nume forțează reîncărcarea lor când se schimbă conținutul.

Crawlerele AI și JavaScript

Googlebot execută JavaScript, dar nu orice crawler face la fel. Pentru boții care alimentează căutarea cu AI nu am găsit o garanție oficială generală că randează scripturile, așa că nu presupune că o fac. Dacă vrei ca textul tău să fie citat acolo, cea mai sigură cale este ca el să fie în HTML-ul inițial. Despre cum le permiți sau le blochezi accesul, vezi articolul despre boții AI și robots.txt.

Greșeli frecvente

• HTML inițial gol, cu un singur <div id="root"> și tot conținutul adus prin scripturi.
• Linkuri fără href sau cu fragmente în loc de adrese reale.
• Aceeași adresă pentru conținut diferit (de exemplu schimbarea conținutului fără schimbarea URL-ului).
• Titlu și meta description identice pe toate paginile unui SPA.
• Pagini de eroare cu status 200.
• JavaScript blocat în robots.txt.
• Conținut esențial ascuns în spatele unui clic.
• Presupunerea că „se vede în browser, deci se vede în Google”.
• Redirecturi făcute doar din JavaScript când se putea face un 301 de la server. Cele de server sunt mai clare pentru roboți; detalii în articolul despre redirecturi 301 și 302.

Limite: când problema nu e JavaScript-ul

Nu orice problemă de indexare vine din scripturi. Înainte să refaci arhitectura, exclude cauzele simple: pagini blocate, noindex rămas din testare, canonical greșit, conținut slab sau duplicat. De asemenea:

• un site mic și static cu puțin JavaScript decorativ nu are de ce să-ți facă griji;
• zonele cu autentificare (conturi, panouri) nu trebuie indexate, deci randarea lor nu contează pentru SEO;
• nicio configurare nu garantează indexarea: Google nu indexează toate paginile pe care le găsește.

Concluzie: ce faci în continuare

JavaScript nu este un dușman al SEO-ului, dar cere disciplină. Pași concreți:

1. Alege SSR sau generare statică pentru paginile care trebuie găsite în căutare.
2. Verifică linkurile: <a href> cu adrese reale, fără fragmente.
3. Compară codul sursă cu HTML-ul randat din Search Console pe câte o pagină de fiecare tip.
4. Asigură coduri de status corecte (200, 301, 404) de la server.

Dacă ai un site dinamic care nu se indexează cum ar trebui, serviciul de SEO tehnic începe cu exact aceste verificări. Mai multe ghiduri găsești pe blog.