Google Search Console — «Сторінка з переадресацією»: коли це нормально і коли шкодить

Що насправді означає «Сторінка з переадресацією»

У Search Console «Сторінка з переадресацією» — це статус індексації, а не моральний вирок.
Це означає, що Google спробував отримати URL і отримав відповідь з редиректом замість фінального контенту
(зазвичай 200). Google вирішив, що початковий URL не є канонічним, індексованим URL. Тому він не індексує
цей початковий URL; натомість слідує за редиректом і (можливо) індексує цільовий URL.

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

Ключове операційне питання не «Як змусити цей статус зникнути?» а:
Чи отримують індексацію, ранжування та стабільне обслуговування правильні цільові URL?

Що це не означає

• Не є помилкою за замовчуванням. Редирект — це валідна відповідь.
• Не доказ того, що Google збитий з пантелику. Це доказ того, що Google звертає увагу.
• Не гарантія, що цільовий URL буде індексовано. Редирект може вести у безвихідь.

Як Google обробляє це «під капотом» (практична версія)

Googlebot отримує URL A, отримує редирект до URL B і фіксує зв’язок.
Якщо сигнали послідовні (редирект стабільний, B повертає 200 і є канонічним, внутрішні посилання вказують на B, карта сайту
містить B, hreflang вказує на B тощо), Google схильний консолідувати сигнали індексації на B і відкинути A.
Якщо сигнали суперечливі — ви отримаєте еквівалент плечима від Search Console.

Одна інженерна реальність, яку іноді недооцінюють SEO-фахівці: редиректи не є безкоштовними. Вони витрачають бюджет краулінгу,
додають затримку, можуть дивно кешуватися і створювати прикордонні випадки у взаємодії CDN, браузерів і ботів. У продакшні
найпростішим редиректом є той, який вам не потрібен.

Коли це нормально (і коли варто ігнорувати)

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

Сценарії, де це нормальне

• HTTP → HTTPS. Ви хочете, щоб HTTP-URL постійно переадресовувалися.
  GSC часто показуватиме HTTP-URL як «Сторінка з переадресацією». Це нормально.
• www → без www (або навпаки). Непріоритетний хост має редиректити на пріоритетний.
• Нормалізація слешу в кінці. Оберіть один варіант і редиректіть інший.
• Стара структура URL після міграції. Старі шляхи редиректять на нові.
• Очищення параметрів (деякі параметри трекінгу, ідентифікатори сесій). Редирект або канонікалізація в залежності від семантики.
• Локалізоване або регіональне роутування, якщо виконане обережно (і не на базі ненадійних IP-евристик).

Як виглядає «нормально» в метриках

• Цільові URL з’являються в розділі Індексується і показують покази/клацання.
• Редиректи одношагові (A → B), а не A → B → C → D.
• Тип редиректу переважно 301/308 для постійних переміщень (за рідкісними винятками).
• Внутрішні посилання, rel=canonical та карти сайту переважно вказують на цільові URL.
• Лог-файли сервера показують успішні звернення Googlebot до цільового контенту (200).

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

Коли це шкодить (і як проявляється)

«Сторінка з переадресацією» шкодить, коли вона приховує нестиковку між тим, що ви хочете індексувати, і тим,
що Google здатен надійно отримати, відрендерити та вважати канонічним. Також це шкодить, коли редиректи використовуються як тимчасове
латкування для глибших проблем (дубльований контент, неправильно маршрутизовані локалі, биті внутрішні посилання, непослідовний протокол/хост).

Сценарії високого впливу

1) Ланцюги редиректів і витрата краул-бюджету

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

2) Редирект на неіндексований ресурс

Редирект на URL, що повертає 404, 410, 5xx, заблокований robots.txt або має «noindex» — це тихе видалення сторінок.
GSC покаже початковий URL як «Сторінка з переадресацією», але реальна проблема — що цільовий URL не можна індексувати.

3) Використання 302/307 як «постійного» редиректу

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

4) Змішані сигнали: редирект каже одне, canonical — інше

Якщо URL A редиректить на B, але canonical сторінки B вказує назад на A (або на C), ви створили суперечку за канонічність.
Google обере переможця. Це може бути не ваш улюблений варіант.

5) Редиректи, що тригеряться UA, гео, куками або JS

Умовні редиректи — найшвидший шлях отримати «працює на моєму ноуті» SEO. Googlebot — не ваш браузер.
Ваш крайовий CDN — не ваш origin. Origin — не ваш staging. Якщо редирект залежить від умов,
тестуйте його так, як бачить його Google.

6) Карти сайту, напхані URL з редиректами

Карта сайту призначена для переліку канонічних, індексованих URL. Коли ви даєте Google тисячі перенаправлених URL у sitemap,
ви по суті посилаєте його у доручення. Він виконуватиме довгий час, а потім тихо знизить пріоритет.

Жарт №1: Ланцюги редиректів — як ланцюги корпоративного погодження: ніхто не знає, хто додав останній крок, але всі терплять затримку.

Як виглядає «шкода» у результатах

• Переважні URL не індексуються або індексуються нестабільно.
• У звіті Coverage з’являються сплески «Duplicate, Google chose different canonical» поруч із редиректами.
• У звіті Performance покази падають для мігрованих сторінок і не відновлюються.
• Логи сервера показують, що Googlebot натрапляє на редиректні URL замість канонічних цілей.
• Велика частина краулінгу витрачається на редиректи замість контентних URL.

Фізика редиректів: 301/302/307/308, кешування та канонізація

Коди стану, з погляду операторів

• 301 (Moved Permanently): «Це нова адреса.» Агресивно кешується клієнтами та проміжними вузлами. Добре для канонічних переміщень.
• 302 (Found): «Тимчасово тут.» Історично трактувався як тимчасовий. Пошукові системи стали гнучкішими, але ваш намір має значення.
• 307 (Temporary Redirect): Як 302, але суворіше зберігає семантику методу. Більш релевантний для API.
• 308 (Permanent Redirect): Як 301, але збереження семантики методу. Стає більш поширеним.

Теги canonical vs редиректи: обирайте інструмент

Редирект — це інструкція на стороні сервера: «Не залишайся тут.» Canonical — підказка всередині сторінки: «Індексувати інший.»
Якщо ви можете безпечно редиректити (без впливу на користувачів, без функціональної потреби зберігати старий URL), робіть це. Це сильніше й чистіше.
Використовуйте canonical для випадків, коли дублі мають залишатися доступними (фільтри, сортування, параметри трекінгу, друковані версії).

Але не змішуйте їх необережно. Якщо ви робите редирект A → B, то canonical сторінки B майже завжди має бути B. Ви хочете одну узгоджену історію.

Затримка та надійність: чому SRE звертають увагу на «просто редирект»

Кожен хоп — ще один запит, який може впасти; ще один TLS-рукопотиск; ще один пошук в кеші; ще одне місце, де некоректний заголовок
може все зламати. Помножте це на швидкість краулінгу Googlebot і ваш власний трафік — і отримаєте реальну вартість.

Цитата, яку варто прикріпити до дашборда: Надія — не стратегія. — Gene Kranz.
Редиректи, які роблять ставку на те, що пошукові системи «розберуться», — повільний інцидент.

Поведіка кешу, яку не варто ігнорувати

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

Швидкий план діагностики

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

1) Підтвердіть фінальну ціль і кількість хопів

• Візьміть вибірку проблемних URL зі звіту GSC.
• Прослідкуйте редиректи і зафіксуйте: кількість хопів, коди стану, фінальний URL, фінальний статус.
• Якщо кількість хопів > 1 — у вас вже є конкретна робота.

2) Перевірте, чи цільовий URL індексується

• Фінальний статус має бути 200.
• Немає заголовка або мета-тега «noindex».
• Не заблокований robots.txt.
• Canonical вказує на себе (або на чітко визначений канонічний URL).

3) Перевірте, чи ваш власний сайт не саботує вас

• Внутрішні посилання повинні вказувати на фінальні цілі, а не на редиректні URL.
• Карта сайту має містити канонічні URL, а не тих, що редиректять.
• Hreflang (якщо використовується) має посилатися на канонічні цілі.

4) Подивіться логи сервера щодо поведінки Googlebot

• Чи Googlebot повторно звертається до редиректних URL? Це свідчить, що джерела дискавері все ще вказують на них.
• Чи Googlebot зазнає помилок на цілі (timeout-и, 5xx, блокування)? Це питання надійності, а не «SEO».

5) Якщо це міграція: порівняйте старе й нове покриття

• Старі URL мають бути «Сторінка з переадресацією». Нові URL мають індексуватися.
• Якщо нові URL не індексуються, швидше за все це: noindex, блокування robots, слабкі внутрішні посилання або конфлікти canonical.

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

Це ті перевірки, які я реально виконую. Кожне завдання включає: команду, що означає типовий вивід, і яке рішення прийняти далі.
Замініть прикладні домени і шляхи на свої. Команди припускають, що ви можете дістатися до сайту з shell.

Завдання 1: Прослідкуйте редиректи і порахуйте хопи

cr0x@server:~$ curl -sSIL -o /dev/null -w "final=%{url_effective} code=%{http_code} redirects=%{num_redirects}\n" http://example.com/Old-Path
final=https://www.example.com/new-path/ code=200 redirects=2

Значення: Відбулося два редиректи. Фінальний статус 200.
Рішення: Якщо redirects > 1, намагайтеся звести правила так, щоб перша відповідь вказувала безпосередньо на фінальний URL.

Завдання 2: Друк повного ланцюга редиректів (подивіться кожен Location)

cr0x@server:~$ curl -sSIL http://example.com/Old-Path | sed -n '1,120p'
HTTP/1.1 301 Moved Permanently
Location: https://example.com/Old-Path
HTTP/2 301
location: https://www.example.com/new-path/
HTTP/2 200
content-type: text/html; charset=UTF-8

Значення: HTTP→HTTPS, потім нормалізація хоста/шляху.
Рішення: Змініть перший редирект так, щоб він вказував одразу на фінальний хост/шлях, а не на проміжний.

Завдання 3: Виявлення циклів редиректів

cr0x@server:~$ curl -sSIL --max-redirs 10 https://www.example.com/loop-test/ | tail -n +1
curl: (47) Maximum (10) redirects followed

Значення: Цикл або надмірний ланцюг.
Рішення: Трактувати як інцидент: ідентифікуйте набір правил (CDN, load balancer, origin), що створює цикл, і виправте його перш ніж думати про індексацію.

Завдання 4: Перевірити rel=canonical на цілі

cr0x@server:~$ curl -sS https://www.example.com/new-path/ | grep -i -m1 'rel="canonical"'
<link rel="canonical" href="https://www.example.com/new-path/" />

Значення: Canonical вказує на себе. Добре.
Рішення: Якщо canonical вказує не туди, виправте шаблони чи заголовки; інакше Google може ігнорувати ваш намір з редиректом.

Завдання 5: Перевірити на наявність noindex в мета-тезі на цілі

cr0x@server:~$ curl -sS https://www.example.com/new-path/ | grep -i -m1 'noindex'

Значення: Відсутність виводу означає, що мета-тег «noindex» не знайдено серед перших матчів.
Рішення: Якщо ви бачите noindex, зупиніться. Саме це перешкоджає індексації. Виправте конфіг релізу, прапорці CMS або витік середовища зі staging.

Завдання 6: Перевірити заголовок X-Robots-Tag на наявність noindex

cr0x@server:~$ curl -sSIL https://www.example.com/new-path/ | grep -i '^x-robots-tag'
X-Robots-Tag: index, follow

Значення: Заголовки дозволяють індексацію.
Рішення: Якщо бачите «noindex», виправте його у вихідному коді (app, правила CDN або security middleware). Заголовки переважують інші наміри.

Завдання 7: Підтвердити, що robots.txt не блокує ціль

cr0x@server:~$ curl -sS https://www.example.com/robots.txt | sed -n '1,120p'
User-agent: *
Disallow: /private/

Значення: Показано базовий robots.txt.
Рішення: Якщо шлях цілі заборонено, Google може бачити редирект, але не сканувати контент. Оновіть robots.txt і перевірте повторно в GSC.

Завдання 8: Перевірити, чи карта сайту містить редиректні URL

cr0x@server:~$ curl -sS https://www.example.com/sitemap.xml | grep -n 'http://example.com' | head
42:  <loc>http://example.com/old-path</loc>

Значення: Карта сайту містить неканонічні URL (HTTP-хост).
Рішення: Перегенеруйте карти сайту, щоб у них були лише фінальні канонічні URL. Це недорога та ефективна очистка.

Завдання 9: Знайти внутрішні посилання, що все ще вказують на редиректні URL

cr0x@server:~$ curl -sS https://www.example.com/ | grep -oE 'href="http://example.com[^"]+"' | head
href="http://example.com/old-path"

Значення: Головна сторінка все ще посилається на старий HTTP-URL.
Рішення: Виправте генерацію внутрішніх посилань (шаблони, поля CMS). Внутрішні посилання — це ваш власний внесок краул-бюджету у фонд редиректів.

Завдання 10: Перевірити тип редиректу (301 vs 302) на краю

cr0x@server:~$ curl -sSIL https://example.com/old-path | head -n 5
HTTP/2 302
location: https://www.example.com/new-path/

Значення: Встановлено тимчасовий редирект.
Рішення: Якщо переміщення постійне — змініть на 301/308. Якщо це дійсно тимчасово (обслуговування, A/B), переконайтеся, що це обмежено у часі і моніториться.

Завдання 11: Переконатися, що ціль стабільно повертає 200 (не іноді 403/500)

cr0x@server:~$ for i in {1..5}; do curl -sS -o /dev/null -w "%{http_code} %{time_total}\n" https://www.example.com/new-path/; done
200 0.142
200 0.151
200 0.139
500 0.312
200 0.145

Значення: Періодично 500. Це баг на надійності.
Рішення: Не сперечайтеся зі звітом GSC, поки origin не стабілізовано. Виправте upstream-помилки, потім попросіть повторну індексацію.

Завдання 12: Перевірити правила Nginx на подвійну нормалізацію

cr0x@server:~$ sudo nginx -T 2>/dev/null | grep -nE 'return 301|rewrite .* permanent' | head -n 20
123:    return 301 https://$host$request_uri;
287:    rewrite ^/Old-Path$ /new-path/ permanent;

Значення: Кілька директив редиректу можуть складатися (протокол + шлях).
Рішення: Об’єднайте в один канонічний редирект де можливо, або забезпечте порядок, який запобігає мультихопам.

Завдання 13: Перевірити правила Apache на неочікувані матчі

cr0x@server:~$ sudo apachectl -S 2>/dev/null | sed -n '1,80p'
VirtualHost configuration:
*:443                  is a NameVirtualHost
         default server www.example.com (/etc/apache2/sites-enabled/000-default.conf:1)

Значення: Підтверджує, який vhost за замовчуванням; неправильний дефолтний vhost може створювати небажані хост-редиректи.
Рішення: Переконайтеся, що канонічний хост налаштований правильно і що неканонічні хости явно редиректять в один хоп.

Завдання 14: Використати access-логи, щоб побачити, чи Googlebot застряг на редиректних URL

cr0x@server:~$ sudo awk '$9 ~ /^30/ && $0 ~ /Googlebot/ {print $4,$7,$9,$11}' /var/log/nginx/access.log | head
[27/Dec/2025:09:12:44 /old-path 301 "-" 
[27/Dec/2025:09:12:45 /old-path 301 "-" 

Значення: Googlebot повторно запитує редиректний URL. Джерела дискавері все ще вказують на них.
Рішення: Виправте внутрішні посилання та карти сайту; розгляньте оновлення зовнішніх посилань, якщо контролюєте їх (профілі, власні властивості).

Завдання 15: Перевірити непослідовну поведінку за User-Agent (небезпечні «розумні» редиректи)

cr0x@server:~$ curl -sSIL -A "Mozilla/5.0" https://www.example.com/ | head -n 5
HTTP/2 200
content-type: text/html; charset=UTF-8

cr0x@server:~$ curl -sSIL -A "Googlebot/2.1" https://www.example.com/ | head -n 5
HTTP/2 302
location: https://www.example.com/bot-landing/

Значення: Різні відповіді для Googlebot. Це червоний прапор, якщо немає дуже виправданої причини.
Рішення: Видаліть логіку редиректів на основі UA; це може виглядати як клоакинг і створює нестабільність індексації.

Завдання 16: Перевірити, чи HSTS не винна у вашій плутанині з редиректами

cr0x@server:~$ curl -sSIL https://www.example.com/ | grep -i '^strict-transport-security'
Strict-Transport-Security: max-age=31536000; includeSubDomains

Значення: HSTS увімкнено, отже браузери після першого контакту примусово підніматимуть HTTPS.
Рішення: Не «дебажте» редиректи лише в браузері; використовуйте curl у чистому середовищі. HSTS може приховувати HTTP-поведіку і змушувати вас ганятися за примарами.

Три корпоративні міні-історії з поля бою редиректів

Інцидент: неправильне припущення («Google сам це розбереться»)

Середня SaaS-компанія мігрувала з легасі CMS на сучасний фреймворк. План виглядав чистим:
старі URL редиректитимуться на нові, а новий сайт буде швидшим. Інженери реалізували редиректи на рівні додатку,
і QA перевірив це в браузері. Всі розійшлися додому.

На першому тижні Search Console почав заповнюватися «Сторінка з переадресацією», а покази впали для цінних сторінок.
SEO-команда занепокоїлася і вимагала «прибрати редиректи». Це було неправильним вогнегасником.
SRE на виклику зробив непрестижну річ: витягнув логи сервера для Googlebot і відтворив запити через curl.

Припущення, яке зламало їх: «Якщо в браузері працює — Googlebot бачить те ж саме.»
Їхній CDN мав правила пом’якшення бот-трафіку, які поводилися інакше для невідомих user-agent-ів під час піків трафіку.
Коли origin працював повільно, edge повертав тимчасовий редирект на загальну сторінку «будь ласка, спробуйте пізніше» — для людей це прийнятно,
але для індексації — катастрофа. Googlebot ішов за редиректом і знаходив тонкий контент.

Виправлення не було «SEO-магією». Це була продукційна гігієна:
вони виняткували перевірені боти з правила пом’якшення, покращили кешування для нових сторінок і припинили редиректити на загальний fallback.
Після цього «Сторінка з переадресацією» залишилася для старих URL (очікувано), а нові URL стабілізувалися і знову індексувалися.

Оптимізація, що призвела до відкату: згортання параметрів через редиректи

У e‑commerce організації була проблема з параметрами: нескінченні URL типу ?color=blue&sort=popular&ref=ads.
Статистика краулінгу виглядала погано, і хтось запропонував «просте» рішення: редиректити будь-який URL з параметрами на сторінку категорії без параметрів.
Одне правило переписування, щоб правити всім.

Це швидко запустилося. Надто швидко. Конверсія впала. Органічний трафік для довгохвостих варіантів категорій обрушився.
Search Console показував багато «Сторінка з переадресацією», але справжнє пошкодження було в тому, що вони
редиректували реальні сторінки з пошуковим наміром. Деякі комбінації параметрів відображали значимі відфільтровані сторінки,
які користувачі шукали (і які мали унікальний товар).

Гірше того, правило редиректу створювало ланцюги: URL з параметром → чиста категорія → гео-редирект → локалізована категорія.
Googlebot витрачав більше часу на стрибки, ніж на сканування. Зросла затримка. Сайт виглядав «нестабільним».

Відкат був болючим, але необхідним. Вони замінили грубе правило на політику:
відкидати лише відомі трекінгові параметри (utm/ref), залишати функціональні фільтри індексованими там, де контент це виправдовує,
і використовувати rel=canonical для дублів. Раптом «Сторінка з переадресацією» обмежилася лише сміттєвими URL, а не прибутковими.

Сумна, але правильна практика: гігієна sitemap та внутрішніх посилань врятувала ситуацію

Платформа для публікацій провела консolidування доменів: чотири субдомени в один канонічний хост.
Вони реалізували 301-редиректи і чекали турбулентності. Родзинка: вони поставилися до цього як до операційної зміни, а не до SEO-бажання.

Перед запуском вони згенерували мапу відповідностей (старий → новий), прогнали автоматичні тести редиректів і оновили внутрішні посилання в шаблонах.
Не лише навігацію. Футер, блоки «пов’язані статті», RSS-фіди — усе. Вони також перегенерували карти сайту, щоб включити лише канонічні URL,
і опублікували їх разом із деплоєм.

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

Урок не був гламурним: нудна робота запобігає холодній аварії.
Редиректи — це міст, але потрібно ще перемістити трафік, посилання і сигнали на новий бік.

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

1) Симптом: сплеск «Сторінка з переадресацією» після деплою

Коренева причина: Нове правило ввело мультихоп-редиректи або цикли (часто слеш + локаль + нормалізація хоста).
Виправлення: Проганяйте тести ланцюгів редиректів на вибірці URL; зводьте до одного хопа; додавайте регресійні тести в CI для канонічних URL.

2) Симптом: Старі URL показують «Сторінка з переадресацією», але нові — «Crawled — currently not indexed»

Коренева причина: Цільові сторінки низької якості/тонкі, заблоковані, повільні або мають конфлікти canonical/noindex.
Виправлення: Переконайтеся, що ціль повертає 200, індексується, має self-canonical і суттєвий контент. Виправте продуктивність і шаблони.

3) Симптом: GSC показує «Сторінка з переадресацією» для URL, які мають бути фінальними

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

4) Симптом: Редиректи працюють у браузері, але не для Googlebot

Коренева причина: Умовна логіка на основі user-agent, cookies, гео або бот-мітігація на рівні CDN/WAF.
Виправлення: Тестуйте з UA Googlebot, порівнюйте заголовки, видаліть умовні редиректи і забезпечте однакову нормалізацію.

5) Симптом: Сторінки зникають після «очищення» параметрів

Коренева причина: Правило редиректу згорнуло значимі URL у загальні сторінки, втративши довгохвосту релевантність.
Виправлення: Редиректьте/видаляйте лише трекінгові параметри; обробляйте функціональні фільтри за допомогою canonical або noindex, або дозволяйте індексацію вибірково.

6) Симптом: Редиректні URL залишаються в індексі місяцями

Коренева причина: Тимчасові редиректи (302/307) використовуються для постійних переміщень або непослідовні сигнали canonical.
Виправлення: Використовуйте 301/308 для постійних переміщень; переконайтеся, що ціль канонічна; оновіть внутрішні посилання і карти сайту на ціль.

7) Симптом: Редиректи викликають періодичні 5xx та падіння краулінгу

Коренева причина: Обробка редиректів на рівні додатку викликає дорогі обчислення; overload origin; промахи кеша; TLS-рукопотиск на кожному хопі.
Виправлення: Перенесіть редиректи на edge/web-сервер де можливо; кешуйте редиректи; зменште кількість хопів; моніторьте p95 latency на кінцях редиректів.

Жарт №2: Найшвидший спосіб знайти невідоме правило редиректу — видалити його і почекати, поки хтось важливий помітить.

Чеклисти / покроковий план

Чеклист A: Ви бачите «Сторінка з переадресацією» і хочете зрозуміти, чи варто хвилюватися

1. Візьміть 20 URL зі звіту (мікс важливих і випадкових).
2. Запустіть curl з лічильником редиректів. Якщо багато випадків >1 хопа — хвилюйтеся.
3. Підтвердіть, що фінальні URL повертають 200 і індексуються (noindex/robots/canonical).
4. Перевірте, чи фінальні URL індексуються і отримують покази.
5. Якщо фінальні URL здорові — розглядайте «Сторінка з переадресацією» як інформаційний сигнал.

Чеклист B: Очищення редиректів, яке не викличе новий інцидент

1. Зробіть інвентар поточних правил редиректів у всіх шарах: CDN/WAF, load balancer, web server, app.
2. Визначте політику канонічних URL: протокол, хост, слеш, нижній регістр, патерни локалі.
3. Забезпечте одношаговий шлях до канонічного URL де можливо.
4. Оновіть внутрішні посилання і шаблони, щоб використовували канонічні URL.
5. Перегенеруйте карти сайту, щоб містили лише канонічні URL.
6. Деплойте з моніторингом: частота редиректів, 4xx/5xx на цілі, латентність.
7. Після деплою робіть лог-семпл Googlebot і перевіряйте, що він дістається до сторінок з 200.

Чеклист C: План для міграцій (доменів або структури URL)

1. Створіть файл мапінгу (старий → новий) для всіх високовартісних URL; не покладайтеся лише на regex.
2. Реалізуйте 301/308 редиректи і протестуйте на цикли та ланцюги.
3. Збережіть паритет контенту: тайтли, заголовки, структуровані дані де доречно.
4. Переконайтеся, що нові сторінки мають self-referencing canonical.
5. Переключіть карти сайту на нові URL під час запуску.
6. Моніторьте індексацію: нові сторінки мають зростати, в той час як старі стають «Сторінкою з переадресацією».
7. Тримайте редиректи довго (місяці — роки в залежності від екосистеми), а не два тижні тому, що хтось хоче «чисту конфігурацію».

Цікаві факти та історичний контекст

• Факт 1: HTTP 301 і 302 датуються ранніми специфікаціями HTTP; веб пересував сторінки ще майже з початку існування.
• Факт 2: 307 і 308 були введені пізніше для уточнення збереження методів; вони важливіші для API, але з’являються в сучасних стеках.
• Факт 3: Пошукові системи історично трактували 302 як «не передавати сигнали», але з часом ставлення стало гнучкішим, якщо редирект тримається довго.
• Факт 4: HSTS може зробити HTTP→HTTPS редиректи невидимими при тестуванні в браузері, бо браузер піднімає з’єднання до HTTPS ще до запиту.
• Факт 5: CDN часто реалізують редиректи на edge; це швидше, але може створювати приховані взаємодії з редиректами origin.
• Факт 6: Раніше канонізацію часто робили через редиректи, бо rel=canonical спочатку не існував; згодом canonical став стандартним інструментом.
• Факт 7: Ланцюги редиректів стали частішими, коли стек наростав: CMS + фреймворк + CDN + WAF + load balancer — кожен «допомагає» нормалізувати.
• Факт 8: Боти не поводяться як користувачі: вони можуть сканувати в масштабі, повторювати запити агресивно і підсилювати дрібні неефективності у великі інфраструктурні витрати.

FAQ

1) Чи варто намагатися позбутися «Сторінки з переадресацією» у Search Console?

Не заради самого факту. Ваша мета — щоб цільові URL індексувалися і показували результати. Те, що перенаправлені URL «не індексуються», — очікувано.
Очищайте тільки коли поведінка редиректів неефективна або непослідовна.

2) Чи є «Сторінка з переадресацією» покаранням?

Ні. Це категоризація. Покарання — це те, що ви робите далі: зберігати ланцюги, редиректити на тонкі сторінки або надсилати суперечливі сигнали canonical.

3) Скільки редиректів — занадто багато?

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

4) Чи 302 шкодить SEO у порівнянні з 301?

Іноді. Якщо переміщення постійне — використовуйте 301 або 308. Довгоіснуючий 302 може спрацювати, але він передає невизначеність і може затримати консолідацію.
Не будьте впевнені, що Google «рано чи пізно» трактуватиме це як 301.

5) Чому моя карта сайту показує URL, які GSC визначає як «Сторінка з переадресацією»?

Тому що генератор карти сайтів використовує неправильну базу (HTTP vs HTTPS, неправильний хост) або виводить застарілі шляхи.
Виправте генератор, щоб карти сайту містили лише канонічні, фінальні URL. Це один із найпростіших виграшів у цій темі.

6) Що робити, якщо мені потрібні обидві версії доступними (наприклад, відфільтровані сторінки), але я не хочу їх індексувати?

Не редиректте їх, якщо вони функціонально потрібні. Залиште доступними, а потім свідомо використовуйте rel=canonical або правила noindex.
Редиректи призначені для «цого не має існувати як лендингову сторінку».

7) Чи може «Сторінка з переадресацією» бути спричинена JavaScript-редиректами?

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

8) Скільки часу зберігати редиректи після міграції?

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

9) Чому редиректні URL все ще багато сканується?

Google продовжує знаходити їх через внутрішні посилання, карти сайту або зовнішні посилання. Внутрішні джерела під вашим контролем; виправляйте їх першими.
Зовнішні посилання потребують часу, щоб зникнути. Мета — припинити живити проблему.

10) Чи може «Сторінка з переадресацією» приховувати проблеми з безпекою або WAF?

Абсолютно. WAF іноді редиректить підозрілий трафік, трафік з лімітом або певні user-agent-и. Якщо Googlebot отримує таке ставлення,
ви отримаєте нестабільність індексації. Підтвердіть поведінку за допомогою тестів з UA і логів edge.

Висновок: практичні наступні кроки

«Сторінка з переадресацією» не ваш ворог. Це ліхтарик. Інколи він світить на URL, які ви навмисно вивели з обігу. Чудово.
Інколи він показує борг редиректів: ланцюги, цикли, суперечливі canonical і «тимчасові» редиректи, що стали постійними із лінощів.

Наступні кроки, що швидко окуповуються:

1. Візьміть 20–50 URL зі звіту і виміряйте кількість хопів через curl.
2. Підтвердіть, що цілі індексуються (200, без noindex, не заблоковані, self-canonical).
3. Виправте внутрішні посилання і карти сайту, щоб вказували на фінальні канонічні URL.
4. Зведіть редиректи до одного хопа і стандартизуйтесь на 301/308 для постійних переміщень.
5. Спостерігайте логи: Googlebot має витрачати менше часу на редиректи і більше — на справжні сторінки.

Якщо ви поставитесь до редиректів як до продакшн-інфраструктури — спостережуваної, придатної для тестування і нудної —
ви отримаєте кращий SEO-результат: Google витрачатиме свій час на ваш контент, а не на вашу «водопровідну мережу».