Чек-лист переноса сайта на новый движок
Причины переезда сайта на новую 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 чеков. Внимательность к деталям, редиректам, тегам обеспечит вам переезд
на новую платформу с минимальными потерями трафика. Также не забудьте создать резервную копию на каком-нибудь домене или поддомене (предварительно закрыв от индекса). Вы всегда сможете вернуться к ней и перенести недостающие данные, если потребуется, а также сможете сравнить новый сайт со старым.
SPA сайты уже не индексируются никак? JavaScript поисковые боты игнорируют?
В качестве внутренних ссылок должны использоваться относительные ссылки, а не абсолютные.Скажите пожалуйста: почему? В чём преимущество таких ссылок? Мой опыт говорит об обратном:
В каждой CMS формируются свои директивы, которые следует закрывать от индекса поисковых систем.1) если кто-то заимствует контент, то абсолютные ссылки внутри текста ведут на источник, а не 404-ю страницу;
2) если контент публикуется и на сторонних ресурсах, нужно заморачиваться с добавлением доменного имени, чтобы нигде не получить ссылки, ведущие в никуда.
А, понятно, это просто не совсем качественный перевод какой-то старой статьи...
SPA индексируются ровно так, как настроите. Обычно таки хреново.
Беда в том, что ни один бот не обрабатывает JS и AJAX при первичном сканировании. Если сможет - обработает. Но потом. А вам ещё сопоставлять, что он там нарендерил. Так что правило номер один: всё критически важное - только в HTML, в статике.
Ориентироваться же на то, что кто-то притырит у вас контент и так и разместит - как-то не труЪ. Доров много, это правда, но защищаться от парсинга лучше не так.
Спасибо за полезную инфу. Упустил этот момент.
> Ориентироваться же на то, что кто-то притырит у вас контент и так и разместит - как-то не труЪ.Да нет, я имел в виду: зачем заморачиваться с прописыванием относительных ссылок, когда абсолютные приносят больше пользы, чем проблем? Извлечение выгоды из попыток "тыринга" тут как позитивный пример, не цель и не защита. Целью я считаю упрощение контроля за ссылками на сайте в целом: при абсолютных не нужно городить автозамену в той части проекта, которая ответственна за кросс-постинг, да и в RSS ленте (если она требуется и если там дублируется контент) ссылки валидные будут. Так ли страшны абсолютные ссылки, что нужно отказываться от них?
Если адрес домена в абсолютных ссылках проставляется программно, то ничего страшного. А вот если текстом, то в случае переезда на другой домен или создании поддомена, вы вспомните, как хороши относительные)
Тут, скорее традиция и защита от внутреннего и внешнего дурака. Скажем, несколько лет все перетаскивали сайты на https. А потом понеслось: то домен под фильтр уйдёт благодаря склику конкурентами, то РКН вдруг подумает, что надо бы заблокировать за что-нибудь и приходится переезжать. В основном, конечно, дичь, но иной раз можно немного сэкономить время.
Только с костылями в виде пререндеринга, которых можно было бы избежать если изначально не пытаться применять технологии для разработки веб-приложений к разработке веб-сайтов.
Очередной 100 чек лист как перенести сайт.
Сколько таких статей было?
Главное не потерять ссылки? Ну логично
Вот шутки-шутками, а один местный (в смысле, периодически активничающий на vc.ru под видом сео-эксперта) дурачок нам однажды накатал ТЗ на "сео-правки", включающие в себя перевод всех относительных урлов в абсолютные. И топил, что это очень-очень важно для правильного технического сео.
Ну там еще куча перлов была в его ТЗ, вроде требования добавить H1-заголовок на политику конфиденциальности или атрибут rel="canonical" к pdf-файлу, но вот это запомнилось больше всего.
Комментарий удален модератором
Комментарий удален модератором