Перенос сайта на 1С-Битрикс: как подготовить переезд и сохранить трафик

Перенос сайта на Битрикс стоит начинать с перечня страниц, которые уже приводят клиентов. Затем — сохранить их адреса и содержание, подготовить редиректы для неизбежных изменений и проверить новую площадку до запуска. Такой порядок помогает избежать технических потерь. Обещать неизменный трафик нельзя: Google предупреждает о временных колебаниях позиций при существенных изменениях сайта.

Под «без потери трафика» мы понимаем цель подготовки: не потерять доступные страницы, тексты, ссылки и возможность оформить заявку. Ниже — план, по которому владелец или маркетолог сможет обсудить работы с командой и принять результат. Его можно использовать для корпоративного сайта, каталога и магазина; у магазина добавятся отдельные проверки заказов и обмена данными.

Зачем переезжать на 1С-Битрикс и что менять одновременно

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

Отдельный аргумент — предусмотренные платформой интеграции: с 1С, платежами и доставкой. Но готовый механизм ещё нужно настроить и испытать на данных компании. Критерии выбора мы разобрали в статье почему стоит выбрать 1С-Битрикс для сайта. Сама по себе смена CMS рост посещаемости не гарантирует.

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

Снять исходное состояние: страницы, трафик, обращения

До начала переделки сохраните исходный сайт и его показатели. Архив файлов и базы нужен для возврата и сверки содержания; выгрузка адресов — для проверки маршрутов; отчёты аналитики — для сравнения результата. Не откладывайте сбор на день запуска: к этому моменту старая структура уже может быть недоступна.

Список страниц собирайте из нескольких источников: обхода сайта, CMS, Sitemap, аналитики и поисковых кабинетов. Так проще заметить страницу, на которую уже нет ссылки в меню, но ещё приходят посетители. Подробный состав проверок есть в материале о техническом и поисковом аудите сайта.

В отчёте Метрики «Страницы входа» посмотрите, с каких страниц начинаются визиты из поиска и какие из них связаны с целями. В Search Console сохраните показатели по страницам и запросам. Предлагаем отдельно отметить страницы с обращениями, важные категории, услуги и материалы, на которые ведут внешние ссылки.

• Адрес и назначение. Полный URL, тип страницы, раздел, основной товар или услуга.
• Содержание. Заголовки, основной текст, характеристики, изображения, документы и связанные ссылки.
• Настройки поиска. Title, description, canonical, разрешение индексирования и фактический ответ сервера.
• Результат для бизнеса. Поисковые визиты, обращения или заказы, если их учёт настроен; коммерческая значимость страницы.
• Особые маршруты. Фильтры, пагинация, языковые версии, старые перенаправления и адреса файлов.

Периоды сравнения выбирайте с учётом сезонности и обычного ритма продаж. Если спрос заметно различается по дням недели, сравнение случайных соседних дней будет слабой проверкой. Зафиксируйте дату и время запуска, сохраните настройки отчётов и список изменений — это рабочая база для разбора отклонений, а не прогноз будущего трафика.

Составить карту URL до настройки новых страниц

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

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

Подготовить 301-редиректы и проверить их конечную цель

Если адрес действительно изменился, настройте постоянное перенаправление на соответствующую новую страницу. Яндекс рекомендует серверный 301 и доступную цель с ответом 200 и содержимым. Google также поддерживает постоянные серверные перенаправления. Для обычной постоянной смены URL в плане можно использовать 301.

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

• Ведите сразу на конечный URL. Google советует избегать цепочек перенаправлений, Яндекс их допускает, но лишние переходы замедляют загрузку для посетителя. При наличии старого редиректа обновите его назначение, чтобы не добавлять новые переходы к прежней цепочке.
• Проверяйте соответствие содержания. Категория должна вести к своей новой версии или обоснованной замене, а не к случайному разделу.
• Разберите параметры. Адрес карточки с идентификатором, фильтр и рекламная метка могут требовать разных решений. Не удаляйте все параметры одним общим правилом без проверки.
• Проверьте варианты адреса. Протокол, www, завершающий слеш и старые варианты пути не должны создавать циклы.
• Обновите внутренние ссылки. Меню, хлебные крошки, карточки и тексты должны вести сразу на актуальные страницы.

Если несколько старых материалов содержательно объединены в один, проверьте, что новая страница действительно отвечает на прежние задачи. Массовое перенаправление любых удалённых URL на главную Google может воспринять как soft 404 — страницу, фактически не дающую ожидаемого содержания. Если подходящей замены нет, предусмотрите настоящий ответ 404 или 410.

В рекомендациях есть различие. Яндекс советует, если тематика сайта не изменилась, перенаправлять удалённую страницу 301-м редиректом на соответствующий раздел или раздел со схожей тематикой, а код 404 отдавать, когда меняется тематика. Google просит не перенаправлять много старых адресов на одну нерелевантную страницу и для удалённого контента без замены отдавать 404 или 410. Практический критерий — посетитель по старой ссылке получает подходящий ответ. Проверяйте его по содержанию, а не только по названию раздела.

У правил должен быть ответственный и место хранения. Не удаляйте их сразу после переключения: Google рекомендует сохранять редиректы как можно дольше, обычно не менее года, а с точки зрения посетителей — бессрочно.

Перенести контент: сначала пробная загрузка, затем весь объём

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

В документации по работе с инфоблоками описаны штатные CSV- и XML-импорт. Для CSV указан путь «Контент → Информационные блоки → Импорт → CSV», для XML — раздел импорта XML. Для торгового каталога документация отдельно указывает «Магазин → Настройки → Импорт данных».

XML-обмен инфоблоков позволяет переносить также свойства и изображения. Однако файл XML из произвольной старой CMS не становится совместимым с импортёром из-за одного расширения. Разработчику нужно сопоставить структуру источника с требованиями выбранного инструмента. При нестандартной схеме согласуйте отдельный конвертер или программу переноса и её проверку.

Что включить в пробную партию

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

После загрузки сверьте не только количество элементов, но и их смысл. Сохранились ли абзацы, списки, ссылки и подписи? Работают ли изображения и скачивание документов? Правильно ли отображаются символы? Не превратился ли HTML в видимый текст с тегами? Зафиксируйте ошибки до массового импорта.

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

У магазина отдельно определите источник цен и остатков: старая CMS, учётная система или подготовленная выгрузка. Не запускайте конкурирующие загрузки без согласованного порядка. Работу обмена и тестового заказа стоит включить в общий план; подробнее — в материале об интеграции 1С с сайтом.

Сохранить метаданные, содержание и связи между страницами

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

В форме элемента инфоблока SEO-настройки по умолчанию наследуются от инфоблока или раздела. Для собственного значения предусмотрена опция «Изменить для этого элемента». При переносе проверяйте индивидуальные поля: общий шаблон новой CMS не должен незаметно заменить ранее согласованные заголовки всех страниц.

Title — название HTML-документа, description — метаописание, H1 — видимый основной заголовок. Для них нужна отдельная сверка. Заполненное название элемента в админке ещё не доказывает, что нужный заголовок выведен на странице. Практику заполнения разобрали в статье о title, description и H1.

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

Проверить canonical и служебные адреса

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

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

Закрыть тестовую площадку и подготовить её к приёмке

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

Одного Disallow в robots.txt недостаточно для гарантированного исключения URL из Google. Если используется noindex, робот должен получить страницу, чтобы увидеть его. Google поддерживает noindex в метатеге или HTTP-заголовке, но не как запись в robots.txt. Поэтому не стоит рассчитывать на noindex, спрятанный за запретом обхода.

Для открытой служебной HTML-страницы правило в разделе head может выглядеть так:

<meta name="robots" content="noindex">

Тестовую площадку, закрытую авторизацией, оставляйте закрытой. Перед публикацией проверьте, что временные ограничения не перешли на страницы рабочего сайта: отдельно смотрите robots.txt, метатеги и HTTP-заголовок X-Robots-Tag. Логику этих файлов разобрали в статье о robots.txt и Sitemap.

Что принять на тестовом сайте

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

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

Попросите показать результаты проверки ссылок, ответов сервера и метаданных в виде списка URL с найденными отклонениями. Общая формулировка «всё протестировано» неудобна для приёмки. По списку должно быть понятно, какая ошибка исправлена, какая требует решения владельца и что осталось проверить на рабочем домене.

Чек-лист запуска: кто и что подтверждает

У запуска должен быть согласованный порядок действий и ответственный за решение о переключении. Для каждого пункта отметьте исполнителя, способ проверки и результат. Ниже — рекомендуемый рабочий чек-лист.

До переключения

• Карта старых и новых URL согласована; важные страницы и намеренные удаления отмечены.
• Пробный и полный переносы сверены; правила повторного импорта понятны.
• Подготовлена резервная копия и проверен способ возврата. Известно, кто принимает решение о нём.
• Определён момент остановки редактирования старой версии и финальной синхронизации изменений.
• Для магазина отдельно согласована передача новых заказов, пользователей и остатков за время подготовки.
• Подготовлены рабочие robots.txt, Sitemap, canonical и редиректы; временные запреты перечислены.
• Сохранены права в поисковых кабинетах, коды подтверждения и настройки аналитики.

При переключении

• Загрузить последние согласованные изменения, включить новую версию и правила перенаправлений.
• Проверить публичные URL без авторизации: сохранённые страницы и цели редиректов отдают нужное содержимое.
• Проверить отсутствие тестовых запретов на рабочих страницах и сохранение защиты отдельной тестовой площадки.
• Испытать формы и заказы, поступление данных ответственному сотруднику и запись целей аналитики.
• Убедиться, что ссылки и файлы открываются на рабочем домене; сверить новую карту сайта.
• Записать время запуска и фактически внесённые изменения.

Если одновременно меняется сервер, включите в план переключение инфраструктуры и DNS. У Google для этого есть отдельная инструкция без смены URL. Не добавляйте переключение DNS в план автоматически, когда меняется только приложение на прежнем сервере.

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

Проверить запуск в Яндекс Вебмастере и Search Console

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

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

В инструменте проверки URL различайте сведения об индексированной версии и проверку страницы на сайте (live test). Успешный тест не означает, что страница уже появилась в поиске. Выбранный Google канонический адрес смотрят в данных индексирования; текущий тест не предсказывает этот выбор. Запрос индексирования тоже не гарантирует результат.

Нужно ли подавать заявку на переезд

Если остались прежние домен и адреса страниц, отдельной смены адреса сайта нет. При изменении путей на том же домене инструмент Google «Изменение адреса» (Change of Address) не нужен. Если одновременно меняете домен или поддомен, следуйте отдельным условиям этого инструмента из инструкции Google. У Яндекса есть своя процедура переезда на новое доменное имя; её не стоит смешивать с одной лишь установкой новой CMS.

Наблюдать за страницами после запуска

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

В отчёте об эффективности Search Console доступны клики, показы, CTR и средняя позиция, а также разрезы по страницам и запросам. В Метрике проверяйте поисковые визиты и цели. Эти показатели отвечают на разные вопросы: клик в поиске и зарегистрированный аналитикой визит не обязаны совпадать.

Это направления диагностики, а не готовые диагнозы. Не объясняйте любое падение «обычной переиндексацией», пока не проверили технические причины. Но и обещать возврат к прежней посещаемости к конкретной дате не стоит: размер сайта, состав изменений и обработка страниц различаются.

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

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

• Проверить только главную. За ней остаются услуги, категории, документы и старые ссылки. Пройдите карту URL и разные шаблоны.
• Поменять все адреса ради единообразия. Сначала оцените возможность сохранить их; для необходимых изменений подготовьте соответствия до запуска.
• Поставить один редирект на главную. Проверяйте смысл новой цели. Без подходящей замены предусмотрите ответ об отсутствии страницы.
• Принять импорт по числу записей. Сверьте тексты, связи, свойства, файлы и результат повторной загрузки.
• Забыть индивидуальные SEO-поля. Проверьте, не подменил ли общий шаблон значения перенесённых страниц.
• Перенести настройки тестового сайта на рабочий. Проверьте robots.txt, noindex, X-Robots-Tag и canonical именно на публичных URL.
• Оставить старые внутренние ссылки. Обновите навигацию и ссылки в контенте по карте адресов, чтобы посетители сразу попадали к нужному материалу.
• Закончить работу в момент переключения. Включите проверку аналитики, поисковых кабинетов и последующих отклонений в приёмку проекта.

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

Можно ли перенести сайт без изменения адресов?

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

Гарантирует ли переезд без ошибок сохранение всего трафика?

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

Всё ли перенесётся через CSV или XML?

Штатные инструменты предназначены для определённых данных и форматов. Для инфоблоков предусмотрены CSV и XML; XML-обмен может включать свойства и изображения. Но структуру чужой CMS нужно сопоставить с форматом импортёра. Перенос заказов, пользователей и индивидуальных SEO-значений следует согласовать отдельно и проверить на пробной загрузке.

Когда можно удалить старые редиректы?

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

Сколько времени и денег потребуется на перенос?

Оценку стоит составлять по составу данных и работ: объёму контента, карте URL, каталогу, интеграциям, новой вёрстке, тестированию и запуску. До сметы подготовьте инвентаризацию и пробный перенос сложных материалов. Универсальный срок или цена без этих сведений не объясняют, какие работы и проверки входят в предложение.

Источники

• Возможности и различия комплектаций — 1С-Битрикс, сравнение редакций; подключения к внешним системам — интеграции платформы.
• CSV/XML, инфоблоки и торговый каталог — 1С-Битрикс, «Работа с инфоблоками штатными средствами»; SEO-поля — форма элемента инфоблока.
• Изменение адресов, 301, проверка доступности и Sitemap — Яндекс Вебмастер, «Смена структуры и дизайна сайта». Смена домена — отдельная инструкция по переезду.
• Страницы начала визитов и анализ целей — Яндекс Метрика, отчёт «Страницы входа».
• Подготовка карты URL, запуск, наблюдение, цепочки редиректов и инструмент «Изменение адреса» — Google Search Central, How to move a site, редакция 20.08.2026. Смена сервера без изменения URL — Changing your hosting.
• Постоянные перенаправления — Google Search Central, Redirects and Google Search. Предпочтительные адреса — How to specify a canonical URL.
• Авторизация и управление видимостью — Google Search Central, Control what you share with Google Search; метатег и HTTP-заголовок — Block Search indexing with noindex.
• Проверка страницы — справка Search Console, «Инструмент проверки URL»; показатели поиска — Performance report.