Google nu vede jumătate din site-ul tău. Și AI-ul nu vede nimic.

Deschide site-ul tău chiar acum. Click dreapta. „View Page Source” (sau „Vizualizare sursă pagină”). Uită-te la ce apare. Dacă vezi conținutul tău: texte, titluri, descrieri de produse, tot ce ar trebui să fie acolo, ești în regulă. Dar dacă vezi doar câteva linii de cod și un <div id="root"></div> gol, ai o problemă pe care probabil nu o știi.

Acel <div> gol e tot ce vede Google când îți vizitează site-ul prima dată. Tot ce vede ChatGPT. Tot ce vede Perplexity. Tot ce vede Claude. O pagină goală.

Un studiu Onely pe 6.000 de site-uri a descoperit că 42% din conținutul generat prin JavaScript nu ajunge niciodată în indexul Google. Nu întârziat. Niciodată. Iar site-urile care depind complet de JavaScript pentru a-și afișa conținutul se clasează cu 67% mai jos decât cele care livrează HTML direct.

Și totuși, aproape nimeni din România nu vorbește despre asta. Agențiile vând „SEO tehnic” fără să verifice dacă Google poate măcar citi site-ul pe care l-au construit.

Cum „vede” Google un site: cele două valuri de indexare

Când Googlebot (robotul de căutare al Google) ajunge pe o pagină web, nu o procesează ca un browser obișnuit. Nu deschide Chrome, nu apasă butoane, nu așteaptă animații. Procesul se împarte în două faze distincte, pe care Google le numește intern „cele două valuri de indexare”:

Valul 1: HTML-ul brut (instant)

Googlebot descarcă codul sursă al paginii — exact ce vezi tu când faci „View Source”. Dacă textul, titlurile, link-urile, descrierile și datele structurate (Schema) sunt deja acolo, în HTML, Google le citește și le indexează imediat. Gata. Eficient. Rapid.

Valul 2: randarea JavaScript (coadă de așteptare)

Dacă pagina ta depinde de JavaScript ca să-și afișeze conținutul (adică HTML-ul brut e gol și abia după ce browser-ul execută scripturile apare textul), atunci Googlebot pune pagina la coadă. O coadă specială, unde un serviciu intern numit WRS (Web Rendering Service, serviciul de randare web) deschide pagina într-un browser virtual, execută JavaScript-ul, și abia apoi vede conținutul.

Problema? Coada asta nu e instantă. Un studiu Vercel și MERJ din aprilie 2024, pe 37.000 de pagini, a măsurat exact cât durează:

Deci în cel mai bun caz, conținutul tău JavaScript ajunge în Google cu 10 secunde întârziere. În cel mai rău caz? 18 ore. Iar dacă site-ul tău e mic, nou, sau cu puțină autoritate? Onely a documentat întârzieri de până la 313 ore (aproape 2 săptămâni) pentru pagini JavaScript profunde.

Ce înseamnă CSR, SSR și SSG (pe limba tuturor)

Aceste trei acronime apar constant când vorbim despre cum construiești un site. Sunt termeni tehnici, dar conceptele din spatele lor sunt simple. Iată ce trebuie să știi:

CSR — Client-Side Rendering (randare pe dispozitivul vizitatorului)

Serverul trimite o pagină aproape goală. Doar un schelet de cod. Apoi browser-ul tău (Chrome, Safari, Firefox) descarcă JavaScript-ul și construiește pagina chiar pe telefonul sau calculatorul tău. Tu vezi rezultatul final, dar robotul de căutare vede doar scheletul gol.

E ca și cum ai comanda o mobilă de la IKEA: primești cutia cu piese, și tu o asamblezi acasă. Arată bine la final, dar până asamblezi tu, oricine se uită la cutie vede doar piese împachetate.

SSR — Server-Side Rendering (randare pe server; pagina vine gata)

Serverul construiește pagina complet înainte să o trimită. Când ajunge la tine (sau la Google), conținutul e deja acolo, vizibil, citibil, indexabil. Browser-ul tău doar o afișează.

E ca și cum ai comanda mobila montată: vine gata asamblată, o pui direct în cameră. Oricine intră vede mobila completă.

SSG — Static Site Generation (pagini pre-construite la publicare)

Similar cu SSR, dar paginile se construiesc o singură dată, când publici site-ul, nu de fiecare dată când cineva intră pe ele. Rezultatul: pagini HTML gata făcute, rapide, pe care orice robot le citește instant.

E ca și cum ai avea un catalog tipărit: fiecare pagină e deja scrisă, nu se generează pe loc când cineva deschide catalogul.

Crawlerii AI nu „dau click” și nici nu încearcă

Până aici am vorbit despre Google, care poate executa JavaScript (chiar dacă o face cu întârziere). Dar uite realitatea din 2026: Google nu mai e singurul motor de căutare care contează. ChatGPT, Perplexity, Claude, Gemini — toate au propriii roboți care scanează site-uri.

Și niciunul dintre ei nu execută JavaScript. Niciunul.

Un studiu pe peste 500 de milioane de accesări GPTBot (robotul OpenAI, cel din spatele ChatGPT) a confirmat: zero execuție JavaScript. GPTBot descarcă uneori fișierele JavaScript (în circa 11,5% din cazuri), dar le tratează ca text brut, nu le rulează. Le citește ca pe un document, nu ca pe un program.

Același lucru e valabil pentru ClaudeBot (Anthropic), PerplexityBot, și Bytespider (ByteDance). Când acești roboți accesează site-ul tău, primesc doar HTML-ul brut. Dacă HTML-ul e gol (cum e la CSR), ei văd o pagină goală. Site-ul tău poate fi pe poziția 1 în Google și complet invizibil în ChatGPT.

WordPress: nu e chiar vinovat, dar agențiile îl complică inutil

Aici trebuie o clarificare importantă. WordPress, în forma lui de bază, servește HTML. Adică robotul de căutare primește conținut real din prima accesare. Din perspectiva asta, WordPress nu are problema CSR pe care am descris-o mai sus.

Problema apare când agențiile îl „îmbunătățesc” cu zeci de extensii. Iată ce se întâmplă în practică:

• Page builders (constructori vizuali de pagini) ca Elementor, Divi sau WPBakery generează megabyți de JavaScript și CSS inutil. O pagină simplă care ar avea 50 KB ajunge la 2-3 MB.
• Lazy loading agresiv (încărcare întârziată): imagini, secțiuni întregi de text, chiar și titluri care nu se încarcă până nu derulezi. Tu le vezi, dar robotul care nu „derulează” nu le vede.
• Conținut în taburi și acordeoane care se deschid doar la click. Google a declarat oficial că poate devaloriza conținutul ascuns în spatele interacțiunilor.
• 20+ extensii JavaScript care se încarcă simultan: chat widgets, popup-uri, animații, slidere, contoare. Fiecare adaugă scripturi pe care serverul Google trebuie să le execute.

Rezultatul: un site WordPress care structural ar fi OK devine un coșmar de performanță. Nu pentru că WordPress e rău, ci pentru că nimeni nu verifică ce impact au extensiile astea asupra a ceea ce vede robotul de căutare.

React, Angular, Vue fără SSR: frumos pentru ochi, invizibil pentru roboți

Aici e problema cea mare. Când o agenție construiește un site cu React, Angular sau Vue în modul CSR pur (doar Client-Side Rendering, adică randare exclusiv pe dispozitivul vizitatorului), livrează clientului un produs care arată spectaculos pe ecran, dar care e complet gol pentru motoarele de căutare.

Iată ce se întâmplă tehnic: serverul trimite un fișier HTML care conține practic o singură linie utilă: <div id="app"></div>. Restul e JavaScript. Browser-ul tău descarcă acele scripturi, le execută, și construiește toată pagina pe dispozitivul tău. Tu vezi un site complet. Google vede un <div> gol.

Ironia: clientul plătește premium pentru „tehnologie modernă”, dar primește un site care e mai puțin vizibil pentru Google decât o pagină HTML scrisă în 2005.

Cum verifici singur în 30 de secunde

Nu ai nevoie de instrumente scumpe și nici de cunoștințe tehnice. Trei teste simple care îți spun imediat dacă site-ul tău are problema asta:

Testul 1: View Source (vizualizare sursă)

Deschide site-ul tău. Click dreapta → „View Page Source” (sau Ctrl+U). Caută în codul care apare textul real al paginii tale: titlul principal, descrierea, conținutul. Dacă textul e acolo, ești OK. Dacă vezi doar <script> și <div id="root"></div> fără conținut, ai o problemă.

Testul 2: dezactivează JavaScript

În Chrome: deschide Setări → Securitate și confidențialitate → Setări site → JavaScript → dezactivează. Reîncarcă pagina. Dacă conținutul dispare, crawlerii AI nu-l văd. (Nu uita să reactivezi JavaScript după test.)

Testul 3: Google Search Console

Dacă ai Google Search Console configurat, folosește funcția „Inspectare URL”. Compară „HTML descoperit” cu „Captură de ecran”. Dacă captura arată pagina completă dar HTML-ul descoperit e gol sau incomplet, Google are nevoie de valul 2 de randare ca să-ți vadă conținutul.

Ce fac agențiile din România? (nimic)

Am căutat: „JavaScript rendering SEO România”, „CSR SSR SEO România”, „probleme indexare JavaScript site-uri românești.” Rezultate relevante din piața locală? Zero.

Asta nu înseamnă că problema nu există aici. Înseamnă că nimeni nu o discută. Agențiile din România vând „optimizare SEO” care înseamnă, de cele mai multe ori: cercetare cuvinte cheie, meta titluri, și câteva link-uri. Nimeni nu verifică dacă Google poate efectiv citi conținutul pe care l-au construit.

Un studiu Sitebulb arată că doar 10,6% din profesioniștii SEO declară că înțeleg complet cum tratează Google randarea JavaScript. 10 din 100. Restul fie nu știu, fie nu verifică.

Între timp, 72% din site-uri au cel puțin un factor tehnic SEO critic defect. Nu e o eroare minoră. E o problemă fundamentală care afectează dacă site-ul e vizibil sau nu.

Soluția: cum rezolvi problema (sau cum o eviți din start)

Dacă ai deja un site cu problemă de randare JavaScript, soluțiile variază în funcție de gravitate:

Dacă ai un SPA pur (React, Angular, Vue fără SSR)

Ai nevoie de o migrare la o arhitectură cu SSR (Server-Side Rendering, randare pe server). Nu e un „fix” rapid; e o reconstrucție parțială. React → Next.js, Vue → Nuxt.js, Angular → Angular Universal. Datele susțin investiția: migrarea de la CSR la SSR produce în medie +40% trafic organic (Koanthic, 2026) și site-urile sunt indexate cu 35% mai rapid.

Cifra de +340% din social media vine de la faptul că SSR randează corect Open Graph tags. Când partajezi un link pe Facebook, LinkedIn sau WhatsApp, previzualizarea se generează din HTML-ul brut. Dacă site-ul tău e CSR, previzualizarea e goală sau cu titlu generic. Cu SSR, fiecare pagină arată exact cum trebuie.

Dacă ai WordPress cu extensii problematice

Auditează extensiile. Dezactivează-le una câte una și compară „View Source” cu și fără fiecare extensie. Verifică dacă page builder-ul tău generează conținut în HTML sau doar prin JavaScript. Dacă ai Elementor, Divi, sau WPBakery: conținutul principal (texte, titluri, link-uri) trebuie să fie prezent în HTML-ul brut, nu doar în output-ul JavaScript.

Dacă construiești un site nou

Alege de la început o arhitectură care servește HTML complet. SSR sau SSG. Fiecare pagină publică trebuie să livreze conținut real în primul răspuns HTTP. Meta titluri, descrieri, date structurate, texte, link-uri — totul în HTML, fără dependență de JavaScript pentru conținut SEO-critic.

Ce facem noi la FLASH SHIP

Fiecare site pe care îl construim folosește SSR (Server-Side Rendering) nativ. Asta înseamnă că atunci când orice robot de căutare — fie el Google, Bing, GPTBot, ClaudeBot sau PerplexityBot — accesează o pagină, primește HTML complet din prima milisecundă.

• Conținut în HTML direct: texte, titluri, descrieri, link-uri — totul e prezent în codul sursă, fără dependență de JavaScript.
• Meta titluri și descrieri randate pe server, nu injectate prin JavaScript.
• Date structurate (JSON-LD) livrate direct în HTML: Organization, LocalBusiness, Service, BlogPosting, FAQPage, BreadcrumbList.
• Open Graph tags prezente în HTML-ul brut, pentru previzualizări corecte pe orice platformă.
• Indexare completă din ziua 1: fiecare pagină e descoperibilă, citibilă și indexabilă instant.

Rezultatul: zero dependență de valul 2 de randare. Nicio coadă de așteptare. Nicio pagină invizibilă. Site-ul e citibil complet atât de Google, cât și de fiecare platformă AI care contează în 2026.

Dacă vrei să verifici, fă testul chiar pe flashship.ro. Click dreapta → View Source. Tot conținutul e acolo, în HTML, fără niciun truc.