Переїзд сайту без втрати пошукових переходів: карта URL і редиректи

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

Звідки взяти старі адреси

Почніть із sitemap старого сайту та експорту сторінок зі старої бази або CMS. Ці джерела показують задуману структуру, але не охоплюють усіх адрес, які відвідують люди. У Search Console перегляньте сторінки, що отримували переходи й покази, а також звіт про індексацію. У серверних логах шукайте запити до старих шляхів, особливо помилки після попередніх змін сайту.

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

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

Як зіставляти сторінки

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

У кейсі ЖНИВ-АГРО під час переходу з OpenCart старі адреси зіставляли з новим каталогом і закривали постійними перенаправленнями. Подібна робота потрібна й для сайту послуг: у проєкті «Інстинкт Сонця» окремо перенесли старі точки входу до матеріалів і розділів. Це показує, чому таблицю відповідностей не можна збирати лише за новим меню.

Який код повертає сервер

Для остаточного переїзду сторінки використовуйте 301: він повідомляє браузеру й пошуковій системі, що адресу змінено постійно. 302 підходить для тимчасового перенаправлення, коли старий URL планують повернути. Перед запуском перевірте фактичний HTTP-код, а не лише те, що браузер зрештою відкрив потрібну сторінку.

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

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

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

1. До запуску проганяйте карту автоматично: перевірте код старої адреси, місце переходу, кінцевий код і відсутність циклу. Окремо перегляньте найважливіші сторінки вручну.
2. Після перемикання оновіть внутрішні посилання, canonical, sitemap і мовні зв'язки. Вони мають вказувати на нові адреси, а не постійно проходити через редирект.
3. Надішліть нову карту сайту в Search Console. Перевіряйте звіти про індексацію та серверні помилки, бо старі посилання можуть проявитися вже після відкриття.
4. Для нових помилок зі старих адрес доповнюйте карту відповідностей. Фіксуйте виправлення в одному місці, щоб наступне оновлення конфігурації їх не стерло.

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