Міграція домену WordPress без втрати SEO: 301s, канонікали, карти сайту і нуль драм

Що ви фактично змінюєте (і чому SEO дратується)

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

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

• HTTP-редиректи (зазвичай 301), які зіставляють старі URL з новими еквівалентами.
• Теги canonical які кажуть «переважна URL цієї сторінки — тут» (rel=canonical).
• Карти сайту які перераховують нові URL і допомагають відкриттю для індексації.
• Внутрішні посилання, оновлені, щоб більше не шкодити самим собі старо-доменними посиланнями.
• Послідовна поведінка відповіді (коди статусу, кешованість, контент), що не виглядає як обман.

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

Факти та контекст, що пояснюють дивні речі

Кілька коротких конкретних історичних та механічних моментів. Це не дрібниці; вони пояснюють, чому деякі «хитрі скорочення» — поганий кар’єрний вибір.

1. 301 vs 302 раніше інтерпретували більш буквально. Протягом років 302 могла гальмувати передачу сигналу; сучасні рушії розумніші, але 301 усе ще стандарт для постійних переміщень.
2. Google представив концепцію rel=canonical у 2009. Вона була створена, щоб зменшити дублювання індексації, коли той самий контент існує на кількох URL — саме те, що ви створюєте під час міграції.
3. XML sitemaps стали масовими в середині 2000-х. Вони не «підвищують рейтинг», але скорочують час відкриття і допомагають швидше виявляти помилки покриття.
4. WordPress давно підтримує «Site Address (URL)» vs «WordPress Address (URL)». Неправильне розуміння цього розриву спричиняє половину самостійно спричинених аутеджів при зміні домену.
5. Браузери почали жорсткіше застосовувати mixed-content у 2010-х. HTTPS-новий домен з HTTP-ресурсами може непомітно зламати рендеринг і трекінг.
6. HTTP/2 (стандартизовано 2015) змінив модель витрат продуктивності. Ланцюги редиректів усе ще дорогі, але менше ніж в епоху «одне з’єднання на ресурс» — все одно не безкоштовні.
7. CDN популяризували агресивне кешування редиректів. Неправильний 301 може бути закешований на краю і пережити ваш хотфікс, що захоплююче так само, як дзвінок по пейджеру.
8. Пошукові системи трактують довгі ланцюги редиректів як проблему якості та ефективності. Вони можуть припинити слідувати після занадто багатьох стрибків, а бюджет краулінгу обмежений.

Одна перефразована ідея, яку варто тримати в голові, бо вона прямо застосовується тут: парафразована ідея: «Сподівання — не стратегія; вимірюйте, автоматизуйте й верифікуйте.» — Gene Kim (парафразовано)

Незмінні умови: що має бути правдою при cutover

Перш ніж чіпати DNS TTL або налаштування WordPress, визначте ці інваріанти. Це не «приємні дрібниці». Це межа між «тимчасовим падінням» і «чому нас видалили з індексу».

1) Кожен старий URL повертає односкоковий 301 на свій новий еквівалент

Не «головна сторінка для всього», не 302 «поки що», не ланцюг типу old → http new → https new → www new. Один стрибок. Тримайте це нудним.

2) Нові сторінки самі канонізуються на новий домен

Коли краулер заходить на новий домен, canonical повинен вказувати на новий домен. Якщо канонікали все ще посилаються на старий домен, ви говорите Google віддавати перевагу старим URL… водночас роблячи редиректи з цих URL. Це конфлікт, і конфлікти не ранжуються.

3) Внутрішні посилання припиняють вказувати на старий домен

Редиректи для зовнішніх користувачів. Ваш власний сайт не має їх потребувати. Внутрішні старо-доменні посилання збільшують марнування краулінгу й ховають проблеми з контентом.

4) Карти сайту й robots.txt відображають нову реальність

Опублікуйте карти сайту, які перераховують тільки нові URL. robots.txt не повинен випадково блокувати важливі шляхи тому, що хтось скопіював правило для staging.

5) Виживають трекінг і критичні інтеграції

Аналітика, callback-и оплат, OAuth redirect URIs, webhooks, CSP заголовки, шаблони листів і маркетингові пікселі — усе чутливе до домену. Зберіть їх у список наперед.

Жарт №1: Міграція домену без мапи редиректів — як змінити адресу офісу й потім дивуватися, чому листи приходять на «Невідомий мешканець».

Швидка діагностика (перевірте в цьому порядку)

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

Перше: чи редиректи правильні й односкокові?

• Візьміть 20 URL з найбільшим трафіком з аналітики і перевірте коди статусу, заголовки Location і кількість стрибків.
• Підтвердіть, що рішення HTTP→HTTPS і non-www→www не створюють додаткових стрибків.
• Підтвердіть, що старий домен повертає тільки редиректи (можливо окрім ACME challenges).

Друге: чи канонікали послідовні?

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

Третє: чи краулери можуть виявляти й отримувати нові URL ефективно?

• Переконайтесь, що карти сайту завантажуються, не блокуються і містять правильний хост.
• Перевірте robots.txt: немає випадкового disallow, директива sitemap вказує на новий домен.
• Підтвердіть стабільність відповідей сервера: немає сплесків 5xx, немає блокувань WAF для Googlebot.

Четверте: чи випадково ви дублюєте сайт на кількох хостах?

• Переконайтесь, що тільки один «переважний» хост доступний для індексації (www vs apex). Інші хости повинні 301.
• Переконайтесь, що старий домен не повертає 200 OK сторінки через обхід (origin IP, забутий vhost).

П’яте: чи кеші вам брешуть?

• Очистіть CDN-кеші для редиректів і HTML.
• Перевірте, чи «поганий 301» не був закешований з довгим TTL.
• Підтвердіть, що кеш сторінок WordPress не повертає старі теги canonical.

Чеклісти / покроковий план (pre-flight → post-flight)

Фаза 0: Визначте, що означає «той самий URL»

Якщо ви змінюєте тільки домен (oldsite.com → newsite.com), але зберігаєте шляхи однаковими, життя простіше. Якщо ви також змінюєте структуру permalink, об’єднуєте категорії або «очищаєте контент», зупиніться. Розділіть це на два проекти. Міграція домену вже сама по собі достатньо ризикована.

Фаза 1: Інвентар та мапування

• Експортуйте список індексованих URL (Search Console), основні сторінки приземлення (аналітика) і URL карти сайту (старий).
• Створіть мапу редиректів: старий URL → новий URL, включно з крайовими випадками (trailing slash, uppercase, legacy assets).
• Визначте переважний хост: apex чи www. Оберіть один і дотримуйтеся.

Фаза 2: Побудуйте новий сайт паралельно

• Підніміть новий домен у staging з HTTPS.
• Встановіть WordPress Home/Site URLs на новий домен контрольовано.
• Оновіть внутрішні посилання, URL медіа за потреби та поведінку canonical.
• Згенеруйте нові карти сайту і підтвердіть, що вони перераховують лише URL нового хоста.

Фаза 3: Попередня перевірка перед cutover

• Пропустіть краул по staging/new домену і перевірте canonical, коди статусу та розподіл хостів у внутрішніх посиланнях.
• Протестуйте правила редиректів на вибірці старих URL перед тим, як світ побачить зміни.
• Знизьте DNS TTL заздалегідь (не за п’ять хвилин до cutover).

Фаза 4: Cutover

• Увімкніть редиректи на старому домені (переважно на рівні сервера).
• Переключіть DNS або маршрутизацію балансувальника для нового домену.
• Перевірте сертифікати (і старі, і нові, якщо старий повертає HTTPS-редиректи).
• Спостерігайте логи і рівень помилок, ніби від цього залежить результат.

Фаза 5: Прибирання після cutover (перші 72 години)

• Надішліть нові карти сайту, запросіть індексацію ключових сторінок.
• Моніторьте 404 і цикли редиректів; виправляйте прогалини в мапі.
• Оновіть сторонні інтеграції та дозволені домени.
• Тримайте редиректи старого домену живими довго (думаючи про 1 рік+; і довше — нормально).

Практичні завдання з командами, виводами й рішеннями (12+)

Це перевірки виробничого рівня. Кожна має: команда → типовий вивід → що це означає → яке рішення далі. Запускайте їх з shell з мережею до вашого сайту та, коли потрібно, до ваших серверів.

Завдання 1: Перевірте, що один URL робить чистий односкоковий 301

cr0x@server:~$ curl -I https://old.example.com/products/widget
HTTP/2 301
date: Sat, 27 Dec 2025 10:11:02 GMT
location: https://new.example.com/products/widget
cache-control: max-age=3600

Що означає вивід: HTTP 301 — правильно; Location вказує на точний новий URL; тут не показано проміжних стрибків.

Рішення: Якщо Location вказує на головну сторінку або неправильний шлях, ваша мапа редиректів неповна або занадто загальна. Виправте правила до cutover або поки не пошириться шкода індексації.

Завдання 2: Виміряйте кількість стрибків редиректу (ланцюги вбивають ефективність)

cr0x@server:~$ curl -s -o /dev/null -w "%{url_effective} %{num_redirects} %{http_code}\n" -L https://old.example.com/products/widget
https://new.example.com/products/widget 1 200

Що означає вивід: Один редирект і потім 200 на фінальному URL.

Рішення: Якщо num_redirects > 1, зменшіть стрибки, об’єднавши правила (наприклад, поєднати http→https і нормалізацію хоста в один редирект, де можливо).

Завдання 3: Підтвердіть, що старий домен ніколи не повертає 200 контент

cr0x@server:~$ curl -I https://old.example.com/
HTTP/2 301
location: https://new.example.com/

Що означає вивід: Старий домен є строго редиректором.

Рішення: Якщо ви бачите HTTP 200 з HTML, у вас два індексовані екземпляри. Це дублювання контенту і канонічна плутанина. Зробіть старий домен тільки-редиректним.

Завдання 4: Перевірте теги canonical на новому домені

cr0x@server:~$ curl -s https://new.example.com/products/widget | grep -i -m1 canonical

Що означає вивід: Canonical вказує на новий хост і правильний шлях.

Рішення: Якщо він вказує на old.example.com, ви кажете краулерам віддавати перевагу старому домену. Виправте налаштування WordPress, конфіг SEO-плагіна й будь-яку хардкодну поведінку теми.

Завдання 5: Виявити mixed content (поширено після HTTPS-міграції)

cr0x@server:~$ curl -s https://new.example.com/ | grep -Eo 'src="http://[^"]+' | head
src="http://old.example.com/wp-content/uploads/2023/hero.jpg

Що означає вивід: HTML містить HTTP-URL ресурсів (і на старому домені).

Рішення: Замініть у базі даних і/або застосуйте переписування контенту. Mixed content може ламати рендеринг сторінки й тихо погіршувати SEO-сигнали.

Завдання 6: Підтвердіть, що карта сайту перераховує новий хост

cr0x@server:~$ curl -s https://new.example.com/sitemap_index.xml | head -n 12



https://new.example.com/post-sitemap.xml

Що означає вивід: Індекс карти сайту існує і посилається на sitemaps на новому домені.

Рішення: Якщо loc-елементи вказують на старий домен або http, виправте налаштування генератора sitemap і очистіть кеші.

Завдання 7: Перевірте, що robots.txt не блокує новий сайт

cr0x@server:~$ curl -s https://new.example.com/robots.txt
User-agent: *
Disallow:
Sitemap: https://new.example.com/sitemap_index.xml

Що означає вивід: Немає глобального disallow; sitemap вказує правильно.

Рішення: Якщо ви бачите Disallow: / або staging-правила, виправте негайно. Один поганий robots.txt може зробити ваші прекрасні редиректи неважливими.

Завдання 8: Переконайтесь, що WordPress Home/Site URLs вірні через WP-CLI

cr0x@server:~$ wp option get home
https://new.example.com
cr0x@server:~$ wp option get siteurl
https://new.example.com

Що означає вивід: WordPress вважає, що живе на новому домені для обох значень.

Рішення: Якщо це старий домен (або невідповідність), виправте через WP-CLI і очистіть кеші. Невідповідність home/siteurl створює цикли редиректів і зламані сесії в адмінці.

Завдання 9: Знайдіть рядки зі старим доменом у базі (dry run)

cr0x@server:~$ wp search-replace 'old.example.com' 'new.example.com' --dry-run --all-tables
+-----------------------+--------------+--------------+
| Table                 | Column       | Replacements |
+-----------------------+--------------+--------------+
| wp_posts              | post_content | 812          |
| wp_postmeta           | meta_value   | 144          |
| wp_options            | option_value | 19           |
+-----------------------+--------------+--------------+
Success: 975 replacements to be made.

Що означає вивід: Посилання на старий домен вбудовані в контент/мета/опції.

Рішення: Плануйте реальний прогін у вікні техобслуговування з попереднім бекапом. Якщо замін дуже багато, врахуйте наявність серіалізованих даних і покладіться на безпечну обробку WP-CLI (воно підтримує серіалізацію).

Завдання 10: Виконайте заміну (після бекапу)

cr0x@server:~$ wp search-replace 'old.example.com' 'new.example.com' --all-tables --precise
Success: Made 975 replacements.

Що означає вивід: Посилання в базі оновлено.

Рішення: Негайно очистіть кеш сторінок і об’єктів. Потім повторно перевірте теги canonical і хости у внутрішніх посиланнях за допомогою швидкого краулу або вибіркового grep.

Завдання 11: Знайдіть топ 404 у логах NGINX після cutover

cr0x@server:~$ sudo awk '$9==404 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head
48 /wp-content/uploads/2019/legacy-logo.png
31 /category/old-campaign/
19 /products/widget-pro/

Що означає вивід: Ці шляхи запитуються й повертають 404.

Рішення: Додайте таргетовані редиректи або відновіть відсутні ресурси. Для сторінок контенту мапуйте на найкращі еквіваленти. Для ресурсів або подавайте їх, або редиректіть на нове місце; уникайте редиректу кожного браку на головну сторінку.

Завдання 12: Підтвердіть покриття TLS сертифікатами для обох доменів

cr0x@server:~$ echo | openssl s_client -servername old.example.com -connect old.example.com:443 2>/dev/null | openssl x509 -noout -subject -issuer -dates
subject=CN = old.example.com
issuer=CN = R3, O = Let's Encrypt
notBefore=Dec 10 00:00:00 2025 GMT
notAfter=Mar  9 23:59:59 2026 GMT

Що означає вивід: Старий домен має дійсний сертифікат, що важливо, якщо він редиректить по HTTPS.

Рішення: Якщо сертифікат старого домену недійсний/просрочений, браузери й краулери можуть не слідувати редиректам надійно. Оновіть його й автоматизуйте оновлення; не дозволяйте старому домену гнити.

Завдання 13: Перевірте нормалізацію хоста (www vs apex)

cr0x@server:~$ curl -I https://new.example.com/ | sed -n '1,5p'
HTTP/2 301
location: https://www.new.example.com/

Що означає вивід: new.example.com редиректить на обраний канонічний хост (www у цьому прикладі).

Рішення: Переконайтесь, що кожен непереважний хост 301 до переважного. Потім упевніться, що сам WordPress налаштований генерувати переважний хост у посиланнях і канонікалах.

Завдання 14: Швидко ідентифікуйте цикли редиректів

cr0x@server:~$ curl -I -L --max-redirs 5 https://old.example.com/wp-admin/ 2>&1 | tail -n 6
curl: (47) Maximum (5) redirects followed

Що означає вивід: Існує цикл — часто спричинений конфліктними редиректами між WordPress, веб-сервером і CDN.

Рішення: Проаналізуйте, де відбувається зміна хоста/протоколу/шляху. Потім виберіть один шар для нормалізації (переважно edge/web server) і налаштуйте WordPress відповідно.

Стратегія редиректів: 301s, що не розплавлять систему

Редиректи — це хребет міграції. Якщо вони неправильні, усе інше стає пластирем на зламаній нозі.

Принципи, що витримують навантаження

• Використовуйте редиректи на рівні сервера, а не плагіна WordPress. Ви хочете, щоб редиректи працювали навіть якщо PHP впаде, і щоб вони були швидкими.
• Віддавайте перевагу точним мапам для топ-сторінок. Для довгого хвоста загальне правило підходить (той самий шлях на новому домені), але не гадьте для цінних сторінок.
• Уникайте ланцюгів редиректів. Мета — один стрибок. Два — терпимо в аваріях. Три — і ви місяцями будете дебажити «чому Google не бачить».
• Не редиректіть усе на головну сторінку. Це патерн soft-404 і викидає сигнали релевантності.
• Тримайте редиректи довго. Зовнішні посилання й закладки не закінчуються тому, що у вас є дорожня карта.

Nginx приклад: зі старого домену на новий, збереження URI

cr0x@server:~$ sudo nginx -T | sed -n '1,40p'
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
# ...snip...
server {
    listen 443 ssl http2;
    server_name old.example.com;

    return 301 https://www.new.example.com$request_uri;
}

Що означає вивід: Тест конфігурації Nginx пройшов; server block повертає одиночний 301, зберігаючи шлях і рядок запиту.

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

Apache приклад: old → new у vhost або .htaccess

Apache працює добре; просто уникайте накладання правил так, щоб виникали цикли або зайві стрибки. Якщо можете розмістити редиректи у конфігу vhost, а не в .htaccess, робіть так для продуктивності й ясності.

Query strings: зберігайте їх, якщо немає причин не робити цього

Параметри кампаній і трекінгові query string-і повинні передаватися. Обрізання їх може спростити логи, але ви будете «сліпі» в ті тижні, коли найбільше потрібна атрибуція.

Жарт №2: Закешований 301 на CDN-краю — як гліттер: як тільки він неправильний, він неправильний усюди і назавжди.

Канонікали: тихий вбивця ваших позицій

Якщо редиректи — це хребет, то канонікали — нервова система. Вони не завжди з’являються в «базових перевірках», але контролюють, який URL отримає кредит.

Як повинні виглядати теги canonical під час і після міграції

• На новому домені: canonical вказує на новий URL (самореферентний canonical — нормальний).
• На старому домені: бажано не повертати 200 сторінки, а тільки редиректи. Якщо тимчасово подаєте контент, канонікали все одно мають вказувати на новий домен — акуратно і послідовно.
• Обирайте один варіант хоста: www або apex. Canonical має точно йому відповідати.
• HTTPS скрізь: canonical має бути https, якщо це ваша канонічна схема.

Де канонікали ламаються в WordPress

• Конфіг SEO-плагіна прив’язана до старого URL сайту. Деякі плагіни зберігають абсолютні URL у налаштуваннях або кешах.
• Хардкодний canonical у шаблонах теми. Хтось «оптимізував SEO» у 2018 і лишив міну уповільненої дії.
• Кеш сторінки повертає старий HTML. Ви виправили базу, але кеш все ще віддає старі канонікали.
• Multisite і нюанси domain mapping. Генерація canonical може залежати від site ID і таблиць мапінгу; простого search-replace може бути недостатньо.

Canonical vs redirect: що перемагає?

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

Карти сайту: зробіть роботу Google нудною

Карти сайту не магічний попіл для рейтингу. Вони — операційне інструментування для індексації. Під час міграції саме це вам потрібно: швидше відкриття, чіткіший звіт і менше «невідомих невідомостей».

Правила для карт сайту після зміни домену

• Генеруйте карти сайту, в яких перераховані тільки URL нового домену.
• Розміщуйте індекс карти сайту в стабільному місці (стандартний шлях підходить).
• Переконайтесь, що карти сайту повертають 200 OK, не вимагають авторизації і не заблоковані WAF-викликами.
• Тримайте старі карти сайту доступними, якщо їх запитують, але вони повинні 301 на нові або бути замінені посиланнями на новий домен.

Image і video sitemaps

Якщо ваш бізнес залежить від пошуку зображень або річ-результатів, не забудьте про записи в image sitemap. Міграція домену може «працювати» для HTML, тоді як медіа-відкриття тихо падає, якщо посилання на зображення все ще ведуть на старий хост або блокуються правилами hotlink.

Search Console та аналітика: доведіть, що воно спрацювало

Тут ви перетворюєте «думаю, що все добре» на докази. Потрібні два види доказів: коректність для краулерів і поведінка для користувачів.

Необхідне в Search Console

• Додайте й верифікуйте нову властивість домену (domain-level якщо можливо).
• Надішліть нові карти сайту.
• Використайте інструмент зміни адреси (change-of-address), якщо це застосовно (при переміщенні між доменами під тією ж верифікованою власністю).
• Моніторьте звіти покриття: сплески в «Excluded», «Crawled – currently not indexed» або «Duplicate, Google chose different canonical» — це сигнал до дій.

Необхідне в аналітиці

• Оновіть параметри дефолтного URL де потрібно (залежить від вашого стеку аналітики).
• Перевірте виключення рефералів і крос-доменний трекінг, особливо для checkout flows.
• Анотируйте час міграції та великі виправлення (зміни правил редиректів, ресабміт карти сайту).

Перевірка по логах краще за відчуття дашборду

Дашборди показують результати. Логи показують причини. Протягом першого тижня вам потрібні обидва, але саме логи покажуть шаблони ботів, цикли редиректів і кластери 404 раніше, ніж агрегований звіт перетворить їх на розмите «спад».

Кешування/CDN і побічні ефекти на продуктивність

Міграції домену часто включають зміну CDN, зміну TLS-термінації або «поки тут, давайте додамо WAF». Це нормально. Це також шлях, як випадково ввести блокування краулерів і баги кешування.

Кешування редиректів: корисно, поки не стає проблемою

301 може кешуватися браузерами й проміжними вузлами. Це функція. Це також причина, через яку треба тестувати правила редиректів перед релізом. Якщо ви випустите неправильний 301 з щедрим cache-control, ви розповсюдите помилку по всіх edge-локаціях і агентам користувачів, що його отримали.

Кеш сторінок і об’єктів

Після зміни домену потрібно очистити:

• Повний кеш сторінок (плагін, reverse proxy, CDN).
• Object cache (Redis/Memcached), бо опції й рендерені фрагменти можуть там зберігатися.
• Opcode cache, якщо ви деплоїли нову конфігурацію, що впливає на генерацію URL (рідше, але не треба припускати).

WAF-правила і поведінка ботів

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

Сховище, бекапи та відкат: ставтеся до контенту як до даних

Міграції WordPress — це міграції даних. Домен — лише найбільш видима частина.

Зробіть бекап бази й uploads так, ніби хочете зберегти роботу

Потрібен моментальний знімок стану:

• База даних (якщо можливо — консистентна транзакційно).
• wp-content/uploads (і будь-які кастомні директорії контенту).
• Конфігурація: wp-config.php, vhost-и веб-сервера, правила CDN, записи DNS.

План відкату: простий, протестований і не теоретичний

Відкат для міграції домену зазвичай — це повернення DNS + маршрутизації й відключення правил редиректів. Але це працює тільки якщо:

• Старий сайт все ще може коректно віддавати початковий контент.
• Ви не мутували базу так, що вона ламає старий домен (наприклад, незворотна заміна без знімка).
• Ви можете швидко відновити дійсні сертифікати для обох доменів.

Краї кейсу сховища: захист від hotlink і legacy-ресурси

Багато сайтів мають hotlink-protection прив’язане до реферера або хоста. Коли ви міняєте домен, це може блокувати завантаження зображень на ваших власних сторінках, якщо правила не оновлені. Якщо ресурси знаходяться в object storage за CDN, перевірте заголовки хосту та поведінку підписаних URL.

Три корпоративні міні-історії з траншей міграцій

Міні-історія 1: Інцидент через неправильне припущення

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

Ніч cutover пройшла гладко до ранку, коли трафік прийшов. Платні кампанії потрапляли на старий домен і іноді коректно редиректились… іноді ні. Інколи відвідувачі бачили 200 OK старої головної сторінки, бо забутий Apache vhost все ще віддавав контент на старому хості, коли запит приходив без SNI через TLS-невідповідність. Тим часом сторінки товарів на новому домені мали canonical, що вказував на старий домен, бо SEO-плагін закешував site URLs.

Результат — ідеальний шторм «два сайти, один набір контенту». Краулери бачили дублікати. Користувачі бачили непослідовну поведінку. Внутрішні команди сперечалися, бо кожна тестувала різні URL і отримувала іншу реальність.

Вирішення було нудним: змусити старий домен редиректити на edge для всіх запитів, оновити сертифікат старого домену, очистити кеші й регенерувати канонікали. Потім два тижні чистили довгий хвіст відсутніх редиректів, виявлених у логах.

Урок: не припускайте, що рівень застосунку керує міграцією. Зробіть веб-сервер або CDN джерелом істини для old→new редиректів, а застосунок — генерувати послідовні канонікали для нового хоста.

Міні-історія 2: Оптимізація, що відбилася бумерангом

Інша організація хотіла, щоб міграція була «швидкою для краулерів». План був такий: зберегти старий сайт з 200 OK на місяць і додати rel=canonical, що вказує на новий домен, на тій самій логіці, що це збереже UX і «поступово переведе Google». Вони також використали 302 для деяких шляхів «на випадок відкату».

Звучало обережно. Насправді — ні. Вони створили три конфліктні сигнали: 200 OK на старих URL, іноді 302 редиректи і канонікали, що вказують інакше. Краулери відповіли хеджуванням: індексували обидві версії, вибирали власні канонікали і затягували консолідацію, бо нічого не виглядало авторитетним.

Потім CDN «дружньо» закешував підмножину 302 з довгими TTL. Деякі клієнти бачили старий домен тижнями; інші мігрували миттєво. Запити в сапорт стали дивними, бо користувачі були буквально в різних реальностях залежно від стану кешу.

Після гонитви привели все до послідовних 301 для всіх старих URL, зробили старий домен тільки-редиректним і прибрали складність «м’якого переходу». Індексація стабілізувалась. Позиції відновились.

Урок: міграції — не місце для неоднозначних сигналів. Якщо переміщення постійне — використовуйте 301, а не «відчуття».

Міні-історія 3: Нудно, але правильно — що врятувало день

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

Вони почали з мапи редиректів, зібраної з трьох джерел: існуючих карт сайту, топ-сторінок приземлення і логів серверу за останні 30 днів. Вони категоризували URL як: «треба мапити точно», «можна мапити правилом» і «навмисно видалено». Для видалених сторінок робили продумані редиректи до найближчих еквівалентів — не на головну — якщо не було справжнього замінника, тоді повертали 410.

Вони тестували редиректи у staging, програючи список старих URL і автоматично перевіряючи коди статусу й заголовки Location. Також перевіряли теги canonical і hostname в sitemap невеликим скриптом і не робили cutover, поки кількість помилок не була нульовою.

На cutover у них TTL DNS був знижений за дні до події, сертифікати вже видані, а кеші налаштовані з адекватними TTL для редиректів. Пост-cutover «war room» в основному дивився за графіками, що залишалися нудними, і реагував на невеликий список 404 від рідкісних legacy-ресурсів.

Урок: нудні інженерні практики — інвентар, автоматизація й верифікація — це не бюрократія. Це спосіб уникнути надмірних нарад із занадто багатьма людьми.

Поширені помилки: симптом → корінна причина → виправлення

1) Різке падіння позицій і затяжний спад після двох тижнів

Симптоми: Нові сторінки індексуються повільно; старі сторінки залишаються; «Duplicate, Google chose different canonical» зростає.

Корінна причина: Конфліктні сигнали: редиректи не послідовні, канонікали все ще вказують на старий домен або кілька варіантів хоста повертають 200.

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

2) Все редиректить на головну сторінку

Симптоми: Користувачі скаржаться «посилання не ведуть на потрібний товар»; Search Console показує soft 404; трафік довгого хвоста зникає.

Корінна причина: Надто широке правило редиректу без збереження шляху або відсутня мапа.

Виправлення: Реалізуйте host-редирект із збереженням шляху. Додайте явні редиректи для переміщених/перейменованих секцій. Використовуйте логи, щоб пріоритезувати високоволюмні 404 і виправляти їх ітеративно.

3) Нескінченні цикли редиректів

Симптоми: Браузер показує «занадто багато редиректів»; curl досягає max-redirs; вхід в адмінку ламається.

Корінна причина: Конфліктна нормалізація між CDN, веб-сервером і WordPress home/siteurl; змішане HTTP/HTTPS примусове застосування.

Виправлення: Виберіть один шар для примусу схеми й хоста (переважно edge/web server). Встановіть WordPress home і siteurl на фінальний канонічний. Переконайтеся, що X-Forwarded-Proto коректний за проксі.

4) Новий сайт завантажується, але картинки/CSS не працюють

Симптоми: Відсутній стиль, зламані зображення, помилки в консолі; метрики SEO деградують.

Корінна причина: Mixed content (http ресурси), хардкодні URL на старий домен або hotlink-protection, прив’язаний до старого хоста.

Виправлення: Пошук-заміна в базі для старих хостнеймів; оновлення правил CDN/hotlink; забезпечення HTTPS для ресурсів. Очистіть кеші.

5) Search Console показує «Submitted URL blocked by robots.txt»

Симптоми: Sitemap відправлено, але URL виключені; краулінг зупиняється.

Корінна причина: На прод випадково розгорнуто robots.txt зі staging або плагін встановлений на «Discourage search engines».

Виправлення: Виправте robots.txt і налаштування WordPress «Discourage search engines». Запитайте повторний краул і повторно надішліть карти сайту.

6) Редиректи працюють для людей, але краулери блокуються

Симптоми: В логах Googlebot отримує 403/429; індексація сповільнюється; дашборди WAF показують блокування.

Корінна причина: WAF/захист ботів не налаштований під поведінку краулерів; ліміти запитів надто жорсткі; видаються challenge-сторінки.

Виправлення: Дозвольте перевірені IP краулерів де доречно (обережно), зменшіть false positives і переконайтеся, що боти можуть отримувати карти сайту і HTML без JS-челенджів.

7) Старий домен все ще ранжує замість нового

Симптоми: SERP показує старі URL; нові URL з’являються уривчасто; беклінки не «переносяться».

Корінна причина: Старі URL повертають 200 або мають канонікали на себе; редиректи — 302 або непослідовні.

Виправлення: Переведіть на послідовні 301. Усуньте 200-відповіді на старому домені. Переконайтеся, що нові URL самі канонізуються. Тримайте редиректи стабільними довго.

FAQ

1) Як довго тримати редиректи старого домену?

Як мінімум 12 місяців. Довше безпечніше. Зовнішні посилання, закладки і повільні краулери будуть звертатися до старих URL роками.

2) Чи варто використовувати плагін для редиректів у WordPress?

Ні для масової зміни домену. Робіть редиректи на веб-сервері або CDN. Використовуйте редиректи на рівні WordPress лише для невеликої кількості редакторських правок, де потрібен UI.

3) Чи потрібно змінювати структуру permalink під час міграції домену?

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

4) Який найкращий редирект: 301 чи 308?

Обидва постійні. 308 суворо зберігає метод; 301 загальноприйнятий і універсально зрозумілий для веб-контенту. Використовуйте 301, якщо немає вагомої причини інакше.

5) Чи потрібно оновлювати внутрішні посилання, якщо редиректи працюють?

Так. Внутрішні посилання на старий домен марнують crawl budget і ховають проблеми. Оновіть їх, щоб сайт переходив напряму на канонічні URL.

6) Що щодо www vs non-www?

Оберіть один переважний хост і застосуйте його всюди: редиректи, канонікали, карти сайту і налаштування WordPress. Невідповідність тут створює дубльовані URL, що конкурують між собою.

7) Чи буде падіння трафіку в будь-якому випадку?

Зазвичай буде короткочасне коливання. Мета — мінімізувати тривалість і величину, надавши послідовні сигнали і уникаючи неефективності краулінгу (ланцюги, дублікати, заблоковані ресурси).

8) Чи можна видалити контент старого сайту одразу після міграції?

Контент можна видаляти. Інфраструктуру старого домену, яка віддає редиректи, — ні. Тримайте старий домен з швидкими, надійними редиректами по HTTPS з дійсними сертифікатами.

9) Як обробляти сторінки, що були виведені з експлуатації без заміни?

Якщо немає значимого еквіваленту, повертати 410 може бути доречно. Якщо є близький альтернативний ресурс — редиректьте на нього. Уникайте редиректу всього на головну; це виглядає як soft 404.

10) Чи потрібно перезавантажувати disavow-файли чи щось подібне?

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

Практичні наступні кроки

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

1. Складіть мапу редиректів з реальних даних (sitemaps, аналітика, логи) і протестуйте її з curl до cutover.
2. Аудитуйте канонікали та внутрішні посилання на новому домені, потім очистіть усі шари кешу, що можуть віддавати старий HTML.
3. Операціоналізуйте верифікацію: слідкуйте за логами на кластери 404, підтверджуйте односкокові редиректи і тримайте TLS та редиректи старого домену здоровими довго.

SEO під час міграції — здебільшого про зменшення неоднозначності. Дайте краулерам одну чітку історію, подавайте її послідовно і не «оптимізуйте» себе в кут.