Чек-лист SEO при редизайні сайту: чому після перезапуску падає трафік, що перевірити до, під час і після запуску та як зберегти видимість у Google і ШІ.

Коротко
редизайн сайту зберігає свої позиції в пошуку, якщо сторінки, що приносять трафік, залишають свої URL (або отримують 301-редирект), текст, заголовки та внутрішні посилання, а нові шаблони лишаються доступними для сканування й швидкими. Більшість падінь після запуску спричиняють видалений контент, зламані внутрішні посилання, забутий noindex із тестового сервера або контент, що з'являється лише за допомогою JavaScript. Просканувати старий сайт слід до початку робіт, протестувати новий на захищеному тестовому сервері, а після запуску порівняти обидва.
Хочете дізнатися більше? Запитайте
SEO при редизайні сайту: це робота із захисту позицій, поки змінюються шаблони, дизайн, навігація, контент або CMS. Цей посібник стосується редизайнів зі збереженням того самого домену. Якщо змінюється домен або більшість URL, проєкт є міграцією: дотримуйтеся нашого чек-листа SEO-міграції та посібника Google про перенесення сайту зі зміною URL, який попереджає власників сайтів очікувати тимчасових коливань позицій.
Так, щоразу. Google і ШІ-асистенти, що читають вебпростір, оцінюють сторінки за тим, що знаходять у HTML: текст, заголовки, посилання, структуровані дані, швидкість. Редизайн змінює частину цих сигналів або всі, тож пошукові системи переоцінюють сторінки. Наслідки можуть бути позитивними (швидші сторінки, зрозуміліша структура, кращий контент) або негативними (бідніші сторінки, втрачені посилання). Результат визначає те, скільки сигналів ранжування зберігають нові шаблони.
| Що змінюється в редизайні | SEO-ризик | Чому |
|---|---|---|
| Лише кольори, шрифти, зображення | Низький | HTML-контент і URL залишаються тими самими |
| Нові шаблони й макети сторінок | Середній | Заголовки, текстові блоки та внутрішні посилання часто переміщуються або зникають |
| Нова навігація та меню | Середній | Глибина посилань і внутрішній авторитет перерозподіляються |
| Контент переписано або об'єднано | Високий | Сторінки втрачають фрагменти й ключові слова, за якими ранжувалися |
| Нова CMS або JavaScript-фреймворк | Високий | Рендеринг, URL, редиректи та метадані змінюються одночасно |
| Змінено структуру URL | Високий | Кожен змінений URL потребує редиректу: розглядайте це як міграцію |
Причини повторюються від проєкту до проєкту. До кожної є простий контроль:
| Ризик | Як проявляється | Контроль |
|---|---|---|
| Контент видалено або скорочено | Сторінки падають за довгими запитами | Порівняти кількість слів і розділів на сторінці: старе проти нового |
| Переписані заголовки title та H1 | Нижчий коефіцієнт кліків, втрачені позиції | Вивантажити title та H1 до запуску, порівняти після |
| Втрачені внутрішні посилання | Глибокі сторінки втрачають позиції, з'являються сторінки-сироти | Порівняти внутрішні посилання, отримані кожним URL |
| URL змінено без 301 | Помилки 404, втрачені зворотні посилання | Карта редиректів, перевірена на кожному старому URL |
| Контент рендериться JavaScript | Сторінки індексуються порожніми, ШІ-асистенти нічого не бачать | Порівняти сирий HTML і відрендерений HTML |
| Повільніші шаблони | Гірші Core Web Vitals, вищий відсоток відмов | Перевірити LCP, INP і CLS на тестовому сервері |
| noindex або блокування robots.txt, залишені з тестового сервера | Сторінки зникають з індексу за кілька днів | Перевірити robots.txt і мета-тег robots у день запуску |
| Видалено структуровані дані | Зникають розширені результати | Валідувати schema в кожному шаблоні |
Дві з цих причин заслуговують на увагу. По-перше, JavaScript: Google рендерить сторінки за допомогою headless Chromium, але його документація з JavaScript SEO зазначає, що він знаходить лише ті посилання, які є стандартними елементами anchor з атрибутом href. Меню, зроблені з кнопок або обробників кліків, приховують цілі розділи. Наш посібник із JavaScript SEO описує варіанти рендерингу. По-друге, швидкість: рекомендації Google щодо Core Web Vitals встановлюють «хороші» порогові значення: LCP не більше 2,5 секунди, INP не більше 200 мілісекунд і CLS не більше 0,1, виміряні на 75-му перцентилі візитів. Важкі відео на головному екрані та слайдери: звичайна причина, чому новий шаблон їх не проходить.
Запустіть повне сканування робочого сайту та вивантажте кожен індексований URL разом із title, мета-описом, H1, кількістю слів, canonical, кодом стану та кількістю отриманих внутрішніх посилань. Це сканування стає вашою базовою лінією: після запуску ви порівнюватимете новий сайт із нею рядок за рядком. Збережіть також структуровані дані та файл robots.txt.
Вивантажте дані Search Console за 12-16 місяців (кліки та покази за сторінками й запитами), сторінки, що отримують зворотні посилання, і сторінки, що конвертують. Ці сторінки недоторканні: збережіть їхній URL, основний текст і title або покращуйте їх свідомо. Аудит контенту допомагає вирішити, що залишити, об'єднати чи видалити, і вказує для кожного видалення цільовий URL.
Найбезпечніший редизайн зберігає всі URL. Коли URL мусить змінитися, зіставте його один до одного з найближчою новою сторінкою за допомогою 301-редиректу, без ланцюжків і без перенаправлення всього на головну. Наш посібник про SEO-редиректи містить правила. Google радить зберігати редиректи щонайменше рік.
Дизайнери вирішують, де розміщується текст; розробники: як він рендериться. Дайте їм письмові вимоги: один H1 на шаблон, текст у HTML, меню, доступні для сканування, хлібні крихти, архітектура сайту з глибиною кожного розділу, schema, яку треба зберегти, і бюджет продуктивності. Читабельність і навігація теж мають значення: дивіться наш посібник про UX і SEO.
Уникайте запуску в пік сезону, перед святами або в п'ятницю: у перші дні після запуску знаходять помилки, і хтось має бути на зв'язку, щоб їх виправити. Запишіть, хто що перевіряє в день запуску, і наперед вирішіть, який сигнал запускає відкіт (наприклад, ключові сторінки повертають помилки або зникають з індексу). Тримайте старий сайт доступним на резервному сервері кілька тижнів, щоб швидко відновити шаблон чи блок тексту, якщо сторінка втратить позиції.
Розмістіть новий сайт на тестовому сервері, захищеному паролем (або принаймні правилом noindex), щоб Google не індексував дублікат вашого сайту. Потім протестуйте до запуску:
| Коли | Перевірки |
|---|---|
| День запуску | robots.txt дозволяє сканування, немає випадкового noindex, редиректи працюють, XML-карту сайту оновлено й подано в Search Console, тег аналітики спрацьовує |
| Тиждень 1 | Повне сканування, порівняне з базовою лінією, помилки 404 у Search Console, перевірка URL найважливіших сторінок |
| Тижні 2 - 4 | Кліки й покази ключових сторінок проти тих самих тижнів раніше, звіт про індексацію, звіт Core Web Vitals |
| Місяці 2 - 3 | Запити, що втратили позиції, сторінки для доповнення, внутрішні посилання для відновлення |
Перевірка непрацюючих посилань виявляє посилання, що досі ведуть на старі URL у меню, футерах і статтях. Виправляйте ці посилання в джерелі, а не покладайтеся на редиректи, і відновіть внутрішнє перелінкування, втрачене через видалення бічних панелей або блоків пов'язаних публікацій. Певні коливання в перші тижні є нормальними. Падіння, що триває після місяця на групі сторінок, вказує на конкретну причину: порівняйте ці сторінки з їхньою версією в базовій лінії.
ChatGPT, Claude, Perplexity і Gemini цитують сторінки, контент яких можуть прочитати й витягти. Редизайн може обмежити цей доступ так, як Google пробачив би. Аналіз трафіку ШІ-краулерів від Vercel (грудень 2024) показав, що жоден із великих ШІ-краулерів, зокрема GPTBot і ClaudeBot, не рендерить JavaScript. Сторінка, що показує текст лише після запуску JavaScript, невидима для більшості ШІ-краулерів.
Кожна додаткова зміна ускладнює діагностику падіння. Якщо ви також плануєте зміну домену, нову структуру URL або масштабне переписування контенту, розділіть їх: запустіть редизайн з ідентичними URL та контентом, дочекайтеся стабільного трафіку, потім виконайте наступну зміну. Коли календар вимагає все одразу, вкладіть більше часу у базове сканування та карту редиректів, адже тільки вони дають змогу знайти, що зламалося.
Редизайн зберігає позиції, коли новий сайт містить той самий контент, посилання та сигнали, що й старий, але в швидшій і зрозумілішій формі. Скануйте до, тестуйте на тестовому сервері, порівнюйте після. Коли новий сайт стабілізується, продовжуйте додавати сторінки, що відповідають на запитання ваших клієнтів: Sorank пише й публікує статті для SEO та GEO в режимі autopilot на оновленому сайті.
Коли URL, контент і внутрішні посилання збережено, позиції зазвичай стабілізуються за кілька тижнів. Google попереджає, що позиції можуть тимчасово коливатися щоразу, коли сайт істотно змінюється. Якщо ключові сторінки через один-два місяці досі нижчі за базову лінію, порівняйте їх зі скануванням до запуску, щоб знайти змінений контент, title чи посилання.
Лише якщо поточні URL становлять реальну проблему, наприклад нечитабельні параметри або структуру, що більше не відповідає сайту. Кожен змінений URL потребує 301-редиректу на найближчий відповідник і додає ризику до запуску. Збереження наявних URL: найпростіший спосіб захистити зворотні посилання та позиції.
Так, коли він усуває реальні слабкі місця: повільні шаблони, контент, схований за JavaScript, глибоку навігацію, відсутні заголовки або бідні сторінки. Приріст дають вимірні покращення: кращі Core Web Vitals, зрозуміліше внутрішнє перелінкування й багатший контент. Редизайн, що змінює лише візуальний стиль, рідко сам по собі зрушує позиції.
ВОНИ ПРОБУВАЛИ SORANK ДО ВАС
