{"id":14276,"url":"\/distributions\/14276\/click?bit=1&hash=721b78297d313f451e61a17537482715c74771bae8c8ce438ed30c5ac3bb4196","title":"\u0418\u043d\u0432\u0435\u0441\u0442\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0432 \u043b\u044e\u0431\u043e\u0439 \u0442\u043e\u0432\u0430\u0440 \u0438\u043b\u0438 \u0443\u0441\u043b\u0443\u0433\u0443 \u0431\u0435\u0437 \u0431\u0438\u0440\u0436\u0438","buttonText":"","imageUuid":""}

Чек-лист переноса сайта на новый движок

Причины переезда сайта на новую CMS могут быть разными — например, нужно обновить функционал, дизайн, структуру. Это могут быть требования импортёра (например, для сайтов автодилеров), когда все идентичные сайты переезжают на новую платформу. Также практикуется перенос сайта на новый хостинг и домен, но здесь мы рассмотрим переезд именно на новую платформу, так как он наиболее специфичен.

Перенос сайта на новую платформу — трудозатратная процедура. В ней задействованы разные специалисты: как правило, это SEO-специалист, программист и контент-менеджер.

Сайт можно перенести с минимальными потерями, а можно потерять весь наработанный трафик, если допустить ошибки. Именно поэтому важно соблюдать технологию переноса сайта.

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

На основании своего опыта мы собрали чек-лист для переноса сайта на новую CMS с минимальными потерями.

Чек-лист переноса сайта на новый движок

  • 1. Сохранена структура сайта

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

  • 2. Создана карта редиректов

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

  • 3. Перенесены метатеги title и description

Новый сайт необходимо заполнить метатегами. Для этого достаточно сделать выгрузку тегов на старом сайте и внести их вручную либо через шаблон (если это предусмотрено) на новом.

  • 4. Перенесены SEO-тексты

Скорее всего, для сайта, на котором велось SEO, были написаны тексты для продвижения. Их также стоит перенести на новую систему управления сайтом.

  • 5. Проверена разметка страниц

Страницы должны иметь такую же текстовую разметку, как и ранее. Кроме того, нужно проверить статичное содержание на страницах, где это требуется. Текст должен быть в статичном html — тогда он будет понятен поисковым системам.

  • 6. Перенесены счётчики и вебмастеры

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

  • 7. Приостановлены редиректы с мобильной версии

Если ваш сайт имеет мобильную версию, то и редиректы в ней следует обновить.

  • 8. Сформирован новый robots.txt

В каждой CMS формируются свои директивы, которые следует закрывать от индекса поисковых систем. Поэтому файл robots.txt нужно сформировать заново, в зависимости от вида CMS.

  • 9. Сохранено основное зеркало

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

  • 10. Сгенерирован sitemap.xml

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

  • 11. Проверено наличие 404-страниц

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

  • 12. 404-страницы настроены

На новом сайте битые ссылки должны отдавать код 404, корректные — код 200. Корректность кодов важна для поисковой оптимизации сайта, поэтому, если эта проблема обнаружена, её стоит устранить до запуска сайта.

  • 13. Используются относительные ссылки

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

  • 14. Настроен nofollow

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

  • 15. Настроены страницы пагинации

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

  • 16. Код проверен на лишние элементы

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

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

на новую платформу с минимальными потерями трафика. Также не забудьте создать резервную копию на каком-нибудь домене или поддомене (предварительно закрыв от индекса). Вы всегда сможете вернуться к ней и перенести недостающие данные, если потребуется, а также сможете сравнить новый сайт со старым.

0
8 комментариев
Написать комментарий...
Дмитрий Глашков
Текст должен быть в статичном html — тогда он будет понятен поисковым системам.

SPA сайты уже не индексируются никак? JavaScript поисковые боты игнорируют?

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

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

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

А, понятно, это просто не совсем качественный перевод какой-то старой статьи...

Ответить
Развернуть ветку
Виктор Петров

SPA индексируются ровно так, как настроите. Обычно таки хреново.
Беда в том, что ни один бот не обрабатывает JS и AJAX при первичном сканировании. Если сможет - обработает. Но потом. А вам ещё сопоставлять, что он там нарендерил. Так что правило номер один: всё критически важное - только в HTML, в статике.
Ориентироваться же на то, что кто-то притырит у вас контент и так и разместит - как-то не труЪ. Доров много, это правда, но защищаться от парсинга лучше не так.

Ответить
Развернуть ветку
Дмитрий Глашков
> Беда в том, что ни один бот не обрабатывает JS и AJAX при первичном сканировании. Если сможет - обработает. Но потом.

Спасибо за полезную инфу. Упустил этот момент.

> Ориентироваться же на то, что кто-то притырит у вас контент и так и разместит - как-то не труЪ.

Да нет, я имел в виду: зачем заморачиваться с прописыванием относительных ссылок, когда абсолютные приносят больше пользы, чем проблем? Извлечение выгоды из попыток "тыринга" тут как позитивный пример, не цель и не защита. Целью я считаю упрощение контроля за ссылками на сайте в целом: при абсолютных не нужно городить автозамену в той части проекта, которая ответственна за кросс-постинг, да и в RSS ленте (если она требуется и если там дублируется контент) ссылки валидные будут. Так ли страшны абсолютные ссылки, что нужно отказываться от них?

Ответить
Развернуть ветку
Анатолий Потапов

Если адрес домена в абсолютных ссылках проставляется программно, то ничего страшного. А вот если текстом, то в случае переезда на другой домен или создании поддомена, вы вспомните, как хороши относительные)

Ответить
Развернуть ветку
Виктор Петров

Тут, скорее традиция и защита от внутреннего и внешнего дурака. Скажем, несколько лет все перетаскивали сайты на https. А потом понеслось: то домен под фильтр уйдёт благодаря склику конкурентами, то РКН вдруг подумает, что надо бы заблокировать за что-нибудь и приходится переезжать. В основном, конечно, дичь, но иной раз можно немного сэкономить время.

Ответить
Развернуть ветку
Дмитрий Александрович
SPA сайты уже не индексируются никак?

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

Ответить
Развернуть ветку
Alexey

Очередной 100 чек лист как перенести сайт.
Сколько таких статей было?
Главное не потерять ссылки? Ну логично

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

Вот шутки-шутками, а один местный (в смысле, периодически активничающий на vc.ru под видом сео-эксперта) дурачок нам однажды накатал ТЗ на "сео-правки", включающие в себя перевод всех относительных урлов в абсолютные. И топил, что это очень-очень важно для правильного технического сео.

Ну там еще куча перлов была в его ТЗ, вроде требования добавить H1-заголовок на политику конфиденциальности или атрибут rel="canonical" к pdf-файлу, но вот это запомнилось больше всего.

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку
5 комментариев
Раскрывать всегда