Статьи

Перенесення сайту на нову CMS без втрати позицій і трафіку: як підготувати ТЗ програмісту - Netpeak Blog

  1. Перенесення сайту на нову CMS без втрати позицій і трафіку: як підготувати ТЗ програмісту Часто онлайн-проект...
  2. 2. Аналіз тестового сайту і контроль впроваджень
  3. 3. Підготовка техзавдання для перенесення сайту
  4. 3.1. Що потрібно зробити до переїзду на нову CMS?
  5. 3.2. Що потрібно зробити після переїзду на нову CMS?
  6. 4. Перевірка та контроль після перенесення сайту
  7. висновки
  8. Перенесення сайту на нову CMS без втрати позицій і трафіку: як підготувати ТЗ програмісту
  9. 1. Підготовка технічних завдань для впровадження на тестовому сайті
  10. 2. Аналіз тестового сайту і контроль впроваджень
  11. 3. Підготовка техзавдання для перенесення сайту
  12. 3.1. Що потрібно зробити до переїзду на нову CMS?
  13. 3.2. Що потрібно зробити після переїзду на нову CMS?
  14. 4. Перевірка та контроль після перенесення сайту
  15. висновки
  16. Перенесення сайту на нову CMS без втрати позицій і трафіку: як підготувати ТЗ програмісту
  17. 1. Підготовка технічних завдань для впровадження на тестовому сайті
  18. 2. Аналіз тестового сайту і контроль впроваджень
  19. 3. Підготовка техзавдання для перенесення сайту
  20. 3.1. Що потрібно зробити до переїзду на нову CMS?
  21. 3.2. Що потрібно зробити після переїзду на нову CMS?
  22. 4. Перевірка та контроль після перенесення сайту
  23. висновки

Перенесення сайту на нову 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 (а це, швидше за все, було, якщо з сайтом працювали), на старому сайті вже є своя таблиця редиректів. Потрібно попросити програмістів перенести її на тестовий сайт.

Чому це важливо? Про цю таблиці часто забувають і налаштовують редирект тільки з відображуваних сторінок старого сайту.

Ось так:

http://site.com/old-url → 301 → http://site.com/new-url

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

http://site.com/old-old-url → 404

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

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

Як це зробити?

3.1.2.1. Вивантажити з Google Analytics сторінки, які дають найбільше трафіку за рік-два. Для цього потрібно зайти в звіт «Канали - Organic Search», вибрати потрібні дати і основний параметр - «Сторінка входу». Далі - вибрати відображення 500-1000 рядків на сторінці та натиснути «Експортувати».

3.1.2.2. Вивантажити з Ahrefs сторінки, на які розміщені зовнішні посилання. Для цього потрібно зайти в сервіс, ввести домен сайту і вибрати «Export».

У таблиці нас цікавить тільки стовпець «Link URL», тобто ті сторінки нашого сайту, на які посилаються зовнішні ресурси.

У таблиці нас цікавить тільки стовпець «Link URL», тобто ті сторінки нашого сайту, на які посилаються зовнішні ресурси

3.1.2.3. Об'єднати дві таблиці і видалити дублі сторінок (можна використовувати Notepad ++ з додатковим розширенням TextFX):

Об'єднати дві таблиці і видалити дублі сторінок (можна використовувати Notepad ++ з додатковим розширенням TextFX):

3.1.2.4. Список всіх URL потрібно звести в окрему таблицю і пробити коди відповідей сторінок, щоб розуміти, які сторінки доступні зараз.

Список всіх URL потрібно звести в окрему таблицю і пробити коди відповідей сторінок, щоб розуміти, які сторінки доступні зараз

Пробивання можна здійснити за допомогою Netpeak Cheсker.

Якщо таблиця редиректів старого сайту буде перенесена коректно, на тестовому сайті все вивантажені раніше сторінки будуть віддавати 301 код відповіді:

http://test-site.com/old-old-url → 301 → http://test-site.com/old-url → 301 → http://test-site.com/new-url

Щоб перевірити код відповіді і коректність налаштування редиректів, досить змінити домен основного сайту на тестовий і прочекав URL в Netpeak Checker з включеними параметрами Status Code і Redirects. Також варто пройтися по ланцюжку редиректу - код відповіді може бути 301, але редирект налаштований на головну сторінку.

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

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

Як скласти таблицю редиректів?

  1. Вивантажити все цільові URL зі старого сайту за допомогою Netpeak Spider .
  2. Зіставити їх з аналогічними URL на новому сайті.
  3. Якщо немає аналогічних сторінок на новому сайті - редирект налаштовувати не потрібно, потрібно віддавати код відповіді - 404.

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

Приклад таблиці редиректів:

Приклад таблиці редиректів:

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

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

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

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

Як би ви не налаштовували 301 редіректи - все URL cо старого сайту зберігайте в таблицях перед переносом. Так ви завжди зможете оперативно перевірити коди відповідей. Також це буде ваш бекап (про всяк випадок).

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. Налаштування систем аналітики. Будьте готові, що все настройки аналітики зіб'ються після перенесення. Приступайте до налаштування аналітики оновленого сайту на останній стадії готовності сайту, коли для тесту доступні всі форми, кнопки, кошик.

Що потрібно передбачити в технічному завданні з налаштування аналітики:

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

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

Якщо після прочитання статті у вас залишилися складності з перенесенням сайту на нову CMS, відправляйте заявку і наші SEO-фахівці допоможуть вам.

Перенесення сайту на нову 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 (а це, швидше за все, було, якщо з сайтом працювали), на старому сайті вже є своя таблиця редиректів. Потрібно попросити програмістів перенести її на тестовий сайт.

Чому це важливо? Про цю таблиці часто забувають і налаштовують редирект тільки з відображуваних сторінок старого сайту.

Ось так:

http://site.com/old-url → 301 → http://site.com/new-url

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

http://site.com/old-old-url → 404

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

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

Як це зробити?

3.1.2.1. Вивантажити з Google Analytics сторінки, які дають найбільше трафіку за рік-два. Для цього потрібно зайти в звіт «Канали - Organic Search», вибрати потрібні дати і основний параметр - «Сторінка входу». Далі - вибрати відображення 500-1000 рядків на сторінці та натиснути «Експортувати».

3.1.2.2. Вивантажити з Ahrefs сторінки, на які розміщені зовнішні посилання. Для цього потрібно зайти в сервіс, ввести домен сайту і вибрати «Export».

У таблиці нас цікавить тільки стовпець «Link URL», тобто ті сторінки нашого сайту, на які посилаються зовнішні ресурси.

У таблиці нас цікавить тільки стовпець «Link URL», тобто ті сторінки нашого сайту, на які посилаються зовнішні ресурси

3.1.2.3. Об'єднати дві таблиці і видалити дублі сторінок (можна використовувати Notepad ++ з додатковим розширенням TextFX):

Об'єднати дві таблиці і видалити дублі сторінок (можна використовувати Notepad ++ з додатковим розширенням TextFX):

3.1.2.4. Список всіх URL потрібно звести в окрему таблицю і пробити коди відповідей сторінок, щоб розуміти, які сторінки доступні зараз.

Список всіх URL потрібно звести в окрему таблицю і пробити коди відповідей сторінок, щоб розуміти, які сторінки доступні зараз

Пробивання можна здійснити за допомогою Netpeak Cheсker.

Якщо таблиця редиректів старого сайту буде перенесена коректно, на тестовому сайті все вивантажені раніше сторінки будуть віддавати 301 код відповіді:

http://test-site.com/old-old-url → 301 → http://test-site.com/old-url → 301 → http://test-site.com/new-url

Щоб перевірити код відповіді і коректність налаштування редиректів, досить змінити домен основного сайту на тестовий і прочекав URL в Netpeak Checker з включеними параметрами Status Code і Redirects. Також варто пройтися по ланцюжку редиректу - код відповіді може бути 301, але редирект налаштований на головну сторінку.

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

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

Як скласти таблицю редиректів?

  1. Вивантажити все цільові URL зі старого сайту за допомогою Netpeak Spider .
  2. Зіставити їх з аналогічними URL на новому сайті.
  3. Якщо немає аналогічних сторінок на новому сайті - редирект налаштовувати не потрібно, потрібно віддавати код відповіді - 404.

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

Приклад таблиці редиректів:

Приклад таблиці редиректів:

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

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

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

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

Як би ви не налаштовували 301 редіректи - все URL cо старого сайту зберігайте в таблицях перед переносом. Так ви завжди зможете оперативно перевірити коди відповідей. Також це буде ваш бекап (про всяк випадок).

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. Налаштування систем аналітики. Будьте готові, що все настройки аналітики зіб'ються після перенесення. Приступайте до налаштування аналітики оновленого сайту на останній стадії готовності сайту, коли для тесту доступні всі форми, кнопки, кошик.

Що потрібно передбачити в технічному завданні з налаштування аналітики:

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

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

Якщо після прочитання статті у вас залишилися складності з перенесенням сайту на нову CMS, відправляйте заявку і наші SEO-фахівці допоможуть вам.

Перенесення сайту на нову 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 (а це, швидше за все, було, якщо з сайтом працювали), на старому сайті вже є своя таблиця редиректів. Потрібно попросити програмістів перенести її на тестовий сайт.

Чому це важливо? Про цю таблиці часто забувають і налаштовують редирект тільки з відображуваних сторінок старого сайту.

Ось так:

http://site.com/old-url → 301 → http://site.com/new-url

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

http://site.com/old-old-url → 404

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

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

Як це зробити?

3.1.2.1. Вивантажити з Google Analytics сторінки, які дають найбільше трафіку за рік-два. Для цього потрібно зайти в звіт «Канали - Organic Search», вибрати потрібні дати і основний параметр - «Сторінка входу». Далі - вибрати відображення 500-1000 рядків на сторінці та натиснути «Експортувати».

3.1.2.2. Вивантажити з Ahrefs сторінки, на які розміщені зовнішні посилання. Для цього потрібно зайти в сервіс, ввести домен сайту і вибрати «Export».

У таблиці нас цікавить тільки стовпець «Link URL», тобто ті сторінки нашого сайту, на які посилаються зовнішні ресурси.

У таблиці нас цікавить тільки стовпець «Link URL», тобто ті сторінки нашого сайту, на які посилаються зовнішні ресурси

3.1.2.3. Об'єднати дві таблиці і видалити дублі сторінок (можна використовувати Notepad ++ з додатковим розширенням TextFX):

Об'єднати дві таблиці і видалити дублі сторінок (можна використовувати Notepad ++ з додатковим розширенням TextFX):

3.1.2.4. Список всіх URL потрібно звести в окрему таблицю і пробити коди відповідей сторінок, щоб розуміти, які сторінки доступні зараз.

Список всіх URL потрібно звести в окрему таблицю і пробити коди відповідей сторінок, щоб розуміти, які сторінки доступні зараз

Пробивання можна здійснити за допомогою Netpeak Cheсker.

Якщо таблиця редиректів старого сайту буде перенесена коректно, на тестовому сайті все вивантажені раніше сторінки будуть віддавати 301 код відповіді:

http://test-site.com/old-old-url → 301 → http://test-site.com/old-url → 301 → http://test-site.com/new-url

Щоб перевірити код відповіді і коректність налаштування редиректів, досить змінити домен основного сайту на тестовий і прочекав URL в Netpeak Checker з включеними параметрами Status Code і Redirects. Також варто пройтися по ланцюжку редиректу - код відповіді може бути 301, але редирект налаштований на головну сторінку.

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

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

Як скласти таблицю редиректів?

  1. Вивантажити все цільові URL зі старого сайту за допомогою Netpeak Spider .
  2. Зіставити їх з аналогічними URL на новому сайті.
  3. Якщо немає аналогічних сторінок на новому сайті - редирект налаштовувати не потрібно, потрібно віддавати код відповіді - 404.

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

Приклад таблиці редиректів:

Приклад таблиці редиректів:

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

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

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

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

Як би ви не налаштовували 301 редіректи - все URL cо старого сайту зберігайте в таблицях перед переносом. Так ви завжди зможете оперативно перевірити коди відповідей. Також це буде ваш бекап (про всяк випадок).

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. Налаштування систем аналітики. Будьте готові, що все настройки аналітики зіб'ються після перенесення. Приступайте до налаштування аналітики оновленого сайту на останній стадії готовності сайту, коли для тесту доступні всі форми, кнопки, кошик.

Що потрібно передбачити в технічному завданні з налаштування аналітики:

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

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

Якщо після прочитання статті у вас залишилися складності з перенесенням сайту на нову CMS, відправляйте заявку і наші SEO-фахівці допоможуть вам.

3.1. Що потрібно зробити до переїзду на нову CMS?
3.2. Що потрібно зробити після переїзду на нову CMS?
3.1. Що потрібно зробити до переїзду на нову CMS?
3.2. Що потрібно зробити після переїзду на нову CMS?
3.1. Що потрібно зробити до переїзду на нову CMS?
3.2. Що потрібно зробити після переїзду на нову CMS?
Але як проконтролювати всі нюанси, щоб сайт не втратила позиції і трафік після переїзду?
Не подобається структура старого сайту?
Чи не могли раніше впровадити або оптимізувати сторінки фільтрів?
Не було адаптивної версії сайту?

Новости