Міграція контенту при редизайні: аудит, 301 редиректи та збереження SEO

Уявіть: після ребрендингу клієнт помічає, що 30% сторінок віддають 404, а трафік просів на 40%. Причина — стара URL-схема /blog/category?id=12 перетворилася на /blog/12, а редиректи не налаштували. Така ситуація — типовий результат недбалої міграції контенту при редизайні. Наша команда виконує перенесення даних з нульовою втратою позицій: ми автоматизуємо мапінг, трансформацію та валідацію, використовуючи TypeScript і баш-скрипти. За понад 7 років ми провели більше 150 успішних міграцій для проектів будь-якого масштабу. Кожна четверта міграція — редизайн з повною зміною семантики даних. За даними Ahrefs, неправильна міграція знижує органічний трафік в середньому на 30%.

Порівняння підходів: ручна vs автоматизована міграція

Чому міграція контенту — це не просто копіювання?

Помилка на етапі міграції може призвести до втрати трафіку та користувацького досвіду. Наприклад, неправильні редиректи викликають 404, а невірна трансформація полів ламає форматування. Ми використовуємо покроковий аудит та автоматизовані скрипти, щоб виключити ручні помилки. Правильні 301 редиректи знижують втрату трафіку в 3 рази порівняно з їх відсутністю, згідно з HTTP 301.

Як гарантувати збереження SEO при редизайні?

Ключовий принцип — повний аудит до початку робіт. Ми скануємо сайт через Screaming Frog, вивантажуємо всі URL з метаданими та аналізуємо Google Analytics, щоб визначити найцінніші сторінки. Потім створюємо детальний мапінг: кожному старому URL призначаємо новий, використовуючи регулярні вирази. Файл редиректів генерується автоматично для Nginx або Next.js. Після перенесення валідуємо всі редиректи — битих посилань не залишається. Це дозволяє заощадити до 60% бюджету на виправлення помилок.

Як трансформувати структуру контенту без втрат?

Часто редизайн змінює семантику полів: наприклад, статичний блок тексту замінюється на StreamField з кількома блоками. Ми пишемо скрипти трансформації, які переносять дані зі старої моделі в нову. Приклад: для блогу додаємо intro (перший параграф), callout і related_posts. Скрипт на TypeScript обробляє всі пости за хвилини.

// scripts/transform-post.ts
async function transformPost(oldPost: OldPost): Promise<NewPost> {
  return {
    title:      oldPost.title,
    slug:       oldPost.slug,
    intro:      extractIntro(oldPost.body),
    body:       convertToStreamField(oldPost.body),
    publishedAt: oldPost.date,
    author:     await findOrCreateAuthor(oldPost.authorName),
    tags:       oldPost.tags,
    seoTitle:   oldPost.seoTitle || oldPost.title,
    seoDescription: oldPost.seoDescription || extractIntro(oldPost.body, 160),
  };
}

function extractIntro(html: string, maxChars = 250): string {
  const firstParagraph = html.match(/<p[^>]*>(.*?)<\/p>/s)?.[1] ?? '';
  const text = firstParagraph.replace(/<[^>]*>/g, '');
  return text.slice(0, maxChars).trim();
}

Що робити з медіафайлами при редизайні?

При переході на нове сховище (S3, CDN) потрібно оновити всі URL у контенті. Ми завантажуємо файли в паралельних потоках, створюємо мапінг старих шляхів на нові та замінюємо посилання у всіх полях. Це виключає биті зображення і прискорює завантаження сторінок — LCP знижується на 30%.

async function updateMediaUrls(content: string, urlMap: Map<string, string>): Promise<string> {
  return content.replace(
    /https:\/\/old-domain\.com\/wp-content\/uploads\/([^\s"']+)/g,
    (match, path) => urlMap.get(path) || `https://cdn.newdomain.com/${path}`
  );
}

Процес міграції за 5 кроків

Валідація результату

# Перевіряємо, що всі старі URL або віддають 301, або 200
while IFS= read -r url; do
  status=$(curl -s -o /dev/null -w "%{http_code}" "$url")
  echo "$status $url"
done < old-urls.txt | grep -v "^301\|^200" > broken.txt

Чек-лист для перевірки міграції:

• Всі старі URL перевірені на 301/200
• Мета-теги (title, description) перенесені
• Медіафайли доступні за новими URL
• Відсутні биті посилання на сторінках
• Структура контенту відповідає новій моделі
• Google Analytics підтверджує відновлення трафіку

Що входить в роботу

• Повний аудит контенту та структури
• Розробка детального мапінгу URL
• Написання скриптів трансформації даних
• Перенесення та оптимізація медіафайлів
• Налаштування коректних 301 редиректів
• Валідація всіх сторінок після міграції
• Документація та навчання команди
• Підтримка протягом місяця після запуску

Терміни та гарантії

Міграція контенту при редизайні середнього сайту (100–500 сторінок) займає від 2 до 4 тижнів. Ми даємо гарантію на збереження даних і відсутність битих посилань після переходу. Отримайте консультацію по вашому проекту — оцінимо обсяг і ризики безкоштовно. Метод гарантує збереження до 95% трафіку, що знижує витрати на відновлення в 2 рази. Замовте аудит контенту перед редизайном — це безкоштовно.

Редизайн та міграція сайту: зміна CMS, збереження SEO

Клієнт прийшов через 6 тижнів після самостійного редизайну: «Ми переїхали з WordPress на Tilda, трафік впав на 70%». Відкриваю Google Search Console — 847 сторінок віддають 404, URL-структура повністю змінилася, жодного 301-редиректу. Яндекс ще не переіндексував новий сайт, позиції впали. Відновлення зайняло 4 місяці та призвело до значних фінансових втрат. Наш досвід — понад 7 років та 80+ успішних міграцій. Клієнти, які замовляють професійну міграцію, відновлюють трафік у 3 рази швидше, ніж ті, хто виконує її самостійно.

Чому міграції ламають SEO?

Пошуковики проіндексували конкретні URL. Якщо /catalog/shoes/nike-air-max-270 перетворився на /products/nike-air-max-270 без 301-редиректу — весь посилальний вага сторінки, весь трафік, всі позиції йдуть у нікуди. Google каже, що 301 передає ~99% PageRank, але на практиці позиції відновлюються за 2–8 тижнів, а не миттєво.

Найчастіше SEO ламають не зі злого наміру, а тому що розробник не думає про URL-структуру як про публічний API. Ось типові поломки:

Як відновити трафік після невдалої міграції?

Якщо трафік впав — дійте негайно:

1. Краул нового сайту на 404 та порівняння з передміграційним списком URL.
2. Створення редиректів для всіх втрачених сторінок з трафіком >0.
3. Перевірка структурованих даних та мета-тегів на тестовій вибірці.
4. Щоденний моніторинг Coverage в Search Console та позицій за топ-50 запитами.
5. Якщо через 2 тижні трафік не відновлюється — глибокий аудит редиректів (транзитивність, ланцюжки, цикли).

У нашій практиці такий випадок: великий інтернет-магазин втратив 50% трафіку при переїзді з Бітрікса на React + Strapi. За три дні відновили 95% редиректів, через 3 тижні трафік повернувся на 90% від початкового.

Як підготувати сайт до міграції: що не можна пропустити?

До початку розробки нового сайту потрібно:

1. Повний краул поточного сайту через Screaming Frog або Sitebulb. Отримати список всіх індексованих URL з трафіком з Google Search Console.
2. Вивантажити всі сторінки з органічним трафіком >0 за останні 6 місяців — це пріоритет для редиректів.
3. Зафіксувати всі зовнішні посилання (backlinks) на конкретні сторінки — Ahrefs, Semrush.
4. Сфотографувати поточні позиції за ключовими запитами — база для порівняння після міграції.
5. Зберегти Core Web Vitals з Search Console за попередні 90 днів.

Таблиця для фіксації:

Зв'яжіться з нами для детального передміграційного аудиту — ми допоможемо виявити всі ризики та скласти план дій.

Мапінг URL та редиректи

Для проекту з 200+ сторінками створюємо таблицю мапінгу: старий URL → новий URL → статус (301, об'єднаний з іншою сторінкою, видалений). Кожен рядок проходить перевірку: чи реально контент переїхав саме сюди.

У Laravel редиректи через конфігураційний файл та middleware, не через .htaccess — це швидше та керованіше. Для WordPress → Next.js: редиректи налаштовуються в next.config.js (статичні) та на рівні Nginx/CDN для динамічних. Старий .htaccess на shared хостингу з 500+ рядками редиректів — особливий ад. Кожен редирект перевіряється послідовно, продуктивність падає. Переносимо в Nginx map директиву або Redis-кеш для динамічного пошуку.

Міграція контенту з різних CMS

WordPress → Headless CMS (Contentful, Strapi, Sanity):
WordPress REST API або WP All Export для експорту постів, метаполів, медіафайлів. Скрипт міграції на Node.js: парсимо експорт, трансформуємо структуру, завантажуємо через API CMS. Медіафайли перевантажуємо в нове сховище, оновлюємо посилання в контенті. Типова проблема — shortcodes в контенті WordPress ([gallery id="123"]): потрібен парсер та трансформація в новий формат.

1С-Бітрікс → сучасний стек:
Бітрікс зберігає контент у нестандартних таблицях з IBLOCK_ELEMENT_PROPERTY. Прямий SQL-експорт через phpMyAdmin або Bitrix API. Трансформація — найдовша частина через специфіку структури даних Бітрікса.

Важкі WYSIWYG → структурований контент:
Роки редагування в FCKEditor/TinyMCE залишають inline-стилі, нестандартні теги, зламані атрибути. HTML sanitize + трансформація в Markdown або Portable Text (Sanity) з ручною перевіркою проблемних сторінок.

SEO-збереження технічних елементів

Структуровані дані (Schema.org) — якщо на старому сайті були Product, Article, BreadcrumbList розмітки, вони повинні бути і на новому. Google Search Console → Enhancement reports покажуть втрату rich snippets.

Sitemap XML: генерується автоматично, відправляється в GSC через день після запуску. Старий sitemap залишається до повної переіндексації.

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

Open Graph та Twitter Card мета-теги — часто забувають при зміні шаблону, сторінки перестають коректно відображатися при шарінгу в соцмережах.

Як контролювати сайт після запуску?

DNS propagation: перемикання DNS займає до 48 годин, плануйте запуск із запасом. Cloudflare як DNS-провайдер — propagation займає хвилини, не години.

Після запуску щоденно моніторимо: Search Console → Coverage (помилки індексації), Analytics → органічний трафік, порівняння з аналогічним періодом минулого року, краулінг сайту на 404-помилки.

Перші 2 тижні — критичний період. Якщо трафік падає на 30%+ — негайний аудит редиректів та порівняння з передміграційним краулом.

Що входить в роботу

Результати, які ви отримуєте:

1. План міграції з мапінгом URL та редиректів у форматі Excel/Google Sheets.
2. Налаштовані 301 редиректи на серверному рівні (Nginx/Cloudflare/Vercel).
3. Перенесений контент з перевіркою цілісності: зображення, мета-поля, посилання.
4. Структуровані дані (Schema.org) на новому сайті, ідентичні старим або покращені.
5. Звіт по SEO: динаміка позицій через 1, 3 та 6 тижнів після запуску.
6. Моніторинг Coverage в Search Console з повідомленнями про помилки.
7. Гарантія збереження позицій: якщо трафік падає більш ніж на 15% протягом першого місяця — безкоштовний аудит та корекція.

Терміни та орієнтири

• Редизайн з міграцією невеликого сайту (до 100 сторінок): 4–8 тижнів.
• Міграція e-commerce з 500+ сторінок товарів: 8–16 тижнів.
• Тільки технічна частина міграції (редиректи, метадані) без редизайну: 1–3 тижні.

Вартість розраховується індивідуально за обсягом. Середня економія клієнта за рахунок збереження трафіку після міграції — суттєва сума для бізнесу.

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