Найчастіше сайт втрачає органічний трафік не через слабкі тексти, а через технічні дрібниці, яких роками ніхто не помічає: canonical, що веде не туди, тестовий домен в індексі, тисячі дублів від фільтрів. Нижче сім помилок, які команда PBS регулярно бачить на аудитах, і спосіб швидко перевірити кожну на власному сайті.
Усі сім помилок ми регулярно знаходимо, коли проводимо для клієнтів технічний SEO-аудит сайту. У стандартні чеклисти вони зазвичай не потрапляють, бо сайт при цьому «працює нормально»: сторінки відкриваються, замовлення оформлюються, а трафік поступово просідає.
- 1. Canonical вказує не на ту сторінку
- 2. Тестовий домен в індексі або noindex на продакшені
- 3. Ланцюжки редиректів і внутрішні посилання на 301
- 4. Фільтри, сортування та UTM генерують тисячі дублів
- 5. Hreflang, який конфліктує сам із собою
- 6. Контент і посилання існують лише після виконання JavaScript
- 7. Sitemap зі сміттям і сторінки-сироти
- У якому порядку виправляти
1. Canonical вказує не на ту сторінку
Тег canonical є на сторінці, плагін показує зелену галочку, тому всі вважають, що питання закрите. На практиці трапляються три сценарії: сторінки пагінації канонізовані на першу (і товари з другої сторінки й далі Google бачить гірше), canonical веде на версію з http або без www, canonical на сторінках фільтрів веде на саму сторінку фільтра, хоча її планували закрити.
Як перевірити. У Google Search Console відкрийте «Перевірку URL» для кількох типових сторінок і порівняйте поля «Канонічна сторінка, вказана користувачем» та «Канонічна сторінка, вибрана Google». Якщо вони різняться на багатьох сторінках, Google вашим підказкам не довіряє. Масово це видно у Screaming Frog на вкладці Canonicals.
2. Тестовий домен в індексі або noindex на продакшені
Дві сторони однієї проблеми. Розробники піднімають dev- чи staging-копію без закриття від індексації, і в пошуку з’являється повний дубль сайту. Або навпаки: тестову версію закрили через meta robots noindex, а під час релізу цей тег переїхав на бойовий сайт. Другий випадок небезпечніший: сторінки випадають з індексу поступово, і падіння помічають через кілька тижнів.
Як перевірити. Пошукайте в Google унікальну фразу з вашого сайту в лапках: чужі піддомени з вашим контентом одразу спливуть. Після кожного релізу перевіряйте код головної та кількох шаблонних сторінок на noindex, а також заголовок X-Robots-Tag у відповіді сервера, бо його в коді сторінки не видно.
3. Ланцюжки редиректів і внутрішні посилання на 301
Сайт переїжджав на https, потім змінював структуру URL, потім прибирав слеш у кінці. Кожен переїзд додав свій редирект, і тепер стара адреса проходить три-чотири переадресації до фінальної. Окрема історія: меню, хлібні крихти та посилання в текстах досі ведуть на старі URL. Користувач цього не помічає, а робот витрачає краулінговий бюджет на зайві запити, і частина ваги посилань губиться дорогою.
Як перевірити. У Screaming Frog є звіт Redirect Chains, а фільтр внутрішніх посилань із кодом 3xx покаже, звідки саме вони стоять. Правило просте: внутрішні посилання мають вести одразу на сторінку з кодом 200, а будь-який редирект має бути в один крок.
4. Фільтри, сортування та UTM генерують тисячі дублів
Класика інтернет-магазинів. Каталог на 2 000 товарів, а в індексі чи в черзі на сканування 60 000 URL: комбінації фільтрів, сортування за ціною, параметри сесій, мітки з рекламних кампаній. Google витрачає ресурс на сміття, а нові товари й категорії індексуються із запізненням.
Як перевірити. У GSC у звіті «Індексування сторінок» подивіться причини «Сторінка є копією» та «Просканована, але не проіндексована» і зверніть увагу на приклади URL із параметрами. Звіт «Статистика сканування» покаже, яку частку запитів робота забирають такі адреси. Далі рішення залежить від CMS: закриття параметрів у robots.txt, canonical на основну категорію, винесення частотних фільтрів в окремі статичні посадкові сторінки.
5. Hreflang, який конфліктує сам із собою
Для українських сайтів із двома мовними версіями це чи не найпоширеніша проблема. Типові помилки: українська сторінка посилається на російську, а та у відповідь ні (hreflang працює лише у парі); hreflang вказує на URL, який віддає редирект або закритий від індексації; canonical обох версій веде на одну мову, і друга версія фактично прибирається з індексу власноруч.
Як перевірити. Відкрийте код парних сторінок і переконайтесь, що кожна містить посилання і на себе, і на альтернативну версію, а canonical у кожної веде на саму себе. У Screaming Frog вкладка Hreflang має готові фільтри Missing Return Links та Non-200 Hreflang URLs.
6. Контент і посилання існують лише після виконання JavaScript
Сайт на сучасному фреймворку виглядає чудово, але в сирому HTML замість тексту порожній контейнер. Google уміє рендерити JavaScript, проте робить це з затримкою і не завжди повністю. А більшість AI-краулерів, які збирають дані для відповідей ChatGPT чи Perplexity, JavaScript не виконують узагалі. Тож якщо опис товару, ціна або блок перелінковки з’являються лише після рендерингу, для частини роботів їх просто немає.
Як перевірити. Порівняйте вихідний код сторінки (Ctrl+U) з тим, що бачите у вкладці Elements в інструментах розробника. Ключовий контент, заголовки та посилання у форматі <a href> мають бути вже у вихідному коді. У GSC «Перевірка URL» → «Переглянути перевірену сторінку» покаже HTML, який реально отримав Googlebot.
7. Sitemap зі сміттям і сторінки-сироти
Карта сайту генерується автоматично, і ніхто не дивиться, що в ній: редиректи, видалені товари з кодом 404, сторінки з noindex. Для Google це сигнал, що файлу не можна довіряти. Зворотна ситуація: важливі сторінки є в sitemap, але на них не веде жодне внутрішнє посилання. Такі сторінки-сироти індексуються погано і майже не ранжуються, бо не отримують внутрішньої ваги.
Як перевірити. Завантажте sitemap.xml у Screaming Frog у режимі List і подивіться коди відповіді: там мають бути лише сторінки з кодом 200, відкриті для індексації, з canonical на себе. Щоб знайти сиріт, підключіть до сканування sitemap і дані GSC, а потім відкрийте звіт Orphan Pages.
У якому порядку виправляти
Спочатку те, що блокує індексацію повністю: noindex на продакшені, помилки canonical, конфлікти hreflang. Потім те, що марнує краулінговий бюджет: дублі від параметрів, ланцюжки редиректів, брудний sitemap. JavaScript-рендеринг зазвичай найдорожчий у виправленні, тому його варто планувати разом із розробниками як окремий проєкт.
Жодна з цих помилок не видна неозброєним оком: сайт відкривається, замовлення оформлюються. Саме тому технічну перевірку варто повторювати після кожного великого релізу, а не раз на кілька років.
