Міграція медіафайлів: 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 місяці та призвело до значних фінансових втрат. Наш досвід — понад 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 тижні.

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

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