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

Міграція сайту без просадки
Міграція сайту без просадки

Саме тому до міграції треба ставитися не як до разового релізу, а як до safety protocol. Спокійно, методично, з контролем на кожному етапі. Google прямо радить готувати новий сайт, тестувати його заздалегідь, робити URL mapping і вже потім запускати перенаправлення. У цій статті розберемо, як зібрати карту 301 у Google Sheets і автоматично перевірити її ще до виходу на бойовий сервер через How to move a site та Redirects and Google Search.

Крок 1. Inventory: зберіть повний список старих URL

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

  • sitemap.xml;
  • Google Search Console;
  • краулер на кшталт Screaming Frog або власний попередній аудит;
  • список сторінок із трафіком;
  • список сторінок із беклінками.

Не можна обмежитися лише sitemap. У ній часто немає старих, технічних або частково живих URL, які все ще мають сигнали. У Search Console теж можуть бути сторінки, які вже не на виду, але ще отримують кліки або покази. Якщо пропустити такі адреси, після релізу вони підуть у 404 або в беззмістовні редиректи на головну.

Що пріоритезувати в першу чергу

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

Крок 2. Зберіть карту редиректів у Google Sheets

Зберіть карту редиректів у Google Sheets
Зберіть карту редиректів у Google Sheets

Найзручніше вести карту в таблиці. Базова структура така:

  • колонка A — Old URL;
  • колонка B — New URL;
  • колонка C — Type;
  • колонка D — Priority;
  • колонка E — Status check;
  • колонка F — Notes.

Для більшості сценаріїв у колонці Type має бути саме 301, якщо переїзд постійний. Тут важливо не плутати статус 301 vs 302:

  • 301 — постійний переїзд;
  • 302 — тимчасовий редирект.

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

Крок 3. Автоматизуйте співставлення old URL → new URL

Коли сторінок сотні або тисячі, руками зв’язувати кожну пару довго і ризиковано. Саме тут таблиця починає працювати як інженерний інструмент. Якщо у вас є окремий лист із новими сторінками, можна підтягувати новий URL автоматично через XLOOKUP або VLOOKUP за назвою, артикулом, slug або категорією.

Приклад логіки:

  • на одному листі у вас старий каталог;
  • на другому — новий каталог;
  • через формулу ви шукаєте відповідник;
  • вручну допрацьовуєте тільки складні або нестандартні випадки.

Приклад через XLOOKUP:

=XLOOKUP(C2, NewMap!C:C, NewMap!B:B, "")

Тут C2 може бути назвою сторінки, товару або технічним ключем. Але важливо пам’ятати: формула не замінює перевірку. Вона пришвидшує чорнове зіставлення, а не гарантує, що сторінка дійсно релевантна як кінцева точка.

Крок 4. Перевірте new URL ще до релізу

Перевірте new URL ще до релізу
Перевірте new URL ще до релізу

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

Найпростіший сценарій — прогнати таблицю через Apps Script і перевірити, чи new URL:

  • відповідає кодом 200;
  • не веде в 404;
  • не віддає 500;
  • не запускає ланцюжок зайвих перенаправлень.

Нижче — базова функція для перевірки сторінок на тестовому сервері.

function checkNewUrlsOnStaging() {

const sheet = SpreadsheetApp.getActiveSpreadsheet().getActiveSheet();

const lastRow = sheet.getLastRow();

for (let i = 2; i <= lastRow; i++) {

const oldUrl = sheet.getRange(i, 1).getValue();

const newUrl = sheet.getRange(i, 2).getValue();

if (!newUrl) {

sheet.getRange(i, 5).setValue('NO NEW URL');

continue;

}

try {

const response = UrlFetchApp.fetch(newUrl, {

followRedirects: false,

muteHttpExceptions: true

});

const code = response.getResponseCode();

if (code === 200) {

sheet.getRange(i, 5).setValue('OK 200');

} else if (code >= 300 && code < 400) {

sheet.getRange(i, 5).setValue('REDIRECT ' + code);

} else if (code === 404) {

sheet.getRange(i, 5).setValue('ERROR 404');

} else {

sheet.getRange(i, 5).setValue('CHECK ' + code);

}

} catch (e) {

sheet.getRange(i, 5).setValue('FETCH ERROR');

}

}

}

Цей код — мінімальна база. У бойовому варіанті його варто розширити:

  • додати перевірку фінального URL;
  • виводити redirect target в окрему колонку;
  • окремо позначати 301, 302 і 307;
  • логувати проблемні рядки.

Крок 5. Вбийте ланцюжки та цикли до запуску

Для SEO міграція небезпечна не тільки помилками 404. Ланцюжки типу old URL → temporary URL → final URL теж ламають швидкість і створюють зайві кроки для користувача та робота. Ще гірше — циклічні редиректи, коли сторінка починає ганятися по колу.

Хороше правило дуже просте:

  • один old URL;
  • один прямий 301;
  • один фінальний new URL.

Не робіть “тимчасових обхідних маршрутів”, якщо можете дати пряме перенаправлення одразу. І не редиректіть усі старі сторінки на головну — це поганий сигнал і для користувача, і для SEO.

Крок 6. Впровадження на сервері

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

  • .htaccess для Apache;
  • конфіг Nginx;
  • правила на рівні CMS або reverse proxy.

Тут важливо не просто “додати редиректи”, а зберегти контроль над логікою:

  • найцінніші сторінки перевіряємо окремо;
  • масові шаблонні правила застосовуємо лише там, де структура справді передбачувана;
  • складні URL із параметрами не лишаємо “на авось”.

Крок 7. Перевірте все після релізу

Після викатки робота не закінчується. Тепер потрібно перевірити вже активовані редиректи на live-сайті:

  • чи old URL віддає 301;
  • чи new URL відкривається з 200;
  • чи немає 302 замість 301;
  • чи не з’явилися нові 404;
  • чи правильно оновлюються сигнали в Search Console.

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

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

Що має бути у фінальному чек-листі міграції

  • зібрані всі актуальні old URL;
  • пріоритезовані сторінки з трафіком і беклінками;
  • створена 301 redirect map;
  • усі new URL перевірені на стейджингу;
  • ланцюжки та цикли прибрані;
  • редиректи розгорнуті на сервері;
  • після релізу виконана повторна перевірка.

Висновок

Міграція сайту SEO — це не про удачу. Це про карту, контроль і перевірку до того, як помилки побачить Google. Якщо у вас є повний inventory, чиста 301 редирект мапа, тестовий сервер і простий скрипт для перевірки кодів відповіді, переїзд перестає бути хаосом. Він стає керованим процесом.

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