Шаблон чек-листа технічного SEO-аудиту

Аудит скануваності та індексації

Переконайтеся, що пошукові системи можуть знайти, просканувати та проіндексувати саме потрібні сторінки — і нічого зайвого.

Robots і директиви сканування

• ☐ Переконайтеся, що robots.txt відкривається на кореневому домені та повертає статус 200, а не 4xx/5xx.
• ☐ Перевірте, що жодне правило Disallow не блокує CSS, JavaScript чи важливі директорії з контентом, потрібні для рендерингу.
• ☐ Переконайтеся, що staging- або dev-хости заблоковані від продакшену, а сам продакшен не заборонений випадково для всього сайту (['Disallow: /']).
• ☐ Переконайтеся, що в robots.txt указано дійсне посилання на sitemap.
• ☐ Перевірте meta robots і заголовки X-Robots-Tag на випадкові noindex чи nofollow на індексованих сторінках.
• ☐ Переконайтеся, що сторінки, які ви хочете проіндексувати, не заблоковані в robots.txt (заборонений URL не може прочитати власний тег noindex).

XML-карти сайту

• ☐ Переконайтеся, що sitemap містить лише канонічні, індексовані URL зі статусом 200: жодних редиректів, noindex чи заблокованих адрес.
• ☐ Переконайтеся, що sitemap не перевищує лімітів на файл (['50,000 URLs / 50 MB без стиснення']) і за потреби використовує sitemap-індекс.
• ☐ Перевірте, що URL використовують абсолютні, узгоджені https-шляхи, які відповідають бажаному домену.
• ☐ Надішліть sitemap у Search Console та переконайтеся, що він зчитується без помилок.
• ☐ Звірте кількість URL у sitemap із кількістю проіндексованих і дослідіть великі розбіжності.

Канонізація

• ☐ Переконайтеся, що кожна індексована сторінка має самопосилання canonical (абсолютний URL).
• ☐ Перевірте, що canonical-теги вказують на живі URL зі статусом 200, а не на редиректи чи 404.
• ☐ Перевірте на суперечливі сигнали (canonical проти noindex, canonical проти hreflang, canonical проти sitemap).
• ☐ Переконайтеся, що варіанти з параметрами, фасетами, пагінацією та session-ID канонізуються коректно.
• ☐ Переконайтеся, що канонічною є лише одна версія URL серед http/https, www/non-www і варіантів зі слешем у кінці.

Покриття індексу

• ☐ Перегляньте звіт Індексування сторінок у Search Console та розберіть кожну причину Не проіндексовано.
• ☐ Дослідіть Просканована, але ще не проіндексована та Виявлена, але ще не проіндексована на предмет проблем з якістю чи краулінговим бюджетом.
• ☐ Усуньте патерни Дублікат без канонічної, вибраної користувачем та Альтернативна сторінка з правильним canonical-тегом.
• ☐ Використайте «Перевірку URL», щоб підтвердити відрендерений HTML, canonical та індексованість ключових шаблонів.
• ☐ Перевірте логи сервера чи звіт «Статистика сканування» на сплески 4xx/5xx та марнування краулінгу.
• ☐ Переконайтеся, що важливі сторінки доступні через внутрішні посилання, а не лише через sitemap.

Аудит архітектури сайту та внутрішньої перелінковки

Забезпечте, щоб найважливіші сторінки були неглибокими, добре перелінкованими й отримували внутрішню вагу посилань.

Глибина сканування та структура

• ☐ Запустіть повне сканування з головної сторінки та зафіксуйте глибину кліків для кожного URL.
• ☐ Переконайтеся, що пріоритетні сторінки лежать на невеликій глибині від головної (['3 кліки або менше']).
• ☐ Виявте глибокі сторінки, поховані за пагінацією, фільтрами чи тонкими хаб-сторінками, і за потреби зробіть структуру пласкішою.
• ☐ Переконайтеся в логічній, узгодженій ієрархії URL, що віддзеркалює розділи сайту.
• ☐ Переконайтеся, що головна навігація та футер відкривають доступ до топ-категорій і ключових комерційних сторінок.

Сторінки-сироти та тупикові сторінки

• ☐ Звірте дані сканування із sitemap та даними аналітики/логів, щоб знайти сторінки-сироти (URL без внутрішніх вхідних посилань).
• ☐ Додайте контекстні внутрішні посилання, щоб повернути цінний осиротілий контент, або видаліть чи перенаправте малоцінні сироти.
• ☐ Виявте тупикові сторінки з малою кількістю чи відсутністю вихідних внутрішніх посилань і додайте релевантні посилання.
• ☐ Переконайтеся, що сторінки з пагінацією та фільтрами все ще відкривають шляхи сканування до базових елементів.

Вага посилань та анкорний текст

• ☐ Складіть карту кількості внутрішніх вхідних посилань і позначте цінні сторінки, яким їх бракує.
• ☐ Зменшіть кількість посилань на малоцінні URL (вхід, кошик, службові сторінки), що розмивають вагу.
• ☐ Використовуйте описовий, різноманітний, релевантний за ключами анкорний текст замість загального натисніть тут.
• ☐ Переконайтеся, що важливі внутрішні посилання — це скановані елементи <a href>, а не лише JavaScript-обробники кліків.
• ☐ Виправте внутрішні посилання, що проходять через редиректи чи ведуть на 404, щоб вага передавалася напряму.

Хлібні крихти та хаб-сторінки

• ☐ Впровадьте навігацію «хлібні крихти» на глибоких шаблонах і розмітьте її структурованими даними BreadcrumbList.
• ☐ Переконайтеся, що посилання в «хлібних крихтах» — справжні анкори і відображають реальну ієрархію сайту.
• ☐ Створіть або посильте хаб/категорійні сторінки, що ведуть до пов’язаного кластерного контенту.
• ☐ Переконайтеся, що модулі пов’язаного та контекстного контенту перелінковують тематично близькі сторінки між собою.

Аудит Core Web Vitals та продуктивності

Діагностуйте та пріоритезуйте проблеми зі швидкістю й стабільністю сторінки, що шкодять досвіду користувача та позиціям.

Польові дані та діагностика

• ☐ Перегляньте звіт Core Web Vitals у Search Console та відзначте групи URL, що не проходять на мобільних і десктопі.
• ☐ Надавайте перевагу польовим (реальних користувачів) даним над лабораторними оцінками; лабораторні інструменти — лише для відтворення й налагодження.
• ☐ Переконайтеся в цілях: LCP не більше ['2.5s'], INP не більше ['200ms'], CLS не більше ['0.1'] на 75-му перцентилі.
• ☐ Аудитуйте репрезентативні шаблони (головна, категорія, товар/стаття), а не лише головну сторінку.

Largest Contentful Paint (LCP)

• ☐ Визначте LCP-елемент на кожному ключовому шаблоні та переконайтеся, що він завантажується рано.
• ☐ Робіть preload LCP-зображення чи шрифту й уникайте lazy-load для медіа над згином.
• ☐ Віддавайте hero-зображення в сучасних форматах із правильними розмірами та адаптивним srcset.
• ☐ Скоротіть час відповіді сервера (TTFB) через кешування та CDN.

Interaction to Next Paint (INP)

• ☐ Розбивайте довгі JavaScript-задачі та відкладайте некритичні скрипти.
• ☐ Мінімізуйте роботу основного потоку від сторонніх тегів, A/B-інструментів і чат-віджетів.
• ☐ Видаліть невикористовуваний JavaScript і CSS та розділяйте великі бандли на частини.
• ☐ Тестуйте реальні взаємодії (тапи, відкриття меню, введення у форми) на мобільному пристрої середнього класу.

Cumulative Layout Shift (CLS)

• ☐ Задавайте явні ширину й висоту (або aspect-ratio) для зображень, відео та вбудувань.
• ☐ Резервуйте місце для реклами, банерів і динамічно вставленого контенту.
• ☐ Робіть preload вебшрифтів і використовуйте font-display, щоб обмежити зсуви від заміни тексту.
• ☐ Уникайте вставлення контенту над наявним контентом після завантаження.

Доставка, кешування та мобільні

• ☐ Усуньте CSS/JS, що блокують рендеринг, і вбудовуйте інлайн лише критичний CSS.
• ☐ Увімкніть стиснення тексту (gzip/Brotli) і довготривалі заголовки кешу для статичних ресурсів.
• ☐ Переконайтеся, що HTTP/2 чи HTTP/3 та CDN віддають ресурси близько до користувачів.
• ☐ Переконайтеся, що мобільний макет адаптивний, а цілі для тапу та розміри шрифтів придатні для дотику.
• ☐ Перетестовуйте після кожного виправлення та спостерігайте за польовими даними протягом повного вікна збору, перш ніж оголошувати успіх.

Аудит структурованих даних та розширених результатів

Перевірте, що ваша schema-розмітка точна, придатна та отримує розширені результати, на які має право.

Покриття schema та вибір типів

• ☐ Проведіть інвентаризацію: які шаблони мають структуровані дані, а яким придатним шаблонам їх бракує.
• ☐ Зіставте кожну сторінку з відповідними типами (['Article, Product, FAQPage, BreadcrumbList, Organization, LocalBusiness']).
• ☐ Надавайте перевагу JSON-LD у коді сторінки й тримайте один узгоджений формат розмітки на сторінку.
• ☐ Впровадьте сутність Organization чи сайтового рівня з логотипом і профілями sameAs, де це доречно.

Правила точності та придатності

• ☐ Переконайтеся, що розмічений контент видимий користувачам на сторінці: жодних прихованих даних чи лише в розмітці.
• ☐ Включіть усі обов’язкові властивості для кожного типу та додайте рекомендовані, щоб посилити придатність.
• ☐ Переконайтеся, що значення правдиві та актуальні (ціна, наявність, рейтинги, дати) й відповідають контенту сторінки.
• ☐ Використовуйте розмітку review/rating лише для справжніх відгуків на сторінці й дотримуйтеся чинних правил щодо самовихваляння.
• ☐ Переконайтеся, що посилання на сутності та ID узгоджені між пов’язаними блоками розмітки.

Валідація та тестування

• ☐ Прогоніть кожен ключовий шаблон через Rich Results Test і валідатор schema.
• ☐ Виправте всі повідомлені помилки та усуньте попередження, що блокують покращення.
• ☐ Тестуйте відрендерений HTML, оскільки частина розмітки вставляється через JavaScript після завантаження.
• ☐ Вибірково перевіряйте кілька реальних URL на шаблон, а не лише один приклад.

Моніторинг та підтримка

• ☐ Відстежуйте кожен тип розширеного результату у звітах Покращення в Search Console на нові помилки.
• ☐ Налаштуйте сповіщення чи регулярну перевірку після змін шаблону, CMS чи плагінів.
• ☐ Повторно валідуйте, коли змінюються рекомендації або функція визнається застарілою.
• ☐ Ведіть журнал того, які шаблони видають які типи schema і хто за них відповідає.

Аудит міжнародного SEO

Переконайтеся, що правильна мовна та регіональна версія кожної сторінки віддається й індексується для потрібної аудиторії.

Впровадження hreflang

• ☐ Переконайтеся, що кожна сторінка в мовному/регіональному наборі посилається на всі альтернативи, включно із самопосиланням hreflang.
• ☐ Перевірте, що зворотні теги двонаправлені: кожна альтернатива посилається на решту (жодних односторонніх посилань).
• ☐ Використовуйте дійсні коди мови та опційні коди регіону (['en, en-GB, es-MX']) у форматі ISO.
• ☐ Включіть тег x-default для глобального фолбеку чи селектора мови.
• ☐ Оберіть один метод доставки (HTML head, HTTP-заголовок чи sitemap) і застосовуйте його послідовно.
• ☐ Спрямовуйте hreflang-URL на живі, індексовані, канонічні сторінки зі статусом 200 — ніколи на редиректи чи noindex-сторінки.

Взаємодія canonical та індексації

• ☐ Переконайтеся, що кожен локалізований URL самоканонічний, а не канонізований до іншої мовної версії.
• ☐ Переконайтеся, що hreflang і canonical не суперечать один одному на тій самій сторінці.
• ☐ Перевірте, що майже дублікатні локалізовані сторінки не зводяться до єдиного canonical.
• ☐ Переконайтеся, що локалізовані сторінки присутні у власних sitemap із правильними альтернативними посиланнями.

Геотаргетинг та структура URL

• ☐ Переконайтеся в чіткій, масштабованій структурі для мов/регіонів (ccTLD, піддомен чи підкаталог) і застосовуйте її послідовно.
• ☐ Встановіть таргетинг за країною там, де доречно, і узгодьте його зі стратегією URL.
• ☐ Уникайте авторедиректів на основі IP, що блокують краулерів чи замикають користувачів у неправильній версії; надавайте перевагу мовному банеру чи селектору.
• ☐ Локалізуйте контент осмислено (валюта, одиниці, контактні дані, правопис), а не дублюйте одну мову.

Валідація

• ☐ Проскануйте сайт з увімкненою звітністю hreflang та усуньте відсутні чи биті зворотні теги.
• ☐ Використайте «Перевірку URL», щоб підтвердити, як виявляються альтернативи.
• ☐ Вибірково перевірте кілька локалей на коректний рендеринг, індексованість і віддачу.
• ☐ Проведіть повторний аудит після додавання нових локалей чи шаблонів.

Аудит міграції / редизайну сайту

Захистіть позиції та трафік до, під час і після міграції чи редизайну, перевіривши редиректи й паритет.

Підготовка перед запуском

• ☐ Проскануйте живий сайт і як базову лінію експортуйте повний перелік індексованих URL, заголовків, метаданих і кодів статусу.
• ☐ Зафіксуйте базові показники: топ органічних цільових сторінок, позиції, трафік, конверсії та покриття індексу.
• ☐ Переконайтеся, що staging-сайт заблоковано від індексації та захищено (авторизація чи IP-allowlist), але переконайтеся, що директиви буде знято під час запуску.
• ☐ Побудуйте повну карту редиректів від кожного старого URL до найближчого нового відповідника.
• ☐ Підготуйте нові XML-sitemap, robots.txt та ресурси аналітики/Search Console для нової структури.

Мапування редиректів

• ☐ Використовуйте постійні редиректи 301 для змінених URL і уникайте 302 для постійних переміщень.
• ☐ Мапуйте старі URL один-до-одного на релевантні нові сторінки; уникайте масових редиректів на головну.
• ☐ Усуньте ланцюжки та петлі редиректів, щоб кожен старий URL розв’язувався за один крок.
• ☐ Збережіть чи мігруйте hreflang, canonical і структуровані дані на нові URL.
• ☐ Врахуйте застарілі параметри, медіафайли та будь-які URL із зовнішніми зворотними посиланнями.

Паритет контенту та технічний

• ☐ Перевірте, що заголовки, метаописи, заголовки, тіло контенту та зображення перенесено чи покращено.
• ☐ Переконайтеся, що внутрішні посилання ведуть на нові URL напряму, а не через редиректи.
• ☐ Перевірте, що canonical-теги, структуровані дані та hreflang правильні на нових шаблонах.
• ☐ Порівняйте Core Web Vitals і ключову швидкість сторінки до та після, щоб виявити регресії.

Валідація під час і після запуску

• ☐ На запуску зніміть staging-блокування noindex/robots і переконайтеся, що продакшен-сайт скановний.
• ☐ Надішліть нові sitemap і скористайтеся «Перевіркою URL», щоб запросити індексацію пріоритетних сторінок.
• ☐ Повторно проскануйте новий сайт, щоб підтвердити, що редиректи розв’язуються, немає критичних 404 і жоден шаблон не видає ненавмисний noindex.
• ☐ Щодня стежте за покриттям індексу, статистикою сканування, позиціями та трафіком у перші тижні й пильнуйте стійких падінь.
• ☐ Тримайте редиректи довгостроково та виправляйте будь-які нововиявлені биті шляхи.

Як часто слід проводити технічний SEO-аудит?

Для більшості сайтів добре працює комплексний технічний аудит щокварталу в парі з безперервним моніторингом у проміжках. Великі сайти, що часто змінюються (великі e-commerce чи новинні видання), виграють від щомісячних глибоких занурень, тоді як малі стабільні сайти часто можуть чекати пів року. Крім графіка, завжди запускайте відповідний модуль аудиту після будь-якої великої події: міграції, редизайну, зміни CMS чи оновлення шаблону, адже саме тоді з’являються технічні проблеми.

Яка різниця між аудитом і постійним моніторингом?

Аудит — це комплексний огляд у певний момент часу, коли ви системно перевіряєте скануваність, архітектуру, продуктивність, структуровані дані та інше, щоб знайти й пріоритезувати проблеми. Моніторинг — це безперервний автоматизований шар, що стежить за новими проблемами між аудитами, відстежуючи покриття індексу, биті посилання, сплески кодів статусу, Core Web Vitals і помилки структурованих даних, щоб регресії виринали швидко. Аудити задають напрям і розкривають глибокі проблеми; моніторинг швидко ловить нові. Потрібне й те, й інше.

Чи є Core Web Vitals фактором ранжування?

Так. Core Web Vitals є частиною сигналів досвіду сторінки Google і можуть впливати на позиції, особливо як вирішальний фактор між сторінками схожої релевантності та якості. Вони не чарівна паличка (релевантний, корисний контент залишається домінантним фактором), тож ставтеся до Core Web Vitals як до значущого сигналу досвіду користувача та ранжування, який варто зробити правильно, а не як до заміни якості контенту та загального здоров’я сайту.

Чи рендерить Google JavaScript і чому це важливо для аудиту?

Google може рендерити JavaScript, але рендеринг відбувається другим проходом після початкового сканування й залежить від того, чи скановні ресурси. Якщо критичний контент, внутрішні посилання, canonical чи структуровані дані з’являються лише після виконання клієнтського JavaScript, їх можуть виявити пізно чи пропустити, якщо скрипти заблоковано чи вони збоять. Під час аудиту завжди перевіряйте відрендерений DOM на додачу до сирого HTML і переконайтеся, що ваш robots.txt дозволяє JavaScript і CSS, потрібні для рендерингу.

Які технічні проблеми слід виправляти першими?

Пріоритезуйте все, що блокує сканування чи індексацію важливих сторінок: випадкові теги noindex, надто широкі правила disallow у robots.txt, биті чи суперечливі canonical, помилки сервера (5xx) та ланцюжки чи петлі редиректів. Вони можуть повністю прибрати сторінки з пошуку, тож переважають косметичні виправлення. Прибравши блокери сканування й індексації, просувайтеся за серйозністю через архітектуру сайту, Core Web Vitals, структуровані дані та міжнародні питання.

Скільки часу після виправлення проблем я побачу результати?

Це залежить від проблеми та того, як швидко пошукові системи повторно сканують уражені сторінки. Зняття блокера індексації може відобразитися за кілька днів для пріоритетних URL, які ви запросили через «Перевірку URL», тоді як широкі зміни на великому сайті можуть зайняти тижні, поки завершиться повторне сканування. Польові метрики на кшталт Core Web Vitals оновлюються лише після проходження повного вікна збору даних, тож очікуйте затримку, перш ніж покращення з’являться в цих звітах. Повторно скануйте, валідуйте та моніторте, а не припускайте миттєву зміну.