Как обновлять сайт без потери SEO: что согласовать с разработчиком

01

Почему обновление сайта может снизить поисковый трафик

Поисковая система оценивает не дизайн страницы, а её адрес, содержание, доступность, внутренние ссылки и сигналы каноничности. Поэтому риск возникает не только при полном переезде на другой домен. Достаточно изменить шаблон карточки товара, правила формирования ЧПУ или структуру каталога на 1С-Битрикс. Для поисковика прежняя страница может исчезнуть, а новая — оказаться её неполной или неочевидной заменой.

Типовой сценарий: в старом каталоге работали адреса вида /catalog/krossovki/model-123/, а после доработки появились фильтры, новые разделы и URL /shop/obuv/model-123/. Если между ними нет точного 301-редиректа, накопленные сигналы старой страницы не передаются автоматически. Если же все старые страницы перенаправить на главную, это не считается корректной заменой и ухудшает пользовательский путь.

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

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

03

Сначала зафиксируйте исходное состояние

Нельзя принять результат по формулировке «позиции не просели» на следующий день после релиза: поисковые системы переобходят сайт не мгновенно, а спрос и позиции меняются по внешним причинам. Вместо этого фиксируют измеримые артефакты до начала работ. Минимальный набор — выгрузка URL из карты сайта и систем аналитики, список страниц с органическими переходами, данные из панелей вебмастеров, текущие метатеги и статус кодов ответов.

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

На проекте удобно вести один файл с листами «Текущие URL», «Карта миграции», «Редиректы», «Проверка после релиза». У каждой строки должен быть владелец решения. Тогда спорный адрес не теряется между дизайнером, контент-менеджером и разработчиком, а задача не сводится к расплывчатому требованию «сохранить SEO».

04

Что согласовать при изменении шаблонов и структуры

Изменение шаблона не должно удалять SEO-разметку вместе со старой вёрсткой. В 1С-Битрикс title, description, H1, текст раздела и canonical могут формироваться в разных местах: в свойствах элемента, настройках раздела, шаблоне компонента или обработчике. Попросите разработчика показать источник каждого значения на тестовой странице, а не только визуально подтвердить, что заголовок отображается.

При изменении каталога важно разделить постоянные страницы и динамические комбинации фильтра. Индексировать имеет смысл только те фильтры, для которых есть спрос, уникальное содержимое и стабильный URL. Остальные параметры сортировки, пагинации, служебные метки и случайные сочетания должны быть закрыты от создания дублей через canonical, robots или правила обработки параметров — выбранный механизм зависит от текущей архитектуры сайта.

Не допускайте, чтобы canonical всех страниц каталога указывал на раздел верхнего уровня «для надёжности». Такой подход скрывает различия между ценными карточками и категориями. Канонический адрес должен быть абсолютным, доступным по 200 OK и соответствовать той странице, которую нужно видеть в поиске. После релиза его проверяют в HTML, а не только в настройках административной части.

05

Редиректы: не список исключений, а логика перехода

301-редирект нужен, когда старая страница навсегда получила новый эквивалентный адрес. Он не заменяет исправление внутренних ссылок: меню, хлебные крошки, карточки и XML-карта должны сразу вести на новые канонические URL. Иначе поисковый робот и пользователь проходят лишний переход, а при нескольких изменениях появляются цепочки вида старый URL → промежуточный URL → новый URL.

Для массовых изменений согласуйте правило и исключения. Например, если поменялся только раздел в адресе карточек, допустимо регулярное выражение с сохранением символьного кода. Но если часть товаров удалена, часть объединена, а часть получила новые коды, автоматическое правило опасно. Для таких позиций требуется отдельная карта соответствий из CMS, PIM или выгрузки каталога.

На 1С-Битрикс правила могут быть заданы на уровне веб-сервера, в файле обработки URL или модуле. Маркетологу не обязательно выбирать реализацию, но важно запросить перечень правил и результаты проверки. Официальные материалы по настройке ЧПУ и комплексных компонентов доступны в документации 1С-Битрикс; конкретное решение должно соответствовать структуре проекта.

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

06

Как принять техническое SEO сайта после релиза

Приёмка должна проходить на тестовом контуре до открытия его для поиска, а затем повторяться на боевом сайте. Тестовый домен нужно закрыть от индексации паролем или корректным запретом для роботов; после публикации этот запрет обязательно снимают. Ошибка в robots.txt или метатеге noindex способна убрать из выдачи даже безупречно перенесённые страницы.

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

Зафиксируйте результаты в таблице с датой, URL, ожидаемым и фактическим кодом, canonical, title и замечанием. Такой документ полезнее устного подтверждения: по нему легко закрыть дефекты и повторить проверку после срочного исправления.

1. 1

   Проверьте доступность. Новые целевые страницы должны отвечать кодом 200, а переносимые старые — кодом 301.

2. 2

   Откройте цепочки. Убедитесь, что каждый редирект ведёт сразу на конечный адрес без 302, 404 и циклов.

3. 3

   Сверьте каноникал. На выборке страниц canonical указывает на доступный абсолютный URL нужной страницы.

4. 4

   Проверьте метаданные. Title, description и H1 не стали пустыми, шаблонными или одинаковыми на приоритетных страницах.

5. 5

   Обновите сигналы. В sitemap оставьте новые URL, отправьте его в панели вебмастеров и следите за ошибками обхода.

07

Признаки того, что релиз нельзя принимать

Иногда команда считает SEO-задачу выполненной, потому что в браузере открывается новый сайт. Для поисковой миграции этого недостаточно. Красные сигналы обычно видны ещё на тестовом контуре: страницы имеют одинаковые метатеги, старые ссылки остаются в меню, фильтры неконтролируемо меняют адреса, а редиректы добавлены без карты и проверки.

Отдельный риск — смешение задач SEO и аналитики. При смене шаблона могут исчезнуть счётчики, цели, UTM-параметры и события электронной торговли. Это не всегда влияет на индексацию, но лишает маркетинг возможности сравнить период до и после релиза. Проверьте переход с UTM-метками: параметр не должен превращать страницу в дубль, ломать canonical или пропадать до фиксации визита в аналитике.

Если в проекте предусмотрены формы и CRM, пройдите контрольную заявку после публикации. Страница может сохранять позиции, но терять обращения из-за неработающего JavaScript, изменённого поля формы или события аналитики. SEO-обновление сайта оценивают вместе с работоспособностью ключевых коммерческих сценариев.

08

Контроль после публикации: первые дни и следующие недели

В день релиза проверьте доступность главных типов страниц, форму заявки, коды ответов и наличие служебных запретов. Затем загрузите новую XML-карту сайта в используемые панели вебмастеров и наблюдайте за отчётами по сканированию. Небольшое колебание числа страниц в индексе допустимо, но рост 404, исключённых URL или страниц с дублирующим canonical требует разбора.

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

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

09

Какое решение принять до старта доработки

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

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

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