Міграція сайту без втрат: правильне налаштування 301-редиректів
Втрата трафіку після зміни домену — класика. Клієнт переїжджає, забуває налаштувати 301, і пошуковики бачать 404. Наш досвід: для інтернет-магазину з 50 000 URL після міграції трафік впав на 80% за тиждень. Маппінг і коректні редиректи повернули позиції за місяць. Без 301 ви втрачаєте не лише трафік, а й посилальну вагу. Збереження ранжування обходиться значно дешевше, ніж повторний запуск реклами. Економія бюджету на відновлення позицій — ще один вагомий аргумент на користь якісної міграції. Наша команда має понад 5 років досвіду в SEO-міграціях та виконала 50+ успішних проєктів.
Правильне налаштування 301-редиректів зберігає до 99% ранжування. Навіть один пропущений URL може коштувати тисяч відвідувань на місяць. Економія на відновленні трафіку може сягати до $5000 залежно від масштабу.
Що таке 301 і чому він важливий?
HTTP 301 — код "Moved Permanently", що передає від 90 до 99% PageRank новій сторінці. Для порівняння: 302 передає менше 10% — це в 10 разів гірше. Google зазвичай переносить позиції за 2–8 тижнів після коректного налаштування. Використовуйте лише 301 для постійних змін. При тимчасових акціях або A/B-тестах допустимий 302, але для міграції — тільки 301.
Чому важлива перевірка ланцюжків редиректів?
Ланцюжок із кількох редиректів (наприклад, A→B→C) розмиває передавану вагу. Кожен крок втрачає 5–10% PageRank. Ми стежимо, щоб ланцюжки не перевищували одного кроку. Після міграції проганяємо сайт через Screaming Frog для виявлення таких ситуацій. В одному з проєктів ланцюжок із трьох кроків знизив передачу ваги на 25% — після виправлення трафік відновився за два тижні.
Як уникнути втрати трафіку при міграції?
Перед переїздом складаємо повний маппінг URL, приділяючи особливу увагу сторінкам з високим трафіком і беклінками. Після деплою моніторимо Google Search Console на появу 404. Протягом місяця відстежуємо позиції та коригуємо редиректи за потреби. Також корисно перевірити www і non-www версії домену, щоб не створити додаткових пропусків. Для перевірки редиректів використовуйте curl -I URL або браузерне розширення Redirect Path. Зверніть увагу на HSTS та канонічні теги — вони можуть впливати на індексацію.
Приклад із практики: міграція сайту на Laravel. Вихідний сайт на WordPress з 15 000 URL. Автоматично імпортували структуру в панель адміністратора, налаштували редиректи через middleware з кешуванням у Redis. Після деплою моніторили 404 — виявили 2% помилок, викликаних регістрозалежними шляхами. Виправили за годину.
Що входить у налаштування 301-редиректів
- Аудит старого сайту: краулінг всіх URL, аналіз трафіку з Google Search Console.
- Маппінг кожного старого URL з новим, пріоритизація за трафіком і беклінками.
- Реалізація редиректів через .htaccess, Nginx або middleware (Laravel, Django, Node.js).
- Тестування ланцюжків, відсутності 404 і коректної передачі ваги.
- Моніторинг у Google Search Console протягом 30 днів після деплою.
- Документація по всіх редиректах і звіт про перевірку.
Стратегія міграції
До переїзду:
- Краулінг старого сайту (Screaming Frog, Sitebulb) — вивантажити всі індексовані URL.
- Перевірити через Google Search Console — знайти сторінки з трафіком і позиціями.
- Співставити старі URL з новими (mapping таблиця).
- Пріоритизувати сторінки з трафіком.
| Старий URL |
Новий URL |
Пріоритет |
/catalog.php?cat=12 |
/catalog/smartphones |
Високий |
/product.php?id=4521 |
/products/iphone-15-pro |
Високий |
/about.html |
/pro-kompaniyu |
Середній |
/news/archived/post-1 |
/blog/post-1-slug |
Низький |
Процес налаштування 301-редиректів
| Етап |
Опис |
| Аудит старого сайту |
Краулінг, вивантаження всіх URL, аналіз трафіку з GSC |
| Маппінг |
Співставлення кожного старого URL з новим, пріоритизація |
| Реалізація |
Редиректи через .htaccess, Nginx або middleware на Laravel/іншому стеку |
| Тестування |
Перевірка ланцюжків, відсутність 404, коректність передачі ваги |
| Моніторинг |
Відстеження 404 і позицій протягом 30 днів після деплою |
| Звіт |
Документація по всіх редиректах і результатах перевірки |
Типові помилки
- Використання 302 замість 301 — вага не передається.
- Редиректи на головну замість релевантних сторінок — втрачається контекст.
- Ланцюжки редиректів більше одного кроку — розмивають PageRank.
- Ігнорування регістру URL — биті посилання.
- Невраховані параметри в URL — сторінки не індексуються.
Перевірка після міграції
- Screaming Frog: краулінг нового сайту, перевірка ланцюжків редиректів (не більше 1 кроку).
- Google Search Console: моніторинг Coverage → Not Found (404).
- Ahrefs/Semrush: перевірка, що беклінки коректно редиректнуті.
- Перевірити www і non-www версії домену.
Термін налаштування: 1–3 дні залежно від обсягу маппінгу. Отримайте консультацію з налаштування редиректів до міграції — це знизить ризики. Замовте експрес-аудит поточних редиректів, щоб переконатися в коректності передачі ваги.
Редизайн та міграція сайту: зміна 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. Ось типові поломки:
| Проблема |
Причина |
Рішення |
| Дубльований контент |
Новий сайт відкривається паралельно зі старим |
Вимкнути індексацію dev-версії, налаштувати canonical |
| Втрата метаданих |
Title і description залишилися в старій CMS |
Експорт через API, масовий імпорт з перевіркою |
| Зміна canonical |
Пагінація та фільтри скинулися |
Зафіксувати до розробки, впровадити в шаблон |
| Швидкість просіла |
Важкі секції, неоптимізовані зображення |
Оптимізувати LCP, CLS, TTFB до запуску |
Як відновити трафік після невдалої міграції?
Якщо трафік впав — дійте негайно:
- Краул нового сайту на 404 та порівняння з передміграційним списком URL.
- Створення редиректів для всіх втрачених сторінок з трафіком >0.
- Перевірка структурованих даних та мета-тегів на тестовій вибірці.
- Щоденний моніторинг Coverage в Search Console та позицій за топ-50 запитами.
- Якщо через 2 тижні трафік не відновлюється — глибокий аудит редиректів (транзитивність, ланцюжки, цикли).
У нашій практиці такий випадок: великий інтернет-магазин втратив 50% трафіку при переїзді з Бітрікса на React + Strapi. За три дні відновили 95% редиректів, через 3 тижні трафік повернувся на 90% від початкового.
Як підготувати сайт до міграції: що не можна пропустити?
До початку розробки нового сайту потрібно:
- Повний краул поточного сайту через Screaming Frog або Sitebulb. Отримати список всіх індексованих URL з трафіком з Google Search Console.
- Вивантажити всі сторінки з органічним трафіком >0 за останні 6 місяців — це пріоритет для редиректів.
- Зафіксувати всі зовнішні посилання (backlinks) на конкретні сторінки — Ahrefs, Semrush.
- Сфотографувати поточні позиції за ключовими запитами — база для порівняння після міграції.
- Зберегти Core Web Vitals з Search Console за попередні 90 днів.
Таблиця для фіксації:
| Етап аудиту |
Інструмент |
Критичність |
| Збір URL |
Screaming Frog + GSC |
Висока |
| Трафік за сторінками |
Google Analytics / Search Console |
Висока |
| Зовнішні посилання |
Ahrefs / Majestic |
Середня |
| Позиції |
Яндекс.Wordstat / Serpstat |
Середня |
| Core Web Vitals |
GSC CrUX |
Висока |
Зв'яжіться з нами для детального передміграційного аудиту — ми допоможемо виявити всі ризики та скласти план дій.
Мапінг 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) з ручною перевіркою проблемних сторінок.
| CMS |
Інструменти міграції |
Складність |
Ризики |
| WordPress |
WP All Export, WP-CLI, REST API |
Середня |
Shortcodes, meta fields |
| 1С-Бітрікс |
Bitrix API, SQL-експорт |
Висока |
Складна структура, властивості інфоблоків |
| Joomla |
J2XML, пряме вивантаження з БД |
Висока |
Застарілі розширення |
| Tilda/Readymag |
Експорт через API (обмежений) |
Середня |
Немає повного доступу до контенту |
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%+ — негайний аудит редиректів та порівняння з передміграційним краулом.
Чек-лист на запуск (спойлер)
- [ ] Всі 301 редиректи працюють і не утворюють ланцюжків
- [ ] Sitemap відправлений в GSC та Яндекс.Вебмайстер
- [ ] Прописані canonical на всіх сторінках
- [ ] Перевірено відображення Open Graph / Twitter Card
- [ ] Скориговані robots.txt та мета-теги noindex
- [ ] Core Web Vitals в зеленій зоні (LCP <2.5s, CLS <0.1, INP <200ms)
Що входить в роботу
Результати, які ви отримуєте:
- План міграції з мапінгом URL та редиректів у форматі Excel/Google Sheets.
- Налаштовані 301 редиректи на серверному рівні (Nginx/Cloudflare/Vercel).
- Перенесений контент з перевіркою цілісності: зображення, мета-поля, посилання.
- Структуровані дані (Schema.org) на новому сайті, ідентичні старим або покращені.
- Звіт по SEO: динаміка позицій через 1, 3 та 6 тижнів після запуску.
- Моніторинг Coverage в Search Console з повідомленнями про помилки.
- Гарантія збереження позицій: якщо трафік падає більш ніж на 15% протягом першого місяця — безкоштовний аудит та корекція.
Терміни та орієнтири
- Редизайн з міграцією невеликого сайту (до 100 сторінок): 4–8 тижнів.
- Міграція e-commerce з 500+ сторінок товарів: 8–16 тижнів.
- Тільки технічна частина міграції (редиректи, метадані) без редизайну: 1–3 тижні.
Вартість розраховується індивідуально за обсягом. Середня економія клієнта за рахунок збереження трафіку після міграції — суттєва сума для бізнесу.
Отримайте консультацію по вашому проекту — ми відповімо протягом дня. Замовте передміграційний аудит вашого сайту та отримайте точний кошторис з планом редиректів. Зв'яжіться з нами, щоб обговорити деталі.