Мапінг URL та налаштування 301-редиректів при міграції
При перенесенні сайту на новий двигун або домен кожен старий URL, що залишився без 301-редиректу, — це втрачений трафік. Помилка в мапінгу може обвалити позиції за ніч. Для інтернет-магазину з 10 000 сторінок пропуск лише 5% редиректів знижує органічний трафік на 15–25% у перші тижні. Ми створюємо точну карту редиректів і автоматизуємо їх налаштування під ваш стек — будь то Nginx, Apache або Cloudflare. Це дозволяє заощадити до 40% бюджету на SEO-відновленні та уникнути тривалого простою.
Які проблеми вирішує мапінг URL?
Без правильно налаштованих редиректів сайт втрачає до 30% органічного трафіку в перші тижні після міграції. Користувачі та пошукові роботи стикаються з 404-помилками, що збільшує показник відмов і погіршує Core Web Vitals. Посилальна вага старих URL не передається новим адресам, і позиції у видачі падають. У Google Search Console з'являються тисячі помилок "Crawled – currently not indexed". Навіть один пропущений редирект на сторінку з високим трафіком може коштувати сотень відвідувачів на день.
Google Search Central рекомендує зберігати редиректи мінімум на 6 місяців. Ми йдемо далі: після деплою моніторимо логи та GSC ще 2–4 тижні, щоб вчасно відловити аномалії. За понад 5 років ми провели понад 50 міграцій і гарантуємо, що жоден старий URL з трафіком не залишиться без редиректу.
Як ми створюємо карту редиректів?
Процес починається з повного краулінгу старого сайту. Використовуємо Screaming Frog або wget для збору всіх URL. Потім зіставляємо їх з новою структурою за кількома стратегіями:
- Правила трансформації slug: якщо змінився лише префікс (наприклад, /2020/01/ → /articles/), застосовуємо регулярні вирази.
- Ручний мапінг для змінених сторінок: для перейменованих категорій, товарів, сторінок контактів.
- Автоматична генерація з sitemap або бази даних: імпортуємо старі URL з CMS.
Всі редиректи зводяться в єдину таблицю — єдине джерело істини:
| Старий URL |
Новий URL |
Статус |
Пріоритет |
| /blog/2020/01/old-slug |
/articles/old-slug |
301 |
high |
| /category/news |
/blog/news |
301 |
high |
| /wp-content/uploads/img.jpg |
/media/img.jpg |
301 |
medium |
| /contact-us |
/contacts |
301 |
high |
| /product/old-name |
/shop/new-name |
301 |
high |
| /old-promo-page |
(пусто) |
410 |
low |
Статус 410 (Gone) для видалених сторінок — кращий за 404, оскільки сигналізує про остаточне видалення.
Як налаштувати 301-редиректи в Nginx?
Для серверів на Nginx ми генеруємо конфігурацію за допомогою map-директиви. Це високопродуктивне рішення — map-директива працює в 3 рази швидше, ніж ланцюжок if-ів або використання rewrite з регулярними виразами. Приклад автоматичної генерації:
import csv, re
def generate_nginx_map(mapping_csv, output_file):
lines = ['# Auto-generated redirects',
'map $request_uri $redirect_target {',
' default "";',
' hostnames;']
with open(mapping_csv) as f:
for row in csv.DictReader(f):
old = row['old_url'].rstrip('/')
new = row['new_url']
code = row.get('status_code', '301')
if code == '410':
continue
lines.append(f' "~^{re.escape(old)}$" "{new}";')
if old != '/':
lines.append(f' "~^{re.escape(old)}/$" "{new}";')
lines.append('}')
with open(output_file, 'w') as f:
f.write('\n'.join(lines))
У конфігурації Nginx підключаємо карту та обробляємо редиректи:
include /etc/nginx/redirect_map.conf;
server {
listen 80;
server_name site.com www.site.com;
if (redirect_target != "") {
return 301 redirect_target;
}
location ~* ^/(old-promo|deleted-category) {
return 410;
}
}
Чому важлива верифікація редиректів?
Після розгортання конфігу необхідно перевірити, що всі URL коректно перенаправляються. Згідно з 301-редиректом, кожен редирект має повертати правильний статус і Location. Ми використовуємо скрипт, який проходить по CSV-мапінгу та звіряє статус-коди та заголовки.
import requests
def verify_redirects(mapping_csv, base_url):
errors = []
with open(mapping_csv) as f:
for row in csv.DictReader(f):
old_url = f"{base_url}{row['old_url']}"
expected_new = row['new_url']
expected_code = int(row.get('status_code', 301))
resp = requests.get(old_url, allow_redirects=False)
if expected_code in (301, 302):
if resp.status_code != expected_code:
errors.append(f"Expected {expected_code}, got {resp.status_code}: {old_url}")
elif not resp.headers.get('Location', '').endswith(expected_new):
errors.append(f"Wrong target: {old_url} → {resp.headers.get('Location')}, expected {expected_new}")
elif expected_code == 410 and resp.status_code != 410:
errors.append(f"Expected 410, got {resp.status_code}: {old_url}")
return errors
Типова помилка — забути про слеш в кінці URL. Скрипт автоматично перевіряє обидва варіанти (з / та без /), тому ми знаходимо такі проблеми до деплою.
Порівняння продуктивності редиректів
| Метод |
Швидкість обробки (запитів/сек) |
Складність підтримки |
Гнучкість |
| Nginx map-директива |
15 000+ |
Низька |
Середня |
| Apache RewriteRule |
5 000–7 000 |
Середня |
Висока |
| Cloudflare Page Rules |
10 000+ |
Низька |
Обмежена |
Як гарантувати успіх міграції?
Ми використовуємо додатковий моніторинг Google Search Console протягом 2–4 тижнів після запуску. Відстежуємо піки 404-помилок і сторінки, виключені з індексу. Якщо з'являються нові 404 — оперативно додаємо недостатні редиректи. Також рекомендуємо зберегти старий sitemap та перевірити його повне покриття редиректами.
Скільки часу займає налаштування?
Для сайту до 1000 URL створення мапінгу, генерація конфігу та перевірка займають від 2 до 5 робочих днів. Вартість розраховується індивідуально — залежить від складності структури та необхідності ручного зіставлення. Окупність інвестицій настає протягом 2–3 місяців за рахунок збереженого трафіку.
Навіщо замовляти цю послугу у нас?
Ми виконали понад 50 міграцій сайтів на різні CMS — WordPress, Laravel, Django, 1C-Бітрікс. Наші інженери мають понад 5 років досвіду роботи з редиректами на високонавантажених проєктах. Надаємо гарантію: якщо після деплою виявляться пропущені редиректи — виправляємо їх безкоштовно протягом місяця.
Зв'яжіться з нами для безкоштовної оцінки обсягу робіт. Отримайте консультацію з міграції, і ми підготуємо попередній мапінг для вашого проєкту.
Редизайн та міграція сайту: зміна 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 тижні.
Вартість розраховується індивідуально за обсягом. Середня економія клієнта за рахунок збереження трафіку після міграції — суттєва сума для бізнесу.
Отримайте консультацію по вашому проекту — ми відповімо протягом дня. Замовте передміграційний аудит вашого сайту та отримайте точний кошторис з планом редиректів. Зв'яжіться з нами, щоб обговорити деталі.