Технически контролен списък за SEO: Най-добрият списък за подобряване на вашия уебсайт

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

Обхождане и индексиране

Първото нещо, което трябва да разгледате по време на техническия одит, е как вашият сайт се индексира и обхожда от търсачките. В крайна сметка, ако страниците на вашия сайт не могат да бъдат обходени, те няма да бъдат индексирани (с малки изключения). В резултат на това страниците, които не са представени в индекса, няма да участват в класирането.

Прегледайте отчета за индексиране на страници в Google Search Console

Най-точният и надежден начин да анализирате индексирането на вашия уебсайт е да анализирате отчета за индексиране на страници в Google Search Console.

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

Също така погледнете страниците, които са изключени.

Не всички състояния в отчета „Изключени страници“ са проблем. Не трябва да фокусирате вниманието си върху всички изключени страници, а само върху тези, където поведението на Google не отговаря на вашите намерения.

В таблицата по-долу можете да видите статусите, които обикновено изискват внимание и по-задълбочен анализ:

Статус	Какво означава	Какво трябва да направите
Грешка при пренасочване	Google не успя да последва URL адреса поради проблеми с пренасочването.	Намалете броя на пренасочванията (до 1-2). Избягвайте безкрайни и кръгови пренасочвания.- Уверете се, че крайният URL адрес връща 200 OK и не е блокиран в robots.txt/noindex.
Грешка на сървъра	Сървърът върна грешка 5xx.	Проверете регистрационните файлове на сървъра. Уверете се, че сайтът не е претоварен.- Коригирайте вътрешни грешки, особено ако се повтарят отново.
Открит – не е индексиран	Google знае за страницата, но все още не я е обходил. Показва проблеми с обхождането на бюджета.	Уверете се, че страницата е в картата на сайта. Добавете вътрешни връзки към него. Оптимизирайте бюджета за обхождане.
Обходен – не индексиран	Google посети страницата, но избра да не я индексира. Обикновено показва ниско качество на страницата.	Подобрете качеството и уникалността на съдържанието. Уверете се, че страницата няма дубликати. Добавете вътрешни връзки към него.
Дублиране без избран от потребителя каноничен	Google смята страницата за дубликат, но не посочихте канонично.	Проверете двойките страници и посочете необходимата канонична или преразгледайте структурата на сайта.
Дубликат, Google избра различен каноничен от потребител	Google игнорира посочения от вас канонически.	Причините могат да бъдат много; Трябва внимателно да проучите данните на страницата и да изберете най-подходящата стратегия (noindex, пренасочване, премахване, robots.txt, промени в структурата на уебсайта и вътрешно свързване).
Мек 404	Страницата изглежда „празна“ или „не е намерена“, но връща състояние 200 OK.	Връщане 404 или 410. Направете пренасочване. Подобрете съдържанието. Блокиране от индексиране.

Другите статуси вероятно не сигнализират за никакви проблеми. Тези доклади обаче си струва да бъдат прегледани, за да се уверите, че страниците не са били премахнати, пренасочени, канонизирани или блокирани от индексиране по погрешка.

Състояние	Какво означава	Какво трябва да знаете
Алтернативна страница с подходящ каноничен таг	Google правилно потвърди каноничното, което посочихте.	Всичко работи според очакванията. Не се изискват действия. Уверете се, че сте посочили желания канонически.
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 може също да помогне при анализиране на страници, които са индексирани или изключени от индекса. За да направите това, трябва да свържете API на Google Search Console, преди да започнете обхождането на сайта.
За да се свържете, отидете на Конфигурация -> 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 или други роботи, за да анализирате страниците, включени в Sitemap.xml. В Screaming Frog sitemap.xml може да се сканира отделно в режим на списък или може да бъде включено в обикновено сканиране на сайта. За да направите това, в Конфигурация -> Spider -> Crawl активирайте сканирането на XML карта на сайта и добавете абсолютните URL адреси на картите на сайта, които искате да обходите.

Не се препоръчва използването на различни онлайн услуги за генериране на карта на сайта, тъй като те могат да генерират само статична карта на сайта, която няма да се актуализира автоматично. Оптималният вариант е да се генерира 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 name=“роботи“ 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 → Настройки → Статистика за обхождане. В таблицата по-долу можете да видите най-често срещаните проблеми, които можете да откриете в този отчет:

Проблем	Какво да търсите в отчета	Възможни причини
Рязко намаляване на пълзенето	По-малко обхождане на ден	Проблеми с достъпността, неправилни настройки в 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 Новини
	ЧЗВPage	Страница с често задавани въпроси (ЧЗВ)
	Как да	Ръководство стъпка по стъпка
	Уеб страница	Обща информация за уеб страница
Продукти и оферти	Продукт	Описание на продукта
	Принасям	Ценова оферта
	АгрегатОферта	Ценови диапазон за продукт от различни продавачи
Отзиви и оценки	Преглед	Преглед на продукт или услуга
	Рейтинг	Числова оценка (често в рамките на преглед)
	Агрегиран рейтинг	Средна оценка въз основа на множество отзиви
Организации и хора	Организация	Описание на фирма или марка
	Местен бизнес	Местен бизнес с информация за контакт и график
	Човек	Човек (напр. автор на статия, говорител и т.н.)
Събития	Събитие	Онлайн или офлайн събитие
Навигация и структура	Списък на трохите	Навигация на трохите
	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?“,

„автор“: {

„@type“: „Лице“,

„име“: „Джон Смит“

},

„datePublished“: „2025-12-01“

}

</скрипт>

Когато внедрявате структурирани данни, следвайте протокола Schema.org и използвайте валидатора , за да проверите коректността на внедрените типове микроданни. Някои видове структурирани данни от протокола Schema.org също могат да помогнат за показването на богати фрагменти в резултатите от търсенето с Google.

Имайте предвид, че изискванията на Google за структурирани данни за богати фрагменти се различават леко от стандарта за Schema.org. Често трябва да се посочат повече полета, отколкото изисква протоколът за Schema.org. Така че, ако искате да постигнете богат фрагмент, следвайте указанията на Google за структурирани данни. Можете да проверите коректността на реализацията на микроданните с помощта на валидатора на богати фрагменти.

Има и много генератори на микроданни, но те могат да създават само статичен код, който няма да се актуализира с промени в съдържанието на страницата. Гарантирането, че информацията в микроданните съответства на това, което е видимо за потребителите на страницата, е част от изискванията на Google за структурирани данни. Ако правилата по отношение на структурираните данни бъдат нарушени, страницата може да загуби всички богати фрагменти и в някои случаи да бъде изправена пред ръчни санкции. Затова се уверете, че микроданните ви се генерират автоматично и се актуализират автоматично.

Доволен

Като част от техническия 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 и други параметри канонизацията също може да бъде решение. Важно е обаче да се отбележи, че 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, h2 и описания за дубликати

Въпреки че заглавията, описанията и заглавията на 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.

Скорост на уебсайта, мобилни устройства и удобство за потребителя

Използване на HTTP протокол

Използването на защитения HTTPS протокол е от съществено значение за гарантиране на сигурността на предаването на данни между потребителя и сървъра. Той не само повишава доверието на потребителите, но и има положително въздействие върху SEO. За да проверите за HTTPS, просто погледнете адресната лента на браузъра – трябва да се появи икона на катинар.
За подробен анализ можете да използвате услугата SSL Labs, която ще предостави пълен отчет за състоянието на SSL сертификата и ще идентифицира всички потенциални проблеми.

Също така е важно да се гарантира, че няма смесено съдържание — HTTP ресурси на HTTPS страниците. За този анализ можете да използвате отчета HTTPS в Google Search Console, който ще показва URL адреси както с HTTP, така и с HTTPS.

Източник: Search Console на нашия клиент

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

Core Web Vitals е набор от показатели, предложени от Google за оценка на качеството на потребителското изживяване на уебсайт. Тези показатели се фокусират върху скоростта на зареждане, интерактивността и визуалната стабилност на съдържанието на страницата. Те включват три ключови показателя:

Описание	на показателя	Оптимална стойност
Най-голяма боя за съдържание (LCP)	Измерва времето за зареждане на най-големия видим елемент на страницата (напр. изображение или текст).	По-малко от 2,5 секунди
Забавяне на първия вход (FID)	Измерва времето, необходимо на страницата да отговори на първото взаимодействие с потребителя (напр. щракване върху бутон или връзка).	По-малко от 100 милисекунди
Кумулативно изместване на оформлението (CLS)	Оценява визуалната стабилност на страницата, т.е. колко елементи се движат по време на зареждане на страницата.	По-малко от 0,1

 

Данните, събрани от реални потребители, могат да се видят в отчета на Search Console „Основни показатели за мрежата“ (обобщени данни) или в PageSpeed Insights (за отделни тестове). Докато работите върху Core Web Vitals, имайте предвид, че трябва да определите проблемите, които оказват голямо влияние върху показателите на CWV. Например, докато оптимизирате LCP, трябва да определите кой от 4-те аспекта (TTFB, забавяне на зареждането, време за зареждане или забавяне на изобразяването) допринася най-много за високия резултат на LCP.

В примера по-долу се вижда, че не е нужно да се фокусираме върху оптимизирането на TTFB или времето за зареждане. Вместо това можем да вложим цялата си енергия в подобряване на забавянето на натоварването и след това на забавянето на изобразяването.

Източник: https://pagespeed.web.dev/ – тест на nike.com уебсайт (само например). Домейнът е замъглен

Уверете се, че уебсайтът ви е удобен за мобилни устройства

Удобството за мобилни устройства се превърна в решаващ фактор от 2018 г., когато Google премина към подход за индексиране на мобилни устройства . Това означава, че Google вече използва предимно мобилната версия на уебсайта за класиране и индексиране, а не настолната версия.

В Google Search Console можете да тествате страниците си, като кликнете върху „Тестване на Live URL“ в инструмента за проверка на URL адреси и вижте как Googlebot-Mobile го вижда.

Компресиране на изображения

Оптимизацията на изображенията, насочена към компресирането им, без да губи качество, помага за ускоряване на зареждането на уебсайта, особено ако на страниците има много графично съдържание.

Онлайн инструменти като TinyPNG или Squoosh могат да се използват за компресиране на изображения. Също така си струва да проверите дали се използват съвременни формати на изображения, като WebP, тъй като те могат значително да намалят размера на файла.

Използване на CDN за международни уебсайтове

Използването на CDN има смисъл, ако уебсайтът ви обслужва широк спектър от географски отдалечени региони.

CDN (мрежа за доставка на съдържание) разпределя съдържанието на сайта между сървъри, разположени по-близо до потребителите, намалявайки забавянето по време на зареждане. Можете да проверите за използване на CDN, като разгледате заглавките на HTTP заявки в инструментите за разработчици на браузъра (раздел Мрежа), където може да се появят препратки към доставчика на CDN, като Cloudflare или Akamai. Има и онлайн инструменти за тестване на CDN. Конфигурирането на CDN обикновено се извършва чрез хостинг панела или CMS.

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

Извод

Техническият одит на уебсайт не е еднократна процедура, а непрекъснат процес, който изисква редовно внимание към техническите фактори, които могат да повлияят на неговата производителност и видимост. Тъй като всеки уебсайт е уникален, конкретният фокус и честотата на проверките ще варират. Този контролен списък за технически SEO одит ще ви помогне да се уверите, че не сте забравили нищо важно.