Переїзд сайту без втрати позицій

«Ми переїхали на новий сайт, а заявки з Google зникли» — з цієї фрази починається помітна частина наших аудитів. Сценарій майже завжди однаковий: компанія вирішує змінити домен або перейти зі старої самописної системи на WordPress, OpenCart чи Shopify, розробник робить красивий новий сайт, його запускають у п’ятницю ввечері — а через два тижні органічний трафік падає вдвічі. Дизайн тут ні до чого. Пошукова система просто не змогла зрозуміти, куди поділися сторінки, які вона роками показувала людям.

Переїзд — це одна з небагатьох ситуацій у SEO, де за один день можна втратити те, що накопичувалося роками. Але це також добре керований процес: якщо пройти його за чеклістом, позиції зазвичай повертаються швидко, а часто сайт навіть виграє від чистішої структури. Нижче — порядок дій, яким ми користуємося у власних проєктах міграції: від інвентаризації старого сайту до моніторингу через кілька місяців після запуску.

Які бувають переїзди і чим вони ризиковані

Слово «міграція» в SEO означає будь-яку зміну, після якої пошуковій системі треба заново зрозуміти ваш сайт. Ризик залежить від того, скільки всього змінюється одночасно. Найчастіше ми зустрічаємо такі сценарії:

Тип переїзду	Що змінюється	Рівень ризику
Перехід на HTTPS	Протокол, адреси сторінок лишаються ті самі	Низький
Новий домен, той самий сайт	Домен, структура й контент без змін	Середній
Нова CMS, той самий домен	Шаблони, часто URL, мета-теги, перелінковка	Середній або високий
Новий домен + нова CMS + нова структура	Майже все	Високий

Головне правило, яке ми пояснюємо кожному клієнту: чим менше змін за раз, тим легше знайти причину, якщо щось піде не так. Якщо є можливість, ми розносимо етапи в часі: спершу переносимо сайт на нову CMS зі збереженням адрес, а домен міняємо пізніше, коли все стабілізувалося. Коли ж усе мусить статися одночасно — наприклад, через ребрендинг, — підготовка має бути особливо ретельною.

Окремо варто чесно відповісти собі на запитання, чи потрібен переїзд узагалі. Нова CMS не дає SEO-переваг сама по собі. Якщо стара платформа дозволяє редагувати мета-теги, керувати URL, швидко віддає сторінки й нормально оновлюється, часто дешевше доопрацювати її. Переїзд виправданий, коли система фізично не дає розвивати сайт, не отримує оновлень безпеки або коли бізнес змінює назву.

Етап 1. Інвентаризація: зафіксуйте все, що є зараз

Найбільша помилка — починати з нового сайту. Ми завжди починаємо зі старого. Поки він працює, з нього можна зібрати повну картину: які сторінки існують, які з них приносять трафік, на які ведуть зовнішні посилання. Після запуску цю інформацію відновити набагато важче.

Ось що ми збираємо до початку розробки:

1. Повний список URL. Скануємо сайт краулером (Screaming Frog, Netpeak Spider чи аналогом), додаємо адреси з карти сайту, зі звіту «Сторінки» в Google Search Console і з аналітики за останні 12–16 місяців. Кожне джерело знаходить те, що пропускають інші: старі акційні сторінки, PDF-файли, адреси з параметрами.
2. Сторінки з трафіком. Експортуємо зі Search Console кліки й покази за сторінками, а з аналітики — входи й конверсії. Так ми бачимо, які 10–20% адрес приносять основну частину відвідувачів і заявок.
3. Зовнішні посилання. Вивантажуємо звіт «Посилання» з Search Console і, за можливості, дані з Ahrefs чи Serpstat. Сторінки, на які посилаються інші сайти, мають отримати точний редирект — це гарантія, що їхня вага не загубиться.
4. SEO-елементи сторінок. Title, description, H1, canonical, мета-роботс, hreflang, розмітка Schema.org, alt зображень. Зберігаємо вивантаження краулера як «знімок» старого сайту.
5. Базові показники. Фіксуємо позиції за ключовими запитами, кількість сторінок в індексі, швидкість основних шаблонів. Без цієї точки відліку після запуску неможливо сказати, що саме змінилося.

Окремо ми переглядаємо robots.txt, налаштування піддоменів, мовні версії та все, що підключено до сайту: аналітику, пікселі, CRM, форми, онлайн-чат. На старих сайтах часто знаходиться щось, про що ніхто вже не пам’ятає, але воно досі приносить заявки — наприклад, окрема посадкова сторінка під давню рекламну кампанію.

Етап 2. Карта редиректів — серце міграції

Карта редиректів — це таблиця, де для кожної старої адреси вказано нову. Саме вона визначає, чи передасть пошукова система новим сторінкам вагу старих. Ми складаємо її в таблиці з трьома колонками: стара URL, нова URL, коментар (перенесено як є, об’єднано, видалено).

Правила, яких ми дотримуємося:

• Тільки 301. Постійний редирект — сигнал, що сторінка переїхала назавжди. Тимчасові 302, JavaScript-перенаправлення чи мета-refresh для міграції не підходять.
• Один до одного. Кожна стара сторінка веде на найближчий за змістом відповідник. Категорія — на категорію, стаття — на статтю, товар — на той самий товар.
• Жодних масових редиректів на головну. Пошукова система розцінює їх як «м’яку 404» — вага не передається. Якщо відповідника справді немає, краще віддати 404 або 410, а для важливих сторінок створити заміну.
• Без ланцюжків. Якщо сайт уже переїжджав раніше, старі редиректи треба переписати так, щоб вони одразу вели на кінцеву адресу, а не стрибали через дві-три проміжні.
• Усі варіанти адрес. З www і без, http і https, зі слешем у кінці й без, з великими літерами. Кожен варіант має одним кроком потрапляти на канонічну нову адресу.
• Не лише сторінки. Зображення, PDF-каталоги, прайси, які люди зберегли в закладках або на які посилаються форуми, — теж частина карти.

На великих сайтах ми не пишемо тисячі рядків вручну. Для товарів і статей працюють правила: наприклад, якщо стара адреса /product.php?id=125, а нова формується з назви, ми зіставляємо їх через ідентифікатор товару в базі. Для категорій і ключових сторінок, навпаки, перевіряємо кожен рядок очима — тут помилка найдорожча.

І ще порада: якщо при переході на нову CMS можна зберегти старі адреси без змін — зберігайте. Найкращий редирект — той, який не знадобився. Змінювати URL варто лише тоді, коли старі справді погані: з параметрами, кирилицею без потреби чи безглуздими ідентифікаторами. Як ми будуємо зрозумілу структуру адрес, описано в статті «Внутрішня SEO-оптимізація сайту».

Етап 3. Що обов’язково перенести на новий сайт

Навіть з ідеальними редиректами сайт просяде, якщо нова версія гірша за стару за змістом. Пошукова система порівнює: раніше на сторінці було 800 слів корисного тексту, таблиця характеристик і відгуки, а тепер — банер і два речення. Тому ми звіряємо новий сайт зі «знімком» старого за кожним важливим шаблоном.

Наш список того, що має переїхати без втрат:

1. Контент сторінок із трафіком — тексти, таблиці, FAQ, відгуки. Можна покращувати, але не скорочувати без причини.
2. Title, description і H1. Якщо вони працювали, переносимо як є. Нові шаблони мета-тегів тестуємо після стабілізації, а не в день запуску.
3. Внутрішня перелінковка. Меню, хлібні крихти, блоки «схожі товари» й посилання в текстах мають вести одразу на нові адреси, а не на старі через редирект.
4. Canonical і мета-роботс. Перевіряємо, що канонічні адреси вказують на нові URL і що на робочих сторінках немає залишеного з розробки noindex.
5. Мовні версії й hreflang, якщо сайт багатомовний. Кожна версія має посилатися на нові адреси своїх «сестер». Про роботу з мовними версіями ми писали в матеріалі «Просування в англомовних регіонах».
6. Структуровані дані — Organization, Product, BreadcrumbList, Article. Нова тема чи плагін часто генерують розмітку інакше або не генерують її взагалі.
7. Зображення з alt-текстами і зрозумілими назвами файлів — для багатьох магазинів пошук за картинками дає відчутний трафік.
8. Аналітика й інтеграції: GA4, Search Console, пікселі, цілі, відправка заявок у CRM, коди підтвердження.

Окремо дивимося на швидкість і мобільну версію. Новий сайт не повинен бути повільнішим за старий: якщо головний шаблон став важчим, падіння позицій можна помилково приписати редиректам, хоча причина зовсім в іншому. Прискорення шаблонів перед запуском ми робимо в межах послуги оптимізації сайту. Оскільки Google оцінює сайт насамперед за мобільною версією, ми тестуємо її на реальному смартфоні — детальніше в статті «Як досягти успіху в mobile-first index».

Етап 4. Тестовий стенд: перевіряємо до запуску

Новий сайт ми завжди збираємо на тестовому сервері. І першим ділом закриваємо його від індексації — найкраще паролем на рівні сервера. Заборона в robots.txt надійна менше: якщо на стенд хтось поставить посилання, адреси можуть потрапити в індекс без вмісту, і тоді в пошуку з’явиться дубль вашого сайту.

На стенді ми проходимо кілька перевірок:

• Сканування нового сайту й порівняння зі знімком старого: чи всі важливі сторінки на місці, чи не з’явилися дублі, порожні сторінки, биті посилання, сторінки без title чи H1.
• Тест карти редиректів. Проганяємо весь список старих URL через краулер у режимі списку й дивимося, що кожна адреса за один крок віддає 301 на правильну сторінку з кодом 200.
• Перевірка шаблонів головної, категорії, картки товару, статті, контактів — на десктопі й смартфоні.
• Форми й оплата. Тестова заявка має дійти до менеджера, тестове замовлення — пройти до кінця.
• Швидкість основних шаблонів — порівнюємо з показниками старого сайту.

Саме на цьому етапі зазвичай знаходиться найбільше проблем: сторінки пагінації без контенту, фільтри, що відкрились для індексації, розмітка з помилками, забуті сторінки політики конфіденційності. Знайти їх до запуску в рази дешевше, ніж після.

Етап 5. День запуску: порядок дій

Ми не запускаємо переїзд у п’ятницю й перед святами. Найкраще — на початку тижня, у період найменшого сезонного попиту, коли команда на зв’язку кілька днів поспіль. Порядок такий:

1. Робимо повний бекап старого сайту й бази — щоб за потреби повернутися за годину.
2. Переносимо фінальний контент: замовлення, нові статті, відгуки, що з’явилися під час розробки.
3. Знімаємо пароль і заборону індексації з нового сайту. Це пункт, який забувають найчастіше.
4. Вмикаємо редиректи й одразу вибірково перевіряємо 20–30 ключових адрес вручну.
5. Оновлюємо robots.txt і карту сайту: у ній лише нові адреси з кодом 200.
6. Підтверджуємо сайт у Search Console (за новим доменом — новий ресурс) і надсилаємо карту сайту.
7. Перевіряємо аналітику в режимі реального часу та тестові заявки.
8. Скануємо весь сайт ще раз — уже на бойовому сервері.

Корисний прийом: тимчасово залишити на сервері стару карту сайту зі старими адресами. Так пошукова система швидше пройде по них, побачить редиректи й оновить індекс. Через кілька тижнів її можна прибрати.

Етап 6. Особливості переїзду на новий домен

Якщо змінюється домен, до всього сказаного вище додаються ще кілька кроків:

• Інструмент «Зміна адреси» в Search Console. Після запуску редиректів у ресурсі старого домену вказуємо новий. Інструмент працює саме для зміни домену, а не для переходу на HTTPS чи зміни структури.
• Старий домен — не продавати й не відпускати. Редиректи мають працювати якомога довше, щонайменше рік, а на практиці ми радимо тримати домен постійно: на нього роками вестимуть старі посилання, візитки, закладки.
• Зовнішні посилання. Найцінніші — партнерські сайти, каталоги, профілі в соцмережах — просимо оновити на нову адресу. Редирект передає вагу, але пряме посилання надійніше.
• Усе, де вказано адресу сайту: профіль Google Business, рекламні кабінети, email-підписи, розсилки, друковані матеріали, месенджери, платіжні системи.
• Пошта на домені. Якщо разом із доменом змінюються адреси email, плануємо це окремо, щоб не загубити листи клієнтів.

Ще одна деталь: перед купівлею нового домену ми перевіряємо його історію. Домен, на якому раніше був спам-сайт, може мати санкції чи погане посилальне оточення — і переїзд на нього нашкодить замість допомогти.

Після запуску: моніторинг перших тижнів

Коливання позицій після міграції — нормальне явище. Пошуковій системі потрібен час, щоб обійти нові адреси й переклеїти до них сигнали. Наше завдання — відрізнити звичайне коливання від реальної проблеми й відреагувати раніше, ніж вона вдарить по заявках.

Коли	Що перевіряємо
Перші 1–3 дні	Помилки 404 і 5xx у логах, роботу редиректів, аналітику, форми, robots.txt
Перші 2 тижні	Звіт індексування в Search Console, сканування, трафік за ключовими сторінками
1–2 місяці	Позиції й кліки порівняно з базовою точкою, переїзд сторінок в індексі
3–6 місяців	Стабілізація, нові можливості: покращення мета-тегів, контенту, структури

Найкорисніше джерело в перші дні — звіт «Сторінки» в Search Console і серверні логи: вони показують, які адреси робот запитує і що отримує у відповідь. Якщо бачимо багато 404 на старих URL — дописуємо редирект. Якщо важлива сторінка має статус «Виявлено, наразі не проіндексовано» — перевіряємо перелінковку та карту сайту.

За нашим досвідом, при акуратному переїзді трафік повертається до попереднього рівня протягом кількох тижнів, рідше — пари місяців. Якщо ж через місяць показники все ще суттєво нижчі, це сигнал шукати системну помилку, а не чекати.

Як це виглядає на практиці

Типова ситуація: компанія з продажу обладнання вирішує перейти зі старої самописної системи на WordPress і заодно змінити домен після ребрендингу. На старому сайті кілька сотень сторінок, частина з них — товари з адресами на кшталт /catalog/item.php?id=…, плюс десятки PDF-інструкцій, на які посилаються дилери. Розробник уже почав верстати нові шаблони, і про SEO згадали за місяць до запуску.

Ми починаємо з інвентаризації й одразу бачимо, що помітну частину органічних входів дають саме PDF-інструкції та кілька старих статей, яких немає в новій структурі. Тому спершу домовляємося перенести їх, а не «почистити». Далі складаємо карту редиректів: товари зіставляємо за артикулом, категорії й статті — вручну. На тестовому стенді знаходимо забутий noindex у шаблоні категорій і розмітку товарів без ціни. Запускаємо у вівторок, у перший тиждень дописуємо кілька десятків редиректів для адрес, які знайшлися лише в логах. Трафік коливається пару тижнів і повертається до попереднього рівня — без драми і без втрачених заявок. Конкретні терміни залежать від розміру сайту, тому ми їх не обіцяємо, але порядок дій щоразу той самий.

Помилки, які ми виправляємо найчастіше

Більшість «провалених» переїздів, які до нас приходять, мають одну або кілька причин із цього списку:

1. Забутий noindex. Заборона індексації, поставлена на тестовому стенді, переїхала на бойовий сайт.
2. Редиректи на головну замість точних відповідників — і всі сторінки, що мали позиції, втратили їх одночасно.
3. Тимчасові 302 замість постійних 301, бо так «за замовчуванням» налаштовано плагін.
4. Втрачений контент: тексти категорій, FAQ і відгуки не перенесли, «бо в новому дизайні для них немає місця».
5. Відпущений старий домен через рік після переїзду — разом із ним зникли всі редиректи й вага посилань.
6. Аналітику не перенесли або перенесли без цілей, і ніхто не може сказати, що сталося із заявками.

Короткий чекліст міграції

• Повний список старих URL зібрано з краулера, Search Console, аналітики й карти сайту.
• Збережено знімок SEO-елементів і базові показники трафіку та позицій.
• Карта редиректів 301 один до одного, без ланцюжків і масових переходів на головну.
• Контент, мета-теги, розмітка й hreflang перенесено без втрат.
• Тестовий стенд закритий паролем, сайт просканований, редиректи протестовані.
• У день запуску знято noindex, оновлено robots.txt і карту сайту, налаштовано Search Console.
• Для нового домену використано «Зміну адреси», старий домен продовжено.
• Щоденний моніторинг перші тижні й порівняння з базовою точкою.

Часті запитання

Чи можна переїхати взагалі без просідання трафіку?

Короткі коливання бувають майже завжди, навіть при ідеальній підготовці. Але при правильних редиректах і збереженому контенті вони невеликі й швидко минають. Серйозне падіння на місяці — ознака помилки, а не «нормальна плата за переїзд».

Скільки часу тримати редиректи?

Якомога довше. Google радить щонайменше рік, але ми не бачимо причин їх колись вимикати: вони майже нічого не коштують, а старі посилання й закладки живуть роками.

Чи можна одночасно змінити домен, CMS і дизайн?

Можна, але ризик зростає, а знайти причину проблеми стає важче. Якщо бізнес дозволяє, ми розносимо зміни в часі. Якщо ні — компенсуємо це особливо детальною картою редиректів і тестуванням.

Коли варто залучити SEO-фахівця?

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

Підсумок

Переїзд сайту на новий домен чи нову CMS — не лотерея, а проєкт із чіткими етапами: інвентаризація, карта редиректів, перенесення контенту, тестування, акуратний запуск і моніторинг. Більшість втрат трафіку стається не через складність задачі, а через поспіх і пропущені кроки.

Якщо ви плануєте міграцію, — напишіть нам ще до старту розробки. Ми підготуємо карту редиректів, перевіримо новий сайт перед запуском і супроводимо перші місяці в межах просування сайту. А якщо переїзд пов’язаний із новою платформою для магазину, допоможемо з розробкою інтернет-магазину, де SEO враховане з першого дня.