Checklist de SEO tehnic pentru site-uri de produs

De ce contează SEO tehnic pentru companiile de produs?

Acest articol face parte din ghidul de SEO și strategie de conținut. Începe de acolo pentru imaginea de ansamblu.

Google raportează că 53% dintre utilizatorii de mobil părăsesc site-urile care se încarcă în mai mult de trei secunde (Google/SOASTA Research, 2017). SEO tehnic este fundația care determină dacă cineva îți găsește vreodată conținutul. Echipele de produs uită asta constant.

Iată ce văd că se întâmplă. O companie de produs petrece șase luni construind un site de marketing frumos. Copywriting-ul e bun. Designul e rafinat. Publică zece articole, așteaptă trafic și nu se întâmplă nimic. Fișierul robots.txt copiat din staging blochează jumătate din site. Imaginile au 4MB în format PNG. Nu au niciun sitemap.

Echipele de produs gândesc în funcționalități și sprinturi. SEO tehnic nu se potrivește într-un Jira board, așa că e deprioritizat. Dar e stratul de infrastructură de care depind toate celelalte. Poți scrie cel mai bun articol din industria ta. Dacă Google nu-l poate accesa, indexa și servi rapid, articolul ăla nu există.

Am urmărit acest tipar repetându-se în zeci de proiecte. Companiile care își rezolvă SEO tehnic mai întâi văd rezultate din conținut în câteva luni. Cele care sar peste asta se întreabă de ce blogul lor primește douăsprezece vizite pe săptămână.

Nu e complicat. E doar ușor de ignorat.

Ce sunt Core Web Vitals și de ce ar trebui să te intereseze?

Conform documentației Google despre experiența paginii, paginile care ating toate cele trei praguri Core Web Vitals primesc un semnal de clasament îmbunătățit în rezultatele căutării. Aceste trei metrici măsoară viteza, reactivitatea și stabilitatea vizuală. Majoritatea site-urilor de produs eșuează la cel puțin una dintre ele.

LCP: Largest Contentful Paint

LCP măsoară cât durează până când cel mai mare element vizibil se randează. De obicei e o imagine hero sau un bloc de titlu. Ținta e sub 2.5 secunde. Orice peste 4 secunde e considerat slab.

Datele din Chrome UX Report din 2025 arată că doar 53% dintre site-uri ating pragul „bun" pentru LCP. Asta înseamnă că aproape jumătate din site-uri pierd poziții în clasament pentru că conținutul principal se încarcă prea lent.

Principalii factori care afectează LCP: imagini neoptimizate (servirea unui JPEG de 3000px pentru un container de 600px), JavaScript care blochează randarea și întârzie prima afișare, și timpi lenți de răspuns ai serverului. Rezolvă aceste trei probleme și vei repara majoritatea problemelor de LCP.

INP: Interaction to Next Paint

INP a înlocuit First Input Delay în martie 2024. Măsoară cât de repede răspunde pagina ta când cineva apasă un buton, atinge un link sau scrie într-un câmp. Ținta e sub 200 de milisecunde.

Această metrică contează mai mult pentru site-urile de produs decât pentru bloguri, pentru că paginile de produs tind să aibă elemente interactive. Calculatoare de prețuri, toggleuri de funcționalități, formulare de solicitare demo. Dacă oricare dintre ele pare lent, INP suferă. Framework-urile JavaScript grele sunt de obicei vinovate.

CLS: Cumulative Layout Shift

CLS măsoară cât de mult se mișcă layout-ul paginii în timpul încărcării. Ținta e sub 0.1. Ai trăit un CLS prost: ești pe punctul de a atinge un link și o reclamă se încarcă deasupra, împingând totul în jos. Atingi ce nu trebuie. Enervant.

Cauzele frecvente includ imagini fără atribute explicite de lățime și înălțime, fonturi web care se schimbă și modifică dimensiunea textului, și embedduri de la terți (widget-uri de chat, bannere de analytics) care se injectează după randarea inițială. Setează dimensiuni pe toate elementele media. Folosește font-display: swap cu fonturi de fallback adecvate. Încarcă scripturile de la terți asincron.

De ce SSG-urile îți oferă un avantaj

Dacă folosești un generator de site-uri statice precum Eleventy, Hugo sau Astro, ai rezolvat deja câteva probleme de SEO tehnic. HTML-ul pre-randat înseamnă că browserul primește exact ce are nevoie fără să aștepte ca JavaScript să construiască pagina.

Acest site rulează pe Eleventy. Scorurile noastre Lighthouse pentru performanță ating constant 95+ fără optimizări exotice. Fără hidratare. Fără blocaje de randare pe client. Fișiere HTML simple servite de pe un CDN.

Compară asta cu un SPA în React unde browserul descarcă un bundle JavaScript, îl parsează, îl execută, apoi randează conținutul. Până când apare secțiunea hero, au trecut două-trei secunde. Un studiu de la Wix Engineering a descoperit că fiecare îmbunătățire de 100ms în LCP a corelat cu o creștere de 0.3% în rata de conversie.

Nu orice companie de produs poate trece la un SSG peste noapte. Dar dacă construiești un nou site de marketing sau un blog, începe cu unul. O să-ți mulțumești mai târziu.

Cum funcționează crawlability-ul?

O analiză Botify a descoperit că Google nu accesează 51% din paginile site-urilor enterprise. Dacă motoarele de căutare nu-ți pot găsi paginile, nimic altceva nu contează. Crawlability-ul e pasul zero.

Robots.txt: fișierul pe care toată lumea îl configurează greșit

Fișierul robots.txt le spune motoarelor de căutare ce părți din site pot accesa. E și fișierul care provoacă cele mai multe daune SEO auto-inflictate pe care le-am văzut vreodată.

Greșeala clasică: mediul de staging are Disallow: / ca să prevină indexarea conținutului de test de către Google. Cineva publică acel robots.txt în producție. Brusc, întregul tău site dispare din rezultatele căutării. Am văzut asta întâmplându-se la companii cu trafic lunar de șase cifre. E întotdeauna o după-amiază proastă.

Verifică-ți robots.txt chiar acum. Accesează domeniultau.com/robots.txt și citește-l. Asigură-te că nu blochează nimic din ce vrei indexat. Dacă nu ești sigur, Google Search Console are un tester de robots.txt.

XML sitemap: cuprinsul tău pentru Google

Un XML sitemap listează fiecare pagină pe care vrei ca motoarele de căutare să o indexeze. E un fișier simplu, dar îi spune lui Google exact ce există pe site-ul tău și când a fost actualizată ultima dată fiecare pagină.

Generează-ți sitemap-ul automat. Fiecare CMS sau SSG major are un plugin sau o funcționalitate nativă pentru asta. Nu-l menține manual. Trimite-l prin Google Search Console și Bing Webmaster Tools. Verifică-l periodic ca să te asiguri că paginile noi apar.

Menține-ți sitemap-ul curat. Nu include pagini pe care le-ai setat la noindex. Nu include URL-uri redirecționate. Un sitemap cu 500 de URL-uri toate valide e mai bun decât unul cu 5.000 de URL-uri unde jumătate returnează erori.

Linkuri interne: semnalul subestimat

Paginile orfane sunt pagini invizibile. Dacă nicio altă pagină de pe site nu trimite spre un conținut, motoarele de căutare s-ar putea să nu-l descopere niciodată, chiar dacă e în sitemap.

Linkurile interne servesc două scopuri. Ajută motoarele de căutare să găsească și să înțeleagă relația dintre paginile tale. Și transmit autoritate de la paginile performante spre conținutul mai nou. De aceea funcționează modelele de cluster tematic: pagina pilon trimite spre fiecare ramură, și fiecare ramură trimite înapoi spre pilon.

O regulă rezonabilă: fiecare pagină ar trebui să fie accesibilă în maximum trei click-uri de pe pagina principală. Dacă un utilizator are nevoie de cinci click-uri ca să ajungă la pagina de prețuri, Google o va trata și ea ca prioritate scăzută. Folosește instrumente precum Screaming Frog sau Ahrefs Site Audit pentru a identifica paginile orfane și a le repara.

Sunt paginile potrivite indexate?

Conform Search Engine Journal, indexul Google conține sute de miliarde de pagini, dar asta nu înseamnă că toate paginile tale sunt incluse. Indexarea corectă a paginilor potrivite (și excluderea celor nepotrivite) e zona unde majoritatea companiilor de produs fac greșeli.

Tag-uri canonical

Tag-urile canonical le spun motoarelor de căutare care versiune a unei pagini este cea „oficială". Asta contează mai mult decât realizează majoritatea echipelor.

Conținutul tău ar putea fi accesibil la mai multe URL-uri. Cu slash la final și fără. Cu www și fără. Cu parametri UTM adăugați. Fiecare dintre acestea e tehnic un URL diferit, iar Google le-ar putea trata ca pagini separate cu conținut duplicat.

Setează un tag canonical auto-referențial pe fiecare pagină. Alege un format de URL (eu prefer fără www, cu slash la final) și respectă-l. Redirecționează toate variațiile spre versiunea canonical cu redirecturi 301.

Când să folosești noindex

Nu orice pagină ar trebui să apară în rezultatele căutării. Pagina de mulțumire după trimiterea formularului? Noindex. Paginile de rezultate ale căutării interne? Noindex. Paginile de arhivă cu conținut subțire? Noindex.

Folosește tag-ul <meta name="robots" content="noindex"> pe paginile care nu au un scop în căutare. Asta îți menține bugetul de crawl concentrat pe paginile care chiar merită poziții.

Conținut duplicat din parametrii URL

Site-urile de e-commerce și SaaS sunt notorii pentru asta. Filtrarea, sortarea și paginarea creează sute de variații de URL pentru același conținut. /products?sort=price și /products?sort=date și /products?page=2 pot arăta toate ca pagini separate pentru Google.

Gestionează asta cu tag-uri canonical care indică spre URL-ul principal, sau folosește instrumentul de parametri URL din Google Search Console pentru a-i spune lui Google cum să gestioneze fiecare tip de parametru.

Cum să-ți verifici indexarea

Scrie site:domeniultau.com în Google. Asta îți arată fiecare pagină pe care Google a indexat-o. Compară acel număr cu paginile din sitemap. Dacă e o diferență mare, ceva nu e în regulă.

Verifică și raportul „Pagini" din Google Search Console, în secțiunea „Indexare". Detaliază exact ce pagini sunt indexate, care sunt excluse și de ce. E cel mai util raport pentru SEO tehnic. Verifică-l lunar.

Cum ajută structured data la SEO?

Un studiu Milestone Research a descoperit că paginile cu schema markup primesc cu până la 40% mai multe click-uri organice decât paginile fără. Structured data le spune motoarelor de căutare ce este conținutul tău, nu doar ce spune.

JSON-LD: formatul corect

Există trei formate pentru structured data: JSON-LD, Microdata și RDFa. Folosește JSON-LD. Google îl recomandă. Se află într-un tag script în head-ul paginii, separat de conținutul HTML. E mai ușor de implementat, întreținut și depanat.

Iată cum arată un schema Article de bază în JSON-LD:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Titlul articolului tău",
  "author": {
    "@type": "Person",
    "name": "Numele Autorului"
  },
  "datePublished": "2026-03-16",
  "dateModified": "2026-03-16"
}

Ce tipuri de schema contează cu adevărat?

Voi fi sincer: majoritatea tipurilor de schema nu fac diferență vizibilă pentru companiile de produs. Iată cele care contează.

Schema Organization și WebSite pe pagina principală. Acestea stabilesc entitatea ta în knowledge graph-ul Google. Include logo-ul, profilurile sociale și informațiile de contact.

Schema Article pe fiecare postare de blog. Include autorul, datele și titlul. Asta ajută Google să înțeleagă structura conținutului tău și să afișeze rich snippets.

Schema FAQPage pe paginile cu secțiuni de întrebări și răspunsuri. E unul dintre puținele tipuri de schema care generează direct rezultate îmbogățite în căutare. Când întrebările tale din FAQ apar ca răspunsuri extensibile în SERP, ratele de click cresc.

Schema BreadcrumbList pentru navigarea pe site. Ajută Google să înțeleagă ierarhia site-ului tău și să afișeze breadcrumbs în rezultatele căutării.

LocalBusiness dacă ai un birou fizic. Asta ajută cu vizibilitatea în căutările locale și poate activa panoul de knowledge panel pentru afacerea ta.

Ignoră schema Product dacă nu ești o companie de e-commerce. Ignoră schema Review dacă nu ai recenzii legitime de la terți. Adăugarea tipurilor de schema care nu corespund conținutului tău real poate face mai mult rău decât bine.

Testarea structured data

Folosește Rich Results Test de la Google pentru a-ți valida implementarea. Lipește un URL și îți arată exact ce poate citi Google din structured data ta. Repară orice erori sau avertismente raportate.

Google Search Console are și o secțiune dedicată „Îmbunătățiri" pentru fiecare tip de schema. Dacă schema FAQ are probleme, le vei vedea acolo. Verifică după fiecare publicare de modificări.

Este site-ul tău pregătit pentru indexarea mobile-first?

Google a trecut la indexarea mobile-first ca standard în 2023, ceea ce înseamnă că versiunea mobilă a site-ului tău e cea pe care Google o accesează și o clasează (Google Search Central, 2023). Dacă experiența mobilă e stricată, pozițiile pe desktop suferă și ele.

Bazele optimizării mobile

N-ar trebui să mai spun asta în 2026, dar încă văd site-uri de produs care necesită scroll orizontal pe telefoane. Sau au ținte de atingere atât de mici încât ai nevoie de un stylus. Ștacheta nu e ridicată.

Setează tag-ul viewport meta: <meta name="viewport" content="width=device-width, initial-scale=1">. Asigură-te că tot conținutul e accesibil pe mobil fără scroll orizontal. Setează țintele de atingere la cel puțin 48x48 pixeli (recomandarea Google). Asigură-te că textul e lizibil fără zoom, cu un minim de 16px pentru textul principal.

Testează pe dispozitive reale

Simularea mobilă din Chrome DevTools e utilă, dar imperfectă. Nu reproduce performanța reală a dispozitivului, condițiile de rețea sau comportamentul la atingere. Cumpără un telefon Android de gamă medie și testează-ți site-ul pe el. E mai aproape de ce experimentează majoritatea utilizatorilor tăi decât MacBook-ul Pro.

Dacă site-ul tău pare rapid pe un telefon Android vechi de trei ani cu conexiune 4G, va părea rapid pentru toți. Ăsta e benchmark-ul.

Ce zici de securitate și HTTPS?

HTTPS este un semnal de clasament Google din momentul în care Google a confirmat asta în 2014. La acest punct, nu există nicio scuză pentru a rula un site HTTP. Let’s Encrypt oferă certificate SSL gratuite. Majoritatea furnizorilor de hosting se ocupă automat.

Avertismente de conținut mixt

Trecerea la HTTPS nu e suficientă dacă pagina ta încarcă în continuare resurse prin HTTP. O singură imagine sau script HTTP declanșează un avertisment de conținut mixt și poate strica indicatorul de conexiune securizată din browsere.

Auditează-ți site-ul pentru conținut mixt după activarea HTTPS. Verifică dacă toate sursele de imagini, tag-urile script, linkurile la stylesheet-uri și importurile de fonturi folosesc URL-uri HTTPS. Majoritatea sistemelor de management al conținutului au pluginuri care le găsesc și le repară automat.

Headere de securitate care merită adăugate

Dincolo de HTTPS, câteva headere HTTP îmbunătățesc atât securitatea, cât și încrederea motoarelor de căutare:

• Content-Security-Policy: Controlează ce resurse poate încărca browserul. Previne atacurile cross-site scripting.
• X-Content-Type-Options: nosniff: Oprește browserele din a face MIME-type sniffing. O îmbunătățire de securitate mică dar semnificativă.
• Referrer-Policy: Controlează câte informații de referrer sunt trimise cu request-urile. strict-origin-when-cross-origin e un default bun.
• Permissions-Policy: Restricționează ce funcționalități ale browserului poate folosi site-ul tău. Dezactivează accesul la cameră, microfon și geolocalizare dacă nu ai nevoie de ele.

Acestea nu afectează direct clasamentele, dar semnalează un site bine întreținut. Iar un site bine întreținut tinde să performeze mai bine la fiecare metrică care chiar afectează clasamentele.

Checklist-ul de SEO tehnic

Iată tot ce am discutat mai sus condensat într-o listă prin care poți lucra efectiv. Recomand să le abordezi în ordine.

Viteză și Core Web Vitals

• [ ] LCP sub 2.5 secunde (testează cu PageSpeed Insights)
• [ ] INP sub 200 de milisecunde
• [ ] CLS sub 0.1
• [ ] Imagini comprimate și servite în format WebP sau AVIF
• [ ] Toate imaginile au atribute explicite de lățime și înălțime
• [ ] Niciun JavaScript care blochează randarea în head-ul documentului
• [ ] Fonturile încărcate cu font-display: swap
• [ ] Scripturile de la terți încărcate asincron

Crawlability

• [ ] Robots.txt verificat și corect (nu blochează conținut important)
• [ ] XML sitemap generat automat și trimis la Search Console
• [ ] Nicio pagină orfană (fiecare pagină are cel puțin un link intern)
• [ ] Paginile cheie accesibile în maximum trei click-uri de pe pagina principală
• [ ] Niciun link intern stricat (verifică cu Screaming Frog sau Ahrefs)

Indexare

• [ ] Tag-uri canonical auto-referențiale pe fiecare pagină
• [ ] Un singur format de URL aplicat (www vs. fără www, slash la final vs. fără slash)
• [ ] Redirecturi 301 pentru toate variațiile de URL
• [ ] Noindex pe paginile care nu ar trebui să se claseze (pagini de mulțumire, arhive de tag-uri, căutare internă)
• [ ] Parametrii URL gestionați prin canonical sau setările Search Console
• [ ] Numărul site:domeniultau.com corespunde cu paginile indexate așteptate

Structured data

• [ ] Schema Organization pe pagina principală
• [ ] Schema Article pe toate postările de blog și articolele
• [ ] Schema FAQPage pe paginile cu secțiuni FAQ
• [ ] Schema BreadcrumbList pentru navigare
• [ ] Toate datele structurate validate cu Rich Results Test
• [ ] Nicio eroare în rapoartele de Îmbunătățiri din Search Console

Mobil

• [ ] Tag-ul viewport meta setat corect
• [ ] Niciun scroll orizontal pe nicio pagină
• [ ] Ținte de atingere de cel puțin 48x48 pixeli
• [ ] Textul principal de cel puțin 16px
• [ ] Testat pe un dispozitiv mobil real de gamă medie

Securitate

• [ ] HTTPS activat cu certificat SSL valid
• [ ] Niciun avertisment de conținut mixt
• [ ] Header Content-Security-Policy setat
• [ ] Header X-Content-Type-Options setat
• [ ] Header Referrer-Policy setat

Parcurge această listă trimestrial. SEO tehnic nu e un proiect de o singură dată. Site-urile se schimbă, pluginurile se actualizează, pagini noi sunt publicate. Ce funcționa trimestrul trecut ar putea fi stricat acum pentru că cineva a publicat o modificare de configurare într-o vineri după-amiază.

Vestea bună: odată ce ai pus această fundație, întreținerea e simplă. Majoritatea acestor verificări durează minute. Partea grea e să le faci prima dată.