# Чек-лист редизайна сайта: 12 шагов перед запуском

> Чек-лист редизайна сайта для бизнеса в Казахстане: 12 шагов перед запуском, карта 301-редиректов, перенос метатегов и проверка на staging без потери трафика.

Source: https://shipmint.kz/blog/cheklist-redizayna-sayta-pered-zapuskom
Published: 2026-06-15
Category: Веб-разработка

---


## TL;DR

Главный риск редизайна — не дизайн, а потеря позиций и заявок в момент переключения на новый сайт. Чаще всего трафик обваливается из-за того, что URL поменялись без 301-редиректов, исчезли метатеги и микроразметка, а формы перестали отправлять заявки в CRM. Перед запуском нужно зафиксировать базовые метрики, сделать инвентаризацию контента и URL, построить карту редиректов, перенести title/description/structured data, проверить скорость и мобильную версию, протестировать всё на staging и подготовить мониторинг в Search Console. Этот чек-лист из 12 шагов проведёт казахстанский бизнес через запуск так, чтобы новый сайт стал лучше старого по всем измеримым показателям, а не только красивее.

---

Редизайн сайта — один из самых недооценённых по риску проектов в малом и среднем бизнесе Казахстана. Со стороны это выглядит как косметика: новый дизайн, свежие фотографии, современный шрифт. Но технически вы строите новый сайт и в один момент подменяете им старый — тот самый, который годами накапливал позиции в Яндексе и Google, ссылки, доверие поисковиков и привычку клиентов находить вас по конкретным запросам.

Типичный сценарий провала выглядит так. Подрядчик сдаёт красивый сайт, его выкатывают в пятницу вечером, все довольны. Через две-три недели владелец замечает, что заявок стало меньше. Ещё через месяц видно по выручке: трафик из поиска просел на треть, телефон звонит реже, а менеджеры жалуются, что заявок с сайта почти нет. Разобраться задним числом сложно и дорого — поисковики уже переиндексировали сайт, позиции пересчитаны, а формы всё это время молча теряли лиды.

Хорошая новость в том, что почти все потери предотвратимы. Они происходят не потому, что редизайн в принципе опасен, а потому что пропускают несколько обязательных технических шагов. Ниже — практический чек-лист из 12 пунктов, который мы в [Shipmint](/services/digital-foundation) проходим перед каждым запуском. Он рассчитан на казахстанский контекст: 2ГИС, Яндекс и Google в выдаче, Kaspi-трафик, интеграции с 1С и местными CRM, требования Закона РК о персональных данных.

## Шаг 1. Зафиксируйте цели и базовые метрики до запуска

Прежде чем что-то трогать, ответьте на вопрос: как вы поймёте, что редизайн удался? Если ответа нет, то любой результат можно будет назвать успехом, и реальное падение трафика останется незамеченным.

Снимите базу по ключевым показателям за последние 3–6 месяцев, пока старый сайт ещё работает:

- органический трафик из Google и Яндекса (Search Console, Яндекс.Вебмастер, Метрика);
- позиции по 20–40 основным коммерческим запросам;
- число заявок с форм и звонков с сайта за месяц;
- конверсия посетитель → заявка;
- топ-10 страниц по трафику и топ-10 по заявкам.

Эти цифры — ваш ориентир. Цель редизайна формулируется не как «сделать красиво», а как «не потерять текущий трафик в момент переезда и вырасти по конверсии на горизонте трёх месяцев». Сохраните скриншоты и выгрузки в отдельную папку с датой — это ваша страховка, если что-то пойдёт не так и потребуется доказать подрядчику регресс.

## Шаг 2. Сделайте полную инвентаризацию контента и URL

Самая частая причина обвала — старый сайт имел, например, 240 проиндексированных страниц, а на новый перенесли 60, остальные просто исчезли. Каждая такая страница могла приносить трафик и заявки.

Соберите полный список всех URL старого сайта из нескольких источников, чтобы ничего не упустить:

- выгрузка из Search Console (отчёт «Страницы» → проиндексированные);
- выгрузка из Яндекс.Вебмастера (раздел «Страницы в поиске»);
- краулинг сайта через Screaming Frog или аналог;
- текущий `sitemap.xml`;
- список страниц с входящими ссылками и трафиком из аналитики.

Сведите всё в одну таблицу. Для каждого URL отметьте: трафик за полгода, число заявок, входящие ссылки, что с ним будет на новом сайте — переносится как есть, объединяется с другой страницей, меняет адрес или удаляется. Страницы с трафиком и заявками удалять нельзя без явного решения; если контент устарел, его переписывают, но URL по возможности сохраняют.

## Шаг 3. Постройте карту 301-редиректов

Если хоть один URL меняется — а при редизайне адреса меняются почти всегда — нужна карта 301-редиректов. Это правило, которое говорит поисковику и браузеру: «страница переехала навсегда, вот новый адрес». 301-редирект передаёт накопленный вес страницы на новый URL, поэтому позиции сохраняются.

Карта — это таблица «старый URL → новый URL», где каждому старому адресу сопоставлен релевантный новый. Ключевые правила:

- редирект всегда ведёт на **тематически близкую** страницу, а не на главную скопом — массовый редирект всего на `/` поисковики трактуют как «мягкую 404» и вес не передают;
- цепочки редиректов недопустимы: URL-A не должен вести на URL-B, который ведёт на URL-C — только один прыжок;
- проверьте и `http`/`https`, и `www`/без `www`, и слэш на конце — всё должно сводиться к одной канонической версии.

Пример правил для Nginx:

```nginx
# Один прыжок: старый адрес услуги → новый
location = /old-uslugi/sayty {
    return 301 https://example.kz/services/web-development;
}

# Принудительный https и без www
server {
    server_name www.example.kz example.kz;
    return 301 https://example.kz$request_uri;
}
```

После запуска прогоните весь список старых URL краулером и убедитесь, что каждый отдаёт код 301 и ведёт ровно в одну точку. Это самый важный технический шаг всего редизайна — именно здесь теряют трафик чаще всего.

## Шаг 4. Сохраните title, meta-description и заголовки H1

Поисковики ранжируют страницу во многом по её title и содержанию заголовков. Если новый шаблон сгенерировал безликие title вида «Главная — Компания» вместо проработанных «Натяжные потолки в Алматы — монтаж за 1 день», страница теряет соответствие запросам и проседает, даже если URL и редиректы в порядке.

В таблицу инвентаризации добавьте колонки: текущий title, текущий description, текущий H1 — и перенесите их на соответствующие страницы нового сайта. Если контент переписывается, метатеги обновляются осознанно, с сохранением основного ключа. Отдельно проверьте, что новый движок не дублирует title по всему сайту и не оставляет пустыми description у важных страниц. Для коммерческих посадочных это особенно критично — мы подробно разбирали логику таких страниц в материале о том, [как конверсионный сайт превращает трафик в заявки](/blog/konversionnyy-sayt-kak-prevratit-trafik-v-zayavki).

## Шаг 5. Перенесите структурированные данные (Schema.org)

Микроразметка JSON-LD — это то, что помогает поисковикам и AI-системам понять, кто вы и что предлагаете. Организация, услуги, отзывы, хлебные крошки, FAQ — всё это часто живёт на старом сайте и при редизайне молча исчезает, потому что новый шаблон о ней не знает.

Проверьте через валидатор Schema.org и тест расширенных результатов Google, какая разметка есть на старом сайте, и воспроизведите её на новом. Минимум для бизнеса в РК:

- `Organization` или `LocalBusiness` с названием, адресом, телефоном, ссылками на профили в 2ГИС и соцсетях;
- `BreadcrumbList` для навигации;
- `Service` для страниц услуг;
- `FAQPage` там, где есть блок вопросов-ответов.

Важно: NAP-данные (название, адрес, телефон) в разметке должны совпадать буква в букву с вашей карточкой в 2ГИС и Яндекс.Картах — расхождения подрывают локальное ранжирование. Не выдумывайте `aggregateRating`, если у вас нет реальной системы сбора отзывов — за фиктивные оценки можно получить ручные санкции.

## Шаг 6. Проверьте Core Web Vitals и скорость

Редизайн — частая причина деградации скорости: тяжёлые анимации, неоптимизированные изображения, лишние сторонние скрипты, видеофоны на главной. А скорость напрямую влияет и на позиции, и на конверсию, особенно на мобильном интернете в регионах Казахстана.

Перед запуском прогоните ключевые страницы через PageSpeed Insights и сверьте показатели с порогами:

| Метрика | Что измеряет | Целевой порог |
|---|---|---|
| LCP | Скорость загрузки основного контента | до 2,5 с |
| INP | Отзывчивость на действия пользователя | до 200 мс |
| CLS | Стабильность вёрстки при загрузке | до 0,1 |

Обязательно сравните результаты со старым сайтом: новый не должен быть медленнее. Самые частые виновники — несжатые картинки (переводите в WebP/AVIF, задавайте размеры, чтобы не было сдвигов layout), отсутствие ленивой загрузки и лишние шрифты. Глубокий разбор каждой метрики и расчёт потерь в тенге мы привели в статье про [Core Web Vitals и скорость сайта](/blog/core-web-vitals-skorost-sayta-prodazhi-2026).

## Шаг 7. Протестируйте мобильную версию

В Казахстане большинство визитов на коммерческие сайты приходит со смартфонов, а поисковики ранжируют именно по мобильной версии (mobile-first индексация). Красивый макет на десктопе ничего не значит, если на телефоне форма уезжает за край экрана, кнопка «Заказать» не нажимается, а текст приходится зумить.

Проверьте на реальных устройствах, а не только в эмуляторе браузера:

- кнопки и ссылки достаточно крупные для пальца, между ними есть отступы;
- формы удобно заполнять, появляется правильная клавиатура (цифровая для телефона);
- нет горизонтального скролла;
- кликабельный номер телефона (`tel:`) и кнопка WhatsApp;
- меню открывается и закрывается без багов;
- картинки и видео не выходят за экран и не тормозят прокрутку.

Отдельно протестируйте на медленном 3G/4G — именно так сайт открывается у части клиентов вне крупных городов.

## Шаг 8. Настройте аналитику, цели и UTM-метки

При переезде на новый сайт счётчики аналитики часто либо забывают поставить, либо ставят, но теряют настроенные цели и события. В результате вы запускаетесь вслепую и не видите ни трафика, ни конверсий.

Перед запуском проверьте на новом сайте:

- установлен Яндекс.Метрика и/или Google Analytics 4 на всех страницах;
- перенесены цели — отправка формы, клик по телефону, переход в WhatsApp, заказ;
- работает вебвизор/карта кликов в Метрике, если использовали;
- сохранена связь рекламных кабинетов (Яндекс.Директ, Google Ads) и UTM-разметка ссылок;
- если есть Facebook Pixel или другие пиксели — они перенесены.

Не размечайте внутренние ссылки UTM-метками — это ломает атрибуцию источников. UTM нужны только для внешних кампаний. Проверьте, что согласие на сбор данных (cookie-баннер) соответствует Закону РК о персональных данных, а аналитика грузится после согласия пользователя.

## Шаг 9. Проверьте формы и интеграцию с CRM

Это шаг, который теряет деньги быстрее всего и при этом самый незаметный. Сайт может работать, выглядеть отлично, собирать трафик — а заявки с форм уходить в никуда, потому что при переезде сломалась отправка. Бизнес узнаёт об этом через недели, когда уже потеряны десятки лидов.

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

- заявка приходит на нужную почту и/или в CRM (Bitrix24, amoCRM, 1С) с правильными полями;
- работает уведомление в Telegram/WhatsApp, если оно настроено;
- пользователь видит понятное подтверждение «спасибо, мы перезвоним»;
- отрабатывает защита от спама (Cloudflare Turnstile или reCAPTCHA), но она не блокирует реальных людей;
- цель в аналитике засчитывается при отправке;
- есть согласие на обработку персональных данных с чекбоксом — это требование закона РК.

Протестируйте сценарии с ошибками: пустые поля, неверный формат телефона. Форма должна подсказывать, а не молча отказывать.

## Шаг 10. Проведите полноценный QA на staging

Все предыдущие проверки делаются на промежуточном (staging) сайте — закрытой копии нового сайта, недоступной поисковикам и публике. Запускать «вживую» непроверенное нельзя.

Критично: на staging должен стоять запрет индексации, иначе тестовая версия попадёт в поиск и создаст дубли. Закройте её и через `robots.txt`, и через HTTP-авторизацию:

```
User-agent: *
Disallow: /
```

А вот ровно эту строку нужно **убрать** при запуске на боевом домене — самая обидная ошибка редизайна, когда сайт переезжает вместе с `Disallow: /` и полностью выпадает из индекса. На staging пройдите по чек-листу: все страницы открываются, нет битых ссылок и 404, изображения на месте, формы работают, текст без «рыбы» и плейсхолдеров, фавикон, страница 404 оформлена, юридические страницы (политика конфиденциальности, оферта) на месте. Проверьте в разных браузерах и на мобильном.

## Шаг 11. Подготовьте запуск и момент переключения

Выберите для переключения время минимального трафика — обычно ночь буднего дня, а не вечер пятницы, когда некому будет реагировать на проблемы. Подготовьте план отката: если что-то пойдёт критически не так, вы должны мочь за минуты вернуть старый сайт.

Чек-лист самого момента запуска:

1. Снять с боевого сайта запрет индексации (`Disallow: /`), проверить `robots.txt`.
2. Включить все 301-редиректы по карте и прогнать старые URL краулером — каждый отдаёт 301.
3. Сгенерировать и проверить новый `sitemap.xml`, убедиться, что в нём только актуальные URL с кодом 200.
4. Проверить SSL-сертификат и принудительный https.
5. Отправить новый sitemap в Search Console и Яндекс.Вебмастер.
6. Запросить переобход ключевых страниц.
7. Отправить тестовую заявку через основную форму — убедиться, что она дошла до CRM.
8. Проверить, что счётчики аналитики фиксируют визиты.

После выполнения держите старый сайт в резерве хотя бы пару недель — не удаляйте файлы и базу сразу.

## Шаг 12. Настройте мониторинг после запуска

Запуск — не финиш, а начало самого ответственного периода. Первые 4–6 недель поисковики переиндексируют сайт, и именно тогда видны все упущенные ошибки. Их нужно ловить, пока они дёшевы.

Что отслеживать ежедневно в первую неделю и затем еженедельно:

- **Search Console / Яндекс.Вебмастер**: отчёт об ошибках сканирования и индексации, рост числа 404, исключённые страницы, статус нового sitemap;
- **позиции** по тем же 20–40 запросам, что вы зафиксировали на шаге 1 — небольшое колебание в первые недели нормально, устойчивое падение — сигнал тревоги;
- **трафик** в сравнении с базой;
- **число заявок** — главный бизнес-показатель; если форм-конверсии нет несколько дней, проверяйте формы немедленно;
- **скорость** ключевых страниц в реальных данных Core Web Vitals.

Заведите простой журнал: дата, метрика, значение, отклонение от базы. Если через 2–3 недели позиции и заявки держатся на уровне базы или выше — редизайн прошёл чисто. Если что-то проседает, у вас есть инвентаризация, карта редиректов и базовые цифры, чтобы быстро найти причину.

## Часто задаваемые вопросы

### Почему после редизайна сайта упал трафик из поиска?

Чаще всего причина — смена URL без 301-редиректов: поисковик видит старые адреса как 404 и обнуляет их позиции. Вторая по частоте причина — потеря title, метатегов и структурированных данных, когда новый шаблон сгенерировал безликие заголовки. Третья — случайно оставшийся на боевом сайте запрет индексации `Disallow: /`. Все три проблемы предотвращаются прохождением чек-листа до запуска и проверяются в Search Console после.

### Нужны ли 301-редиректы, если адреса страниц не менялись?

Если структура URL полностью сохранена — точь-в-точь те же адреса — массовые редиректы не нужны. Но почти любой редизайн меняет хотя бы часть адресов: убираются старые разделы, объединяются страницы, меняется формат ЧПУ. Поэтому карту редиректов делают всегда, даже если кажется, что URL не трогали. Минимум — проверить и свести к одной версии http/https и www/без www, чтобы не плодить дубли.

### Сколько времени занимает восстановление позиций после редизайна?

Если всё сделано правильно, позиции вообще не должны заметно падать — 301-редиректы передают вес, и поисковики обновляют индекс в течение 2–4 недель без потерь. Если ошибки были и трафик просел, восстановление после исправления занимает обычно от нескольких недель до пары месяцев, в зависимости от объёма сайта и того, как быстро поисковик переобходит страницы. Поэтому дешевле и быстрее не допустить падения, чем потом его лечить.

### Можно ли запускать новый сайт частями, а не целиком?

Да, поэтапный запуск часто безопаснее, особенно для крупных сайтов с интернет-магазином или тендерной частью. Сначала переносят и проверяют один раздел, убеждаются, что трафик и заявки не пострадали, и только потом мигрируют остальное. Минус — дольше и сложнее в эксплуатации, потому что какое-то время работают две версии. Для лендинга или небольшого корпоративного сайта проще запуститься целиком за одну ночь с готовым планом отката.

### Что обязательно проверить в формах перед запуском?

Реально отправьте тестовую заявку на боевом домене и убедитесь, что она дошла до почты и CRM с правильными полями, сработало уведомление в Telegram или WhatsApp, пользователь увидел подтверждение, а цель засчиталась в аналитике. Отдельно проверьте защиту от спама — она не должна блокировать живых людей — и наличие чекбокса согласия на обработку персональных данных, как требует Закон РК. Сломанная при переезде форма теряет лиды молча, поэтому это первое, что проверяют после запуска.

### Что такое staging и зачем он нужен при редизайне?

Staging — это закрытая от поисковиков и публики копия нового сайта, на которой проходят весь QA до запуска: проверяют страницы, ссылки, формы, скорость, мобильную версию. Это позволяет находить и исправлять ошибки без риска для боевого сайта и трафика. Главное правило — на staging стоит запрет индексации `Disallow: /`, и его обязательно нужно снять при переезде на рабочий домен, иначе сайт выпадет из поиска.

Редизайн без потерь — это в первую очередь дисциплина: инвентаризация, карта редиректов, перенос метаданных и формы, проверенные на staging. В Shipmint мы ведём этот чек-лист как часть услуги [«Цифровой фундамент»](/services/digital-foundation) — строим сайт так, чтобы он не только выглядел лучше старого, но и сохранял каждую позицию и каждую заявку в момент переключения. Если вы планируете обновить сайт и не хотите рисковать трафиком, [напишите нам](/contact) — разберём ваш текущий сайт, соберём карту редиректов и проведём запуск без провала по продажам.


---

## Related

- [Blog](https://shipmint.kz/blog)
- [Contact](https://shipmint.kz/contact)