Як перенести домен, не обваливши пошукові позиції

Зміна домену — один із небагатьох SEO-проєктів, де технічно невелика помилка може дуже швидко стати дуже помітною. Відсутній редирект, заблокований шлях для сканування або забутий canonical можуть перетворити простий ребрендинг на тижні нестабільності позицій.

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

Почніть з інвентаризації, а не з правила редиректу

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

Перш ніж торкатися DNS, складіть список важливих URL:

• URL, які отримують органічний трафік
• URL із зовнішніми зворотними посиланнями
• URL, які конвертують, генерують ліди або підтримують кампанії
• Canonical URL, які зараз є у вашій XML-мапі сайту
• PDFs, зображення та файли для завантаження, на які є зовнішні посилання
• Цінні застарілі URL, яких може не бути в поточній навігації

Для кожного старого URL призначте ціль на новому домені. У більшості випадків це має бути та сама сторінка з тим самим наміром. Якщо /pricing стає https://newdomain.com/pricing, це просто. Якщо три старі сторінки продуктів об’єднуються в один новий посібник, свідомо задокументуйте це рішення.

Уникайте лінивого шаблону: редиректити все на нову головну сторінку. Це зручно, але викидає релевантність. І пошукові системи, і користувачі очікують, що цільова сторінка відповідатиме на ту саму потребу, що й початковий URL.

Зберігайте структуру URL там, де можете

Міграція домену простіша, коли шляхи залишаються стабільними. Перехід з oldsite.com/blog/example на newsite.com/blog/example значно чистіший, ніж одночасна зміна домену, CMS, slug, структури папок і контенту.

Іноді редизайн або міграція CMS роблять зміни URL неминучими. Якщо так, розділіть рішення:

1. Що змінюється через зміну домену?
2. Що змінюється через зміну структури сайту?
3. Що видаляється, об’єднується або переписується?

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

Використовуйте постійні редиректи в один перехід

Для справжньої міграції домену використовуйте серверні редиректи 301 або 308 зі старих URL на їхні нові еквіваленти. Тимчасові редиректи — для тимчасових ситуацій. JavaScript-редиректи, meta refresh і soft redirects є слабшими сигналами та їх легше зламати.

Ваші цілі щодо редиректів прості:

• Кожен важливий старий URL повертає постійний редирект.
• Кожен редирект веде безпосередньо до фінальної цілі.
• HTTP чисто редиректить на HTTPS.
• Варіанти з www і без www обробляються послідовно.
• Редиректи не залежать від крихкої поведінки query string, якщо це не потрібно.

Поганий ланцюжок виглядає так:

http://oldsite.com/page → https://oldsite.com/page → https://www.oldsite.com/page → https://newsite.com/page → https://www.newsite.com/page

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

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

Підготуйте DNS і сертифікати до запуску

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

Також потрібні чинні TLS-сертифікати для обох доменів. Це легко випустити з уваги. Старий домен після міграції все ще має віддавати HTTPS-редиректи. Якщо його сертифікат спливе, користувачі й сканери можуть натрапити на попередження браузера ще до того, як дістануться нового сайту.

Якщо переїзд впливає на email, не ставтеся до цього як до другорядного завдання. Зміни домену часто ламають SPF, DKIM, DMARC, MX records, tracking links і transactional mail. Щоб освіжити в пам’яті важливі записи, перегляньте наш дружній до розробників посібник з MX, SPF, DKIM і DMARC.

Перевірте canonical, внутрішні посилання та мапи сайту

Після запуску новий домен має поводитися так, ніби він завжди був canonical-домом для контенту.

Це означає:

• Canonical tags вказують на нові URL, а не на старий домен.
• Внутрішні посилання використовують новий домен або root-relative paths.
• XML sitemaps містять лише фінальні, індексовані нові URL.
• hreflang annotations, якщо використовуються, посилаються на нові URL.
• Open Graph, structured data та alternate links оновлені.
• Robots.txt не блокує важливі розділи.

Не публікуйте sitemap, повний старих URL, очікуючи, що редиректи все приберуть. Sitemap має бути списком URL, які ви хочете індексувати. Після міграції це означає фінальні URL на новому домені.

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

Не змінюйте все в день запуску

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

Це не забобон. Це дисципліна налагодження. Якщо позиції впадуть після запуску, вам потрібно знати, чи причина в мапінгу редиректів, доступі для сканування, зміненому контенті, повільнішому рендерингу, відсутніх structured data чи в чомусь іншому.

Зробіть початковий запуск настільки близьким до старого сайту, наскільки це практично. Коли новий домен стабілізується, вносьте більші редакційні та дизайнерські зміни меншими партіями.

Повідомте пошуковим системам, що змінилося

У Google Search Console підтвердьте і старий, і новий домени. Потім використайте інструмент Change of Address, коли переїзд є зміною на рівні домену, а контент переноситься на новий домен. Після запуску надішліть новий sitemap.

Це не замінює редиректи. Це їх підтримує. Пошуковим системам усе ще потрібні доступні для сканування, постійні редиректи, щоб зрозуміти мапінг на рівні URL.

Для Bing та інших пошукових систем використовуйте їхні webmaster tools, якщо доступні. Також оновіть місця, які ви контролюєте: соціальні профілі, бізнес-каталоги, цільові сторінки реклами, підписи в email, документацію, партнерські посилання та canonical references у синдикованому контенті.

Не всі зовнішні посилання буде оновлено, і це нормально. Але найважливіші варто оновити. Якщо великий партнер, app marketplace, documentation portal або press page посилається на старий домен, попросіть оновлення.

Моніторте правильні речі після запуску

Перші кілька днів після міграції мають бути активним моніторингом, а не святкуванням.

Перевіряйте:

• Server logs щодо активності сканування на старому й новому доменах
• 404s і неочікувані 5xx errors
• Ланцюжки та петлі редиректів
• Статус індексації в Search Console
• Виявлення та обробку sitemap
• Органічні landing pages і шаблони запитів
• Conversion paths, що залежать від старих URL
• Analytics filters і referral exclusions

Очікуйте шум у звітності. Деякі інструменти аналітики вважають новий домен новою property, якщо їх не налаштувати належно. Деякі dashboards порівнюють трафік старого домену з трафіком нового домену й роблять міграцію гіршою, ніж вона є.

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

Продуктивність також не слід ігнорувати. Якщо новий домен запускається з важчими шаблонами, зламаним кешуванням або неоптимізованими ресурсами, користувачі можуть відчути міграцію як уповільнення. Якщо ви використовуєте Lighthouse як частину перевірок, читайте його з урахуванням пріоритетів; наш матеріал про те, як читати звіт Lighthouse без паніки, пояснює, як відокремити суттєві проблеми від шуму.

Зберігайте старий домен надовго

Не дозволяйте старому домену спливти після того, як міграція «запрацює». Тримайте його зареєстрованим, підтримуйте чинні сертифікати й залишайте редиректи активними якомога довше. На практиці це часто означає роки.

Старі посилання продовжують існувати в блогах, закладках, документації, PDFs, emails і social posts. Редиректи — це міст між цим історичним слідом і новим доменом. Вимкнення їх надто рано ламає шляхи користувачів і марнує накопичені сигнали.

Також збережіть копію мапи редиректів і нотаток запуску. Через шість місяців, коли хтось запитає, чому застарілий URL поводиться певним чином, ви будете раді, що це задокументували.

<!-- tool-cta:start -->

💡 Спробуйте це: Після переходу відстежте свої старі URL-адреси через Redirect Checker, щоб підтвердити, що кожна з них спрямовується одним 301-переходом на правильну нову сторінку.

<!-- tool-cta:end -->

Розумний чекліст міграції

Перед запуском:

• Підтвердьте обидва домени в Search Console.
• Проскануйте поточний сайт і експортуйте важливі URL.
• Створіть one-to-one redirect map.
• Зменште DNS TTLs.
• Підготуйте TLS-сертифікати для старого й нового доменів.
• Оновіть canonicals, internal links, hreflang, structured data і sitemaps.
• Протестуйте редиректи в staging або контрольованому середовищі.

У день запуску:

• Розгорніть редиректи.
• Підтвердьте поведінку HTTP to HTTPS.
• Протестуйте важливі зразки URL з кожного типу шаблону.
• Надішліть новий sitemap.
• Використайте інструмент Change of Address, де це доречно.
• Стежте за server errors, redirect loops і blocked resources.

Після запуску:

• Моніторте crawl errors і indexing reports.
• Оновіть важливі зовнішні посилання там, де можете.
• Порівнюйте трафік за наміром landing page, а не лише за сумарними показниками доменів.
• Тримайте редиректи активними безстроково.
• Відкладіть непов’язаний редизайн або контентні експерименти, доки переїзд не стабілізується.

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