Tehnički SEO 2026: crawl, index, canonical i JavaScript

Tehnički SEO je deo SEO optimizacije koji omogućava pretraživaču da pronađe, učita, razume, renderuje i pravilno indeksira sadržaj sajta.

Možete imati najbolji tekst u industriji.

Ako je URL blokiran, canonical pokazuje na pogrešnu stranicu, JavaScript skriva glavni sadržaj ili interni linkovi nisu crawlable — Google možda neće videti ono što korisnik vidi.

Zato tehnički SEO nije „sređivanje nekoliko meta tagova“.

To je infrastruktura organske vidljivosti.

Najjednostavnije ga možemo posmatrati kroz sledeći tok:

discovery → crawl → render → index → canonicalization → serving

Ako jedan deo tog sistema ne radi, SEO problem često nastaje mnogo pre nego što dođemo do pitanja kvaliteta sadržaja ili backlinkova.

Za kompletnu analizu sajta pogledajte naš vodič SEO analiza sajta. Ako želite širu strategiju organskog rasta, pogledajte SEO optimizaciju.

Primarne fraze

tehnički SEO · tehnička SEO optimizacija · technical SEO · tehnički SEO audit · crawl i indexing · JavaScript SEO · canonical SEO

Uvod: tehnički SEO ne rangira stranicu umesto sadržaja — ali može sprečiti sadržaj da uopšte uđe u igru

Jedna od najčešćih SEO grešaka je pogrešan redosled rada.

Tim vidi pad pozicija i odmah počinje da:

• menja naslove;
• dodaje još teksta;
• objavljuje nove članke;
• kupuje backlinkove.

A pravi problem može biti:

• novi canonical;
• slučajan noindex;
• pogrešan redirect;
• JavaScript rendering;
• parametarski URL-ovi;
• neispravan sitemap;
• interno linkovanje.

Zato tehnički SEO počinje pitanjem:

„Može li pretraživač pouzdano da dođe do prave verzije našeg sadržaja i razume šta sa njom treba da uradi?“

1. Kako Google tehnički obrađuje stranicu?

Google u svojoj aktuelnoj JavaScript SEO dokumentaciji proces opisuje kroz tri osnovne faze:

1. crawling;
2. rendering;
3. indexing.

To je dobar mentalni model i za sajtove koji nisu posebno JavaScript-heavy.

Google prvo mora da otkrije URL.

Zatim mora da ga crawluje.

Kada je potrebno, sadržaj se renderuje.

Tek nakon obrade može doći do indeksiranja i konsolidovanja odgovarajuće canonical verzije.

Izvor: Google Search Central — JavaScript SEO basics.

2. Discovery: kako Google uopšte nalazi URL?

Najvažniji izvori otkrivanja novih URL-ova uključuju:

• interne linkove;
• eksterne linkove;
• XML sitemap;
• ranije poznate URL-ove;
• redirekcije.

Za klasičnu internu navigaciju Google preporučuje crawlable HTML linkove, odnosno standardne <a href="..."> elemente.

Dugme koje JavaScript-om otvara drugi sadržaj nije nužno isto što i crawlable link.

To postaje posebno važno kod:

• SPA aplikacija;
• infinite scroll-a;
• „Load more“ sistema;
• JavaScript navigacije.

3. Interni link koji korisnik može da klikne nije automatski link koji crawler može pouzdano da prati

Problematičan pattern može izgledati kao element koji samo poziva JavaScript funkciju.

Za važne SEO destinacije sigurniji pristup je pravi link:

<a href="https://example.com/usluga">Usluga</a>

Ne radi se o tome da Google „ne razume JavaScript“.

Google ga renderuje.

Ali standardan crawlable HTML i dalje predstavlja jednostavniju i robusniju osnovu.

4. Crawlability i indexability nisu ista stvar

Ova dva termina se često pogrešno koriste kao sinonimi.

Crawlability odgovara na pitanje:

„Može li crawler da pristupi URL-u?“

Indexability odgovara na pitanje:

„Da li sadržaj može da bude uključen u Search indeks?“

Stranica može biti crawlable, ali označena kao noindex.

Može biti crawlable, ali Google proceni drugu stranicu kao canonical.

Može biti otkrivena kroz linkove, ali blokirana u robots.txt.

5. Robots.txt: šta stvarno radi?

robots.txt primarno kontroliše crawler pristup.

Primer:

User-agent: *
Disallow: /admin/

Ovakvo pravilo govori crawlerima koji ga poštuju da ne crawluju navedenu putanju.

Ali robots.txt nije pravi alat za uklanjanje URL-a iz indeksa.

Ako je cilj da stranica ne bude indeksirana, koristi se odgovarajući noindex signal.

6. Jedna od najopasnijih grešaka: robots.txt + noindex

Google mora da crawluje stranicu kako bi video robots meta tag.

Ako prvo blokirate URL kroz robots.txt, Google možda neće moći da pročita:

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

Google zato eksplicitno navodi da URL sa noindex pravilom mora ostati dostupan crawler-u da bi pravilo moglo da bude pročitano.

Izvor: Google Search Central — Block Search indexing with noindex.

7. X-Robots-Tag: noindex nije samo za HTML

Za HTML je najpoznatiji robots meta tag.

Ali za resurse poput:

• PDF dokumenata;
• slika;
• video fajlova;
• drugih non-HTML resursa;

može se koristiti HTTP header:

X-Robots-Tag: noindex

8. HTTP status kodovi su deo SEO arhitekture

Search engine ne vidi samo sadržaj.

Vidi i odgovor servera.

Najvažniji statusi uključuju:

• 200 — uspešan odgovor;
• 301/308 — permanent redirect;
• 302/307 — temporary redirect;
• 404 — resurs nije pronađen;
• 410 — resurs je uklonjen;
• 5xx — problem na serveru.

Problem nastaje kada ono što stranica prikazuje i ono što server govori nisu usklađeni.

9. Soft 404: stranica izgleda kao greška, server kaže 200

Primer:

Proizvod više ne postoji.

Korisnik dobije poruku:

„Proizvod nije pronađen.“

Ali server vraća:

200 OK.

To je tipična situacija u kojoj Search sistem mora dodatno da zaključuje da se zapravo radi o nepostojećem sadržaju.

Na SPA aplikacijama ovo može biti posebno problematično kada routing i error handling ostanu potpuno na client-side JavaScript-u.

10. Redirect nije isto što i canonical

Ovo je važna tehnička razlika.

Redirect preusmerava korisnika i crawler na drugi URL.

Canonical dozvoljava da URL ostane dostupan, ali sugeriše koja verzija treba da bude primarna.

Ako stari URL više ne treba da postoji:

redirect je često logičnije rešenje.

Ako više URL-ova legitimno mora da ostane dostupno sa vrlo sličnim sadržajem:

canonical može imati smisla.

11. Canonical nije komanda

Google canonical tretira kao signal.

Možete navesti:

<link rel="canonical" href="https://example.com/glavna-stranica">

ali Google može izabrati drugu canonical verziju ako ostali signali ukazuju da je ona prikladnija.

Zato problem ne rešava samo dodavanje canonical taga.

Potrebno je da signali budu usklađeni.

12. Koji canonical signali su najjači?

Google trenutno navodi sledeću praktičnu hijerarhiju:

• redirect — jak signal;
• rel="canonical" — jak signal;
• sitemap inclusion — slabiji signal.

Signali mogu da se kombinuju.

Najčistiji setup je kada:

• interni linkovi pokazuju na canonical;
• sitemap sadrži canonical;
• canonical tag pokazuje na canonical;
• stare verzije redirectuju gde je potrebno.

Izvor: Google Search Central — Canonical URLs.

13. Self-referencing canonical

Za canonical URL je često korisno da sadrži canonical link ka samom sebi.

Na primer:

https://example.com/seo

canonical →

https://example.com/seo

Time template eksplicitno definiše preferiranu verziju.

Posebno je korisno kod sistema koji generišu:

• tracking parametre;
• filtere;
• sort parametre;
• session URL-ove.

14. Canonical chain i canonical loop

Loša implementacija može napraviti:

A → canonical B

B → canonical C

ili još gore:

A → B → A

Ne pravite od canonical-a redirect chain.

Svaka duplikat stranica treba direktno da signalizira finalnu preferiranu verziju.

15. XML sitemap: šta treba da sadrži?

Sitemap nije spisak svakog URL-a koji CMS može da generiše.

To je spisak URL-ova koje smatrate relevantnim za Search.

Idealno:

• 200 status;
• indexable;
• canonical;
• važan za Search.

Ne bi trebalo rutinski da bude pun:

• 404 URL-ova;
• redirecta;
• noindex stranica;
• duplikata;
• filter URL-ova bez Search vrednosti.

16. Sitemap limit nije jedan beskonačan fajl

Google trenutno navodi limit od:

50.000 URL-ova ili 50 MB uncompressed po sitemap fajlu.

Za veće sajtove koristi se više sitemapova i sitemap index.

Izvor: Google Search Central — Build and submit a sitemap.

17. JavaScript SEO: Google renderuje JavaScript, ali to ne znači da implementacija nije važna

Google Search koristi evergreen Chromium za rendering JavaScript-a.

Zato tvrdnja:

„Google ne vidi JavaScript.“

nije tačna.

Ali JavaScript može stvoriti dodatne tehničke probleme.

Na primer:

• sadržaj stigne tek nakon neuspelog API poziva;
• linkovi nisu pravi href linkovi;
• canonical se menja nakon rendera;
• error page vraća 200;
• robots meta se dinamički menja;
• ključan sadržaj zavisi od user interaction-a.

18. Server-side rendering, static rendering ili client-side rendering?

Nije potrebno da svaki SEO sajt koristi istu arhitekturu.

Client-side rendering može raditi.

Server-side rendering može raditi.

Static generation može raditi.

Važno je da ključni Search sadržaj bude:

• dostupan;
• stabilan;
• pravilno linkovan;
• renderabilan;
• pravilno indeksabilan.

Arhitektura treba da služi proizvodu, a ne SEO dogmi.

19. JavaScript canonical: može, ali ne komplikujte ono što može biti u HTML-u

Google može da pročita canonical koji JavaScript ubaci tokom renderinga.

Ali Google preporučuje da canonical, kada je moguće, bude definisan direktno u HTML-u.

Posebno treba izbegavati situaciju gde originalni HTML kaže:

canonical A

a JavaScript nakon rendera promeni canonical u:

canonical B.

To stvara konflikt signala.

20. Renderovani HTML je važniji od onoga što developer vidi u source fajlu

Kod JavaScript sajtova proverite:

• šta postoji u početnom HTML-u;
• šta postoji nakon rendera;
• šta Google URL Inspection prikazuje;
• da li ključni sadržaj postoji u rendered DOM-u.

Chrome DevTools i Google Search Console URL Inspection rešavaju različite delove istog problema.

21. Pagination: „Load more“ dugme nije dovoljan SEO sistem

Google crawler uglavnom ne „klikće“ dugmad da bi učitao sledeći set sadržaja.

Ako imate:

• 100 proizvoda;
• 20 proizvoda po prikazu;
• samo JavaScript „Load more“;

morate proveriti da li Google ima crawlable URL put do ostalih proizvoda.

Google za pagination preporučuje sekvencijalno povezivanje stranica kroz standardne crawlable linkove.

Izvor: Google — Pagination and incremental page loading.

22. Faceted navigation: jedan od najvećih tehničkih SEO problema e-commerce sajtova

Zamislite kategoriju patika sa filterima:

• brend;
• veličina;
• boja;
• pol;
• cena;
• sortiranje.

Njihove kombinacije mogu proizvesti hiljade ili milione URL-ova.

Na primer:

/patike?brand=x&color=black&size=44&sort=price

Problem nije samo duplicate content.

Problem je i crawl eksplozija.

23. Koje filter stranice treba indeksirati?

Ne postoji pravilo „indeksiraj sve filtere“ niti „blokiraj sve filtere“.

Pravo pitanje je:

da li konkretna kombinacija ima stabilan i stvaran Search intent?

Na primer:

„muške crne Nike patike“

može imati organski smisao.

Ali:

„sort=price&view=48&session=123“

uglavnom nema.

Google posebno upozorava da faceted navigation može proizvesti praktično beskonačan URL prostor i usporiti otkrivanje važnog sadržaja.

Izvor: Google Crawling Infrastructure — Faceted navigation.

24. Crawl budget: kome treba da bude prioritet?

Crawl budget nije tema kojom svaki mali sajt treba svakodnevno da se bavi.

Postaje mnogo važniji kada postoji:

• veliki broj URL-ova;
• često menjanje sadržaja;
• veliki e-commerce katalog;
• parametarski URL-ovi;
• faceted navigation;
• veliki broj duplikata;
• server performance problemi.

Google crawl budget opisuje kroz:

• crawl capacity limit;
• crawl demand.

Izvor: Google Crawling Infrastructure — Crawl budget.

25. Crawl budget optimizacija ne znači blokirati nasumično pola sajta

Prvi korak je bolji URL inventory.

Identifikujte:

• duplikate;
• filtere;
• stare URL-ove;
• beskonačne kalendare;
• interne search stranice;
• parametre;
• stare staging URL-ove.

Zatim odlučite šta:

• treba da ostane;
• treba da se redirectuje;
• treba da bude noindex;
• ne treba da se crawluje;
• treba potpuno ukloniti.

26. Internal architecture: koliko klikova deli homepage od važnog sadržaja?

Interni linkovi imaju dve funkcije.

Za korisnika:

navigacija.

Za Search sistem:

discovery, kontekst i hijerarhija.

Važne komercijalne stranice ne treba da budu izolovane duboko u strukturi bez relevantnih internih linkova.

Na primer, ovaj tehnički SEO vodič prirodno podržava glavnu SEO uslugu, ali i specifične teme poput optimizacije brzine sajta.

27. Orphan pages

Orphan stranica postoji na sajtu, ali nijedna relevantna interna stranica ne linkuje ka njoj.

Možda postoji u sitemapu.

Možda je Google pronađe.

Ali sa arhitektonske strane šaljete signal:

„Ova stranica nije deo normalnog korisničkog puta.“

Važne SEO stranice treba integrisati u stvarnu strukturu sajta.

28. Breadcrumbs nisu samo vizuelna dekoracija

Breadcrumb struktura može pomoći:

• korisniku da razume gde se nalazi;
• internom povezivanju;
• jasnijoj hijerarhiji;
• structured data implementaciji.

Posebno su korisni na velikim:

• e-commerce;
• publishing;
• directory;
• knowledge-base sajtovima.

29. Structured data: objasnite entitet, ne spamujte schema markup

Structured data daje pretraživaču dodatne eksplicitne informacije o sadržaju.

Na primer:

• Article;
• Organization;
• Product;
• LocalBusiness;
• BreadcrumbList;
• Person.

Ali schema nije ranking prečica.

Google navodi da validan structured data može učiniti stranicu podobnom za određene rich result prikaze, ali prikaz nije garantovan.

Izvor: Google Search Central — Structured data.

30. Structured data mora da opisuje stvarni sadržaj

Nemojte dodavati:

• lažne reviews;
• izmišljene ocene;
• FAQ koji korisnik ne vidi;
• product price koji nije na stranici;
• organization podatke koji nisu tačni.

Bolje je imati manje, ali precizno implementiranih podataka nego ogroman JSON-LD koji ne odgovara stranici.

31. Core Web Vitals jesu tehnički SEO tema — ali nisu ceo tehnički SEO

LCP, INP i CLS su važni za korisničko iskustvo.

Ali sajt može imati odličan Core Web Vitals rezultat i istovremeno:

• pogrešan canonical;
• blokirane stranice;
• lošu internu strukturu;
• duplicate URL probleme;
• neispravan sitemap.

Zato ne treba poistovećivati:

technical SEO = PageSpeed.

Za performance deo pogledajte poseban vodič Optimizacija brzine sajta.

32. Mobile SEO: responsive nije jedini tehnički kriterijum

Mobile iskustvo treba testirati kao realan korisnički scenario.

Proverite:

• da li sadržaj postoji i na mobile verziji;
• da li navigacija funkcioniše;
• da li CTA ostaje dostupan;
• da li interstitial prekriva sadržaj;
• da li JS guši slabiji uređaj;
• da li elementi menjaju raspored.

33. HTTPS i mixed content

HTTPS je danas osnovna infrastrukturna higijena.

Ali migracija na HTTPS može ostaviti:

• HTTP interne linkove;
• HTTP canonicale;
• mixed-content assete;
• duple HTTP/HTTPS URL-ove;
• pogrešne sitemap URL-ove.

Proverite ceo signal chain, ne samo da li browser pokazuje katanac.

34. Migracije: trenutak kada se tehnički SEO najlakše pretvara u poslovni problem

Migracija može uključiti:

• promenu domena;
• promenu CMS-a;
• promenu URL strukture;
• HTTP → HTTPS;
• redizajn;
• spajanje sajtova.

Najveća greška je uključiti SEO tim dva dana pre launch-a.

SEO treba da učestvuje pre nego što se finalizuju:

• URL struktura;
• redirect mapa;
• navigation;
• template-i;
• canonical logika;
• sitemap;
• staging pravila.

35. Staging: jedan mali checkbox može indeksirati ceo razvojni sajt

Staging okruženje treba zaštititi od javnog indeksiranja.

Ali nakon launch-a proverite da zaštita nije preneta na produkciju.

Klasičan scenario:

novi sajt izgleda savršeno, ali ima sitewide noindex.

Zato launch audit mora proveriti:

• robots meta;
• robots.txt;
• canonical;
• HTTP status;
• sitemap;
• analytics;
• Search Console.

36. Server log analiza: šta Googlebot stvarno radi, ne šta mislimo da radi

SEO crawler simulira strukturu sajta.

Server log pokazuje stvarne requestove.

Log analiza može odgovoriti:

• koje URL-ove Googlebot najčešće crawluje;
• da li troši crawl na filtere;
• koji statusi se vraćaju;
• da li važni URL-ovi dobijaju crawl;
• da li postoje crawl spike-ovi.

Na velikom sajtu to može biti mnogo vrednije od još jednog generičkog crawler exporta.

37. Search Console nije samo alat za pozicije

Za tehnički SEO posebno su korisni:

• URL Inspection;
• Page Indexing;
• Sitemaps;
• Core Web Vitals;
• Enhancements / rich result reports;
• Manual Actions;
• Security Issues.

Search Console treba čitati kao Search dijagnostički sistem, ne samo kao keyword dashboard.

38. GSC signal za DA.org.rs

39. Šta prvo rešavati? Technical SEO priority framework

Najveća greška tehničkog audita je tretirati svaki warning kao jednako važan.

Nije.

40. Ne popravljajte SEO audit redom kojim crawler prikazuje greške

SEO alat može prijaviti:

• 4.000 „issues“;
• 1.500 warnings;
• 300 notices.

To ne znači da imate 5.800 SEO problema.

Možda imate:

jedan pogrešan template koji proizvodi 5.000 instanci iste greške.

Tehnički SEO ekspert treba da pronađe root cause.

41. Jedan broken canonical može biti važniji od 5.000 missing alt atributa

Prioritet određujemo prema:

• broju pogođenih relevantnih URL-ova;
• važnosti tih URL-ova;
• crawl/index posledici;
• business vrednosti;
• verovatnoći problema;
• trošku implementacije.

42. Technical SEO checklist

43. Šta ne treba raditi?

44. Kako DA pristupa tehničkom SEO-u?

Ne počinjemo od pitanja:

„Koliko grešaka možemo da pronađemo?“

Počinjemo od:

„Koje tehničko usko grlo trenutno ograničava Search rezultat?“

To može biti:

• indexability;
• crawl waste;
• JavaScript;
• architecture;
• migration;
• performance;
• template problem.

Zatim probleme rangiramo prema:

impact × coverage × effort × risk.

Za tehničke probleme koji zahtevaju izmenu sajta SEO ne ostaje odvojen od developmenta. Zato DA pristup povezuje SEO sa web razvojem kada je implementation deo problema.

45. Tehnički SEO i AI Search

ChatGPT Search, Google AI i drugi novi discovery sistemi ne znače da tehnička osnova prestaje da bude važna.

Naprotiv.

Javni sadržaj mora da bude:

• dostupan crawlerima;
• stabilan;
• jasno strukturiran;
• pravilno povezan;
• tehnički dostupan kao izvor.

Platform-specific deo za OpenAI obradili smo u vodiču Kako optimizovati sajt za ChatGPT Search.

Zaključak: tehnički SEO je dobar kada ga korisnik i content tim gotovo ne primećuju

Najbolja tehnička infrastruktura nije ona koja proizvodi najveći audit report.

To je ona koja omogućava da:

• važni URL-ovi budu lako otkriveni;
• crawler pristupi sadržaju;
• Search razume canonical verziju;
• JavaScript ne skriva ključne informacije;
• duplikati ne stvaraju crawl haos;
• migracije čuvaju postojeće signale;
• korisnik dobije brz i stabilan sajt.

Tehnički SEO nije odvojen od sadržaja.

On pravi infrastrukturu kroz koju sadržaj dobija šansu da bude pronađen.

Zato redosled treba da bude:

pronađi blocker → utvrdi uzrok → odredi prioritet → implementiraj → proveri Search rezultat.

Ne:

pokreni crawler → popravi sve što je crveno → nadaj se rastu.

Ako želite kompletnu dijagnostiku tehničke, sadržajne i authority strane sajta, pogledajte SEO analizu sajta. Za kontinuiranu optimizaciju pogledajte SEO usluge DA.