Техничка SEO контролна листа: Крајната листа за подобрување на вашиот веб-сајт

Техничка SEO контролна листа

Ползање и индексација

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

Прегледајте го извештајот за индексирање на страници во Google Search Console

Најточниот и најверодостоен начин да се анализира индексирањето на вашиот веб-сајт е да се анализира извештајот за индексирање на страници во Google Search Console.

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

Исто така, погледнете страници кои се исклучени.

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

Во табелата подолу, можете да ги видите статусите кои бараат внимание и подлабока анализа:

Статус Што	значи	Што треба да направите
Грешка при пренасочување	Google не беше во можност да го следи URL поради проблеми со пренасочувањето.	Намалете го бројот на пренасочувања (на 1-2). Избегнувајте бесконечни и кружни пренасочувања. – Уверете се дека конечната URL враќа 200 OK и не е блокирана во robots.txt/noindex.
Грешка на серверот	Серверот врати 5xx грешка.	Проверете логови на серверот. Уверете се дека сајтот не е преоптоварен. – Поправете внатрешни грешки, особено ако се повторуваат.
Откриено – не е индексирано	Гугл знае за страницата, но сè уште не ја обползал. Укажува на проблеми со ползањето на буџетот.	Уверете се дека страницата е на мапата на сајтот. Додадете внатрешни врски кон него. Оптимизирање на буџетот за ползање.
Crawled – не е индексиран	Гугл ја посетил страницата, но одлучил да не ја индексира. Обично укажува на низок квалитет на страницата.	Подобрување на квалитетот и уникатноста на содржината. Уверете се дека страницата нема дупликат. Додадете внатрешни врски кон него.
Дупликат без каноничен избран од корисникот	Google ја смета страницата за дупликат, но вие не наведовте канонски.	Проверете ги паровите на страниците и ги наведете потребните канонски или преиспитајте ја структурата на сајтот.
Дупликат, Google избрал различен канонски од корисникот	Гугл го игнорирал вашиот назначен канон.	Може да има многу причини; Треба внимателно да ги испитате податоците на страницата и да изберете најсоодветна стратегија (noindex, пренасочување, отстранување, robots.txt, промени во структурата на веб-сајтот и внатрешно поврзување).
Мек 404	Страницата изгледа “празна” или “не е пронајдена”, но враќа 200 OK статус.	Враќање на 404 или 410. Направете пренасочување. Подобрување на содржината. Блокирање од индексирање.

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

Статус	Што значи	Што треба да знаете
Алтернативна страница со соодветна канонска ознака	Гугл правилно го потврди канонскиот што го наведете.	Сè работи како што се очекуваше. Не е потребна акција. Уверете се дека сте го одредиле саканиот канон.
URL блокиран од robots.txt	Google не може да ја облезе страницата.	Проверете ја robots.txt датотеката. Дозволете пристап ако сакате да биде индексиран.
URL означен со ‘noindex’	Страницата ја има директивата noindex.	Уверете се дека noindex ознаката е поставена намерно. Ако страницата е важна, отстранете ја ознаката.
Не е пронајдена (404)	Страницата не постои.	Ако ова е важно, вратете ја страницата. Ако страницата е трајно избришана, уверете се дека нема внатрешни врски до неа.
Блокиран поради неовластено барање (401)/ Блокиран поради забранет пристап (403)	Страницата е блокирана со овластување или забранета.	Дозволете пристап ако страницата треба да биде индексирана.
Страница со пренасочување	Страницата пренасочува кон друга.	Проверете дали пренасочувањето е намерно и точно.
URL блокиран поради друг 4xx проблем	Страницата е недостапна поради 4xx грешка различна од 404 (на пример, 403, 401, 410, итн.).	Проверете го статусниот код на HTTP рачно. Поправи ги поставувањата за пристап. Поставување на точни статусни кодови или пренасочувања. Дозволете пристап за Googlebot ако е потребно.

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

Screaming Frog исто така може да помогне при анализирање на страници кои се индексирани или исклучени од индексот. За да го направите тоа, треба да го поврзете Google Search Console API пред да започнете со ползање на сајтот.
За да се поврзете, одите на Configuration -> API Access -> Google Search Console. Кликнете на Пријавите се со Google и ги следете инструкциите.

Откако ќе се поврзете, овозможете URL инспекција, и исто така можете да ја активирате опцијата за игнорирање на индексирање на URL адреси кои не можат да бидат индексирани.

Тогаш ќе можете да го видите и споредите статусот на секоја страница според Search Console (како што Google ја гледа) и нејзиниот вистински статус како што е утврдено во процесот на ползање.

Имајте на ум дека само 2000 URL на ден се достапни за секоја страница, така што овој метод е посоодветен за мали сајтови.

Проверете што има во вашиот sitemap.xml

Sitemap.xml е XML датотека која им овозможува на пребарувачите листа на страници на сајтот, како и (опционално) информации за датумот на последната измена, фреквенцијата на ажурирање и препорачаниот приоритет на ползање.

Обично се става во коренот на локацијата, на пример: https://example.com/sitemap.xml. Sitemap.xml им помага на пребарувачите да најдат нови или ажурирани страници побрзо. Покрај тоа, вклучувањето на страница во оваа датотека е еден од сигналите за одредување на канонската верзија на страницата, иако слаба.

Податотеката sitemap.xml е особено корисна за:

• нови сајтови со неколку надворешни врски;
• големи сајтови со многу страници;
• сајтови со многу медиумска содржина;
• Сајтови за вести кои се ажурираат често.

Sitemap.xml треба да ги содржи сите страници кои сакате да ги индексирате.

Можете да го користите истиот Screaming Frog или други crawlers за да ги анализирате страниците вклучени во Sitemap.xml. Во Screaming Frog, sitemap.xml може да се скенира одделно во List Mode, или може да биде вклучен во редовно скенирање на сајтот. За да го направите ова, во Configuration -> Spider -> Crawl, активирајте XML скенирање на sitemap и додадете апсолутни URL адреси на sitemaps кои сакате да ги crawl.

Не се препорачува да се користат различни онлајн сервиси за генерирање на Sitemap, бидејќи тие може да генерираат само статична мапа која нема да биде автоматски ажурирана. Оптимална опција е да се генерира sitemap.xml со користење на додатоци за CMS на кој работи сајтот, или да се напише скрипта која ја генерира мапата на сајтот според одредени услови и автоматски ја ажурира кога ќе се направат промени на сајтот.

Кога го генерирате sitemap.xml, уверете се дека вашата датотека е во согласност со протоколот sitemap.xml. Можете да користите различни онлајн валидатори за ова, како што се https://www.xml-sitemaps.com/validate-xml-sitemap.html.

Дали е потребно да се вклучат сите тагови наведени во протоколот? Не секогаш. На пример, Google ги зема предвид само <loc> и <lastmod> тагови. Бидете сигурни дека датумот во <lastmod> ознаката е точен. Ако има обиди да се манипулира со него, Google може да ја игнорира оваа ознака.

Уверете се дека нема грешки во robots.txt

Датотеката robots.txt е првото место каде што ботот за пребарување го гледа пред да ја облезе страницата. Тој одредува кои делови од страната можат или не можат да се ползаат и како резултат на тоа кои страници ќе бидат индексирани од страна на пребарувачите. Секогаш треба да се наоѓа на https://example.com/robots.txt.

Оваа датотека е алатка за управување со ползање (не индексирање!) на сајтот. Некои страници, дури и ако се блокирани во robots.txt, сепак можат да бидат индексирани (обично ако има внатрешни или надворешни врски до нив). Таквите страници (индексирани и покрај тоа што се блокирани во robots.txt) може да се видат во Google Search Console во извештајот “Индексирани, иако блокирани од robots.txt”.

Еве што треба да проверите во врска со robots.txt датотеката како дел од техничката SEO ревизија:

1. Достапност на датотеката

Датотеката треба да биде достапна на https://example.com/robots.txt и да даде 200 OK статус на одговор. Неговото отсуство, грешки при преземање или пренасочувања (301, 302, 403, 404) може да ги спречат пребарувачите правилно да ги разберат правилата за ползање на сајтот.

1. Синтакса и коректност

Проверете дали структурата на датотеката го следи стандардот. Пример за основен шаблон:

• Кориснички агент: *
• Забранет: /admin/
• Дозволено: /public/
• Карта на сајтот: https://example.com/sitemap.xml

1. Забрани и дозволи директиви

Проверете дали важните страници не се случајно забранети, на пример:

• Дома (/)
• Картички за производи (/product/)
• Блог или статии (/blog/, /articles/)

Честа грешка е блокирање на слики, стилови и скрипти при блокирање на административни фолдери. Во таков случај, треба да се наведе дека иако административната папка е блокирана, некои типови на датотеки треба да бидат отворени за скенирање. Ова често се случува на WordPress сајтовите кога папката со сите кориснички содржини, Disallow: /wp-content е блокирана.

Во овој случај, само датотеки од одреден формат можат да бидат отворени за скенирање:

• Дозволи: /wp-content/uploads/*.css
• Дозволи: /wp-content/uploads/*.js
• Дозволи: /wp-content/uploads/*.jpeg

За да го потврдите вашиот robots.txt и да ги тестирате директивите кои ќе ги додадете, можете да ја користите оваа алатка.

1. Проверка на компатибилноста со други директиви

Грешките често се јавуваат кога robots.txt се во конфликт со:

• meta tag <meta name=”robots” content=”noindex”>
• канонски

На пример, ако страницата е отворена во robots.txt но е блокирана преку noindex, таа ќе биде обходена, но нема да влезе во индексот. Ова е прифатливо, но важно е да се направи намерно.

Исто така, чест проблем е кога има други инструкции за ботови во изворниот код и истовремено блокирање на страницата во robots.txt. Роботите на пребарувачите не ги скенираат страниците блокирани во robots.txt. Тие не ги гледаат ознаките наведени во кодот, на пример, канонизација. Тоа значи, таквиот канонски едноставно ќе биде непресметан.

Проверете го вашето внатрешно поврзување

Една од клучните задачи на техничката ревизија е да се осигура дека внатрешното поврзување на сајтот работи правилно. Ова значи дека сите внатрешни врски мора да водат до вистински, постоечки страници кои се отворени за индексирање, враќаат 200 OK статус код, не содржат пренасочувања, и, што е најважно, не укажуваат на страници со 4xx/5xx грешки. На прв поглед, ова може да изгледа како мал детаљ, но во пракса, дури и неточните внатрешни врски можат негативно да влијаат:

• Ефикасноста на сканирање на веб-сајтови од страна на пребарувачите,
• Дистрибуција на внатрешната SEO тежина (PageRank),
• Корисничко искуство.

Првиот чекор во анализата е да се проверат сите внатрешни врски за грешки. Особено важно е да се идентификуваат прекршени врски кои водат до страници со 404, 410 или други грешки (како што се 403, 500).
Подолу е табела со главните типови на грешки кои можат да се појават во внатрешните врски, нивното значење и препорачани акции за да се поправат.

Тип на грешка	Што значи	Што да се направи
404	Страницата не е пронајдена	Отстранете ја врската или ја заменете со работна
403	Пристапот е забранет	Проверка на поставките за пристап
301/302	Пренасочување	Ажурирање на врската до конечната URL адреса
5xx	Грешка на серверот	Проверете го серверот или CMS

 

Исто така е важно да се анализира длабочината на хиерархијата на страницата, што значи да се утврди на кое ниво и колку кликови од почетната страница се наоѓа клучната содржина. Подобро е важните страници да не бидат подлабоки од третото ниво – ова ја зголемува нивната достапност и за пребарувачите и за корисниците.
Еден од клучните елементи на анализата е идентификување на “сирачиња” страници – оние кои немаат внатрешни врски кои укажуваат на нив. Дури и ако овие страници се вклучени во мапата на сајтот, недостатокот на внатрешни врски ги прави помалку достапни.
Дополнително, важно е да се анализираат текстовите – зборовите и фразите кои содржат линкови. Тие треба да бидат релевантни и значајни, како што текстовите им помагаат на пребарувачите да го разберат контекстот на врската.

Анализирајте ги статистиките за ползање

Анализата на статистиката на crawl е начин да се разбере како Googlebot комуницира со сајтот: кои страници се покануваат, колку често и како тоа влијае на SEO. Овие податоци се достапни во Google Search Console → Settings → Crawl Statistics. Во табелата подолу, можете да ги видите најчестите проблеми кои можете да ги откриете во овој извештај:

Прашање	Што да се бара во извештајот	Можни причини
Нагло намалување на лазењето	Помалку лазења на ден	Проблеми со пристапноста, неправилни поставувања во robots.txt, блокови, 5xx грешки
Многу 4xx и 5xx грешки	Грешки во URL	Избришани страници, скршени врски, проблеми со серверот
Времето за одговор се зголеми	>1 секунда — знак за предупредување	Проблеми со хостингот, преоптоварување на серверот
Многу 3xx пренасочувања	Пренасочувања наместо директни URL адреси	Неточни пренасочувања, синџири за пренасочување, голем број на внатрешни врски со пренасочувања
CSS/JS не се полза	Тие недостасуваат од статистиката	Блокиран од robots.txt

 

Дополнително, може да се анализираат логови на серверот. Тие ви овозможуваат да ги видите вистинските барања од ботовите за пребарување (не само Googlebot туку и Bingbot, YandexBot и други), наместо само агрегирани податоци од Google Search Console.
Ова е напреден, “суров” метод на дијагностика кој бара значително време. За да ги визуелизирате податоците, можете да користите алатки со отворен код како GoAccess или Screaming Frog Log File Analyzer.

Имплементирање на структурирани податоци

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

Главниот стандард или протокол кој се користи за структурирани податоци на веб-сајтови е Schema.org. Постојат и други протоколи, како што е OpenGraph, но се користи за социјални мрежи.
Schema.org е заеднички проект на Google, Microsoft, Yahoo и Yandex, создаден за да се развие и одржи унифициран стандард за структурирани податоци на интернет.
Schema.org вклучува стотици типови на ентитети, од кои најчесто се наведени во табелата подолу:

Категорија	Ентитет (@type)	Цел
Содржина и страници	Статија	Статија или содржина на вести
	Блог Постинг	Блог пост
	ВестиСтатија	Статија за Google News
	FAQPage	Страница со често поставувани прашања
	Како	Водич чекор по чекор
	Веб-страница	Општи информации за веб страница
Производи и понуди	Производ	Опис на производот
	Понуда	Ценовна понуда
	Агрегатна понуда	Ценовен опсег за производ од различни продавачи
Рецензии и рејтинги	Преглед	Преглед на производ или услуга
	Рејтинг	Нумерички рејтинг (често во рамките на преглед)
	Агрегатен рејтинг	Просечна оцена врз основа на повеќе рецензии
Организации и луѓе	Организација	Опис на компанија или бренд
	Локален бизнис	Локален бизнис со контакт информации и распоред
	Личност	Личност (на пример, автор на статијата, говорник, итн.)
Настани	Настан	Онлајн или офлајн настан
Навигација и структура	BreadcrumbList	Навигација со трошки
	SiteNavigationElement	Точки на главното мени
Мултимедија	Видеообјект	Видео со метаподатоци (за видео фрагменти)
	ImageObject	Слика со опис
Образование и работни места	Курс	Онлајн курс или програма за обука
	Објавување на работа	Слободно работно место (за Google for Jobs)

Се препорачува да се имплементираат структурирани податоци во JSON-LD формат. Овој блок е поставен во <главата> или <телото> на HTML документот, но не е прикажан на корисникот – се чита од ботовите за пребарување. Сите главни пребарувачи, како што се Google, Bing и Yahoo, го поддржуваат овој формат. Пример за JSON-LD код е прикажан подолу:

<script type=”application/ld+json”>

{

“@context”: “https://schema.org”,

“@type”: “Статија”,

“headline”: “Што е JSON-LD?”,

“author”: {

“@type”: “Личност”,

“name”: “Џон Смит”

},

“datePublished”: “2025-12-01”

}

</сценарио>

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

Имајте на ум дека барањата на Google за структурирани податоци за богати фрагменти малку се разликуваат од стандардот Schema.org. Често, повеќе полиња треба да бидат специфицирани отколку што го бара протоколот Schema.org. Така, ако сакате да постигнете богат фрагмент, следете ги упатствата на Google за структурирани податоци. Можете да ја проверите исправноста на имплементацијата на микроподатоци со помош на валидаторот на rich snippet.

Исто така, постојат многу генератори на микроподатоци, но тие можат само да создадат статички код кој нема да биде ажуриран со промени во содржината на страницата. Осигурување дека информациите во микроподатоците се совпаѓаат со она што е видливо за корисниците на страницата е дел од барањата на Гугл за структурирани податоци. Ако политиката во врска со структурираните податоци е прекршена, страницата може да ги изгуби сите богати фрагменти и во некои случаи да се соочи со рачни казни. Затоа, уверете се дека вашите микроподатоци се автоматски генерирани и автоматски ажурирани.

Содржина

Како дел од техничката SEO ревизија, важно е да се оценат основните карактеристики на содржината: од структурата на насловите и мета таговите до присуството на alt атрибути за слики и потенцијални дупликат страници. Овие елементи директно влијаат на индексирањето и на тоа како пребарувачите го гледаат сајтот.

Тестирајте го вашиот веб-сајт за целосни дупликати

Целосни дупликати се јавуваат кога идентична содржина е достапна преку различни URL адреси на сајтот. Дупликатите можат целосно да му наштетат на рангирањето на вашиот сајт.
Најчести типови на целосни дупликати се:

• Пристапност преку HTTP и HTTPS
• Пристапност со и без WWW
• Пристапност со или без завршна коса црта
• Достапност на URL во големи и мали букви
• Страницата е достапна со екстензии на датотеки како .html, .htm, .php, .aspx, и без нив
• Параметри кои не ја менуваат содржината на страницата, како што се UTM тагови
• Идентични содржини под различни URL. На пример, производот е наведен во две категории, достапни преку две различни URL. Или страницата на производот достапна со и без категоријата во URL.
• Тест верзии на сајтот (DEV домен се користи за развој).

За да најдете дупликати на страници поврзани со варијации на URL, рачно ги тестирајте URL и проверете го кодот за одговор на серверот за тие варијанти на URL. Можете да користите било која алатка за да ги проверите кодовите за одговор на серверот, како што е https://httpstatus.io/. Внесете ги варијациите на URL и проверете нивната достапност.

За да се поправат проблемите со варијации во HTTP/HTTPS, www/without-www, со/без коса црта, голи/мали букви, и пристапноста на страници со екстензии како .html, .htm, .php, .aspx, и без нив, потребно е да се постави 301 пренасочување на посакуваната верзија.

Кога се пронајдени дупликати поради достапноста на идентична содржина со додавање или отстранување на делови од URL адресата (на пример, производот е достапен во две категории), најдобро е да се преиспита структурата на URL и структурата на сајтот. За UTM и други параметри, канонизацијата исто така може да биде решение. Сепак, важно е да се напомене дека Google ја третира канонската ознака како препорака, а конечната одлука за тоа која URL да се избере останува во рацете на Google.

Ако се најде тест верзија на сајтот во индексот на Google, треба да биде блокиран од индексирање, и барање за нејзино отстранување треба да се испрати преку Google Search Console.

Решавање на делумни дупликати на страници

Делумни дупликати на страници се случуваат кога две или повеќе страници на сајтот содржат многу слични, но не целосно идентични содржини. Најчести видови на делумни дупликати се:

• Сортирање на страници
• Филтрирајте страници
• Страници за пагинација
• Страници со слични производи (на пример, производите се разликуваат само по боја)
• Повеќе верзии на сајтот на ист јазик, но за различни региони (на пример, три англиски сајтови за САД, Велика Британија и Австралија).

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

Делумни дупликати обично се наоѓаат за време на процесот на ползање на сајтот од страна на различни ползачи. Тие ќе имаат повторувачки параметри и може да го имаат истиот наслов и H1 како страниците на главната категорија.
За да се елиминираат делумните дупликати не може да се постави пренасочување, бидејќи овие страници се потребни за функционалноста на сајтот. Подолу ќе дискутираме за методите за справување со делумни дупликати

Сортирање и филтрирање на страници

Овие страници можат да бидат блокирани од ползање во robots.txt датотеката, иако ова може да биде игнорирано од страна на Google, особено ако врските укажуваат на овие страници. Ова ќе помогне да се зачува буџетот.
Исто така, можете да ги блокирате преку директивата <meta name=”robots” content=”noindex, nofollow” />, која ќе ги спречи овие страници да бидат индексирани, но нема да му каже на Google дека не треба да се ползат.
Најдобриот пристап во овој случај е да се користи JavaScript за ажурирање на содржината на страницата кога корисникот применува сортирање или филтри, без генерирање на дополнителни URL адреси и врски за филтрирање или сортирање на страници.

Варијанти на производи достапни на различни URL адреси

Идеално, сите варијанти на производи треба да се комбинираат на една страница, каде што корисникот може да ја избере саканата боја или големина без да ја менува URL-ата, со користење на JavaScript. Сепак, ако се користи посебна страница за секоја варијанта, треба да се наведе канонска врска до главната страница на производот. Сепак, како што беше споменато претходно, Google може да го игнорира канонскиот сет од страна на корисникот.

Страници за пагинација

Страниците за пагинација не треба да бидат блокирани од индексирање. За да се осигура дека Google ја смета првата страница од категоријата како главна:

• Вклучете ја само првата страница во sitemap.xml датотеката.
• Додадете линк до главната страница на категоријата на сите страници за пагинација.
• Додадете броеви на страници на насловот и H1 на страниците за пагинација. На пример, “Бели кошули – страна 2”.

Страниците се достапни на еден јазик, но за различни региони

Во овој случај, треба да се користат атрибутите на Hreflang. Тие се користат за да им кажат на пребарувачите кој јазик и регионална верзија на веб страницата треба да им го покажат на корисниците врз основа на нивните јазични преференции и локација.
Постојат неколку начини да се имплементираат атрибутите на Hreflang:

• Во HTTP заглавјата
• Преку тагови во секцијата <глава>
• Преку тагови во sitemap.xml

Најлесниот начин да се имплементира е преку тагови во делот <head>.

Постојат правила кои hreflang атрибутите имплементирани преку тагови во секцијата <head> треба да ги исполнуваат:

• • Атрибутот треба да го има следниот формат: <link rel=”alternate” hreflang=”lang_code_country_code” href=”url-of-page” />
  • Јазикот и државните кодови треба да бидат валидни. За да го изберете валидниот код за секоја јазична мутација, видете ја оваа страница.

• Секоја јазична верзија мора да се наведе себеси, како и сите други јазични верзии во своите hreflang атрибути. Тоа значи дека секоја страница мора да има ист број на hreflang атрибути

• Врските во атрибутите hreflang треба да бидат апсолутни и индексирачки.

Пример за код:

<link rel=”alternate” href=”https://example.com/en-us/page” hreflang=”en-us” />

<link rel=”alternate” href=”https://example.com/en-gb/page” hreflang=”en-gb” />

<link rel=”alternate” href=”https://example.com/en-us/page” hreflang=”x-default” />

Проверете наслови, h1, h2s и описи за дупликати

Иако насловите, описите и H1-H6 заглавјата се поврзани со SEO оптимизацијата на страницата, нивната анализа во рамките на техничката ревизија може да биде корисна за откривање на дупликат.

За да ги анализирате, можете да користите било кој crawler кој ги собира овие тагови.

Кога се најдат дупликат наслови, H1-H6 тагови и описи, се анализираат податоците на страницата и се идентификува причината за дуплирањето. Ова може да се должи на достапноста на сајтот преку HTTP и HTTPS, дуплирање на ознаките на главните категории на страниците на филтерите, или едноставно човечка грешка каде што овие тагови биле погрешно пополнети.

Оптимизирање на alt атрибутите за слики

Alt атрибутите се HTML атрибут кој се користи во <img> ознаката на следниов начин: <img src=”image.jpg” alt=” Опис на сликата”>. Неговата главна цел е да обезбеди текстуален опис на содржината на сликата. Овој текст се прикажува ако сликата не успее да се вчита и се чита гласно од читачите на екран за да им помогне на корисниците со оштетен вид. Соодветен, описен алт текст може да им помогне на вашите слики да се рангираат во пребарувањето на слики и да ја подобрат целокупната релевантност на страницата.

Ако имате веб-сајт со многу визуелна содржина, тогаш оптимизацијата на alt атрибутите е поважен чекор отколку за класичните веб-сајтови кои се потпираат на текстуална содржина.

Многу ползачи како Screaming Frog, Ahrefs, SemRush, итн. анализираат alt атрибути, и таму можете да добиете податоци за недостасувачките или празните alt атрибути.

Можете да прочитате повеќе за создавањето на описни alt атрибути во официјалните документи на Google.

Брзина на веб-страницата, мобилен телефон и лесност за употреба

Користење на HTTPs протокол

Користењето на безбедниот HTTPS протокол е од суштинско значење за да се обезбеди безбедноста на преносот на податоци помеѓу корисникот и серверот. Тоа не само што ја зголемува довербата на корисниците, туку исто така има позитивно влијание врз SEO. За да проверите дали има HTTPS, едноставно погледнете во адресната лента на пребарувачот – треба да се појави икона на катанц.
За детална анализа, можете да го користите SSL Labs сервисот, кој ќе обезбеди целосен извештај за статусот на SSL сертификатот и ќе ги идентификува потенцијалните проблеми.

Исто така е важно да се осигура дека нема мешана содржина – HTTP ресурси на HTTPS страници. За оваа анализа, можете да го користите HTTPS извештајот во Google Search Console, кој ќе покаже URL адреси со HTTP и HTTPS.

Извор: Конзола за пребарување на нашиот клиент

Подобрување на основните веб витални вредности

Core Web Vitals е збир на метрики предложени од страна на Google за да се процени квалитетот на корисничкото искуство на веб-страницата. Овие метрики се фокусираат на брзината на вчитување, интерактивноста и визуелната стабилност на содржината на страницата. Тие вклучуваат три клучни индикатори:

Метрички	опис	Оптимална вредност
Најголема содржинска боја (LCP)	Го мери времето на вчитување на најголемиот видлив елемент на страницата (на пример, слика или текст).	Помалку од 2,5 секунди
Задоцнување на првиот влез (FID)	Го мери времето потребно на страницата да одговори на првата интеракција на корисникот (на пример, кликнување на копче или линк).	Помалку од 100 милисекунди
Кумулативна промена на распоредот (CLS)	Ја проценува визуелната стабилност на страницата, односно колку елементи се движат за време на вчитувањето на страницата.	Помалку од 0.1

 

Податоците кои се собрани од вистински корисници може да се видат во извештајот на Search Console “Core web vitals” (агрегирани податоци) или во PageSpeed Insights (за индивидуални тестови). Додека работите на Core Web Vitals, имајте на ум дека треба да ги дефинирате проблемите кои имаат големо влијание врз CWV метриките. На пример, додека се оптимизира LCP, треба да се дефинира кој од 4-те аспекти (TTFB, Load Delay, Load Delay, или Render delay) придонесува најмногу за високиот LCP резултат.

Во примерот подолу, видливо е дека не треба да се фокусираме на оптимизација на TTFB или Load Time. Наместо тоа, можеме да ја ставиме целата наша енергија во подобрување на задоцнувањето на товарот и потоа рендерирање на задоцнувањето.

Извор: https://pagespeed.web.dev/ – тест на nike.com веб-сајт (само на пример). Доменот е замаглен

Уверете се дека вашата веб-страница е пријателска за мобилни телефони

Пријателството за мобилни телефони стана клучен фактор од 2018 година, кога Google се префрли на пристап за индексирање на мобилни телефони. Ова значи дека Google сега првенствено ја користи мобилната верзија на веб-сајтот за рангирање и индексирање, наместо десктоп верзијата.

Во Google Search Console, можете да ги тестирате вашите страници со кликнување на “Test Live URL” во алатката за проверка на URL и да видите како Googlebot-Mobile го гледа.

Компресирање на слики

Оптимизацијата на сликите со цел да ги компресира без губење на квалитетот помага да се забрза вчитувањето на веб-страницата, особено ако има многу графичка содржина на страниците.

Онлајн алатките како што се TinyPNG или Squoosh може да се користат за компресирање на слики. Исто така е вредно да се провери дали се користат модерни формати на слики, како што е WebP, бидејќи тие можат значително да ја намалат големината на датотеката.

Користете CDN за меѓународни веб-сајтови

Користењето на CDN има смисла ако вашата веб-страница служи на широк спектар на географски оддалечени региони.

CDN (Content Delivery Network) ја дистрибуира содржината на сајтот преку сервери лоцирани поблиску до корисниците, намалувајќи ја латентноста за време на вчитувањето. Можете да проверите за користење на CDN со испитување на HTTP барањата во алатките за развивање на пребарувачот (таб Мрежа), каде што референци на CDN провајдерот, како што се Cloudflare или Akamai, може да се појават. Исто така, постојат онлајн алатки за тестирање на CDN. CDN конфигурацијата обично се врши преку хостинг панелот или CMS.

Користете кеширање
Кеширањето им овозможува на прелистувачите и прокси серверите да чуваат копии на ресурси, намалувајќи го оптоварувањето на серверот и забрзувајќи го товарењето на следните посети. Можете да ја проверите точноста на кеширањето во алатките за развивање на пребарувачот — во делот Мрежа, погледнете во Cache-Control, Expires и ETag заглавијата. Google PageSpeed Insights исто така дава препораки за кеширање. Важно е статичните ресурси (слики, скрипти, стилови) да имаат соодветни поставки за кеширање, и серверот треба да ги има соодветните правила конфигурирани (на пример, во .htaccess или nginx конфигурација). За да го проверите кеширањето, можете да користите онлајн сервиси како GiftOfSpeed.

Заклучок

Техничката ревизија на веб-сајтот не е еднократна постапка, туку постојан процес кој бара редовно внимание на техничките фактори кои можат да влијаат на неговата ефикасност и видливост. Бидејќи секоја веб-страница е уникатна, специфичниот фокус и фреквенција на проверките ќе варираат. Оваа листа за техничка SEO ревизија ќе ви помогне да се осигурате дека не сте заборавиле ништо важно.