SEO tehnic înseamnă proiectarea și întreținerea infrastructurii unui site astfel încât motoarele de căutare să poată descoperi, accesa, reda, înțelege și indexa paginile importante, iar utilizatorii să le poată folosi fără blocaje tehnice. Pentru un magazin online sau un site de servicii, obiectivul nu este obținerea unui scor perfect într-un instrument, ci eliminarea problemelor care limitează vizibilitatea, traficul relevant, conversiile și calitatea măsurării.

Un site poate avea produse bune, servicii competitive și conținut bine documentat, dar să rămână aproape invizibil dacă paginile sunt blocate, duplicate, izolate în arhitectură, randate incomplet sau marcate cu directive contradictorii. În sens invers, un site impecabil tehnic nu va ocupa automat poziții bune dacă nu răspunde suficient de clar intenției de căutare sau nu oferă valoare reală.

SEO tehnic este, așadar, o condiție de funcționare, nu o garanție de clasare. Rolul său este să creeze mediul în care motoarele de căutare pot evalua corect conținutul și în care investițiile în produse, servicii, cercetare și comunicare nu sunt limitate de probleme de infrastructură.

Ce include SEO tehnic, pe scurt

SEO tehnic acoperă șase procese principale: descoperirea URL-urilor, crawlingul, randarea, indexarea, canonicalizarea și servirea paginilor în rezultatele căutării. Problemele apar atunci când paginile importante sunt inaccesibile, transmit semnale contradictorii, se încarcă incomplet, concurează cu variante duplicate sau nu pot fi asociate corect cu restul site-ului.

Pentru un magazin online, aceste probleme afectează frecvent categoriile, produsele, filtrele, paginarea, variantele, imaginile și datele de preț sau stoc. Pentru un site de servicii, problemele apar mai ales în arhitectura serviciilor, paginile locale, formularele de contact, conținutul duplicat și implementările JavaScript.

Google precizează că nu există cerințe tehnice suplimentare pentru apariția în AI Overviews sau AI Mode. Pagina trebuie să fie indexată, eligibilă pentru afișarea unui snippet și să respecte aceleași principii SEO fundamentale folosite în căutarea obișnuită.

Ce este SEO tehnic

SEO tehnic reprezintă componenta optimizării pentru motoarele de căutare care gestionează modul în care un site este descoperit, parcurs, randat, indexat, canonicalizat și servit în rezultate.

În practică, include:

arhitectura informațională;
linkingul intern;
structura URL-urilor;
fișierul robots.txt;
directivele meta robots și X-Robots-Tag;
sitemapurile XML;
codurile HTTP;
redirecturile;
canonicalizarea;
conținutul duplicat;
paginarea și navigația cu filtre;
randarea JavaScript;
HTML-ul semantic;
titlurile și metadatele;
performanța și Core Web Vitals;
optimizarea imaginilor;
datele structurate Schema.org;
versiunile mobile și internaționale;
migrarea site-urilor;
securitatea și disponibilitatea serverului;
analiza logurilor și monitorizarea indexării.

Nu toate problemele tehnice au aceeași importanță. Un noindex aplicat din greșeală pe toate categoriile unui magazin este critic. Un warning opțional într-o implementare Schema.org poate avea impact redus. Auditul nu trebuie să numere erori, ci să determine ce pagini sunt afectate, ce rezultat comercial depinde de ele și cât de sigură este explicația.

Cum ajunge o pagină în Google

Pentru a înțelege diagnosticul tehnic, trebuie separate etapele prin care o pagină poate deveni eligibilă pentru afișare.

Descoperire: motorul de căutare află că URL-ul există.
Crawling: crawlerul solicită URL-ul și resursele asociate.
Randare: HTML-ul, CSS-ul și JavaScript-ul sunt procesate.
Indexare: conținutul și semnalele paginii sunt evaluate și stocate.
Canonicalizare: este selectată varianta reprezentativă dintre URL-uri similare.
Clasare: pagina este evaluată în raport cu o anumită căutare.
Servire: motorul decide dacă și cum afișează rezultatul.

Aceste etape nu sunt sinonime. O pagină poate fi descoperită, dar necrawl-uită. Poate fi crawl-uită, dar neindexată. Poate fi indexată, dar considerată duplicatul altui URL. Poate fi indexată corect și totuși să nu primească vizibilitate, deoarece răspunsul său este slab sau concurența este mai relevantă.

Exemplu dintr-un magazin online

Un magazin publică o categorie la adresa:

https://exemplu.ro/scaune-ergonomice/

Categoria este inclusă în meniu și sitemap, deci poate fi descoperită. Serverul returnează 200 OK, iar conținutul este vizibil. În cod există însă următorul element:

<link rel="canonical"
      href="https://exemplu.ro/scaune/">

Problema nu se află la crawling, ci la canonicalizare. Site-ul îi transmite motorului de căutare că pagina principală este categoria generală. Dacă această instrucțiune nu reflectă relația reală dintre pagini, categoria importantă poate pierde semnale și vizibilitate.

Exemplu dintr-un site de servicii

O firmă creează o pagină pentru „consultant fiscal București”, dar aceasta nu apare în meniu, nu primește linkuri din alte pagini și nu este inclusă în sitemap. Pagina returnează 200 OK, însă este orfană. Chiar dacă poate fi descoperită printr-un link extern, arhitectura internă nu comunică importanța sau relația sa cu serviciul principal.

Cerințele tehnice minime

O pagină trebuie să fie accesibilă crawlerului, să returneze un răspuns funcțional și să ofere informații indexabile. Aceste condiții nu garantează indexarea, dar fără ele pagina are șanse reduse să fie procesată corect.

Pentru o pagină comercială importantă trebuie verificate cel puțin următoarele condiții:

URL-ul este accesibil fără autentificare;
Googlebot nu este blocat;
serverul returnează codul potrivit;
conținutul principal este prezent în HTML sau DOM-ul randat;
nu există o directivă noindex accidentală;
canonicalul indică URL-ul corect;
pagina primește linkuri interne;
resursele necesare randării sunt accesibile;
versiunea mobilă conține informațiile esențiale;
pagina nu este un duplicat lipsit de diferențiere.

Îndeplinirea cerințelor tehnice nu obligă Google să indexeze sau să afișeze pagina. Conținutul trebuie să fie suficient de util, distinct și relevant pentru a merita includerea.

Arhitectura site-ului

Arhitectura descrie modul în care paginile sunt grupate, ierarhizate și conectate. O arhitectură bună permite utilizatorilor să înțeleagă unde se află, iar motoarelor de căutare să descopere paginile și să estimeze relațiile dintre ele.

Arhitectura unui magazin online

Un traseu tipic este:

Homepage
└── Categorie principală
    └── Subcategorie
        └── Produs

Exemplu:

Homepage
└── Mobilier de birou
    └── Scaune ergonomice
        └── Scaun ergonomic Model X

Produsele importante nu ar trebui să depindă exclusiv de căutarea internă sau de filtre. Google recomandă ca produsele să poată fi accesate prin linkuri de la categorii și subcategorii. Googlebot nu completează, în mod obișnuit, formularele de căutare internă pentru a descoperi produsele.

O categorie importantă poate primi suplimentar linkuri din:

homepage;
articole de ghidare;
pagini de brand;
categorii asociate;
produse complementare;
secțiuni sezoniere.

Arhitectura unui site de servicii

Un site B2B poate avea structura:

Homepage
└── Servicii
    ├── Consultanță fiscală
    ├── Contabilitate
    └── Audit financiar
        └── Audit pentru companii de producție

Paginile pentru industrii și locații trebuie create numai când oferă informații și diferențiere reale. Combinarea automată a 12 servicii cu 15 orașe poate produce 180 de pagini aproape identice. Dacă singura diferență este numele orașului, site-ul riscă să creeze pagini slabe sau de tip doorway.

Adâncimea de click

Adâncimea indică numărul de linkuri necesare pentru a ajunge de la o pagină de referință la destinație. Nu există o regulă universală conform căreia orice pagină trebuie să fie accesibilă în maximum trei clickuri.

Principiul util este mai simplu: paginile importante comercial trebuie să fie ușor accesibile, iar ierarhia linkurilor trebuie să reflecte prioritatea lor.

Dacă o categorie generează o parte importantă din venit, dar este ascunsă sub cinci niveluri de navigație, problema nu este doar SEO. Clienții au aceeași dificultate de a o găsi.

Linkingul intern

Linkingul intern ajută motoarele de căutare să descopere pagini, să înțeleagă relațiile dintre ele și să estimeze importanța relativă a acestora. Pentru utilizatori, linkurile creează trasee între informație și acțiune.

Cum arată un link crawlable

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

Varianta următoare poate arăta ca link, dar nu este o implementare robustă:

<span onclick="window.location='/servicii/audit-seo-tehnic/'">
  audit SEO tehnic
</span>

Paginile importante trebuie legate prin elemente <a> cu atribut href. Google recomandă linkuri HTML reale, deoarece evenimentele JavaScript atașate altor elemente pot să nu fie detectate sau urmărite în același mod.

Anchor textul

Textul linkului trebuie să descrie destinația.

Mai util:

<a href="/ghid-alegere-scaun-ergonomic/">
  cum alegi un scaun ergonomic
</a>

Mai puțin util:

<a href="/ghid-alegere-scaun-ergonomic/">
  click aici
</a>

Anchor textul nu trebuie repetat mecanic în aceeași formă pe toate paginile. Este mai natural să reflecte contextul propoziției, păstrând însă destinația clară.

Linking intern pentru magazine online

Un sistem util include:

homepage către categoriile prioritare;
categorii către subcategorii;
subcategorii către produse;
produse către categoria lor;
produse către accesorii și produse complementare;
articole către categorii și produse relevante;
breadcrumb către nivelurile superioare;
pagini de brand către produsele brandului;
produse alternative pentru articole indisponibile.

Exemplu: un ghid despre alegerea unui scaun ergonomic poate trimite contextual către categoria de scaune, către un articol despre suportul lombar și către două produse relevante. Nu trebuie transformat într-un catalog de linkuri fără logică editorială.

Linking intern pentru site-uri de servicii

Un site de servicii poate conecta:

articole educaționale cu serviciul relevant;
studii de caz cu problema și serviciul aplicat;
pagini de industrie cu serviciile disponibile;
servicii principale cu subservicii;
pagini locale cu locația și datele reale;
paginile echipei cu ariile de expertiză;
întrebările frecvente cu ghidurile aprofundate.

Breadcrumbs

Breadcrumbul vizibil ajută orientarea și exprimă ierarhia:

<nav aria-label="Breadcrumb">
  <ol>
    <li><a href="/">Acasă</a></li>
    <li><a href="/mobilier-birou/">Mobilier de birou</a></li>
    <li><a href="/scaune-ergonomice/">Scaune ergonomice</a></li>
    <li aria-current="page">Model X</li>
  </ol>
</nav>

Markupul BreadcrumbList trebuie să reflecte aceeași structură, nu o ierarhie inventată doar pentru motorul de căutare.

Pagini orfane

O pagină orfană nu primește linkuri interne crawlable. Pentru identificare trebuie comparate:

URL-urile găsite de crawler;
sitemapurile;
paginile din Google Search Console;
landing page-urile din analytics;
URL-urile din CMS;
logurile serverului;
backlinkurile externe.

Dacă o pagină este importantă, trebuie integrată în arhitectură. Dacă nu mai are rol, trebuie evaluată pentru consolidare, redirecționare, eliminare sau noindex.

nofollow, sponsored și ugc

Pentru linkurile normale nu este necesar un atribut special.

Un link plătit:

<a href="https://partener.ro/"
   rel="sponsored">
  Partener comercial
</a>

Un link din conținut generat de utilizatori:

<a href="https://exemplu-utilizator.ro/"
   rel="ugc">
  Site-ul autorului
</a>

nofollow nu trebuie folosit pentru a controla arhitectura internă a paginilor obișnuite și nu înlocuiește noindex.

Structura URL-urilor

URL-urile trebuie să fie stabile, clare și administrabile. Ele nu trebuie schimbate doar pentru o îmbunătățire cosmetică.

Exemplu clar:

https://exemplu.ro/scaune-ergonomice/

Exemplu dificil:

https://exemplu.ro/index.php?id=4872&cat=19&session=abc

Reguli practice:

folosește litere mici;
folosește cratime între cuvinte;
evită identificatorii de sesiune;
păstrează URL-urile persistente;
limitează parametrii inutili;
alege o singură variantă cu sau fără trailing slash;
consolidează HTTP/HTTPS și www/non-www;
nu introduce date în URL pentru conținut evergreen dacă nu sunt necesare;
folosește redirect permanent când URL-ul se schimbă definitiv.

Parametrii UTM

URL-urile cu parametri de campanie pot afișa același conținut:

/servicii/seo/?utm_source=newsletter
/servicii/seo/?utm_source=linkedin

Linkurile interne trebuie să folosească URL-ul curat, iar canonicalul trebuie să indice varianta principală.

Parametri clari și persistenți

Pentru site-urile e-commerce, Google recomandă parametri de forma ?cheie=valoare, nu valori izolate greu de interpretat.

Recomandat:

/tricou?culoare=verde
/categorie?page=2

Mai greu de interpretat:

/tricou?verde
/categorie?2

Parametrii temporari, precum identificatorii de sesiune, locația relativă sau momentul curent, nu trebuie folosiți în linkurile interne către paginile indexabile.

Variantele produselor

Pentru un tricou disponibil în mai multe culori, pot exista URL-uri precum:

/tricou-model-x/
/tricou-model-x/?culoare=verde
/tricou-model-x/?culoare=negru

Decizia depinde de valoarea fiecărei variante:

dacă variantele nu au cerere sau conținut distinct, pot fi consolidate;
dacă fiecare variantă are inventar, imagini și cerere proprie, poate avea URL separat;
linkurile, canonicalul, feedul și datele structurate trebuie să fie consecvente.

Crawling și robots.txt

Crawlingul este procesul prin care roboții solicită URL-uri și urmăresc legăturile dintre ele. Fișierul robots.txt controlează crawlingul anumitor zone, nu indexarea în sens absolut.

Exemplu:

User-agent: *
Disallow: /cont/
Disallow: /cos/
Disallow: /cautare/
Allow: /

Sitemap: https://exemplu.ro/sitemap_index.xml

Greșeala critică

User-agent: *
Disallow: /

Această regulă blochează întregul site pentru roboții care o respectă. Apare frecvent când setările mediului de dezvoltare sunt copiate în producție.

robots.txt nu este o metodă de noindex

Folosește robots.txt când vrei să limitezi accesarea anumitor tipuri de URL-uri. Folosește noindex când pagina poate fi accesată, dar nu trebuie să apară în rezultatele căutării.

Combinația următoare este contradictorie:

# robots.txt
Disallow: /pagina-interna/

<meta name="robots"
      content="noindex">

Dacă pagina nu poate fi accesată, motorul poate să nu vadă directiva noindex. Pentru eliminarea din rezultate, pagina trebuie lăsată crawlable până când directiva este procesată.

Ce poate fi blocat într-un magazin

În funcție de implementare, pot fi evaluate:

coșul;
contul clientului;
căutarea internă;
anumite sortări;
parametrii fără valoare;
zonele de administrare;
endpointurile tehnice.

Nu trebuie blocate automat fișierele CSS sau JavaScript necesare randării.

Meta robots și X-Robots-Tag

Meta robots controlează indexarea la nivelul unei pagini HTML:

<meta name="robots"
      content="noindex, follow">

Pentru fișiere non-HTML, precum un PDF:

X-Robots-Tag: noindex

Directivă	Rol	Observație
`index`	Permite indexarea	Nu garantează includerea în index
`noindex`	Solicită eliminarea din index	Pagina trebuie să fie accesibilă crawlerului
`follow`	Permite urmărirea linkurilor	Comportament implicit în majoritatea cazurilor
`nofollow`	Limitează urmărirea linkurilor	Nu controlează canonicalizarea
`nosnippet`	Blochează snippetul	Poate reduce atractivitatea și eligibilitatea pentru citări AI
`max-snippet`	Limitează lungimea snippetului	Se folosește numai când există un motiv clar
`max-image-preview`	Controlează dimensiunea previzualizării imaginii	Pentru articole este utilă valoarea `large`

Pentru a fi eligibilă drept link de susținere în AI Overviews sau AI Mode, o pagină trebuie să poată fi indexată și afișată în Google Search cu un snippet. Directive precum nosnippet sau limite foarte restrictive pot reduce informațiile pe care Google le poate prezenta.

Sitemapurile XML

Sitemapul este un inventar al URL-urilor pe care site-ul le consideră importante. El ajută descoperirea și monitorizarea, dar nu garantează indexarea.

În mod normal, sitemapul trebuie să conțină:

URL-uri canonice;
pagini indexabile;
răspunsuri 200 OK;
pagini relevante pentru căutare;
date de modificare reale, dacă sunt incluse.

Nu ar trebui să conțină:

redirecturi;
404 sau 410;
pagini cu noindex;
variante necanonice;
filtre fără valoare;
pagini de cont, coș sau căutare internă.

Exemplu

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://exemplu.ro/seo-tehnic/</loc>
    <lastmod>2026-07-31</lastmod>
  </url>
</urlset>

Data lastmod trebuie schimbată numai după o modificare reală și semnificativă. Actualizarea automată zilnică a tuturor datelor reduce valoarea semnalului.

Sitemapuri pentru magazine mari

Un magazin poate separa:

categorii;
produse;
articole;
pagini de brand;
imagini;
versiuni lingvistice.

Această separare permite monitorizarea mai clară a indexării pe tipuri de pagini. Sitemapul nu înlocuiește linkingul intern. O pagină inclusă în sitemap, dar absentă din arhitectură, rămâne slab conectată.

Codurile HTTP

Cod	Semnificație	Utilizare
`200`	Solicitare reușită	Pagină funcțională
`301` / `308`	Mutare permanentă	URL înlocuit definitiv
`302` / `307`	Mutare temporară	Situație reversibilă
`304`	Conținut nemodificat	Reduce transferul la recrawl
`404`	Resursa nu există	URL fără înlocuitor
`410`	Resursa a fost eliminată	Eliminare explicită
`429`	Prea multe solicitări	Limitare temporară
`500`	Eroare internă	Problemă a aplicației sau serverului
`503`	Serviciu indisponibil	Mentenanță temporară

Soft 404

Un soft 404 apare când pagina returnează 200, dar spune că resursa nu există:

HTTP/1.1 200 OK

Produsul căutat nu a fost găsit.

Serverul declară succes, în timp ce conținutul declară eroare. Soluția este un cod potrivit sau un redirect către un înlocuitor real.

404 sau 410?

Folosește 404 când resursa nu a fost găsită sau nu mai există, fără să fie necesar să comunici o eliminare intenționată. Folosește 410 când vrei să indici explicit că resursa a fost eliminată.

În practică, ambele pot conduce la eliminarea URL-ului din index. Alegerea trebuie făcută după sensul real al situației, nu după presupunerea că 410 produce întotdeauna un avantaj important.

Produse eliminate

dacă există succesor direct, redirect permanent;
dacă pagina are încă valoare și cerere, poate rămâne cu alternative;
dacă nu există înlocuitor, 404 sau 410;
nu redirecționa automat toate produsele către homepage.

Redirecturile

Redirecturile permanente sunt potrivite pentru URL-uri mutate definitiv:

/serviciu-vechi/
301 → /serviciu-nou/

Redirecturile temporare sunt potrivite pentru schimbări reversibile:

/campanie/
302 → /campanie-temporara/

301 sau 302?

Folosește 301 sau 308 când mutarea este permanentă și vechiul URL nu mai trebuie folosit. Folosește 302 sau 307 când redirecționarea este temporară, iar URL-ul inițial trebuie păstrat drept referință principală.

Lanțuri de redirect

/a/
301 → /b/
301 → /c/
301 → /destinatie/

Linkurile interne și regulile vechi trebuie actualizate direct către destinația finală. Lanțurile adaugă latență, consumă resurse și complică diagnosticul.

Bucle

/a/ → /b/
/b/ → /a/

O buclă împiedică accesul și trebuie tratată ca incident critic.

Canonicalizarea

Canonicalizarea indică URL-ul reprezentativ dintre pagini identice sau foarte asemănătoare.

<link rel="canonical"
      href="https://exemplu.ro/seo-tehnic/">

Canonicalul este un semnal puternic, nu o comandă absolută. Motoarele pot selecta altă variantă dacă semnalele site-ului sunt contradictorii.

Canonical sau redirect?

Folosește redirect când vechiul URL nu mai trebuie accesat și utilizatorii trebuie trimiși automat către noua destinație. Folosește canonical când mai multe URL-uri trebuie să rămână accesibile, dar unul dintre ele reprezintă versiunea principală pentru indexare.

Canonical sau noindex?

Folosește canonical când mai multe URL-uri au conținut identic sau foarte asemănător și vrei să consolidezi semnalele către o variantă principală. Folosește noindex când pagina nu trebuie să apară în rezultatele căutării. Cele două rezolvă probleme diferite.

Semnale care trebuie aliniate

canonical;
redirecturi;
linking intern;
sitemap;
hreflang;
date structurate;
feeduri comerciale.

Exemplu contradictoriu

pagina A are canonical către B;
sitemapul include A;
linkurile trimit către A;
B redirecționează către A.

Nu există o preferință coerentă. Site-ul trebuie să aleagă URL-ul canonic și să alinieze toate semnalele.

Navigația cu filtre

Filtrele sunt una dintre cele mai mari surse de URL-uri în magazine.

/laptopuri?brand=x&ram=16&culoare=negru&sort=pret

Dacă fiecare combinație este crawlable, un catalog cu câteva sute de produse poate genera sute de mii de URL-uri.

Filtre care pot avea valoare

/laptopuri-gaming/
/laptopuri-business/

Acestea pot răspunde unor intenții distincte, dacă au suficiente produse și conținut diferențiat.

Filtre utilitare

?sort=pret-desc
?view=grid
?items=96

Acestea schimbă prezentarea, nu subiectul paginii.

Proces de decizie

Pentru fiecare filtru se verifică:

există cerere distinctă;
combinația rămâne stabilă;
există suficiente produse;
pagina poate avea conținut propriu;
are rol în arhitectură;
nu canibalizează o categorie existentă;
poate fi menținută când stocul se schimbă.

Studiu de caz ipotetic

Un magazin are 20.000 de produse și 1,4 milioane de URL-uri generate de filtre. Googlebot petrece o parte mare din solicitări pe sortări, combinații fără produse și parametri de sesiune.

Ordinea de intervenție:

exportarea tuturor tipurilor de URL;
analiza logurilor;
gruparea parametrilor după funcție;
identificarea combinațiilor cu valoare;
crearea de URL-uri curate pentru acestea;
eliminarea linkurilor către combinații inutile;
canonical sau noindex unde este justificat;
robots.txt pentru spații infinite, după analiză;
sitemap numai cu URL-uri canonice;
monitorizarea indexării și crawlingului.

Nu există o singură soluție pentru toate filtrele. Unele trebuie indexate, altele trebuie lăsate accesibile doar utilizatorilor, iar altele trebuie eliminate din sistemul de linkuri.

Paginarea și infinite scroll

Fiecare pagină dintr-o secvență trebuie să aibă URL propriu:

/scaune-ergonomice/?page=2

Fiecare pagină trebuie să aibă, în mod obișnuit, canonical către ea însăși, nu către pagina 1.

Linkurile secvențiale trebuie să fie crawlable:

<a href="/scaune-ergonomice/?page=2">
  Pagina următoare
</a>

Google nu apasă butoane ca un utilizator. Dacă produsele sunt încărcate doar după click pe „Mai multe” sau după scroll, trebuie să existe și URL-uri accesibile prin linkuri.

Google nu mai folosește rel="next" și rel="prev" pentru identificarea secvențelor, deși acestea pot fi utile altor sisteme.

Paginare sau load more?

Paginarea oferă URL-uri distincte, o poziție clară și acces mai simplu pentru crawlere. Load more poate oferi o experiență fluidă, dar trebuie susținut de URL-uri și linkuri pe care crawlerul le poate accesa. Infinite scroll fără o structură URL accesibilă poate ascunde produse sau articole.

HTML semantic și headinguri

HTML-ul semantic explică rolul elementelor din pagină. Nu înlocuiește conținutul, dar îl face mai robust pentru browsere, tehnologii asistive și crawlere.

Diferența dintre title și H1

<title> este titlul documentului folosit în browser și ca sursă posibilă pentru rezultatul Google;
H1 este titlul principal vizibil al paginii;
og:title controlează titlul folosit de multe platforme sociale.

Acestea pot fi asemănătoare, dar nu trebuie să fie obligatoriu identice.

Ierarhie corectă

<h1>Scaune ergonomice</h1>

<h2>Cum alegi un scaun ergonomic</h2>

<h3>Suportul lombar</h3>
<h3>Reglajele scaunului</h3>

<h2>Modele disponibile</h2>

Ierarhie neclară

<h1>Scaune ergonomice</h1>
<h4>Cum alegi un scaun</h4>
<h2>Suport lombar</h2>

O ordine imperfectă nu produce automat o penalizare SEO, dar reduce claritatea semantică și accesibilitatea.

Reguli practice

un singur titlu principal clar;
H2 pentru ideile majore;
H3 pentru subdiviziuni reale;
H4 pentru procese complexe;
nu folosi headinguri doar pentru mărimea fontului;
nu introduce cuvinte-cheie forțat în fiecare heading;
headingurile din acordeoane trebuie să descrie secțiunea;
nu folosi componente globale care generează zeci de H1-uri.

Google poate folosi H1, alte headinguri și textul vizual proeminent drept surse pentru title link. Un titlu principal clar reduce ambiguitatea.

Meta title și meta description

Google nu impune o limită fixă în caractere pentru elementul <title> sau meta description. Rezultatele sunt trunchiate în funcție de spațiul disponibil și pot fi rescrise.

Ca reguli editoriale:

meta title: aproximativ 50–60 de caractere;
meta description: aproximativ 140–160 de caractere;
aceste intervale reduc riscul trunchierii, dar nu sunt limite tehnice;
unicitatea și claritatea sunt mai importante decât atingerea unei lungimi exacte.

Exemplu pentru categorie

<title>Scaune ergonomice pentru birou • Exemplu</title>

<meta name="description"
      content="Compară scaune ergonomice cu suport lombar, reglaje și garanție. Vezi modelele disponibile, specificațiile și opțiunile de livrare.">

Exemplu pentru produs

<title>Scaun ergonomic Model X, negru • Exemplu</title>

<meta name="description"
      content="Scaun ergonomic Model X cu suport lombar reglabil, tetieră și brațe 4D. Vezi prețul, stocul, dimensiunile și condițiile de livrare.">

Exemplu pentru serviciu

<title>Audit SEO tehnic pentru site-uri de business • Exemplu</title>

<meta name="description"
      content="Audit SEO tehnic pentru indexare, arhitectură, viteză, JavaScript și migrare. Primești probleme prioritizate și recomandări aplicabile.">

Exemplu slab

<title>
Scaune, scaune ieftine, scaune bune, scaune ofertă
</title>

De ce poate fi rescris titlul

este prea lung;
este generic;
repetă excesiv cuvinte;
nu corespunde conținutului;
conține boilerplate excesiv;
pagina are un H1 mai clar;
titlul nu reflectă limba principală.

Google poate genera snippetul folosind conținutul paginii atunci când consideră că acesta răspunde mai bine căutării decât meta description. Meta description trebuie tratată ca o propunere editorială, nu ca text garantat.

Optimizarea imaginilor

Imaginile influențează performanța, accesibilitatea, conversia și vizibilitatea în Google Images, Google Lens sau alte suprafețe vizuale.

Atributul alt

Pentru o imagine informativă:

<img
  src="/imagini/scaun-ergonomic-negru.webp"
  alt="Scaun ergonomic negru cu suport lombar reglabil"
  width="900"
  height="900">

Pentru o imagine decorativă:

<img
  src="/imagini/forma-decorativa.svg"
  alt=""
  aria-hidden="true">

Pentru o imagine-link:

<a href="/cos/">
  <img
    src="/icons/cos.svg"
    alt="Deschide coșul de cumpărături">
</a>

Alt textul descrie informația sau funcția imaginii. Nu trebuie să fie o listă de cuvinte-cheie. Pentru o imagine care funcționează ca link, alt textul poate avea și rolul de anchor text.

Imagini responsive

<picture>
  <source
    type="image/avif"
    srcset="/produs-480.avif 480w,
            /produs-960.avif 960w,
            /produs-1440.avif 1440w">

  <source
    type="image/webp"
    srcset="/produs-480.webp 480w,
            /produs-960.webp 960w,
            /produs-1440.webp 1440w">

  <img
    src="/produs-960.jpg"
    srcset="/produs-480.jpg 480w,
            /produs-960.jpg 960w,
            /produs-1440.jpg 1440w"
    sizes="(max-width: 768px) 100vw, 50vw"
    width="960"
    height="960"
    alt="Espressor automat văzut din față"
    loading="lazy"
    decoding="async">
</picture>

Elementul LCP nu trebuie încărcat leneș

<img
  src="/hero-categorie.webp"
  alt="Colecție de scaune ergonomice"
  width="1600"
  height="900"
  fetchpriority="high">

Checklist pentru imagini

dimensiuni adaptate spațiului de afișare;
compresie adecvată;
WebP sau AVIF, cu fallback dacă este necesar;
srcset și sizes;
lățime și înălțime declarate;
lazy loading pentru imaginile sub fold;
fără lazy loading pentru imaginea LCP;
URL-uri stabile;
nume descriptive;
alt text contextual;
imaginile importante accesibile crawlerului;
image sitemap pentru cataloage mari;
imaginile produsului incluse în datele structurate;
minimum 1.200 px lățime pentru imaginile principale vizate pentru Discover;
max-image-preview:large.

Pentru produsele care trebuie descoperite în Google Images sau Lens, calitatea imaginii, datele produsului și informațiile actualizate din Merchant Center trebuie tratate împreună.

JavaScript SEO

Problema nu este folosirea JavaScript-ului, ci dependența conținutului critic de execuții care pot eșua, întârzia sau necesita acțiuni ale utilizatorului.

HTML inițial

<div id="produs"></div>

DOM după randare

<div id="produs">
  <h1>Scaun ergonomic Model X</h1>
  <p>Descrierea produsului...</p>
</div>

Dacă API-ul eșuează sau scriptul este blocat, conținutul poate lipsi din versiunea randată.

Modele de randare

Model	Descriere	Risc SEO
SSR	HTML generat pe server	Robust pentru conținut critic
SSG	HTML generat la build	Bun pentru pagini stabile
CSR	Conținut generat în browser	Depinde de randare și API-uri
Hydration	HTML existent devine interactiv	Poate consuma mult JavaScript
Dynamic rendering	Versiuni diferite pentru crawler și utilizator	Soluție temporară, greu de întreținut

SSR sau CSR?

SSR și SSG oferă, de regulă, un HTML inițial mai robust pentru conținutul important. CSR poate funcționa, dar crește dependența de JavaScript, API-uri și randare. Alegerea trebuie făcută după tipul aplicației, frecvența actualizării și resursele echipei, nu doar după SEO.

Ce trebuie comparat

view source;
DOM-ul browserului;
HTML-ul din URL Inspection;
captura randată;
erorile din consolă;
solicitările de rețea;
răspunsurile API;
metadatele înainte și după randare.

Infinite scroll

Google nu derulează pagina precum un utilizator. Produsele încărcate doar după scroll trebuie să fie accesibile și prin URL-uri paginabile, legate cu <a href>.

Optimizarea codului și a resurselor

Optimizarea codului urmărește reducerea timpului, resurselor și riscului necesar pentru afișarea conținutului important.

HTML

HTML valid și semantic;
titlu și metadate în <head>;
linkuri reale;
fără DOM excesiv;
conținut critic disponibil textual;
fără texte importante generate doar prin CSS;
formulare cu etichete accesibile;
elemente interactive cu rol corect.

Conținutul inserat exclusiv prin proprietatea CSS content nu trebuie folosit pentru informații importante. Textul comercial, descrierile și linkurile trebuie să existe în HTML sau DOM.

CSS

eliminarea CSS neutilizat;
critical CSS pentru conținutul inițial;
încărcarea amânată a stilurilor neesențiale;
evitarea fișierelor foarte mari pentru câteva reguli;
reducerea calculelor costisitoare de layout;
rezervarea spațiului pentru elemente dinamice.

JavaScript

code splitting;
tree shaking;
eliminarea bibliotecilor neutilizate;
amânarea scripturilor necritice;
reducerea sarcinilor lungi;
împărțirea procesării în operațiuni mai mici;
limitarea scripturilor third-party;
auditarea tag managerului;
încărcarea modulelor doar unde sunt folosite.

Scripturi third-party

Un site de business poate încărca simultan analytics, tag manager, CRM, chat, heatmaps, cookie management, calendare, formulare și rețele publicitare. Fiecare script poate adăuga latență, erori și sarcini pe threadul principal.

Auditul trebuie să răspundă la patru întrebări:

Este scriptul folosit?
Este necesar pe fiecare pagină?
Poate fi încărcat după interacțiune sau consimțământ?
Ce rezultat comercial justifică impactul său?

Compresie și cache

Brotli sau Gzip;
cache headers pentru resurse statice;
hashuri în numele fișierelor;
CDN unde reduce latența;
HTTP/2 sau HTTP/3;
preconnect numai către domenii critice;
preload numai pentru resurse esențiale;
evitarea preîncărcării excesive.

Fonturi

formate moderne;
subseturi de caractere;
număr limitat de greutăți;
font-display potrivit;
preload numai pentru fonturile critice;
evitarea întârzierii textului vizibil.

Core Web Vitals

Metrică	Ce măsoară	Prag „bun”
LCP	Încărcarea elementului principal	Maximum 2,5 secunde
INP	Răspunsul la interacțiuni	Maximum 200 ms
CLS	Stabilitatea vizuală	Maximum 0,1

Evaluarea se face la percentila 75. Datele de teren descriu utilizatori reali, în timp ce testele de laborator ajută diagnosticul.

LCP

Probleme frecvente:

server lent;
imagine hero mare;
imagine descoperită târziu;
lazy loading aplicat greșit;
CSS sau fonturi blocante;
conținut generat numai după JavaScript.

INP

Exemplu: filtrul unui magazin rulează un script de 600 ms la fiecare click. Soluția poate include reducerea JavaScript-ului, împărțirea sarcinilor și optimizarea actualizării DOM.

CLS

Exemplu: un banner promoțional este inserat deasupra produselor după încărcare. Spațiul trebuie rezervat dinainte.

Core Web Vitals sunt importante pentru experiență, dar nu trebuie tratate ca factor unic sau ca justificare pentru ignorarea conținutului, arhitecturii și intenției.

Mobile-first

Versiunea mobilă trebuie să conțină aceleași informații importante, linkuri, metadate și date structurate.

Probleme frecvente:

descrieri eliminate pe mobil;
linkuri importante absente;
imagini diferite sau blocate;
canonical diferit;
date structurate incomplete;
butoane greu de folosit;
interstițiale intruzive;
performanță semnificativ mai slabă;
filtre inaccesibile crawlerului.

Conținutul din acordeoane poate fi indexabil dacă există în DOM. Nu trebuie eliminat complet doar pentru a simplifica interfața.

Date structurate și Schema.org

Schema.org este vocabularul. Google folosește anumite tipuri și proprietăți pentru funcționalități în rezultate. Un markup poate fi valid Schema.org, dar să nu producă un rich result Google.

Trebuie separate:

validitatea sintactică;
concordanța cu pagina;
proprietățile obligatorii;
proprietățile recomandate;
eligibilitatea Google;
afișarea efectivă.

Nu există un tip special de Schema.org care să asigure includerea în AI Overviews sau AI Mode. Datele structurate trebuie să corespundă informațiilor vizibile și să fie folosite pentru tipul real al paginii.

Product și Offer

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Scaun ergonomic Model X",
  "image": [
    "https://exemplu.ro/imagini/model-x-1x1.jpg",
    "https://exemplu.ro/imagini/model-x-4x3.jpg",
    "https://exemplu.ro/imagini/model-x-16x9.jpg"
  ],
  "description": "Scaun ergonomic cu suport lombar reglabil.",
  "sku": "SC-X-NEGRU",
  "gtin13": "5941234567890",
  "brand": {
    "@type": "Brand",
    "name": "Exemplu"
  },
  "offers": {
    "@type": "Offer",
    "url": "https://exemplu.ro/scaun-model-x/",
    "priceCurrency": "RON",
    "price": "1499.00",
    "priceValidUntil": "2026-12-31",
    "itemCondition": "https://schema.org/NewCondition",
    "availability": "https://schema.org/InStock"
  }
}
</script>

Informațiile trebuie să coincidă cu pagina. Nu marca prețuri sau stocuri care nu sunt vizibile ori actuale.

Proprietăți relevante pentru produse

name;
image;
description;
sku;
gtin;
mpn;
brand;
offers;
review;
aggregateRating.

Ratingul trebuie adăugat numai dacă evaluările există și sunt prezentate pe pagină. Recenziile și scorurile nu trebuie inventate sau colectate într-un mod care induce în eroare.

MerchantReturnPolicy

{
  "@type": "MerchantReturnPolicy",
  "applicableCountry": "RO",
  "returnPolicyCategory":
    "https://schema.org/MerchantReturnFiniteReturnWindow",
  "merchantReturnDays": 14,
  "returnMethod":
    "https://schema.org/ReturnByMail",
  "returnFees":
    "https://schema.org/FreeReturn"
}

OfferShippingDetails

{
  "@type": "OfferShippingDetails",
  "shippingDestination": {
    "@type": "DefinedRegion",
    "addressCountry": "RO"
  },
  "shippingRate": {
    "@type": "MonetaryAmount",
    "value": "19.99",
    "currency": "RON"
  }
}

Exemplele trebuie adaptate condițiilor reale. Dacă returul nu este gratuit, markupul nu trebuie să afirme contrariul.

ProductGroup și variante

Pentru variante pot fi folosite:

ProductGroup;
hasVariant;
variesBy;
identificatori și URL-uri proprii;
preț și disponibilitate pentru fiecare variantă.

Datele structurate trebuie să reflecte selecția reală din interfață. Dacă utilizatorul selectează varianta verde, prețul, stocul, SKU-ul și imaginea trebuie să descrie varianta verde.

Organization

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Compania Exemplu",
  "url": "https://exemplu.ro/",
  "logo": "https://exemplu.ro/logo.png",
  "sameAs": [
    "https://www.linkedin.com/company/exemplu"
  ],
  "contactPoint": {
    "@type": "ContactPoint",
    "telephone": "+40-21-000-0000",
    "contactType": "customer service",
    "areaServed": "RO",
    "availableLanguage": ["ro", "en"]
  }
}
</script>

Organization descrie entitatea, nu fiecare pagină a site-ului. Implementarea principală trebuie să fie consecventă cu informațiile de contact și identitate publicate.

WebSite și numele site-ului

{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "url": "https://exemplu.ro/",
  "name": "Exemplu",
  "alternateName": "Compania Exemplu"
}

Google poate folosi markupul WebSite

LocalBusiness

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "ProfessionalService",
  "name": "Compania Exemplu București",
  "url": "https://exemplu.ro/bucuresti/",
  "telephone": "+40-21-000-0000",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Strada Exemplu 10",
    "addressLocality": "București",
    "postalCode": "010101",
    "addressCountry": "RO"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 44.4268,
    "longitude": 26.1025
  },
  "openingHoursSpecification": [{
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": [
      "Monday",
      "Tuesday",
      "Wednesday",
      "Thursday",
      "Friday"
    ],
    "opens": "09:00",
    "closes": "18:00"
  }]
}
</script>

Nu crea markup local pentru locații virtuale sau adrese la care compania nu operează.

Service

Schema.org acceptă tipul Service, dar nu orice implementare produce o funcționalitate specială în Google. Poate fi folosit pentru semantică, fără promisiunea unui rich result.

{
  "@context": "https://schema.org",
  "@type": "Service",
  "name": "Audit SEO tehnic",
  "provider": {
    "@type": "Organization",
    "name": "Compania Exemplu"
  },
  "areaServed": "RO",
  "serviceType": "Audit SEO tehnic"
}

Article

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "SEO tehnic: ghid complet",
  "image": [
    "https://exemplu.ro/seo-tehnic-16x9.jpg"
  ],
  "datePublished": "2026-07-31",
  "dateModified": "2026-07-31",
  "author": {
    "@type": "Person",
    "name": "Numele autorului"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Exemplu"
  }
}

dateModified trebuie actualizat după o revizie reală, nu automat la fiecare încărcare a paginii.

BreadcrumbList

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Acasă",
      "item": "https://exemplu.ro/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "SEO",
      "item": "https://exemplu.ro/seo/"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "SEO tehnic"
    }
  ]
}

FAQPage

Markupul FAQ nu trebuie implementat doar pentru a ocupa mai mult spațiu în rezultate. Eligibilitatea Google este limitată și poate fi modificată. Întrebările și răspunsurile trebuie să fie vizibile pe pagină.

VideoObject și ImageObject

Pentru videoclipurile și imaginile importante pot fi folosite tipurile corespunzătoare, dacă informațiile sunt reale și complete. Markupul nu înlocuiește accesibilitatea fișierelor, thumbnailurile, transcrierea sau contextul textual.

Validare și monitorizare

scrie markupul;
verifică concordanța cu pagina;
testează în Rich Results Test;
verifică în Schema.org Validator;
publică gradual;
monitorizează Search Console;
retestează după schimbări de template.

SEO tehnic pentru magazine online

Pentru un magazin online, SEO tehnic trebuie analizat la nivelul întregului catalog și al fiecărui șablon. O eroare într-un template de produs se poate propaga la mii de URL-uri.

Categoriile

O categorie trebuie să aibă:

URL stabil;
title și H1 clare;
produse accesibile prin linkuri;
conținut suficient pentru orientare;
canonical propriu;
paginare crawlable;
filtre controlate;
breadcrumb;
imagini optimizate;
linkuri către subcategorii.

Conținutul categoriei trebuie să ajute utilizatorul să înțeleagă selecția, diferențele și criteriile de alegere. Un paragraf generic repetat pe zeci de categorii nu creează diferențiere reală.

Produsele

un URL stabil;
nume unic;
descriere utilă;
identificatori corecți;
preț și stoc actualizate;
imagini clare;
date structurate;
variante gestionate coerent;
alternative pentru indisponibilitate;
recenzii reale;
link către categorie.

Căutarea internă

Rezultatele căutării interne nu trebuie indexate automat. Pot genera pagini aproape infinite și slab controlate.

Exemplu:

/cautare/?q=scaun
/cautare/?q=scaune
/cautare/?q=scaun+negru

Dacă astfel de URL-uri sunt indexabile, magazinul poate genera mii de pagini subțiri, instabile și duplicate.

Feedul Merchant Center

Feedul și pagina trebuie să fie consecvente pentru:

preț;
monedă;
stoc;
identificatori;
URL;
imagini;
condiție;
livrare;
retur.

Diferențele dintre feed, Schema.org și pagina vizibilă pot produce respingeri, informații neactualizate sau pierderea eligibilității pentru anumite suprafețe comerciale.

Produse sezoniere

Dacă pagina revine anual și păstrează aceeași intenție, este mai eficient să fie menținut URL-ul și actualizat conținutul decât să fie creat un URL nou în fiecare sezon.

Pagini fără produse

Decizia depinde de situație:

temporar fără stoc: păstrează pagina și oferă alternative;
categorie eliminată definitiv: redirect către un înlocuitor sau 404;
filtru gol: nu trebuie indexat;
categorie strategică în curs de reaprovizionare: păstrează utilitatea informațională.

Recenziile

Recenziile trebuie să fie vizibile, reale și asociate produsului corect. Filtrarea automată a recenziilor negative sau generarea artificială a unui scor poate induce în eroare utilizatorii și motoarele de căutare.

Trackingul comercial

Problemele tehnice nu se limitează la indexare. Un magazin poate lua decizii greșite dacă:

tranzacțiile sunt duplicate;
retururile nu sunt reconciliate;
venitul include sau exclude transportul în mod inconsistent;
moneda este raportată greșit;
consimțământul produce diferențe neînțelese;
checkoutul rulează pe alt domeniu și pierde sesiunea.

Exemplu complet de diagnostic e-commerce

Un magazin cu 35.000 de produse observă că numai 9.000 sunt indexate. Nu trebuie presupus automat că problema este crawl budgetul.

Diagnosticul poate arăta astfel:

12.000 de produse nu primesc linkuri din categorii;
5.000 au canonical către produsul părinte;
4.000 sunt fără stoc și returnează soft 404;
3.000 sunt variante aproape identice;
2.000 sunt blocate de o regulă robots.txt;
o parte dintre URL-uri nu au conținut distinct;
filtrele generează 800.000 de URL-uri suplimentare.

Soluția nu este „trimite din nou sitemapul”. Sunt necesare intervenții diferite pentru arhitectură, variante, stoc, canonicalizare și controlul filtrelor.

SEO tehnic pentru site-uri de servicii și afaceri

Site-urile de servicii au, de regulă, mai puține URL-uri decât magazinele, dar problemele lor pot afecta direct generarea de lead-uri.

Paginile de servicii

Fiecare serviciu trebuie să aibă o promisiune și un conținut distinct. Nu este suficientă schimbarea H1-ului și a câtorva substantive.

O pagină de serviciu trebuie să explice:

problema rezolvată;
pentru cine este serviciul;
ce include;
cum se desfășoară;
ce date sau acces sunt necesare;
ce rezultate poate și nu poate garanta;
ce dovezi și exemple există;
cum poate fi contactată compania.

Paginile locale

O pagină locală trebuie să conțină informații reale:

adresă sau zonă deservită;
echipă sau responsabil;
servicii disponibile;
program;
date de contact;
studii de caz locale;
condiții sau particularități regionale;
LocalBusiness, unde este justificat.

Studiu de caz: 1.440 de pagini programatice

O companie are 12 servicii, 8 industrii și 15 orașe. Prin combinare generează 1.440 de pagini.

Înainte de publicare trebuie verificat:

există cerere distinctă;
serviciul chiar este disponibil;
există informații locale;
pagina poate fi diferențiată;
există dovadă sau experiență relevantă;
pagina nu canibalizează serviciul principal;
echipa poate menține datele;
conversia poate fi măsurată.

Dacă răspunsul este negativ pentru majoritatea criteriilor, combinația produce volum de URL-uri, nu valoare.

Formularele

Un formular poate afecta rezultatul comercial chiar dacă nu influențează direct indexarea.

Verifică:

funcționează pe mobil;
nu depinde de scripturi blocate;
mesajele de eroare sunt clare;
pagina de confirmare nu este indexabilă;
conversia este măsurată o singură dată;
consimțământul este gestionat corect;
datele sunt transmise securizat.

PDF-uri

Broșurile, cataloagele și documentația pot fi indexate. Pentru control se poate folosi X-Robots-Tag. Dacă informația este importantă pentru căutare, o pagină HTML este de regulă mai ușor de integrat în arhitectură și măsurare.

Staging

Un mediu de test nu trebuie protejat doar prin robots.txt. Soluția robustă este autentificarea. Un staging indexat poate genera duplicate și poate expune informații.

Subdomenii și platforme externe

Formularele, blogurile, centrele de ajutor și aplicațiile pot rula pe subdomenii sau platforme separate. Trebuie verificat:

dacă sunt indexabile;
dacă au canonical corect;
dacă utilizatorul păstrează continuitatea navigării;
dacă analytics și conversiile traversează domeniile;
dacă informațiile importante sunt fragmentate inutil.

Hreflang și site-uri internaționale

<link rel="alternate"
      hreflang="ro"
      href="https://exemplu.ro/ro/seo-tehnic/">

<link rel="alternate"
      hreflang="en"
      href="https://exemplu.ro/en/technical-seo/">

<link rel="alternate"
      hreflang="x-default"
      href="https://exemplu.ro/">

Reguli:

URL-urile trebuie să fie indexabile;
referințele trebuie să fie reciproce;
canonicalul rămâne, de regulă, în aceeași limbă;
limba și regiunea trebuie declarate corect;
nu redirecționa forțat exclusiv după IP;
oferă selector de limbă;
folosește URL-uri separate.

O pagină în română nu trebuie să aibă canonical către versiunea engleză doar pentru că engleza este considerată versiunea „principală”. Hreflang și canonical rezolvă probleme diferite.

Crawl budget și analiza logurilor

Crawl budget devine relevant mai ales pentru site-uri mari, actualizate frecvent sau cu spații extinse de URL-uri.

Semnale:

milioane de URL-uri;
multe filtre;
parametri infiniți;
crawling pe pagini fără valoare;
produse noi descoperite greu;
server lent sau instabil;
multe pagini „Discovered – currently not indexed”.

Pentru un site cu câteva sute de pagini, problema principală este rareori crawl budgetul. Este mai probabil să existe probleme de conținut, arhitectură, canonicalizare sau linking.

Ce arată logurile

ce URL-uri solicită Googlebot;
cât de des;
ce coduri primește;
ce tipuri de pagini sunt ignorate;
unde apar erori;
cât durează răspunsul;
ce crawlere consumă resurse.

Trebuie verificată autenticitatea botului, nu doar user-agentul declarat. Un crawler rău intenționat poate folosi un user-agent care pretinde că este Googlebot.

HTTPS, securitate și disponibilitate

Site-ul trebuie să folosească HTTPS consecvent.

Verificări:

certificat valid;
redirect HTTP către HTTPS;
canonical HTTPS;
sitemap HTTPS;
fără conținut mixt;
resurse interne pe HTTPS;
HSTS, unde este implementat corect;
fără bucle de redirect;
monitorizare uptime;
backup și plan de recuperare.

Un site compromis poate genera spam, pagini false și redirecturi. Search Console și monitorizarea modificărilor trebuie incluse în procesul tehnic.

Mentenanța temporară

Pentru o oprire temporară este mai potrivit un răspuns 503 Service Unavailable, eventual cu header Retry-After, decât transformarea tuturor paginilor în 404 sau redirectarea lor către o pagină generică.

Migrarea site-urilor

Migrarea poate însemna schimbarea domeniului, CMS-ului, structurii URL, designului sau protocolului.

Înainte de lansare

inventar complet de URL-uri;
trafic și conversii pe URL;
backlinkuri;
mapare URL vechi–nou;
baseline de indexare și Core Web Vitals;
testarea robots, canonical, sitemap și hreflang;
backup;
plan de revenire;
verificarea trackingului;
testarea redirecturilor.

La lansare

eliminarea noindex și a blocajelor de staging;
activarea redirecturilor;
actualizarea linkurilor interne;
publicarea sitemapurilor;
verificarea Search Console;
testarea paginilor importante;
monitorizarea erorilor și serverului.

După lansare

crawl complet;
verificarea redirecturilor;
monitorizarea 404;
compararea traficului pe tipuri de pagini;
urmărirea canonicalizării;
analiza logurilor;
păstrarea redirecturilor pe termen lung.

Ce trebuie evitat

schimbarea simultană a domeniului, CMS-ului, conținutului și arhitecturii fără necesitate;
redirecturi toate către homepage;
eliminarea paginilor cu trafic fără înlocuitor;
păstrarea linkurilor interne către vechile URL-uri;
lansarea fără verificarea trackingului;
eliminarea redirecturilor după câteva săptămâni.

Cum faci un audit SEO tehnic complet

1. Definește obiectivul

Exemple:

categorii neindexate;
scădere după migrare;
produse descoperite greu;
trafic organic fără lead-uri;
site lent pe mobil;
diferențe între sitemap și index.

Un audit fără o întrebare inițială riscă să producă o listă mare de observații fără prioritate.

2. Construiește inventarul

Combină crawler, sitemap, Search Console, analytics, CMS, backlinkuri și loguri.

3. Clasifică URL-urile

homepage;
categorii;
produse;
servicii;
articole;
locații;
filtre;
paginare;
căutare;
cont și utilitare.

4. Verifică accesul și indexabilitatea

robots.txt;
meta robots;
X-Robots-Tag;
cod HTTP;
canonical;
conținut;
duplicare;
soft 404.

5. Verifică arhitectura

pagini orfane;
adâncime;
anchor text;
linkuri rupte;
redirecturi interne;
breadcrumb;
paginare;
filtre.

6. Verifică randarea

HTML inițial;
DOM randat;
URL Inspection;
erori JavaScript;
API-uri;
resurse blocate;
metadate dinamice.

7. Verifică performanța

date reale;
laborator;
TTFB;
LCP;
INP;
CLS;
imagini;
CSS;
JavaScript;
fonturi;
third-party scripts.

8. Verifică Schema.org

tip corect;
proprietăți obligatorii;
concordanță cu pagina;
produse și variante;
stoc și preț;
organizație și locații;
breadcrumb;
erori la nivel de template.

9. Verifică măsurarea

Search Console configurat;
analytics funcțional;
conversii neduplicate;
cross-domain tracking;
consimțământ;
parametri de campanie;
date comerciale reconciliate.

10. Prioritizează

O formulă orientativă:

Prioritate = impact × acoperire × încredere ÷ efort și risc

Problemă	Impact	Prioritate
Toate categoriile au noindex	Pagini comerciale excluse	Critică
1,4 milioane de filtre crawlable	Inventar diluat și crawling inutil	Ridicată
Produsele nu au alt text	Accesibilitate și imagini afectate	Medie
Warning opțional în schema Article	Impact redus	Scăzută

Cum faci articolul și site-ul eligibile pentru citări AI

Nu există o optimizare separată care să garanteze selecția în AI Overviews sau AI Mode. Google recomandă aceleași elemente fundamentale folosite pentru Search:

pagina să fie indexabilă;
crawlingul să nu fie blocat;
conținutul important să existe în formă textuală;
linkurile interne să facă pagina ușor de descoperit;
imaginile și videoclipurile să susțină explicația;
datele structurate să corespundă informațiilor vizibile;
Merchant Center și Business Profile să fie actualizate;
pagina să fie eligibilă pentru snippet.

Pentru citabilitate, conținutul trebuie să ofere pasaje autonome și verificabile. O propoziție precum „canonicalul este important” este slabă. Un răspuns mai ușor de folosit este:

Canonicalul este un semnal prin care un site indică URL-ul preferat dintre pagini identice sau foarte asemănătoare; el nu redirecționează utilizatorul și nu obligă Google să selecteze varianta declarată.

Articolele tehnice trebuie să separe explicit:

regula confirmată de documentația oficială;
recomandarea practică;
exemplul ipotetic;
interpretarea Semantik;
limita dovezii.

Checklist pentru magazine online

categoriile sunt accesibile prin linkuri;
produsele sunt accesibile din categorii;
filtrele sunt controlate;
paginarea are URL-uri proprii;
fiecare pagină are canonical corect;
produsele eliminate au strategie;
variantele sunt consecvente;
sitemapul conține URL-uri canonice;
prețul și stocul coincid în pagină, schema și feed;
Product și Offer sunt valide;
imaginile sunt responsive;
imaginea principală nu este lazy-loaded;
căutarea internă nu generează indexare necontrolată;
Core Web Vitals sunt evaluate pe șabloane;
checkoutul și contul nu apar în index;
produsele importante primesc linkuri interne;
trackingul nu dublează tranzacțiile;
versiunea mobilă conține toate datele comerciale;
Merchant Center și pagina sunt sincronizate;
recenziile și ratingurile sunt reale.

Greșeli frecvente

robots.txt este folosit pentru noindex;
canonicalul este tratat ca o comandă absolută;
toate 404 sunt redirecționate către homepage;
paginile 2, 3 și 4 au canonical către pagina 1;
infinite scroll nu are URL-uri;
filtrele generează spații infinite;
sitemapul include redirecturi și noindex;
titlurile sunt duplicate;
headingurile sunt folosite doar pentru design;
alt textul este umplut cu keywords;
imaginea LCP este lazy-loaded;
Schema.org descrie informații inexistente;
ratingurile sunt inventate sau înșelătoare;
versiunea mobilă are mai puțin conținut;
JavaScript-ul generează linkuri fără href;
migrarea este lansată fără mapare;
warningurile sunt tratate ca probleme critice;
SEO tehnic este separat de obiectivele afacerii;
se presupune că un fișier special pentru AI garantează citarea;
se optimizează densitatea cuvântului-cheie în detrimentul clarității.

Ce nu poate rezolva SEO tehnic

SEO tehnic nu poate compensa permanent:

un produs fără cerere;
o ofertă necompetitivă;
conținutul superficial;
intenția interpretată greșit;
lipsa diferențierii;
pagini create doar pentru variante de cuvinte-cheie;
lipsa autorității;
o experiență comercială slabă;
prețuri și procese care nu susțin conversia.

Corectarea unei probleme tehnice nu produce întotdeauna o creștere imediată. Paginile trebuie recrawl-uite și reevaluate, iar problema tehnică poate fi doar una dintre explicații.

SEO tehnic este infrastructura care permite motoarelor de căutare să descopere, acceseze, randze, indexeze și interpreteze corect paginile unui site. Pentru magazine online, înseamnă controlul categoriilor, produselor, filtrelor, variantelor, imaginilor, feedurilor și datelor comerciale. Pentru site-uri de servicii, înseamnă arhitectură clară, pagini diferențiate, locații reale, formulare funcționale și trasee coerente între conținut și conversie.

Un audit bun nu urmărește să elimine fiecare warning. El identifică blocajele care afectează paginile importante, separă cauza de simptom și prioritizează intervențiile după impact, acoperire, certitudine, efort și risc.

Un site sănătos tehnic nu primește automat vizibilitate și nici nu este garantat că va fi citat într-un răspuns AI. Dar un site cu probleme de crawling, indexare, canonicalizare, randare sau performanță poate împiedica motoarele de căutare să evalueze chiar și conținutul foarte bun. Diagnosticul trebuie să înceapă cu traseul complet al paginii și să se încheie cu efectul asupra traficului, conversiilor, marjei și rezultatelor comerciale.

Pentru un site cu probleme de indexare, arhitectură complexă, filtre, JavaScript sau o migrare cu risc, o analiză SEO, AEO și GEO poate clarifica problemele tehnice și ordinea intervențiilor înaintea unor modificări ample.

Surse și lecturi suplimentare

Google Search Central: cerințe tehnice pentru Google Search — condițiile minime de acces, funcționare și indexabilitate.
Google Search Central: funcțiile AI și site-ul tău — eligibilitatea pentru AI Overviews și AI Mode, controalele de preview și măsurarea în Search Console.
Google Search Central: crawling și indexare — documentația oficială despre descoperire, procesare și indexare.
Google Search Central: ghid SEO pentru dezvoltatori — HTML, JavaScript, metadate și conținut textual.
Google Search Central: bune practici pentru e-commerce — structură, produse, date comerciale și lansarea magazinelor.
Google: structura magazinelor online — linking între categorii, subcategorii și produse.
Google: structura URL-urilor e-commerce — parametri, variante și URL-uri persistente.
Google: paginare, load more și infinite scroll — URL-uri distincte și linkuri crawlable.
Google: robots.txt — rol, sintaxă și limite.
Google: noindex — meta robots și X-Robots-Tag.
Google: canonicalizarea URL-urilor — semnale, implementare și contradicții.
Google: redirecturi — metode permanente și temporare.
Google: title links — sursele titlurilor, rescriere și bune practici.
Google: snippets și meta descriptions — generarea fragmentelor și controalele disponibile.
Google: optimizarea imaginilor — accesibilitate, alt text și descoperirea imaginilor.
Google: Core Web Vitals — LCP, INP și CLS.
Google: introducere în date structurate — eligibilitate, concordanță și validare.
Google: tipuri de date structurate acceptate — funcționalitățile Search care folosesc structured data.
Google: date structurate pentru e-commerce — Product, BreadcrumbList, LocalBusiness și alte tipuri relevante.
Google: migrarea site-urilor — planificarea și monitorizarea schimbărilor de URL.

Continuă analiza

Trafic organic: cum îl măsori și cum îl transformi în rezultate comerciale — pentru legătura dintre vizibilitate, clickuri și performanța afacerii.
Canibalizare SEO — pentru suprapunerea dintre pagini, categorii și intenții de căutare.
llms.txt și vizibilitatea în AI — pentru delimitarea dintre standarde tehnice confirmate și soluții cu efect nedemonstrat.