SEO technical în 2026: schema markup, Core Web Vitals și AI search

01Schema.org modern: ce tipuri contează cu adevărat în 2026

Schema.org a devenit limba de bază prin care Google și LLM-urile înțeleg conținutul unei pagini. Nu mai este suficient să declari Organization și Article. În 2026, paginile competitive folosesc grafuri JSON-LD complete care leagă mai multe entități: Organization, WebSite, WebPage, BreadcrumbList, Product, Service, FAQPage, HowTo, Person și Event. Aceste entități nu trăiesc separat, ci se referențiază reciproc prin id-uri canonice, formând un graf semantic real.

Greșeala clasică este să adaugi schema generată automat de plugin, fără validare. Audit-urile tehnice arată că peste 60% din site-urile românești au schema duplicat, fără id-uri, sau cu câmpuri obligatorii lipsă. Rezultatul: Google ignoră complet markup-ul. Soluția corectă este un singur graf JSON-LD pe pagină, validat în Rich Results Test și în Schema Markup Validator, cu @id-uri stabile și relații semantice clare între entități.

Pentru ecommerce, Product cu offers, aggregateRating și review este esențial. Pentru servicii, Service legat de Organization și AreaServed. Pentru articole, Article cu author tip Person care are sameAs către LinkedIn și ORCID. Aceste detalii decid dacă pagina ta apare în AI Overviews ca sursă citată sau dispare în zgomot.

• →Folosește un singur graf JSON-LD pe pagină, nu fragmente multiple care se contrazic
• →Adaugă @id-uri canonice pentru fiecare entitate și leagă-le explicit
• →Validează lunar cu Rich Results Test și Schema Markup Validator
• →Pentru produse, completează GTIN, brand, availability, price și priceCurrency
• →Pentru autori, leagă Person prin sameAs către profile externe verificabile

02Core Web Vitals în 2026: INP a schimbat regulile

Din martie 2024, INP a înlocuit FID ca metrică oficială de interactivitate, iar în 2026 a devenit cel mai dur indicator. INP măsoară latența celei mai slabe interacțiuni de pe pagină, nu doar prima. Asta înseamnă că un site care lasă impresia de rapiditate la primul click poate eșua dacă orice meniu, filtru sau formular răspunde lent ulterior. Pragul bun este sub 200ms, iar 500ms este eșec.

LCP rămâne critic și ar trebui să fie sub 2.5 secunde pe mobil 4G simulat. CLS sub 0.1 înseamnă layout stabil. Toate trei se măsoară pe field data prin Chrome User Experience Report, nu pe lab data din Lighthouse. Diferența contează: scorul de 100 din Lighthouse nu garantează nimic dacă utilizatorii reali au INP de 600ms din cauza unui handler JavaScript prost scris.

Pentru a câștiga INP, lucrurile concrete sunt: împărțirea task-urilor lungi cu scheduler.yield, eliminarea sincronului din event handlers, debouncing pentru filtre, virtualizare pentru liste, și un audit serios al third-party scripts. Tag Manager-ul plin de pixeli vechi este principala cauză de INP slab pe site-urile românești.

03AI Overviews și pregătirea pentru AEO

AI Overviews au devenit standard în SERP-urile Google pentru interogări informaționale. În loc de 10 link-uri albastre, utilizatorul primește un rezumat generat care citează 3-5 surse. Studiile din 2025 arată că paginile citate în AI Overviews primesc între 1.5x și 3x mai mult trafic relevant decât cele aflate organic în top 3, pentru că vizitatorul vine deja pre-calificat și încrezător în sursă.

AEO, Answer Engine Optimization, este disciplina nouă care înlocuiește parțial SEO-ul informațional. Principiul: scrii pentru a fi citat, nu doar pentru a fi listat. Asta înseamnă paragrafe scurte cu definiții directe, liste numerotate cu pași clari, tabele comparative, și markup HowTo sau FAQPage acolo unde se potrivește. Întrebările explicite, urmate de răspunsuri concise în primul paragraf, sunt formatul preferat de modelele de extragere.

În plus, autoritatea de domeniu și menționările în surse de încredere influențează direct citarea în AI Overviews. Modelele preferă domenii cu istoric jurnalistic, citări academice, sau profil clar de expert. Pentru un site B2B, asta înseamnă presa de specialitate, podcasturi, studii citate, și un profil al autorului bine documentat extern.

• →Scrie prima propoziție din fiecare secțiune ca un răspuns autonom, citabil
• →Folosește H2 și H3 ca întrebări reale, nu ca slogane de marketing
• →Adaugă FAQPage schema doar acolo unde întrebările sunt autentice
• →Construiește profil de autor cu sameAs către surse externe verificabile
• →Monitorizează citările prin instrumente ca Ahrefs Brand Radar sau Otterly

04Arhitectura de indexare: sitemap, canonical, robots

Multe site-uri pierd 30-50% din potențialul organic din probleme banale de indexare. Sitemap-uri vechi, canonical inconsistent, robots.txt prea permisiv sau prea restrictiv, paginare fără rel prev/next coerent. Google a abandonat oficial rel prev/next ca semnal, dar arhitectura paginării influențează direct cum descoperă spider-ul conținutul nou.

În 2026, un sitemap XML bun este împărțit pe tipuri de conținut, are sub 50.000 URL-uri per fișier, include lastmod corect actualizat, și este referit explicit în robots.txt. Sitemap-urile care raportează lastmod-uri identice pentru toate URL-urile sunt ignorate. Google folosește lastmod ca semnal de prioritate pentru recrawl, iar abuzul anulează semnalul complet.

Canonical-urile trebuie să fie auto-referențiate pe paginile principale, să indice către versiunea curată fără parametri pe paginile filtrate, și să nu intre niciodată în conflict cu hreflang. Pentru site-urile multilingve, x-default și hreflang reciproc între toate variantele sunt obligatorii. O singură eroare de hreflang poate scoate jumătate din site din indexul corect.

05Render, JavaScript și crawl budget

Googlebot rulează Chrome Headless modern, dar render-ul JavaScript rămâne mai lent decât HTML pur. Pentru site-urile mari, crawl budget-ul se consumă rapid când fiecare pagină are nevoie de execuție JS pentru conținut. Server-side rendering, static generation sau incremental static regeneration sunt soluțiile moderne pentru a livra HTML complet de la prima cerere.

În proiectele Blackbone, recomandarea standard pentru ecommerce mare și site-uri editoriale este Next.js cu ISR sau Astro pentru conținut majoritar static. SPA-urile pure rămân o opțiune doar pentru aplicații închise, autentificate, unde SEO nu contează. Pentru orice pagină publică, HTML livrat de server este regula. Hidratarea selectivă, prin React Server Components sau Astro islands, păstrează interactivitatea fără să tortureze crawler-ul.

Crawl budget-ul se optimizează și prin eliminarea paginilor cu valoare zero. Paginile de tag goale, filtrele combinate care generează milioane de URL-uri, search-urile interne expuse, calendarele infinite, toate consumă crawl și diluează autoritatea. Robots.txt și noindex strategic, plus o ierarhie clară, redirecționează atenția Google către paginile care contează.

06Monitorizare continuă și auditele Blackbone

SEO tehnic nu se face o singură dată. Un site mare schimbă sute de pagini pe lună, iar regresiile apar tăcut: un dezvoltator schimbă un canonical, un plugin adaugă schema duplicat, o migrare strică redirect-urile. Monitorizarea continuă prin Search Console, Ahrefs, Sitebulb și logfile analysis este standardul modern.

Logfile analysis rămâne instrumentul cel mai subutilizat. Logurile serverului arată exact ce face Googlebot pe site: ce pagini vizitează, cât de des, ce coduri primește, unde se blochează. Aceste date sunt mult mai concrete decât rapoartele Search Console și dezvăluie probleme invizibile altfel: cicluri de redirecturi, paginile orfane indexate, sau zone unde crawl-ul este complet absent.

În metodologia firma de IT Blackbone, fiecare audit începe cu un crawl complet, urmat de logfile analysis pe minim 30 de zile, validarea schema pe sample reprezentativ, măsurarea Core Web Vitals pe field data, și un raport prioritizat după impact estimat. Nu livrăm liste de 300 de probleme generice, ci 15-20 de intervenții care produc rezultat măsurabil în 90 de zile.