Що таке soft 404 (і чому Google звертає на це увагу)

«Soft 404» — це повідомлення від Google: «Це схоже на відсутню сторінку, хоча сервер не відправив коректний 404.» Зазвичай сервер повертає 200 OK (іноді 302 або 403) разом із контентом, який нагадує сторінку помилки, майже порожню сторінку, результат пошуку без результатів або загальний шаблон.

Завдання Google — не пускати сміття в індекс. Якщо URL повертає 200, але поводиться так, ніби «тут нічого немає», індексувати його значить засмічувати результати пошуку. Тому Google намагається вивести намір: відсутній контент, тонкий контент, дублі шаблону або шахрайські поведінки, спричинені редиректами/кешуванням.

Операційно soft 404 — це не «тільки SEO». Це питання розподілених систем: кеші, CDN, логіка редиректів, межі автентифікації, обробка ботів і непослідовні коди статусу. Googlebot — просто ще один клієнт із власними вимогами.

Практичне правило: ваш сайт має бути нудним для краулерів. Передбачувані коди статусу, послідовний контент, мінімум сюрпризів. Сюрпризи — для запусків продуктів, а не для HTTP-відповідей.

Чому сайти на WordPress викликають soft 404

1) «Красиві» сторінки 404, що повертають 200

Багато тем WordPress рендерять гарну сторінку «Сторінку не знайдено», але забувають відправити статус 404 Not Found. Іноді це проблема теми, іноді плагіна, іноді — шар кешування, який зберіг сторінку 404 і віддає її як 200.

2) Результати пошуку, архіви тегів і пагінація, що виглядають порожніми

WordPress може створювати багато URL: /tag/, /author/, /page/99/, внутрішні результати пошуку, датовані архіви. Коли такі сторінки мають мало контенту (або «No posts found»), Google може трактувати їх як soft 404 — особливо якщо сервер повертає 200 з шаблоном, що переважно складається з заголовку/футера.

3) «Прибирання» редиректами, що стирає сенс

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

4) Режим обслуговування, WAF та блокування ботів, що надто «кмітливі»

Деякі сайти повертають 200 зі сторінкою «в обслуговуванні», або блокують ботів і віддають HTML «Доступ заборонено» з 200. Googlebot індексує таку сторінку або позначає soft 404. Якщо потрібно блокувати — робіть це правильно: 503 для обслуговування з Retry-After, 401/403 для автентифікації, і послідовну поведінку.

5) Непослідовний рендеринг: бот бачить одне, люди — інше

Гео-правила, A/B тестування, персоналізація, банери згоди і проблеми з JS можуть змінювати вміст сторінки. Якщо Googlebot отримує обчистену сторінку, інтерстиціал або порожню оболонку, він може поставити оцінку «відсутня». Іноді нічого «не ламається» у вас, поки ви не протестуєте як Googlebot і не побачите сумну правду.

Жарт №1: Soft 404 — як колега, який каже «Я не звільняюсь», пакуючи свої речі в коробку.

Швидкий план діагностики (перевіряйте в цьому порядку)

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

Перш за все: перевірте HTTP-статус і кінцевий пункт

• Чи повертає URL 200, відображаючи при цьому повідомлення про 404?
• Чи є ланцюг редиректів, що завершується на головній або сторінці пошуку?
• Чи вказує canonical на інше місце?

По-друге: порівняйте, що бачить Googlebot, і що бачите ви

• Зробіть запит з User-Agent Googlebot. Порівняйте довжину HTML, title, robots meta, canonical та body-контент.
• Перевірте, чи не вставляє WAF/CDN перевірки або інтерстиціали.

По-третє: ізолюйте шар, що «бреше»

• Чи віддає неправильний статус origin server (WordPress/PHP)?
• Чи шар кешування переписує або кешує сторінки помилок некоректно?
• Чи плагін створює редиректи або «розумну» обробку 404?

По-четверте: визначте намір URL

• Чи повинна сторінка існувати? Зробіть її суттєвою і придатною для індексації.
• Чи повинна вона бути відсутня? Повертайте 404 або 410 і не редиректьте на непридатні сторінки.
• Чи повинна існувати, але не індексуватися? Повертайте 200 з noindex, але зберігайте корисний контент для користувачів.

Як Google вирішує, що сторінка — «soft 404»

Google не публікує повний алгоритм класифікації (і вам не варто цього хотіти), але за сигналами можна зробити висновки:

• Схожість контенту до відомих шаблонів помилок: «Not found», «no longer available», «nothing here» тощо.
• Тонкий контент: переважно навігація, шапка/футер, відсутній основний контент.
• Несподівані редиректи: багато відсутніх URL редиректять на загальні сторінки.
• Низька унікальна цінність: фасетні архіви або авто-генеровані сторінки без відмінностей.
• Аномалії fetch/render: заблоковані ресурси, JS-помилки, інтерстиціали, стіни згоди, виклики WAF.
• Послідовність у часі: один і той самий URL переключається між «реальним контентом» і «порожнім» через стан кешу або гео.

Google також дивиться на загальну модель сайту. Якщо тисячі URL поводяться як «порожні сторінки» з 200, до сайту швидко виникає недовіра.

Одна оперативна цитата, яка має бути в кожному runbook на виклику: You build it, you run it. — Werner Vogels

Практичні завдання: команди, виводи та рішення

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

Завдання 1: Перевірте кінцевий HTTP-статус і ланцюг редиректів

cr0x@server:~$ curl -sSIL https://example.com/suspect-url | sed -n '1,25p'
HTTP/2 301
date: Sat, 27 Dec 2025 10:12:11 GMT
location: https://example.com/
cache-control: max-age=3600
server: nginx

HTTP/2 200
date: Sat, 27 Dec 2025 10:12:11 GMT
content-type: text/html; charset=UTF-8
cache-control: max-age=300
server: nginx

Що це означає: URL редиректить на головну. Якщо таке трапляється для відсутніх сторінок, Google часто позначає soft 404, бо ціль невідповідна.

Рішення: Якщо URL дійсно видалено, припиніть редиректити його на головну. Поверніть 404 або 410. Якщо сторінка переміщена — редиректьте на найближчий релевантний еквівалент, а не на загальну сторінку.

Завдання 2: Перевірте, чи тіло сторінки містить шаблон «не знайдено», попри 200

cr0x@server:~$ curl -sS https://example.com/missing-page | grep -Ei 'not found|404|no posts found|nothing here' | head
404
Sorry, the page you are looking for could not be found.

Що це означає: Сайт повідомляє користувачам, що сторінка відсутня, але ймовірно повертає 200.

Рішення: Виправте коди статусу в джерелі (тема/шаблон або WordPress-хуки), потім перевірте знову. Гарна 404-сторінка — це ок, але 404-сторінка з кодом 200 — ні.

Завдання 3: Порівняйте, що бачить Googlebot і звичайний браузер

cr0x@server:~$ curl -sS -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://example.com/product/widget | sed -n '1,20p'
<html>
<head>
<title>Access Denied</title>
<meta name="robots" content="noindex,nofollow">
</head>
<body>Request blocked.</body>

Що це означає: Правило WAF/CDN по-різному обробляє Googlebot. Навіть якщо люди бачать продукт, Google бачить сторінку блокування.

Рішення: Виправте доступ бота. Дозвольте Googlebot (обережно), або поверніть чесний код (403) і прийміть, що сторінка не індексуватиметься. Не віддавайте «Access denied» з кодом 200.

Завдання 4: Підтвердіть реальний статус від origin (обхід CDN, якщо можливо)

cr0x@server:~$ curl -sSIL --resolve example.com:443:203.0.113.10 https://example.com/missing-page | sed -n '1,12p'
HTTP/2 200
date: Sat, 27 Dec 2025 10:14:02 GMT
content-type: text/html; charset=UTF-8
server: nginx
x-cache: MISS

Що це означає: При прив’язці DNS до origin IP видно, що origin повертає 200. Проблема, ймовірно, у WordPress/темі або налаштуваннях origin, а не в CDN.

Рішення: Виправте обробку WordPress (шаблон, правила перезапису, плагіни), щоб відсутні сторінки повертали 404/410.

Завдання 5: Перевірте заголовки на предмет кешування сторінок, що схожі на помилки

cr0x@server:~$ curl -sSIL https://example.com/missing-page | egrep -i 'HTTP/|cache-control|age|x-cache|cf-cache-status|vary|location'
HTTP/2 200
cache-control: public, max-age=86400
age: 43122
x-cache: HIT
vary: Accept-Encoding

Що це означає: CDN/проксі кешує «відсутній» досвід на день. Якщо сторінка тимчасово помилкова або невірно маршрутизована, Google буде багаторазово бачити погану версію.

Рішення: Не кешуйте 404-шаблони як 200. Встановіть правильні коди статусу й різні TTL для відповідей помилок. Після виправлення очистіть кеші для цих записів.

Завдання 6: Перегляньте директиви robots і canonical

cr0x@server:~$ curl -sS https://example.com/suspect-url | egrep -i 'rel="canonical"|meta name="robots"' | head

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

Рішення: Виправте генерацію canonical. Кожна реальна сторінка має канонізувати саму себе; неканонічні сторінки слід обробляти через редиректи або noindex з чіткою причиною.

Завдання 7: Знайдіть патерни «порожніх архівів» WordPress у логах доступу

cr0x@server:~$ sudo awk '$7 ~ /\/tag\/|\/author\/|\/page\/[0-9]+\/|\/\?s=/' /var/log/nginx/access.log | tail -n 5
198.51.100.21 - - [27/Dec/2025:10:10:01 +0000] "GET /tag/obsolete/ HTTP/2.0" 200 18432 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
198.51.100.21 - - [27/Dec/2025:10:10:03 +0000] "GET /author/ghostwriter/ HTTP/2.0" 200 18012 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
198.51.100.21 - - [27/Dec/2025:10:10:06 +0000] "GET /page/99/ HTTP/2.0" 200 17655 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

Що це означає: Googlebot краулить тонкі/порожні архівоподібні URL, які часто отримують позначку soft 404.

Рішення: Вирішіть, чи заслуговують ці архіви на індексацію. Якщо ні — поставте noindex, або звужуйте внутрішні посилання та генерацію sitemap, щоб не запрошувати краулерів на марні URL.

Завдання 8: Перевірте, чи WordPress відправляє правильний статус для 404

cr0x@server:~$ curl -sS -o /dev/null -D - https://example.com/this-should-404 | head -n 8
HTTP/2 200
date: Sat, 27 Dec 2025 10:16:31 GMT
content-type: text/html; charset=UTF-8
server: nginx

Що це означає: Явний тривожний сигнал. Відсутня сторінка повертає 200.

Рішення: Виправляйте в джерелі: перевірте обробку 404 у WordPress, відключіть підозрілі плагіни, перегляньте правила перезапису, і переконайтеся, що ваш сервер не переписує відсутні URL до index.php без правильної логіки 404.

Завдання 9: Знайдіть правила «редирект на все» в Nginx

cr0x@server:~$ sudo nginx -T 2>/dev/null | egrep -n 'try_files|error_page|return 301|rewrite' | head -n 25
45:    try_files $uri $uri/ /index.php?$args;
88:    error_page 404 =200 /index.php;
132:   rewrite ^/old/(.*)$ / permanent;

Що це означає: error_page 404 =200 /index.php; — класичний підводний камінь. Він перетворює реальний 404 на 200, часто віддаючи тему 404 як успішну відповідь.

Рішення: Видаліть або виправте це. Якщо вам потрібні кастомні сторінки помилок — зберігайте 404. У Nginx віддавайте краще error_page 404 /404.html; (без =200), або дозвольте WordPress обробляти 404, але впевніться, що він відправляє правильний статус.

Завдання 10: Перевірте Apache на предмет неправильної конфігурації ErrorDocument

cr0x@server:~$ sudo apachectl -t -D DUMP_VHOSTS 2>/dev/null | head
VirtualHost configuration:
*:80                   example.com (/etc/apache2/sites-enabled/000-default.conf:1)

cr0x@server:~$ sudo grep -R "ErrorDocument 404" -n /etc/apache2/sites-enabled /var/www 2>/dev/null | head
/etc/apache2/sites-enabled/000-default.conf:23:ErrorDocument 404 /index.php

Що це означає: Якщо Apache маршрутизовує 404 на /index.php без збереження 404-статусу, WordPress може відповісти 200 зі сторінкою вигляду 404.

Рішення: Використовуйте виділений документ 404, що зберігає статус, або забезпечте, щоб PHP/WordPress виставляли коректний код при рендері «не знайдено».

Завдання 11: Підтвердіть, що WordPress може згенерувати справжній 404 через WP-CLI

cr0x@server:~$ cd /var/www/html
cr0x@server:~$ wp eval 'echo is_404() ? "is_404\n" : "not_404\n";'
not_404

Що це означає: Якщо запускати це у контексті запиту, складніше, але як саніті-чек це показує, що WordPress не трактує певні «відсутні» патерни як 404 (часто через кастомні rewrite або плагіни).

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

Завдання 12: Виявлення «soft 404 через тонкість» за допомогою довжини контенту

cr0x@server:~$ curl -sS https://example.com/tag/obsolete/ | wc -c
8123

cr0x@server:~$ curl -sS https://example.com/real-article/ | wc -c
128944

Що це означає: Сторінка тегу набагато менша за реальний матеріал. Це не завжди погано, але якщо вона здебільшого складається з шаблону і «No posts found», Google, ймовірно, поставить soft 404.

Рішення: Або покращіть сторінку (унікальний текст, відображення реальних елементів), або поставте noindex і зменшіть внутрішні посилання, які роблять її важливою.

Завдання 13: Перевірте sitemap на предмет URL, яких не повинно бути

cr0x@server:~$ curl -sS https://example.com/sitemap.xml | grep -Eo '<loc>[^<]+' | head
https://example.com/
https://example.com/tag/obsolete/
https://example.com/page/99/

Що це означає: Sitemap рекламуватиме тонкі/порожні URL. Google їх краулить, оцінює і повідомляє. Справедливо.

Рішення: Виправте генерацію sitemap (налаштування SEO-плагіна). Включайте тільки ті URL, що заслуговують на індексацію. Sitemap — це контракт; не підписуйте того, чого не можете виконати.

Завдання 14: Перевірте, що сервер повертає 410 для назавжди видаленого контенту

cr0x@server:~$ curl -sS -o /dev/null -D - https://example.com/old-campaign-2019 | head -n 6
HTTP/2 410
date: Sat, 27 Dec 2025 10:20:09 GMT
content-type: text/html; charset=UTF-8
server: nginx

Що це означає: 410 Gone чітко означає постійне видалення. Google зазвичай видаляє такі URL швидше, ніж 404.

Рішення: Використовуйте 410 для спеціально видалених сторінок, які не плануєте відновлювати. Для випадкових/помилкових URL підходить 404.

Завдання 15: Перевірте, чи якийсь «корисний» плагін редиректів маскує 404

cr0x@server:~$ wp plugin list --status=active
+---------------------+----------+--------+---------+
| name                | status   | update | version |
+---------------------+----------+--------+---------+
| redirection         | active   | none   | 5.4.2   |
| wp-super-cache      | active   | none   | 1.9.4   |
| seo-plugin          | active   | none   | 21.2    |
+---------------------+----------+----------+---------+

Що це означає: Плагіни редиректів нормальні — поки хтось не ввімкне глобальне правило «редиректити всі 404 на головну».

Рішення: Проведіть аудит правил. Видаліть глобальні правила 404→home. Замініть їх конкретними 301 редиректами, що маплять старі URL на найближчі нові.

Завдання 16: Підтвердіть, що ваша 404-сторінка позначена як 404 (і не кешується як 200)

cr0x@server:~$ curl -sS -o /dev/null -D - https://example.com/definitely-missing | egrep -i 'HTTP/|cache-control|age|x-cache|via'
HTTP/2 404
cache-control: no-cache, must-revalidate, max-age=0
x-cache: MISS

Що це означає: Це саме те, що бажано: коректний статус і консервативне кешування.

Рішення: Відправляйте це в продакшн. Потім очистіть всі застарілі кеші з 200 і попросіть переіндексацію у Search Console для ключових URL після виправлень.

Три корпоративні міні-історії з практики

Міні-історія №1: Інцидент через хибне припущення

Середнього розміру e‑commerce компанія мігрувала зі старої CMS на WordPress із новою гарною темою. Команда зробила те, що роблять команди: перевірила вручну топ‑50 сторінок. Все «працювало». Запуск відбувся в п’ятницю після обіду, бо звісно так роблять.

За тиждень Search Console засвітився soft 404 для продуктових URL. Сторінки продукту були доступні для людей, але Google почав їх виключати. Платний трафік продовжував конвертувати, органічний впав, й СЕО почув фразу «index coverage report».

Хибне припущення: «Якщо сторінка завантажується, її статус мусить бути 200 і це добре». Тема рендерила шаблон «product not available», коли товару не було, але повертала 200 і ставила canonical на сторінку категорії. Це не продуктова сторінка, а ввічливо замаскована відсутність.

Вони виправили це: сторінки, що вичерпалися тимчасово, повертали 200 лише якщо містили реальні деталі продукту й альтернативи. Дійсно видалені товари отримали 410 з релевантними редиректами, де це можливо. Також вони виправили canonical для реальних продуктів. Індексація поступово відновилася; ключове — послідовність і відсутність «флапінгу».

Міні-історія №2: Оптимізація, що повернулася бумерангом

Медіа-сайт хотів зменшити навантаження на origin. Вони ввели агресивне кешування на CDN і додали правило: кешувати HTML 24 години, включно зі «сторінками помилок», бо це підвищувало hit rate і робило дашборди спокійнішими.

Потім у WordPress стався короткий збій бази даних. Протягом кількох хвилин багато сторінок відрендерили мінімальний шаблон «No posts found» (бо запити не відпрацювали). Origin усе ще повертав 200, оскільки PHP-слой не кинув критичної помилки. CDN із задоволенням кешував ці відповіді на день.

Люди почали скаржитись, але справжня шкода була тихою: Googlebot краулнув у поганий інтервал, побачив багато майже пустих 200 сторінок і позначив їх як soft 404. Навіть після відновлення бази даних Google продовжував бачити кешовану пустоту.

Виправлення було непривабливим: перестати кешувати HTML-відповіді, що схожі на помилки, кешувати 5xx коротко і дати 404 адекватний TTL. Також додали application-level health gate: якщо WordPress не може виконати запит контенту — повертати 503, а не «успішну» порожню сторінку. Метрики продуктивності трохи погіршились; індексація і довіра користувачів покращились. Вибирайте компроміси свідомо.

Міні-історія №3: Нудна, але правильна практика, що врятувала ситуацію

Регульована B2B SaaS компанія вела документацію і лендинги на WordPress. Їхня SRE команда наполягла на бюрократичній процедурі: тижневий job, що краулить вибірку URL зі sitemap і перевіряє статус, canonical і довжину контенту.

Це було не модно. Воно запускалося з CI‑runner за допомогою curl і скидало результати в таблицю та канал оповіщень. Маркетинг іноді скептично реагував. SRE іноді відкатував їхні коментарі. Мир встановився.

Під час оновлення плагіна кешування виник баг на краю, і кеш почав віддавати 404-шаблон для деяких пагінованих архівів. Сторінки повертали 200 з «Nothing Found». Тижневий job виявив аномалію за кілька годин, а не тижнів, і вони відкотили оновлення до того, як Google обробив значну частку сайту.

Ця практика не виграла премії. Але вона запобігла індексаційній катастрофі — а це майже як операційна нагорода.

Жарт №2: Найшвидший спосіб створити soft 404 — «спростити редиректи» прямо перед святковими вихідними. Другий найшвидший — проговорити це вголос.

Поширені помилки: симптом → причина → виправлення

1) «Soft 404» на URL, що показують користувачеві повідомлення 404

Симптом: Сторінка каже «Не знайдено», але сервер повертає 200.

Корінь проблеми: Тема рендерить 404-шаблон, але серверний статус лишається 200, або Nginx/Apache переписує 404 на index.

Виправлення: Переконайтесь, що HTTP-відповідь — 404. Приберіть error_page 404 =200 патерни. Перевіряйте за допомогою curl -I і з UA Googlebot.

2) Відсутні сторінки редиректяться на головну

Симптом: Багато старих URL редиректять на /; Search Console позначає soft 404.

Корінь проблеми: Плагін редиректів «допомагає», відсилаючи всі 404 на головну, або універсальні правила перепису.

Виправлення: Замініть глобальні редиректи на конкретні 301 на релевантні заміни. Якщо заміни немає — повертайте 404 або 410.

3) Архівні сторінки позначені як soft 404

Симптом: Теги, автори, датовані архіви або пагінація фігурують як soft 404.

Корінь проблеми: Порожні архіви або дуже тонкі сторінки з переважно шаблоном.

Виправлення: Вирішіть: або зробіть їх цінними (куровані матеріали, вступний текст, реальні внутрішні посилання), або поставте noindex і приберіть із sitemap.

4) Сплески soft 404 після ввімкнення кешування CDN

Симптом: Search Console починає фіксувати багато URL незабаром після змін кешування.

Корінь проблеми: Кеш зберіг тимчасові пусті/помилкові відповіді як 200 та віддавав їх довго Googlebot.

Виправлення: Налаштуйте правила кешування: не кешуйте шаблони помилок, робіть TTL для 404/5xx консервативним, очищуйте кеш після виправлень і не кешуйте персоналізовані або бот-челенджовані відповіді.

5) Google бачить «Доступ заборонено» або інтерстиціали

Симптом: Soft 404 або «Crawled – currently not indexed» для важливих URL; fetch-as-bot показує сторінку блокування.

Корінь проблеми: WAF, бот-захист, гео-правила або стіни згоди, що віддаються Googlebot.

Виправлення: Дозвольте Googlebot (перевіряючи зворотний DNS, якщо ви суворі), або віддайте коректні 403/401 і прийміть неіндексацію. Не віддавайте сторінки блокувань з кодом 200.

6) Теги canonical зводять багато сторінок до однієї

Симптом: Багато URL мають canonical на головну або корінь категорії; індексація падає.

Корінь проблеми: Неправильні налаштування SEO-плагіна, баг теми або хак «уникнути дублікатів».

Виправлення: Встановіть canonical на саму сторінку для реальних сторінок. Використовуйте канонізацію свідомо, а не як кнопку паніки.

7) JSON/REST ендпоінти або параметричні URL індексуються і отримують flag

Симптом: Search Console показує soft 404 для дивних URL типу з параметрами або API-ендпоінтів.

Корінь проблеми: Внутрішні посилання на пошук, параметризовані сторінки, або плагін генерує сміттєві URL.

Виправлення: Перестаньте генерувати такі шляхи: обмежте внутрішні посилання, розгляньте noindex для результатів пошуку, і переконайтесь, що не-HTML ендпоінти не потрапляють у sitemap.

Контрольні списки / покроковий план

Крок 1: Тріаж URL

• Пакет A: Має існувати і бути проіндексований (строкові сторінки, ключові документи).
• Пакет B: Має існувати, але не індексуватися (внутрішній пошук, деякі архіви).
• Пакет C: Має не існувати (видалені кампанії, помилки друку, спамні параметри).

Не використовуйте одну глобальну політику для всіх пакетів. Це шлях до soft 404 — і до нарад.

Крок 2: Для Пакета A зробіть сторінку беззаперечно реальною

• Поверніть 200 з достатнім основним контентом.
• Переконайтесь, що canonical вказує на себе.
• Уникайте «сторінок без результатів», що маскуються під контент.
• Виправте відмінності рендерингу для Googlebot.
• Переконайтесь, що сторінка не блокується WAF, авторизацією або robots.

Крок 3: Для Пакета B тримайте чесність і намір

• Поверніть 200, але додайте noindex через meta robots (або X-Robots-Tag у заголовках).
• Вилучіть із XML sitemap.
• Зменшіть внутрішні посилання, що просувають їх як важливі.

Крок 4: Для Пакета C — правильно видаліть

• Поверніть 404 для невідомих/помилкових URL.
• Поверніть 410 для навмисно видаленого контенту, який не будете відновлювати.
• Редиректьте тільки коли є релевантна заміна. Редирект на головну рідко релевантний.

Крок 5: Виправте платформні поведінки, що створюють soft 404 у масштабі

• Тема: Переконайтесь, що 404-шаблони не переписують коди статусу.
• Плагіни: Аудит плагінів редиректів та SEO на предмет глобальних правил і канонікалів.
• Серверна конфігурація: Приберіть перепис 404→200 та інші «catch-all» хаки.
• CDN: Не кешуйте тимчасово порожні відповіді як довгоживучий HTML.
• Моніторинг: Додайте плановий краул, що вибірково перевіряє статус і розмір контенту важливих URL.

Крок 6: Підтвердьте і потім попросіть Google переоцінити

• Перевірте знову за допомогою curl -I і UA Googlebot.
• Очищайте кеші після виправлень.
• У Search Console запитуйте повторну індексацію для найважливіших URL. Не витрачайте запити на тисячі; виправте системні проблеми й дайте краулінгу зробити свою справу.

Факти та історичний контекст (корисно, не тривіально)

• Факт 1: «Soft 404» — це не HTTP-статус. Це класифікація пошукової системи, накладена на вашу фактичну відповідь.
• Факт 2: Раніше веб‑сервери часто віддавали кастомні сторінки помилок, але HTTP-статус мав значення; пошукові системи навчилися не довіряти «красивим помилкам» з 200.
• Факт 3: Гнучкість permalink і rewrite у WordPress — двосічний меч: вона робить багато URL «здійсненними», навіть коли контенту немає.
• Факт 4: Тренд на SPA і важкі JS‑теми збільшив випадки, коли краулери отримують «порожні оболонки», що виглядають як soft 404 при невдалому рендері.
• Факт 5: Прийняття CDN покращило продуктивність, але посилило баги: одна погана відповідь, закешована глобально, може змінити те, що бачать краулери на дні.
• Факт 6: Пошукові системи трактують масові редиректи на головну як проблеми якості; це нагадує «шахрайські редиректи» і поведінку з низькою цінністю.
• Факт 7: 410 Gone існує в HTTP десятиліттями, але використовується рідко; він може пришвидшити видалення, коли ви справді маєте на увазі «назавжди зникло».
• Факт 8: Параметри й фасетна навігація розмножили варіанти URL в e‑commerce і CMS; пошукові системи стали класифікувати багато майже порожніх комбінацій як низькоцінні або soft-404‑подібні.
• Факт 9: Управління ботами виросло у категорію продуктів; випадкове кидання викликів Googlebot тепер — поширена причина аномалій індексації.

Питання й відповіді

1) Чи завжди soft 404 — це погано?

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

2) Чи треба редиректити всі 404 на головну, щоб «врятувати SEO»?

Ні. Це класичний тригер soft 404. Редиректьте тільки коли є релевантна заміна. Інакше повертайте 404 або 410.

3) Що краще: 404 чи 410?

404 означає «не знайдено (можливо тимчасово)». 410 означає «прибрано (навмисно)». Використовуйте 410 для сторінок, які ви точно не плануєте відновлювати, особливо якщо їх продовжують краулити.

4) Чи може лише тонкий контент спричинити soft 404?

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

5) Моя WordPress 404-сторінка виглядає нормально — чому Google все одно скаржиться?

Бо Google дивиться на код статусу і намір. Якщо ви повертаєте 200 з повідомленням про 404, або канонізуєте все на головну, Google назве це тим, чим воно є: не реальною сторінкою.

6) Чи може кешування викликати soft 404, навіть якщо origin уже виправлено?

Абсолютно. CDN може закешувати тимчасову порожню відповідь як 200. Googlebot потрапляє на кешовану версію, а не на щойно виправлений origin, поки TTL не мине або ви не очистите кеш.

7) Чи ставити noindex для сторінок, що отримали soft 404?

Якщо сторінка має бути і індексована — виправте її, а не ставте noindex. Якщо сторінка має існувати, але не індексуватися (наприклад, внутрішній пошук) — noindex підходить, при умові, що вона корисна для користувачів.

8) Скільки часу Google потребує на відновлення після виправлень?

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

9) Чи потрібно міняти ядро WordPress для виправлення цього?

Зазвичай ні. Більшість причин — поведінка тем, плагінів, серверні правила (404→200) і кеш/WAF. Почніть з них.

10) Чому Google може позначити реальну сторінку як soft 404 під час міграції?

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

Висновок: наступні кроки, що дійсно мають значення

Soft 404 — не містичне явище. Це невідповідність між тим, що ваш сервер заявляє (200), і тим, що ваш контент повідомляє («тут нічого немає»), часто підсилена редиректами й кешуванням. Виправте невідповідність — і Google зазвичай заспокоюється.

1. Виберіть 10 позначених URL і прогоніть їх через швидкий план діагностики: статус, редиректи, вигляд для бота, поведінка кешу.
2. Приберіть глобальні редиректи 404→головна. Замініть на конкретні релевантні мапи або повертайте 404/410.
3. Зробіть 404 справжніми 404. Аудитуйте правила Nginx/Apache і поведінку теми, що змушують 200.
4. Вирішіть, що варте індексації. Якщо архіви/результати пошуку тонкі — або покращіть їх, або поставте noindex і приберіть із sitemap.
5. Виправте політику кешування, щоб тимчасова порожнеча не стала глобальною «істиною» на 24 години.
6. Додайте нудний тижневий краул. Нудне — надійне. Надійне — прибуткове.

Якщо ви виконаєте вищесказане, Search Console перестане доносити, Googlebot перестане недовіряти сайту, і ви рідше отримуватимете термінові повідомлення про «таємне падіння трафіку». А це й є справжній KPI.