Audit SEO tehnic: Cum verificați și remediați erorile de crawl

Audit SEO tehnic: Cum verificați și remediați erorile de crawl, adică tot ce împiedică Google să acceseze, să înțeleagă și să indexeze corect paginile: blocaje în robots.txt, erori de server, redirecționări în lanț, canonicale greșite, resurse inaccesibile, adrese duplicate. Sunt invizibile pentru vizitatori și pot ține jumătate din site în afara indexului luni de zile. Ghidul descrie procedura pe care o aplicăm la fiecare site nou, pe arii, cu uneltele, cu erorile frecvente și cu prioritizarea remediilor după efect.

Un audit tehnic nu aduce trafic singur; este fundația: conținutul bun și legăturile nu produc nimic pe pagini pe care Google nu le vede. De aceea îl facem înaintea oricărei lucrări de conținut.

Audit SEO tehnic: Cum verificați și remediați erorile de crawl

Uneltele

• Search Console: raportul de indexare a paginilor, statisticile de accesare, inspecția adreselor, Core Web Vitals; sursa de adevăr, gratuită.
• Un crawler propriu (Screaming Frog, gratuit până la 500 de adrese; Sitebulb; sau analizorul de site GOAI pentru verificările de bază): titluri, descrieri, coduri, canonicale, legături, adâncime.
• curl din terminal, pentru antete, redirecționări și răspunsuri per user agent.
• Jurnalele serverului, pentru ce face Googlebot de fapt.
• PageSpeed Insights și Lighthouse, pentru viteză și randare.
• Validatorul de date structurate și scanerul de antete, pentru markup și securitate.

Aria 1: accesul

1. robots.txt: există, e static, nu blochează CSS, JavaScript, imagini sau secțiuni de conținut; regulile cu joker sunt verificate în raportul robots.txt din Search Console. Un Disallow: / uitat de la dezvoltare este cea mai scumpă greșeală.
2. Firewall și servicii de protecție: Googlebot (verificat după adresa IP) primește 200, nu 403 sau pagini de verificare; testul live din Search Console arată ce a primit. Am întâlnit repetat servicii de protecție care serveau roboților un ecran de verificare cu cod 200, indexat ca „pagină”.
3. Viteza serverului: timpul mediu de răspuns din statisticile de accesare sub 300 ms; erorile 5xx la zero; capacitatea de accesare depinde de ele.
4. DNS și certificat: fără erori de gazdă în statisticile de accesare; certificat valid pe toate numele.

Aria 2: indexarea

1. Raportul de indexare a paginilor, cu filtrul pe paginile trimise: fiecare motiv de neindexare cu lista lui; interpretarea este în ghidul despre rapoartele de acoperire.
2. noindex neintenționat: crawlerul listează paginile cu meta robots noindex sau cu antet X-Robots-Tag; comparați cu ce vreți indexat.
3. Canonicalele: fiecare pagină indexabilă cu canonical spre ea însăși; variantele (parametri, filtre) spre principală; niciun canonical spre prima pagină sau spre http.
4. Duplicatele: variante de adresă (slash, majuscule, www, http), parametri, paginare, versiuni de tipărire; remediile sunt în ghidul despre conținutul duplicat.
5. Paginile subțiri și soft 404: pagini cu sub 100 de cuvinte, categorii goale, rezultate de căutare; noindex sau consolidare.
6. Hreflang, pentru site-uri în mai multe limbi: reciproc, cu coduri corecte, cu canonical propriu pe fiecare versiune.

Aria 3: adresele și redirecționările

1. O singură versiune canonică a domeniului, cu redirecționare directă (o săritură) de la toate celelalte; curl -IL pe fiecare variantă.
2. Lanțuri și bucle: crawlerul le listează; fiecare lanț se scurtează la o săritură.
3. Legături interne spre redirecționări și spre 404: rescrise spre destinația finală; pe blogul nostru, consolidarea a 13 perechi de articole a cerut rescrierea a 179 de legături interne în aceeași zi.
4. Adrese vechi după migrări: fiecare cu 301 spre echivalentul nou; cele fără echivalent, 410.
5. Structura adreselor: scurte, cu cuvinte, fără parametri în legăturile interne.

Aria 4: randarea și resursele

1. HTML-ul randat din inspecția adresei conține conținutul principal, titlurile, legăturile; ce apare doar după JavaScript executat târziu sau după interacțiune nu este văzut.
2. Resursele (CSS, JavaScript, imagini, fonturi) accesibile lui Googlebot, de pe domenii care nu îl blochează.
3. Paginile grele: sub 2-3 MB și sub 100 de cereri; imaginile la dimensiune, cu srcset.
4. Core Web Vitals pe mobil, din datele reale: LCP sub 2,5 secunde, INP sub 200 de milisecunde, CLS sub 0,1; remediile sunt în articolul despre optimizarea Core Web Vitals.

Aria 5: harta, structura și legăturile interne

1. Harta XML: doar adrese 200, canonice, indexabile; lastmod real; trimisă și cu stare Success; regulile sunt în ghidul despre trimiterea hărții XML.
2. Adâncimea: paginile importante la cel mult trei clicuri de prima pagină; crawlerul raportează adâncimea.
3. Paginile orfane: în hartă, dar fără nicio legătură internă; se leagă sau se elimină.
4. Meniul și subsolul: complete pe mobil, fără legături spre redirecționări.
5. Ancorele: descriptive, nu „aici”.

Aria 6: jurnalele

Jurnalul de acces filtrat după Googlebot verificat spune ce accesează Google de fapt: proporția de cereri spre pagini utile față de parametri și adrese inutile, codurile de răspuns, frecvența pe secțiuni. Pe site-uri mari, este singura sursă pentru bugetul de accesare; metoda este în articolul despre bugetul de accesare, iar citirea jurnalelor pe cPanel, în ghidul despre jurnalele de erori și acces.

Erorile pe care le găsim cel mai des

Eroare	Frecvență la audituri	Efect	Remediu
Legături interne spre redirecționări	aproape toate site-urile	buget irosit, semnale diluate	rescriere spre destinație
Duplicate de adresă (slash, www, parametri)	majoritatea	canonice alese greșit	redirecționări și canonical
noindex sau blocare accidentală	una din cinci	pagini întregi lipsă din index	corectare și cerere de indexare
Harta cu adrese moarte sau redirecționate	jumătate	avertismente, buget irosit	regenerare din date curente
Roboți blocați de protecție	una din zece, în creștere	indexare oprită sau conținut greșit	excepții pentru roboții verificați
Site de test indexat	una din zece	duplicat al producției	parolă, apoi eliminare
LCP peste 4 secunde pe mobil	jumătate	experiență slabă, accesare redusă	imagini, cache, scripturi

Un audit tehnic, pe un exemplu

Un magazin cu 3.000 de produse și trafic organic în scădere lentă de un an. Accesul: robots.txt corect, dar serviciul de protecție bloca Googlebot pe paginile de categorie cu filtre (403 în jurnale, cu tiparul „prea multe cereri”). Indexarea: 28.000 de adrese cunoscute, 2.600 indexate; 19.000 în duplicate fără canonical (produsul în trei categorii, plus sortări). Adresele: două redirecționări pentru http și www, în lanț; 1.200 de legături interne spre redirecționări. Randarea: prețurile și disponibilitatea aduse prin JavaScript după încărcare, invizibile în HTML-ul randat pentru jumătate din produse. Harta: 4.000 de adrese, dintre care 900 redirecționate. Prioritizarea: excepția pentru Googlebot în protecție (ziua 1), canonicalele și noindex pe sortări (săptămâna 1), redirecționarea într-o săritură și rescrierea legăturilor (săptămâna 2), prețurile în HTML (luna 1), harta regenerată (săptămâna 1). La două luni, adresele indexate au coborât la 3.400 (produse și categorii), iar afișările pe produse au crescut cu 45%; niciun conținut nou.

Uneltele proprii pentru verificări repetate

Un script de 30 de rânduri cu curl, rulat săptămânal din cron, verifică pentru lista paginilor principale: codul de răspuns, prezența meta robots noindex, canonical-ul, antetul Content-Type, timpul de răspuns, și trimite e-mail doar la abateri. Un al doilea script compară harta site-ului cu răspunsurile reale ale adreselor din ea, lunar. Pe site-urile pe care le administrăm, aceste două scripturi au prins un noindex apărut după o actualizare de modul și o buclă de redirecționare după o schimbare de DNS, în aceeași săptămână, înainte de orice raport din Search Console; costul lor a fost o oră de scris, o singură dată.

Prioritizarea

1. Ce oprește indexarea (blocaje, noindex, 5xx, roboți blocați): azi.
2. Ce dublează sau diluează (duplicate, canonicale, redirecționări interne): săptămâna aceasta.
3. Ce încetinește (viteză, resurse, pagini grele): luna aceasta.
4. Ce îmbunătățește descoperirea (hartă, structură, orfane): luna aceasta.
5. Ce ține de igienă (antete, date structurate, hreflang): în următoarele două luni.

Fiecare remediere se verifică: inspecția adresei după corectare, validarea din raportul de indexare, comparația statisticilor de accesare la două săptămâni.

Întrebări frecvente

1. Cât durează un audit tehnic? Pentru un site de firmă, o zi; pentru un magazin cu mii de pagini, două-trei, plus jurnalele.
2. Pot face auditul singur? Verificările de bază, da, cu Search Console și un crawler gratuit; interpretarea și prioritizarea sunt partea care cere experiență.
3. Cât de des? Trimestrial, plus după fiecare lansare; verificările automate săptămânale acoperă între audituri.

Menținerea

• Verificare automată săptămânală a paginilor principale (cod 200, fără noindex, canonical corect), dintr-un script cu curl, cu alertă pe e-mail.
• Raportul de indexare și statisticile de accesare, lunar.
• Audit complet trimestrial și după orice lansare (temă, module, migrare).
• Jurnalul schimbărilor pe site, ca erorile să poată fi legate de cauză.

Lista completă a erorilor de indexare, cu diagnosticul și remediul fiecăreia, este în articolul despre erorile de indexare frecvente; pentru WordPress, particularitățile sunt în ghidul despre SEO tehnic pentru WordPress. Auditul de mai sus, aplicat pe site-ul dumneavoastră și livrat ca listă de priorități, este serviciul nostru de SEO tehnic.

Surse

• Ajutor Search Console, raportul de indexare a paginilor: stările și motivele de neindexare.
• Google, codurile de stare HTTP și erorile de rețea: cum tratează Google fiecare cod și eroare de conectare.