SEO-кейс: падіння трафіку після редизайну через помилки 301

SEO-кейс №3: після редизайну сайт втратив 52% трафіку. Чому 301-редиректи не врятували переїзд?

Рубрика: SEO практика
Ніша: оренда будівельної техніки
Тип кейсу: технічне SEO, міграція сайту, 301-редиректи, індексація

У п'ятницю ввечері компанія запустила новий сайт. Дизайн став сучаснішим, сторінки відкривалися швидше, форми працювали, а розробники налаштували 301-редиректи зі старих адрес. На перший погляд — ідеальна міграція.

Через три тижні SEO-фахівець відкрив Google Search Console і побачив стрімке падіння кліків. У відділі продажів почали рідше надходити запити на оренду мініекскаваторів та генераторів. Найнеприємніше було те, що всі старі URL начебто перенаправлялися, а нові сторінки відкривалися з кодом 200.

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

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

Уявімо компанію, яка здає будівельну техніку в оренду в Дніпрі та області. У каталозі — мініекскаватори, генератори, компресори, віброплити, підйомники й інше обладнання. Клієнти шукають не абстрактну «техніку», а конкретну машину, потужність, умови доставки та вартість оренди.

До оновлення сайт мав:

42 сторінки типів техніки та окремих послуг;

186 карток моделей обладнання;

28 корисних статей, інструкцій і відповідей на питання щодо вибору техніки;

сторінки умов доставки, оплати, застави та контактів;

налаштовані Google Search Console, GA4 та облік кваліфікованих звернень у CRM.

За типовий 28-денний період до змін Google Search приносив 2 860 кліків, а CRM фіксувала 72 кваліфіковані звернення з органічного каналу. Кваліфікованим вважали запит на техніку, яка є в асортименті, у доступній географії й із реальним наміром оренди.

Найцінніші посадкові сторінки отримували переходи за вузькими запитами: «оренда мініекскаватора Дніпро», «генератор 10 кВт оренда», «віброплита в оренду з доставкою». Саме їх потрібно було зберегти під час переїзду.

Чому компанія вирішила змінити сайт

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

Змінилася й схема URL:

Було: /orenda-mini-ekskavatora-dnipro/
Стало: /orenda/mini-ekskavatory/

Було: /arenda-generatora-10-kvt/
Стало: /orenda/heneratory-10-kvt/

Сам по собі перехід на нові адреси не є помилкою. Проблеми виникли на етапі, де треба було пов'язати кожну стару корисну сторінку з відповідним новим документом.

Перше помилкове рішення: «Поставимо 301 на каталог — і все збережеться»

На момент запуску детальної таблиці зіставлення URL не підготували. Розробник створив загальні правила: якщо старий шлях не знаходить точного збігу в новій структурі, перенаправляти користувача на /catalog/.

На перевірці це виглядало непогано: старий URL відповідав 301, а кінцева адреса — 200 OK. Але 81 адреса, серед них сторінки з цільовим комерційним трафіком, вела до загального каталогу, де були десятки різних видів техніки.

Уявімо клієнта, який шукає «оренда генератора 10 кВт» і натискає результат Google. Замість сторінки генераторів потрібної потужності він потрапляє до каталогу, де бачить екскаватори, компресори та підйомники. Технічно сторінка відкрилася. Але пошуковий намір не був задоволений.

Google прямо рекомендує не перенаправляти багато старих URL на одну нерелевантну сторінку, наприклад головну. Такі перенаправлення можуть розглядатися як soft 404. Водночас доречні перенаправлення на справді об'єднаний матеріал допустимі. Тому правило «301 завжди рятує SEO» — небезпечне спрощення.

Друга помилка: прихований noindex у шаблоні нового сайту

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

<meta name="robots" content="noindex, follow">

Після публікації її прибрали не всюди. У нашому сценарії 26 нових сторінок техніки продовжували віддавати noindex, хоча відповідали 200 OK і мали правильний контент.

Це окремий від редиректів збій. Якщо Googlebot може просканувати сторінку й бачить noindex, Google не повинен залишати її в результатах пошуку. У нашій моделі частина важливих сторінок втратила можливість нормально брати участь у видачі саме через цю директиву.

Додаткова небезпека — спроба закрити такі URL ще й у robots.txt. Тоді робот не зможе прочитати noindex, тож така комбінація не є коректним універсальним способом вилучення сторінки з індексу. Для продакшену потрібно окремо перевіряти обидва механізми.

Третя помилка: суперечливі сигнали canonical і застарілі посилання

В окремих шаблонах нової CMS залишився rel="canonical", який вказував не на новий URL, а на стару адресу, що вже повертала 301. Іншими словами, сайт одночасно просив Google перейти на нову сторінку й натякав, що основною є стара.

У XML sitemap теж залишилася частина старих URL. А блоки «Популярна техніка» на деяких сторінках продовжували посилатися на адреси, які перенаправлялися, замість того щоб вести відразу на нові сторінки.

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

Що сталося з трафіком

Порівняймо два модельні 28-денні періоди: стабільний період до запуску та повний період після переїзду.

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

У цьому сценарії насторожило не лише падіння кліків, а й конкретні перевірені факти: важливі старі URL вели на нерелевантні сторінки, частина нових мала noindex, а canonical і внутрішні посилання вказували на неактуальні адреси.

Як проводили аудит: не гадати про алгоритми, а перевіряти ланцюжок URL

1. Зібрали перелік найважливіших старих посадкових сторінок

Із Search Console вивантажили сторінки, які приносили основні органічні кліки за 3–6 місяців до запуску. До списку додали URL із зовнішніми посиланнями, конверсіями та ключовими товарами. Дані зіставили зі старим sitemap, краулом і резервною копією структури.

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

2. Для кожної старої адреси перевірили кінцеву сторінку

Найкориснішою стала проста таблиця:

Це приклади умовних URL, а не справжні адреси компанії. Суть правильної міграції — переносити намір і зміст сторінки, а не просто перенаправляти її відвідувача куди завгодно.

3. Перевірили статуси та директиви на нових сторінках

Для пріоритетних URL перевіряли:

HTTP-відповідь старої адреси: 301 або інший обґрунтований статус;

кінцевий URL і кінцевий HTTP-статус;

відсутність зайвих ланцюжків чи циклів редиректів;

robots.txt, meta robots та X-Robots-Tag;

canonical у вихідному та відрендереному HTML;

видимість головного вмісту для Googlebot;

наявність нового URL в актуальному sitemap;

внутрішні посилання на кінцеву канонічну адресу.

Тільки після цього оцінювали, які URL Google уже переобійшов, що він визначає канонічним і які сторінки відсутні в індексі. Звіт Page indexing і URL Inspection допомагали відокремити фактичну помилку від простого очікування переобходу.

План виправлення: чотири хвилі робіт

Хвиля 1. Забрали блокування з потрібних сторінок

Розробники виправили шаблон, який додавав noindex до 26 важливих URL. Перевірили, що сторінки відкриваються для Googlebot, мають коректний статус і більше не містять заборони індексації ані в HTML, ані в HTTP-заголовках.

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

Хвиля 2. Перепризначили 301 за змістом

Для 81 проблемної адреси переглянули цільові сторінки. Там, де нова відповідна категорія або картка реально існувала, поставили прямий серверний 301 саме на неї. Коли зміст старої сторінки перенесли й об'єднали з іншим матеріалом, використовували перенаправлення на цей об'єднаний матеріал.

Якщо послугу припинили й релевантної альтернативи не було, не вигадували редирект на головну. Залишали коректний 404 або 410 та зручну сторінку помилки для користувача.

Хвиля 3. Узгодили всі сигнали про основні URL

На нових сторінках виправили canonical, оновили внутрішні посилання й XML sitemap. В актуальному sitemap залишили кінцеві URL, які компанія хотіла бачити в пошуку, а не адреси-перенаправлення.

Оскільки в нашому сценарії домен не змінювався, а змінювалися тільки шляхи, інструмент Change of Address не був потрібний. Його застосування має сенс для відповідних переїздів між доменами чи субдоменами, а не як універсальна кнопка після будь-якого редизайну.

Хвиля 4. Відновили корисність комерційних сторінок

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

Це важливо: навіть ідеальна таблиця редиректів не врятує ситуацію, якщо нові сторінки набагато слабші або не відповідають тому самому пошуковому наміру.

Модель відновлення: не миттєве повернення до старих показників

Через приблизно три місяці після основних виправлень у навчальному сценарії порівняли ще один 28-денний період:

Від мінімуму кліки зросли на 81,6%, а кваліфіковані звернення — на 69,2%. Але відносно періоду до редизайну кліків усе ще було на 13,6% менше, а звернень — на 8,3% менше.

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

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

Чого не варто робити після втрати трафіку

1. Не поспішайте купувати посилання «для повернення позицій». Якщо критичні сторінки закриті noindex або перенаправляються не туди, посилання не виправлять першопричину.

2. Не перенаправляйте всі старі адреси на головну чи загальний каталог. HTTP 301 сам по собі не робить кінцеву сторінку релевантною.

3. Не змінюйте масово Title, H1 і тексти, поки не зрозуміли, що сталося з URL. Інакше ви змішаєте наслідки міграції з наслідками нової контентної оптимізації.

4. Не закривайте помилкові URL у robots.txt навмання. Спочатку визначте, чи вони повинні перенаправлятися, індексуватися, бути доступними для сканування або справді повертати код помилки.

5. Не називайте будь-яке короткострокове падіння санкцією Google. Після зміни URL коливання можливі й без порушень; діагноз має ґрунтуватися на фактах.

Чекліст перед міграцією: 12 перевірок, що можуть зберегти місяці роботи

Зробіть повний список старих URL. Використайте краул, sitemap, аналітику, звіти про цільові сторінки та дані про зовнішні посилання.

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

Підготуйте таблицю old URL → new URL. Для кожної сторінки знайдіть реального відповідника, а не загальну категорію за замовчуванням.

Визначте долю видалених послуг. Якщо заміни немає, передбачте коректний статус 404 або 410.

Протестуйте редиректи до запуску. Переконайтеся, що вони прямі, постійні й ведуть на релевантні кінцеві сторінки.

Перевірте індексацію шаблонів. Шукайте випадкові noindex, X-Robots-Tag і блокування в robots.txt.

Перевірте canonical. Нові сторінки мають послідовно вказувати на актуальні основні адреси.

Переконайтеся, що вміст доступний для сканування. Особливо якщо нова CMS використовує JavaScript для побудови каталогу.

Оновіть sitemap та внутрішні посилання. Вони повинні вести на нові кінцеві URL.

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

Після запуску відстежуйте групи URL. Аналізуйте статуси, індексацію, кліки, запити та звернення щодня в перші критичні дні, а потім — регулярно.

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

Поширені запитання

Чи передає 301-редирект SEO-сигнали старої сторінки?

Постійний редирект є сильним сигналом того, що контент переїхав на нову адресу. Google зазначає, що сам по собі 301 не спричиняє втрати PageRank. Але це не означає, що будь-яка сторінка збереже старі позиції після перенаправлення на довільний URL. Відповідність змісту й коректність переїзду мають значення.

Чи обов'язково змінювати URL під час редизайну?

Ні. Якщо стара адреса логічна, стабільна й корисна, її часто варто зберегти. Зміна URL додає окреме технічне завдання, а не автоматичну SEO-перевагу.

За скільки часу повернуться позиції після виправлення міграції?

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

Чи треба надсилати всі нові URL на ручну індексацію?

Ні. Варто перевірити критичні сторінки й підтримувати коректний sitemap та внутрішню структуру. Ручний запит на переобхід не є способом миттєво відновити всі позиції.

Висновок

Помилка цього кейсу почалася ще до запуску нового дизайну — в момент, коли команда вирішила, що будь-який 301-редирект кращий за відсутність редиректу.

Насправді для SEO важлива не сама наявність перенаправлення, а те, чи потрапляє людина й пошукова система на відповідний новий документ. Якщо до неправильного зіставлення URL додаються випадкові noindex, застарілі canonical та внутрішні посилання, красивий редизайн може обійтися бізнесу дуже дорого.

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

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

Google Search Central: перенесення сайту зі зміною URL

Google Search Central: перенаправлення та Google Search

Google Search Central: індексація та noindex

Google Search Central: виправлення canonical