Що важливо зрозуміти за темою «Перевірка статус-кодів і помилок 404»

Коли браузер або пошуковий робот запитує сторінку, сервер відповідає не текстом чи картинками, а коротким числовим кодом. Це статус-код — своєрідна візитка відповіді сервера. Він каже запитувачу: «все ок», «сторінка переїхала», «такої сторінки немає» або «у мене проблеми, спробуй пізніше».

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

  • 2xx — успішні відповіді. Код 200 означає, що сторінка віддалася нормально. Це ідеальний сценарій.
  • 3xx — переадресації. Найчастіше це 301 (постійне переміщення) та 302 (тимчасове). Вони кажуть роботу: «стороні тут немає, але вона тепер за цією адресою».
  • 4xx — помилки клієнта. Найвідоміший — 404, який означає «сторінку не знайдено». Також буває 410 («сторінку видалено назавжди»), який для SEO навіть корисніший за 404.
  • 5xx — помилки сервера. Коди 500, 502, 503 свідчать про збій на боці хостингу чи серверного ПЗ. Це критично, бо робот просто не може отримати сторінку.

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

Практичні особливості та варіанти застосування

Перевірка статус-кодів — це не разова дія, а регулярна процедура. На великих сайтах ситуація змінюється щодня: додаються нові сторінки, старі видаляються, оновлюються URL категорій, змінюються правила роутингу.

Інструменти для перевірки

Для повного збору статус-кодів потрібен краулер, який пройде по всьому сайту або по конкретному списку URL. Screaming Frog, Netpeak Spider, Sitechecker — кожен із них дає таблицю, де кожен URL має свою колонку зі статус-кодом. Фільтруєте по 4xx і 5xx — і перед вами картина проблем.

Google Search Console показує помилки 404 і 5xx у розділі «Індексація сторінок», але з затримкою і не повністю. Це доповнення, а не заміна повного краулінгу.

Як працювати з різними типами помилок

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

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

Ланцюжки редиректів. Коли URL A редиректить на B, а B — на C, це ланцюжок. Пошукові роботи проходять кілька рівнів, але кожен зайвий крок — це втрата часу і «сили» посилання. Оптимально — один редирект 301 з видаленої сторінки на актуальну.

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

М'які 404: прихована проблема

Сервер віддає код 200, але на сторінці немає реального контенту — лише напис «сторінку не знайдено» або порожній шаблон. Для пошуковика це 200-та відповідь, тому він індексує цю «порожнечу». Google називає це soft 404 і явно показує в Search Console. Виправляється так: сервер має повертати справжній код 404, а не 200 з повідомленням про відсутність сторінки.

Помилки, обмеження та що враховувати на практиці

Редирект усіх 404 на головну — поширена помилка

Багато хто налаштовує так: будь-який неіснуючий URL веде на головну сторінку з кодом 301 або 302. Це здається зручним для користувача, але створює дві проблеми. Перша — пошуковий робот думає, що за кожною цією адресою є унікальний контент (адже код не 404), і починає індексувати дублі головної сторінки з різними URL. Друга — якщо на старі сторінки вели зовнішні посилання, їхня вага розпорошується, бо всі вони тепер вказують на головну, а не на тематичні заміни.

Занадто багато 404 — сигнал проблем

Десяток 404 на сайті з тисяч сторінок — нормально. Тисячі 404 — це вже симптом. Можливо, зламалася генерація URL, змінилася структура категорій без редиректів, або масово видалили товари без налаштування обробки видалених сторінок. Пошукові системи сприймають це як ознаку низької якості технічної підтримки сайту.

5xx помилки вимагають негайної реакції

На відміну від 404, помилки 5xx означають, що сервер не може обробити навіть коректний запит. Якщо Googlebot регулярно стикається з 5xx, він може знизити частоту краулінгу або взагалі тимчасово припинити сканування. Тому моніторинг 5xx — це завдання не раз на місяць, а постійне. Uptime-моніторинг (Ping-Admin, UptimeRobot) дасть сповіщення ще до того, як проблема зачепить індексацію.

Обмеження інструментів

Краулери на кшталт Screaming Frog у безкоштовних версіях обмежені кількістю URL (зазвичай 500). На великих сайтах це дає лише уривчасту картину. Також класичні краулери не завжди коректно рендерять JavaScript-контент — сторінка може віддавати 200 з порожнім шаблоном, а реальний контент підвантажується скриптом пізніше. Для таких випадків потрібні інструменти з рендерингом (Screaming Frog у платній версії з JavaScript rendering, або хмарні сервіси).

Коли 404 — це правильна відповідь

Не кожну 404 треба «лікувати». Якщо сторінку видалено, заміни немає, і на неї не ведуть цінні зовнішні посилання — 404 є чесною та правильною відповіддю. Спроба зробити редирект на щось суміжне часто виглядає спамом і дратує користувача, який очікував побачити конкретний товар чи статтю. Краще показати нормальну сторінку 404 з пошуком, навігацією та популярними розділами — це збереже довіру і не заплутає пошуковика.