Модуль 5 · Урок 17

HTTP, redirects, status codes і дублікати

HTTP response — машинний факт про стан URL. Правильний аудит читає весь redirect chain, кінцевий status, content і canonical, а не довіряє тому, що браузер «щось показав».

2xx3xx4xx / soft 4045xx / 429

Status contract

КласСенс для URLSEO-рішення
2xxЗапит успішний; content може оброблятисяПеревірити реальний main content, indexability і canonical
301/308Постійне переміщенняВести прямо на еквівалентну final destination
302/303/307Тимчасове переміщенняSource може лишатися preferred; використовуйте лише коли move тимчасовий
404/410Ресурс відсутнійПовернути чесний status або redirect лише за наявності релевантної заміни
429/5xxRate/server failureВиправити availability, capacity, retry behavior; не маскувати 200

Redirect має зберігати намір

Permanent server-side redirect є сильним canonical signal. Будуйте one-hop map old URL → найближча еквівалентна final page. Не відправляйте всі видалені матеріали на homepage: якщо заміни немає, 404/410 чесніші для людини й системи.

BeforeInventory URLs, links, traffic/backlinks, destination equivalence, query parameters і dependencies.
AfterSource status, Location, hops, final 200, canonical, content parity, updated internal links і sitemap.

Chains і loops — операційний борг

A→B→C витрачає час і створює більше точок відмови; A→B→A блокує доступ. Оновіть rules та internal links до прямого final URL.

Soft 404: 200 без корисного ресурсу

Сторінка може повертати 200, але показувати «нічого не знайдено», порожній template або нерелевантний replacement. Google може трактувати її як soft 404. Перевіряйте status разом із main content і URL purpose. Custom 404 page корисна для навігації, але HTTP response все одно має бути 404.

Removed URL decision
Exact replacement? → 301/308. Temporary outage? → 503 із контрольованим retry. Resource permanently gone without replacement? → 404/410. Never return 200 only to hide an error.

Duplicate inventory, а не «магічний canonical»

Дублікати виникають через protocol/host, slash, parameters, sort/filter, print/AMP, tracking, case, session IDs або CMS archives. Для кожного pattern визначте: потрібна окрема сторінка, crawl-only utility, canonical alternate, redirect чи removal. Не canonicalize різні tasks/contents на одну сторінку.

Evidence. Sample URLs, response, content similarity, internal links, sitemap і selected canonical.
Rule. Один documented pattern із exceptions, owner і test set.
Rollout. Спочатку мала вибірка, потім validation, лише після цього масштабування.
Monitor. Coverage, crawl/server logs, selected canonicals, traffic і 404 reports.

Практика уроку

  1. Побудуйте redirect/status inventory для 20 дозволених URL.
  2. Розгорніть кожен chain: source status, hops, final status, canonical і content match.
  3. Знайдіть один soft-404 candidate та доведіть observation.
  4. Створіть redirect map із reason, owner, acceptance і rollback.
  5. Не запускайте mass redirect без staging test, backup і sign-off.

Офіційні джерела

Практична перевірка · урок 17 з 42

Закріпіть матеріал уроку

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

1. Який redirect сигналізує постійне переміщення?
2. Коли доречний 302/307?
3. Куди має вести redirect видаленої сторінки?