Аналіз змін посилань під час перенесення сайту

Створіть карту редиректів до запуску

Карта редиректів — це частина перенесення, яку часто недооцінюють. Найважливіше — це кінцеві адреси. Перед аналізом даних посилань після перенесення старі URL-адреси мають чітку адресу призначення, адже саме на ці адреси вже вказують посилання.

Поелементне перенаправлення краще, ніж скидання на головну сторінку

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

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

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

Спростіть ланцюжки до запуску

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

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

Зберігайте робочі шляхи

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

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

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

Чого очікувати після перенесення

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

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

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

Hreflang та канонічні посилання також потребують уваги. Нечіткість поширена. Наприклад, після міграції CRA на Next.js сайти часто отримують канонічні теги, які суперечать їхнім наборам hreflang, а посилання розділяються між двома версіями сторінки.

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

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

Спостерігайте за тим, що переміщується без оголошення про запуск

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

Noindex, який переноситься зі збіркою staging

Копія staging, яка була виключена з пошуку, може перенести свої налаштування на робочий сайт. Перевірте мета-теги robots та будь-який заголовок noindex при першому краулінгу та виберіть вибірку сторінок з кожного розділу, а не лише з головної сторінки. Вибірка кожного розділу.

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

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

Фрагментні посилання, які індексуються

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

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

Перевірте звіт про покриття після запуску на наявність URL-адрес із хешем, бо саме вони тихо множаться. Хеші — це винуватці.

Піддомен, який стає головним доменом

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

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

Посилання do-follow, які здаються зниклими

Після редизайну рядки do-follow в інструменті можуть різко впасти, і перша думка — що посилання зникли. Порівняйте старі топ-сторінки з новими, перш ніж прийняти цю думку, а потім перевірте, чи правильно кожна стара адреса тепер перенаправляє. Перевірте, перш ніж панікувати.

Виправте це першим. Посилання, яке все ще існує на сторінці-джерелі, але вказує на мертвою адресу, — це випадок, який потрібно виправити першим.

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

Співпраця з розробником під час перенесення

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

Надайте розробнику карту, а не список завдань

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

Плани тестування першими. Запитайте короткий план тестування, який починається зі старих адрес із файлу топ-сторінок.

Узгодьте, хто читає щомісячний файл

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

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

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

Заплануйте відкат до запуску

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

Запишіть відкат. Відкат, який існує лише в голові однієї людини, — це не план.