Міграція сайту і зміна URL

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

Основа — посібник Google про переїзд сайту зі зміною URL і окремий посібник про зміну хостингу, коли адреси не змінюються.

Який це випадок

• Адреси змінюються (HTTP на HTTPS, новий домен, обʼєднання доменів, нові шляхи): потрібен посібник про переїзд зі зміною URL;
• Адреси лишаються, змінюється хостинг або підключається CDN: окремий посібник. Переїзд починається з перемикання DNS, а стару інфраструктуру вимикають, коли переконалися, що всі користувачі, зокрема Googlebot, отримують контент з нової. Тестовий сайт закривають від індексування правилом noindex.

Принципи: змінюйте одне за раз

• Одна зміна за раз. Якщо хочете змінити домен, систему керування й оформлення, робіть їх по черзі: спершу домен, потім оформлення. Найнебезпечніший варіант — новий дизайн, нова CMS, нові URL і чищення контенту в одному релізі — прямо суперечить цій пораді;
• Час із низьким трафіком. Якщо можливо, обирайте періоди спаду, щоб зачепити менше людей і дати серверу більше ресурсів для Googlebot;
• Одразу чи частинами. Малим і середнім сайтам радять переїжджати цілком одночасно: це допомагає користувачам і прискорює розпізнавання переїзду. Великі сайти можна переносити за розділами; для проби беруть розділ, що змінюється рідше;
• Терпіння. Для сайту середнього розміру потрібно кілька тижнів або більше, щоб Google поступово почав показувати нові URL замість старих, для великих — довше. Переїзд іде по кожному URL окремо й вважається завершеним, коли Googlebot побував на кожній адресі старого й нового сайту хоча б раз. Фіксованої частоти обходу немає.

Підготовка нового сайту

1. Список старих URL. Почніть із важливих: мапи сайту, найвідвідуваніші адреси за логами чи аналітикою, сторінки з посиланнями зі звіту Search Console, список із CMS. Додайте URL зображень, відео, JavaScript і CSS: їх переносять так само, як решту;
2. Відповідність старих і нових адрес. Для кожного старого URL визначте, куди він веде. Для зміни домену може вистачити правила для всього домену;
3. Налаштувати нову систему. Бажано ту саму CMS, що на старому сайті; перенести зображення й файли для завантаження. Див. урок про вибір CMS;
4. robots.txt і noindex. Багато хто закриває сайт під час розробки. Заздалегідь підготуйте, як має виглядати файл на момент переїзду, і список сторінок, з яких треба буде зняти noindex. Див. урок про robots.txt і meta robots;
5. Видалений контент. Адреси, які не переносите, мають на новому сайті віддавати код 404 або 410;
6. Анотації на новому сайті. Кожному новому URL — самопосилальний canonical; якщо є hreflang, оновіть його на нові адреси; внутрішні посилання замініть на нові. Див. тег canonical;
7. Search Console. Підтвердьте обидва сайти, усі варіанти (www і без, HTTPS і HTTP). Переконайтеся, що метод підтвердження продовжить працювати на новому сайті; перегляньте налаштування старого сайту, наприклад файл відхилених посилань;
8. Потужності сервера. Після переїзду Google тимчасово обходить новий сайт інтенсивніше: до звичайних обходів додаються обходи старих адрес із перенаправленням. Переконайтеся, що нового вистачить.

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

Перенаправлення

Використовуйте серверні постійні перенаправлення (301 або 308); клієнтські — лише якщо інакше не можна. Уникайте ланцюжків: Googlebot проходить до 10 ланок, але краще вести одразу на кінцеву адресу; якщо не можна — в ідеалі не більше 3 і менше 5. І не відправляйте багато старих адрес на одну нерелевантну, наприклад на головну: це може бути сприйнято як soft 404. Виняток — обʼєднання кількох сторінок в одну. Докладніше — в уроці про редиректи. Гарна новина: 301 та інші постійні перенаправлення не призводять до втрати PageRank.

Запуск

1. Увімкніть перенаправлення.
2. Перевірте, що canonical на новому сайті вказує на нові адреси, а тимчасові noindex зняті.
3. Протестуйте перенаправлення: для окремих адрес перевірка URL, для багатьох — скрипти або перевірка редиректів.
4. Якщо змінюється домен чи піддомен, надішліть у Search Console заявку про зміну адреси. Для HTTP на HTTPS, для www і без www та для зміни шляхів у межах домену вона не потрібна. За зміни домену подайте її для всіх підтверджених варіантів старого.
5. Зберігайте перенаправлення якомога довше, зазвичай щонайменше рік.
6. Надішліть нову мапу сайту; стару можна прибрати. Див. урок про XML-мапи.
7. Одразу оновіть посилання: внутрішні, зовнішні (попросіть власників сайтів зі списку), профілі в соцмережах, рекламні кампанії.

Моніторинг

• Мапи сайту. Надішліть обидві: стару й нову. Спершу в новій буде нуль проіндексованих сторінок, а в старій багато; з часом це дзеркально змінюється. Попередження про перенаправлення в старій мапі нормальні й їх можна ігнорувати. Стежити за цим зручно через моніторинг мапи сайту;
• Індексування й запити. Звіт про індексування покаже спад на старому й зростання на новому сайті; у звіті за запитами почнуть зʼявлятися адреси нового сайту. Стежте за несподіваними помилками обходу, як-от «не знайдено», і за адресами, що помилково ведуть на неіснуючі. Масово перевіряти статуси — аудит URL; 404 — органічні 404;
• Логи й аналітика. Дивіться на обходи Googlebot, адреси з несподіваними помилками та звичайний трафік. На старому сайті трафік має падати, на новому зростати.

Типові помилки за документацією

• Лишилися noindex або блокування в robots.txt, потрібні лише на час міграції. Якщо robots.txt немає, він має віддавати 404;
• Неправильні перенаправлення: на неіснуючі адреси нового сайту;
• старі canonical і hreflang, що вказують на старі адреси;
• забуті зображення, файли й ресурси.

Практика автора: паритет контенту і перші 72 години

Далі — не вимоги Google, а робочі прийоми. Паритет контенту: якщо в сторінки після редизайну зникли таблиці, FAQ чи важливі заголовки, вона відповідає на запит гірше, навіть якщо адреса й перенаправлення правильні. Звіряйте основний зміст і блоки, а мобільну версію перевіряйте окремо: Google здебільшого індексує мобільну версію контенту. Перші 72 години: переконатися, що на робочому сайті знято noindex; прогнати пачки старих адрес; перевірити, що нові адреси віддають 200 і canonical на себе; що мапа сайту містить лише підсумкові адреси; що внутрішні посилання не ведуть через перенаправлення. Обійти сайт можна краулером. Документація наводить і свій набір перевірок, він вище.

Чек-лист

1. Змінюється одне за раз; обрано час із низьким трафіком.
2. Є список старих URL із зображеннями й ресурсами та відповідність новим.
3. На новому сайті самопосилальні canonical, оновлені hreflang і внутрішні посилання.
4. Перенаправлення серверні постійні, без ланцюжків і без масового відправлення на головну.
5. Знято все, що блокувало індексування на час розробки.
6. Подано заявку про зміну адреси, якщо змінюється домен чи піддомен.
7. Нову мапу сайту надіслано; перенаправлення зберігаються щонайменше рік.
8. Іде моніторинг обох сайтів.

Помилки

• Змінювати все в одному релізі.
• Подавати заявку про зміну адреси під час переходу на HTTPS.
• Лишати noindex і блокування з тестового сайту.
• Знімати перенаправлення за пару місяців.
• Вважати переїзд завершеним у день запуску.

Що далі

Правила адрес, на яких будується будь-який переїзд, — в уроках про структуру URL та домени й піддомени.