Як перенести сайт і зберегти SEO

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

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

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

Перш ніж змінювати сайт, зберіть вихідні дані з кількох джерел: проскануйте поточний сайт, перевірте XML-карту сайту, дані аналітики про сторінки входу та Google Search Console. Жодне джерело не є повним. У карті сайту можуть бути відсутні цінні сторінки; аналітика може не показати сторінки з малим трафіком, але важливими зовнішніми посиланнями; а сканер знайде лише ті URL, до яких можна дістатися.

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

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

Зіставляйте сторінки за призначенням, а не за зручністю

Для кожної важливої старої адреси виберіть один із трьох варіантів: залишити її, перенаправити на справді відповідну сторінку або повернути навмисний 404 чи 410, якщо матеріал остаточно прибрали й заміни немає. Редирект має зберігати намір відвідувача. Перенаправлення багатьох не пов’язаних між собою адрес на головну може здаватися способом уникнути помилок, але людина потрапить не туди, куди очікувала, а значення старої сторінки не буде передано.

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

Узгодьте канонічні адреси, внутрішні посилання та карту сайту

Редирект — лише один із сигналів. На новому сайті канонічні теги мають указувати на бажану сторінку, придатну до індексації. У внутрішніх посиланнях потрібно використовувати кінцеві адреси, а не покладатися на редиректи. XML-карта сайту має містити лише канонічні URL, які повертають 200 і мають індексуватися. Сигнали мають збігатися: сторінка не повинна перенаправлятися, водночас залишаючись у карті сайту, або вказувати канонічним тегом на не пов’язану адресу.

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

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

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

1. Проскануйте тестовий сайт і перевірте коди відповідей, канонічні URL, заголовки сторінок, внутрішні посилання та індексованість.
2. Перевірте всі важливі URL із карти редиректів, а також вибірку зі звичайних шаблонів і типів адрес.
3. Переконайтеся, що в robots.txt, директивах meta robots та HTTP-заголовках випадково не заблоковано індексацію.
4. Перевірте відрендерену сторінку, а не лише початкову відповідь HTML: важливий вміст і метадані мають бути доступні.
5. Переконайтеся, що продакшн-карта сайту містить нові канонічні URL і доступна після запуску.

Для великих сайтів карту редиректів варто перевіряти автоматично. Невеликий скрипт може зробити запит до кожної старої адреси, пройти редиректи й позначити неочікувані коди відповіді, ланцюжки або адреси призначення. Така перевірка не замінить сканування сайту чи оцінювання доречності сторінок, але допоможе знайти механічні помилки до релізу.

Моніторте міграцію як програмний реліз

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

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

Надійний план міграції розглядає SEO як частину випуску: вихідні дані, зіставлення адрес, реалізація, автоматизовані перевірки й моніторинг після запуску. Для ширшого контексту перегляньте матеріал про те, з чого складається SEO та посібник з AEO/GEO. Site Analyzer також може допомогти перевірити технічну готовність вашого сайту та його підготовку до пошуку.

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