Continutul apare in browser, dar nu in Google: cum verifici daca JavaScript blocheaza indexarea

Deschizi pagina in browser si totul pare in regula: titlul produsului apare, descrierea este completa, meniul functioneaza, iar utilizatorul poate naviga normal. In Google, insa, pagina nu este indexata cum te astepti sau continutul important pare sa lipseasca.

Pe un site bazat pe React, Vue sau alta arhitectura cu randare JavaScript, faptul ca un utilizator vede continutul in browser nu demonstreaza automat ca Google a primit si a randat aceeasi versiune. Browserul tau poate avea cookie-uri, local storage, sesiuni existente, permisiuni sau alte conditii pe care sistemul de randare Google nu le are.

Un diagnostic corect de JavaScript SEO si indexare trebuie sa urmareasca intregul traseu: ce raspunde serverul, ce resurse poate accesa Googlebot, ce produce JavaScript dupa executie, ce linkuri descopera Google si ce versiune ajunge efectiv sa fie folosita pentru indexare.

De ce browserul si Google pot vedea lucruri diferite

Un browser modern poate transforma un raspuns HTML minimal intr-o pagina complexa. Descarca JavaScript, executa aplicatia, solicita date prin HTTP, modifica DOM-ul si afiseaza continutul rezultat.

Google poate executa JavaScript si foloseste un sistem de randare bazat pe Chromium. Totusi, documentatia Google subliniaza ca exista diferente si limitari care trebuie luate in calcul. De aceea, „functioneaza la mine in Chrome” nu este un test suficient pentru indexare.

Mai exista o diferenta importanta: browserul tau poate avea deja stare. Poate exista o sesiune autentificata, date salvate local sau un consimtamant acordat anterior. Sistemul Google de randare nu trebuie presupus ca porneste cu aceeasi stare.

HTML initial versus DOM randat

Sa luam o pagina de produs simplificata. Serverul poate raspunde initial cu ceva conceptual de forma:

<main id="app"></main>

Aplicatia JavaScript porneste apoi, cere produsul printr-un endpoint si introduce in DOM numele, descrierea, pretul, imaginile si alte informatii.

Daca alegi View Source in browser, vezi in principal codul initial returnat de server. Daca deschizi DevTools si inspectezi fila Elements dupa executarea aplicatiei, vezi DOM-ul rezultat. Documentatia Search Console explica exact aceasta diferenta: sursa initiala si codul final randat nu sunt neaparat acelasi lucru.

Pentru SEO, intrebarea importanta devine: continutul important apare si in HTML-ul randat accesibil Google?

Crawling, rendering si indexing sunt etape diferite

Google descrie procesarea aplicatiilor JavaScript in trei faze principale: crawling, rendering si indexing.

1. Crawling

Googlebot solicita URL-ul si verifica inclusiv daca accesul este permis. Raspunsul initial poate contine deja continutul paginii sau poate fi doar un app shell care necesita JavaScript pentru a genera continutul principal.

2. Rendering

Paginile eligibile sunt procesate de sistemul de randare, unde JavaScript poate fi executat. Google precizeaza ca paginile cu status HTTP 200 sunt trimise catre coada de randare daca nu exista o directiva care impiedica indexarea; pentru raspunsurile non-200, randarea poate fi omisa.

Google avertizeaza si ca nu este evident din exterior cand o pagina asteapta crawling-ul sau rendering-ul. De aceea, o arhitectura care livreaza continutul esential direct in raspunsul HTML poate reduce dependenta de aceasta etapa pentru descoperirea continutului.

3. Indexing

Dupa procesare, Google poate folosi HTML-ul randat pentru indexare si poate extrage din nou linkuri. Indexarea nu este insa garantata doar pentru ca pagina poate fi randata: Google analizeaza si alte aspecte, inclusiv canonicalizarea si continutul paginii.

Cum verifici concret pagina

Pentru un URL pe care il controlezi, Search Console URL Inspection este punctul practic de pornire.

1. Inspecteaza URL-ul complet.
2. Analizeaza informatiile despre versiunea cunoscuta de Google.
3. Ruleaza Test Live URL daca vrei sa verifici implementarea actuala.
4. Deschide View Tested Page.
5. Verifica HTML-ul randat.
6. Verifica screenshot-ul disponibil pentru testul live.
7. Analizeaza resursele incarcate si eventualele mesaje sau exceptii JavaScript.

Search Console precizeaza ca rezultatul implicit al URL Inspection se refera la versiunea din index, nu la o verificare live. Cele doua trebuie comparate atunci cand pagina a fost modificata recent.

Cauta efectiv continutul important

Nu te limita la screenshot. Deschide HTML-ul randat si cauta o fraza unica din continutul principal: numele produsului, un paragraf din articol sau o informatie care ar trebui sa existe pe pagina.

Daca fraza exista in browser, dar nu apare in HTML-ul randat din testul Google, ai restrans semnificativ problema. Investigatia se muta spre JavaScript, resurse, requesturi, conditii de executie si modul in care datele sunt obtinute.

Daca fraza apare in HTML-ul randat, nu mai presupune automat ca JavaScript este cauza neindexarii. Verifica indexability, canonical, duplicarea, raspunsurile HTTP si informatiile raportate de URL Inspection.

JavaScript functioneaza, dar datele din API nu ajung la Google

Aplicatia poate porni corect si totusi continutul sa lipseasca. Un scenariu tipic este acesta:

1. HTML-ul initial contine app shell-ul.
2. JavaScript se executa.
3. Aplicatia solicita datele prin HTTP.
4. Requestul esueaza sau primeste un raspuns diferit.
5. DOM-ul final ramane incomplet.

Google recomanda folosirea URL Inspection sau Rich Results Test pentru investigarea problemelor JavaScript, deoarece instrumentele permit inspectarea DOM-ului randat, a resurselor incarcate si a erorilor JavaScript.

Verifica inclusiv daca fisierele JavaScript sau alte resurse esentiale sunt blocate pentru Googlebot. Daca o pagina sau resursele necesare sunt blocate prin robots.txt, Google poate sa nu poata obtine versiunea randata asteptata.

Linkurile trebuie sa fie linkuri, nu doar elemente care raspund la click

Aplicatiile frontend pot implementa navigarea in multe feluri, dar nu toate variantele sunt la fel de usor de descoperit de crawlere.

Google recomanda linkuri HTML de forma <a href="/produse">. Un element <span> cu un handler JavaScript sau un element <a> fara atribut href nu ofera aceeasi baza robusta pentru descoperirea URL-ului.

Pentru SPA-uri cu routing client-side, Google recomanda folosirea History API si a URL-urilor reale, nu folosirea fragmentelor de forma #/produse pentru incarcarea unor pagini diferite.

Un router poate intercepta click-ul pentru a evita un reload complet, dar destinatia trebuie sa ramana un URL real pe care crawlerul il poate solicita direct.

SPA-ul afiseaza „pagina nu exista”, dar serverul raspunde 200

Aceasta este una dintre problemele clasice ale unei configuratii SPA in care serverul trimite acelasi document pentru aproape orice cale.

Utilizatorul deschide /produs-inexistent. Aplicatia porneste, API-ul spune ca produsul nu exista, iar React sau Vue afiseaza un mesaj 404. Dar raspunsul HTTP initial a fost 200 OK.

Pentru Google, statusurile HTTP au semnificatie. Google recomanda folosirea unor statusuri relevante, precum 404 pentru resurse inexistente. Pentru SPA-urile unde statusul nu poate fi schimbat usor dupa randarea client-side, documentatia Google propune strategii precum redirectarea catre un URL care raspunde efectiv cu 404 sau adaugarea unei directive noindex pe pagina de eroare.

O pagina care pare eroare prin continut, dar raspunde cu 200, poate fi interpretata drept soft 404.

Storage, sesiuni si permisiuni: browserul tau nu este o sesiune Googlebot

O aplicatie poate conditiona continutul de informatii salvate in browser. Aici apar diferente greu de observat in testarea manuala.

Google precizeaza ca Web Rendering Service nu pastreaza starea intre incarcari: datele din Local Storage si Session Storage sunt sterse intre page loads. Prin urmare, continutul public important nu ar trebui sa depinda de presupunerea ca o valoare exista deja in storage.

La fel, functiile care necesita permisiuni ale utilizatorului trebuie gandite cu fallback. Google ofera exemplul API-urilor care necesita acces la camera: crawlerul nu poate fi obligat sa ofere o astfel de permisiune pentru a ajunge la continut.

Daca informatia este publica si destinata cautarii, intreaba-te daca poate fi obtinuta pornind de la o sesiune curata, fara clickuri speciale, permisiuni sau stare salvata anterior.

Continutul exista doar dupa scroll sau click?

Lazy loading poate imbunatati performanta, dar continutul destinat indexarii trebuie sa poata fi incarcat intr-un mod pe care Google il poate procesa.

Google recomanda verificarea implementarii prin URL Inspection si cautarea continutului in HTML-ul randat. Daca o sectiune apare numai dupa o interactiune pe care crawlerul nu o executa in fluxul necesar, nu presupune ca acea sectiune va fi disponibila pentru indexare.

O distinctie utila este intre optimizarea resurselor si ascunderea dependentei de interactiune. Poti amana imagini sau componente necritice, dar continutul principal public nu ar trebui sa depinda inutil de un gest al utilizatorului pentru a deveni accesibil.

CSR, SSR sau prerendering: trebuie rescris tot site-ul?

Nu orice site React sau Vue are nevoie de o migrare completa. Google poate procesa JavaScript si poate indexa continut generat client-side atunci cand implementarea functioneaza corect.

Totusi, documentatia Google spune ca server-side rendering sau prerendering raman abordari bune deoarece fac continutul disponibil mai direct pentru utilizatori si crawlere, iar nu toate boturile executa JavaScript.

Google nu mai recomanda dynamic rendering ca solutie pe termen lung pentru problemele continutului JavaScript. In locul unei versiuni speciale servite crawlerelor, documentatia recomanda abordari precum server-side rendering, static rendering sau hydration atunci cand arhitectura proiectului le permite.

Alegerea trebuie facuta dupa proiect. Un dashboard privat nu are aceleasi cerinte ca un magazin online cu mii de pagini publice de produs. O aplicatie PWA poate avea zone interactive puternic client-side, in timp ce paginile publice importante pentru cautare pot livra continutul esential intr-o forma mai robusta. Pentru o perspectiva mai larga asupra arhitecturii, vezi si ghidul despre PWA sau aplicatie mobila nativa pentru business.

Exemplu practic: pagina de produs pe care utilizatorul o vede, dar Google o randaza incomplet

Presupunem ca avem un magazin construit ca SPA. URL-ul /produse/scaun-ergonomic-x functioneaza impecabil cand este accesat normal.

View Source arata doar structura aplicatiei. Dupa pornire, JavaScript cere produsul prin API si completeaza pagina. Proprietarul observa insa ca Google nu pare sa asocieze URL-ul cu descrierea produsului.

Diagnosticul poate urma aceasta ordine:

1. Inspectezi URL-ul in Search Console.
2. Rulezi testul live.
3. Deschizi HTML-ul randat si cauti o fraza unica din descriere.
4. Fraza lipseste.
5. Verifici resursele si erorile JavaScript.
6. Constati ca requestul pentru date depinde de o valoare salvata anterior in storage.
7. Intr-un browser obisnuit valoarea exista, deci problema nu era vizibila echipei.
8. Modifici fluxul astfel incat datele publice ale produsului sa poata fi obtinute fara acea stare persistenta.
9. Testezi din nou URL-ul si verifici daca produsul apare acum in HTML-ul randat.

Important este modul in care a fost gasita cauza. Nu s-a pornit de la concluzia „Google nu indexeaza React”. S-a comparat ceea ce vede utilizatorul cu ceea ce poate procesa efectiv Google.

Continutul este randat corect? Atunci nu mai da vina automat pe JavaScript

Daca HTML-ul testat de Google contine continutul principal, linkurile sunt crawlable si resursele se incarca, continua diagnosticul.

URL Inspection poate indica daca accesul este permis, daca fetch-ul a reusit si daca indexarea este permisa. Raportul poate oferi si informatii despre canonical-ul selectat de Google pentru versiunea indexata. Un test live valid nu garanteaza indexarea: Google precizeaza explicit ca testul live verifica doar o parte dintre conditiile necesare.

Asadar, diferentiaza doua probleme:

• Google nu poate obtine continutul: investighezi rendering-ul, resursele, API-urile si executia JavaScript.
• Google poate obtine continutul, dar URL-ul nu este indexat cum te astepti: investighezi indexability, canonicalizare, duplicare, descoperire, calitatea si unicitatea continutului si celelalte informatii disponibile in Search Console.

Pentru problemele care depasesc rendering-ul unei singure pagini, ghidul despre SEO tehnic si verificarile necesare inainte si dupa lansare acopera si alte puncte ale infrastructurii de indexare.

Greseli frecvente

• Testezi doar in browserul tau: sesiunea si storage-ul local pot ascunde problema.
• Consideri View Source versiunea finala: pe paginile JavaScript, DOM-ul poate fi modificat substantial dupa executie.
• Presupui ca Google nu executa JavaScript: Google il poate executa, dar implementarea trebuie sa fie accesibila si compatibila.
• Navigarea foloseste doar click handlers: ofera linkuri reale cu elemente anchor si href.
• Routing bazat pe # pentru continut distinct: foloseste URL-uri reale si History API.
• Toate rutele raspund 200: poti produce soft 404 si semnale HTTP incorecte.
• Continutul depinde de stare locala: Google nu trebuie presupus ca are sesiunea unui utilizator recurent.
• Testul live este verde, deci pagina sigur va fi indexata: Google precizeaza ca un rezultat valid nu garanteaza includerea in index.

Checklist: pagina apare in browser, dar nu corect in Google

1. Verifica statusul HTTP al URL-ului solicitat direct.
2. Verifica robots.txt si directivele robots/noindex.
3. Compara HTML-ul initial cu DOM-ul randat in browser.
4. Inspecteaza URL-ul in Google Search Console.
5. Ruleaza Test Live URL pentru versiunea actuala.
6. Deschide HTML-ul randat de Google si cauta textul principal.
7. Compara screenshot-ul Google cu pagina vazuta de un utilizator nou.
8. Verifica resursele care nu s-au incarcat si erorile JavaScript.
9. Testeaza requesturile HTTP/API de care depinde continutul.
10. Verifica daca pagina functioneaza fara date preexistente in Local Storage sau Session Storage.
11. Verifica daca informatia publica depinde de login, permisiuni sau interactiuni inutile.
12. Asigura-te ca navigarea foloseste linkuri <a href> catre URL-uri reale.
13. Testeaza direct fiecare ruta importanta din SPA, nu doar navigarea pornind din homepage.
14. Verifica paginile inexistente si raspunsurile 404/soft 404.
15. Daca HTML-ul randat este corect, continua cu canonicalizarea, duplicarea si celelalte cauze de neindexare.

Daca exista discrepante intre HTML-ul initial, continutul randat si ceea ce ajunge la Google, un audit SEO tehnic si remedierea problemelor de indexare poate urmari problema de la raspunsul serverului pana la rendering, link discovery, canonicalizare si indexability.

Concluzie: verifica ceea ce primeste Google, nu doar ceea ce vezi tu

JavaScript nu este automat incompatibil cu SEO. Problema apare atunci cand continutul public depinde de conditii pe care crawlerul nu le poate reproduce sau cand arhitectura transmite semnale diferite fata de ceea ce utilizatorul vede pe ecran.

Cea mai eficienta metoda de diagnostic este comparatia. Verifica raspunsul serverului, DOM-ul browserului si HTML-ul randat de Google. Apoi urmareste resursele, requesturile, linkurile si statusurile HTTP.

Daca Google vede continutul in HTML-ul randat, cauta mai departe cauza indexarii. Daca nu il vede, repara mai intai traseul prin care continutul ajunge in DOM. Aceasta separare evita multe ore pierdute cu modificari care nu ating problema reala.