Технически контролен списък за 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/
• Позволете: /публично/
• Карта на сайта: https://example.com/sitemap.xml

1. Директиви за забрана и разрешаване

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

• Начало (/)
• Продуктови карти (/продукт/)
• Блог или статии (/блог/, /статии/)

Често срещана грешка е блокирането на изображения, стилове и скриптове при блокиране на административни папки. В такъв случай трябва да се уточни, че въпреки че административната папка е блокирана, някои видове файлове трябва да са отворени за сканиране. Това често се случва на WordPress сайтове, когато папката с цялото потребителско съдържание, Disallow: /wp-content е блокирана.

В този случай за сканиране могат да се отварят само файлове с определен формат:

• Разрешено: /wp-content/uploads/*.css
• Разрешено: /wp-content/uploads/*.js
• Разрешено: /wp-content/uploads/*.jpeg

За да потвърдите robots.txt си и да тествате директивите, които ще добавите, можете да използвате този инструмент.

1. Проверете съвместимостта с други директиви

Често възникват грешки, когато robots.txt конфликтува с:

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

Най-лесният метод за изпълнение е чрез тагове в секцията <глава>.

Има правила, на които трябва да отговарят атрибутите на 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 са 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.

Източник: 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 можете да тествате страниците си, като кликнете върху „Тестване на 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 одит ще ви помогне да сте сигурни, че не сте забравили нищо важно.