Zakaj strani niso indeksirane
Neindeksirane strani se ne morejo prikazovati v Googlu.
Tehnični SEO (technical SEO) oziroma tehnična SEO optimizacija je urejanje vsega, kar Googlu in AI iskalnikom omogoči, da vašo stran najdejo, izrišejo, razumejo in indeksirajo. Vsebina in povezave pridejo na vrsto šele, ko ta osnova deluje.
Tehnična napaka redko povzroči padec čez noč. Veliko pogosteje tiho odreže del strani iz Googla, na primer kategorije z oznako noindex ali članke, ki jih ni v sitemapu.
Vodič je namenjen lastnikom, direktorjem, vodjem marketinga in razvijalcem, ki želijo vedeti, kaj preveriti, kaj popraviti najprej in kako to preverite sami v Search Console.
Dodali smo lasten pregled javnih strani 68 slovenskih podjetij in checklist z 32 točkami po resnosti, ki ga lahko odkljukate kar v članku.
Tehnični SEO skrbi za infrastrukturo strani: crawling, izris, indeksiranje, hitrost, varnost in strukturo. On-page SEO ureja naslove in besedila, off-page pa povezave in omembe znamke.
Razliko najlažje razložimo s trgovino. Vsebina je blago, tehnični SEO pa vrata, luči in police trgovine. Če so vrata zaklenjena, kupec blaga ne vidi, tudi če je odlično.
Tehnični SEO je v letu 2026 pomemben tudi za AI iskanje. ChatGPT, Gemini in Googlovi AI povzetki uporabljajo vire, ki jih njihovi crawlerji lahko preberejo. Stran, ki jo Google težko izriše, praviloma težko navede tudi AI.
V glavnem vodiču smo tehnični SEO povzeli v poglavju kaj mora biti tehnično urejeno. Tu gremo v podrobnosti, ki jih potrebujete pri izvedbi.
Enkraten pregled stanja je SEO analiza, ki zajame tudi vsebino in povezave. Ta članek je nadaljevanje za tehnični del: kako napake popravite in kako preprečite, da se vrnejo.
Septembra 2026 smo pregledali javne strani 78 slovenskih podjetij iz industrije, trgovine, financ, energetike, turizma in prehrane. Analizirali smo jih 68, preostale so nam vrnile blokado ali napako.
Na vsaki strani smo preverili vrsto stvari, ki jih lahko vidi vsak crawler. Rezultat je spodnja meja, saj smo gledali samo domačo stran in eno podstran.
53 % strani ima vsaj eno od sedmih preverjenih napak, 24 % vsaj dve. Verig preusmeritev pri tem nismo šteli, ker dva skoka nista resna napaka.
Med sedmimi napakami je najpogostejši canonical (31 %). 22 % domačih strani ga nima, pri 9 % pa ne kaže na samo stran. Podobno pogost je napačen odgovor za neobstoječ URL (32 %, če štejemo tudi preusmeritve), sledi robots.txt brez vrstice Sitemap (28 %).
Dobra novica: nobena pregledana domača stran nima oznake noindex in vse razen ene preusmerijo HTTP na HTTPS. Osnovna varnost je torej urejena skoraj povsod.
Največ rezerve je pri hitrosti. Samo 19 % slik na domačih straneh je v formatu WebP ali AVIF, 81 % strani pa ima vsaj polovico slik brez mer width in height.
Google stran obdela v treh korakih. Najprej jo crawler (Googlebot) prenese, nato jo izriše, na koncu jo indeksira, kar pomeni, da jo shrani v bazo, iz katere izbira rezultate.
Pri crawlanju Googlebot najprej prebere robots.txt in preveri statusno kodo. Iz HTML-ja pobere povezave <a href> in jih doda v vrsto za naslednje obiske.
Pri izrisu Chromium izvede JavaScript, kot bi to naredil brskalnik. Pri tem ne klikne gumbov in ne drsi po strani, zato vsebina, ki se pokaže šele ob interakciji, pogosto ostane nevidna.
Google je decembra 2025 v dokumentacijo dodal dve pojasnili. Strani, ki ne vrnejo kode 200, morda sploh ne gredo v izris, kanonizacija pa poteka pred izrisom in po njem.
Stanje »Odkrito, trenutno ni indeksirano« pomeni, da Google URL pozna, a ga še ni obiskal. Pri večjem številu takih strani je vzrok pogosto šibko notranje povezovanje ali preobremenjen strežnik.
Stanje »Preiskano, trenutno ni indeksirano« pomeni, da je Google stran obiskal in se odločil, da je ne doda. Tu je vzrok običajno vsebina: podvojena, tanka ali manj koristna od drugih strani na isto temo.
robots.txt je besedilna datoteka v korenu domene, ki crawlerjem pove, katerih poti naj ne obiskujejo. Od leta 2022 je standard zapisan v RFC 9309, ki ga upoštevajo Google in večina resnih crawlerjev.
Najpomembnejše pravilo je preprosto. Crawler upošteva samo najbolj specifično skupino User-agent, ki ustreza njegovemu imenu, splošna skupina z zvezdico zanj takrat ne velja več.
Zato pazite, ko dodate skupino za en bot, na primer za AI crawler. Pravila iz splošne skupine morate v novo skupino ponoviti, sicer bot sme obiskati tudi poti, ki ste jih želeli zapreti.
Znotraj skupine velja najdaljše ujemajoče se pravilo. Allow: /kategorija/pece/ premaga Disallow: /kategorija/, ker je daljše in bolj natančno.
Google prebere največ 500 KiB datoteke in vsebino za tem mejnikom prezre. Če robots.txt vrne napako strežnika 5xx, Google prvih 12 ur ne crawla nič, zato je dosegljivost te datoteke enako pomembna kot njena vsebina.
Crawl budget je število URL-jev, ki jih Google na vaši strani želi in zmore obiskati v določenem času. Za večino slovenskih podjetij ni omejitev, čeprav o njem veliko beremo.
Google zapiše okvirne pragove. Z crawl budgetom se ukvarjajte pri več kot milijon straneh, ki se spreminjajo tedensko, ali pri več kot 10.000 straneh, ki se spreminjajo dnevno. Tretji znak je veliko URL-jev s stanjem »Odkrito, trenutno ni indeksirano«.
Spletna trgovina s 3.000 izdelki ga običajno ne potrebuje. Ista trgovina s filtri po barvi, velikosti in ceni pa lahko ustvari milijone kombinacij URL-jev, ki porabijo obisk za strani brez vrednosti.
Zato pri trgovinah najprej pogledamo, koliko URL-jev Google dejansko obišče. Poročilo Crawl stats v nastavitvah Search Console pokaže zahteve na dan, odzivni čas in deleže statusnih kod. Če je večina zahtev na filtrih, je to znak za ukrepanje.
Noindex ni dober način za varčevanje s crawl budgetom. Google mora stran obiskati, da oznako vidi, zato za filtre, ki jih ne potrebujete v iskanju, raje uporabite robots.txt.
Single-page frontend (SPA) je stran, kjer JavaScript v brskalniku izriše vso vsebino in menja poglede brez nalaganja nove strani. Tako so zgrajene številne sodobne trgovine in aplikacije, na primer na ogrodjih React, Vue ali Angular.
Google JavaScript izvede, a z omejitvami. Vsaka stran mora počakati v vrsti za izris, vsaka napaka v skripti pa lahko pomeni prazno stran v indeksu.
Najbolj zanesljiva rešitev je izris na strežniku (SSR, server-side rendering) ali vnaprej izrisane strani. Takrat crawler dobi celotno vsebino že v prvem HTML-ju, kar pomaga tudi AI crawlerjem, ki JavaScripta pogosto sploh ne izvedejo.
Za nadzor indeksiranja imate tri orodja. Noindex stran izključi, canonical pove, katera od podobnih strani je glavna, statusna koda pa pove, ali stran sploh obstaja.
Noindex je oznaka v HTML-ju ali glavi X-Robots-Tag. Primerna je za košarico, prijavo, zahvalne strani in interne rezultate iskanja. Strani z noindex ne blokirajte v robots.txt, sicer crawler oznake nikoli ne vidi.
Canonical je namig, ki ga Google upošteva skupaj z drugimi signali. Vsaka stran naj ima absoluten canonical nase, podvojene različice pa kažejo na glavno.
Google canonical preglasi, ko mu nasprotujejo drugi signali. Če sitemap in notranje povezave kažejo na drugo različico kot canonical, Google izbere sam, kar v Search Console vidite kot »Dvojnik; Google je izbral drugo kanonično stran kot uporabnik«.
| Koda | Kaj naredi Google | Kdaj jo uporabite |
|---|---|---|
| 200 | Stran lahko indeksira. | Vsaka prava stran. |
| 301 / 308 | Signale prenese na nov URL. | Trajna selitev, druga različica domene. |
| 302 / 307 | Dlje obdrži stari URL. | Res začasni primeri. |
| 404 / 410 | URL izpade iz indeksa. | Stran ne obstaja in nima naslednice. |
| 200 brez vsebine | Označi kot programsko napako 404. | Nikoli. |
| 429 / 5xx | Upočasni crawlanje, trajne napake izpadejo. | 503 samo za kratko vzdrževanje. |
V našem pregledu 66 % strani za neobstoječ URL vrne pravilno kodo 404 ali 410. Kar 25 % jih preusmeri, večinoma na domačo stran, 7 % pa vrne 200.
Preusmeritev vsega na domačo stran se zdi prijazna do uporabnika. Google jo lahko obravnava kot programsko napako 404, uporabnik pa ne ve, da iskane strani ni več. Preusmeritev 301 na vsebinsko ustrezno naslednico je v redu, sicer je boljša stran 404 z iskalnikom in povezavami na kategorije.
Ista vsebina na več URL-jih razdeli signale in zmede Google. Najpogostejši vzroki so končna poševnica, velike črke, sledilni parametri, filtri in različice domene.
Pogosta napaka je, da je vsaka stran dosegljiva s poševnico in brez nje, obe z odzivom 200 in brez preusmeritve. Če canonical kaže na eno različico, sitemap pa oddaja drugo, Google indeksira nedosledno.
Popravek ima tri korake: 301 z ene različice na drugo, sitemap s kanoničnimi naslovi in notranje povezave na isto različico. Vsi trije signali morajo kazati v isto smer.
V našem pregledu 38 % strani streže podstran s poševnico in brez nje, obe s kodo 200. Večina ima vsaj canonical na eno različico, 11 % pa nima niti tega.
Fasetna navigacija so filtri v trgovini, na primer barva, velikost in cena. Vsaka kombinacija ustvari nov URL, zato iz 200 izdelkov hitro nastane več deset tisoč naslovov.
Google je decembra 2024 objavil ločeno dokumentacijo za fasete. Če filtriranih strani ne potrebujete v iskanju, crawlanje ustavite v robots.txt, na primer z Disallow: /*?*barva=. Canonical in nofollow sta po Googlovih besedah manj učinkovita.
Nekatere kombinacije pa imajo iskanja, na primer »bele vgradne pečice«. Take izberite ročno in jim dajte statičen URL, lasten naslov in besedilo, da postanejo prave landing page kategorije.
Google od leta 2019 ne uporablja oznak rel=next in rel=prev. Vsaka stran paginacije naj ima canonical nase in prave povezave na naslednjo stran. Canonical vseh strani na prvo stran je napaka, ker skrije izdelke na drugih straneh.
Preusmeritev pošlje uporabnika in crawler z enega URL-ja na drugega. Trajna preusmeritev (301 ali 308) prenese signale na nov naslov, začasna (302 ali 307) pa pusti stari naslov dlje v indeksu.
Veriga nastane, ko se preusmeritve naberejo skozi leta. Stari naslov preusmeri na vmesnega, ta pa na končnega. Google sledi do deset skokom, vsak skok pa doda čakanje in možnost napake.
V našem pregledu 59 % strani potrebuje dva skoka iz vsaj ene različice naslova, na primer iz http brez www prek https brez www do https z www. To ni resna napaka, popravek pa je preprost.
Pri 24 % strani je v verigi vsaj ena začasna preusmeritev. Za trajne selitve uporabite 301 ali 308, 302 pa samo za res začasne primere, kot je vzdrževanje.
Če se članki preselijo na nove naslove, stari naslovi pa ne dobijo preusmeritev 301, Google še naprej prikazuje stare naslove, nove pa lahko tedne ignorira.
Pogost vzrok je, da seznam člankov in meni še kažeta na stare naslove, frontend pa za neobstoječo stran vrne 200. Pri selitvi zato vedno pripravimo tabelo star URL, nov URL in jo preverimo pred objavo in po njej, skupaj z notranjimi povezavami.
Več o selitvah in prenovah smo zapisali v članku SEO pri prenovi spletne strani. Največ obiska se izgubi prav pri prenovi.
XML sitemap je seznam URL-jev, ki jih želite v Googlu. Google ga uporabi za odkrivanje strani, predvsem novih in globoko skritih. Sitemap Googlu pomaga, da za stran izve, indeksiranje pa je še vedno njegova odločitev.
Omejitve so jasne. En sitemap ima lahko največ 50.000 URL-jev ali 50 MB nestisnjene velikosti. Večje strani uporabijo indeksno datoteko (sitemap index), ki našteje več sitemapov.
Na mednarodni spletni trgovini smo pri preverjanju sitemapa opazili, da je veja sitemapa z vsebinami padla s 77 slovenskih URL-jev na enega samega. Ta je bil domača stran drugega trga.
Nihče sitemapa ni spreminjal namenoma, napako je povzročila nastavitev generatorja sitemapa. Kako tak primer poteka pri prenovi strani, smo opisali v članku SEO pri prenovi spletne strani.
V našem pregledu 16 % strani nima dosegljivega in veljavnega sitemapa. Od najdenih jih 12 % nima lastmod, pri 11 % pa prvi URL v sitemapu ne vrne kode 200.
Arhitektura je način, kako so strani povezane med seboj. Google pomembnost strani sklepa tudi iz tega, koliko notranjih povezav kaže nanjo in kako daleč je od domače strani.
Dobro pravilo je, da so pomembne strani največ tri klike od domače strani. Izdelek na deveti strani paginacije je lahko deset klikov globoko, zato ga Google obišče redko.
Osirotela stran (orphan page) je stran, na katero ne kaže nobena notranja povezava. Najdete jo tako, da primerjate URL-je iz sitemapa s tistimi, ki jih najde crawler, na primer Screaming Frog.
Članek je lahko objavljen in v sitemapu, Google pa ga ne pozna. Pregled URL-ja pokaže, da URL Googlu ni znan, čeprav so sosednji članki indeksirani.
Pogost vzrok je, da na članek ne kaže nobena notranja povezava. Rešitev sta dve povezavi z ustreznih strani, na primer s seznama člankov in s sorodne strani. Sitemap sam ni dovolj.
Za notranje povezave uporabljajte opisna sidra. »Cene tekaških čevljev« Googlu pove več kot »kliknite tukaj«. Navigacija in drobtinice naj bodo v HTML-ju, da jim crawler lahko sledi.
Core Web Vitals so trije Googlovi kazalniki uporabniške izkušnje. Od 12. 3. 2024 so to LCP, INP in CLS, INP pa je takrat zamenjal starejši FID.
| Kazalnik | Dobro | Izboljšati | Slabo |
|---|---|---|---|
| LCP | do 2,5 s | do 4 s | nad 4 s |
| INP | do 200 ms | do 500 ms | nad 500 ms |
| CLS | do 0,1 | do 0,25 | nad 0,25 |
Stran je uspešna, ko vse tri meritve dosežejo prag na 75. percentilu obiskov, ločeno za telefon in računalnik. To pomeni, da mora hitra izkušnja veljati za tri četrtine uporabnikov.
Google uporablja podatke resničnih uporabnikov Chroma (CrUX, Chrome User Experience Report) za zadnjih 28 dni. Lighthouse in PageSpeed Insights pa v laboratoriju simulirata en obisk.
Oba sta koristna za različne stvari. Laboratorijski test pokaže vzrok, podatki uporabnikov pa, ali se je stanje res izboljšalo. Ker gre za 28-dnevno povprečje, popravek v poročilu vidite šele po nekaj tednih.
Ocena 100 v Lighthouse ni cilj. Stran z oceno 70 lahko pri uporabnikih prestane vse tri pragove, stran z oceno 95 pa ne, če ima veliko počasnih telefonov.
LCP (Largest Contentful Paint) meri, kdaj se izriše največji element na zaslonu. Pri večini strani je to glavna slika, zato so popravki pogosto preprosti.
Pogosta napaka so slike, naložene v večji velikosti, kot so prikazane, na primer 2.500 px široka slika v okvirju širine 445 px.
Pomanjšanje na dvojno prikazno širino lahko zmanjša prenos slik tudi za okoli dve tretjini, brez vidne razlike. Popravek ne zahteva razvijalca, samo ponovno nalaganje slik v pravi velikosti.
V našem pregledu slovenskih strani ima glavno sliko označeno s fetchpriority samo 22 % strani, preconnect pa uporablja 16 %.
INP (Interaction to Next Paint) meri, kako hitro se stran odzove na klik, dotik ali tipko, in to ves čas obiska, tudi po prvem kliku. Dober INP je do 200 ms.
Glavni vzrok slabega INP so dolga opravila (long tasks), ki zasedejo brskalnik za več kot 50 ms. Največkrat jih povzročijo skripte tretjih strani: klepetalniki, orodja za analitiko, pasice za piškotke in oglasne oznake.
CLS (Cumulative Layout Shift) meri, koliko se vsebina premika med nalaganjem. Najpogostejši vzrok so slike brez mer width in height, ki jih ima v našem pregledu 81 % strani na vsaj polovici slik.
Drugi vzroki so pasice, ki se pojavijo nad vsebino, in pisave. Z font-display: swap in rezerviranim prostorom za pasice preprečite večino premikov.
Vsaka domena ima vsaj štiri različice: s www in brez, prek http in https. Vse morajo z eno preusmeritvijo pripeljati na isti končni naslov.
V našem pregledu ima 9 % strani vsaj dve različici domene, ki delujeta vsaka zase. Za Google sta to dve ločeni strani z isto vsebino.
HTTPS je potrjen, čeprav majhen, signal za uvrstitev. Veliko pomembnejše je, da brskalnik strani brez HTTPS označi kot nevarne, kar odžene uporabnike.
Po selitvi na HTTPS preverite še mešano vsebino (mixed content), torej slike ali skripte, ki se še nalagajo prek http. Ko vse deluje, dodajte glavo HSTS, ki brskalniku pove, naj http preskoči.
Google je prehod na mobile-first indeksiranje zaključil za vse strani. Za indeksiranje in razvrščanje uporablja mobilno različico strani, tudi za uporabnike na računalniku.
Pri odzivnih straneh je to redko težava. Težave nastanejo, ko mobilna različica skrije vsebino, na primer opise izdelkov, tabele ali strukturirane podatke, ki so na namizju vidni.
Strukturirani podatki so oznake v kodi (najpogosteje JSON-LD po slovarju Schema.org), ki Googlu opišejo, kaj je na strani. Nekateri prinesejo obogaten rezultat, na primer ceno in zvezdice pod izdelkom.
Google seznam podprtih vrst v zadnjih letih krči. Za čistejši prikaz rezultatov je ukinil HowTo, FAQ in vrsto manj uporabljenih oznak.
Poglejte vrstico Why.
V prevodu: FAQ obogateni rezultati se od 7. 5. 2026 v Googlu ne prikazujejo več. Že od avgusta 2023 so bili omejeni na uradne vladne in zdravstvene strani.
Oznak FAQPage vam ni treba odstraniti. Google zapiše, da neuporabljeni strukturirani podatki ne škodijo, pomagajo pa pri razumevanju strani, tudi v AI iskanju.
Za podjetja so v letu 2026 najbolj uporabne oznake Organization, WebSite, Breadcrumb, Product in Article, za lokalna podjetja še LocalBusiness. V našem pregledu 47 % domačih strani nima nobenih oznak JSON-LD.
Test obogatenih rezultatov (Rich Results Test) pokaže, katere oznake Google prepozna in ali so upravičene do obogatenega rezultata. Validator Schema.org preveri vse vrste, tudi tiste, ki jih Google ne prikazuje.
Na eni od domačih strani smo našli blok JSON-LD s praznim objektom in drobtinico brez imena. Search Console je javljal napako »Unnamed item«. Takrat ne dodajte drugega bloka, dokler prvi ni popravljen, sicer Google dobi dva nasprotujoča si opisa istega podjetja.
Hreflang je oznaka, ki Googlu pove, katera jezikovna ali tržna različica strani je namenjena kateremu uporabniku. Slovenski uporabnik tako vidi slovensko stran, hrvaški hrvaško, četudi sta si vsebinsko podobni.
Najpogostejša napaka so manjkajoče povratne povezave. Če slovenska stran kaže na hrvaško, hrvaška pa nazaj ne, Google oznako prezre. Blok mora biti enak na vseh različicah, vključno s sklicem nase.
V našem pregledu hreflang uporablja 41 % strani. Od teh jih 21 % ima vsaj eno očitno napako: manjka sklic nase, povratna povezava ali pa je koda jezika napačna.
Pri slovenskih straneh smo naleteli tudi na oznako si namesto sl. Koda jezika sledi standardu ISO 639-1, kjer si pomeni singalščino. Regija sledi ISO 3166-1, zato je en-UK neveljavna, pravilna pa en-GB.
Oznaka x-default je neobvezna. Priporočamo jo za stran z izbiro trga ali za različico, ki velja, ko nobena druga ne ustreza.
Na mednarodnih straneh se zgodi, da hreflang sploh ni nastavljen. Na enterprise platformah je to pogosto sprememba, ki jo lahko izvede samo razvojna ekipa, zato jo načrtujemo kot projekt z roki in odgovorno osebo.
Log datoteka strežnika zapiše vsako zahtevo, tudi vsak obisk Googlebota. Pokaže, katere URL-je Google res obiskuje, kako pogosto in kakšen odgovor dobi.
Search Console pokaže vzorec in povzetek. Logi pokažejo vsak posamezen obisk, zato so zelo koristni pri velikih trgovinah, selitvah in težavah z indeksiranjem.
Pri analizi logov preverite, ali je obiskovalec res Googlebot. Ime v glavi User-Agent lahko ponaredi vsak, pravega Googlebota pa potrdite z obratnim DNS ali z Googlovimi objavljenimi razponi IP.
Zunanja SEO orodja včasih javijo noindex, ker jim zaščita pred boti vrne blokado 403 z oznako noindex v glavi. Pravi Googlebot pa ni blokiran, kar potrdi Pregled URL-ja v Search Console.
Zato pri takih opozorilih vedno najprej preverimo statusno kodo.
AI crawlerji, kot so GPTBot, OAI-SearchBot, ClaudeBot in PerplexityBot, prav tako berejo robots.txt. Nekateri zbirajo podatke za učenje modelov, drugi iščejo vire za odgovore v živo.
Za večino podjetij, ki želijo biti omenjena v ChatGPT in Perplexity, priporočamo, da iskalnim botom (OAI-SearchBot, PerplexityBot) dostop dovolite. Odločitev za bote, ki zbirajo podatke za učenje, je poslovna.
AI crawlerji JavaScripta pogosto ne izvedejo. Zato je vsebina v izvornem HTML-ju zanje še pomembnejša kot za Google. Podrobno smo to opisali v vodiču GEO optimizacija, skupaj s pregledom robots.txt večjih slovenskih strani.
Vsak popravek preverite z orodjem, ki vidi stran tako kot Google. Brskalnik in razvijalčev računalnik pogosto pokažeta drugo sliko, ker imata piškotke, prijavo ali drugo različico strani.
Po popravku v poročilu Strani uporabite gumb »Potrdi popravek«. Google nato ponovno preveri prizadete URL-je, kar običajno traja od nekaj dni do nekaj tednov.
Search Console je brezplačno Googlovo orodje in edini vir, ki pokaže, kako vašo stran vidi Google. Za tehnični SEO je šest poročil dovolj za redno spremljanje.
Poročilo Strani (Indeksiranje strani) je najpomembnejše. Ne pričakujte, da bo seznam razlogov prazen, ker so nekateri pričakovani, na primer strani s preusmeritvijo in alternativne strani z ustrezno kanonično oznako. Iščite nenadne spremembe.
V poročilu Zemljevidi spletnih mest primerjajte število najdenih URL-jev z mesecem prej. Tako bi pravočasno opazili tudi primer izgubljene veje sitemapa, opisan zgoraj.
Poročilo Osnovni spletni kazalniki (Core Web Vitals) združuje podobne URL-je v skupine. Popravek na predlogi kategorije tako izboljša vse kategorije hkrati.
Hero na vrhu članka prikazuje, kako se poročilo Strani spreminja po popravkih. Zaporedje je povzeto po naših projektih, trgovina in številke pa so izmišljene.
Seznam uporabljamo pri vsakem tehničnem pregledu. Točke smo razvrstili v osem skupin in tri stopnje resnosti, da veste, kaj popraviti najprej.
Spodaj je isti seznam z razlago vsake točke. Odkljukajte, kar je pri vas urejeno, in pokazal se bo delež urejenega ter tri naloge, s katerimi začnete.
Urejeno po resnosti
0 %
Kritično šteje 5, visoko 3, srednje 1 točko.
Odprtih kritičnih točk: 6.
Tehnični pregled pogosto najde 30 ali več težav. Razvojna ekipa pa ima omejen čas, zato je vrstni red pomembnejši od dolžine seznama.
Vsako težavo ocenimo po dveh merilih. Vpliv pove, koliko strani ali obiska prizadene, trud pa, koliko ur razvijalca in usklajevanja potrebuje. Najprej pridejo težave z velikim vplivom in majhnim trudom.
| Težava | Resnost | Kako zaznate | Kako popravite | Kdo |
|---|---|---|---|---|
| Sitemap trga vsebuje samo del pomembnih strani | Kritično | Zemljevidi spletnih mest v Search Console, mesečna primerjava | Nastavitev generatorja sitemapa za trg, nato ponovna oddaja | Razvojna ekipa |
| Prazen H1 in dva vidna H1 na domači strani | Srednje | Ročni pregled kode ali crawler | Popravek v urejevalniku vsebin, en vidni H1 | Mi, v CMS |
| Slike večkrat večje od prikaza | Srednje | DevTools, zavihek Network | Ponovno nalaganje slik v dvojni prikazni širini, WebP | Mi, v CMS |
Pri enterprise platformah marsičesa ne moremo spremeniti v urejevalniku vsebin. Predloge, sitemap, hreflang in preusmeritve so v rokah razvojne ekipe, besedila, naslovi in slike pa pogosto v naših.
Zato na začetku sodelovanja naredimo zemljevid: kaj popravimo sami, kaj potrebuje zahtevek in koliko časa razvojna ekipa običajno potrebuje. Hitre popravke naredimo takoj, zahtevke pa pripravimo z URL-ji in primeri, da jih ekipa lahko izvede brez dodatnih vprašanj.
Tehnični SEO je prva prioriteta pri spletnih trgovinah, straneh na več trgih, straneh s tisoči URL-jev in pred vsako prenovo ali selitvijo. Tam napaka hitro prizadene stotine strani.
Pri manjši predstavitveni strani na urejenem sistemu, kot je sodoben WordPress, je slika drugačna. Osnove so pogosto že urejene, več rezerve pa je v vsebini in lokalnem SEO.
Po našem mnenju se ne splača loviti popolne ocene v Lighthouse. Ko stran prestane Core Web Vitals pri uporabnikih, je naslednji vložek v hitrost redko najboljša naložba. Isti denar bolje porabite za vsebine ali povezave.
Tudi prenova URL-jev samo zaradi lepšega zapisa se redko splača. Vsaka selitev prinese tveganje in nekaj tednov negotovosti, zato jo raje povežite s prenovo strani.
Tehnični SEO ni projekt, ki ga enkrat zaključite. Vsaka posodobitev sistema, nov vtičnik ali prenova lahko vrne staro napako.
Vodič ne pokriva tehničnih podrobnosti posameznih sistemov (WordPress, Shopify, SAP Commerce), varnosti strežnika in nastavitve CDN. Če želite drugo mnenje o svoji strani, si oglejte našo storitev SEO in GEO optimizacija, pri izbiri izvajalca pa vam pomaga vodič kako izbrati SEO agencijo.
Kratke razlage izrazov iz tega vodiča. Z njimi lažje berete poročila in se pogovarjate z razvijalci.
Ta članek je del serije o SEO optimizaciji. Začnite pri glavnem vodiču in nadaljujte s temo, ki vas zanima.
Tehnični SEO oziroma tehnična SEO optimizacija je urejanje infrastrukture strani, da jo Google in AI iskalniki lahko najdejo, izrišejo in indeksirajo. Zajema robots.txt, sitemap, canonical, preusmeritve, hitrost, strukturirane podatke in hreflang.
On-page SEO ureja vsebino posamezne strani: naslove, besedila, slike in notranje povezave. Tehnični SEO ureja delovanje celotne strani, na primer indeksiranje, hitrost in preusmeritve.
V Search Console odprite poročilo Strani ali vpišite URL v Pregled URL-ja. Poročilo pokaže indeksirane strani in razloge, zakaj druge niso indeksirane.
Ne. robots.txt ustavi obisk crawlerja, stran pa lahko ostane v indeksu brez opisa. Za odstranitev uporabite noindex in strani ne blokirajte v robots.txt.
LCP do 2,5 s, INP do 200 ms in CLS do 0,1. Meri se na 75. percentilu obiskov resničnih uporabnikov, ločeno za telefon in računalnik.
INP meri odzivnost na vse klike in dotike med obiskom, FID pa je meril samo zakasnitev prvega. INP je FID kot Core Web Vital zamenjal 12. 3. 2024.
FAQ obogateni rezultati se od 7. 5. 2026 v Googlu ne prikazujejo več. Oznak vam ni treba odstraniti, ker ne škodijo, novih pa zaradi obogatenega rezultata ne dodajajte.
Po Googlovih pragovih pri več kot milijon straneh, ki se spreminjajo tedensko, ali pri več kot 10.000 straneh z dnevnimi spremembami. Pri trgovinah ga pogosto porabijo filtri, ki jih uredite v robots.txt.
Priporočamo da. Absoluten canonical nase Googlu jasno pove, katero različico prikazati, tudi ko se URL pojavi s parametri ali v drugi obliki.
Celoten pregled enkrat do dvakrat na leto in pred vsako prenovo. Poročila Strani, sitemap in Core Web Vitals v Search Console pa preglejte vsak mesec.
Osnove da: Search Console, sitemap, robots.txt, slike in canonical v sodobnem CMS. Za JavaScript, hreflang, selitve in velike trgovine potrebujete razvijalca ali izkušenega strokovnjaka.
Da. AI crawlerji morajo stran prebrati, mnogi pa JavaScripta ne izvedejo. Vsebina v izvornem HTML-ju in dovoljen dostop v robots.txt sta osnova za omembe v AI odgovorih.
Pregledamo indeksiranje, sitemap, preusmeritve, hitrost in vidnost v AI orodjih. Povemo, katere tri tehnične napake vas stanejo največ obiska in kdo jih lahko popravi.
Brezplačni pregled SEO in AI vidnosti
