SEO-план міграції пов’язує старі сторінки з новою версією сайту й визначає порядок її приймання. Одного списку редиректів недостатньо: потрібна картка може відкритися за новою адресою, але втратити опис, мову або зв’язки з категорією.
Розгляньмо умовний магазин фурнітури, який змінює структуру шляхів на попередньому домені. Картка петлі H-12, категорія петель та інструкція з вибору мають зберегти своє призначення. План потрібен до перемикання, а не після появи перших втрат.
До запуску: збережіть початковий стан і погодьте долю сторінок
Зберіть перелік адрес із CMS, обходу, sitemap, доступних журналів, Search Console та аналітики. Почніть із важливих для бізнесу сторінок, але не обмежуйтеся поточними лідерами переходів. Інструкція може мати сезонний попит, а файл із розмірами – вхідні посилання, яких не видно в короткому періоді звіту.
Додайте зображення, документи й потрібні ресурси. Переїзд HTML-картки не переносить їх автоматично. Збережіть початкові матеріали й налаштування, за якими можна встановити, що змінилося та як повернути передбачену поведінку.
Для кожної адреси визначте результат: залишається попередньою, отримує рівноцінний новий шлях, об’єднується з відповідним матеріалом або остаточно видаляється без заміни. Не призначайте головну сторінку спільною ціллю для всіх винятків.
Для H-12 підтвердьте ту саму модель, комплект і корисний опис у новій картці. Для категорії – потрібний асортимент і переходи до товарів. Для інструкції – сам матеріал, а не лише перенесений заголовок. Мовні версії зіставте окремо.
Зафіксуйте початкові показники з датами й фільтрами: сторінки, тип пошуку, країни, пристрої та вибраний період. Кліки Search Console і сеанси аналітики не стають однією метрикою. Роботу вимірювань на новій версії потрібно перевірити окремо від майбутнього трафіку й замовлень.
Розподіліть відповідальність і підготуйте умови запуску
Для кожного завдання вкажіть виконавця, результат і спосіб приймання. Власник матеріалу вирішує, що зберігається, а що знімається; розробник відповідає за маршрути й виведення шаблонів; фахівець із перевірки зіставляє фактичну версію з рішенням. Сама назва ролі не означає, що завдання комусь передали.
Намагайтеся розділяти незалежні великі зміни. Одночасна зміна адрес, CMS, асортименту й дизайну ускладнить пошук причини збою. Якщо розділення неможливе, явно перелічіть залежності й розширте контрольні сценарії під фактичний обсяг.
Підготуйте умови дозволу на запуск. Для магазину фурнітури вони можуть мати такий вигляд.
| Контрольний об’єкт | Що має бути готове | Коли перемикання відкладають |
|---|---|---|
| Картка H-12 | Новий шлях віддає ту саму потрібну модель і вміст | Замість картки заглушка або інший товар |
| Категорія петель | Товари доступні за справжніми посиланнями | Потрібний асортимент існує лише в базі |
| Мовна пара | Переклади, canonical і зв’язки ведуть на погоджені нові адреси | Одна мова випадково підміняє іншу |
| Попередні маршрути | Правила ведуть до відповідних кінцевих сторінок | Є цикли, неправильні цілі або втрачені винятки |
| Доступність версії | Відповіді, ресурси й правила індексації відповідають запуску | На потрібних публічних сторінках залишилися обмеження тестового середовища |
Окремо додайте бізнес-сценарії: які форми та шляхи купівлі мають зберегтися, хто і як їх прийме. SEO-перевірка маршруту не підтверджує правильність розрахунку замовлення або роботи оплати.
Під час перемикання: перевіряйте фактичну версію
Виберіть відповідне вікно з урахуванням відвідувань та операційної роботи. Запишіть послідовність дій, відповідального за рішення про зупинку та спосіб зв’язку виконавців. План повернення має враховувати дані й налаштування, які змінюються під час запуску; миттєве безпечне повернення не можна обіцяти без такої підготовки.
Для постійного перенесення налаштуйте відповідні постійні переходи, наприклад 301 або 308, на погоджені цілі. Бажаний прямий маршрут до кінцевого матеріалу. Внутрішні посилання, canonical, мовні зв’язки й нова sitemap також мають використовувати нові адреси.
Перевірте саме робочий домен після перемикання. Знятий noindex на стенді не допомагає, якщо він залишився в публічній відповіді. Переконайтеся, що потрібні файли доступні, а сервер справляється із запитами до попередніх і нових маршрутів.
У нашому прикладі домен не змінюється, змінюються лише шляхи: інструмент зміни адреси ресурсу в Search Console для цього не потрібен. Для іншого типу перенесення склад процедур уточнюють окремо; один сценарій не можна механічно переносити на всі міграції.
Якщо H-12 відкриває інший товар або категорії недоступні, це встановлена проблема впровадження. Її не слід пояснювати очікуванням переіндексації. Виправте причину або виконайте передбачене повернення, потім повторіть відповідні перевірки.
Після запуску: спостерігайте за перенесенням і зберігайте маршрути
Окремо стежте за відповідями старих адрес, станами нових сторінок у Google та переходами користувачів. Порівнюйте ті самі групи й умови, які зафіксували до запуску. Для зміни домену дані старого й нового ресурсу також потребують узгодженого обліку.
Перенесення обробляється за окремими URL; готовність сайту не означає одночасного оновлення всіх пошукових даних. Можливі коливання видимості. Водночас технічні дефекти, які зберігаються, потрібно досліджувати за фактами, а не чекати їх зникнення до вигаданого строку.
Заплануйте тривале збереження постійних переходів: зазвичай щонайменше рік, а якщо старі маршрути потрібні користувачам – довше. Уточніть, хто підтримує попередній домен і правила, якщо вони беруть участь у перенесенні. Видалення редиректів через кілька днів може обірвати шляхи, якими ще користуються.
Підсумковий план має давати змогу відповісти, що переноситься, хто це робить, який результат дозволяє запуск і як виявити відхилення. Підготовку технічної частини разом із перевіркою шаблонів і зв’язків можна обговорити в межах внутрішньої SEO-оптимізації сайту.
Потрібна допомога з вашим проєктом?
Залиште ім’я та номер телефону. Зв’яжуся з вами, щоб обговорити завдання, обсяг робіт і наступний крок.
