Сайт віддає 200 на будь-яку неіснуючу адресу: перевірка за десять секунд

Коротка відповідь: якщо у вивідній теці статичного сайту немає файлу сторінки помилки, частина хостингів віддає на будь-який неіснуючий шлях головну сторінку з кодом 200. Не порожню відповідь, не помилку, а повноцінну головну, яка виглядає як звичайна сторінка сайту.

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

Як ми на це напоролись

Симптом виглядав дрібним і не там, де була причина.

Ми видалили файл з проєкту, задеплоїли й перевірили адресу. Вона віддавала 200. Перша думка була про кеш, друга про те, що збірка не пройшла.

Насправді сторінка віддавала не свій старий вміст. Вона віддавала головну. Запит на видалений файл, запит на випадковий набір символів, запит на будь-що: усе давало ту саму головну сторінку з кодом успіху.

Далі ми прогнали весь портфель. З восьми сайтів проблема виявилась на одному, тому це не системна біда, а конкретна конфігурація конкретного проєкту. Але саме тому її й не помічають: вона з'являється мовчки на новому сайті, зібраному без сторінки помилки.

Перевірка, яка займає десять секунд

Потрібен один запит до будь-якої явно неіснуючої адреси.

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

200 означає, що пастка активна. Сервер каже, що сторінка є, хоча її немає.

404 означає, що все гаразд. Саме цього ми й хочемо.

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

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

Чому це шкодить

Механіка проста, а масштаб неочевидний.

Пошукова система отримує сторінку з кодом успіху й не має підстав вважати її помилкою. Для неї це нова сторінка сайту. Вміст у неї такий самий, як у головної, тому вона стає дублем.

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

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

Для ШІ-систем картина та сама, але гірша. Вони отримують сторінку з кодом успіху й читають її як валідне джерело, не маючи жодного натяку, що адреса помилкова.

Ще три пастки з того самого інциденту

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

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

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

Третя, найпідступніша: проміжний кеш тримає стару відповідь. Джерело вже віддає 404, а домен усе ще відповідає 200, бо відповідь закешована. У нашому випадку термін життя кешу становив тиждень.

Перевіряти в такій ситуації треба в обхід кешу: або за адресою конкретного деплою, або з параметром, який ламає кешування. Інакше ви полагодите й вирішите, що не полагодили.

Що зробити, щоб не повторилось

Три дії, усі дешеві.

Покласти сторінку помилки у вивід. У більшості генераторів це шаблон з явно вказаним кінцевим шляхом і позначкою не включати його в колекції та в карту сайту. Сторінка має віддаватись, але не перелічуватись.

Поставити перевірку в збірку. У нас збірка падає, якщо файл сторінки помилки зник з результату. Це дешевше за будь-який моніторинг, бо ловить проблему до деплою.

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

Чого ми не стверджуємо

Кілька меж.

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

Ми не міряли, скільки саме дублів встигає потрапити в індекс до виправлення. Логіка підказує, що це залежить від того, скільки помилкових посилань на вас існує, але цифри в нас немає.

І один сайт з восьми це не привід говорити про епідемію. Це привід один раз перевірити свої.

Часті питання

Як зрозуміти, що в мене ця проблема?

Один запит до вигаданої адреси. Код 200 означає, що пастка активна.

Хіба редирект на головну не рівноцінний?

Ні. Перенаправлення чесно каже, що сторінки немає й показує іншу. Код 200 стверджує, що сторінка існує.

Чи достатньо намалювати гарну сторінку помилки?

Недостатньо. Важливий не вигляд, а код відповіді. Красива сторінка з кодом 200 це та сама пастка.

Полагодили, а домен усе одно віддає 200.

Найімовірніше, відповідь лежить у кеші. Перевіряйте в обхід, за адресою конкретного деплою.

Чи стосується це сайтів на звичайному сервері?

Там поведінка інша й зазвичай коректна. Пастка характерна для статичного хостингу без явно покладеного файлу помилки.

Підсумок

Статичний хостинг без файлу сторінки помилки може віддавати головну з кодом 200 на будь-який неіснуючий шлях. Це м'який 404 на необмеженій кількості адрес, і кожне чуже зламане посилання стає проіндексованою копією головної.

Перевірка займає десять секунд: запит до вигаданої адреси й погляд на код відповіді. Виправлення це один файл у виводі плюс перевірка в збірці.

Три суміжні пастки здатні переконати вас, що все гаразд, коли це не так: редирект самої сторінки помилки, брудна тека збірки й закешована стара відповідь. Перевіряти треба в обхід кешу, інакше висновок буде хибним.

Матеріал підготували Євгеній Чиж, засновник Chyzh Agency, і Дмитро Попрядухін, Head of SEO.