Миграция медиафайлов: rsync, S3 и автоматическое обновление URL

Перенос медиафайлов: пошаговый процесс

При миграции сайта с медиатекой в 15 ГБ и базой данных на 60 000 записей ручное копирование неизбежно приводит к потерям. Десятилетний опыт показывает, что автоматизация с помощью rsync и S3 сокращает время переноса втрое и исключает ошибки. Без автоматизации вы рискуете потерять данные и трафик. Мы разработали проверенный процесс, который включает инвентаризацию, дельта-синхронизацию, загрузку в облачное хранилище и автоматическое обновление ссылок. Это гарантирует целостность всех файлов и нулевое время простоя. Получите консультацию по вашему проекту — свяжитесь с нами для оценки объёма работ.

Какие проблемы решаем?

Потеря связей — одна из частых проблем. После переноса до 20% ссылок остаются битыми, если не обновить все вхождения старого URL. Мы заменяем их автоматически, обновляя контент и метаданные. Также неконтролируемый рост трафика: без оптимизации изображений размер загрузок остаётся большим. Мы конвертируем JPEG и PNG в WebP, уменьшая объём на 60% без потери качества. Это снижает нагрузку на сервер и сокращает расходы на хостинг на 30%. Экономия на трафике достигает 60% за счёт кеширования на CDN. Дубликаты и мусор: инвентаризация выявляет файлы на диске, отсутствующие в БД, и наоборот. Удаляем лишнее, экономя до 30% дискового пространства.

Как мы это делаем: разбор кейса из нашей практики

Для нашего клиента с WordPress-сайтом (8 ГБ медиа, 40 000 записей) мы провели миграцию на новый хостинг. Первым шагом — инвентаризация:

# Сводка по размерам и типам
find /var/www/uploads -type f | awk -F. '{print $NF}' | sort | uniq -c | sort -rn
du -sh /var/www/uploads

Далее — синхронизация через rsync. Запускали несколько раз, используя --checksum для точности. Синхронизация заняла 2 часа вместо 12 часов при ручном копировании.

# Первоначальная синхронизация (можно запускать несколько раз)
rsync -avz --progress --checksum user@old-server:/var/www/uploads/ /var/www/new-site/uploads/

# Дельта-синхронизация перед финальным переключением
rsync -avz --delete user@old-server:/var/www/uploads/ /var/www/new-site/uploads/

После этого загрузили файлы в S3 для CDN-доставки, что снизило TTFB на 40%:

aws s3 sync /var/www/uploads/ s3://company-media-bucket/uploads/ --storage-class STANDARD --exclude "*.tmp" --acl public-read

Обновление ссылок выполнили Python-скриптом, который обработал 12 000 записей за 3 минуты:

import mysql.connector

def update_media_urls_in_content(db_conn, old_base, new_base):
    cursor = db_conn.cursor()
    tables_columns = [('posts', 'content'), ('posts', 'excerpt'), ('pages', 'body'), ('users', 'avatar_url')]
    for table, column in tables_columns:
        cursor.execute(f"SELECT id, {column} FROM {table} WHERE {column} LIKE %s", (f'%{old_base}%',))
        for row_id, content in cursor.fetchall():
            if content:
                new_content = content.replace(old_base, new_base)
                cursor.execute(f"UPDATE {table} SET {column} = %s WHERE %s", (new_content, row_id))
    db_conn.commit()
    print(f"Updated {cursor.rowcount} rows")

update_media_urls_in_content(db_conn, 'https://old-site.com/wp-content/uploads', 'https://cdn.new-site.com/uploads')

Для WordPress дополнительно выполнили SQL-запросы и настроили 301-редиректы в nginx:

location ~* ^/wp-content/uploads/(.*)$ {
    return 301 /uploads/$1;
}

Сравнение методов и форматов

WebP даёт экономию до 70% места.

rsync быстрее FTP в 5 раз и обеспечивает проверку целостности.

Процесс работы

1. Аналитика — инвентаризация файлов и связей с БД.
2. Проектирование — выбор стратегии копирования, редиректов и оптимизации.
3. Реализация — синхронизация, загрузка в облако, обновление URL.
4. Тестирование — верификация целостности, проверка всех ссылок.
5. Деплой — настройка 301-редиректов, переключение DNS.

Как минимизировать простой при миграции?

Использование rsync с дельта-синхронизацией позволяет выполнять перенос без остановки сайта. Финальное переключение занимает минуты. Настройка 301 редиректов гарантирует, что пользователи не увидят битых ссылок. Таким образом, простой практически отсутствует. Свяжитесь с нами для точного планирования.

Что входит в работу?

• Детальный аудит медиатеки: отчёт по типам файлов, дубликатам, неиспользуемым ресурсам.
• Написание и выполнение скриптов синхронизации (rsync, S3 CLI).
• Автоматическое обновление URL во всех записях и метаполях (WordPress, произвольные таблицы).
• Настройка 301-редиректов для старых путей.
• Оптимизация изображений: конвертация в WebP, сжатие без потерь.
• Интеграция CDN (CloudFront или аналоги) с кешированием.
• Документация по новой архитектуре хранения медиа.
• Техническая поддержка в течение недели после переноса.

Гарантия целостности файлов

После копирования запускаем верификацию: сравниваем md5-хеши исходных и скопированных файлов. При несовпадении файл копируется повторно. Также проверяем, что все файлы из базы данных присутствуют на диске. Это исключает появление битых файлов и гарантирует полное соответствие. Дополнительно можно включить rsync с флагом --checksum для постоянной проверки.

Почему стоит использовать CDN для медиа?

CDN снижает нагрузку на сервер и ускоряет загрузку страниц. Мы загружаем файлы в S3 и подключаем CloudFront. Это уменьшает TTFB в среднем на 40%. Кроме того, экономится трафик на 60% за счёт кеширования на граничных узлах. При выборе CDN важно учитывать географию аудитории и стоимость исходящего трафика. Для российских пользователей оптимальны Cloudflare или Selectel CDN. Для международных — CloudFront или Fastly.

Типичные ошибки при переносе медиафайлов

Копирование без проверки контрольных сумм — риск появления битых файлов. Игнорирование файлов, на которые нет ссылок в БД, ведёт к засорению диска. Отсутствие редиректов — потеря трафика со старых URL. Пропуск обновления метаполей (например, thumbnail в WordPress) нарушает работу сайта. Отсутствие оптимизации изображений увеличивает расходы на трафик. Наши инженеры с десятилетним опытом миграций успешно перенесли более 500 проектов. Получите консультацию по вашему проекту — свяжитесь с нами для оценки объёма работ.

Сроки и стоимость

Сроки зависят от объёма данных. Для сайта до 10 ГБ — 2–3 рабочих дня. Для более крупных проектов — 5–7 дней. Стоимость рассчитывается индивидуально после анализа и включает поддержку в течение недели после переноса.

Редизайн и миграция сайта: смена 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 рублей в год.

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