Редизайн сайта клиники без потери позиций в поиске: чек-лист

Коротко (TL;DR): редизайн сайта клиники не должен приводить к падению позиций и трафика, если заранее зафиксировать текущие метрики, построить карту 301-редиректов на каждый URL — включая страницы врачей и услуг, — сохранить микроразметку и лицензии в подвале, протестировать сайт на стейджинге и контролировать индексацию первые две недели после запуска.

Редизайн — это обновление внешнего вида, структуры или технологической платформы сайта при сохранении (в идеале) всей накопленной SEO-ценности: позиций, индексации, ссылочного веса страниц. Для обычного корпоративного сайта это уже рискованная операция. Для сайта клиники риск выше: кроме обычных страниц услуг здесь десятки профилей врачей, лицензии и разрешительные документы в подвале, интеграция с МИС и ЕГИСЗ, виджет онлайн-записи — и каждый из этих элементов может незаметно потеряться при переносе на новую платформу.

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

Почему редизайн сайта клиники — это риск для SEO-позиций

Редизайн ломает позиции не сам по себе, а через накопление мелких технических потерь: изменившийся URL без редиректа, переписанный title, пропавшая Schema.org-разметка, случайно удалённая страница врача. По отдельности каждая потеря незаметна, но вместе они дают заметную просадку трафика через 1-2 недели после запуска, когда Google переобходит обновлённый сайт.

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

Что зафиксировать до старта редизайна

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

Технический и контентный аудит текущего сайта

1. Выгрузить из Google Search Console список всех проиндексированных URL и текущие позиции по ключевым запросам.
2. Зафиксировать органический трафик за последние 3 месяца в разбивке по страницам — это базовая линия для сравнения после запуска.
3. Собрать полную карту текущей структуры URL: главная, страницы услуг, профили врачей, блог, служебные страницы (политика конфиденциальности, лицензии).
4. Проверить текущую скорость загрузки (Core Web Vitals) — чтобы при запуске нового сайта было с чем сравнивать, если скорость вдруг ухудшится.
5. Сохранить текущие title, meta description и H1 всех ключевых страниц в отдельную таблицу — это заготовка для технического задания на редизайн.

Что отдельно нужно сохранить на сайте клиники

Помимо стандартного SEO-аудита, у клиники есть элементы, которые часто выпадают из поля зрения разработчика, незнакомого со спецификой медицинских сайтов:

• Страницы врачей и их профили. Уникальный текст о квалификации, стаже и специализации каждого врача — это не шаблонный контент, а часть, по которой страница ранжируется отдельно от страницы клиники в целом.
• Разрешительные документы и лицензии в подвале. Номера лицензий и ссылки на сканы разрешительных документов обязаны остаться на сайте после редизайна — это не только SEO-сигнал доверия, но и требование к медицинскому сайту.
• Schema.org-разметка медицинских типов. Разметка MedicalClinic, Physician и других медицинских типов должна быть перенесена в новый шаблон, а не потеряна при смене CMS — подробно о том, какие типы использовать и какие ошибки чаще всего ломают разметку, мы разбирали в статье Schema.org для медицинского сайта.

Карта соответствия URL — как не потерять трафик при переносе

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

Старый URL	Новый URL	Редирект	Приоритет
/doctors/ivanova-ov	/doctors/ivanova-ov	301 (URL не меняется)	Высокий
/uslugi/konsultaciya-terapevta	/services/konsultaciya-terapevta	301	Высокий
/about/licenses.html	/conditions/licenses	301	Высокий
/blog/category/novosti	/blog/?category=novosti	301	Средний
/old-promo-page	— (страница больше не актуальна)	301 на ближайшую релевантную страницу или 410	Низкий

Почему именно 301, а не 302: 301 (постоянный редирект) сообщает поисковику, что старый адрес переехал навсегда и нужно передать накопленный вес новому URL. 302 (временный) этот вес не передаёт — Google продолжает считать старый адрес основным и может держать в индексе оба URL одновременно, что приводит к путанице и потере позиций вместо их сохранения.

Для клиники отдельное внимание нужно трём типам URL: страницы врачей (/doctors/<slug>), страницы услуг (/services/<slug>) и страницы направлений или заболеваний (/conditions/<slug>) — именно они обычно несут больше всего органического трафика и чаще всего меняют структуру при редизайне, потому что попадают под новую категоризацию меню.

Что обязательно включить в техническое задание на редизайн

Техническое задание на редизайн должно явно фиксировать SEO-требования, а не оставлять их на усмотрение дизайнера или разработчика — иначе часть требований неизбежно потеряется при вёрстке. Это не формальность для подрядчика, а инструмент приёмки: без письменных критериев сложно доказать, что конкретный элемент сайта должен был сохраниться, если он пропал в финальной версии.

• Title, meta description и H1 ключевых страниц сохраняются без изменений или меняются только по согласованию с человеком, отвечающим за SEO.
• Вся Schema.org-разметка переносится в новый шаблон в неизменном виде, если не было отдельной задачи на её доработку.
• Функциональность, которой пользуются пациенты, не теряется при смене платформы или фреймворка: онлайн-запись, личный кабинет пациента, виджет видеоконсультаций — каждый из этих модулей требует отдельного пункта в ТЗ с критерием приёмки «работает так же, как на старом сайте, или лучше».
• URL-структура ключевых разделов сохраняется, если нет отдельного обоснования на её изменение.

Что нельзя терять на сайте клиники при переносе

Это тот слой требований, который чаще всего отсутствует в типовых чек-листах редизайна, потому что они написаны для обычного сайта, а не для медицинского.

• Онлайн-запись и формы. Если при редизайне меняется движок бронирования или виджет записи, его нужно тестировать отдельно от остального сайта — именно здесь чаще всего теряются заявки пациентов, причём совершенно незаметно для команды, потому что форма визуально выглядит рабочей, а запрос никуда не уходит.
• Модерация и витрина отзывов о врачах. Виджет отзывов и история оценок должны переехать вместе с профилями врачей, а не обнулиться на новом сайте. Отдельный разговор — правовая сторона публикации отзывов и то, как устроена их модерация: об этом подробно в статье отзывы о врачах на сайте клиники.
• Интеграция с МИС и ЕГИСЗ. Смена хостинга или фреймворка не должна ломать API-эндпоинты, через которые сайт обменивается данными с медицинской информационной системой — это нужно проверять отдельным тестовым сценарием, а не полагаться на то, что «интеграция и так заработает».

Как протестировать сайт клиники перед релизом

1. Развернуть новую версию сайта на стейджинге, закрытом от индексации через noindex или защиту паролем — чтобы Google не проиндексировал черновую версию раньше времени.
2. Прогнать пачкой проверку всех редиректов из карты соответствия URL (через Screaming Frog или серию запросов curl -I) — убедиться, что каждый старый адрес действительно ведёт на правильный новый, а не на главную страницу по умолчанию.
3. Протестировать формы записи и виджет онлайн-бронирования целиком — от заполнения формы до реального появления заявки в административной панели или МИС.
4. Проверить через Google Rich Results Test, что Schema.org-разметка на ключевых страницах (клиника, услуги, врачи) распознаётся корректно.
5. Сравнить title, H1 и meta description на стейджинге с зафиксированными на этапе аудита — любое расхождение нужно обосновать или откатить.

Первые две недели после запуска — что контролировать

Запуск нового сайта — не конец работы по SEO, а начало периода контроля, когда ещё можно быстро исправить ошибку до того, как она превратится в затяжную просадку.

• Покрытие в Search Console. Проверять раздел «Страницы» на предмет новых ошибок 404 и soft-404 — рост их числа сразу после запуска почти всегда означает пропущенный редирект в карте соответствия URL.
• Скорость переобхода. Через запрос переиндексации в Search Console для ключевых страниц (главная, топовые услуги, топовые врачи) можно ускорить обновление данных в индексе, не дожидаясь естественного обхода.
• Мониторинг позиций по ключевым страницам. Ежедневная или через день проверка позиций по страницам услуг и врачей, которые приносили основной трафик — это позволяет заметить затяжную просадку в первую неделю, а не через месяц, когда её сложнее связать с конкретной причиной.

Просадка трафика после редизайна клиники — норма или повод для тревоги?

Временная просадка на 1-3 недели после корректно проведённого редизайна — это норма, а не признак ошибки: Google физически требуется время, чтобы переобойти изменившиеся URL и перенести на них накопленные сигналы ранжирования. Поводом для тревоги становится не сама просадка, а её длительность и динамика: если трафик не начинает восстанавливаться после третьей недели, скорее всего в карте редиректов есть пропущенные адреса, либо при переносе потерялась часть контента или разметки, которую нужно искать через повторный аудит, а не ждать дальше.

Поэтапный редизайн или полный релиз — что выбрать клинике

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

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

Частые ошибки при редизайне сайта клиники

Ошибка	Последствие	Как избежать
Нет карты соответствия URL или она неполная	Часть старых адресов отдаёт 404, трафик и позиции по ним теряются безвозвратно	Составлять карту до начала разработки, по полной выгрузке из Search Console, а не по памяти
Использован 302 вместо 301	Вес старой страницы не передаётся новой, Google держит в индексе оба URL	Жёстко прописать тип редиректа в ТЗ и проверить на стейджинге
Лицензии и разрешительные документы потеряны в подвале	Нарушение требований к сайту медицинской организации, потеря доверительных сигналов	Включить проверку подвала в отдельный пункт приёмки сайта
Schema.org-разметка не перенесена в новый шаблон	Пропадают расширенные сниппеты в выдаче, хуже цитируемость в AI-поиске	Проверять каждую ключевую страницу через Google Rich Results Test перед релизом
API-интеграция с МИС оборвана при смене хостинга	Данные о приёмах и пациентах перестают синхронизироваться незаметно для персонала	Тестировать интеграцию отдельным сценарием, а не полагаться на «должно заработать само»
Title и H1 переписаны «для свежести» без согласования	Потеря соответствия странице в выдаче по ключевым запросам, просадка позиций	Фиксировать текущие title/H1 на этапе аудита и менять только по согласованию

Частые вопросы