Чек-лист міграції сайту, який пропускають більшість агенцій

Більшість міграцій сайту провалюються не з гуркотом.

Вони провалюються тихо, через тижні після того, як усі вже переключились на наступний проєкт.

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

Іноді так і є.

Іноді справжня проблема просто ще не проявилась.

Чек-лист міграції існує не просто так. Але більшість чек-листів фокусуються на видимій механіці: редиректи, sitemap, мобільна версія, аналітика, DNS.

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

Успішна міграція, це не про запуск нового сайту.

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

Чому провал виглядає тихо

Чому провал виглядає тихо

Чиста міграція і зламана можуть виглядати майже однаково в перший тиждень.

Деяка втрата трафіку нормальна. Google потрібно проіндексувати нові URL, обробити редиректи і переоцінити зв'язок між старою і новою версіями сайту.

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

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

Різниця в тому, що відбувається далі.

Небезпека тому не в першому падінні трафіку. Вона в припущенні, що це падіння і є всією історією.

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

Цього недостатньо, щоб назвати міграцію успішною.

Про міграцію потрібно судити за траєкторією, що слідує за нею, а не за скріншотом, знятим через три дні після запуску.

Карта редиректів, яку ніхто не закінчує

Карта редиректів, яку ніхто не закінчує

Усі знають, що редиректи важливі.

Набагато менше команд редиректять усе, що насправді потрібно редиректити.

Очевидні сторінки зазвичай виживають: головна, ключові сторінки послуг, важливі продукти.

Складна частина, це довгий хвіст.

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

Одна задокументована міграція прокраулила 14 200 URL і створила редиректи на весь набір, а не тільки на сторінки, важливі за аналітикою. Інша протестувала майже тисячу окремих редиректів до запуску.

Такий рівень підготовки може здаватись надмірним, поки щось не зламається.

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

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

Пошуковим системам байдуже до дедлайну.

Є ще одна проблема, яку ще легше пропустити: варіанти URL.

HTTP проти HTTPS. З www чи без. Trailing slash. Регістр. Старі структури URL. Параметри і застарілі шляхи.

Для людини це може виглядати однією й тією самою сторінкою.

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

Карта міграції, що покриває сторінки, які люди пам'ятають, але ігнорує URL, які ніхто не пам'ятає, не повна карта міграції.

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

Довгий хвіст, це де зазвичай ховаються роки накопиченої історії.

Старі сайти буває важче перенести

Старі сайти буває важче перенести

Одна міграція відновлюється за тижні. Інша може зайняти багато місяців.

Хочеться звинуватити платформу, CMS чи реалізацію редиректів.

Це має значення. Але це не вся картина.

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

У цьому є інтуїтивний сенс.

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

Це створює незручний парадокс.

Чим усталеніший сайт, тим ретельніше, можливо, потрібно поводитись з його міграцією.

Вік сам по собі не проблема. Проблема, накопичена складність.

Тому десятирічний сайт із сильною пошуковою видимістю не варто трактувати просто як більшу версію дворічного сайту.

Його ризик міграції інший.

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

Ми самі проходимо через рівно такий перехід прямо зараз зі SHTAYER, переносячи каталог, що зростає мультимовно, з WordPress на Laravel, оскільки стара платформа вичерпала себе. Ми писали про те, яке рішення запускає такий переїзд, у статті Коли бізнес переростає WordPress?.

Сліпа зона трьох тижнів

Сліпа зона трьох тижнів

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

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

Потім сигнал може зсунутись.

Іноді позитивно. Іноді негативно.

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

Команда розробки перейшла на інший проєкт. SEO-консультант здав звіт по запуску. Клієнт прийняв новий сайт. У найгірших випадках стара інфраструктура вже деактивована.

Тепер є проблема з трафіком, але немає чистого бейзлайну і нікого з повним контекстом.

Тому ми ставимось до постзапускного моніторингу як до частини самої міграції, не як до опціонального постпродакшену.

Запуск, це віха.

Це не кінець міграції.

Структуровані дані заслуговують на увагу

Структуровані дані заслуговують на увагу

Мікророзмітку легко забути, бо відвідувачі її не бачать.

Саме тому вона губиться під час міграцій.

Нова CMS може генерувати свою власну структуровану розмітку. Може не генерувати жодної. Може замінити ретельно реалізовану розмітку на загальну.

Сайт може виглядати повністю коректним, поки пошукова система отримує суттєво іншу інформацію.

Product schema, review schema, article schema та інші типи структурованих даних мають різні вимоги. Міграції тому потрібна не лише візуальна перевірка.

Живу реалізацію потрібно протестувати.

Тут теж є важлива різниця.

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

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

Rich-результат зникає. Сторінка стає менш зрозумілою пошуковику. CTR змінюється. Рейтинг трохи зсувається.

Окремо жодне не виглядає катастрофою.

Разом вони можуть стати дорогими.

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

Hreflang може зламатись непомітно

Hreflang може зламатись непомітно

Для мультимовних сайтів проблема ускладнюється.

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

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

Сайт все ще відкривається.

Перемикач мови все ще працює.

Контент все ще на місці.

Але сигнали, що надсилаються Google, можуть більше не відповідати структурі, яку задумав бізнес.

Тому мультимовні міграції вимагають архітектурного мислення, а не просто перевірки перекладів.

Питання не лише в тому, чи існує кожна мовна версія.

Питання в тому, чи зберігає нова система зв'язки між цими версіями.

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

Робота відбувається до запуску

Робота відбувається до запуску

Найсильніші міграції поділяють одну просту рису:

Більша частина складної роботи відбувається до зміни DNS.

Карта редиректів готується, поки старий сайт ще живий.

Інвентар URL звіряється з новою архітектурою.

Внутрішні посилання аудіюються.

Мікророзмітка документується.

Зв'язки hreflang картуються.

Дані аналітики і Search Console встановлюють бейзлайн.

Важливі рейтинги і посадкові сторінки ідентифікуються.

Новий сайт тестується проти старого до того, як старе оточення зникає.

Це не ефектна робота.

Ніхто не дивиться на ідеальну таблицю редиректів у день запуску і не думає: яка прекрасна міграція.

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

А нудний, це саме те, що нам потрібно.

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

Знайти проблему під час планування, це знахідка аудиту.

Знайти її після запуску, це інцидент.

Моніторинг не закінчується на запуску

Моніторинг не закінчується на запуску

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

Це самозаспокоєння.

Серйозній міграції потрібен визначений період спостереження.

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

Це не обов'язково вимагає величезного технологічного стеку.

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

Точний період моніторингу повинен залежати від розміру і складності сайту.

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

Це ще одне місце, де жорсткі чек-листи можуть стати небезпечними.

Чек-лист повинен контролювати ризик, не замінювати судження.

У що обходиться пропуск цього

У що обходиться пропуск цього

Задокументовані випадки складно ігнорувати.

Одна міграція втратила 42% органічного пошукового трафіку за дванадцять днів після того, як компанія пішла без нормальної стратегії редиректів, посилаючись на обмежені IT-ресурси.

Інший сайт середнього розміру в рітейлі запустився з повністю новими URL і без редиректів і втратив приблизно 60% органічного трафіку за два тижні. Відновлення потребувало місяців виділеної роботи.

Є й інші приклади, де зміни URL перетворили позитивне рік-до-року органічне зростання на різке тижневе падіння одразу після запуску.

Ці цифри не варто трактувати як універсальне передбачення.

Сайт не обов'язково втратить 42%, бо хтось пропустив редирект.

Пошук так не працює.

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

Вартість тому не лише в втраченому трафіку.

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

Що потрібно чек-листу

Що потрібно чек-листу

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

Чи мігруємо ми кожен значущий URL, чи лише сторінки, видимі у топ-трафік звіті?

Чи врахували ми варіанти URL і застарілі структури?

Чи розуміємо ми, скільки авторитету і історії накопичив існуючий домен?

Чи задокументували ми структуровані дані сайту до заміни CMS?

Чи збережені мультимовні зв'язки, а не відтворені з пам'яті?

Чи є в нас передзапускний бейзлайн?

Хто відповідає за моніторинг сайту після запуску?

І, можливо, найважливіше:

Що відбувається, якщо цифри виглядають нормально три тижні, а потім раптово ні?

Це питання змінює план міграції.

Бо найбезпечніша міграція не та, у якої найдовший чек-лист.

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

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

Сайт несе історію.

Його URL несуть історію. Його зворотні посилання несуть історію. Його пошукова видимість несе історію. Його мовна архітектура, внутрішні посилання і структуровані дані несуть історію.

Новий сайт може виглядати зовсім інакше.

Накопичена цінність за ним все одно повинна здійснити цю подорож.