Маппинг URL и настройка 301-редиректов при миграции

Маппинг 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.

Все редиректы сводятся в единую таблицу — единый источник истины:

Статус 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. Скрипт автоматически проверяет оба варианта (с / и без /), поэтому мы находим такие проблемы до деплоя.

Сравнение производительности редиректов

Как гарантировать успех миграции?

Мы используем дополнительный мониторинг 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 месяца и обошлось в потерю выручки около 2 млн рублей за квартал. Наш опыт — более 7 лет и 80+ успешных миграций, гарантируем сохранение позиций при правильном подходе.

Почему миграции ломают 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-кэш для динамического поиска. Подробнее в Wikipedia: HTTP 301.

Миграция контента из разных 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 недели.

Стоимость рассчитывается индивидуально по объёму. Средняя экономия клиента за счёт сохранения трафика после миграции — от 300 000 до 500 000 рублей в год.

Получите консультацию по вашему проекту — мы ответим в течение дня. Закажите предмиграционный аудит вашего сайта и получите точную смету с планом редиректов. Свяжитесь с нами, чтобы обсудить детали.