Чек-лист міграції сайту: від за 4 тижні до 45-го дня
Зміна домену, перенесення платформи, зміна хостингу або нова схема URL: посилання, що ведуть на ваш сайт, не мають значення, який саме з цих варіантів обрано. Цей список допоможе вам зафіксувати необхідне до запуску та перевірити після нього.
Команда досліджень ArchiLinks ·
Наша позиція
Більшість втрат під час міграції виникають через відсутність редиректів, а не через тип редиректу
Команди годинами сперечаються щодо 301 проти 302, а потім запускаються з 3000 URL зовнішніх посилань, які повертають 404. Знайдіть усі зворотні посилання на веб-сайт, перш ніж приймати будь-які інші рішення, оскільки цей список покаже, де знаходяться ризики.
- Збирайте сторінки, що містять посилання, за 4 тижні, а не в ніч перед запуском.
- Кожен URL із зовнішнім посиланням потребує однокрокового редиректу 301 на відповідну сторінку.
- Залишайте редиректи активними щонайменше на рік, оскільки старі посилання часто існують довше за сторінки, на які вони колись вели.
Хронологія
За 4 тижні: інвентаризація
Прокрибуйте старий сайт, експортуйте звіт про продуктивність із Search Console та запустіть toppages та refdomains для старого хостингу. Збережіть три файли разом із датою.
За 3 тижні: мапування
Спочатку створіть карту редиректів із посилальних сторінок, потім — на основі трафіку, і нарешті — на основі краулингу. Рецепт карти редиректів містить скрипт ранжування.
За 2 тижні: тестування на staging
Протестуйте кожен старий URL на staging-середовищі та переконайтеся, що це один крок, статус 301 і 200 у кінці. Зупиніть збірку при наявності ланцюжка або циклу.
День 0: запуск
Опублікуйте редиректи, нову карту сайту, оновлені теги canonical та внутрішні посилання в одному релізі. Надішліть нову карту сайту в Search Console. Для зміни домену скористайтеся інструментом «Зміна адреси».
За 1 тиждень: логи та покриття
Перевірте логи сервера на наявність запитів Googlebot до старих URL, а потім звіт «Сторінки» на наявність сплесків 404 або м’яких 404. Виправте карту; не чекайте.
За 30–45 днів: порівняння посилань
Після щомісячного оновлення витягніть refdomains для нового хостингу та порівняйте їх із старим файлом. Різниця, що перевищує кілька відсотків, потребує уваги.
Що змінюється залежно від типу перенесення
| Перенесення | Редиректи | Додаткові перевірки | Фокус на даних посилань |
|---|---|---|---|
| Новий домен | Редирект 301 на рівні хостингу, на рівні шляху там, де шляхи змінюються | Інструмент «Зміна адреси», старий домен зберігається щонайменше 12 місяців | Посилальні домени, що поступово переходять на новий хостинг |
| HTTP на HTTPS або зміна www | Редирект 301 на рівні хостингу | Canonical, HSTS, змішаний контент | Малі відмінності; підтвердіть, що обидва хостинги resolving до одного |
| Перенесення платформи, той самий домен | Карта на рівні шляху | Пагінація, параметри, слеші в кінці | Найбільш посилані сторінки, які змінили шлях |
| Піддомен у підпапку (або навпаки) | Карта на рівні шляху, правила на рівні хостингу | Cookies, robots.txt на рівні хостингу, аналітика | Чи ведуть посилання на старий хостинг чи на новий |
| Об’єднання двох сайтів | Багато до одного мапування | Дублювання контенту, вибір canonical | Перетин посилальних доменів через intersect |
Чек-лист дня запуску
- Старі URL повертають 301 за один крок, що перевіряється скриптом, а не вручну.
- Новий хостинг повертає 200 із самореферентним canonical на кожному шаблоні.
- robots.txt на новому хостингу не містить правил для staging. Залишений Disallow: / — це класична помилка дня запуску.
- XML карта сайту містить лише 200, індексовані, canonical URL.
- Внутрішні посилання, навігація та структуровані дані вказують на нові URL, а не на редиректовані.
- Властивості Analytics та Search Console для нового хостингу існують до перемикання.
- Базові JSON-файли зафіксовані з датою в назві кожного файлу.
Наш граф посилань оновлюється приблизно раз на місяць. Посилання, створене в тиждень вашого запуску, може не відобразитися при витягуванні на 30-й день. Використовуйте звіт «Посилання» в Search Console для фінального кроку та оцінюйте різницю після другого оновлення. Ці дані також живлять огляд внутрішнього та зовнішнього equity після запуску, а hreflang регіональні домени охоплюють випадок для кількох країн.
Редирект 301, що закінчується 404, нічого не зберігає
Деякі команди пересилають кожен старий URL на новий головний розділ і дозволяють цільовим сторінкам згодом зникнути. Сам редирект працює. Саме тому ця звичка є ризикованою, оскільки кожен крок виглядає чистим у логах, тоді як сторінка в кінці відповідає 404.
Уявіть, що ви переносите магазин на новий домен і залишаєте лише товари, які ще продаються. Сторінки категорій, які утримували більшість зовнішніх посилань, тепер ведуть нікуди. Порахуйте URL із зовнішніми посиланнями, перш ніж прибирати що-небудь. Зробіть це першим кроком. Сторінка з посилальними доменами потребує активного цільового ресурсу на ту ж тему, а не просто «не знаю».
Тримайте правило коротким: один крок, потім фінальний 200. Усе інше — витік, який ви обрали.
Що захищає однокроковий редирект 301 на активну сторінку
Цінність посилання знаходиться на URL, на який воно веде. Редирект передає цю цінність лише якщо адреса, на яку він веде, відповідає та все ще відповідає темі. Товар, переміщений на той самий товар у новому каталозі, проходить цей тест, тоді як товар, відправлений на головну сторінку, зазвичай ні, навіть якщо саме на неї всі посилалися.
Перевіряйте фінальний статус після кожної зміни шаблону. Редирект, який працював під час запуску, може закінчуватися 404 після пізнішого релізу, коли хтось видаляє категорію під час оновлення меню.
Коли 410 є чесною відповіддю
Деякі старі URL не мали посилань, відвідувань чи реальної заміни. Для них чітке 404 або 410 є більш чесним, ніж редирект на сторінку, яка не відповідає на запитання, яке ставило старе. Редирект на нерелевантну сторінку часто сприймається як м’який 404, тому він нічого не зберігає.
Запишіть рішення для кожної групи URL із зазначенням причини. Папка архівованих туторіалів отримає іншу відповідь, ніж папка сторінок із вісьмома посилальними доменами, і вам захочеться пояснити цю різницю колезі через півроку.
Перевірка останнього кроку, а не лише першого
Більшість тестів редиректів зупиняються на першій відповіді, що є неправильним місцем для зупинки. Прокладіть ланцюжок до кінця, а потім запишіть кількість кроків та фінальний статус поруч із старим URL. Ланцюжок із двох кроків не є зламаним, але він додає затримку та ще одну точку, де правило може відмовити.
Якщо скрипт недоступний, таблиця та кілька викликів curl виконають роботу. На сторінці API-скриптів є версія, яку можна налаштувати на графік.
Карти сайту та ручні запити після запуску
Залишайте стару карту сайту доступною кілька тижнів після перенесення. Краулери, які знову відвідають старий хостинг, зможуть знайти ці адреси в одному списку, що прискорить їхній перший прохід через редиректи.
Ручні запити — це інший інструмент. Використовуйте їх для кількох найважливіших сторінок, а не для сотень URL, поданих по одній. Запитувана сторінка без внутрішніх посилань та тонким контентом схильна знову зникнути, тому запит такий же ефективний, як і сторінка за ним.
Очікування — це дійсний план. Дайте час на краулінг, а потім оцініть його на основі даних.
Залишення старої карти сайту в списку на певний час
Залишайте стару карту сайту в Search Console, доки старі URL не перестануть з’являтися в статистиці краулінгу. Тоді навмисно видаліть її та запишіть дату в журналі міграції.
Не видаляйте її в день запуску просто для того, щоб властивість виглядала охайно. Раннє видалення приховує той єдиний список, який містить усі старі URL, які вам все ще потрібно відстежувати.
Запит індексації для сторінок, що містять посилання
Оберіть двадцять нових URL із найбільшою кількістю зовнішніх посилань, використовуючи той самий join, який ви створили для карти редиректів, і подайте їх вручну. Зусилля тоді слідуватимуть за ризиком, а не за розміром сайту.
Якщо запитувана сторінка досі відсутня через кілька тижнів, подивіться на сторінку, перш ніж просити знову. Перевірте її внутрішні посилання, canonical та контент. П’ятий запит нічого не змінить.
Як довго потрібно чекати, щоб оцінити перенесення
Оцінюйте перенесення за другим витягуванням посилань, а не першим. Наш індекс оновлюється приблизно раз на місяць, тому витягування на третій день переважно показує картину минулого місяця. Запустіть друге витягування після оновлення та використовуйте його, щоб знайти всі зворотні посилання на веб-сайт на новому хостингу.
Звіт «Сторінки» та дані посилань відповідають на різні запитання. Читайте їх поруч, а не як суперечливі вердикти щодо одного перенесення.
П’ять перевірок перед тим, як staging-сайт стане доступним
Тримайте staging поза індексом
Поставте пароль або allow-list перед staging. Правило robots.txt саме по собі не зупинить пошукові системи від індексації URL, які вони вже знають із посилань.
Перевірте налаштування noindex та canonical
Відкрийте шаблон та налаштування CMS і шукайте прапорець noindex або canonical, який вказує на інший URL. У WordPress налаштування видимості для пошукових систем — це те, що люди забувають після копіювання сайту зі staging.
Замініть файл robots для staging
Отримайте live robots.txt після перемикання та порівняйте його з файлом, який ви планували опублікувати. Правила staging, що потрапили в продакшн, можуть заблокувати краулерів на всьому хостингу.
Запустіть тест кроків на live-хостингу
Staging доводить, що карта працює на копії. Запустіть тест одного кроку знову на реальному домені після змін DNS, оскільки кеш CDN або правило хостингу можуть поводитися інакше там.
Тримайте старий хостинг активним
Залишайте старий домен, що обслуговує редиректи, стільки, скільки його URL все ще отримують посилання або відвідування. Внесіть дату поновлення в календар, перш ніж хтось забуде про існування домену.
Спостереження за сайтом після запуску, а не лише до нього
Аудит до запуску фіксує стан на день його проведення. Більшість пошкоджень під час запуску проявляються пізніше, після оновлення плагіна, зміни правила CDN або шаблону, який торкається налаштування, ніким не переглянутого.
Підходьте до післязапускового спостереження як до набору невеликих diff-змін проти збереженого базового рівня. Панель керування не потрібна. Достатньо розкладу та папки з файлами з датами.
Що має порівнювати тижневе спостереження
Оберіть перевірки, які найбільше постраждають, якщо вони зміняться, і запускайте їх одного дня щотижня.
- Код стану та фінальний URL для топ-50 старих URL із посиланнями
- robots.txt та мета-тег robots на основних шаблонах
- Кількість активних 200 URL проти кількості в новій карті сайту
- Теги canonical на головній сторінці, одній категорії та одній статті
Чому разовий аудит пропускає повільне дрейфування
Налаштування дрейфують після запуску. Залишений прапорець тестування, плагін, що переписує permalinks, або редирект, доданий для виправлення однієї сторінки, можуть скасувати частину плану. Аудит, проведений в день запуску, не бачить жодного з них.
Запланований diff може. Зберігайте базові файли в системі контролю версій і порівнюйте результати кожного тижня з ними, щоб несподівана зміна була помітна в день її виникнення.
Піддомени, видалення та зміни домену всього сайту
Деякі команди переносять розділ на піддомен і індексують лише його популярні сторінки. Це може спрацювати. Ціна в тому, що посилання, спрямовані на тихі сторінки, тепер потрапляють на хостинг з меншою історією, тому порахуйте їх, перш ніж щось вирізати.
Запити на видалення вузькіші, ніж здається. Search Console застосовує видалення до властивості, де ви його подали, тому запит, поданий на піддомені, не діє на основний домен. Спочатку перевірте властивість. Потім подайте запит і збережіть обидві перевірки.
Індексація лише популярних сторінок на піддомені
Почніть з кількості посилань на URL у цьому розділі. Сторінки, що містять зовнішні посилання, але малий трафік, є першими, які правило «лише популярні сторінки» приховає. Залиште їх доступними для краулінгу або перенаправте кожну на найближчу популярну сторінку та запишіть причину поруч із правилом.
Те, як основний сайт посилається на піддомен, вирішує, наскільки легко знайти його сторінки. Перелічіть ці посилання, перш ніж обирати, які сторінки залишаться прихованими, оскільки сторінку, на яку основний сайт ніколи не посилається, важко знайти будь-яким шляхом.
Зміна домену всього сайту, сторінка за сторінкою
Правило на рівні хостингу обробляє корінь, але зміна домену також потребує карти на рівні шляху. Коли перша частина URL змінюється, а slug залишається тим самим, заміна хостингу покриває більшість сторінок, а винятки потребують власних рядків.
Створіть список із посилальних сторінок спочатку, а потім зіставте кожен старий шлях із новим. Рецепт карти редиректів показує, як відранжувати цей список за посиланнями.
