Tehnički SEO audit proverava da li pretraživači mogu pouzdano da pronađu, obrade i indeksiraju važne stranice sajta i da li tehnička infrastruktura nepotrebno otežava korišćenje sajta.
Njegov cilj nije da svaki SEO alat pokaže zeleno svetlo. Mnogo je važnije pronaći probleme koji stvarno utiču na veliki broj važnih URL-ova: pogrešno blokirano indeksiranje, loše canonical oznake, spora učitavanja, beskonačna preusmerenja, interne linkove koji vode na greške ili stranice koje Google teško pronalazi.
Dobar audit zato ide od problema na nivou celog sajta ka pojedinačnim stranicama. Greška u šablonu koja utiče na 5.000 URL-ova obično ima veći prioritet od jednog neidealnog meta elementa na jednoj objavi.
Tehnički SEO počinje pitanjem: može li stranica uopšte da bude pronađena?
Pre nego što analizirate sadržaj, naslov ili ključne reči, proverite da li pretraživač može da dođe do URL-a.
Važna stranica može biti kvalitetna, ali joj organska vidljivost neće mnogo pomoći ako:
- nijedan interni link ne vodi ka njoj;
- blokirana je u robots.txt fajlu;
- server često vraća grešku;
- URL vodi kroz problematičan lanac preusmerenja;
- navigacija zavisi od mehanizma koji pretraživač teško otkriva;
- stranica postoji samo kao rezultat interne pretrage bez jasne veze sa ostatkom sajta.
To je razlog da audit počne arhitekturom i dostupnošću, a ne podešavanjem pojedinačnih SEO polja.
Crawlability i indexability nisu ista stvar
Ova dva pojma se često mešaju.
Crawlability govori o tome da li pretraživač može da pristupi stranici i preuzme njen sadržaj.
Indexability govori o tome da li stranica može i treba da bude uključena u indeks.
URL može biti dostupan Googlebotu, ali ipak imati noindex direktivu. Isto tako, stranica može biti dozvoljena za indeksiranje, ali toliko teško dostupna kroz strukturu sajta da je pretraživač retko pronalazi.
Zato tokom audita ova dva pitanja treba proveravati odvojeno.
Robots.txt ne služi za uklanjanje stranice iz Google indeksa
robots.txt kontroliše pristup crawlera određenim delovima sajta. On nije pouzdana zamena za noindex.
Ako želite da pretraživač vidi noindex direktivu na stranici, crawler uglavnom mora moći da joj pristupi.
Zbog toga kombinacija:
Disallow u robots.txt + očekivanje da Google pročita noindex
može biti kontradiktorna.
Tokom audita proverite da li robots pravila slučajno blokiraju:
- važne kategorije;
- članke;
- CSS ili JavaScript koji je potreban za prikaz;
- stranice proizvoda;
- druge URL-ove koji treba da budu dostupni pretraživaču.
Proverite koje stranice imaju noindex
noindex može biti potpuno opravdan za određene stranice, ali je problem kada se slučajno pojavi na važnom sadržaju.
Posebno proverite promene nakon:
- redizajna;
- migracije sajta;
- prebacivanja staging verzije na produkciju;
- promene SEO dodatka;
- izmene šablona.
Jedna globalna postavka može nenamerno uticati na veliki broj URL-ova.
XML sitemap treba da sadrži URL-ove koje zaista želite u pretrazi
XML sitemap pomaže pretraživaču da otkrije važne URL-ove, ali njegovo prisustvo ne garantuje indeksiranje.
U sitemapu bi idealno trebalo da budu stranice koje:
- vraćaju uspešan HTTP odgovor;
- nisu označene kao
noindex; - predstavljaju canonical verziju sadržaja;
- nisu preusmerenja;
- zaista želite dostupne u organskoj pretrazi.
Ako sitemap sadrži hiljade URL-ova koje istovremeno blokirate, preusmeravate ili canonical oznakom šaljete na druge stranice, različiti tehnički signali nisu usklađeni.
Za razumevanje šireg procesa korisno je znati i kako Google pronalazi i obrađuje stranice.
Ne paničite zbog svakog URL-a koji nije indeksiran
Nije cilj da Google indeksira svaki URL koji WordPress ili drugi CMS može da generiše.
Sajt može imati:
- RSS feedove;
- stranice pretrage;
- parametarske URL-ove;
- duplikate;
- stare preusmerene adrese;
- stranice koje su namerno označene kao noindex.
Mnogo važnije pitanje je:
Da li su važne stranice koje treba da dobijaju organski saobraćaj dostupne i indeksabilne?
Audit zato treba da razlikuje očekivano isključivanje iz indeksa od stvarne greške.
Proverite HTTP statusne kodove
Statusni kod brzo pokazuje šta se dešava sa URL-om.
| Status | Najčešće značenje | Šta proveriti |
|---|---|---|
| 200 | Stranica se normalno učitava | Da li je sadržaj zaista ono što očekujete |
| 301/308 | Trajno preusmerenje | Da li vodi direktno na odgovarajući novi URL |
| 302/307 | Privremeno preusmerenje | Da li je privremeni status zaista nameran |
| 404 | Stranica nije pronađena | Da li postoje interni ili važni spoljni linkovi ka njoj |
| 5xx | Serverska greška | Stabilnost servera i učestalost problema |
Sama 404 stranica nije SEO katastrofa. Ako je URL zaista uklonjen i nema odgovarajuću zamenu, status 404 može biti potpuno ispravan.
Problem nastaje kada važni interni linkovi vode na takve stranice ili kada URL koji treba da postoji greškom vraća 404.
Ne preusmeravajte svaki nestali URL na početnu stranicu
Kada stara stranica ima jasnu novu zamenu, preusmerenje ima smisla.
Na primer:
stari vodič → nova verzija istog vodiča.
Ali ako odgovarajuća zamena ne postoji, automatsko slanje svakog 404 URL-a na početnu stranicu obično ne pomaže korisniku.
Preusmerenje treba da ima semantički smisao.
Pronađite lance i petlje preusmerenja
Idealno je da stari URL vodi direktno na finalnu adresu.
Lošija struktura izgleda ovako:
URL A → URL B → URL C → URL D.
Još ozbiljniji problem je petlja:
URL A → URL B → URL A.
Lanci mogu nastati tokom višegodišnjih izmena slugova, migracija i redizajna.
Kada pronađete lanac, interne linkove treba ažurirati tako da vode direktno na finalni URL gde god je moguće.
Canonical oznaka treba da odgovara stvarnoj strukturi sajta
rel="canonical" pomaže da signalizirate koja verzija sličnog ili dupliranog sadržaja predstavlja preferiranu adresu.
Tokom audita proverite da li:
- važna stranica canonicalizuje samu sebe kada je to očekivano;
- canonical ne vodi slučajno na nepovezanu stranicu;
- HTTP i HTTPS verzije nisu pomešane;
- www i non-www verzije koriste doslednu adresu;
- parametarske verzije ne stvaraju nepotrebne konflikte;
- sitemap i interni linkovi koriste istu preferiranu verziju URL-a.
Canonical je signal, a ne apsolutna komanda. Ako ostali signali sajta govore nešto drugo, pretraživač može izabrati drugu canonical verziju.
Proverite da li postoji jedna dosledna HTTPS verzija sajta
Sajt ne bi trebalo da funkcioniše kao više nezavisnih verzija:
http://example.com;https://example.com;http://www.example.com;https://www.example.com.
Odaberite jednu glavnu verziju, a ostale pravilno preusmerite.
Proverite i da li interne veze, canonical oznake i sitemap koriste HTTPS umesto da se oslanjaju na dodatna preusmerenja.
Arhitektura sajta treba da pokaže šta je važno
Važne stranice ne treba da budu skrivene duboko u sajtu bez jasnog puta do njih.
Dobra arhitektura obično omogućava da korisnik iz glavnih kategorija i relevantnih članaka prirodno dođe do važnog sadržaja.
To ne znači da postoji magični maksimalni broj klikova za svaki URL. Bitnije je da struktura bude logična i da stranice koje su poslovno i sadržajno važne imaju odgovarajuće interne veze.
Pronađite orphan stranice
Orphan stranica je URL do kojeg ne vodi nijedan ili gotovo nijedan interni link iz normalne strukture sajta.
Takva stranica može postojati u sitemapu, ali biti praktično izolovana od sadržaja oko nje.
Ako je važna, pronađite prirodna mesta sa kojih treba da bude povezana:
- kategorija;
- glavni vodič;
- povezani članak;
- navigacija;
- druga relevantna stranica.
Ako za stranicu ne postoji nijedno logično mesto za interni link, vredi preispitati koliko se uopšte uklapa u strukturu sajta.
Pokvareni interni linkovi su praktičan prioritet
Interni link koji vodi na 404 ili pogrešno preusmerenje utiče i na korisnika i na strukturu sajta.
Tokom audita pronađite:
- linkove ka obrisanim stranicama;
- linkove ka starim URL-ovima;
- linkove koji prolaze kroz nepotrebno preusmerenje;
- pogrešno napisane adrese;
- linkove ka zastarelim HTTP verzijama.
Prilikom popravke link treba direktno da vodi na finalnu relevantnu stranicu.
Ne menjajte dobre URL-ove samo da bi izgledali „SEO čistije“
Kratak i razumljiv URL može biti koristan, ali postojeći URL koji već funkcioniše ne treba menjati bez razloga.
Promena adrese može zahtevati:
- 301 preusmerenje;
- izmenu internih linkova;
- proveru canonical oznaka;
- ažuriranje sitemapa;
- praćenje stare i nove verzije.
Zato je bolje dobro planirati URL pre objave nego kasnije menjati postojeće adrese zbog sitnih estetskih poboljšanja.
Proverite da li JavaScript skriva ključni sadržaj
Savremeni sajtovi često koriste JavaScript za učitavanje sadržaja i navigacije.
To samo po sebi nije problem, ali audit treba da proveri da li je ključni sadržaj i dalje pouzdano dostupan pretraživaču.
Posebno obratite pažnju ako se:
- glavni tekst pojavljuje tek nakon složene korisničke akcije;
- interni linkovi generišu na neobičan način;
- sadržaj učitava tek nakon beskonačnog skrolovanja;
- različita verzija sadržaja prikazuje crawleru i korisniku;
- važni elementi ne postoje u renderovanoj stranici.
Kod složenijih JavaScript sajtova korisno je proveriti ne samo izvorni HTML već i renderovanu verziju stranice.
Brzina sajta nije samo jedan PageSpeed broj
Jedna laboratorijska ocena može biti korisna za dijagnostiku, ali ne predstavlja kompletno iskustvo svih korisnika.
Performanse treba analizirati kroz više signala:
- stvarne podatke korisnika kada su dostupni;
- laboratorijske testove;
- različite tipove stranica;
- mobilne uređaje;
- sporije mrežne uslove.
Početna stranica može biti brza, dok pojedinačni članci ili stranice proizvoda koriste potpuno drugačiji šablon i imaju problem.
Core Web Vitals proveravajte po tipu stranice
Core Web Vitals pomažu da se procene važni delovi korisničkog iskustva, uključujući brzinu prikaza glavnog sadržaja, odziv na interakciju i stabilnost rasporeda.
Praktično proverite:
- da li se glavni sadržaj pojavljuje dovoljno brzo;
- da li stranica brzo reaguje kada korisnik klikne ili dodirne element;
- da li sadržaj skače dok se naknadno učitavaju slike, oglasi ili fontovi.
Probleme treba tražiti u šablonima. Ako isti problem postoji na stotinama članaka, popravka jednog template-a može poboljšati veliki deo sajta.
Velike slike su čest uzrok sporog učitavanja
Fotografija od nekoliko megabajta ne treba da se šalje korisniku u punoj rezoluciji ako se na ekranu prikazuje kao slika širine nekoliko stotina piksela.
Proverite:
- dimenzije slika;
- kompresiju;
- odgovarajuće moderne formate kada ih sistem podržava;
- responsive verzije;
- lazy loading za slike koje nisu odmah vidljive;
- da hero ili featured slika nije pogrešno odložena ako je potrebna odmah.
Za detaljniji rad na ovoj oblasti pogledajte vodič kako ubrzati sajt i poboljšati performanse.
Previše JavaScript-a može usporiti interakciju
Stranica može vizuelno izgledati učitana, ali dugo ostati spora za korišćenje jer browser obrađuje veliki broj skripti.
Izvor problema mogu biti:
- teški page builder elementi;
- više analytics i advertising skripti;
- chat widgeti;
- nepotrebne biblioteke;
- skripte dodataka koje se učitavaju na svakoj stranici;
- funkcionalnosti koje korisnik nikada ne koristi.
Ne treba nasumično uklanjati svaku skriptu. Prvo utvrdite šta koristi sajt i koliki trošak ta funkcionalnost ima.
Fontovi mogu praviti neočekivane probleme
Veliki broj fontova i težina može povećati količinu podataka i izazvati promenu rasporeda tokom učitavanja.
Proverite:
- koliko familija fontova koristite;
- koliko težina se učitava;
- da li su svi zaista potrebni;
- da li postoji odgovarajuća rezervna tipografija;
- da li učitavanje fonta pomera sadržaj.
Server i hosting su deo performansi
Frontend optimizacija ne može u potpunosti kompenzovati server koji dugo čeka da počne da šalje odgovor.
Ako je sajt spor i pre nego što browser počne ozbiljno da obrađuje sadržaj, proverite:
- hosting;
- cache;
- bazu podataka;
- nepotrebne upite;
- PHP ili drugu serversku konfiguraciju;
- opterećenje dodataka;
- CDN kada ima smisla za projekat.
Mobilna verzija nije samo desktop stranica smanjena na uži ekran
Većina problema na telefonu nastaje kada je sadržaj tehnički responsive, ali nije stvarno upotrebljiv.
Proverite:
- veličinu teksta;
- razmak između elemenata;
- navigaciju;
- forme;
- tabele;
- iskačuće prozore;
- sticky elemente;
- slike i video;
- dugmad i druge elemente za dodir.
Otvorite stranice na stvarnom telefonu. Audit koji se završava samo simulacijom u desktop browseru lako može propustiti praktične probleme.
Pristupačnost i SEO se delimično preklapaju, ali nisu ista disciplina
Dobra semantička struktura, opisni linkovi, smisleni ALT tekstovi i pravilna upotreba naslova mogu koristiti i korisnicima i mašinskoj obradi sadržaja.
Međutim, nije dobro predstavljati svaki accessibility kriterijum kao direktan SEO faktor rangiranja.
Pristupačnost je prvenstveno pitanje omogućavanja ljudima da koriste sajt.
Tokom tehničkog audita ipak ima smisla primetiti očigledne probleme kao što su:
- forme bez jasnih oznaka;
- navigacija kojom se ne može upravljati tastaturom;
- slab kontrast;
- nejasan fokus;
- slike koje prenose informaciju bez odgovarajućeg tekstualnog opisa.
Proverite strukturu naslova
Naslovi treba da prate logičnu strukturu sadržaja, a ne da se biraju samo zbog veličine fonta.
Na tipičnom članku naslov stranice predstavlja H1, dok glavne celine koriste H2, a njihove podceline H3.
To korisniku olakšava skeniranje sadržaja, a mašinama daje jasniju strukturu dokumenta.
Za širu optimizaciju samog sadržaja pogledajte vodič za on-page SEO.
Structured data proveravajte tamo gde zaista odgovara sadržaju
Strukturirani podaci mogu pomoći pretraživaču da bolje razume određene informacije na stranici, ali schema markup ne treba dodavati samo zato da bi audit imao još jednu zelenu stavku.
Proverite:
- da li schema odgovara stvarnom sadržaju;
- da li obavezna polja postoje;
- da li označene informacije korisnik može da vidi na stranici kada je to potrebno;
- da li nema zastarelih ili nevažećih oznaka;
- da li isti sadržaj nije kontradiktorno označen na više načina.
Structured data ne garantuje poseban prikaz u rezultatima pretrage.
Proverite duplirani sadržaj koji nastaje tehnički
CMS može generisati više URL-ova koji vode ka veoma sličnom sadržaju.
Primeri uključuju:
- URL sa parametrima;
- print verzije;
- varijacije sa i bez završne kose crte;
- HTTP i HTTPS;
- www i non-www;
- filtrirane kategorije;
- različite putanje do istog sadržaja.
Cilj nije „kazna za duplirani sadržaj“, već jasno definisanje preferirane verzije i sprečavanje nepotrebnog rasipanja crawlinga i internih signala.
Filteri i faceted navigation mogu proizvesti ogroman broj URL-ova
Ovo je naročito važno za velike prodavnice, oglase i sajtove sa naprednim filtrima.
Kombinacije:
boja + veličina + cena + brend + sortiranje
mogu generisati hiljade ili milione adresa sa vrlo sličnim sadržajem.
Audit treba da utvrdi:
- koje kombinacije stvarno imaju vrednost kao landing stranice;
- koje ne treba indeksirati;
- kako crawler dolazi do parametarskih URL-ova;
- da li struktura generiše praktično beskonačan prostor za crawling.
Proverite paginaciju i arhive
Kategorije, arhive i višestranične liste mogu biti važne za otkrivanje starijih sadržaja.
Tokom audita proverite da li:
- starije stranice ostaju dostupne kroz normalne linkove;
- paginacija radi bez grešaka;
- stranice ne stvaraju beskonačne kombinacije URL-ova;
- važni stari članci nisu praktično odsečeni od sajta.
Interna pretraga ne treba da zameni arhitekturu sajta
Važna stranica ne bi trebalo da bude dostupna samo kada korisnik zna tačan izraz i koristi internu pretragu.
Ako je sadržaj važan, potrebno je da postoji normalan navigacioni ili kontekstualni put do njega.
Rezultati interne pretrage često takođe stvaraju veliki broj tankih URL-ova, pa treba proveriti kako ih sajt tretira.
Proverite soft 404 situacije
Ponekad server vraća status 200, ali sadržaj stranice praktično kaže:
„Proizvod nije pronađen“ ili „Ova stranica više ne postoji“.
Tehnički odgovor tada govori da je sve uspešno, dok sadržaj govori suprotno.
Takve slučajeve treba proveriti i vratiti status koji odgovara stvarnom stanju ili ponuditi odgovarajuću zamenu kada ona zaista postoji.
Logična hijerarhija prioriteta štedi mnogo vremena
Audit može pronaći stotine ili hiljade upozorenja. Nije svako jednako važno.
Praktičan redosled može biti:
| Prioritet | Primer |
|---|---|
| Kritično | Važan deo sajta blokiran ili noindexiran |
| Visoko | Veliki broj 5xx grešaka ili pogrešnih canonical oznaka |
| Srednje | Pokvareni interni linkovi ili nepotrebni redirect lanci |
| Niže | Pojedinačne tehničke nepravilnosti bez stvarnog uticaja |
Prioritet treba dodatno proceniti prema:
- broju pogođenih URL-ova;
- važnosti tih URL-ova;
- uticaju na crawling, indeksiranje ili korisnike;
- težini popravke.
Primer tehničkog audita manjeg WordPress sajta
Zamislimo sadržajni sajt sa 150 članaka.
Audit može izgledati ovako:
- Proveriti glavne verzije domena i HTTPS preusmerenja.
- Pregledati robots.txt.
- Otvoriti XML sitemap i proveriti koje tipove URL-ova sadrži.
- Uporediti sitemap sa važnim objavljenim stranicama.
- Pregledati izveštaj o indeksiranju u Search Console-u.
- Proveriti nekoliko važnih URL-ova kroz URL Inspection.
- Pretražiti sajt radi 4xx i 5xx statusa.
- Pronaći interne linkove koji vode kroz preusmerenja.
- Proveriti canonical oznake.
- Pronaći stranice sa slučajnim noindex statusom.
- Pregledati orphan ili veoma slabo povezane članke.
- Proveriti performanse različitih šablona.
- Testirati nekoliko stranica na stvarnom telefonu.
- Pregledati slike i najteže resurse.
- Zabeležiti probleme prema prioritetu, a ne samo napraviti dugačku listu.
To je korisnije od izvlačenja automatskog izveštaja sa 2.000 upozorenja bez odluke šta zapravo treba popraviti.
Audit treba da završi planom rada
Tehnički audit koji se završava PDF dokumentom od 80 strana nema mnogo vrednosti ako niko ne zna šta se radi dalje.
Za svaki značajan problem zabeležite:
- opis problema;
- primer URL-a;
- koliko stranica je pogođeno;
- zašto je problem važan;
- preporučenu promenu;
- prioritet;
- odgovornu osobu;
- status rešavanja.
Nakon implementacije problem treba ponovo proveriti. Pretpostavka da je tehnička izmena uspešno rešila situaciju nije isto što i potvrda.
Audit nije jednokratan posao
Tehničko stanje sajta se menja.
Novi problem može nastati nakon:
- promene teme;
- instaliranja dodatka;
- redizajna;
- migracije;
- promene domena;
- uvođenja novih filtera;
- promene permalink strukture;
- izmena u JavaScript-u;
- promene servera.
Zato nije potrebno svakog dana raditi kompletan audit, ali ključne tehničke signale treba redovno pratiti.
Praktična kontrolna lista za tehnički SEO audit
- Da li jedna glavna HTTPS verzija domena funkcioniše dosledno?
- Da li robots.txt slučajno blokira važne stranice ili resurse?
- Da li važne stranice imaju ispravan index/noindex status?
- Da li XML sitemap sadrži samo URL-ove koje želite u pretrazi?
- Da li sitemap sadrži preusmerenja, 404 ili noindex stranice?
- Da li važne stranice vraćaju očekivane HTTP statusne kodove?
- Postoje li redirect lanci ili petlje?
- Da li canonical oznake pokazuju na odgovarajuće URL-ove?
- Da li interni linkovi koriste canonical verziju adrese?
- Postoje li pokvareni interni linkovi?
- Postoje li važne orphan stranice?
- Da li struktura sajta omogućava prirodan pristup važnom sadržaju?
- Da li parametri, filteri ili interna pretraga generišu veliki broj nepotrebnih URL-ova?
- Da li JavaScript pouzdano prikazuje ključni sadržaj i linkove?
- Da li različiti tipovi stranica imaju prihvatljive performanse?
- Da li su velike slike pravilno optimizovane?
- Da li nepotrebne skripte usporavaju interakciju?
- Da li se sadržaj pomera tokom učitavanja?
- Da li je mobilna verzija stvarno upotrebljiva?
- Da li naslovi i HTML struktura imaju logičnu hijerarhiju?
- Da li structured data odgovara stvarnom sadržaju?
- Da li postoje soft 404 stranice?
- Da li su problemi rangirani prema stvarnom uticaju?
- Da li je nakon popravke urađena ponovna provera?
Tehnički SEO audit nije pokušaj da se ukloni svako upozorenje koje alat može da pronađe. Njegova svrha je da otkrije prepreke koje pretraživačima otežavaju pristup i razumevanje važnog sadržaja ili korisnicima otežavaju korišćenje sajta.
Najviše vrednosti donosi kada se problemi rešavaju po uticaju: prvo ono što pogađa veliki broj važnih stranica, zatim struktura i interne veze, pa performanse i pojedinačne greške. Zdrav tehnički temelj ne garantuje visoko rangiranje, ali sprečava da dobar sadržaj gubi priliku zbog problema koje je sajt mogao da izbegne.