Audit tehnic SEO: ce verifică pas cu pas și ce primești la final

Ce este un audit tehnic SEO și prin ce diferă de restul

Un audit tehnic SEO răspunde la o întrebare simplă: poate Google să ajungă la paginile tale, să le citească și să înțeleagă care dintre ele contează? Nu judecă dacă textele sunt bune sau dacă ai destule linkuri din alte site-uri. Se uită la fundație. Dacă fundația e strâmbă, tot ce construiești deasupra lucrează în pierdere. Și, spre deosebire de conținut, problemele tehnice afectează de obicei zeci de pagini deodată, nu una singură.

Diferența față de un audit de conținut e ușor de explicat. Auditul de conținut întreabă dacă pagina răspunde bine la ce caută omul. Auditul tehnic întreabă dacă pagina ajunge măcar în fața lui Google în forma corectă. În practică, auditul tehnic e primul pas dintr-un proiect de optimizare SEO, pentru că îți spune ce trebuie reparat înainte să investești în articole noi.

Mai jos luăm verificările pe rând, în ordinea în care le facem noi. La fiecare punem și un exemplu real, găsit pe propriul nostru site. Nu pentru că ne place să ne arătăm greșelile, ci pentru că sunt exact tipul de probleme care nu se văd cu ochiul liber și pe care un audit bun le prinde. Toate au fost reparate, iar reparațiile le descriem pe scurt la fiecare pas.

Pasul 1: indexarea și accesul roboților

Primul lucru verificat e dacă paginile importante sunt în indexul Google. Sursa de încredere aici e raportul de indexare a paginilor din Search Console, nu o căutare cu site: în Google. Raportul îți arată ce pagini sunt indexate și, pentru restul, motivul: eroare 404, pagină marcată noindex, blocată prin robots.txt, duplicat fără canonical ales de tine, sau „accesată, momentan neindexată”.

Google spune clar în documentație că nu trebuie să te aștepți ca toate adresele de pe site să fie indexate, ci doar paginile canonice. Deci nu te sperii de o listă de pagini neindexate. Te uiți dacă printre ele e vreo pagină care aduce bani. Acolo începe munca. Dacă pagina de serviciu principală apare cu „accesată, momentan neindexată”, asta e o problemă. Dacă apar paginile de filtre sau adresele cu parametri, de multe ori e exact comportamentul pe care îl vrei.

Exemplul nostru: pe 16 septembrie 2026, Search Console ne-a trimis un mail cu o eroare „Not found (404)” pentru o adresă de forma /blog/cat-costa-un-site-de-prezentare. Pagina aia nu exista și nu era legată de nicăieri din meniu sau din text. Cauza era în datele structurate: fiecare articol declara în schema de breadcrumb o adresă /blog/nume-articol, când articolele stau de fapt la /blog-nume-articol. Google urmează și adresele din schemă, nu doar linkurile vizibile. Am corectat adresa din schemă, am pus redirect 301 pentru orice adresă veche de acel tip și am extins verificarea noastră automată de linkuri ca să citească și adresele din JSON-LD.

Pasul 2: canonical, redirecturi și pagini duplicate

Aproape orice site are mai multe adrese care duc la același conținut: cu și fără www, cu și fără bară la final, cu parametri de urmărire. Google alege una dintre ele ca versiune principală. Rolul tău e să-i dai semnale care spun același lucru. Documentația Google descrie redirectul ca pe un semnal puternic, tag-ul canonical tot ca pe un semnal puternic, iar sitemap-ul ca pe unul slab. Și avertizează explicit să nu indici adrese canonice diferite pentru aceeași pagină prin metode diferite.

Exact asta găsisem pe vechea versiune a site-ului nostru, în auditul făcut pe 6 septembrie 2026. Toate paginile din sitemap, mai puțin prima, erau listate fără bară la final. Serverul le redirecționa cu 301 spre varianta cu bară. Iar pagina cu bară avea tag-ul canonical îndreptat înapoi spre varianta fără bară. Trei semnale, două direcții. Pentru Google e ca și cum i-ai spune „du-te acolo” și, când ajunge, „de fapt, întoarce-te”.

Reparația nu e complicată, dar trebuie făcută în toate cele trei locuri deodată: adresa din sitemap, ținta redirectului și canonical-ul trebuie să fie aceeași adresă, caracter cu caracter. În site-ul refăcut am legat toate trei de o singură regulă de construire a adreselor, ca să nu mai poată diverge. Apoi am verificat pe site-ul publicat că fiecare adresă din sitemap răspunde direct cu 200, fără niciun redirect pe drum.

Pasul 3: viteza și Core Web Vitals

Core Web Vitals sunt trei măsurători pe care Google le folosește ca să descrie experiența reală pe pagină. Pragurile recomandate de Google sunt: LCP, adică momentul în care apare elementul principal, sub 2,5 secunde; INP, adică cât de repede reacționează pagina la un clic, sub 200 de milisecunde; CLS, adică cât sare conținutul în timp ce se încarcă, sub 0,1. Google spune că aceste măsurători se aliniază cu ce urmăresc să recompenseze sistemele lui de clasare, alături de alte aspecte ale experienței pe pagină.

Într-un audit nu te oprești la scorul din PageSpeed. Măsori pe telefon, cu cache gol și cu viteză și procesor limitate, pe mai multe tipuri de pagini, nu doar pe prima. Apoi cauți cauza fiecărei probleme, pentru că scorul singur nu repară nimic. Un site poate avea un scor bun pe prima pagină și probleme serioase pe articole sau pe paginile de produs. De aceea alegem câte o pagină din fiecare tip de șablon și le măsurăm pe toate, de mai multe ori, ca să nu tragem concluzii dintr-o singură rulare.

Exemplul nostru, din septembrie 2026: încărcarea era bună, dar conținutul sărea. Pe prima pagină am măsurat un CLS de 0,117, peste limita de 0,1. Cauza era bannerul de cookie-uri, care apărea înainte să se încarce fonturile și apoi se rearanja, împingând textul. Web.dev enumeră exact acest tip de cauză printre cele frecvente: fonturi care se afișează mai mari sau mai mici decât varianta de rezervă și elemente adăugate în pagină după conținutul existent. Am mutat apariția bannerului după încărcarea fonturilor. Măsurat pe site-ul live după publicare, CLS-ul a coborât la 0,023.

Pasul 4: date structurate, titluri și versiuni de limbă

Datele structurate sunt bucăți de cod care îi spun lui Google explicit ce e pe pagină: o firmă, un serviciu, un articol, întrebări frecvente, un traseu de navigare. În audit verifici trei lucruri: dacă există, dacă tipul se potrivește cu pagina și dacă adresele din ele duc la pagini reale. Pentru validare, Google recomandă instrumentul Rich Results Test. Pe vechiul nostru site, paginile de servicii aveau doar o schemă generică de firmă locală, fără nicio descriere a serviciului, deși erau pagini comerciale.

Tot aici intră structura titlurilor. Fiecare pagină ar trebui să aibă un singur titlu principal, H1, care spune despre ce e pagina. Pe vechiul site, fiecare pagină avea două: titlul real și încă unul, identic pe tot site-ul, rămas într-o zonă ascunsă a codului. Omul nu îl vedea. Robotul da. Nu e o greșeală gravă, dar e genul de semnal amestecat care se adună cu altele și face pagina mai greu de înțeles.

Dacă site-ul are mai multe limbi, verifici și hreflang, eticheta care leagă între ele versiunile aceleiași pagini. Google cere ca fiecare versiune să se listeze pe ea însăși și pe toate celelalte, iar dacă legăturile nu sunt reciproce, pot fi ignorate. Recomandă și o versiune x-default pentru vizitatorii a căror limbă nu se potrivește cu niciuna. Pe site-ul nostru în cinci limbi am găsit o variantă mai subtilă a problemei: paginile în engleză aveau breadcrumb-ul din schemă îndreptat spre adresele în română.

Pasul 5: linkuri interne și ordinea verificărilor

Ultima parte e felul în care paginile se leagă între ele. Cauți pagini importante la care nu duce niciun link, linkuri interne spre adrese care redirecționează sau dau eroare și pagini care lipsesc din sitemap. Pe vechiul site, pagina de programări era generată, avea linkuri spre ea, dar lipsea din sitemap. O problemă mică, dar exact pagina pe care vrei să o găsească oamenii.

Verificarea asta se face cel mai bine automat, pe tot site-ul, nu pagină cu pagină, pentru că un om obosește după primele zeci de linkuri. Noi rulăm la fiecare publicare un script care urmărește toate linkurile interne, inclusiv cele din datele structurate, și nu publicăm nimic dacă găsește vreunul rupt. Pe scurt, ordinea în care lucrăm într-un audit tehnic arată așa:

• 01Indexare: raportul de indexare din Search Console, robots.txt, sitemap, erori 404 și soft 404.
• 02Adrese: redirecturi, canonical, versiuni cu și fără www sau bară finală, parametri.
• 03Viteză: LCP, INP și CLS măsurate pe telefon, pe mai multe tipuri de pagini, cu cauza fiecărei probleme.
• 04Cod: date structurate validate, un singur H1 pe pagină, titluri și descrieri unice.
• 05Limbi: hreflang reciproc, x-default, adrese corecte în fiecare limbă.
• 06Legături: linkuri interne rupte, pagini fără linkuri spre ele, pagini importante lipsă din sitemap.

Cât durează, ce primești la final și când merită

Durata depinde aproape numai de mărimea și complexitatea site-ului. Un site de prezentare cu câteva zeci de pagini se verifică mult mai repede decât un magazin online cu mii de produse, filtre și variante de adrese. Contează și dacă ai acces la Search Console: fără el, o bună parte din verificări devin ghicit, pentru că nu vezi ce vede Google. Din afară poți verifica totuși adresele, viteza și codul.

Ce ar trebui să primești la final nu e un scor și nici un PDF de 80 de pagini generat de un program. E o listă de probleme ordonate după impact, fiecare cu trei lucruri: unde apare, dovada, adică o captură, o măsurătoare sau un rând din raport, și reparația concretă. Bine e să primești și o verificare după reparații, pentru că multe probleme par rezolvate și nu sunt până nu le vezi confirmate în Search Console.

Merită să faci un audit tehnic când ai refăcut sau mutat site-ul, când ai adăugat o limbă nouă, când traficul organic scade fără o explicație evidentă sau când ai pagini bune care stau blocate pe a doua pagină din Google. Nu merită să-l repeți lunar pe un site mic care nu se schimbă. Acolo ajunge o privire periodică în Search Console.

Surse și lecturi.

• 01Google Search Central — Understanding Core Web Vitals and Google search results
• 02Google Search Central — How to specify a canonical URL with rel="canonical" and other methods
• 03Google Search Central — Tell Google about localized versions of your page
• 04Google Search Console Help — Page indexing report
• 05Google Search Central — Breadcrumb (BreadcrumbList) structured data
• 06web.dev — Cumulative Layout Shift (CLS)

Întrebări frecvente

Echipa The Niche SocietyIngineri AI și software din București · LinkedIn

publicat 2026-09-28