Как перенести сайт на новую CMS и не лишиться трафика

Решение сменить CMS (систему управление контентом сайта) – это решительный шаг, на который обычно идут после долгих дебатов разработчиков и проведения полноценного анализа, в котором указываются сложности и риски, сопровождающие данный процесс. Самой весомой причиной ее смены является невозможность внести новые значимые изменения на сайте.

Одна из главных проблем при переезде сайта на новую CMS – возможная смена URL адресов страниц, что может привести к потере их веса и утрате позиций. Если работа скрипта ЧПУ для старой и новой CMS схожа, то проблема во многом решена, поскольку в таком случае можно просто оставить старые страницы. Но чаще всего такой возможности нет, поэтому для сохранения позиций и трафика сайта требуется основательно подготовиться.

Что же нужно сделать, чтобы перенос сайта на новую CMS прошел наименее болезненно для позиций сайта и его трафика?

Общие рекомендации

Бэкап сайта

Как бы тщательно ни велась подготовительная работа, настоятельно рекомендуется сделать полноценный бэкап сайта, в который следует включить:

• базы данных;
• все файлы с FTP.

Лучше всего сделать несколько полноценных бэкапов за разные даты.

Минимизация контентных изменений

При смене CMS важно сохранить наполнение и верстку сайта – все последующие корректировки и внедрения правок следует проводить только тогда, когда поисковые системы полностью проиндексируют новый сайт. Дополнительные изменения в случае смены адресов страниц могут затруднить для поисковиков понимание «преемственности» их содержимого.

Выбор корректного времени для переноса

Важно правильно подобрать дату релиза сайта. Это не должно произойти в последний рабочий день перед выходными, а также за несколько недель перед важным событием в тематике, когда ожидается значительный прирост трафика на сайте (например, для интернет-магазина цветов не стоит это делать в конце февраля, перед 8 Марта). Важно согласовать срок релиза с SEO-специалистом и другими ответственными специалистами, которые будут осуществлять проверку релиза сайта.

Тестовый поддомен

Тестовый поддомен, на который переносится сайт, обязательно должен быть закрыт от индексации. Это делается директивой, которая прописывается в файле robots.txt:

User-agent: *

Disallow: /

К чему может привести невыполнение этого пункта:

• Страницы тестового поддомена попадут в индекс ПС;
• Пользователи попадут на некачественные страницы сайта;
• Произойдет размытие релевантности на основном сайте – в итоге посадочные страницы могут просесть по ключевым запросам и потерять трафик еще до собственно самого переноса.

Частые ошибки: на тестовый поддомен размещается robots.txt от основного сайта (указание в директиве host основного домена, увы, не поможет), не указывается поле User-Agent. Проверить содержимое файла можно в сервисе «Анализ robots.txt» Яндекс.Вебмастера.

Все будущие изменения на сайте сначала следует внедрить на тестовом поддомене. Поэтому перед релизом не забудьте проконтролировать внедрение всех составленных для разработчиков ТЗ (по переносу контента, метатегов, настройке формирования ЧПУ и т.д.), а также провести аудит на технические ошибки и юзабилити. В случае если на тестовом поддомене проводилось добавление новой информации (новостей, статей, товаров), требуется синхронизировать содержимое сайтов перед переносом и дождаться учета нового контента роботами поисковых систем.

Служебные файлы

Файл Robots.txt

Сразу после переноса сайта на основной домен нужно составить актуальный файл robots.txt, при этом тестовый домен остается закрытым от индексации.

Частая ошибка: вместо составления нового robots.txt для основного домена подгружают файл с тестового (который обычно закрыт от индексации) – в результате поисковики теряют сайт, а сайт теряет позиции и посетителей.

Файл sitemap.xml

После того как составлен файл robots.txt, генерируется карта сайта, которая размещается в корне. Путь к карте прописывается в robots.txt:

Sitemap: http://site.ru/sitemap.xml

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

• В административной части должна быть реализована возможность изменения тегов priority и changefreq.
• Должны быть корректно заполнены XML-теги changefreq и lastmod.
• Тег priority может формироваться на основании данных о вложенности в структуре той или иной страницы.
• Тег changefreq должен формироваться на основании данных о потенциальной частоте обновления контента документа.
• Тег lastmod должен содержать дату последнего изменения контента страницы (но не момент генерации документа).

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

В карте сайта должны быть только те страницы, которые открыты для индексации и имеют код ответа сервера 200. В случае если это файл sitemapindex, он должен содержать ссылки на доступные файлы XML-карты.

С правилами составления sitemap подробнее можно ознакомиться тут.

Проверку файлов Sitemap на синтаксические ошибки можно выполнить в сервисе «Анализ файлов Sitemap» в Яндекс.Вебмастере и «Инструмент проверки файла robots.txt» в Google Search Console.

Фиды для поисковых сервисов

Если у вас на сайте настроены:

• файл выгрузки для Турбо-страниц;
• AMP-страницы;
• файл выгрузки для Яндекс.Маркета;
• файл выгрузки для Яндекс.Дзена;
• файл выгрузки для программы «Товары и цены» Яндекса;

Не забудьте также перенести/перенастроить их в новую CMS.

Заголовки ответов сервера

После релиза необходимо проверить ответ сервера обычных страниц. Все страницы действующего сайта должны отдавать ответ сервера 200.

Если ранее для страниц были настроены заголовки Last-modified и If-Modified-Since, их также следует настроить для новой CMS. Проверить корректность работы можно сервисом Last-Modified.com.

Для несуществующих страниц должна быть настроена корректная обработка 404-й ошибки (один из стандартных кодов ответа HTTP о том, что сервер не может найти запрошенные данные) в шаблоне сайта. Страница 404 должна отдавать соответствующий ответ сервера (404!) и включать в себя:

• Информацию для пользователя о том, что по адресу, по которому он обратился, нет страницы
• Удобную навигацию по разделам сайта, чтобы пользователь мог выбрать, куда ему пойти дальше.

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

Метаинформация и контентное наполнение

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

Все контентное наполнение, теги Title и Meta-Description, заголовки H1–H6, теги link rel=”canonical” должны быть перенесены на соответствующие страницы с минимальными изменениями. Для переноса контента следует составить таблицу по переносу (если старые и новые страницы не совпадают), в которой указать, какой именно контент нужно перенести:

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

Микроразметка

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

Расширенный сниппет в Google с ценой и рейтингом, основанный на данных из товарной микроразметки:

Проверку следует осуществлять через Structured Data Testing Tool от Google и через Валидатор микроразметки в Яндекс.Вебмастере.

Счетчики аналитики и панели вебмастеров

Обязательно следует перенести счетчики аналитики (Яндекс.Метрика, Google Analytics и др.) и верификационные файлы или теги панелей вебмастеров (Яндекс.Вебмастер, Google Search Console и др.), если они были на предыдущей версии сайта.

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

После размещения сайта на основном домене обязательно проверяется работоспособность Яндекс.Метрики, Google Analytics и корректность работы их целей. Проверяется доступность сайта в панелях Яндекс.Вебмастер и Google Search Console.

Перенаправления

В случае если вместе со сменой CMS произошла смена адресов страниц, необходимо настроить 301 редиректы со старых адресов страниц на новые. Не стоит настраивать редиректы с 302/303/307 кодом ответа сервера или через тег Meta-Refresh, так как все они говорят, что страница переехала на новый адрес временно, и имеет смысл рассматривать в качестве отображаемого в поиске устаревший URL.

Также необходимо проверить редиректы с основных зеркал сайта (http/https, www/без www и со слэшем на конце/без слэша на конце), данные редиректы должны отрабатывать на всех страницах сайта, а не только на главной странице.

Если при переносе некоторые страницы были удалены, то необходимо подобрать к ним наиболее близкие по содержимому страницы и настроить 301 редирект с удаленных на новые.

Внутренние ссылки

Внутренние ссылки должны быть заменены на актуальные. Рекомендуется избавиться от ссылок с 301 редиректом.

Все внутренние ссылки и подгружаемые файлы (например, с помощью тега link) должны быть не битыми, URL внутренних ссылок должны отдавать код ответа 200 ОК.

Скорость загрузки

Рекомендуется проверить скорость загрузки различных страниц сайта в сервисах Google PageSpeed, Google LightHouse и GTMetrix. Скорость загрузки страниц сайта имеет особое значение для пользователей мобильных устройств, поэтому в первую очередь проработать ее необходимо именно для них.

Даже в случае если тестовый домен закрыт HTTP-авторизацией, его страницы можно проверить через GTMetrix (введя данные для входа) и Google Lighthouse (авторизовавшись через браузер).

Далее – проводим нагрузочное тестирование сайта на новой CMS. Например, через сервис Loaddy.

Обновление дизайна

Если вместе со сменой CMS произошло обновление дизайна сайта с версткой, рекомендуется также:

• проверить его на корректность отображения и работы на различных устройствах;
• убедиться в прохождении сайтом проверки удобства просмотра на мобильных устройствах (Google Mobile Friendly Test и «Проверка мобильных страниц» в Яндекс.Вебмастере).

После переноса

После переноса сайта с обновленной CMS на «боевой» домен необходимо удостовериться в отсутствии артефактов тестового домена, на котором сайт находился. Для этого проверяются все служебные файлы (XML карта сайта, файл robots.txt и различные файлы выгрузок), ссылки в коде страниц сайта, заголовки ответа сервера, содержимое микроразметки, наличие необходимых редиректов и содержимое тегов link с атрибутом rel=”canonical”.

В заключение

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