[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f640d52pz1k1g":3},{"slug":4,"title":5,"published":6,"publishedAt":7,"createdAt":7,"section":8,"preview":9,"heroImage":8,"previewImage":10,"headMarkup":11,"lifecycleId":42,"bodyMd":43,"bodyHtml":44},"kak-perenesti-korporativnyy-sayt-na-1s-bitriks-kontent-seo-adresa-formy-i-dostupy","Как перенести корпоративный сайт на 1С-Битрикс: контент, SEO-адреса, формы и доступы",true,"2026-08-24T09:00:00+03:00",null,"Переезд сайта ломается не в момент установки новой CMS, а на забытых деталях: старом PDF без владельца, форме с письмом на личную почту, адресе с внешними .","\u002Fcontent-media\u002Farticles\u002Fkak-perenesti-korporativnyy-sayt-na-1s-bitriks-kontent-seo-adresa-formy-i-dostupy\u002Fassets\u002F297b1d70dea0.webp",[12],{"tag":13,"type":14,"key":15,"json":16},"script","application\u002Fld+json","kak-perenesti-korporativnyy-sayt-na-1s-bitriks-kontent-seo-adresa-formy-i-dostupy-faq",{"@context":17,"@type":18,"mainEntity":19},"https:\u002F\u002Fschema.org","FAQPage",[20,26,30,34,38],{"@type":21,"name":22,"acceptedAnswer":23},"Question","Можно ли перенести всё автоматически?",{"@type":24,"text":25},"Answer","Автоматизация помогает с типовыми данными, но не заменяет аудит контента, файлов и интеграций.",{"@type":21,"name":27,"acceptedAnswer":28},"Нужно ли менять URL?",{"@type":24,"text":29},"Только при понятной причине. Для изменённых адресов готовят карту редиректов.",{"@type":21,"name":31,"acceptedAnswer":32},"Как проверить форму?",{"@type":24,"text":33},"Отправить тестовое обращение и подтвердить карточку, поля, источник и ответственного в CRM.",{"@type":21,"name":35,"acceptedAnswer":36},"Кому принадлежат доступы?",{"@type":24,"text":37},"Компании-владельцу сайта. Подрядчик получает ограниченный рабочий доступ.",{"@type":21,"name":39,"acceptedAnswer":40},"Когда удалять старый сайт?",{"@type":24,"text":41},"После периода наблюдения, подтверждения переноса и выполнения плана архивирования.","lc_95beb0eb7479cbbf578c8d9d29a1e7d1","# Как перенести корпоративный сайт на 1С-Битрикс: контент, SEO-адреса, формы и доступы\n\nПереезд сайта ломается не в момент установки новой CMS, а на забытых деталях: старом PDF без владельца, форме с письмом на личную почту, адресе с внешними ссылками или доступе бывшего подрядчика. Миграция требует учёта того, что существует сейчас, и проверки того, что должно работать после переключения.\n\n## Инвентаризация старого сайта\n\n![Схема: Как перенести корпоративный сайт на 1С-Битрикс: контент, SEO-адреса, формы и доступы](\u002Fcontent-media\u002Farticles\u002Fkak-perenesti-korporativnyy-sayt-na-1s-bitriks-kontent-seo-adresa-formy-i-dostupy\u002Fassets\u002F3da73a92a23f.webp)\n\nДо разработки выгружают список URL, шаблонов, файлов, форм, метаданных, редиректов, целей аналитики и внешних интеграций. Для каждой позиции фиксируют действие: перенести, объединить, заменить, закрыть с понятным ответом или оставить на старой платформе до отдельного этапа.\n\nСодержимое не переносят механически. Устаревшие новости, дубли услуг и неактуальные документы лучше отсеять до переноса, иначе новая CMS наследует старый беспорядок.\n\n### Что зафиксировать\n\n- реестр URL\n- аудит файлов\n- владельцы контента\n\n## SEO-адреса и редиректы\n\nДля изменяемых URL готовят карту соответствий: старый адрес, новый адрес, тип перенаправления, причина и результат проверки. Нельзя отправлять всё на главную страницу: посетитель и поисковая система должны получать наиболее близкий релевантный материал.\n\nПосле переключения проверяют статусы ответов, цепочки редиректов, канонические адреса, sitemap и robots.txt. Анализируют реальные ошибки, а не только список, составленный до запуска.\n\n### Что зафиксировать\n\n- карта 301-редиректов\n- контроль 404\n- проверка индексации\n\n## Формы и CRM\n\nДля каждой формы описывают поля, согласие, получателя, создание лида или сделки, передачу источника и реакцию при сбое. Тестовая заявка должна пройти весь путь до ответственного в CRM, а не просто показать сообщение на сайте.\n\nПеред запуском рекламных кампаний отдельно проверяют UTM-метки, дедупликацию и уведомления. На переносе часто теряется не форма, а её контекст.\n\n### Что зафиксировать\n\n- тестовые обращения\n- карта полей\n- лог ошибок обмена\n\n## Доступы и редакторы\n\nУ владельца сайта должны остаться доступы к домену, хостингу, CMS, аналитике, почте уведомлений и хранилищу копий. Учётные записи выдают персонально; общие пароли и доступ бывшего исполнителя исключают до переключения.\n\nРедакторы получают роли по своим задачам. После обучения они создают тестовый материал и проходят короткий сценарий публикации, чтобы обнаружить непонятные права до реальной новости.\n\n### Что зафиксировать\n\n- реестр доступов\n- роли редакторов\n- порядок отзыва доступа\n\n## Окно релиза и откат\n\nНа день переключения назначают ответственных, замораживают контент на старом сайте, делают проверенную копию и определяют критерии отката. В чек-лист входят DNS, сертификат, ключевые URL, формы, аналитика и доступ к админке.\n\nПосле запуска наблюдают за ошибками и обращениями, а не объявляют миграцию завершённой после первого открытия главной страницы. Первые дни дают данные для точечной корректировки.\n\n### Что зафиксировать\n\n- окно работ\n- критерии отката\n- первые проверки после релиза\n\n## Решение о готовности к переносу\n\nК запуску переходят после того, как для каждого типа страницы определены новый адрес, источник контента, ответственный за проверку и действие при ошибке. Формы, личные кабинеты, поиск и платежи, если они есть, проверяют как отдельные сценарии: перенос текстов не подтверждает работу этих функций.\n\nПеред переключением DNS или публикацией составляют план возврата. В нём указывают, кто принимает решение об откате, какую версию сайта возвращают и как фиксируют обращения пользователей в первые часы. Это не резервный пункт в документе, а рабочее условие запуска.\n\n## Рабочий артефакт\n\nЖурнал миграции ведут по URL: старый адрес, новый адрес или причина исключения, тип редиректа, результат проверки и исполнитель. Отдельным списком остаются доступы, резервная копия и место хранения архива старого сайта.\n\nПосле релиза журнал дополняют фактическими результатами: какие маршруты проверены, где исправлены ссылки и какие задачи перенесены в следующий этап. По нему можно восстановить ход переноса без догадок и поиска по переписке. Журнал хранят вместе с инструкцией для дежурной команды на период после переключения.\n\n## Часто задаваемые вопросы\n\n### Можно ли перенести всё автоматически?\n\nАвтоматизация помогает с типовыми данными, но не заменяет аудит контента, файлов и интеграций.\n\n### Нужно ли менять URL?\n\nТолько при понятной причине. Для изменённых адресов готовят карту редиректов.\n\n### Как проверить форму?\n\nОтправить тестовое обращение и подтвердить карточку, поля, источник и ответственного в CRM.\n\n### Кому принадлежат доступы?\n\nКомпании-владельцу сайта. Подрядчик получает ограниченный рабочий доступ.\n\n### Когда удалять старый сайт?\n\nПосле периода наблюдения, подтверждения переноса и выполнения плана архивирования.\n\nУспешная миграция сохраняет не только материалы, но и маршруты посетителей, работающие формы и управляемый способ отката. Чем точнее реестр URL и сценариев до релиза, тем меньше исправлений приходится делать уже на рабочем сайте.\n","\u003Ch1>Как перенести корпоративный сайт на 1С-Битрикс: контент, SEO-адреса, формы и доступы\u003C\u002Fh1>\n\u003Cp>Переезд сайта ломается не в момент установки новой CMS, а на забытых деталях: старом PDF без владельца, форме с письмом на личную почту, адресе с внешними ссылками или доступе бывшего подрядчика. Миграция требует учёта того, что существует сейчас, и проверки того, что должно работать после переключения.\u003C\u002Fp>\n\u003Ch2>Инвентаризация старого сайта\u003C\u002Fh2>\n\u003Cp>\u003Cimg src=\"\u002Fcontent-media\u002Farticles\u002Fkak-perenesti-korporativnyy-sayt-na-1s-bitriks-kontent-seo-adresa-formy-i-dostupy\u002Fassets\u002F3da73a92a23f.webp\" alt=\"Схема: Как перенести корпоративный сайт на 1С-Битрикс: контент, SEO-адреса, формы и доступы\">\u003C\u002Fp>\n\u003Cp>До разработки выгружают список URL, шаблонов, файлов, форм, метаданных, редиректов, целей аналитики и внешних интеграций. Для каждой позиции фиксируют действие: перенести, объединить, заменить, закрыть с понятным ответом или оставить на старой платформе до отдельного этапа.\u003C\u002Fp>\n\u003Cp>Содержимое не переносят механически. Устаревшие новости, дубли услуг и неактуальные документы лучше отсеять до переноса, иначе новая CMS наследует старый беспорядок.\u003C\u002Fp>\n\u003Ch3>Что зафиксировать\u003C\u002Fh3>\n\u003Cul>\n\u003Cli>реестр URL\u003C\u002Fli>\n\u003Cli>аудит файлов\u003C\u002Fli>\n\u003Cli>владельцы контента\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>SEO-адреса и редиректы\u003C\u002Fh2>\n\u003Cp>Для изменяемых URL готовят карту соответствий: старый адрес, новый адрес, тип перенаправления, причина и результат проверки. Нельзя отправлять всё на главную страницу: посетитель и поисковая система должны получать наиболее близкий релевантный материал.\u003C\u002Fp>\n\u003Cp>После переключения проверяют статусы ответов, цепочки редиректов, канонические адреса, sitemap и robots.txt. Анализируют реальные ошибки, а не только список, составленный до запуска.\u003C\u002Fp>\n\u003Ch3>Что зафиксировать\u003C\u002Fh3>\n\u003Cul>\n\u003Cli>карта 301-редиректов\u003C\u002Fli>\n\u003Cli>контроль 404\u003C\u002Fli>\n\u003Cli>проверка индексации\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>Формы и CRM\u003C\u002Fh2>\n\u003Cp>Для каждой формы описывают поля, согласие, получателя, создание лида или сделки, передачу источника и реакцию при сбое. Тестовая заявка должна пройти весь путь до ответственного в CRM, а не просто показать сообщение на сайте.\u003C\u002Fp>\n\u003Cp>Перед запуском рекламных кампаний отдельно проверяют UTM-метки, дедупликацию и уведомления. На переносе часто теряется не форма, а её контекст.\u003C\u002Fp>\n\u003Ch3>Что зафиксировать\u003C\u002Fh3>\n\u003Cul>\n\u003Cli>тестовые обращения\u003C\u002Fli>\n\u003Cli>карта полей\u003C\u002Fli>\n\u003Cli>лог ошибок обмена\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>Доступы и редакторы\u003C\u002Fh2>\n\u003Cp>У владельца сайта должны остаться доступы к домену, хостингу, CMS, аналитике, почте уведомлений и хранилищу копий. Учётные записи выдают персонально; общие пароли и доступ бывшего исполнителя исключают до переключения.\u003C\u002Fp>\n\u003Cp>Редакторы получают роли по своим задачам. После обучения они создают тестовый материал и проходят короткий сценарий публикации, чтобы обнаружить непонятные права до реальной новости.\u003C\u002Fp>\n\u003Ch3>Что зафиксировать\u003C\u002Fh3>\n\u003Cul>\n\u003Cli>реестр доступов\u003C\u002Fli>\n\u003Cli>роли редакторов\u003C\u002Fli>\n\u003Cli>порядок отзыва доступа\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>Окно релиза и откат\u003C\u002Fh2>\n\u003Cp>На день переключения назначают ответственных, замораживают контент на старом сайте, делают проверенную копию и определяют критерии отката. В чек-лист входят DNS, сертификат, ключевые URL, формы, аналитика и доступ к админке.\u003C\u002Fp>\n\u003Cp>После запуска наблюдают за ошибками и обращениями, а не объявляют миграцию завершённой после первого открытия главной страницы. Первые дни дают данные для точечной корректировки.\u003C\u002Fp>\n\u003Ch3>Что зафиксировать\u003C\u002Fh3>\n\u003Cul>\n\u003Cli>окно работ\u003C\u002Fli>\n\u003Cli>критерии отката\u003C\u002Fli>\n\u003Cli>первые проверки после релиза\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>Решение о готовности к переносу\u003C\u002Fh2>\n\u003Cp>К запуску переходят после того, как для каждого типа страницы определены новый адрес, источник контента, ответственный за проверку и действие при ошибке. Формы, личные кабинеты, поиск и платежи, если они есть, проверяют как отдельные сценарии: перенос текстов не подтверждает работу этих функций.\u003C\u002Fp>\n\u003Cp>Перед переключением DNS или публикацией составляют план возврата. В нём указывают, кто принимает решение об откате, какую версию сайта возвращают и как фиксируют обращения пользователей в первые часы. Это не резервный пункт в документе, а рабочее условие запуска.\u003C\u002Fp>\n\u003Ch2>Рабочий артефакт\u003C\u002Fh2>\n\u003Cp>Журнал миграции ведут по URL: старый адрес, новый адрес или причина исключения, тип редиректа, результат проверки и исполнитель. Отдельным списком остаются доступы, резервная копия и место хранения архива старого сайта.\u003C\u002Fp>\n\u003Cp>После релиза журнал дополняют фактическими результатами: какие маршруты проверены, где исправлены ссылки и какие задачи перенесены в следующий этап. По нему можно восстановить ход переноса без догадок и поиска по переписке. Журнал хранят вместе с инструкцией для дежурной команды на период после переключения.\u003C\u002Fp>\n\u003Ch2>Часто задаваемые вопросы\u003C\u002Fh2>\n\u003Ch3>Можно ли перенести всё автоматически?\u003C\u002Fh3>\n\u003Cp>Автоматизация помогает с типовыми данными, но не заменяет аудит контента, файлов и интеграций.\u003C\u002Fp>\n\u003Ch3>Нужно ли менять URL?\u003C\u002Fh3>\n\u003Cp>Только при понятной причине. Для изменённых адресов готовят карту редиректов.\u003C\u002Fp>\n\u003Ch3>Как проверить форму?\u003C\u002Fh3>\n\u003Cp>Отправить тестовое обращение и подтвердить карточку, поля, источник и ответственного в CRM.\u003C\u002Fp>\n\u003Ch3>Кому принадлежат доступы?\u003C\u002Fh3>\n\u003Cp>Компании-владельцу сайта. Подрядчик получает ограниченный рабочий доступ.\u003C\u002Fp>\n\u003Ch3>Когда удалять старый сайт?\u003C\u002Fh3>\n\u003Cp>После периода наблюдения, подтверждения переноса и выполнения плана архивирования.\u003C\u002Fp>\n\u003Cp>Успешная миграция сохраняет не только материалы, но и маршруты посетителей, работающие формы и управляемый способ отката. Чем точнее реестр URL и сценариев до релиза, тем меньше исправлений приходится делать уже на рабочем сайте.\u003C\u002Fp>\n"]