Съветът да настроите пренасочванията и да пуснете новия сайт не е достатъчен. Миграция на сайт е преместване към нов домейн, хостинг, система за управление на съдържанието или структура, при което адресите, видимостта в търсачките и пътят до запитване трябва да продължат да работят. Успешното преместване не приключва с отварянето на началната страница. Трябва да можете да проверите дали клиентите още изпращат формуляри, завършват поръчки и достигат до правилния човек във фирмата.
Съдържание
- Етапите на миграцията и какво трябва да е готово във всеки
- Как да съберете пълния списък с адреси
- Пренасочване, 404 или сливане
- Как да измерите запитванията преди и след миграцията
- Тестване в staging среда преди смяната на DNS
- Проверки след старта на 1, 3, 7 и 14 ден
- Чести грешки при миграция на сайт
- Потвърдете готовността и следващата стъпка
Етапите на миграцията и какво трябва да е готово във всеки
Започнете с обхвата на промяната, а не с датата за пускане. Преместването на хостинг със запазени адреси изисква различна подготовка от смяна на платформата, каталога и домейна едновременно. Запишете какво се променя, какво остава и кой одобрява всяка част.
URL инвентар означава пълен списък на уеб адресите и свързаните с тях ресурси. Пренасочване 301 е постоянен сървърен отговор, който отвежда посетителя и търсачката от стария адрес към новия. Те са основата на техническия план, но не заменят проверката на реалните запитвания и поръчки.
Етапи на миграцията и критерии за преминаване
| Етап | Основна задача | Готовност преди следващия етап |
|---|---|---|
| Инвентар | Списък на всички URL адреси, изображения, PDF файлове и приходни страници | Списъкът е сверен със сървърните логове и Search Console |
| Съпоставяне | Всеки стар адрес е свързан с нов адрес или с решение за премахване | Няма страница без решение |
| Staging тест | Обхождане, проверка на sitemap, robots.txt, canonical, hreflang, формите и събитията | Критичните страници и формуляри работят в тестовата среда |
| Измерване | Архив на GA4, Search Console, рекламни и CRM данни | Има базов период за сравнение и записани критерии |
| Превключване | Намален DNS TTL, активни пренасочвания, rollback копие на базата, файловете и DNS | Връщането назад е проверено и знае се кой го изпълнява |
| След старта | Мониторинг на 404 и 5xx грешки и сравнение с базовия период | Проверките през 1, 3, 7 и 14 ден са по график |
Таблицата е списък на зависимостите, а не разрешение да отложите измерването. Архивът на резултатите започва още при инвентаризацията, а критериите за одобрение се записват преди тестовете и превключването. Съпоставянето не може да започне без пълен списък на адресите, а цялостният staging тест изисква готово съпоставяне.
Staging е защитено тестово копие на сайта. Останалите проверки обхващат правилата за обхождане, предпочитаните адреси, езиковите версии и бизнес функциите, описани по-долу.
Разпределете отговорностите преди работата
За всеки етап посочете изпълнител и човек, който приема резултата. Разработчикът проверява техническото поведение, маркетинг специалистът проверява измерването, а собственикът или управителят потвърждава дали поръчката и запитването достигат до екипа. При малка фирма един човек може да изпълнява няколко роли, но отговорностите трябва да останат отделни.
Инвентарът определя кои адреси изискват внимание. Съпоставянето определя съдбата им. Измерването определя дали промяната е приемлива за бизнеса, а следстартовите проверки показват какво действително се случва.
Правило за пускане: Ако някой етап няма ясен изход и отговорник за приемането му, превключването се отлага.
Как да съберете пълния списък с адреси
Ръчното разглеждане на менюто не е инвентаризация. То пропуска рекламни страници, стари продуктови адреси, файлове с външни връзки и съдържание, което вече не е достъпно през навигацията. Точно такива адреси могат още да водят клиенти.
Създайте обща таблица и обединете адресите от различните системи. Запазете източника на всеки запис, за да знаете защо дадена страница присъства и как да проверите значението ѝ.
Откъде да извадите адресите
- Сървърни логове: Това са записите на заявките към сървъра. Те показват кои адреси посетители и роботи още отварят, включително адреси извън менюто.
- Search Console: Извадете страниците с органични кликвания и информацията за индексиране. Запазете и търсенията, по които важните страници се появяват.
- Google Analytics: Потърсете входните страници, изпратените формуляри и поръчките. Страница с малко посещения може да носи ценни запитвания.
- Стари XML sitemap файлове: Това са машинно четими списъци с адреси за търсачките. Архивните им версии могат да съдържат вече забравено съдържание.
- Рекламни кампании: Проверете крайните адреси в Google Ads и Meta Ads, включително спрени кампании. Те често пазят промоционални страници, които екипът вече не помни.
- Инструменти за обратни връзки: Потърсете външни сайтове, които сочат към ваши страници, изображения или каталози. Така откривате ресурси, които вътрешното обхождане пропуска.
За всеки URL запишете типа ресурс, статус кода и органичния трафик. Статус кодът е отговорът на сървъра дали ресурсът е достъпен, преместен или липсва. Добавете изображенията и PDF файловете, не само страниците.
Какво да проверите отделно
Запишете canonical, указанието коя е предпочитаната версия на адреса, и hreflang, връзките между езиковите варианти. Проверете българските и английските страници поотделно, включително адресите на кирилица и латиница. Не ги обединявайте механично само защото заглавията изглеждат еднакви.
Хипотетичен пример: Сайт със 150 видими страници може да има още 80 адреса от архивни промоции и две стари поддомейн версии. Те не са непременно излишни. Някои може да получават рекламни посещения или да съдържат каталог, към който сочат партньори.
Подредете готовия списък по приход, запитвания и локална видимост. За страница на физически обект проверете телефона, адреса и обслужвания район. Ръчният преглед започва от ресурсите, чиято загуба би прекъснала продажби или контакт с клиенти, а не от най-лесните за обработване страници.
Пренасочване, 404 или сливане
| Тип страница | Действие | Кога се използва |
|---|---|---|
| Страница със същото намерение и нов еквивалент | 301 към еквивалента | Услугата или продуктът е преименуван или преместен |
| Две стари страници със сходна тема | 301 от двете към една обединена страница | Стара статия и стара категория отговарят на един и същи въпрос |
| Страница с трафик или заявки без аналог | Ръчна оценка, после нова страница или 301 към най-близката | Стар продукт, който още се търси |
| Страница без стойност и без входящи връзки | 404 или 410 | Архивна кампания или изтекла промоция |
| Старо PDF или изображение с входящи връзки | 301 към новия файл | Каталог, който е публикуван в нов формат |
| Общо пренасочване към началната страница | Не се използва | Новата страница няма същото намерение и посетителят губи пътя си |
Най-честото правилно решение е директно пренасочване към новия еквивалент. Еквивалент означава страница, която изпълнява същата задача за посетителя, а не просто съдържа сходна дума в заглавието. При преместване на услуга клиентът трябва да намери услугата, условията и начина за запитване.
В документацията си за преместване на сайт Google препоръчва постоянни сървърни пренасочвания, актуализирани sitemap файлове и запазване на пренасочванията обикновено поне една година. Разликите в поведението и практическата настройка са разгледани и в ръководството за пренасочване 301.
Кога близката страница не е достатъчно близка
Ако старият адрес представя конкретен резервен компонент, общата категория с несъвместими продукти не е полезен заместител. По-разумно може да бъде да запазите информационна страница за спрения продукт с ясно обозначени съвместими алтернативи. Това изисква повече работа по съдържанието, но не оставя клиента да гадае.
404 означава, че ресурсът не е намерен. 410 показва, че е премахнат окончателно. Когато няма реален еквивалент и съдържанието няма причина да остане, контролирана страница с такъв отговор е по-честно решение от несвързано пренасочване.
Полезната страница за липсващ ресурс може да предложи търсене, навигация и контакт. Сървърът обаче трябва да върне правилния статус, а не да представя липсващата страница като нормално достъпна.
Сливайте само когато запазвате полезното съдържание
При две стари статии по една тема създайте обединена страница, която запазва важните отговори и от двете. След това насочете двата стари адреса директно към нея. Същият подход е подходящ за статия и категория само ако новата страница действително покрива общото намерение.
Не изграждайте верига от стар адрес към междинен и после към окончателния. Тествайте крайната цел, езика и съдържанието, а не само наличието на пренасочване. Актуализирайте и вътрешните връзки, така че посетителите да отварят новия адрес непосредствено.
Пренасочването е обещание към посетителя, че на новия адрес ще намери смислен заместител. Началната страница рядко изпълнява това обещание.
Как да измерите запитванията преди и след миграцията
Според НСИ 49,7% от предприятията имат собствен уебсайт. Този показател не доказва колко добре фирмите измерват резултатите си. Той обаче поставя практичния въпрос дали сайтът е просто представяне на бизнеса, или канал с проследими запитвания и продажби.
Подгответе архива и критериите за решение преди staging теста. GA4 е системата Google Analytics за измерване на посещения и действия. CRM е системата, в която екипът обработва контактите и продажбите, а UTM параметрите са означения в рекламните връзки за разпознаване на източника.
Източници за архив преди и след миграцията
| Източник | Какво се архивира | Как се сравнява след миграцията |
|---|---|---|
| GA4 | Сесии, събития и конверсии по входна страница | По страница, устройство и език BG/EN |
| Search Console | Кликвания, заявки за търсене и индексиране по URL | По страница и заявка за търсене |
| Google Ads и Meta Ads | Кампании, UTM параметри, кликове и конверсии | Запитвания по кампания след смяната на адресите |
| CRM и онлайн поръчки | Източник на заявката, статус и стойност на поръчката | Брой заявки и приход по канал |
Конверсия е значимото действие, което измервате, например изпратен формуляр или завършена поръчка. Запазете телефонните кликове отделно от действителните разговори. Кликът върху телефон не доказва, че клиентът е разговарял с екипа.
Изберете базов период с представителна активност. Отбележете промоции, промени в рекламния бюджет, липсващи наличности и почивни дни, защото те могат да обяснят разлика без технически проблем. За организацията на събитията използвайте и практическите насоки за GA4 и измерване на маркетинговите резултати.
Запишете кога пускането се одобрява и кога се спира
Определете кои входни страници трябва да запазят работещ път до конверсия, какво отклонение е допустимо и кой взема решението за връщане. Това са критериите за пускане или спиране. Праговете се задават според бизнеса, обема на поръчките и нормалните колебания, а не се копират от чужд проект.
Примерен казус: Посещенията са се възстановили, но отчетените запитвания са намалели. Проверете дали формулярите действително изпращат, дали благодарствената страница е сменена и дали аналитичното събитие се задейства. Проверете и запазването на UTM параметрите.
Съпоставете аналитиката с получените заявки. Ако екипът ги получава, но GA4 не ги отчита, проблемът е в измерването. Ако липсват и в пощата или CRM, трябва да проверите целия процес, а не само настройките за търсачки.
Тестване в staging среда преди смяната на DNS
Staging средата е копие за проверка, защитено от публичен достъп и индексиране. Там можете да тествате новата платформа, без клиентите да попадат на незавършени страници. DNS е системата, която насочва домейна към съответния сървър.
Последователност на приемателния тест
- Обходете тестовото копие. Използвайте crawler, инструмент за автоматично обхождане като Screaming Frog, и сравнете откритите страници с инвентара. Проверете менюта и вътрешни връзки, а всяко липсващо съдържание трябва да има обяснение.
- Проверете достъпа за търсачки. Прегледайте robots.txt, файла с правила за обхождане, XML sitemap и noindex, указанието страницата да не се индексира. Подгответе публичната конфигурация, без да премахвате преждевременно защитата на тестовото копие.
- Проверете адресните и езиковите указания. На примерни страници от всеки тип валидирайте canonical, hreflang и структурираните данни, машинно четимите описания на съдържанието. Нито едно указание за публичния сайт не трябва да сочи към тестовия домейн.
- Изпратете контролирано запитване. Проверете формите на телефон и компютър, съобщенията за грешки и прикачените файлове, ако има такива. Резултатът е приет само когато заявката пристигне при правилния получател.
- Потвърдете измерването. Проследете тестовото действие в аналитичните инструменти и съпоставете данните с реално получената заявка. Уверете се, че повторното отваряне на потвърждението не създава дублирани конверсии.
Запазвайте резултатите като задачи с адрес, описание и отговорник. Снимка на работеща начална страница не е доказателство за готов магазин. При по-сложна структура използвайте технически одит на сайта, за да групирате проблемите по шаблони и приоритет.
Допълнителни проверки за онлайн магазин
В Studio Algorithm започваме новите сайтове със структурата, съдържанието и функционалностите. При онлайн магазин това включва и решения за управлението на каталога, завършването на поръчката, плащането и доставката. При миграция тези решения трябва да се проверят като свързан процес, не като отделни екрани.
Тествайте варианти на продукти, наличности, количка, отстъпки и изчисляване на доставка. Проверете успешно и неуспешно плащане чрез подходящия тестов режим на платежния доставчик. Потвърдете, че поръчката влиза в администрацията с правилния статус и че клиентското известие е коректно.
В списъка за превключване оставете отделни отметки за:
- Публичен достъп: Сваляне на тестовата защита и предназначените само за теста ограничения за индексиране.
- Окончателна синхронизация: Прехвърляне на новите поръчки, клиенти и промени след създаването на копието.
- Работен режим: Активиране на реалните интеграции и последен контролиран тест след DNS промяната.
Проверки след старта на 1, 3, 7 и 14 ден
| Ден | Проверка | Сигнал за проблем |
|---|---|---|
| Ден 1 | Ръчен тест на формите, менюто, плащането и телефонните връзки | Грешки 404 или 5xx при критични адреси |
| Ден 3 | Логове за 404 при стари адреси, които са имали трафик | Стари адреси без пренасочване или с верига от пренасочвания |
| Ден 7 | Сравнение на кликвания, заявки и конверсии с базовия период | Спад при страници с приход, без обяснение в събитията |
| Ден 14 | Индексиране, sitemap и стари адреси в търсенето | Стари адреси, които още се индексират без пренасочване |
Това е работен график за контрол, а не срок за възстановяване на позиции. Наблюдението на сървърни грешки започва веднага при пускането. Кодове 5xx означават проблем при обработката на заявката от сървъра.
Какво действие следва от сигнала
В началната проверка изпълнете реалния клиентски път през ключовите страници. При неработеща форма, плащане или телефонна връзка определете засегнатия обхват и спрете платеното насочване към неработещия процес, докато го поправите.
При прегледа на логовете отделете случайните заявки към несъществуващи адреси от пропуснатите ценни страници. Поправете съпоставянето за старите адреси с реален трафик. Проверявайте и крайната цел на пренасочването, не само първия отговор.
При сравнението на резултатите разгледайте отделно приходните страници, устройствата и каналите. Спад в поръчките изисква проверка на измерването, формите и покупката, преди да се обяснява с органичната видимост. При магазин сравнете и стойността и статуса на поръчките.
При проверката на индексирането разграничете стар адрес, който още се вижда в резултатите, от стар адрес без работещо пренасочване. Вторият случай изисква техническа корекция. Прегледайте и дали sitemap съдържа само предназначените за публичния сайт адреси.
За двуезичните сайтове правете проверките поотделно за всеки език: според НСИ през 2025 г. 25,1% от предприятията с уебсайт предоставят съдържание поне на два езика. Работещата българска форма не доказва, че английската версия изпраща към правилния получател.
Подгответе връщането преди превключването
Rollback е връщане към предишната работеща версия. Преди старта запазете базата, файловете и DNS конфигурацията, проверете възстановяването и посочете кой може да го изпълни. Намалете предварително DNS TTL, времето за кеширане на DNS записите, за да ограничите забавянето при промяна.
Резервното копие не е достатъчно. Нужен е проверен начин за възстановяване, който не изтрива новополучени поръчки и запитвания.
При магазин определете как ще запазите данните, постъпили след превключването. Пълното връщане на стара база без такъв план може да създаде нов бизнес проблем вместо да реши първоначалния.
Чести грешки при миграция на сайт
Някои пропуски не личат при визуален преглед. Те се разпознават чрез съпоставяне на техническия отговор с действително получените заявки.
- Оставена тестова защита: След пускането страниците остават с noindex или блокирани за обхождане. Проверете публичните отговори и сигналите в Search Console, премахнете непредвидените ограничения и повторете обхода.
- Променено всичко едновременно: Нови адреси, дизайн и съдържание затрудняват откриването на причината за спад. Запазете описание на промените и, когато е възможно, разделете преместването от голямото редактиране.
- Спрян стар домейн или хостинг: Старите връзки вече не достигат до новия сайт. Осигурете работещо обслужване на старите адреси за планирания период на пренасочванията, дори старият сайт вече да не се използва.
- Пропуснати пощенски записи: MX определя къде се получава пощата, а SPF участва в удостоверяването на изпращачите. Липсващ MX може да прекъсне получаването, докато неправилен SPF може да влоши доставянето на изпращаните съобщения, затова проверете и двете посоки с реален тест.
- Формуляр към стар получател: Сайтът отчита успешно изпращане, но заявката отива в непроверявана поща или при напуснал служител. Проверете дневника на изпращането и потвърдете получаването с отговорния човек.
Финален контрол с отговор да или не
- Индексиране: Публичните страници достъпни ли са без тестови ограничения?
- Проследимост: Документирани ли са отделно техническите и съдържателните промени?
- Стар адрес: Запазено ли е обслужването на стария домейн и пренасочванията?
- Поща: Проверени ли са получаването и изпращането след DNS промяната?
- Получател: Потвърди ли правилният човек, че е получил тестовата заявка?
Потвърдете готовността и следващата стъпка
Планът за миграция е готов за одобрение, когато можете да представите доказателства, а не само уверение, че разработката е приключила. Работещият дизайн е необходим, но сам по себе си не показва дали сте запазили ценните адреси и пътя до продажба.
Условия за решение
- Проверен инвентар: Списъкът е сверен със сървърните логове и Search Console, а важните ресурси имат определена съдба.
- Тествано съпоставяне: Пренасочванията са проверени на примерни страници от всеки тип, включително файлове и езикови варианти.
- Записано измерване: Базовият период, допустимите отклонения и отговорникът за решение са определени преди DNS промяната.
Ако някое условие липсва, отложете превключването. Разходът за отстраняване на пропуск в тестова среда е по-лесен за управление от проблем, който вече засяга клиентски поръчки. Пускането не трябва да зависи единствено от приключила дизайнерска задача или предварително обявена дата.
Подгответе кратко описание на текущата платформа, броя страници, езиците и каналите, от които идват запитванията. Добавете какво искате да промените и какво не бива да прекъсва, например поръчки, партньорски каталози или заявки за конкретна услуга. Това позволява първо да се обсъдят рисковете, а след това техническото решение.
За обсъждане на конкретния сайт изпратете описанието през страницата за контакт със Studio Algorithm. Посочете и най-важния за бизнеса ви адрес, за да има ясна отправна точка при оценката.
Studio Algorithm предлага уеб разработка и последваща техническа поддръжка с актуализации, мониторинг, сигурност, резервни копия и оптимизация на производителността, които са важни и след миграцията. Посетете Studio Algorithm, за да обсъдите преместването и проверките за вашия сайт. Кой адрес на сайта не бихте искали да загубите при миграцията?
Да приложим това във вашия бизнес?
Разкажете ни за сайта и целите си. Ще обсъдим подходящите следващи стъпки.
Свържете се
