Screaming Frog este util într-un audit tehnic când îl folosești ca instrument de crawl, nu ca verdict. Îți arată cum se leagă paginile, ce răspunsuri dau URL-urile, ce directive blochează indexarea și unde apar probleme repetate. Decizia bună vine abia când pui datele lângă Search Console, Analytics și contextul site-ului.
Primim des site-uri unde auditul tehnic anterior era o listă exportată dintr-un tool. Roșu, galben, verde. Clientul a rămas cu impresia că are sute de probleme, dar nimeni nu i-a spus care țin traficul pe loc și care pot aștepta.
Asta e o abordare slabă. Un crawl nu este audit. Un crawl este radiografia brută. Auditul începe când alegi ce verifici întâi, ce ignori pentru moment și ce nu poți decide fără acces la Search Console, CMS sau server.
Screaming Frog SEO Spider este un crawler desktop folosit pentru audituri SEO tehnice. Pe scurt, intră pe site, urmează linkurile interne și salvează date despre URL-uri, status code-uri, titluri, canonical, meta robots, headinguri, imagini, paginare, sitemap și alte elemente care influențează felul în care Google poate descoperi și înțelege site-ul.
Pagina oficială Screaming Frog SEO Spider îl descrie ca pe un crawler pentru audit SEO. Formularea contează: crawler pentru audit, nu audit automat complet.
Ce face Screaming Frog într-un audit tehnic
Screaming Frog simulează o parte din comportamentul unui crawler: pornește de la un URL, urmărește linkurile interne și notează ce găsește. Asta ajută în audit tehnic pentru că multe probleme SEO nu se văd în browser, dar se văd imediat când analizezi site-ul ca rețea de URL-uri.
Mecanismul are trei pași simpli:
- Toolul cere paginile site-ului, la fel cum un browser cere o pagină de la server.
- Înregistrează răspunsul primit: pagină validă, redirect, eroare, blocare, conținut duplicat, directive SEO.
- Urmărește linkurile găsite și repetă procesul până când nu mai are URL-uri noi de verificat sau până când îl oprești.
De aici apar rapoartele utile: pagini cu status 404, lanțuri de redirect, titluri lipsă, descrieri duplicate, pagini cu noindex, canonical greșit, imagini fără atribut alt, pagini orfane dacă imporți date externe, adâncime mare în structură și probleme de linking intern.
Google explică în documentația despre cum funcționează Search că procesul include crawling, indexare și afișare în rezultate. Diferența asta trebuie păstrată în minte când citești datele din tool: faptul că Screaming Frog găsește o pagină nu înseamnă că Google o indexează sau că pagina poate obține poziții bune.
Unde greșesc audituri făcute doar din exporturi
Un audit tehnic făcut doar din exporturi greșește când tratează fiecare atenționare ca pe o urgență. Nu toate problemele au același impact, iar unele sunt normale pentru anumite site-uri.
Vedem des magazine online cu mii de URL-uri generate de filtre. Toolul le listează frumos, dar decizia nu este „ștergem tot”. Decizia depinde de ce caută oamenii, ce categorii au valoare, ce filtre creează combinații utile și ce combinații consumă crawl fără să aducă pagini bune.
La un auto service, o pagină de „contact” cu titlu prea scurt nu este prima problemă. Mai probabil contează dacă serviciile principale au pagini separate, dacă adresa și zona deservită sunt clare, dacă paginile de servicii sunt legate din meniu și dacă Google poate vedea aceeași firmă în site și în profilul local.
La un cabinet, o problemă tehnică mică poate deveni mare dacă apare pe șablonul tuturor paginilor de servicii. Un noindex pus accidental pe template nu arată spectaculos într-un screenshot, dar poate scoate din index exact paginile care aduc cereri.
Scorul dintr-un tool nu este semnal Google. Este o metodă de prioritizare internă a toolului. La fel, un scor bun nu înseamnă că site-ul răspunde bine intenției de căutare, iar un scor slab nu înseamnă automat că traficul scade din cauza tehnicului.
Cum pregătești crawl-ul înainte să apeși Start?
Un crawl bun începe cu setările potrivite pentru site-ul analizat. Dacă lași totul pe implicit, riști să ratezi zone blocate, să crawl-uiești URL-uri inutile sau să compari date care nu au legătură cu versiunea reală a site-ului.
Noi verificăm întâi versiunea canonică a domeniului: cu sau fără www, http sau https, slash final sau fără slash. Pare detaliu minor, dar am văzut site-uri unde meniul intern trimitea spre o variantă, sitemapul spre alta, iar canonicalul spre a treia. În raport apăreau „duplicări”, dar problema reală era lipsa unei reguli clare pentru URL-uri.
Înainte de crawl, verifici:
- dacă site-ul de analizat este live sau staging;
- dacă trebuie respectat
robots.txtsau vrei să vezi și zonele blocate; - dacă ai acces la sitemapul XML;
- dacă site-ul are zone care cer autentificare;
- dacă ai nevoie de renderizare JavaScript pentru pagini construite client-side;
- dacă vrei să conectezi Search Console sau Analytics pentru date suplimentare.
Trade-off-ul este simplu: un crawl mai agresiv îți dă mai multe date, dar poate încărca inutil serverul. Pentru un magazin online mare sau pentru un site pe hosting slab, nu pornesc niciodată crawl-ul complet fără să mă uit la limite, viteză și orele în care traficul real este mai mic.
Clientul are aici o parte pe care nu o poate face agenția în locul lui: acces la Search Console, Analytics, CMS, hosting sau staging. Fără accesuri, auditul se poate face parțial, dar rămânem în zona de presupuneri pentru unele cauze.
Datele din Screaming Frog trebuie comparate cu Search Console
Datele din Screaming Frog arată ce găsește toolul când crawl-uiește site-ul. Search Console arată ce raportează Google despre site. Diferența dintre cele două este locul unde apar cele mai utile concluzii.
| Sursă | Ce îți arată | Ce nu îți spune singură | Cum o folosim în audit |
|---|---|---|---|
| Screaming Frog | Structură internă, status code-uri, titluri, canonical, meta robots | Dacă Google a indexat efectiv pagina | Găsim probleme tehnice repetate și tipare pe șabloane |
| Search Console | Indexare, performanță organică, interogări, pagini cu impresii | Toate detaliile tehnice de pe fiecare URL | Validăm dacă problema se vede și în datele Google |
| Analytics | Sesiuni, conversii, comportament după click | De ce o pagină nu intră în index | Legăm problemele SEO de pagini cu valoare pentru business |
| CMS sau server | Setări, template-uri, redirecturi, pluginuri | Cum percepe Google pagina în rezultate | Identificăm cauza implementării, nu doar efectul |
În Search Console, raportul „Indexare pagini” este primul loc unde verifici dacă problema detectată în crawl există și pentru Google. Nu te uiți doar la paginile valide. Te uiți la excluse, la motivele de excludere și la exemplele de URL-uri.
Raportul „Performanță” completează imaginea. O pagină cu titlu duplicat poate fi irelevantă dacă nu are nicio valoare pentru business. O pagină de categorie care pierde impresii după o schimbare de structură merită verificată înaintea a cincizeci de meta descrieri lipsă.
Nu poți măsura tot. De exemplu, Screaming Frog nu îți spune exact cum va reevalua Google o pagină după ce schimbi linkingul intern. Poți urmări crawl-ul, indexarea și evoluția în Search Console, dar nu poți izola perfect fiecare semnal într-un site real unde concurența se mișcă în același timp.
Verificările tehnice care schimbă prioritizarea
În audit tehnic, ordinea contează mai mult decât lungimea listei. Noi începem cu probleme care pot bloca descoperirea, indexarea sau consolidarea semnalelor, apoi coborâm spre optimizări de șablon și detalii on-page.
Status code-uri și redirecturi
Status code-urile arată ce răspuns dă serverul pentru fiecare URL. Paginile cu 200 sunt accesibile, 301 indică redirect permanent, 404 indică pagină negăsită, iar erorile de server trebuie verificate rapid dacă apar pe pagini importante.
Nu orice 404 este dezastru. Un produs vechi scos din stoc poate dispărea corect dacă nu mai are înlocuitor și nu mai primește trafic. Problema apare când URL-ul are linkuri interne, backlinkuri sau trafic organic. Atunci alegi între redirect spre echivalent, actualizare pagină sau păstrare cu mesaj util.
Indexare, noindex și robots.txt
Directivele de indexare sunt printre primele verificări, pentru că pot opri pagini bune înainte să concureze în Google. noindex spune motoarelor de căutare să nu indexeze pagina, iar robots.txt poate bloca accesul crawlerelor la anumite zone.
Greșeala pe care o vedem după redesignuri WordPress: site-ul a stat pe staging cu noindex, apoi setarea a rămas activă pe live. Toolul o prinde imediat, dar corecția reală cere acces la CMS sau la pluginul SEO. Aici mentenanță WordPress nu înseamnă doar update-uri de pluginuri, ci control asupra modificărilor care pot afecta indexarea.
Canonical și pagini similare
Tagul canonical indică URL-ul preferat când există pagini foarte asemănătoare. Google poate ține cont de el, dar nu este obligat să îl urmeze dacă semnalele din site spun altceva.
La magazine online, canonicalul greșit apare des pe filtre, paginare și variante de produs. Dacă toate variantele trimit canonical spre categoria principală, poți pierde pagini utile. Dacă toate variantele se auto-canonicalizează fără logică, poți crea duplicare inutilă. Corecția depinde de cererea reală pentru acele variante.
Titluri, headinguri și meta descrieri
Titlurile și headingurile ajută Google și utilizatorul să înțeleagă tema paginii. În Screaming Frog vezi rapid titluri lipsă, duplicate, prea lungi sau generate automat.
Nu recomand rescrierea tuturor titlurilor doar pentru că apar în raport. Încep cu paginile care au impresii în Search Console, poziții apropiate de zona vizibilă sau valoare comercială clară. O pagină de categorie cu trafic potențial merită înaintea unei pagini legale fără rol SEO.
Dacă problema este de structură a conținutului, intră în zona de optimizare SEO on-page, nu doar tehnic. Un titlu bun nu salvează o pagină care nu răspunde la ce caută omul.
Linking intern și adâncime în site
Linkingul intern arată ce pagini susține site-ul prin propria structură. Screaming Frog îți arată câte clickuri sunt necesare până la o pagină, câte linkuri interne primește și din ce zone.
O problemă frecventă la firme de servicii: serviciile profitabile sunt menționate doar în texte, nu au pagini dedicate și nu sunt legate din meniu. Toolul poate arăta adâncimea și lipsa linkurilor, dar clientul trebuie să decidă ce servicii vinde cu prioritate. Agenția nu poate inventa strategia comercială.
Sitemap XML
Sitemapul XML ar trebui să conțină URL-uri canonice, indexabile și utile. Dacă sitemapul include pagini cu noindex, redirecturi sau erori, trimiți semnale contradictorii.
În audit comparăm sitemapul cu ce găsește crawl-ul. Paginile importante care apar în sitemap, dar nu sunt legate intern, trebuie investigate. Paginile legate intern, dar absente din sitemap, pot fi perfect normale, însă pe site-uri mari diferența indică uneori template-uri sau generări automate scăpate de sub control.
Când trebuie activată renderizarea JavaScript?
Renderizarea JavaScript trebuie activată când pagina afișează conținut, linkuri sau elemente SEO abia după rularea JavaScript. Fără renderizare, crawlerul poate vedea o versiune mai săracă decât vede utilizatorul.
Diferența contează la site-uri construite cu frameworkuri moderne, la magazine cu filtre dinamice și la pagini unde meniul sau listările se încarcă după interacțiune. Dacă Screaming Frog în modul standard nu vede linkurile către categorii, iar browserul le afișează, verifici crawl-ul cu JavaScript rendering.
Nu activezi renderizarea doar ca să pari mai riguros. Costă timp, consumă resurse și poate complica analiza. O folosim când există motiv: conținut lipsă în HTML, diferențe între View Source și DOM, linkuri care apar doar după scripturi sau probleme raportate în Search Console care nu se explică prin HTML-ul inițial.
Nu știe nimeni din afară exact cum va procesa Google fiecare implementare JavaScript în fiecare moment. Ce putem face este să verificăm dacă informația critică există în HTML sau devine accesibilă după randare și să evităm implementările în care linkurile interne depind de comportamente fragile.
Audit tehnic pentru WordPress și magazine online
Auditul tehnic cu Screaming Frog arată diferit în WordPress față de un magazin online, pentru că problemele vin din șabloane diferite. La WordPress apar des pluginuri, arhive, taguri și pagini generate automat. La eCommerce apar filtre, variante, produse indisponibile și paginare.
Pe WordPress verificăm de obicei:
- arhive de autor, taguri sau date care se indexează fără scop;
- pagini generate de pluginuri, cu titluri duplicate;
- imagini mari și resurse încărcate inutil pe toate paginile;
- canonical setat de plugin, dar contrazis de linkurile interne;
- redirecturi create în pluginuri diferite, fără evidență clară.
La magazine online, lista se schimbă:
- categorii fără text util sau cu același text copiat;
- filtre indexabile fără cerere reală;
- produse dispărute care returnează
404deși aveau trafic; - paginare incoerentă;
- variante de produs care concurează între ele.
Clientul trebuie să participe la deciziile unde toolul nu are context. Un magazin online știe ce produse revin în stoc, ce categorii au marjă bună și ce filtre folosesc clienții reali. Un cabinet știe ce servicii nu mai vrea să promoveze. Fără aceste informații, auditul devine curățenie tehnică, nu optimizare SEO legată de business.
Cum prioritizezi problemele după crawl?
Prioritizarea după crawl începe cu impactul asupra descoperirii, indexării și paginilor cu valoare. Problemele care afectează șabloane, categorii sau servicii principale vin înaintea detaliilor cosmetice.
Noi folosim o ordine de lucru simplă:
- Blocaje de crawl și indexare:
robots.txt,noindex, erori server, canonical greșit pe pagini importante. - Probleme de structură: pagini valoroase prea adânci, lipsă linking intern, meniuri care nu susțin paginile comerciale.
- Duplicare și consolidare: URL-uri similare, filtre, variante, redirecturi, paginare.
- Șabloane on-page: titluri, headinguri, meta descrieri, conținut repetat.
- Optimizări de calitate: imagini, resurse, date structurate, ajustări fine.
Regula practică: dacă problema afectează o singură pagină slabă, poate aștepta. Dacă afectează un template folosit de sute de pagini sau o categorie care aduce vânzări, intră sus în listă.
Un exemplu concret: într-un site de servicii locale, am văzut toate paginile de oraș legate doar din footer, fără legătură din paginile de servicii. Toolul arăta adâncime acceptabilă, dar structura nu spunea clar ce serviciu se oferă în fiecare zonă. Corecția nu a fost „mai multe linkuri”, ci legarea serviciilor de paginile locale relevante, cu texte scrise pentru oameni, nu blocuri de ancore repetate.
Ce nu îți spune Screaming Frog
Screaming Frog nu îți spune dacă pagina este utilă, dacă oferta este clară sau dacă textul răspunde la intenția de căutare. Toolul vede elemente tehnice. Nu vede conversațiile dintre client și firmă.
Aici se pierd multe audituri. O pagină poate avea titlu, H1, canonical corect și status 200, dar să nu răspundă la întrebarea care aduce clientul. Pentru o firmă de construcții, omul nu caută doar „servicii construcții”. Caută condiții, tipuri de lucrări, zone, garanții, exemple și pași de colaborare.
Screaming Frog nu confirmă nici calitatea backlinkurilor. Poate extrage linkuri externe din pagini și poate fi conectat cu date din alte tooluri, dar metrici precum Domain Authority sunt metrici Moz, nu factori Google. Dacă vezi un scor, îl tratezi ca reper de analiză, nu ca dovadă că Google va schimba pozițiile.
Nu îți spune nici ce va face concurența. Poți repara toate problemele tehnice și tot să nu vezi mișcare rapidă dacă paginile concurente au conținut mai bun, brand mai puternic, linkuri mai relevante sau istoric mai bun. Pozițiile nu se pot garanta, pentru că Google compară pagina ta cu restul rezultatelor, iar restul rezultatelor se schimbă fără să te întrebe.
Când auditul automat este suficient și când nu este?
Un audit automat este suficient pentru o primă verificare, nu pentru decizii grele de structură, indexare sau migrare. Dacă site-ul este mic și vrei să vezi erori evidente, un tool automat ajută. Dacă urmează să schimbi platforma, meniul sau URL-urile, ai nevoie de analiză manuală.
Auditul nostru SEO gratuit poate fi un punct de plecare: verifică automat peste 60 de elemente, oferă un scor, prioritizează probleme și trimite raportul pe email, fără cont și fără card. Limita lui trebuie spusă clar: un tool automat prinde ce poate verifica automat. Nu îți spune dacă structura site-ului are sens pentru business și nici dacă textul răspunde la ce caută clientul tău.
Nu aș decide o migrare, o rescriere de categorii sau o strategie de indexare pentru filtre doar dintr-un audit automat. Aș folosi raportul ca listă de semnale, apoi aș deschide Screaming Frog, Search Console, sitemapul, CMS-ul și datele de trafic.
Ce faci după ce ai raportul tehnic
După raportul tehnic, următorul pas nu este să trimiți toate erorile la dezvoltator. Următorul pas este să transformi raportul în taskuri clare, cu prioritate, URL-uri afectate, cauză probabilă și criteriu de verificare.
Un task bun nu spune „rezolvă canonical”. Spune: „Pe toate paginile de categorie filtrată, canonicalul indică spre URL-ul filtrat, deși vrem consolidare spre categoria principală. Verifică template-ul de filtre și aplică regula X. După implementare, crawl-uim din nou lista de URL-uri.”
Un task bun nu spune „optimizează viteza”. Spune ce resursă încarcă toate paginile, ce template este afectat și unde se verifică rezultatul: PageSpeed Insights, raportul Core Web Vitals sau testul intern după deploy. Core Web Vitals sunt metrici de experiență măsurate prin indicatori precum LCP, INP și CLS, dar optimizarea lor nu înlocuiește problemele de indexare.
După implementare, crawl-ul se repetă. Nu pe tot site-ul de fiecare dată, dacă nu este nevoie. Uneori verifici doar lista de URL-uri afectate. Alteori refaci crawl complet, mai ales după schimbări de meniu, template, platformă sau reguli de redirect.
Întrebări frecvente
Pot face singur un audit tehnic cu Screaming Frog?
Poți face singur o verificare de bază cu Screaming Frog, mai ales pe site-uri mici. Limita apare la interpretare: ce ignori, ce repari întâi și ce confirmi în Search Console. Dacă urmează o migrare sau ai scădere de trafic, nu m-aș baza doar pe exporturi.
Screaming Frog îmi arată de ce nu sunt pe prima pagină?
Screaming Frog nu îți arată singur de ce o pagină nu are poziții bune. Toolul găsește probleme tehnice și de structură, dar pozițiile depind și de conținut, intenție de căutare, concurență, autoritate, istoric și felul în care Google compară rezultatele.
Trebuie reparate toate erorile marcate în tool?
Nu trebuie reparate toate erorile marcate în tool. Unele sunt normale, altele au impact mic, iar unele afectează pagini fără valoare SEO. Începi cu blocaje de indexare, erori pe pagini importante, probleme de template și URL-uri care au trafic sau potențial comercial.
De ce Search Console arată altceva decât Screaming Frog?
Search Console și Screaming Frog măsoară lucruri diferite. Screaming Frog arată ce găsește crawlerul la momentul scanării, iar Search Console raportează date din perspectiva Google. Diferențele apar din indexare, timp de procesare, reguli de crawling, canonical ales și URL-uri pe care toolul nu le-a descoperit.
Cât durează până se vede efectul după rezolvarea problemelor tehnice?
Efectul nu apare instant după rezolvarea problemelor tehnice. Google trebuie să recrawl-uiască paginile, să proceseze schimbările și să le compare cu restul rezultatelor. Pentru SEO, primele rezultate vizibile apar de regulă în 3-6 luni, iar colaborările de 6-12+ luni dau cele mai consistente rezultate.
Un scor bun în audit înseamnă că site-ul este optimizat?
Un scor bun în audit nu înseamnă automat că site-ul este optimizat. Scorul este o sinteză a verificărilor automate. Poți avea scor bun și pagini slabe comercial, conținut neconvingător sau structură care nu susține serviciile importante.
Screaming Frog poate analiza și site-uri WordPress?
Screaming Frog poate analiza site-uri WordPress, pentru că verifică URL-urile livrate public, nu platforma în sine. La WordPress, problemele vin des din pluginuri SEO, arhive indexabile, taguri, teme schimbate fără testare și redirecturi create în mai multe locuri.
Ce se întâmplă dacă schimb tema sau structura site-ului după audit?
Dacă schimbi tema sau structura după audit, raportul poate deveni parțial depășit. Se pot schimba meniuri, headinguri, canonical, viteza, linkurile interne și status code-urile. Anunță înainte modificările mari, ca auditul să fie refăcut pe zonele afectate, nu reparat după ce traficul scade.
Regula practică pentru folosirea Screaming Frog
Screaming Frog este foarte bun când îl folosești ca instrument de investigare. Devine periculos când îl folosești ca listă mecanică de taskuri.
Auditul tehnic bun răspunde la patru întrebări: poate Google descoperi paginile importante, poate să le indexeze, înțelege care este versiunea corectă și susține site-ul acele pagini prin structură internă? Restul vine după.
Dacă ai de ales între a repara o sută de meta descrieri lipsă și a verifica de ce paginile de servicii au noindex, începi cu noindex. Dacă ai de ales între scor și business, alegi business. Toolul îți arată unde să sapi. Decizia rămâne la audit.



