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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Имајте на ум дека само 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 адреси на sitemap кои сакате да ползате.

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

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

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

Осигурете се дека нема грешки во 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

 

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

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

Анализата на статистиката е начин да се разбере како 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	Слика со опис
Образование и работни места	Курс	Онлајн курс или програма за обука
	JobPosting	Слободно работно место (за Google за работа)

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

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

{

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

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

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

“author”: {

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

“name”: “John Smith”

},

“datePublished”: “2025-12-01”

}

</скрипта>

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

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

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

Содржина

Како дел од техничката 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/без-www, со/без коса црта, големи и мали букви, и достапноста на страници со екстензии како .html, .htm, .php, .aspx, и без нив, потребно е да се постави 301 пренасочување кон претпочитаната верзија.

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

Ако тест верзија на сајтот се најде во индексот на Гугл, таа треба да биде блокирана од индексирање, а барање за негово отстранување треба да се испрати преку 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 оптимизацијата на страницата, нивната анализа во рамките на техничката ревизија може да биде корисна за откривање на дупликати.

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

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

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

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

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

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

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

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

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

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

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

Извор: Пребарувачката конзола на нашиот клиент

Подобрување на Core Web Vitals

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, задоцнување на оптоварувањето, време на вчитување или рендерирање задоцнување) придонесува најмногу за високиот LCP резултат.

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

Извор: 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 ревизија ќе ви помогне да се осигурате дека не сте заборавиле ништо важно.