Как перенести сайт на новую 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!) и прилагать. Ant. исключать в себя:

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

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

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

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

Все контентное запруживание, теги 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 произошло обновление дизайна сайта с версткой, рекомендуется в свой черед:

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

Впоследствии переноса

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

В заключительный аккорд

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

Источник: www.seonews.ru