Миграция на сайта на нов CMS без загуба на позиции и трафик: как да направим техническо задание за програмиста

Често онлайн проектът «надраства» родния си CMS (система за управление на съдържанието). Тези, които вече са преживели подобен неудачен преход, добре разбират всички рискове от неграмотния пренос на сайта, затова предупреждават за предстоящите дейности SEO специалиста. Но как да контролирате всички нюанси, така че сайтът да не загуби позиции и трафик след миграцията?

Подготвих чек-лист с последователни стъпки и описание на действията на специалиста по оптимизация за търсачки за всички етапи на преноса на сайта на нов CMS.

1. Подготовка на технически задания (ТЗ) за внедряване на тестов сайт

Важна особеност на миграцията към друг CMS е техническия одит. Всички поправки и SEO доработки трябва да се внедряват на новото «ядро» отново.

Често мигрираме сайта, именно защото на стария не е било възможно да се внедрят доработки с цел оптимизация. Най-добре е предварително да се запознаете с възможностите на системата. Потърсете сайтове с този CMS, за да не изисквате след това невъзможното от програмистите.

Преди да започнете работа над новия сайт или когато вече има «суров» тестов сайт, SEO специалистът е длъжен да даде на програмиста техническо задание:

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

1.2. За формиране на структурата на URL адресите за всички типове страници. Разбира се, добре би било да запазите URL-ите без промени, но при смяна на CMS това е практически невъзможно. Затова трябва отново да определите шаблони за формиране на URL за всички типове страници.

1.3. Шаблони за мета информация (Title, Keywords, Description, H1) за всички типове страници. Тук всичко е индивидуално. Ако на някои страници на сайта имате мета тагове, които са оптимизирани ръчно, направете отделна таблица с тези мета тагове за програмистите. Ако на стария сайт са прилагани шаблони, може те да бъдат доработени и и да се внедрят или просто да се пренесат.

1.4. Базови технически препоръки. За изключване на страници от индексация, настройка на robots.txt, оптимизиране на страници за пагинация, настройка на кодове за отговори от сървъра, генериране на sitemap.xml и html-sitemap, настройка на canonical, микроформати, мултиезичност, настройка на автоматични редиректи (301), оптимизиране на изображения.

1.5. Препоръки за внедряване на SEO поправки, които са били внедрявани по-рано и изискват пренос или които не са могли да бъдат реализирани на старото «ядро». Преди не сте могли да внедрите или да оптимизирате страници-филтри? Добавете отделно подробно ТЗ за да ги реализирате. Липсвала е адаптивна версия на сайта? Добавете ТЗ, за да бъде създадена. Не забравяйте да опишете какво именно трябва да се пренесе.

2. Анализ на тестовия сайт и контрол над внедряването

След известно време програмистът Ви съобщава радостното известие — тестовият сайт е достъпен.

Основни задачи на този етап:

2.1. Съгласуване на дизайна. Ако по сайта работят дизайнери, помолете ги да Ви изпратят макетите. Подгответе списък с уточнения, въпроси, забележки. Записвайте си всички въпроси, които възникват, дори най-незначителните. Включете клиента към обсъждането. Изисквайте поправки по макетите или уговаряйте, кога ще бъдат направени поправките. Колкото по-ясно бъдат направени макетите, толкова по-малко ще трябва да поправяте на тестовия сайт. Ако няма макети, вижте всичко непосредствено на тестовия сайт и все пак подготвяйте списък с уточнения, въпроси, забележки.

2.2. Контрол над внедряването на техническите задания. Не трябва да чакате до момента на релиза и да се надявате, че всичко ще бъде направено точно според ТЗ. Помолете програмистите периодично да Ви показват внедрените точки от техническото задание.

2.3. Провеждането на мини-одит за ползваемост. Удобно ли е на потребителят да извършва целевите действия? Удобно ли е разположена информацията на сайта? Работи ли изпращането на всички форми, на кошницата? Ето това си струва да се провери на първо място.

2.4. Извършване на одит на тестовия сайт. Когато сайтът е практически готов, направете бърз одит, за да разберете възникнали ли са нови критични грешки. Работят ли основните функционалности? Вярна ли е информацията на сайта? Останали ли са там тестови страници или временни текстове? Не се ли генерират излишни линкове от някакъв блок за бърз преглед? Появили ли са се нови типове страници с динамични URL-и? Възникнали ли са циклични редиректи?

3. Подготовка на ТЗ за пренос на сайта

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

3.1. Какво трябва да се направи преди миграцията към нов CMS?

3.1.1. Бекъп. Преди преноса помолете програмистите да направят бекъп на стария и на новия сайт. В случай на непредвидени ситуации ще може бързо да възстановите старото състояние.

3.1.2. Таблица на старите 301 редиректи. Ако на сайта вече са били променяни URL (а това най-вероятно е било правено, ако със сайта е работено), старият сайт вече има своя таблица с редиректи. Трябва да се помолят програмистите да ги пренесат на тестовия сайт.

Защо това е важно? Тази таблица често се забравя и се настройват редиректи само от показваните страници в стария сайт.

Ето така:

Така старите страници от стария сайт остават без редиректи и в резултат на това се получава грешка 404:

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

Освен качването на таблицата с редиректи, на този етап трябва и една допълнителна застраховка.

Как да направим това?

3.1.2.1. Изтеглете от Google Analytics страниците, носещи най-много трафик през предишните година-две. За целта трябва да влезете в отчета «Канали — Organic Search», изберете нужните дати и основния параметър — «Целева страница». След това — изберете показаните 500-1000 реда на страницата и натиснете «Експортирай».

3.1.2.2. Изтеглете от Ahrefs страниците, на които има поставени външни линкове. За целта трябва да отидете на сайта на Ahrefs, да въведете домейна на Вашия сайт и да изберете «Export».

В таблицата ни интересува само колонка «Link URL», тоест тези страници от нашия сайт, към които са насочени външни ресурси.

3.1.2.3. Обединете двете таблици и изтрийте дублираните страници (може да използвате Notepad++ с допълнителното разширение TextFX):

3.1.2.4. Списъкът с всички URL трябва да се сложи в отделна таблица и да се проверят отговорите от страниците, за да се разбере кои страници са достъпни в момента.

Проверката може да се направи с помощта на Netpeak Cheсker.

Ако таблицата с редиректите от стария сайт е пренесена коректно, всички качени по-рано страници на тестовия сайт ще дават 301 код за отговор:

За да проверите кода на отговор и коректността на настройката на редиректите, е достатъчно да промените домейна на основния сайт с тестовия и да проверите URL в Netpeak Checker с включени параметри Status Code и Redirects. Също така си струва да минете по веригата на редиректа — кодът за отговор може да е 301, но редиректа да е към главната страница.

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

Как да направите таблицата с редиректи?

1. Изтеглете всички целеви URL от стария сайт с помощта на Netpeak Spider.
2. Съпоставете ги с аналогичните URL на новия сайт.
3. Ако няма аналогична страница на новия сайт — не е нужно да се настройва редирект, трябва да се получава код на отговор 404.

Ако имате среден интернет магазин или сайт, то най-добре направете съпоставяне на страници за категории и подкатегории ръчно, а след това ги сложете в таблица. Страниците с продуктовата информация може просто да се изтеглят и съпоставянето да се поръча на програмиста.

Пример на таблица с редиректи:

Когато сайтът е голям, ръчното съпоставяне на страници е дълго и трудоемко. В такъв случай всичко е на плещите на програмиста — SEO специалистът трябва само да направи изтеглянето на всички страници от стария сайт, а след настройките да провери кодовете на отговори на изтеглените по-рано страници.

Ако на стария и новия сайт всички URL са формирани с помощта на правила (а не просто са правени ръчно без някаква логика и структуриране), програмистът настройва динамичния редирект без усилие.

Друга работа е, ако URL са формирани ръчно. Едва ли програмистът може да настрои редиректите без съответните таблици. Въпреки че за продуктовите описания понякога прилагат метода на съпоставяне по артикул.

При създаването на таблиците с редиректи, помнете за служебните страници, страниците на блога, новините и така нататък. Не забравяйте за субдомейните, ако ги има.

3.1.4. Пренасяне на контента от стария сайт на тестовия. Ако не направите пренасяне на съдържанието на тестовия сайт, той просто ще се изгуби при миграцията. А това може съществено да повлияе на ранжирането на страниците.

Дайте ясни препоръки кое съдържание трябва да се пренесе на тестовия сайт:

• текстове от страници с раздели и категории;
• текстове от страници с оптимизирани филтри (ако ги има);
• контент от описанията на стоките: текстове-описания, отзиви, видео, характеристики;
• цялата информация от служебните страници, страници на статии, страници за услуги или блога.

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

Пример на таблица за пренос на текстове:

3.1.5. Файлове за верификация. Помолете програмистите да оставят файловете за верификация от Google и Яндекс в главната директория, за да може при пренасянето да не изгубите достъпите.

3.1.6. Синхронизация на информацията. На тестовия сайт често се качва текущата база с продуктите и не се обновява. Но преди Деня Х цялата информация на сайта трябва да се синхронизира. В това число цените на стоките (услугите), и статусите (налично в продажба или стоката не е налична).

3.1.7. Информация към другите специалисти. Задължително напишете в ТЗ, че програмистът или клиентът трябва да предупреди специалистите по реклама и социален маркетинг, че ще бъдат променени URL-ите и предстои миграция към нов CMS. Също така специалистите трябва да уточнят, какви кодове трябва да преместят на новия сайт.

3.1.8. Отделете в нова точка в техническото задание, че пренасянето трябва да се направи само след одобрение от отговориния SEO специалист.

3.2. Какво трябва да се направи след миграцията към нов CMS?

3.2.1. Настройка на системите за анализ. Бъдете готови за това, че всички настройки в системите за анализ ще се объркат след миграцията. Пристъпете към настройката на аналитичните инструменти на обновения сайт на последния стадий на готовност на сайта, когато за теста са достъпни всички форми, бутони, кошница.

Какво трябва да се предвиди в техническото задание за настройка на аналитиката:

• препоръки за внедряване на кодовете за проследяване (Google Analytics, Яндекс.Метрика или Google Tag Manager c вече внедрени кодове на системите за статистика);
• настройка на електронната търговия (за ecommerce проекти);
• настройка на проследяването на събития.

3.2.2. Настройка на robots.txt. Често настройките на robots.txt се пренасят от тестовия сайт. Резултат на това основният сайт се оказва затворен за индексиране. Опишете необходимите инструкции в robots.txt, за да може да ги внедрите оперативно след пренасянето.

3.2.3. Генерирайте Sitemap.xml. Файлът sitemap.xml също често се пренася директно от тестовия сайт, заедно с URL от тестовия сайт. На тази стъпка трябва да помолите програмиста да обнови файла, за да присъстват в него страниците от основния сайт. Също така трябва да се настрои автоматично обновяване на файла веднъж на денонощие (използвайте Cron).

3.2.4. Замяна на вътрешните линкове с актуални. Всички линкове (меню, линкове в текстовете, линкове в атрибутите next, prev, canonical) трябва да бъдат актуални, тоест да не са от тестовия сайт.

Освен това, след настройването на 301 редиректи, линковете в текстовете могат да дават вътрешен 301 редирект. След преноса им ще можете да ги изтеглите и изпратите на контент редактора за поправка.

3.2.5. Проверка на настройките на индексиране. Опишете основните настройки за индексиране, които трябва да бъдат проверени. Тази точка ще е ориентир и за Вас и за програмиста.

Обърнете внимание на настройките за индексиране на филтрите и техните припокривания, служебните страници.

4. Проверка и контрол след пренасянето на сайта

4.1. След прехода, на първо място проверявайте robots.txt и настройките на редиректите. Прегледайте дали не са затворени целевите страници с мета таг <meta name="robots" content="noindex, follow" />.

4.2. Проверете за наличие на мета информация на всяка страница - дали не са се появили дубли.

4.3. Проверете работата на всички форми и кошницата.

4.4. Вижте задължително дали са прехвърлени всички инструменти за уеб аналитика. След миграцията е много важно да продължава да се събира точна статистика за трафика.

4.5. Още веднъж направете мини-одит на сайта, за да разберете дали не са се появили нови критични грешки.

4.6. Обновете файловете sitemap.xml в профилите за уебмастери, за да могат ботовете на търсачките по-бързо да видят новите URL.

4.7. Наблюдавайте трафика и позициите. За определено време е възможно трафикът да падне с 10-20%, но ако всичко е направено правилно — той ще се възстанови в рамките на месец.

Изводи

Работата на SEO специалиста по време на миграция към нов CMS се състои от четири важни етапа:

• подготовка на необходимите технически задания за тестовия сайт;
• анализ на тестовия сайт и контрол на внедряванията;
• подготовка за пренос на сайта;
• проверка и контрол след миграцията.

Между другото всеки сайт си има свои особености, затова често стандартният чек-лист е недостатъчен. Той е само ориентир. При подготовка на техническото задание си заслужава да се отчетат особеностите на проекта и да се ръководим от здравия разум.

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