Чек-лист міграції сайту 2026: три речі, які тепер ламаються без жодного попередження

Класичний чек-лист міграції за духом старший за більшість команд, які ним користуються, і він досі працює. Скласти карту всіх URL, поставити 301-і, не знімати їх, оновити внутрішні посилання, надіслати нові карти сайту, дивитися Search Console. Жоден із цих пунктів не став хибним. Проблема в іншому: список писали для вебу, де будь-яка поломка рано чи пізно проявлялася падінням позицій. Це вже не так.

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

Спершу про статистику, якої тут не буде

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

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

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

Тиха поломка перша: мікророзмітка і зникнення з AI-відповідей

Структуровані дані – найчастіша втрата під час міграції, бо зазвичай вони живуть у темі, плагіні або шарі шаблонів, який саме й замінюють. Новий сайт запускається, сторінки виглядають так само, а розмітка Product, FAQ, Organization, Article і Breadcrumb просто перестає віддаватися.

Раніше це коштувало розширеного сніпета: зникали зірочки, трохи падав CTR, за місяць хтось звертав увагу. У 2026 році дорожчим є інший наслідок. Згенеровані відповіді спираються на машиночитаний зміст сторінки, і сторінка, яка більше не заявляє, що вона таке, скільки коштує і чи є в наявності, стає слабшим кандидатом на використання і цитування. Вступ Google до структурованих даних описує їх як спосіб допомогти пошуку зрозуміти вміст сторінки, і це розуміння щороку живить дедалі більше поверхонь видачі.

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

Як виявити: візьміть по двадцять URL кожного типу шаблона, прогоніть їх валідатором структурованих даних на старому сайті й на стейджингу і порівняйте віддані типи по полях, а не по сторінках. Робіть це до запуску, а не після. Звіти покращень у Search Console зрештою покажуть проблему, але з відставанням у тижні і лише за типами, які Google уже знав у вас.

Тиха поломка друга: товарний фід і агентні канали

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

Дані про товари тепер виходять із сайту другою трубою, яка не має нічого спільного зі скануванням. Фіди відвантажуються в торгові платформи і в комерційні протоколи для агентів: Universal Commerce Protocol від Google і Agentic Commerce Protocol, який підтримують OpenAI і Stripe, обидва працюють зі структурованого товарного фіда з обов’язковими атрибутами: ідентифікація, ціна, наявність, зображення і ознаки придатності.

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

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

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

Тиха поломка третя: історія CrUX прив’язана до джерела

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

Дані Chrome UX Report агрегуються за джерелом. Згідно з документацією CrUX API, набір даних – це ковзне середнє за 28 днів, яке оновлюється щодня, а коли ідентифікатором є джерело, дані всіх сторінок цього джерела агрегуються разом. Змінюєте домен – стаєте новим джерелом. Накопичені польові дані за вами не йдуть.

Практичні наслідки варто проговорити, бо вони приходять у певному порядку. У перший день після зміни домену в нового джерела даних мало або немає взагалі. До двадцяти восьми днів минає, перш ніж ковзне вікно повністю заповниться післяміграційним трафіком, і джерело взагалі з’являється лише тоді, коли долає поріг популярності. У цей період звітність Core Web Vitals для вашого сайту або відсутня, або побудована на частковому вікні, і будь-яке порівняння старого сайту з новим – це порівняння повного вікна з неповним.

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

Три поломки поруч

Про строки, сформульовано обережно

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

Тому діапазон у чотири-дванадцять тижнів варто подавати як спостережувану практику, а не як офіційну заяву: він збігається з тим, що ми бачимо, він не суперечить документації Google, і він не є цитатою. Різниця має значення, коли клієнт просить назвати дату відновлення.

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

Що додати до стандартного чек-листа

• Тест на паритет структурованих даних на стейджингу, за типами шаблонів, із порівнянням на рівні полів, а не позначкою «пройдено».
• Приймальний тест фіда за кількістю позицій, стабільністю ідентифікаторів, доступністю URL, ціною і наявністю – до перемикання і повторно в перший день.
• Перевірка торгових і агентних каналів на перший і третій день, бо помилки з’являються там і більше ніде.
• Власний збір польових даних швидкодії до, під час і після, щоб провал CrUX не став сліпою зоною.
• Зріз CrUX до міграції, вивантажений і збережений, бо історію джерела потім не дістати.
• Заморожена базова лінія показів, кліків і конверсій за типами шаблонів, щоб пізніша суперечка про те, чи стало гірше, вирішувалася даними, а не пам’яттю.

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

Коротко

Карта редиректів досі є основою міграції, і її вже недостатньо. Структуровані дані можуть зникнути разом зі старими шаблонами і коштувати вам присутності у згенерованих відповідях, не зрушивши жодної позиції. Товарний фід може зламатися повністю на боці торгової платформи, поки ваш сайт поводиться бездоганно. А польові дані CrUX прив’язані до джерела і рахуються ковзним вікном у 28 днів, тож зміна домену обнуляє історію швидкодії рівно тоді, коли вона потрібна. Жодна з трьох поломок не викидає помилки, і саме тому вони мають бути в чек-листі окремими рядками, а не в чиїйсь голові.

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

Ми плануємо ці перевірки за замовчуванням, коли беремо міграцію сайту, включно з передзапусковими тестами паритету і зняттям базової лінії. Кейс Curatos Agency показує, як це виглядає, коли перезбирання і переїзд ведуть як один проєкт, а не два, а перетин цих задач докладно розібраний у тексті про редизайн без втрати трафіку і позицій.