Чеклист за миграция на сайт 2026: трите неща, които вече се чупят без предупреждение

Класическият чеклист за миграция е по-стар по дух от повечето екипи, които го ползват, и още работи. Направи карта на всички URL адреси, сложи 301 пренасочвания, не ги махай, обнови вътрешните връзки, подай новите карти на сайта, гледай Search Console. Нито един от тези пунктове не е станал грешен. Проблемът е друг: списъкът е писан за мрежа, в която всяка повреда рано или късно се проявяваше като спад в класирането. Това вече не е така.

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

Първо за статистиката, която няма да я има тук

Търсене по темата за риска при миграция връща уверени проценти: толкова процента от миграциите губят толкова процента трафик. Тези числа обикалят агенционните блогове, повтарят се в презентации и се използват за обосноваване на бюджети.

Не ги цитираме, защото ако тръгнете по следата им, тя не стига доникъде. Източниците цитират един друг, или безименен вътрешен набор от данни, или изследване, което на посочения адрес вече не съществува. Няма публикувана методология, няма определение на извадката и няма как да се разбере какво в тази извадка е наричано „миграция“: смяна на домейн, редизайн, преминаване на друга платформа или всичко наведнъж.

Честната позиция е следната: никой не е публикувал достоверно и възпроизводимо число за средната загуба на трафик при миграция на сайт и всяко число, поднесено като такова, трябва да се чете като маркетинг. Полезният анализ е през механизмите: ето какво се чупи, ето защо и ето как се засича. За това е останалата част от текста.

Тиха повреда номер едно: структурираните данни и изчезването от AI отговорите

Структурираните данни са най-често губеният актив при миграция, защото обикновено живеят в тема, плъгин или шаблонен слой, който точно се сменя. Новият сайт тръгва, страниците изглеждат същите, а разметката Product, FAQ, Organization, Article и Breadcrumb просто спира да се излъчва.

Исторически това струваше богат резултат: звездичките изчезваха от обявата, честотата на кликване падаше малко, някой забелязваше в рамките на месец. През 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 показва как изглежда това, когато пресглобяването и преместването се водят като един проект, а не като два, а припокриването между двете задачи е разгледано подробно в текста за редизайн без загуба на трафик и позиции.