Linkurile JavaScript ascund paginile de crawlerele AI? Ce arată experimentul de 41 de zile

Dacă un link important apare numai după executarea JavaScript, unele crawlere AI pot să nu descopere deloc pagina din spatele lui. Un experiment urmărit timp de 41 de zile a observat 27 de crawlere și a constatat că, în condițiile testului, numai Googlebot și GoogleOther au trecut de linkurile injectate cu JavaScript. GPTBot, OAI-SearchBot, ClaudeBot și alte crawlere au rămas la nivelul accesibil prin HTML.

Concluzia nu este că „JavaScript omoară SEO” și nici că toate sistemele AI se comportă mereu identic. Este mai precisă: navigația critică nu ar trebui să depindă exclusiv de execuția client-side. Un element <a href="..."> prezent în răspunsul HTML este o cale mai robustă pentru motoare de căutare, crawlere AI, tehnologii asistive și situații în care scripturile eșuează.

Ce a testat experimentul

Experimentul lui Vinicius Stanula a împărțit o arhitectură ierarhică în două grupuri. În grupul de control, paginile copil erau legate prin linkuri HTML normale, vizibile în sursa inițială. În grupul tratat, legăturile către nivelurile inferioare erau injectate prin JavaScript și apăreau numai după executarea scriptului.

Paginile de la nivelul superior erau accesibile tuturor boților prin linkuri HTML. Testul nu întreba dacă un crawler poate ajunge pe site, ci dacă poate trece de următorul pas atunci când traseul există numai în DOM-ul construit în browser.

Sinteza tehnică publicată de Buffy descrie 41 de zile și 30.180 de cereri provenite de la 27 de crawlere. Primele 28 de zile au păstrat separarea HTML versus JavaScript, iar următoarele 13 au urmărit recuperarea după transformarea legăturilor în HTML normal.

Rezultatele raportate

Crawler sau grup	Linkuri JavaScript în test	Ce putem spune
Googlebot și GoogleOther	au trecut de ele, cu pierdere de acoperire în profunzime	Google poate randa JavaScript, dar descoperirea nu a egalat grupul HTML.
GPTBot	zero pagini disponibile numai prin legături JS	Buffy raportează 3.809 cereri fără descoperirea paginilor ascunse astfel.
OAI-SearchBot	s-a oprit la nivelul superior în relatarea autorului	Trebuie separat de GPTBot, deoarece are alt scop.
ClaudeBot	zero pagini din traseul exclusiv JS	Rezultat observat în acest experiment, nu regulă garantată.
PerplexityBot și Bingbot	nu au trecut de legăturile exclusiv JS în sinteza publicată	Un index intermediar poate avea propriile limite de descoperire.

Pe partea HTML, Buffy raportează că Google a parcurs toate cele 759 de pagini urmărite la fiecare nivel. Pe partea JavaScript, acoperirea a scăzut la 67% la primul nivel inferior, 56% la următorul și 42% la nivelul cel mai adânc. Valorile descriu site-ul testat; nu sunt praguri pe care să le aplicăm altui proiect.

După înlocuirea linkurilor JavaScript cu linkuri HTML, GPTBot ar fi descoperit 250 de pagini noi, primele în 48 de ore, iar Bingbot 89. Schimbarea nu a fost în conținutul paginilor, ci în calea prin care puteau fi găsite.

Descoperirea linkului nu este același lucru cu randarea paginii

Două probleme sunt amestecate frecvent. Prima este link discovery: poate crawlerul vedea URL-ul și îl poate adăuga în coada de crawl? A doua este randarea: după ce cere URL-ul, poate executa scripturile necesare pentru a vedea conținutul?

O pagină poate avea conținut HTML complet, dar poate rămâne greu de găsit dacă singura legătură către ea este creată printr-un eveniment JavaScript. Invers, URL-ul poate fi descoperit din sitemap sau dintr-un link extern, dar răspunsul serverului poate conține doar un container gol, iar conținutul util să apară după un request client-side.

Auditul trebuie să testeze ambele straturi. A vedea pagina în Chrome nu demonstrează ce a primit crawlerul în răspunsul inițial. A găsi URL-ul într-un sitemap nu demonstrează că arhitectura internă îi comunică importanța și relația cu alte pagini.

GPTBot, OAI-SearchBot și ChatGPT-User nu sunt același bot

Documentația OpenAI separă explicit trei roluri. OAI-SearchBot este folosit pentru ca website-urile să poată apărea în funcțiile Search. GPTBot se referă la accesul pentru conținut care poate fi folosit la îmbunătățirea modelelor generative. ChatGPT-User poate vizita o pagină ca urmare a unei acțiuni inițiate de utilizator.

Blocarea GPTBot nu este echivalentă cu blocarea OAI-SearchBot. La fel, observarea ChatGPT-User în loguri nu dovedește că site-ul a fost indexat pentru Search. O regulă robots.txt trebuie scrisă pentru scopul dorit, iar logurile trebuie analizate pe user-agentul relevant.

Experimentul devine mai util când păstrăm această separare. Faptul că mai multe crawlere OpenAI nu au urmat linkurile JS în condițiile testului nu le transformă într-un singur sistem și nu spune că vor folosi ulterior conținutul în același mod.

ClaudeBot, Googlebot și ceilalți au contracte diferite

Numele „crawler AI” acoperă boți de training, boți de search, fetchere inițiate de utilizator și crawlere ale unor indexuri folosite indirect de asistenți. Fiecare furnizor poate schimba infrastructura, documentația și comportamentul. De aceea, o listă statică de user-agents nu este suficientă pentru o strategie pe termen lung.

Googlebot are o infrastructură de randare JavaScript bine documentată, dar chiar Google recomandă server-side rendering, static rendering sau hydration. Randarea consumă resurse, poate apărea separat de crawl și poate eșua dacă API-urile, scripturile ori permisiunile nu funcționează pentru bot.

Un control robust folosește documentația oficială actuală, verifică regulile din robots.txt, inspectează răspunsul serverului și validează identitatea crawlerelor atunci când analiza logurilor produce decizii de securitate.

Cum arată un link crawlable

Pentru Google, forma sigură este un element <a> cu un atribut href care poate fi rezolvat. Un buton cu onclick, un div care schimbă ruta sau o adresă păstrată numai într-un atribut custom nu oferă același contract.

<a href="/servicii/audit-seo/">Audit SEO</a>

Frameworkurile moderne pot produce exact acest HTML. React, Vue, Angular, Next.js sau Nuxt nu sunt problema prin ele însele. Problema apare când arhitectura livrată depinde de un browser complet pentru a construi orice cale către conținutul important.

Un router client-side poate intercepta clickul pentru o tranziție rapidă, păstrând totuși un href real. Progressive enhancement permite experienței interactive să funcționeze fără să elimine fallback-ul semantic.

SSR, SSG, hydration și CSR

Model	Ce primește clientul inițial	Risc pentru descoperire
SSR	HTML generat pe server pentru cererea curentă	redus dacă linkurile și conținutul esențial sunt prezente
SSG	HTML generat anterior și servit ca fișier	redus pentru paginile incluse corect în build
Hydration	HTML util peste care JavaScript adaugă interactivitate	redus dacă markupul inițial rămâne complet
CSR exclusiv	container și scripturi care construiesc pagina în browser	mai ridicat pentru boții care nu execută fluxul

Alegerea nu trebuie făcută după o etichetă la modă. Un dashboard autentificat poate funcționa excelent client-side și nu are nevoie de indexare. O pagină publică de serviciu, categorie sau documentație are alte cerințe: descoperire, partajare, accesibilitate, performanță și reziliență.

Unde apar frecvent linkuri ascunse de JavaScript

• meniuri mobile construite integral după pornirea aplicației;
• paginare și „load more” fără URL-uri accesibile prin linkuri;
• filtre de categorie care folosesc numai stare internă;
• carusele cu destinații create după interacțiune;
• liste de articole sau produse încărcate exclusiv prin API;
• componente „related content” injectate după consent sau tracking;
• mega-meniuri alimentate de un endpoint care eșuează pentru boți;
• aplicații în care toate rutele sunt butoane fără href.

Nu toate aceste implementări sunt greșite. Devin risc atunci când constituie singura cale internă spre pagini pe care vrem să le găsească un motor. Sitemapul este util, dar nu înlocuiește complet arhitectura navigabilă și relațiile contextuale dintre documente.

Audit de crawlabilitate AI

1. Alege paginile critice. Servicii, categorii, produse, studii de caz și documentație care trebuie descoperite.
2. Descarcă răspunsul brut. Folosește curl -L URL și salvează HTML-ul înainte de executarea JavaScript.
3. Caută linkurile. Verifică dacă destinațiile apar în atribute href, nu doar în bundle sau date JSON.
4. Compară cu DOM-ul randat. Notează ce conținut și ce linkuri apar numai după pornirea aplicației.
5. Testează fără JavaScript. Confirmă că navigația critică și mesajul principal rămân utilizabile.
6. Verifică statusul și redirecturile. Fiecare destinație trebuie să ajungă previzibil la un URL canonic HTTP 200.
7. Controlează robots și CDN. Permisiunea din fișier nu ajută dacă firewallul livrează challenge, 403 sau HTML diferit.
8. Inspectează logurile. Verifică dacă boții cer nivelurile profunde, cu validarea identității unde este necesară.
9. Testează profunzimea. Nu te opri la homepage; urmărește câte clickuri HTML sunt necesare pentru pagina importantă.
10. Remediază și recitește brut. O modificare nu este confirmată până când linkul apare în răspunsul serverului.

Ghidul existent Site-ul tău arată bine. Dar îl pot citi Google, ChatGPT și agenții AI? extinde auditul către canonical, firewall, parametri, conținut și diferențele de user-agent. Aici păstrăm accentul pe concluzia experimentului: traseul intern trebuie verificat în HTML.

Cum remediem fără să reconstruim inutil aplicația

Prima soluție nu este migrarea completă. Uneori este suficient ca meniul, paginarea și blocurile de recomandări să emită linkuri reale. În alte cazuri, frameworkul oferă SSR sau pre-rendering pentru rutele publice, păstrând interactivitatea client-side după încărcare.

Pentru cataloage mari, o strategie hibridă poate genera static paginile stabile și poate randa pe server paginile dinamice. Zonele autentificate rămân aplicații, iar conținutul public primește HTML complet. Alegerea trebuie făcută după cerințe, volum, frecvența actualizărilor și cost operațional.

Când problema ține de arhitectură, nu doar de conținut, intră în zona de dezvoltare software pentru IMM-uri. Un audit bun produce o listă de URL-uri afectate și un test de acceptanță, nu recomandarea vagă „faceți SSR”.

Ce ar putea adăuga AYSA în roadmap

Pentru AYSA, un modul util ar compara automat răspunsul HTML brut cu DOM-ul randat și ar marca linkurile ori conținutul critic disponibile numai după JavaScript. Rezultatul ar fi o listă de riscuri prioritizate după importanța URL-ului și profunzimea în arhitectură.

Aceasta este o propunere editorială de roadmap, nu o capabilitate pe care o declarăm disponibilă. Orice implementare ar trebui să distingă între simpla diferență de DOM și o problemă reală, să păstreze dovezile și să ceară aprobare înaintea modificării website-ului.

Întrebări frecvente

Crawlerele AI execută JavaScript?

Comportamentul diferă. În experimentul analizat, crawlerele AI observate nu au descoperit paginile accesibile numai prin linkuri JavaScript. Nu generalizăm rezultatul la orice produs și orice moment.

Googlebot urmează linkurile injectate prin JavaScript?

Google poate randa JavaScript și a urmat astfel de linkuri în test, dar acoperirea raportată a scăzut cu profunzimea. HTML-ul server-rendered rămâne calea mai robustă.

Este suficient să includ paginile în sitemap?

Sitemapul ajută la descoperire, dar nu înlocuiește legăturile interne și contextul arhitectural. O pagină importantă ar trebui să aibă și o cale HTML normală de la alte pagini relevante.

Trebuie să renunț la React sau Vue?

Nu. Frameworkurile pot genera SSR, SSG sau HTML hidratabil și pot păstra linkuri semantice. Problema este dependența exclusivă de execuția client-side pentru informația publică esențială.

Cum verific rapid un link?

Descarcă răspunsul cu curl -L sau folosește View Source, apoi caută URL-ul destinației. Inspectorul Elements arată DOM-ul după execuție și nu este suficient singur.

GPTBot și OAI-SearchBot sunt același lucru?

Nu. OpenAI le documentează separat: GPTBot este asociat accesului pentru îmbunătățirea modelelor, iar OAI-SearchBot apariției în funcțiile Search.

Un user-agent din log dovedește identitatea botului?

Nu întotdeauna. User-agentul poate fi imitat. Pentru decizii de securitate sau acces trebuie folosită metoda de verificare recomandată de furnizor, acolo unde există.

Concluzie

Experimentul de 41 de zile transformă o recomandare veche într-un test foarte concret: verifică dacă paginile importante au o cale formată din linkuri HTML reale. În site-ul observat, diferența dintre linkul din sursă și linkul apărut după JavaScript a fost diferența dintre descoperire și absență pentru numeroase crawlere.

Nu trebuie să reconstruim orice aplicație și nu trebuie să tratăm un singur experiment drept lege. Trebuie să verificăm propriul site, răspunsul brut, nivelurile profunde și logurile. Dacă vrei o analiză tehnică aplicată, cere un audit de crawlabilitate și arhitectură. Pentru automatizare cu context și aprobare, descoperă AYSA.

Surse verificate

• Vinicius Stanula — experimentul public despre linkuri JavaScript
• Buffy — sinteza experimentului de 41 de zile și 27 de crawlere
• OpenAI — documentația oficială pentru crawlere
• Google Search Central — JavaScript SEO basics
• Google Search Central — linkuri crawlable

Sursele și documentația au fost verificate la 20 august 2026. Rezultatele experimentului sunt atribuite autorilor și sunt prezentate ca observații direcționale de pe un singur site.