Технічне SEO після переїзду інтернет-магазину

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

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

Реєстр перевірки: з чим порівнювати

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

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

• Розмітьте типи. Категорії, товари, бренди, статті, фільтри й службові сторінки. Так під час перевірки видно, чи просіла ціла група, а не окрема сторінка.
• Відсортуйте за трафіком. Перевірка починається зі сторінок, які давали входи, а не з випадкового місця в списку.
• Дивіться на кожну групу окремо, а не загалом. Падіння цілої категорії товарів легко губиться за стабільним брендовим трафіком головної сторінки.
• Ведіть дату останньої перевірки. Через три тижні ніхто не пам’ятає, які рядки вже пройдено.
• Збережіть структуру навігації. Категорія, на яку більше не веде меню, залишається доступною, але отримує менше внутрішніх посилань і може просісти в пошуку.

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

Карта редиректів і ланцюжки

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

• Кожна стара адреса веде на точний еквівалент. Категорія на категорію, товар на товар, стаття на статтю.
• Ніяких ланцюжків. Пряме перенаправлення відповідає швидше, надійніше й точніше зіставляє адреси. Довгий ланцюжок додає затримку, витрачає обхід на проміжні кроки й ризикує обірватися посередині.
• Ніякого масового перенаправлення на головну. Перенаправлення на нерелевантну сторінку пошуковик може визнати прихованою помилкою і обробити як 404.
• Правила на рівні веб-сервера. Конфігурація сервера відповідає швидше за обробку всередині системи керування.

Якщо ви переїжджали із закритої платформи-конструктора, у неї свої особливості експорту: вони розібрані в матеріалі про те, як перейти з Хорошопа або Prom.

Метадані, заголовки й структура каталогу

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

Внутрішні посилання після запуску

Меню, блоки супутніх товарів, банери й посилання всередині статей часто продовжують вести на старі адреси. Технічно все працює, бо спрацьовує редирект. Насправді це три проблеми одразу.

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

Усі внутрішні посилання після релізу мають вести напряму на адреси, що віддають код 200.

Перевірка зовнішніх посилань після запуску

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

• Пройдіть список донорів вручну. Перейдіть за редиректом і перевірте вміст. Навіть технічно правильний редирект може вести на порожню категорію.
• Дивіться фінальний код, а не перший. Посилання може віддавати 301, який веде на другий 301, який веде на 404. У звіті це виглядає як робоче.
• Звіряйте з логами. Якщо за адресою з сильним посиланням досі приходять люди й отримують помилку, це видно в журналі того ж дня.

Мовні версії та hreflang

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

• Повний набір тегів на кожній сторінці. Включно з посиланням на саму себе, інакше зв’язка неповна.
• Версія за замовчуванням, якщо потрібна. Тег x-default підказує пошуку, яку сторінку показати, коли мова й регіон користувача не збігаються з жодною з мовних версій.
• Абсолютні кінцеві адреси. Вказуйте повні адреси, що віддають код 200, і робіть посилання взаємними. Якщо дві сторінки не посилаються одна на одну, Google ігнорує теги.

Карта сайту й robots.txt

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

• Тимчасова карта старих адрес. Файл зі старими адресами, що тепер віддають 301, допомагає пошуковику швидше їх виявити.
• Основна карта з новими адресами. Тільки канонічні, тільки з кодом 200, без редиректів усередині.
• Чистий robots.txt. З нового сервера прибирають усі заборони тестового середовища й закривають лише службові розділи: адмінку, кошик, оформлення замовлення і внутрішній пошук.
• Стилі й скрипти відкриті. Якщо їх закрити, робот не зможе оцінити, як сторінка виглядає насправді.

Регламент постійного контролю після запуску описаний окремо в матеріалі про те, що входить у підтримку сайту.

Канонізація адрес

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

• Єдиний протокол. Примусовий перехід на захищене з’єднання.
• Одне головне дзеркало. З www на без або навпаки, але однаково для всього сайту.
• Однаковий слеш на кінці. Альтернативний варіант віддає редирект, а не другу копію сторінки.
• Нижній регістр в адресах. Інакше та сама сторінка існує у двох написаннях.

Зняті з продажу товари

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

• Є сучасний аналог. Редирект на сторінку наступника, і покупець потрапляє туди, куди хотів.
• Товару немає, але трафік є. Сторінку залишають живою з чесним статусом і блоком посилань на схожі доступні позиції.
• Товару немає і не буде. Сервер віддає 404 або 410. Google обробляє обидва коди однаково й прибирає адресу з індексу.

Мікророзмітка

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

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

Окремо звірте ціну й статус наявності в розмітці з тим, що показано на сторінці. Розбіжність між ними пошуковик вважає помилкою і прибирає розширений сніпет цілком.

Повний склад полів для картки товару розібраний у матеріалі про блоки картки товару.

Швидкість після переїзду

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

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

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

Логи сервера й помилки в консолі

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

• Звернення з кодом 404. Розбирайте за джерелом і призначенням адреси. Якщо це стара сторінка з трафіком, карта редиректів неповна. Якщо товару немає і не буде, 404 або 410 і є правильною відповіддю.
• Серверні помилки на окремих розділах. Каталог може падати під навантаженням саме там, де його не тестували.
• Частота звернень за старими адресами. Показує, як швидко пошуковик склеює старе з новим.
• Глибина обходу нових карток. Якщо робот не доходить до товарів, справа зазвичай у структурі посилань, а не в ліміті.

Що вважати нормальним у перехідний період

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

Головні сторінки й категорії робот зазвичай бачить уже за кілька днів, а на те, щоб обійти весь каталог, оновити індекс і обробити всі переадресації, йому потрібно значно більше часу. Скільки це триватиме, залежить від кількості адрес і швидкості сайту. Google для сайтів середнього розміру називає орієнтир у кілька тижнів і більше, для великих довше, і коливання в цей період очікувані. А от різке падіння органічних входів це привід почати розслідування того ж дня, а не чекати, поки «само встоїться». Заздалегідь названої частки, нижче за яку можна не хвилюватися, не існує: дивіться на розмір падіння відносно власного звичайного рівня.

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

Коли завершувати посилений контроль

Щоденний режим можна знімати, коли це дозволяють показники.

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

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

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

Чек-лист приймання

Пройдіть його в день перемикання і повторіть через тиждень.

• Головна віддає 200. Разом із категоріями верхнього рівня та кількома картками товарів навмання.
• Десять старих адрес віддають 301. Причому різних типів: категорія, товар, фільтр, стаття.
• Жодного ланцюжка. Перехід зі старої адреси відбувається за один крок.
• Заборони індексації немає. Ні в метатегу, ні в robots.txt, ні в заголовку відповіді сервера.
• Карта сайту прийнята. Без помилок, тільки з канонічними адресами.
• Заголовки збіглися. Вибірково перевірені сторінки мають ті самі заголовки, що були.
• Розмітка валідна. Товар, ціна й наявність читаються без синтаксичних помилок.
• Події аналітики йдуть. Від перегляду картки до оплати, на тестовому замовленні.
• Внутрішніх редиректів немає. Меню і тексти ведуть напряму.
• Старий сайт живий. І його можна знову ввімкнути, якщо щось піде не так.

Скільки це коштує

Перевірка після переїзду це разова робота з планом: що саме зламалося, у якому порядку це виправляти. Вона йде як стартовий аудит, від $200.

Контроль позицій наступні місяці це вже щомісячне ведення, і для інтернет-магазину воно рахується за своїм тарифом, від $600/міс. Для магазину з кількома мовними версіями тариф вищий, від $900/міс. Ведення беремо мінімум на три місяці.

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

Висновки

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

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

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