Технички SEO аудит и чек-листа за 2026

Ово није списак подешавања која се ураде једном и више никада не проверавају. Приликом додавања нове секције, редизајна, промене платформе или додавања филтера могу се појавити нови проблеми. Корисан аудит се завршава уређеним задацима за програмера, а не само PDF фајлом.

Шта проверава технички SEO аудит?

Аудит проверава три ствари: може ли претраживач да дође до страница, може ли да изабере исправну верзију за индексирање и може ли да разуме њихов садржај. Затим проверавамо да ли сајт довољно добро функционише за корисника на телефону и да ли техничка ограничења ометају продају.

• пописање и индексирање важних URL адреса
• robots.txt, XML sitemap, canonical и hreflang за вишејезичне сајтове
• 404 грешке, 301 преусмеравања, redirect chains и канонске адресе
• LCP, INP и CLS, величина страница и учитавање слика
• мобилна верзија, навигација, интерни линкови и приступачност главног садржаја
• JavaScript rendering и садржај који се појављује тек након извршавања скрипте
• структурирани подаци у складу са стварним садржајем странице

Како се проверавају пописивање и индексирање?

Robots.txt

У robots.txt проверите да ли су блокиране важне фасцикле, CSS, JavaScript или слике. Обично се ограничавају административни панели, интерне претраге и технички директоријуми. Будите опрезни са општим правилима као што је Disallow: /, која су остала из тестног окружења, као и са аутоматским подешавањима додатака.

Проверите неколико стварних адреса помоћу URL Inspection у Google Search Console. Тако ћете видети да ли је URL адреса доступна, која је канонска верзија изабрана и да ли постоји проблем са индексирањем. Важно је да тестирате почетну страницу, услугу, производ, категорију и страницу са формуларом, а не само почетну адресу.

XML sitemap

Sitemap треба да садржи индексабилне канонске URL адресе које желите да развијате. Не додајте 404 странице, преусмеравања, странице са noindex-ом или филтере без SEO вредности. Пошаљите фајл у Search Console и проверавајте да ли се послате адресе појављују као индексиране.

Canonical, дуплирање и параметри

Филтери, сортирање, UTM параметри и различите варијанте једног производа често стварају мноштво URL адреса са истим садржајем. Canonical указује на жељену верзију, али не уклања потребу за јасном унутрашњом структуром. Треба да упућује на доступну, индексабилну и стварно еквивалентну адресу.

Интерни линкови

Важне услуге и категорије треба да буду доступне из главне навигације или са других смислено повезаних страница. Не ослањајте се само на дугмад која функционишу након JavaScript-а ако главна навигација може да садржи обичне HTML линкове. Потражите orphan pages — странице без интерног линка — и повежите их тамо где би корисник природно наставио.

Шта проверити у погледу брзине и Core Web Vitals?

Core Web Vitals се не побољшавају једним кликом на дугме. Узрок спорог сајта могу бити хостинг, велика слика, JavaScript који блокира учитавање, спољни чет, рекламни пиксели или сложен упит ка бази података. Зато упоређујте лабораторијске тестове са стварним подацима и посматрајте конкретан шаблон — страницу производа, блог, корпу или landing page.

HTTPS је обавезна основа. Проверите сертификат, преусмеравање са HTTP на HTTPS и mixed content — ресурсе који се и даље учитавају преко HTTP-а. Након миграције ажурирајте интерне линкове, canonical адресе, sitemap и подешавања за праћење.

Како се проверавају мобилна верзија и URL адресе?

Google користи мобилну верзију за пописивање и индексирање. Садржај, наслови, интерни линкови, структуре података и основне функције морају бити доступни и на телефону. Садржај скривен иза таба или акордеона није аутоматски проблем, али мобилна верзија не сме бити суштински сиромашнија од десктоп верзије.

Проверите обрасце стварним слањем, падајуће меније, претрагу, филтере и плаћање. Код онлајн продавнице у тест укључите корпу, плаћање поузећем, плаћање картицом и креирање товарног листа, ако су те функције део процеса. SEO резултат нема вредност ако корисник не може да заврши поруџбину.

URL адресе треба да буду кратке и разумљиве. Користите једну доследну структуру и цртице између речи. Не мењајте функционалну адресу без плана за 301 преусмеравање. Приликом редизајна направите табелу старих и нових URL адреса пре него што објавите сајт.

Шта се дешава код JavaScript сајта?

Код сајта изграђеног у React-у, Vue-у или другој JavaScript технологији, немојте претпоставити да је оно што види човек исто што добија Googlebot. Проверите HTML одговор пре извршавања скрипти и визуелизовану верзију. Главни наслов, текст, производи, линкови и метаподаци не смеју да зависе од неуспешног API одговора или скрипте која се учитава прекасно.

Посебну пажњу заслужују филтери, пагинација, бесконачно скроловање и интерна претрага. Ако су важни производи доступни тек након клика на дугме, Google можда неће моћи да их открије на исти начин као корисник. Направите категорије које могу да се индексирају и јасне линкове ка страницама које доносе посете из претраге.

Када schema помаже, а када одмаже?

Структурирани подаци помажу претраживачу да разуме да ли је страница услуга, производ, чланак, организација, догађај или често постављано питање. Они не гарантују проширени резултат и не замењују квалитетан садржај.

Означите само информације које се заиста виде на страници. Не додајте оцене, цене, доступност или често постављана питања која корисник не може да пронађе. Проверите синтаксу, пратите упозорења и упоредите schema са стварним садржајем о пословању.

Како да поставите приоритете проблема?

1. 01
   Прикупите приступе и почетне податке

   Потребни су Google Search Console, Google Analytics или друга аналитика, приступ CMS-у и хостингу, списак важних услуга или производа и информације о последњим изменама. Без њих се одит лако претвара у претпоставку.

2. 02
   Пописујте сајт и направите узорак

   Проверите URL адресе, статусне кодове, наслове, canonical, robots директиве, интерне линкове, слике и дуплиране шаблоне. Упоредите пронађене странице са sitemap-ом и стварним страницама које доносе упите.

3. 03
   Потврдите критичне адресе у Search Console-у

   Тестирајте репрезентативне странице помоћу URL Inspection-а. Проверите индексирање, изабрану канонску верзију, мобилно приказивање и разлоге за искључивање.

4. 04
   Направите backlog за програмера

   Сваки задатак треба да има URL или шаблон, разлог, приоритет, очекивани резултат и начин провере. На пример: „све странице са параметром X треба да упућују на категорију Y“ корисније је од „оптимизујте canonical“.

5. 05
   Проверите након измене

   Поновите пописивање, тестирајте стварне обрасце и поруџбине и пратите Search Console. Након редизајна или миграције не завршавајте проверу на дан објављивања.

Колико кошта технички SEO одит?

За мали пословни сајт основни преглед обично кошта око 300–700 евра. Одит онлајн продавнице, вишејезичног сајта или сајта са прилагођеном платформом често кошта око 700–2 000 евра. Већи системи, JavaScript апликације и миграције процењују се након прегледа броја шаблона, URL адреса, интеграција и потребних тестова.

Цена се највише мења у зависности од величине сајта, броја језичких верзија, филтера и параметара, приступа подацима, квалитета документације и тога да ли је потребно спровести исправке. Ако добијете само списак грешака, мораћете посебно да га претворите у задатке за програмера. Код SEO оптимизације одит може бити део ширег плана за структуру и садржај.

Како изгледа добар резултат одита?

Добар резултат је кратак списак ризика и јасних активности. Критични су блокирана важна страница, погрешна миграција или сајт који не може да пошаље образац. Нижи приоритет имају побољшања која не утичу на индексирање и конверзије.

За корпоративни сајт структура треба да води ка стварном упиту. За онлајн продавницу треба да одржи категорије, производе и процес куповине доступним. Код сложеног система корисно је да се SEO захтеви поставе још током израде сајта, уместо да се исправљају након објављивања. Код редизајна проверите старе адресе и преусмеравања још у фази планирања, као што је описано у оквиру редизајна сајта.

Технички SEO није одвојен од пословања. Неисправна страница услуге значи пропуштен упит, а спор checkout значи напуштену поруџбину. Зато задатке приоритизујте према ризику за видљивост и приходе, а не према томе коју грешку је најлакше исправити.