Як налаштувати 301-редиректи під час міграції сайту

Як покроково налаштувати 301-редиректи під час міграції вебсайту

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

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

1. Визначте тип міграції та цілі редиректів

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

Наприклад, ребрендинг із oldsite.com на newsite.com може потребувати перенаправлення майже кожної живої сторінки, тоді як перехід на іншу CMS може залишити ті самі URL і змінити лише спосіб відображення сторінок. Це не одна й та сама задача. Якщо сприймати їх як одну, план редиректів дуже швидко перетвориться на хаос.

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

Запишіть правила міграції простою мовою. Коротко. «Старі сторінки категорій переходять у нові категорії». «Сторінки завершених промоакцій не потребують редиректів». «Тонкі архівні сторінки можна прибрати». Такі рішення економлять години пізніше, бо 301-редиректи мають відповідати реальній структурі сайту, а не припущенням, зробленим у тиждень запуску.

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

2. Складіть перелік лише тих URL, яким потрібне перенаправлення

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

Збирайте URL із кількох джерел. Використайте поточну sitemap, аналітику, серверні логи та будь-які старі crawl-export’и, які вже є. URL без відвідувань і без посилань може не заслуговувати уваги. А от URL із зовнішніми посиланнями — так. Саме він може залишатися важливим ще пів року після переїзду.

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

Розбийте список на прості групи: сторінки, папки, файли та особливі випадки. Тут допомагають цифри. Список із 12 URL можна обробити одним способом. Список із 1 200 URL потребує шаблонних правил, а не ручного створення окремого правила для кожного рядка. Якщо пропустити цей крок, карту редиректів буде важко перевіряти, тож краще одразу підготувати карту редиректів для сайту.

Тримайте список зосередженим на старому сайті, а не на новому. Старий сайт — це джерело правди про те, що існує сьогодні. Новий — це ціль. Змішування обох занадто рано ускладнює пошук відсутніх сторінок і випадкових дублювань.

3. Зіставте старі URL із правильними новими аналогами

Тепер створіть карту відповідностей. Чиста схема «один до одного» — це найпростіший варіант: один старий URL веде на один новий URL, і зв’язок очевидний. Блог-пост про ціноутворення переходить на нову статтю про ціни. Сторінка послуги про аудит — на нову сторінку аудиту. Усе просто.

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

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

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

Додавайте примітки біля складних URL. Коротко пояснюйте об’єднані сторінки, розділені сторінки та видалений контент. Ці примітки важливі, коли хтось переглядає план за два дні до запуску і запитує, чому сторінка A веде на сторінку B. Відповідь має бути видна в карті, а не захована в чаті.

4. Оберіть правильний спосіб реалізації 301-редиректів

Де саме розміщувати 301-редиректи, залежить від того, де розгорнуто мігрований сайт. На одних стеків найкращим варіантом буде конфігурація сервера. На інших — CMS, CDN або шар маршрутизації застосунку. Оберіть місце, яке надійно віддаватиме редиректи без зайвих складнощів.

Якщо сайт працює на традиційному вебсервері, правила на рівні сервера можуть бути найпрямішим варіантом. Якщо сайтом керують у CMS із вбудованими інструментами редиректів, цього може бути достатньо для невеликих міграцій. Якщо трафік проходить через CDN, edge-правила можуть допомогти, особливо коли потрібні швидкі оновлення для багатьох URL.

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

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

Для більших команд задокументуйте метод в одному місці. Поруч із картою редиректів вкажіть відповідального, платформу та шлях розгортання. Так людина, яка змінює правила, знатиме, чи вони належать до Nginx, Apache, таблиці CMS, панелі CDN або коду застосунку.

5. Напишіть і впорядкуйте правила 301

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

Стережіться циклів. Цикл виникає, коли сторінка A редиректить на сторінку B, а сторінка B повертає назад на сторінку A, або коли дві сторінки без кінця пересилають одна одну по колу. Для роботів і користувачів це тупик. А ще це марнує crawl budget — одну з тих нудних фраз, яка стає дуже цікавою, коли нічого не індексується нормально.

Уникайте й ланцюжків. Ланцюжок означає, що один редирект веде на інший, а потім ще на один. Сторінка A → B → C. Це працює погано й уповільнює все. Якщо можна спрямувати A одразу на C, так і зробіть.

Використовуйте однакові назви й групування всередині файлу або інтерфейсу. Групуйте правила за розділами: старі шляхи блогу, старі шляхи сервісів, старі шляхи товарів, видалені ресурси. Акуратний список легше тестувати. Його також легше передати іншому розробнику о 18:00 у день запуску без довгих пояснень.

Тримайте в полі зору винятки. Широке правило на кшталт «перенаправляти все з /blog/ на /insights/» може виглядати ефективним, але воно здатне зламати теги, сторінки авторів або старі медіапосилання. Якщо для шаблону є винятки, винесіть їх окремо до релізу. Це зекономить час на виправленнях пізніше.

6. Перевірте поведінку редиректів до запуску та після нього

Тестування має відбутися до запуску, а не після першого повідомлення користувача про зламану сторінку. Перевірте вибірку окремих URL із карти, потім протестуйте групові шаблони, а потім — нестандартні випадки, такі як кінцеві слеші, великі літери в шляху, query string і файли з розширеннями. Редирект, який працює для одного URL, може не спрацювати для його близького «родича».

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

Перевіряйте не лише очевидні шляхи. Старі PDF-файли, URL зображень і вкладені папки часто випадають із поля зору. Один пропущений шлях до файлу може створити ланцюг 404-сторінок, який продовжить зростати після запуску, особливо якщо ці ресурси були вбудовані в сторінки або колись поширювалися в соцмережах.

Проводьте перевірку у два етапи: один раз до запуску в staging-середовищі, і ще раз одразу після запуску на живому сайті. Другий раунд виявляє проблеми розгортання, несподіванки кешування та будь-яке правило, яке поводиться інакше, щойно в гру входить реальний хост. Саме на цьому етапі багато команд знаходять той єдиний URL, про який забули.

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

7. Оновіть супровідні сигнали після міграції

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

Оновіть XML-карти сайту з новими URL. Надішліть їх там, де це потрібно. Приберіть зі live sitemap старі URL, якщо вони тепер редиректять, і залиште там лише цільові адреси. Sitemap, заповнений застарілими адресами, надсилає суперечливі сигнали, навіть якщо редиректи працюють ідеально.

Перевірте canonical-теги. Вони мають вказувати на нову сторінку, а не на стару. Це невеликий рядок коду, але він важливий. Canonical, який досі посилається на старий URL, може розмити сигнал для пошукових систем, особливо під час першого циклу сканування після запуску.

Оновіть зовнішні посилання, де це можливо. Це можуть бути сайти партнерів, профілі в соцмережах, шаблони email або каталог, який ви контролюєте. Ви не встигнете виправити все, і це нормально. Мета — зменшити зайвий трафік через шар редиректів, а не виправити весь інтернет.

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

8. Відстежуйте проблеми зі скануванням і трафіком у перше вікно після запуску

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

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

Швидко закривайте прогалини. Якщо якийсь URL пропустили, додайте його. Якщо шаблон надто широкий, звузьте його. Якщо з’явився ланцюжок, скоротіть його. Карта редиректів не завершується на запуску; у перші дні після переїзду це живий документ.

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

Тримайте команду в курсі конкретними прикладами, а не розмитими статус-нотатками. «Чотири URL товарів досі повертають 404» — це корисно. «Деякі проблеми залишаються» — ні. Якщо маркетингова кампанія, згадка в пресі або сторінка з великим числом посилань досі веде на стару адресу, спершу виправте саме цей шлях. Один пропущений URL може мати більші наслідки, ніж десяток сторінок із низькою цінністю.

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