Чекліст міграції сайту (Excel)

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

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

6 готових варіантів

Аркуш налаштувань і легенди

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

Мета: узгодити словник один раз, щоб кожен рядок на кожному аркуші означав те саме.

Заповніть довідкові клітинки

  • Старий домен: [old-domain.com]
  • Новий домен: [new-domain.com]
  • Запланована дата запуску: [Дата]
  • Значення статусу: Не почато / Зіставлено / Редирект створено / Перевірено / Помилка
  • Типи редиректів: 301 постійний / 302 тимчасовий / Canonical / Без редиректу (збережено)
  • Відповідальні: [Розробник], [SEO], [Контент]

Налаштуйте це

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

Аркуш зіставлення URL

Основний трекер: один рядок на кожен старий URL, зіставлений із його новим призначенням.

Мета: зіставити кожен старий URL рівно з одним новим URL, з відповідальним і статусом, щоб на запуску ніщо не лишилося без пари.

Стовпці (A–H)

  • A – Старий URL: [вставте з повного сканування]
  • B – Новий URL: [URL призначення]
  • C – Тип сторінки: [Товар / блог / категорія / лендинг]
  • D – Тип редиректу: [301 / 302 / Canonical / Немає]
  • E – Статус: [Не почато / Зіставлено / Перевірено]
  • F – Відповідальний: [Ім'я]
  • G – Пріоритет: [Високий / Середній / Низький]
  • H – Перевірено?: [Т/Н]

Правила для аркуша

  1. Кожен старий URL зі сканування отримує рядок; жодних порожніх клітинок у стовпцях A чи B.
  2. Позначайте як високопріоритетні рядки зі сторінками, що мають трафік, позиції чи зворотні посилання.
  3. Використовуйте =COUNTIF(B:B,B2)>1, щоб виявити два старі URL, які помилково ведуть на один новий.

Аркуш правил редиректів

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

Мета: передати розробникам однозначний список редиректів «джерело → ціль» без циклів і ланцюжків.

Стовпці (A–E)

  • A – Шлях джерела: [/old-path]
  • B – Шлях цілі: [/new-path]
  • C – Тип редиректу: [301]
  • D – Впроваджено?: [Т/Н]
  • E – Примітки: [Крайні випадки, параметри]

Перевірки перед передачею

  1. Переконайтеся, що жоден шлях цілі не з'являється також як шлях джерела (це ланцюжок редиректів).
  2. Переконайтеся, що жоден шлях джерела не дорівнює власній цілі (це цикл).
  3. Групуйте правила зі спільним патерном, щоб їх можна було обробити одним правилом, де це можливо.
  4. Позначайте крайні випадки з параметрами та кінцевим слешем у Примітках, щоб їх не пропустили.

Аркуш перевірки кодів стану

Фіксуйте живу HTTP-відповідь для кожного URL до й після запуску.

Мета: перевірити, що кожен старий URL повертає очікуваний редирект, а кожен новий URL повертає 200.

Стовпці (A–F)

  • A – Старий URL: [URL]
  • B – Очікуваний код: [301]
  • C – Фактичний код (стейджинг до запуску): [код]
  • D – Фактичний код (після запуску): [код]
  • E – Кінцевий URL після редиректу: [кінцевий URL]
  • F – Пройдено/Помилка: =IF(D2=B2,"Pass","Fail")

Як це запустити

  1. Проскануйте список старих URL і вставте коди відповіді у стовпці C і D.
  2. Стежте за 302 там, де ви очікували 301, і за редиректами, що приземляються на 404.
  3. Відфільтруйте стовпець F за «Fail», щоб миттєво отримати список виправлень для відповідального розробника.

Аркуш метаданих і паритету контенту

Підтвердьте, що заголовки, мета, підзаголовки й canonical перенесено на нові URL.

Мета: переконатися, що нові сторінки зберегли сигнали на сторінці, які заробили старим сторінкам їхні позиції.

Стовпці (A–G)

  • A – Новий URL: [URL]
  • B – Title наявний і правильний?: [Т/Н]
  • C – Meta-опис наявний?: [Т/Н]
  • D – H1 відповідає інтенту?: [Т/Н]
  • E – Canonical правильний?: [Т/Н]
  • F – Внутрішні посилання оновлено?: [Т/Н]
  • G – Паритет контенту: [Повний / Частковий / Відсутній]

Порядок пріоритетів

  1. Спершу перевіряйте рядки з високим трафіком і зворотними посиланнями з аркуша зіставлення.
  2. Позначайте будь-яку сторінку, де контент скоротили під час переїзду; втрачений контент може коштувати позицій.
  3. Переконайтеся, що canonical вказують на новий URL, а не на виведений старий.

Аркуш дашборда прогресу

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

Мета: бачити завершеність з першого погляду й довести готовність до й після запуску.

Метрики для розрахунку

  • Усього URL: =COUNTA('URL Mapping'!A:A)-1
  • % зіставлено: =COUNTIF('URL Mapping'!E:E,"Verified")/total
  • Редиректи, що проходять: =COUNTIF('Status Code Check'!F:F,"Pass")
  • Незакриті рядки з помилками: [кількість]
  • Перевірені високопріоритетні сторінки: [кількість / усього]

Використовуйте це для рішень

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

Як використовувати цей шаблон

  1. Проскануйте старий сайт повністю й вставте кожен URL на аркуш зіставлення URL, по одному рядку на сторінку.
  2. Заповніть аркуш налаштувань, щоб випадні списки статусів і редиректів та форматування застосовувалися по всій робочій книзі.
  3. Зіставте кожен старий URL рівно з одним новим URL, потім призначте тип редиректу, відповідального й пріоритет.
  4. Експортуйте зіставлення на аркуш правил редиректів і перевірте на ланцюжки, цикли та дубльовані цілі.
  5. На стейджингу проскануйте URL і зафіксуйте коди стану, щоб виявити помилки до запуску, а не після.
  6. Перевіряйте метадані, canonical і паритет контенту спершу на найцінніших сторінках.
  7. Стежте за дашбордом прогресу й відмовляйтеся запускати, поки будь-який високопріоритетний рядок з помилкою.
  8. Повторно проскануйте наступного дня після запуску, оновіть фактичні коди стану й усуньте залишкові помилки.

Поради

  • Зіставляйте з повного сканування, а не з мапи сайту: sitemap пропускає осиротілі та старі URL, що досі тримають зворотні посилання, які ви не хочете втратити.
  • Пріоритезуйте рядки за трафіком, позиціями та зворотними посиланнями, щоб обмежений час на QA захищав сторінки, які справді мають значення.
  • Полюйте на ланцюжки й цикли редиректів на аркуші правил редиректів до запуску; кожен зайвий перехід трохи витікає авторитетність і сповільнює сторінку.
  • Тримайте дашборд прогресу як ворота «запуск/не запуск»: запуск готовий, коли високопріоритетні рядки перевірено, а не коли так каже календар.

Поширені запитання

Чому Excel, а не просто плагін редиректів?

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

Чи кожен старий URL має отримати 301?

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

Як знайти кожен старий URL для зіставлення?

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

Що найчастіше це виявляє?

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

Чи замінює це повний технічний аудит?

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

Коли можна припинити відстеження?

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