Міграція сайту: найпоширеніші помилки! - Семальт попереджає



Привіт! У сьогоднішній статті Семальт збирається розповісти вам про найпоширеніші помилки, допущені під час перенесення веб-сайту. При 90% міграції веб-сайтів часто з’являється принаймні одна з помилок, про які я вам сьогодні розповім. На жаль, також буває так, що навіть найменша помилка може коштувати нам втрати трафіку та зменшення видимості.

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

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

Типи міграції

CMS-CMS

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

І ось ви насправді розглядаєте можливість змінити систему управління вмістом на іншу систему управління вмістом. У цьому випадку міграція дає вам багато переваг. Ви можете обробляти більше запитів, ви можете інтегруватися із системами, наприклад для оптових торговців, завдяки яким ваш бізнес зростає, а система управління вмістом просто полегшує вам роботу.

Домен-домен

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

Іноді трапляється також, що якщо, наприклад, у нас є домен, який якось постраждав (наприклад, до нього застосовано фільтр), і ми знаємо, що тут нічого не вдається досягти, тоді ми також розглядаємо можливість зміни домену. Тоді ми маємо справу з міграцією домену в інший домен.

Змінити сторону

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

З цієї причини ми повинні пам’ятати про певні правила, які не дозволять нам втратити те, що ми вже здобули. Ймовірно, ми передусім пов’язуємо міграцію з переспрямуваннями. Отже, якщо ви зробите будь-яку з міграцій, можливо, хтось скаже вам "запам'ятайте, зробіть перенаправлення". І це правда, звичайно, перенаправлення важливі, але є також багато інших елементів, які впливають на те, чи буде міграція успішною чи ні.

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

Версія для розробки

Noindex Nofollow

Якщо ми працюємо над новою версією веб-сайту, ми зазвичай маємо справу з версією для розробки. Отже, це сторінка, яка не повинна бути доступною як для користувачів, так і для пошукових систем, і має бути позначена параметрами Noindex Nofollow. Завдяки цьому методу ми не дозволяємо індексувати наш веб-сайт, і ми можемо вільно над ним працювати.

Це особливо важливо, якщо, наприклад, ми переносимо вміст зі старої сторінки на нову, оскільки Google, потрапивши на нашу сторінку розробки, почне її індексувати. Отже, індекс пошукових систем включатиме вміст як нової, так і старої сторінки - тоді нам доведеться мати справу з дублюванням.

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

SEO співпраця

У випадку з версією для розробки також важливо, що, наприклад, якщо SEO-компанія, з якою ви співпрацюєте, має до неї доступ, вона також може вільно над нею працювати, передавати її та допомагати вам у міграції. Якщо його немає, і ми працюємо над живим організмом, це набагато складніше завдання.

Міграція

Перемістіть весь вміст

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

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

Перенаправлення

Адресна карта

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

Переспрямуйте всі підсторінки

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

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

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

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

301, а не 302

Після того, як ми створимо всі переспрямування, ми повинні пам’ятати, що ці перенаправлення мають бути постійними переспрямуваннями, тобто 301 переспрямуванням. Перенаправлення 302, які також часто виконуються, є тимчасовими переспрямуваннями - вони не передаватимуть потужність тим підсторінкам, про які я розповідав вам раніше.

Аналітика

Якщо ми відкриваємо нову сторінку, ми також повинні переконатися, що на нашому веб-сайті є коди Google Analytics та Google Search Console. Завдяки цьому ми зможемо спостерігати, що відбувається на нашому веб-сайті та як він поводиться.

Повторна індексація

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

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

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

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

mass gmail