Alex Matescu
    Articole

    AI Visibility Lab · Articole

    Paradoxul site-ului terminat: același URL poate arăta diferit pentru om, crawler și instrumentul de audit

    Studiu de caz pe un site React construit cu Lovable: un request generic primește SPA shell-ul, în timp ce documentația Lovable spune că crawlerele verificate primesc HTML pre-randat. Ce demonstrează testul, ce nu demonstrează și cum verifici corect metadata, canonicalizarea și crawlabilitatea.

    · Fondator și coordonator AI Visibility Lab

    Publicat: · Actualizat: · Ultima verificare factuală:

    Un site poate părea complet în browser și, în același timp, poate furniza reprezentări diferite în funcție de agentul care îl accesează. În testul documentat aici, un request HTTP generic către două rute ale propriului meu site a primit același shell HTML: metadate în <head>, fără textul principal pe care îl vede utilizatorul după executarea aplicației în browser. Asta nu demonstrează că ChatGPT, Perplexity, Google sau alte crawlere verificate primesc același răspuns. Documentația Lovable verificată la 10 august 2026 spune explicit că proiectele mai vechi React + Vite folosesc pre-randare la cerere pentru crawlere verificate, în timp ce agenții neverificați și scanerele SEO terțe primesc aplicația SPA obișnuită. Studiul de caz arată, prin urmare, altceva: același URL poate avea mai multe reprezentări tehnice, iar un simplu curl nu trebuie confundat cu ceea ce vede un crawler verificat.1

    Această distincție schimbă teza articolului.

    Problema nu este „un site modern nu există pentru AI”. Problema este că o verificare făcută cu agentul greșit poate descrie o reprezentare diferită de cea servită motorului pe care încerci să-l optimizezi.

    Ce am măsurat

    În august 2026 am făcut o extragere HTTP simplă pe două adrese ale propriului site, folosind un agent generic care nu execută aplicația JavaScript în browser.

    Adresa 1: pagina principală. Răspunsul brut conținea elemente din <head> și shell-ul aplicației, dar nu textul principal vizibil după încărcarea paginii în browser.

    Adresa 2: /lab/articole. Răspunsul brut primit de agentul generic era, în testul efectuat, identic cu cel al paginii principale la nivelul HTML-ului servit înainte de rularea aplicației.

    În răspunsurile testate au apărut și valori precum:

    canonical: /
meta-og:url: /

    Acest rezultat demonstrează trei lucruri precise:

    1. agentul generic testat nu a primit conținutul final pe care îl vede utilizatorul în browser;
    2. cele două rute testate au primit același shell HTML în acel tip de request;
    3. în shell-ul primit, canonicalul și metadatele nu erau specifice rutei interioare.

    Nu demonstrează că toate rutele site-ului au același canonical și nici că Google, ChatGPT, Perplexity, Claude sau Gemini primesc aceeași reprezentare.

    Această limită trebuie păstrată în centrul studiului.

    Descoperirea importantă: nu există o singură versiune a paginii

    La momentul primei măsurători am interpretat shell-ul returnat de curl ca pe ceea ce ar putea primi un crawler AI fără rendering. Documentația Lovable actuală permite o interpretare mai precisă.

    Conform documentației Lovable verificate la 10 august 2026, proiectele Lovable sunt împărțite în două stive tehnice:1

    • aplicațiile noi create după 13 mai 2026 folosesc TanStack Start cu server-side rendering;
    • proiectele mai vechi React + Vite folosesc on-request pre-rendering pe URL-urile publicate;
    • în vechea stivă, pre-randarea este servită crawlerelor verificate, între care Lovable enumeră Google, Bing, boți de preview social și motoare AI precum ChatGPT, Perplexity, Claude și Gemini;
    • scanerele SEO terțe și alți agenți neverificați primesc SPA-ul obișnuit.

    Asta înseamnă că rezultatul generic curl observat în acest studiu este compatibil cu comportamentul documentat al platformei.

    Măsurătoarea nu dovedește invizibilitate pentru AI; dovedește diferențierea răspunsului în funcție de agent.

    Acesta este paradoxul mai interesant: un proprietar poate vedea o pagină completă, un scanner generic poate vedea shell-ul, iar un crawler recunoscut de platformă poate primi HTML pre-randat.

    Canonicalul: problemă reală, dar nu comandă absolută

    Un rel="canonical" indică motorului ce URL preferă publisherul ca reprezentant pentru pagini duplicate sau foarte similare.

    Google descrie rel="canonical" drept un semnal puternic pentru canonicalizare, nu drept o comandă absolută. Google combină această indicație cu alte semnale și poate selecta un alt URL canonical decât cel declarat de publisher.2

    Prin urmare, dacă o pagină interioară distinctă declară homepage-ul drept canonical, formularea corectă nu este:

    „motorul este instruit să nu indexeze pagina.”

    Formularea corectă este:

    pagina transmite un semnal puternic că homepage-ul ar trebui tratat drept URL reprezentativ. Dacă motorul acceptă semnalul, URL-ul interior poate fi consolidat sub canonicalul ales; dacă paginile sunt suficient de diferite sau alte semnale contrazic declarația, motorul poate alege alt canonical.

    Google avertizează explicit împotriva canonicalurilor incorecte între pagini care nu sunt duplicate și recomandă canonicaluri self-referential pentru paginile care trebuie tratate separat.23

    Ce știm din testul meu

    În cele două răspunsuri generice testate, canonicalul era /.

    Ce nu știm doar din acel test

    Nu știm dacă HTML-ul pre-randat servit fiecărui crawler verificat păstra același canonical sau genera unul specific rutei. În aplicațiile JavaScript, canonicalul poate fi stabilit sau modificat de cod, iar Google recomandă ca semnalul să fie cât mai clar și consecvent între HTML-ul inițial și starea randată.4

    De aceea, problema canonicalizării trebuie verificată în reprezentarea relevantă pentru motor, nu dedusă exclusiv din shell-ul primit de un agent generic.

    Pentru Google, verificarea corectă include URL Inspection în Search Console, unde poate fi văzut inclusiv canonicalul selectat de Google.5

    De ce se întâmplă în aplicațiile client-side

    Multe aplicații client-side folosesc un shell HTML comun și construiesc interfața după ce JavaScript rulează în browser. Aceasta este o arhitectură posibilă pentru un SPA, nu definiția tuturor aplicațiilor moderne.

    Într-o astfel de implementare:

    • serverul poate returna un shell comun pentru mai multe rute;
    • routerul din browser decide ce componentă trebuie afișată;
    • JavaScript poate încărca sau construi conținutul;
    • metadata poate rămâne generică dacă aplicația nu o gestionează per rută.

    Aceste probleme nu sunt inevitabile. Framework-urile moderne pot folosi server-side rendering, static generation, streaming sau arhitecturi hibride.

    Prin urmare, riscul nu crește pentru că „stiva este modernă”. Riscul apare atunci când HTML-ul servit înainte de rularea clientului nu conține informația importantă, iar publisherul nu verifică reprezentarea folosită de crawlerele relevante.

    Paradoxul site-ului terminat

    Miezul problemei rămâne util, dar trebuie formulat precis.

    Verificarea vizuală nu verifică reprezentarea crawlerului

    Site-ul poate arăta bine, navigarea poate funcționa și conținutul poate fi complet în browser. Aceste lucruri nu arată ce se află în răspunsul HTML inițial și nici dacă platforma servește altă reprezentare crawlerelor.

    Un audit vizual și un audit al crawlabilității verifică lucruri diferite.

    Faptul că Google poate randa JavaScript nu rezolvă automat tot

    Google Search execută JavaScript și folosește Web Rendering Service. Tot Google documentează însă diferențe și limitări în procesarea aplicațiilor JavaScript și recomandă implementări robuste pentru Search.67

    Așadar, formularea „Googlebot vede întotdeauna site-ul complet” este prea tare.

    Mai corect:

    Google poate executa JavaScript și indexa conținut randat client-side, dar rezultatul trebuie verificat, iar existența JavaScriptului funcțional în browser nu garantează singură indexarea corectă.

    Nu toate crawlerele trebuie presupuse identice

    Nu există o bază solidă pentru afirmația că „majoritatea crawlerelor AI nu execută JavaScript”.

    OpenAI documentează OAI-SearchBot și spune că permiterea accesului ajută conținutul să fie descoperit, afișat și citat în ChatGPT Search, dar documentația publică consultată nu publică un model universal al capabilităților sale de rendering.8

    Perplexity documentează PerplexityBot ca agent folosit pentru descoperirea și indexarea informației pentru search și recomandă permiterea lui în robots.txt, fără să ofere în pagina respectivă o regulă generală despre execuția JavaScript.9

    Prin urmare:

    capabilitățile de rendering și acces diferă între crawlere și nu sunt documentate integral. HTML-ul care conține direct informația esențială rămâne cea mai interoperabilă bază.

    Ce vede fiecare tip de vizitator în cazul Lovable documentat

    Tabelul de mai jos descrie comportamentul documentat de Lovable la 10 august 2026, nu o regulă universală a webului.

    Tip de request Comportament documentat pentru Lovable
    Om, proiect React + Vite vechiPrimește experiența SPA
    Crawler verificat pe proiect React + Vite vechiPrimește HTML pre-randat la cerere
    Scanner SEO / agent neverificat pe proiect React + Vite vechiPrimește SPA-ul obișnuit
    Proiect nou TanStack Start cu SSRRequesturile primesc HTML randat pe server
    GooglebotEste inclus de Lovable între crawlerii pentru care stiva veche oferă pre-randare
    ChatGPT / Perplexity / Claude / GeminiSunt enumerate de Lovable între motoarele AI cărora stiva veche le oferă pre-randare

    Sursa acestui tabel este documentația Lovable, nu o măsurătoare independentă a fiecărui crawler.1

    Această informație este volatilă și trebuie reverificată dacă Lovable își schimbă infrastructura.

    Nuanța onestă despre Lovable

    Studiul nu trebuie prezentat ca acuzație la adresa Lovable.

    Documentația verificată la 10 august 2026 spune că:1

    • aplicațiile noi create după 13 mai 2026 folosesc TanStack Start cu SSR;
    • proiectele mai vechi React + Vite primesc pre-randare automat pentru crawlere verificate;
    • proiectele React + Vite existente pot fi upgradate la TanStack Start;
    • Lovable are o funcție de SEO & AI search review;
    • pentru site-urile publicate există inclusiv un check pozitiv „AI assistants can see your site as Markdown”;
    • review-ul poate semnala probleme precum duplicate titles, canonicaluri către homepage, robots.txt, sitemap și metadata.

    Asta corectează una dintre afirmațiile inițiale ale articolului: nu mai este adevărat, în starea documentată la 10 august 2026, că „niciun instrument obișnuit nu semnalează problema”. Lovable oferă explicit un audit destinat acestor situații.

    O limită importantă

    Un curl generic nu reproduce automat răspunsul servit unui crawler pe care Lovable îl consideră verificat.

    Documentația publică consultată spune că există crawlerii „verified”, dar pasajul folosit în acest articol nu este suficient pentru a afirma metoda tehnică exactă prin care Lovable îi verifică. De aceea, afirmațiile anterioare despre verificare prin „IP și reverse DNS” au fost eliminate.

    Cum verifici fără să tragi concluzia greșită

    Comenzile curl rămân utile, dar răspund unei întrebări precise:

    Ce HTML primește acest request?

    Nu răspund automat la:

    Ce HTML primește Googlebot sau ChatGPT?

    1. Verifică răspunsul generic

    curl -s https://site-ul-tau.ro > /tmp/home.html
curl -s https://site-ul-tau.ro/o-alta-pagina > /tmp/page.html

    2. Compară shell-urile

    diff /tmp/home.html /tmp/page.html

    Dacă sunt identice, concluzia corectă este:

    cele două requesturi generice au primit același HTML; este posibil să existe un SPA shell sau un fallback comun și trebuie verificată arhitectura.

    Nu înseamnă automat că toate crawlerele primesc același răspuns.

    3. Verifică canonicalul din răspunsul primit

    curl -s https://site-ul-tau.ro/o-alta-pagina | grep -i canonical

    Asta îți spune ce canonical există în acea reprezentare.

    4. Caută textul paginii în HTML

    curl -s https://site-ul-tau.ro/o-alta-pagina | grep -F "un text distinct din pagină"

    Dacă textul nu apare, concluzia este:

    textul nu există în HTML-ul primit de requestul respectiv.

    Nu:

    „textul nu există pentru AI”.

    5. Verifică Google separat

    Folosește URL Inspection în Google Search Console pentru:

    • crawl/index status;
    • Google-selected canonical;
    • informațiile pe care Google le are despre URL.5

    6. Pentru Lovable, folosește și review-ul propriu al platformei

    Documentația curentă indică More → SEO & AI search și review-ul pentru crawlability, metadata, canonical, indexing și AI Markdown rendering.1

    Un test corect combină deci raw HTTP, instrumentul motorului și auditul platformei.

    Ce se rezolvă, în ce ordine

    Ordinea revizuită este:

    1. Măsoară outputul real pe rutele importante.
    Nu presupune problema înainte de test.

    2. Verifică canonicalurile.
    Fiecare pagină distinctă care trebuie indexată separat ar trebui, în mod normal, să aibă un canonical coerent cu URL-ul preferat al acelei pagini. Google recomandă self-referential canonical pentru URL-ul canonical.2

    3. Asigură metadata distinctă per rută.
    Titlurile, descrierile și Open Graph metadata trebuie să descrie pagina respectivă. Lovable recomandă explicit metadata unică per rută pentru social previews și auditul SEO/AEO.1

    4. Asigură o reprezentare crawlabilă a conținutului.
    SSR, static generation sau pre-randarea corectă reduc dependența de execuția client-side. Pentru proiectele Lovable vechi, platforma declară că oferă deja pre-randare crawlerelor verificate; upgrade-ul la TanStack Start oferă SSR complet.1

    5. Verifică motorul concret.
    Pentru Google: Search Console. Pentru ChatGPT: nu bloca OAI-SearchBot dacă dorești includerea în search summaries/snippets.8 Pentru Perplexity: permite PerplexityBot dacă dorești apariția în search.9

    6. Repetă testele după publicare.
    Reparația nu se presupune din cod; se verifică în răspunsul public și în instrumentele relevante.

    De ce am publicat propriul diagnostic

    Valoarea studiului nu este că „am demonstrat că site-ul meu era invizibil pentru AI”.

    Nu am demonstrat asta.

    Am demonstrat că un agent generic primea o reprezentare foarte săracă față de browser, iar documentația platformei explică astăzi de ce: pe vechea stivă Lovable, răspunsul poate fi diferențiat între agentul neverificat și crawlerul verificat.

    Publicarea diagnosticului rămâne utilă tocmai pentru că arată cum o concluzie tehnică se poate schimba după verificarea infrastructurii.

    Prima ipoteză a fost:

    „crawlerul vede shell-ul, deci AI-ul vede shell-ul.”

    După verificarea documentației, concluzia devine:

    „crawlerul generic vede shell-ul; nu pot extrapola acel rezultat către un crawler verificat fără să verific reprezentarea servită acelui crawler.”

    Aceasta este o corecție importantă și face studiul mai valoros ca demonstrație de metodă.

    În vizibilitatea AI, scopul nu este să confirmi ipoteza inițială, ci să separi ceea ce ai măsurat de ceea ce ai presupus.

    Întrebări frecvente

    De ce curl nu vede același lucru ca browserul pe unele aplicații React?

    Pentru că o aplicație client-side poate returna un shell HTML și poate construi conținutul după executarea JavaScript. În plus, unele platforme pot servi reprezentări diferite unor categorii diferite de agenți.

    Dacă curl nu vede textul, înseamnă că ChatGPT nu îl vede?

    Nu. curl arată răspunsul primit de requestul respectiv. În cazul proiectelor Lovable React + Vite vechi, documentația Lovable spune că agenții neverificați primesc SPA-ul obișnuit, iar crawlerii AI verificați precum ChatGPT și Perplexity primesc HTML pre-randat.1

    Dacă Google îmi indexează site-ul, înseamnă că totul este corect?

    Nu. Google poate executa JavaScript, dar canonicalizarea, metadata, structura și alte probleme pot exista independent. URL Inspection poate fi folosit pentru a verifica inclusiv canonicalul selectat de Google.65

    Ce înseamnă dacă o pagină interioară are canonical către homepage?

    Înseamnă că pagina trimite un semnal puternic că homepage-ul este URL-ul preferat pentru canonicalizare. Google poate accepta sau poate ignora acel semnal în funcție de celelalte indicii. Pentru pagini distincte care trebuie indexate separat, canonicalul către homepage este de regulă o configurație greșită.2

    Site-urile făcute cu Lovable sunt invizibile pentru AI?

    Nu. Documentația Lovable verificată la 10 august 2026 spune că noile aplicații TanStack Start folosesc SSR, iar aplicațiile React + Vite mai vechi folosesc pre-randare pentru crawlere verificate, inclusiv ChatGPT, Perplexity, Claude și Gemini.1

    Proiectele Lovable React + Vite vechi pot fi migrate la SSR?

    Da, conform documentației Lovable verificate la 10 august 2026, proiectele existente pot fi upgradate la TanStack Start. Această capabilitate este specifică produsului și trebuie reverificată dacă documentația se schimbă.1

    Site-urile moderne au un risc mai mare de invizibilitate AI?

    Nu există bază pentru această regulă. Multe framework-uri moderne folosesc SSR sau static generation. Riscul relevant este ca informația esențială să nu fie disponibilă în reprezentarea pe care o primește crawlerul relevant.

    Cum verific corect un site?

    Combină răspunsul HTTP brut cu instrumentele specifice motorului și platformei. curl verifică raw HTML; Search Console verifică perspectiva Google; iar Lovable oferă propriul SEO & AI search review pentru proiectele sale.

    Metodologie și limite

    Măsurătoarea proprie

    Testul inițial a fost efectuat în august 2026 pe două rute ale delamatescu.ro, folosind un request generic care nu a executat aplicația în browser.

    Rezultatul susține doar afirmațiile despre HTML-ul primit de acel request.

    Nu este folosit în această versiune pentru a deduce direct ce primește un crawler AI verificat.

    Verificarea externă

    Pentru revizia din 10 august 2026 au fost folosite cu prioritate surse primare:

    • documentația Lovable pentru stivele React + Vite și TanStack Start;
    • Google Search Central pentru canonicalizare, JavaScript și URL Inspection;
    • documentația OpenAI pentru OAI-SearchBot;
    • documentația Perplexity pentru PerplexityBot.

    Afirmațiile despre comportamentul Lovable, OpenAI și Perplexity sunt volatile și descriu starea documentației la data verificării. Ele trebuie reverificate periodic.

    Nivelurile de certitudine

    În articol sunt separate explicit:

    • observația măsurată — ce a returnat requestul generic;
    • comportamentul documentat de platformă — ce declară Lovable că servește diferitelor categorii de agenți;
    • comportamentul documentat de motor — de exemplu, Google JavaScript rendering sau accesul OAI-SearchBot;
    • interpretarea AI Visibility Lab — concluzii de metodă care nu sunt prezentate ca mecanisme algoritmice.

    Surse

    1. Lovable Documentation — „Optimize your app for SEO and AI search", verificat 10 august 2026. Documentația precizează că aplicațiile noi create după 13 mai 2026 folosesc TanStack Start cu SSR; proiectele React + Vite mai vechi folosesc on-request pre-rendering pentru crawlerii verificați; agenții neverificați primesc SPA-ul normal; proiectele vechi pot fi upgradate la TanStack Start; iar SEO & AI search review verifică inclusiv canonicaluri, metadata și AI Markdown rendering: docs.lovable.dev/features/seo-aeo
    2. Google Search Central — „How to specify a canonical URL with rel="canonical" and other methods". Google descrie rel="canonical" ca semnal puternic și recomandă canonical self-referential pentru URL-ul canonical: developers.google.com/…/consolidate-duplicate-urls
    3. Google Search Central — „5 common mistakes with rel=canonical". Documentează riscurile canonicalizării unor pagini distincte către o singură pagină și faptul că motoarele pot ignora un canonical nepotrivit: developers.google.com/…/5-common-mistakes-with-relcanonical
    4. Google Search Central — „Understand JavaScript SEO Basics". Google documentează folosirea JavaScript pentru title, meta description și canonical și recomandă consistență între HTML și modificările JavaScript: developers.google.com/…/javascript-seo-basics
    5. Google Search Central — documentația URL Inspection / Google-selected canonical. Instrumentul oferă informații de crawl, indexare și canonical pentru URL-urile inspectate: developers.google.com/…/how-to-discover-suggest-google-selected
    6. Google Search Central — „Understand JavaScript SEO Basics". Google Search procesează JavaScript în etapa de rendering: developers.google.com/…/javascript-seo-basics
    7. Google Search Central — „Fix Search-related JavaScript problems". Google confirmă că rulează JavaScript, dar documentează diferențe și limitări care trebuie luate în calcul: developers.google.com/…/fix-search-javascript
    8. OpenAI Help Center — „Publishers and Developers - FAQ", verificat în august 2026. Orice site public poate apărea în ChatGPT Search; pentru includerea conținutului în summaries/snippets, publisherii nu trebuie să blocheze OAI-SearchBot: help.openai.com/…/publishers-and-developers-faq
    9. Perplexity Documentation — „Perplexity Crawlers", verificat în august 2026. PerplexityBot este folosit pentru descoperirea și indexarea informațiilor pentru rezultatele Perplexity: docs.perplexity.ai/docs/resources/perplexity-crawlers

    Notă de volatilitate

    Infrastructura Lovable și politicile crawlerelor AI se pot schimba rapid. Afirmațiile despre stiva implicită, pre-randare, upgrade-ul TanStack Start, lista crawlerelor verificate, OAI-SearchBot și PerplexityBot descriu starea documentată la 10 august 2026.

    Dacă acest articol este actualizat ulterior, aceste afirmații trebuie reverificate din sursele primare înainte de republicare.

    Articol publicat de AI Visibility Lab, proiect independent de cercetare aplicată și documentare în AI Visibility, GEO și AEO, fondat și coordonat de Alex Matescu. Ultima verificare factuală și a surselor: 10 august 2026.