JavaScript SEO: ce indexează Google și ce rămâne invizibil

JavaScript și SEO e una dintre acele combinații care sună simplu pe hârtie, dar te bagă în probleme reale când vezi că jumătate din site-ul tău nu apare în Google. Dacă lucrezi cu React, Vue, Angular sau orice framework modern, ai întâlnit probabil situația: pagina arată perfect în browser, dar în Search Console e goală sau apare cu conținut parțial.

Hai să clarificăm ce indexează Google din JavaScript, ce ignoră și unde greșesc cei mai mulți developeri când livrează un site SPA către echipa de marketing.

Pe scurt: cum funcționează indexarea JavaScript

Google procesează paginile JS în două etape. Asta e diferența fundamentală față de HTML clasic.

• Etapa 1 – crawling: Googlebot descarcă HTML-ul inițial. Dacă acolo nu e nimic relevant (cazul SPA-urilor), trece mai departe.
• Etapa 2 – rendering: pagina intră într-o coadă de rendering. Google folosește o versiune Chromium ca să execute JS-ul și să vadă conținutul final.
• Etapa 3 – indexare: abia după rendering, conținutul ajunge efectiv în index.

Problema: între etapa 1 și 2 pot trece de la câteva ore la câteva săptămâni. Iar dacă în etapa 1 Googlebot nu găsește linkuri, nu mai descoperă alte pagini de pe site.

Ce indexează Google fără probleme

Lucrurile care funcționează rezonabil de bine în 2024-2025:

• Conținut randat client-side care apare în maxim 5 secunde după încărcare
• Linkuri standard <a href="..."> generate prin JS
• Meta tags injectate prin JS (title, description) – dar cu întârziere
• Structured data (JSON-LD) generat dinamic
• Imagini lazy-loaded corect, cu atribut loading="lazy" nativ

Cuvântul cheie aici e „rezonabil”. Google poate să le indexeze. Asta nu înseamnă că o va face rapid sau consistent pentru fiecare pagină.

Ce rămâne invizibil sau problematic

Lista lucrurilor care îți strică indexarea, în ordinea frecvenței cu care le văd în audituri:

1. Conținut care apare doar la interacțiune

Text afișat după click pe „Read more”, taburi, accordion-uri încărcate la click. Googlebot nu dă click pe nimic. Dacă vrei ca acel conținut să fie indexat, trebuie să existe în DOM la încărcare, chiar dacă e ascuns vizual prin CSS.

2. Linkuri care nu sunt linkuri

Clasica greșeală: <div onclick="navigate()"> sau <span> cu event listener. Pentru Google, nu există. Folosește <a href> real, chiar dacă overrides cu router-ul JS.

3. Conținut blocat prin robots.txt

Mulți blochează folder-ele /static/, /assets/ sau bundle-urile JS. Rezultat: Google nu poate randa pagina pentru că nu poate descărca JS-ul necesar. Verifică robots.txt și asigură-te că fișierele JS și CSS sunt accesibile.

4. Hash-uri în URL (#)

URL-uri de tip example.com/#/produs/123 nu sunt tratate ca pagini separate. Tot ce e după # e ignorat. Folosește History API și URL-uri reale.

5. Date încărcate prin API-uri cu autentificare

Dacă conținutul vine dintr-un API care cere token, Googlebot nu îl primește. Soluția: SSR sau prerender pentru roboți.

SSR, SSG, prerender – care funcționează când

Nu există soluție universală. Depinde de tipul site-ului și de bugetul tehnic.

• Server-Side Rendering (SSR): bun pentru site-uri cu conținut dinamic (e-commerce, news). Next.js și Nuxt rezolvă asta nativ. Cost: server mai scump și complexitate de cache.
• Static Site Generation (SSG): ideal pentru bloguri, landing pages, documentație. Generezi HTML la build. Rapid, ieftin, perfect indexabil.
• Prerendering (Prerender.io, Rendertron): servești HTML pre-randat doar pentru boți. Funcționează, dar Google preferă să vadă același conținut ca utilizatorii. Risc de cloaking dacă e implementat prost.
• Client-Side Rendering pur (CSR): acceptabil doar pentru aplicații private (dashboard-uri, tool-uri). Pentru SEO, evită-l.

Recomandarea mea pentru proiecte noi: dacă SEO contează, alegi din start un framework cu SSR/SSG. Migrarea de la CSR la SSR pe un proiect existent durează 2-6 luni și costă între 5.000 și 25.000 EUR, depinde de complexitate.

Cum verifici ce vede efectiv Google

Nu te baza pe „merge la mine în browser”. Folosește instrumentele care simulează Googlebot:

• URL Inspection în Search Console: click pe „Test Live URL” și vezi HTML-ul randat de Google. Compară-l cu ce vezi tu.
• Mobile-Friendly Test: arată screenshot-ul randat și HTML-ul final. Util pentru debugging rapid.
• View Rendered Source (extensie Chrome): compară HTML-ul inițial cu DOM-ul după JS.
• Screaming Frog cu rendering JavaScript activat: crawl complet pe site, vezi exact ce linkuri și conținut găsește un bot.

Dacă HTML-ul inițial (Ctrl+U) e gol și conținutul apare doar în DOM, ai o problemă. Poate fi tolerabilă pentru câteva pagini, dar pe mii de URL-uri devine gravă.

Greșeli frecvente pe care le văd în audituri

• Title și meta description injectate târziu: Google indexează primul title pe care îl vede. Dacă React Helmet schimbă title-ul după 2 secunde, riscă să rămâi cu cel default.
• Canonical setat dinamic: canonical-ul trebuie să fie în HTML-ul inițial. Setarea lui prin JS e o sursă constantă de probleme.
• Infinite scroll fără paginare reală: Googlebot nu derulează. Conținutul de la pozițiile 20+ nu există pentru el. Adaugă paginare clasică cu URL-uri distincte.
• Status code 200 pentru pagini inexistente: SPA-urile returnează 200 pentru orice URL. Google indexează pagini „Not Found” ca pagini valide. Implementează 404 real server-side.
• Sitemap care nu corespunde cu realitatea: sitemap generat dintr-o sursă, conținut randat din alta. Discrepanțele duc la pagini neindexate.

Core Web Vitals și JavaScript

JavaScript prost optimizat strică Core Web Vitals. Bundle-uri mari, hidratare lentă, layout shift din componente care apar târziu. Toate afectează poziționarea.

Realist, asta înseamnă: code splitting agresiv, lazy loading pentru ce nu e above-the-fold, server components unde se poate, evitarea librăriilor JS care fac același lucru ca 10 linii de cod nativ.

Un site React clasic pornește de la 200-400 KB de JS doar pentru framework. Adaugi UI library, state management, analytics – ajungi rapid la 1 MB. Pe mobile cu 3G, asta înseamnă LCP de 4-6 secunde. Google penalizează.

Când JavaScript SEO nu e problema ta principală

Dacă site-ul tău are sub 100 de pagini și conținut static, nu te complica cu SSR. Google indexează bine și SPA-uri mici. Concentrează-te pe conținut, structură de linkuri interne și autoritate externă.

Pentru autoritate externă, advertorialele rămân una dintre metodele cele mai stabile. Dacă lucrezi la profilul de linkuri, poți publica articole în publicații verificate prin SEO DIGITAL și te concentrezi pe partea tehnică în paralel. Sunt două probleme separate care nu se exclud.

Pe scurt, dacă ai sărit până aici

Google indexează JavaScript, dar cu întârziere și inconsistent. Pentru orice site care depinde de trafic organic, alege SSR sau SSG. Verifică ce vede Googlebot prin Search Console, nu prin browserul tău. Și nu uita: linkurile trebuie să fie <a href>, conținutul important trebuie să existe în DOM la încărcare, iar canonical-ul nu se setează prin JS.