SEO-аудит сайту: що перевірити самому, а що замовити

Після редизайну графік кліків у Search Console пішов униз сходами. Підрядник каже: «Мабуть, Google оновив алгоритм». Це можливо, але ти можеш перевірити простішу річ: чи відкриваються старі адреси сторінок і куди вони ведуть тепер. Якщо покупці та пошук натрапляють на помилки замість товарів, пояснення про алгоритм поки зарано приймати.

SEO-аудит сайту - це перевірка причин, через які важливі сторінки можуть бути недоступними, незрозумілими або не відповідати пошуковим запитам. Добрий результат аудиту - не товстий PDF, а список перевірених проблем із URL, доказами, пріоритетом і способом перевірити виправлення. Частину найважливішого власник може побачити сам за 40 хвилин. Решта потребує доступу, інструментів і людини, яка вміє відрізняти шум сканера від реальної втрати.

Пройдемо самоаудит на умовному інтернет-магазині товарів для дому. Після редизайну він змінив адреси категорій і товарів, але команда не налаштувала перенаправлення зі старих URL. Це навчальне розслідування, а не кейс GrandMa чи підтверджена причина спаду на чиємусь сайті.

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

Для нашого умовного магазину беремо п’ять важливих адрес: головну, дві категорії та два товари, які мали пошукові переходи до редизайну. Старі URL можна взяти зі звіту Search Console за попередній період, зі старої карти сайту або зі збереженого списку сторінок. Поруч запиши нові адреси тих самих товарів. Тепер є що порівнювати, замість того щоб натискати кнопку «сканувати весь сайт» і чекати вироку.

Це не повний технічний SEO-аудит. Це маршрут, який допомагає зрозуміти, чи потрібна термінова правка, глибша діагностика або обидві. Доступ до Search Console дуже бажаний; без нього ти побачиш менше.

У Search Console назви звітів тут наведено за англомовним інтерфейсом; локалізація і налаштування можуть відрізнятися. Google пояснює призначення Search Console, а URL Inspection дає дані про версію сторінки, відому Google, і окрему перевірку живої URL. Це різні стани: сайт міг уже змінитися, а пошук ще не обійшов нову версію.

Команда може використати site: як швидкий орієнтир, але Google попереджає, що результати такого запиту не є повним списком індексованих URL. Не роби з числа вгорі видачі бухгалтерію індексації. Для конкретної сторінки відкривай URL Inspection.

Якщо в тебе немає доступу до Search Console, запиши це як першу організаційну проблему. Попроси власника ресурсу надати доступ до потрібного домену або розділу, а не пересилати раз на місяць скриншот графіка. Поки чекаєш, перевір живі сторінки, старі URL й мобільний шлях покупки. У звіті чесно розділи побачене власноруч і те, що без Search Console поки невідоме.

За сценарієм старий URL товару після редизайну повертає 404, новий URL відкривається, але стара адреса на нього не перенаправляє. Два старі посилання на категорію в меню теж ведуть у порожнечу. Це перевірена технічна проблема в межах прикладу, яка могла вплинути і на людей, і на пошуковий обхід. Вона ще не доводить, яку частку спаду кліків спричинила саме ця помилка: попит, сезон і зміни сторінок могли діяти одночасно.

План виправлення починається з карти відповідностей: стара категорія → її нова категорія, старий товар → той самий товар за новою адресою. Для постійно перенесених сторінок Google рекомендує постійні серверні перенаправлення, зокрема 301 або 308. Не веди всі старі товари на головну: людина шукала конкретний товар, і її маршрут має залишатися зрозумілим. Якщо товар знято назавжди й відповідної заміни немає, 404 може бути чесним результатом; це не автоматична «помилка SEO».

Після налаштування відкрий кожну пару старої та нової адреси, перевір кінцевий статус, товар, title, canonical, внутрішні посилання й актуальну карту сайту. Ланцюжок із кількох редиректів краще скоротити до одного прямого переходу. Потім дивись на конкретні URL у Search Console протягом наступних тижнів. Google зазначає, що переобхід під час переїзду займає час; я не обіцяла б дату повернення попередніх кліків.

Цей приклад також показує, чому замовний аудит не варто починати зі списку кольорових оцінок. Один відсутній маршрут зі старих URL може бути важливішим за десятки попереджень про декоративні зображення, якщо саме ці URL приводили покупців.

Знахідку варто оформити так, щоб розробник не мусив повторювати твоє розслідування. Для нашого умовного магазину це може бути коротка таблиця:

Тут немає колонки «очікуваний приріст трафіку», бо його не можна чесно вивести з трьох перевірок. Є конкретні дії й ознаки готовності. Якщо в магазині тисячі зламаних адрес, ту саму логіку застосовують до повного списку та перевіряють не лише три приклади.

У звіті Page indexing слово «не проіндексовано» не є діагнозом. Google пояснює, що сторінки можуть бути відсутні в індексі з правильних причин: дубль, свідомий noindex або знятий товар без заміни. Якщо URL ніколи не індексувалася, не називай це «деіндексацією». Перевір окремо, чи потрібна ця адреса в пошуку й чому Google її не включає.

robots.txt керує тим, що сканер може відвідати, але не є надійним способом приховати сторінку з пошуку. noindex має інше призначення: вказати, що сторінку не треба додавати до індексу, якщо робот може прочитати цю вказівку. Якщо правила суперечать одне одному, просте «прибрати все» може зробити гірше. Збережи знахідку й попроси фахівця пояснити план.

Canonical вказує бажану основну адресу серед дубльованих або дуже схожих сторінок. Google розглядає його як сигнал, а не безумовний наказ. Якщо новий товар має canonical на стару адресу, а стара віддає 404, це важливіше за довжину опису на товарі. Так само карта сайту допомагає знайти URL, але не гарантує їх індексацію чи позицію.

PageSpeed Insights може показати дані реальних користувачів і лабораторний тест. Core Web Vitals описують завантаження, реакцію та візуальну стабільність. Одна жовта оцінка не доводить причину падіння трафіку й не передбачає місце в Google. Але якщо картка товару стрибає під час натискання «Купити», це вже проблема людини, яку слід виправляти незалежно від графіка позицій.

Сорок хвилин достатньо, щоб помітити симптом і зібрати приклади. Вони не замінюють перевірку всього магазину. Якщо змінилися тисячі адрес, потрібні перелік старих і нових URL, обхід сайту, аналіз шаблонів категорій і товарів, перевірка редиректів, внутрішніх посилань, канонічних адрес, карт сайту та даних Search Console. Іноді потрібні серверні логи. Також треба подивитися, чи сторінки відповідають на реальні запити і чи не конкурують між собою.

Для малого сайту з десятьма сторінками та одного очевидного 404 обсяг буде іншим. Не купуй складну діагностику тільки тому, що вона товща. Різницю між коротким оглядом і платною діагностикою ми пояснювали окремо. Якщо хочеш почати з проблеми однієї сторінки, є перевірка сайту GrandMa. А SEO-послуга охоплює дослідження, пріоритети та подальшу роботу, коли одного огляду замало.

Корисний аудит також дивиться на сторінки, які мають приносити бізнесу звернення. Падіння кліків на старому блозі й зникнення сторінки основної послуги можуть мати різний пріоритет. Якщо працюєш локально, профіль компанії та Google Maps можуть бути окремою частиною пошукової присутності, яку технічний сканер сайту не вимірює.

Для приймання професійного аудиту я б попросила три рівні висновку. Перший - коротке резюме: що сталося, що доведено, що лишається гіпотезою. Другий - реєстр проблем із конкретними URL, кроком відтворення, наслідком, пріоритетом і відповідальним. Третій - план перевірки після змін: які URL відкрити, які дані в Search Console подивитися й коли повернутися до оцінки. Якщо підрядник також впроваджує правки, ці два результати треба показувати окремо: звіт про проблему не доводить, що її вже усунуто на живому сайті.

Попроси позначити залежності. Наприклад, немає сенсу переписувати title для старої URL, яка має перенаправляти на нову. Спочатку вирішують, яка адреса залишається, потім правлять поля й внутрішні посилання. Такий порядок заощаджує роботу редактора й не дає новому контенту з’явитися на сторінці, яку невдовзі приберуть.

1. Які URL і типи сторінок ви перевірите? Попроси назвати категорії, товари, послуги, блог і винятки. Слова «весь сайт» замалі для приймання роботи.
2. Які дані використаєте? Search Console, фактичні HTTP-відповіді, обхід сайту, карта старих адрес і бізнесові питання дають різні частини картини.
3. Як відрізните причину від збігу в часі? Після редизайну могло змінитися кілька речей. Підрядник має показати перевірені факти й межу висновку.
4. Як визначите пріоритет? Проси пояснити вплив на важливі сторінки, ризик, складність і залежності між змінами.
5. Хто вносить виправлення? Аудит і впровадження можуть бути різними роботами. Зафіксуй відповідального та формат завдань для розробника й редактора.
6. Що я отримаю на виході? Потрібні конкретні URL, докази, план першої черги, спосіб повторної перевірки й коротке пояснення для власника.

Якщо результатом є PDF на 80 сторінок із трьомастами однаковими «критичними» попередженнями й без списку перших п’яти дій, команда все ще не знає, що робити в понеділок. У хорошому аудиті можна відкрити URL, повторити перевірку та зрозуміти, кому передати виправлення. Після роботи окремо перевір живі сторінки, а не лише обіцянку в документі.