Руководство по миграции сайта: SEO-стратегия, процесс

Время для чтения: 25 мин
  • Апрель 27, 2019
  • SEO

SEO & Conversion Rate Optimization -
специалист, консультант, team-лид c 2012 года.

Что такое «миграция сайта»?

Миграция сайта (прим.ред: переезд, перенос) — это термин, используется SEO-специалистами для описания любого мероприятия, при котором на сайте происходят существенные изменения, способные повлиять на его видимость в поисковых системах. Сюда относят изменения в его URL, платформе (CMS), структуре, контенте, UI или UX-дизайне.

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

 

План статьи

Примеры миграции сайта. Типы миграции сайта
Подводные камни в миграции сайта. Процесс миграции сайта
1. Оценка и планирование
2. Подготовка к запуску
3. Тестирование перед запуском
4. Действия в день запуска
5. Тестирование после запуска
6. Определение результатов миграции
Дополнение: Полезные инструменты


 

Примеры миграции сайта

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

 

Развенчание мифа об ожидаемом снижении трафика

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

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

 

Примеры неудачных миграций сайтов

На следующем графике показана неудачная миграция сайта крупного британского ритейлера. Сайт потерял 35% своей видимости в поиске через 2 недели после перехода с HTTP на HTTPS. Полное восстановление заняло у них около 6 месяцев. Компания из-за этого понесла значительные потери в доходах. Это типичный пример плохой миграции сайта, вызванной плохими — планированием или реализацией.

Пример плохой миграции сайта - восстановление заняло 6 месяцев!

 

Но восстановление не всегда возможно. Приведенный ниже график видимости взят из другого крупного британского ритейлера, где переход с HTTP на HTTPS привел к потере видимости на 20%.

Еще один пример плохой миграции сайта - никаких признаков восстановления через 6 месяцев!

Вполне реально перейти с HTTP на HTTPS без потери такого большого количества трафика и в течение столь длительного периода, за исключением первых нескольких недель, когда Google обнаруживает новые URL и обновляет результаты поиска.

«В моей практике был случай, когда одна компания шла на поводу разных веб-студий и делала ощутимые переработки сайта — 1 раз чуть ли не в полгода. В эстетике может и был прогресс, но при этом были и постоянные откаты назад по трафику из-за некорректной миграции» (с) HarryChy

 

Примеры успешной миграции сайта

Как выглядит успешная миграция сайта? Это во многом зависит от типа миграции, целей и KPI (более подробно позже). Но в большинстве случаев успешная миграция сайта содержит хотя бы один из следующих пунктов:

  1. Минимальная потеря поисковой видимости в течение первых нескольких недель (краткосрочная цель)
  2. Рост видимости в дальнейшем — в зависимости от типа миграции (долгосрочная цель)

На скрине ниже — миграция сайта с HTTP на HTTPS сопровождается значительным ускорением времени загрузки страниц сайта.

Рост видимости после падения

Следующий скриншот взят после полной переработки сайта. Здесь активно подключили SEO-специалиста на несколько месяцев — до начала работы, для поддержки на этапах стратегии, планирования и тестирования.

Дату запуска пришлось несколько раз переносить из-за рисков, до полного устранения основных технических моментов. Но, как видно на графике — ожидание того стоило. Видимость сайта в поиске не только не упала, но и фактически начала расти с первой недели.

Рост видимости через месяц после миграции достиг 60%, а органический рост трафика через два месяца после запуска — превысил 80%.

Пример очень успешной миграции сайта - мгновенный рост после запуска нового сайта

Пример очень успешной миграции сайта — мгновенный рост после запуска нового сайта

 

Это довольно сложная миграция, ведь новый сайт был перепроектирован и построен с нуля на новой платформе, включающей новые целевые страницы, обновленную структуру URL’ов, множество редиректов для сохранения веса ссылок, а также переход с HTTP для HTTPS.

На самом деле, довольно рисковано внедрять слишком много изменений одновременно, потому что, если что-то пойдет не так — будет сложно выяснить в чем именно заключается ошибка. Но в то же время откладывать серьезные изменения на более поздний срок тоже не лучший вариант, так как для этого потребуется больше ресурсов.

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


 

Типы миграции сайта

Существует много типов миграции сайтов. Все зависит от характера изменений, которые осуществляются.

Типы миграции сайта

Официальная справка от Google в основном охватывает миграции которые классифицируются следующим образом:

  • Сайт перемещается с изменениями URL;
  • Сайт перемещается без изменения URL;

 

Миграции сайта

Структура URL

Обычно это происходит, когда сайт переходит на другую структуру URL:

 

Изменение протокола

Классический пример — переход с HTTP на HTTPS.

 

Смена поддомена или подпапки

Такое часто встречается в международном SEO, когда бизнес решает переместить один или несколько ccTLD (прим.ред: региональные домены верхнего уровня) на поддомены или подпапки.

Другой распространенный пример — это когда мобильный сайт, находящийся на отдельном поддомене или подпапке, становится сопоставимым по адаптивности c dekstop-версией (прим.ред: за счет развития последней), а структура URL на desktop и mobile ничем не отличаются (прим.ред: объединение двух версий в одну).

 

Смена доменного имени

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

 

Смена домена верхнего уровня

В ситуациях когда бизнес решает запустить международные сайты и необходимо переехать с ccTLD (домен верхнего уровня с кодом страны) к gTLD (общий домен верхнего уровня) или наоборот. Например, перейти с .co.uk на .com или перейти с .com на .co.uk и т. д.

 

Изменение структуры сайта

Это изменения в информационной архитектуре сайта, которые обычно влияют на внутренние ссылки и структуру URL.

 

Другие виды миграций

Существуют и другие типы миграции, связанные м изменениями контента, структуры, дизайна или платформы сайта.

 

А) «Реплатформинг»

Когда сайт перемещается с одной платформы/CMS на другую, например, переход с WordPress на Magento. Или же просто осуществляется обновление до последней версии. В некоторых случаях такой переезд может привести к изменению дизайна и URL-адресов (прим.ред: что не будет сразу заметно).

 

Б) Изменение контента

Значительные изменения контента, такие как переписывание контента, объединение или сокращение — могут сильно повлиять на видимость сайта в поиске. Это часто влияет на таксономию сайта, навигацию и внутренние ссылки.

 

В) Mobile-изменения

Кроме выделения отдельной мобильной версии, сюда ещё относится и внедрение AMP (прим.ред: Accelerated Mobile Pages) или создание PWA (прим.ред: Progressive Web Applications).

 

Г) Структурные изменения

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

 

Д) Редизайн сайта

От частичных изменений в UI-дизайне до полной модернизации сайта, включающей значительные изменения в коде и компоновке.

 

Е) Гибридные миграции

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


 

Подводные камни в миграции сайта

Несмотря на то, что каждая миграция сайта отличается, можно выделить наиболее примечательные проблемы:

Причины неудачных миграций сайтов

Невнятная стратегия

Некоторые миграции сайта обречены на провал из-за неясных и нереалистичных целей.

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

 

Некорректное планирование

Разработка подробного плана на раннем этапе — поможет избежать проблем в процессе. Обязательно нужно закладывать дополнительное время и ресурсы для решения любых непредвиденных обстоятельств. Стоит быть гибким и быть готовым правильно и быстро среагировать на них.

Желательно не планировать запуск ощутимых обновлений перед максимальными сезонными пиками. Потому что, если что-то пойдет не так — не будет достаточно времени, чтобы исправить проблемы. Лучше это осуществлять за полгода или в низкие пики сезонности.

 

Недостаточно ресурсов

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

Лучше закладывать дополнительные ресурсы, как минимум на +20% от изначально запланированных. Этот позже позволит быстро решать любые проблемы, как только они возникнут, не ставя под угрозу общий результат.

 

Нет SEO/UX-консультации

Когда изменения происходят на сайте — каждое решение должно быть взвешено с точки зрения как UX, так и SEO. Например, удаление большого количества контента или ссылок для улучшения UX — может ослабить оптимизацию сайта под важные ключевые слова для бизнеса или привести к проблемам с индексацией и т.д. В любом случае, такие изменения могут повредить видимости сайта в поиске.

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

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

«Как по мне, клиенту при миграции сайта более оптимально подключать стороннего, независимого SEO-специалиста. Почему? Да потому что тот будет рекомендовать только то, что нужно по делу.

В других случаях (прим.ред: когда SEO-специалист и веб-разработчики из одной команды) — может быть лишнее раздувание сметы.» (с) HarryChy

 

Позднее обращение к профи

Миграция сайта может занимать несколько месяцев и поэтому требует тщательного планирования и достаточного времени для теста. Обращаться за профессиональной поддержкой на более позднем этапе — довольно рискованно, потому что могли быть пропущены важные шаги (прим.ред: их гораздо сложнее исправлять).

«Как-то ко мне в похожей ситуации (прим.ред: на поздней стадии) обратился один клиент. Там начудили серьезно со структурой, URL, с индексацией. Поисковый робот уже довольно давно это всё четко просканировал.

От меня требовалось, как от спасителя в максимально кратчайшие сроки и чуть ли не под гарантию — всё восстановить. Не взялся. А вот если бы на более ранней стадии — да» (c) HarryChy

 

Отстутствие тестирования

Важно выделить некоторое время и усилия на тщательное тестирование перед запуском сайта. Если в ходе тестирования были выявлены критические проблемы — лучше отложить запуск. Не стоит запускать сайт, если он не был проанализирован как SEO и UX-специалистами.

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

 

Медленное исправление ошибок

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

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

 

Недооценка возможных последствий

Не всегда представители бизнеса реалистично оценивают возможные последствия. Часто действуют по девизу: «Давайте запустим как можно скорее и исправим позже». Не подозревают, что для переиндексации сайта может потребоваться всего несколько дней, а затем восстановление уже займет от нескольких месяцев до полугода.

Как раз в обязанности SEO-специалиста и входит объяснение клиентам всех этапов и возможных негативных сценариев. На основании этого представители бизнеса смогут принимать более обоснованные решения и иметь реалистичные ожидания.


 

Процесс миграции сайта

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

Этап 1: «Оценка и планирование»

К плану статьи ↑

Выделение целей и рисков

Независимо от причин, стоящих за проектом по миграции сайта — важно сразу определиться с целями. Это поможет сформировать правильные ожидания. Переезд сайта с HTTP на HTTPS очень отличается от полной переработки. В первом случае цель — сохранить уровень трафика, во втором — можно рассчитывать на рост.

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

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

В итоге у вас должен быть приоритетный список действий на реализацию.

 

Подготовка плана

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

Дата запуска — важная часть плана. В идеале, новая версия сайта должна быть запущена в то время, когда трафик низкий (прим.ред: сезонный спад). Следует иметь в виду, что миграция редко идет полностью по плану и потребуется определенная степень гибкости.


 

Этап 2: «Подготовка к запуску»

К плану статьи ↑

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

 

Обзор структуры страниц

Стоит ознакомиться с UX варфреймами или UI-мокапами новой версии сайта до начала разработки. Обзор основных шаблонов страниц может помочь выявить проблемы как по SEO, так и в UX на ранней стадии. Например, можно обнаружить, что большие части контента были удалены со страниц категорий или некоторые страницы с большим трафиком перестали отображаться в основной навигации.

Любые радикальные изменения в дизайне или контенте должны быть тщательно рассмотрены на предмет потенциальных проблем с SEO.

 

Технические SEO-спецификации

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

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

Стоит включить конкретные пункты, которые охватывают следующие области:

  • Структура URL
  • Мета-данные
  • Микроразметка
  • Директивы для canonical, meta robots
  • H1-H3-заголовки
  • Основная и дополнительная навигация
  • Внутренняя перелинковка
  • Пагинация
  • XML карта сайта
  • HTML карта сайта
  • Hreflang (если есть международные сайты)
  • Мобильные настройки (приложение, AMP или PWA)
  • Редиректы
  • Пользовательская страница 404
  • JavaScript, CSS и изображения
  • Время загрузки страниц (Deskstop и Mobile)

 

Спецификация также должна включать области функционала CMS, которые позволяют пользователям:

  • Указывать пользовательские URL
  • Обновлять H-заголовки страниц
  • Обновлять мета-данные
  • Обновлять заголовки H1 – H3
  • Добавить/изменить canonical
  • Установить атрибуты meta robots (noindex, follow, nofollow)
  • Добавить или редактировать alt атрибут для фото
  • Включить поле Open Graph
  • Включить поле Twitter Open Graph
  • Создавать/изменять редиректы
  • Обновить файл robots.txt

Также важно убедиться, что при обновлении определенного элемента (например, h1) — другие не затрагиваются (например, title страницы или ссылки в навигации).

 

Определение приоритетных страниц

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

Для этого необходимо:

  1. Просканировать действующую версию сайта (прим.ред: до обновления)
  2. Определить все индексируемые страницы
  3. Определите наиболее эффективные страницы

 

Как выделить самые эффективные страницы

После того как были спарсены все страницы, определены все индексируемые из них — рекомендуется подготовить таблицу, включающую следующие поля:

  • Действующий URL
  • Трафик из поиска за последние 12 месяцев
  • Коэффициент конверсии за последние 12 месяцев
  • Просмотры страницы за последние 12 месяцев
  • Количество ссылочных доноров
  • Количество внешних ссылок

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

Вывод: приоритетные страницы должны быть в новой версии сайта. Если по какой-либо уважительной причине меняется их URL — обязательно ставить 301 редирект на новую или самую релевантную страницу, чтобы пользователи не попадали на 404-страницу.

Если какая-то из этих страниц прекратит свое существование и не будет правильно перенаправлена — это негативно повлияет на позиции сайта и его трафик.

 

Бенчмаркинг

Ближе к запуску новой версии сайта стоит замерить эффективность ещё пока действующей версии (прим.ред: позиции, трафик, скорость загрузки страниц). Это необходимо для сравнения показателей двух версий и последующего понимания того, какие области в новой версии требуют быстрой доработки.

 

Производительность сайта

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

Рекомендуется просмотреть все основные типы страниц с помощью инструментов Google PageSpeed ​​Insights и Lighthouse. Вы можете использовать таблицы, подобные приведенным ниже, для сравнения некоторых наиболее важных показателей эффективности.

MOBILEСкорость загрузкиFCPDCLКачество оптимизацииОценка оптимизации
ГлавнаяБыстро0.7s1.4sХорошо81/100
КатегорияМедленно1.8s5.1sСредне78/100
ПодкатегорияСредне0.9s2.4sСредне69/100
Страница продуктаМедленно1.9s5.5sХорошо83/100

 

DEKSTOPСкорость загрузкиFCPDCLКачество оптимизацииОценка оптимизации
ГлавнаяХорошо0.7s1.4sСредне81/100
КатегорияБыстро0.6s1.2sСредне78/100
ПодкатегорияБыстро0.6s1.3sСредне78/100
Страница продуктаХорошо0.8s1.3sХорошо83/100

 

Данные из парсера

За несколько дней до выгрузки новой версии сайта — запускаем с помощью Screaming Frog SEO Spider (прим.ред: или его аналога) последнее сканирование действующей (старой) версии сайта. Это может очень помочь, если на новой версии возникнут какие-либо проблемы с SEO-оптимизацией.

Финальное сканирование позволит сохранить важную информацию о title страниц старого сайта, мета-данных, заголовках H1-H2, канонических страницах, страницах noindex / nofollow, ссылках. Также на всякий случаем сохраняем старые robots.txt и Sitemap.xml.

 

Данные из кабинета поисковой системы (Google Search Console)

Также экспортируем как можно больше данных по старой версии сайта из кабинета Google Search Console. Они доступны только в течение 90 дней, и есть вероятность, что после запуска нового сайта — рано или поздно исчезнут. Данные, которые стоит экспортировать:

  • Поисковая аналитика запросов и страниц
  • Ошибки сканирования
  • Заблокированные ресурсы
  • Проблемы с адаптивностью
  • Параметры URL
  • Структурированные ошибки данных
  • Ссылки на ваш сайт
  • Внутренние ссылки

 

Подготовка редиректов

Реализация редиректов является одним из наиболее важных действий при переносе сайта. Если старые URL сайта перестали существовать и неправильно перенаправляются —  это обязательно негативно скажется на поисковых позициях и трафике.

 

Почему редиректы важны при переносе сайтов?

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

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

 

Что происходит, когда редиректы реализованы неправильно?

Пользователи будут либо заходить на страницы Not Found (404), либо на нерелевантные страницы, которые не соответствуют интенту. Это в любом случае негативное влияние на показатель отказов и конверсию сайта. Последствия для поисковых систем могут быть катастрофическими: они не смогут связать страницы старой версии сайта со страницами на новом сайте (прим.ред: если URL не совпадают). Сигналы ранжирования (прим.ред: вес) не будут передаваться со старого сайта на новый, что приведет к потере видимости в поиске.

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

 

301, 302, JavaScript-редиректы, meta refresh?

Если URL между старой и новой версией сайта отличаются — стоит использовать использовать 301 редиректы (постоянные). Они сообщат поисковым системам индексировать новые URL, а также перенаправят любые сигналы ранжирования со старых URL на новые.

Также нужно использовать 301 редиректы, если ваш сайт переезжает с другого домена/поддомена, если переходите с HTTP на HTTPS.

302 редиректы используются только в ситуациях, когда перенаправление — временное и индексация нового URL не является приоритетом. Однако, если временные редиректы не снимаются в течении длительного периода времени, то могут восприниматься поисковиками так же, как и постоянные (301) перенаправления.

Следует избегать Meta Refresh и JavaScript-редиректов. Несмотря на то, что Google все лучше и лучше сканирует JavaScript — нет никаких гарантий, что они будут обнаружены или передадут ранжирующие сигналы на новые страницы.

 

Список редиректов

Файл со списком редиректов представляет собой таблицу, которая включает следующие два столбца:

  • URL старого сайта -> URL страницы на старом сайте.
  • URL нового сайта -> URL страницы на новом сайте.

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

Если невозможно найти эквивалентную страницу на новом сайте, лучше направить ее на страницу родительской категории.

 

Не забыть о старых редиректах

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

Рекомендуется исключить любые потенциальные циклические редиректы на этом этапе.

Пример:
  • URL A перенаправляет на URL B (устаревшее перенаправление)
  • URL B перенаправляет на URL C (новое перенаправление)

В результате получается циклическая цепочка:

URL A -> URL B -> URL C

 

Корректно это должно выглядеть так:

  • URL A перенаправляет на URL C (исправлено устаревшее перенаправление)
  • URL B перенаправляет на URL C (новое перенаправление)

 

«Мне как-то доводилось иметь дело с сайтом у которого интернет-маркетолог (generalist) по собственным эстетическим соображениям — менял 1 раз в месяц разные URL сайта.

Там был по сути круговорот удаления/создания страниц. И потом люди удивлялись почему не растут те или страницы по запросам :)» (с) HarryChy

 

Не забыть об URL изображений

Если изображения сайта были перемещены на новое местоположение — Google рекомендует отредиректить старые URL изображений на новые. Если перенаправить все изображения непросто, постарайтесь перенаправить хотя бы те URL изображений, на которые накапливались обратные ссылки.


 

Этап 3: «Тестирование перед запуском»

К плану статьи ↑

Убедитесь, что поисковые системы не могут получить доступ к тестовой версии

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

 

А) Сайт доступен для определенных IP-адресов (рекомендуется)

Создание тестового сайта доступным только для определенных (занесенных в белый список) IP-адресов — очень эффективный способ запретить поисковым системам сканировать его. Любой, кто попытается получить доступ к URL тестового сайта, не сможет увидеть контент, если его IP-адрес не внесен в белый список. Основным преимуществом является то, что пользователи из белого списка могут легко получить доступ и сканировать сайт без каких-либо проблем.

 

Б) Защита паролем

Защита паролем тестовой версии сайта — это еще один способ не допустить краулеров поисковых систем. Но у этого решения есть один недостаток:

В зависимости от реализации может оказаться невозможным сканировать структуру URL разными SEO-парсерами.

 

В) Блокировка Robots.txt

Добавление следующих строк кода в файл robots.txt тестовой версии не позволит поисковым системам сканировать страницы.

User-agent: *
Disallow: /

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

Второк недостаток — если по невнимательности указанный выше файл robots.txt скопируют на работающий сайт (прим.ред: новую версию), это вызовет серьезные проблемы с индексацией.

«Потверждаю вышеописанные тезисы. Сам лично видел проблемы у проекта из-за полностью открытой к индексации — тестовой версии. Плюс даже закрытие от индексации в Robots.txt — позволяло просачиваться в индекс некоторым тестовым страницам.» (c) HarryChy

 

Проверка архитектуры сайта

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

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

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

«На практике наблюдал явления когда:

А) Раздувание структуры сайта за счет дробления и выноса кластеров на отдельные страницы — давало результат.

Б) Консолидация (объединение) страниц — давала рост.

Многое зависит от характера спроса в нише. Плюс считаю, что Яндекс и Google по-разному видят данный аспект. И не так уж легко угодить им тут одновременно» (c) HarryChy

 

Проверка мета-данных и контента

Убедитесь, что title, description, H-заголовки и контент были перенесены со старой версии на новую — без проблем. Если были создали новые страницы, убедитесь, что они оптимизированы и не ориентированы на ключевые слова, которые посажены на другие страницы. Если изменили платформу (CMS), имейте в виду, что новая платформа может иметь другие значения (прим.ред: по-умолчанию) при создании новых страниц.

Не забудьте проверить, был ли загружен пользовательский контент (например, отзывы пользователей, комментарии).

 

Проверка перелинковки

Перелинковка является основой сайта. В каких областях важен корректный перенос перелинковки?

  • Главная и дополнительная навигация
  • Header и footer-ссылки
  • Ссылки из контентной части
  • Ссылки в пагинации
  • Горизонтальные ссылки (похожие статьи, продукты)
  • Хлебные крошки
  • Межсайтовые ссылки (например, ссылки на международные сайты)

 

Технические проверки

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

 

Проверка Robots.txt

Подготовьте файл robots.txt новой версии сайта на тестовом сервере. Таким образом, вы можете проверить его на наличие ошибок и избежать проблем с поисковыми системами позже. Классическая ошибка при миграции сайта — это когда файл robots.txt запрещает доступ поисковой системы, используя следующую директиву:

Disallow: /

Если это случайно будет перенесено на новую версию сайта (и это нередко происходит) — поисковые системы не смогут просканировать сайт. И всё это в конечном итоге приведет к падению видимость продвигаемых страниц, а позже ещё и к выпадению из индекса.

При подготовке файла robots.txt нового сайта убедитесь, что:

  • Он не блокирует доступ поисковой системы к страницам, предназначенным для индексации.
  • Он не блокирует JS или CSS, которые требуются поисковикам для отображения контента страницы.
  • Он ссылается на новый Sitemap.xml, а не на те, которые больше не существуют.

 

Проверка Canonical-тегов

Найдите страницы, которые не имеют канонического тега или имеют, но указывающий на другой URL. По последним стоит разобраться — это осознанно и корректно назначено? Также стоит проверить возвращают ли канонические страницы 200й ответ сервера. Важно исключить любые ответы сервера 3xx, 4xx или 5xx. Также следует поискать страницы с Canonical на другой URL в сочетании с директивой noindex (прим.ред: они одновременно конфликтуют).

 

Проверка Meta Robots

После сканирования тестовой версии сайта найдите страницы со свойствами Meta Robots, для которых установлено значение «noindex» или «nofollow». Просмотрите их внимательно каждый и задайте вопрос: «Это осознанно и корректно назначено для данной страницы»? Если нет — удалить «noindex» или «nofollow».

 

Проверка XML-карт сайта

Подготовьте 2 разных файла Sitemap.xml: один, который содержит все индексируемые страницы новой версии сайта, а другой — все индексируемые страницы старой версии. Первый поможет Google узнать об индексируемых URL новой версии. Второй поможет Google узнать о существующих редиректах и о том, что некоторые из проиндексированных URL были перенаправлены в новые места.

Вы должны проверить каждый Sitemap.xml, чтобы убедиться, что:

  • Внутри нет ошибок
  • Кодировка в UTF-8
  • Нет превышения более 50 000 строк
  • Размер не превышает 50 МБ в несжатом виде

Если строк больше 50 тыс или размер файла превышает 50 МБ — необходимо разбить карту сайта на более мелкие. Это предотвратит перегрузку сервера, если Google запрашивает Sitemap.xml слишком часто.

Кроме того, нужно проверить каждый Sitemap.xml, чтобы убедиться, что они содержат только индексируемые URL. Любые неиндексируемые URL должны быть исключены, например:

  • Страницы со статусами 3xx, 4xx и 5xx
  • Страницы без содержимого, возвращающие 200й ответ вместо 404.
  • Канонизированные страницы (кроме канонических URL на которые они ссылаются сами)
  • Страницы с директивой meta robots — «noindex»

 

<! DOCTYPE html>
<HTML> <HEAD>
<meta name = "robots" content = "noindex" />
(...)
</ HEAD>
<Тело> (...) </ body>
</ Html>
  • Страницы с X-Robots-тегом noindex в заголовке HTTP

 

HTTP / 1.1 200 ОК
Дата: вторник, 10 ноября 2017 г. 17:12:43 GMT
(...)
X-Robots-Tag: noindex
(...)
  • Заблокированные страницы в файле robots.txt

 

Совет: загрузите и откройте каждый Sitemap.xml в Excel, чтобы наглядно видеть все дополнительные дополнительных атрибуты (hreflang и т.д.)

 

Проверка HTML-карты сайта

Наличие HTML-карты сайта в некоторых случаях может быть полезным (прим.ред: в зависимости от размера и структуры сайта). HTML-карта состоящая из URL, которые не связаны с основной навигацией сайта, может значительно ускорить их индексацию. Однако не стоит создавать HTML-карту, содержащую слишком много URL’ов. Если вам нужно включить тысячи URL — рассмотрите возможность создания сегментированной HTML-карты сайта.

Например, HTML-карта сайта NYTimes.com состоит из трех уровней, каждый из которых включает более 1000 URL на карту сайта. Эти вложенные HTML-карты сайта помогают краулерам поисковых систем находить статьи, опубликованные с 1851 года (прим.ред: иначе их было бы трудно обнаружить и проиндексировать, не все из них были перелинкованы).

HTML-карта сайта NYTimes (уровень 1)

 

HTML-карта сайта NYTimes (уровень 2)

 

Проверка микроразметки

Ошибки в микроразметке необходимо выявить заранее. В идеале вы должны протестировать каждый шаблон страницы (а не каждую страницу) с помощью инструмента тестирования структурированных данных от Google .

Обязательно проверьте разметку как на Dekstop, так и на Mobile-страницах.

Инструмент сообщает только о существующих ошибках, но не указывает недостающую микроразметку. Например, если шаблон страницы вашего продукта не содержит микроразметку «Product» — инструмент не сообщит об этом.

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

Официальная документации Google: по реализации структурированных данных и поддерживаемых типах контента .

 

Проверка на наличие JavaScript

Желательно протестировать каждый шаблон страницы новой версии сайта, чтобы убедиться, что Google сможет сканировать важный контент, содержащий JavaScript. Лучше ничего не выдумывать и сделать это по инструкции Джастина Бригга .

Как показали тесты Бартоша Горалевича, даже если Google и способен сканировать и индексировать JavaScript-контент, это не означает, что он способен сканировать контент JavaScript во всех основных JavaScript-фреймворках. Таблица подтверждает выводы, что некоторые JavaScript-фреймворки не являются SEO-friendy, а AngularJS сейчас является самым проблематичным из всех.

 

Проверка мобильной версии

Проверка блокировки содержимого

Стоит убедиться, что файл robots.txt не блокирует файлы JavaScript, CSS или изображения, необходимые для отображения содержимого мобильного сайта. Это может оказать негативное влияние на то, как поисковые системы индексируют, отображают контент страницы мобильного сайта.

 

Проверка — «Mobile first index»

Чтобы избежать проблем, связанных с индексом Google для мобильных устройств — нужно тщательно посмотреть сайт для и убедиться, что между Desktop и Mobile-версиями нет несоответствий в следующих пунктах:

  • Title страниц
  • Мета-данных
  • H-заголовки
  • Canonical-теги
  • Атрибуты Meta Robots (noindex, nofollow)
  • Внутренние ссылки
  • Микроразметка

Вышеперечисленные SEO-элементы должны быть одинаковыми на Desktop и Mobile-версиях.

 

Проверка сайта на адаптивность

Адаптивный сайт должен отображаться на всех устройства с одним и тем же HTML-кодом, который корректируется (с помощью CSS) в зависимости от размера экрана.

Важно чтобы Googlebot мог получить доступ ко всем основным ресурсам, таким как изображения, файлы JavaScript и CSS.

Чтобы сообщить браузерам, что страница адаптивная, в теге <head> каждой HTML-страницы должен присутствовать тег meta = «viewport».

<meta name = "viewport" content = "width = device-width, initial-scale = 1.0">

Если мета-тег viewport отсутствует, то размеры шрифтов могут отображаться некорректно и Google будет рассматривать эту страницу как не оптимизированную для мобильных устройств.

 

Отдельная проверка мобильных URL

Если мобильный сайт использует отдельные URL (прим.ред: отличимые от Desktop), убедитесь, что:

  1. На каждой Desktop-странице есть тег, указывающий на соответствующий мобильный URL.
  2. Каждая Mobile-страница имеет тег rel = «canonical», указывающий на соответствующий URL на Desktop.
  3. Когда на мобильных устройствах запрашиваются URL от Desktop-версиии, то они перенаправляются на соответствующий мобильный URL.
  4. Редиректы работают на всех мобильных устройствах.
  5. Нет перекрестных ссылок между Deskstop страницами и Mobile-страницами. Ссылки, найденные на мобильной странице, должны ссылаться только на другие мобильные страницы.
  6. Мобильные URL-адреса возвращают ответ 200 серверов.

 

Проверка адаптивности под мобильные устройства:

  1. Окно просмотра (прим.ред: viewport) установлено — корректно.
  2. Размер шрифта не слишком маленький.
  3. Элементы управление (т.е. кнопки, ссылки) располагаются не слишком близко.
  4. Нет никаких навязчивых окон с рекламой, формой подписки, загрузки приложений.
  5. Мобильные страницы не имеют проблем со скростью загрузкой (см. Следующий раздел).

Удобный для мобильных устройств инструмент тестирования Google может помочь диагностировать большинство из перечисленных проблем:

 

Проверка технологии AMP:

Если есть AMP-версия и стандартная версия сайта для Dekstop, убедитесь, что:

  • Каждая страница (Dekstop, mobile) имеет тег, указывающий на соответствующий URL для AMP-версии.
  • Каждая AMP-сраница имеет тег rel=»canonical», указывающий на соответствующую Dekstop-страницу.
  • Любая AMP-страница, у которой нет соответствующего URL в Dekstop-версии — имеет канонический тег со ссылкой на себя.

Проверка корректности реализации технологии AMP (прим.ред: Accelerated mobile pages) с помощью Google AMP Test Tool .

 

Некорректные протоколы в ссылках

Google настаивает на усилении в безопасности сайтов, а Chrome — первый браузер, который помечает страницы HTTP как небезопасные. Теперь важно переезжая на HTTPS следить за тем, чтобы все ссылки, в том числе и на изображения, CSS и JavaScript-файлы — были через HTTPS.

Ошибки возникают когда «HTTPS-страница» — ссылается на другие ресурсы через незащищенные соединения HTTP. Большинство браузеров либо блокируют опасные HTTP-запросы, либо просто отображают предупреждения.

Некоррыктный HTTP-протокол после перехода на HTTPS

 

 

Проверка отслеживания веб-аналитики

Убедитесь, что отслеживание веб-аналитических данных настроено — корректно. При выкатке новой версии сайта — веб-разработчки могут просто забыть загрузить счетчики веб-аналитики, настроенные цели и события. Досадно, если через какое-то время заметите, что нет достаточно данных в веб-аналитике по новой версии сайта.

 

Тестирование редиректов

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

  • Циклические редиректы
  • Редиректы с ответом сервера 4xx или 5xx.
  • Canonical URL, которые возвращают ответ сервера 4xx или 5xx.
  • Циклический Canonical (страница A указывает канонической — страницу B, последняя обратно — страницу A).
  • Несоответствия протокола (пример: HTTP и HTTPS или www и не-www)
  • Несоответствия в использования в URL со  «/» (прим.ред: слешем).
  • Недопустимые символы в URL.

Важно убедиться что URL’ы старого сайта корректно перенаправляют на правильный URL на новом сайте.


 

Этап 4: «Действия в день запуска»

К плану статьи ↑

Когда сайт недоступен …

Как раз в тот момент, когда новая версия сайта заменяет старую — есть вероятность, что сайт будет временно недоступен. Время такого простоя должно быть сведено к минимуму. Пока это происходит — сервер должен отвечать на любой запрос с помощью ответа: 503 (Service Temporarily Unavailable, сервис временно недоступен). Это скажет краулерам поисковых систем, что сайт временно недоступен для технического обслуживания и они вернутся для повторного сканирования — позже.

Если сайт в такой ситуации слишком долго находится без 503 ответа сервера — это негативно повлияет на видимость поиске и восстановление не будет быстрым. Кроме того, стоит выводить информационную страницу (503), уведомляющую пользователей о временных технических работах.

 

Проверка технической части

  1. Файл robots.txt — убедитесь, что поисковые системы могут сканировать сайт
  2. Корректны ли 301 редиректы ключевых страниц?
  3. Корректны ли canonical для ключевых страниц?
  4. Корректны ли статусы ответа сервера для ключевых страниц?
  5. Корректны ли директивы Noindex/nofollow?

 

Действия в Google Search Console:

  1. Протестируйте и загрузите карту Sitemap.xml
  2. Установите основной домен (www или не www)
  3. Установите международный таргетинг (если нужно)
  4. Сконфигурируйте параметры URL для решения любых потенциальных проблем с дублями
  5. Загрузите Disavow-файл (если нужно)

 

Этап 5: «Тестирование после запуска»

К плану статьи ↑

После запуска новой версии сайта необходимо провести дополнительную серию проверок. В основном те, что упомянуты в разделе «Этап 3: Тестирование перед запуском».

Однако на этом этапе появится доступ к гораздо большему количеству данных и инструментов. Например, к показательным данным в Google Search Console.

 

Проверить статистику сканирования и логи сервера

Нужно следить за статистикой сканирования в Google Search Console, чтобы убедиться, что Google корректно сканирует страницы новой версии сайта. Когда краулер Google встречает новые страницы — он имеет тенденцию увеличивать среднее число страниц, которые он сканирует за день. Если нет всплеска по просканированным страницам во время даты запуска — значит что-то мешает краулеру сканировать сайт.

Статистика сканирования в консоли поиска Google

Просмотр файлов логов сервера — самый эффективный способ обнаружить любые проблемы со сканированием сайта. Такие инструменты, как Botify и On Crawl — крутые, поскольку объединяют обходы сайта краулером с логами сервера и могут выделять страницы:

  • которые поисковые системы не сканируют;
  • которые не связаны с внутренними страницами перелинковкой (потерянные страницы);
  • страницы с низкой ценностью (дубли, полудубли);

 

Анализ ошибок сканирования

Важно следить за сообщениями об ошибках сканирования. В идеале ежедневно в течение первых нескольких недель. Ежедневная загрузка этих ошибок, обход указанных URL-адресов и выполнение необходимых действий (прим.ред: выполнение дополнительных 301-редиректов, исправление программных 404 ошибок) помогут ускорить восстановление.

В Google Analytics можено легко узнать какие страницы со 404 статусом наиболее посещаемые. Их стоит исправить в первую очередь.

 

 

Другие полезные отчеты Google Search Console

Cтоит обратить внимание ещё на такие страницы как: блокированные ресурсы, ошибки структурированных данных, ошибки в адаптивности под мобильные устройства и международный таргетинг (прим.ред: для проверки hreflang-ошибок).

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

 

Измерение скорости сайта

После того, как новая версия сайта будет запущена — стоит проверить скорость загрузки страниц сайта (Deskstop и Mobile). Поскольку скорость загрузки сайта является один из сигналов ранжирования. Если время загрузки страниц новой версии окажется дольше — следует предпринять оперативные действия, чтобы не спровоцировать потерю позиций и трафика.

 

Оценка скорости с помощью инструментов Google

Два инструмента, которые могут помочь в этом — Pagespeed Insights и Google Lighthouse.

Инструмент Pagespeed Insights измеряет скорость загрузки страниц как на Mobile, так и Deskstop на основе пользовательских данных, которые Google собирает из Chrome. Он также проверяет реализованы ли на странице общие рекомендации по повышению скорости загрузки и ставить оценку оптимизации.

Google PageSpeed ​​Insights в действии

 

Google Lighthouse более удобен для Mobile-проверки, в том числе и для Progressive Web Apps (PWA). Он предоставляет различные данные для измерения производительности страниц, например:

  • Измерение времени, когда виден основной контент страницы.
  • Момент, когда страница готова для взаимодействия с пользователем.

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

Google’s Lighthouse в действии

 

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

Этот же инструмент также обеспечивает сравнение по индустррии. Можно получить представление о том, как далеко вы находитесь от самых эффективных сайтов в своей отрасли.

 

 

Измерение скорости загрузки по реальным пользователям

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

 

 

Кроме того, если есть доступ к инструменту мониторинга, вроде Pingdom — можно оценить скорость сайта на основе пользователей, посещающих ваш сайт. На карте ниже показано, что пользователи видят разную скорость загрузки сайта, в зависимости от их географического положения.

В примере время загрузки страниц для посетителей из Великобритании, США и Германии — хорошее (прим.ред: зеленый цвет), для пользователей других — похуже (желтый и красный).

 


 

Этап 6: «Определение результатов миграции»

К плану статьи ↑

Когда измерять?

Видимость сайта в поиске в течение первых нескольких недель или даже месяцев может быть довольно изменчивой в зависимости от размера и траста сайта. Для небольших сайтов достаточно 4–6-недель, прежде чем сравнивать видимость новой версии со старой. В случае больших сайтов, вполне возможно, что придется подождать не менее 2–3 месяцев.

Кроме того, если новая версия сайта значительно отличается от предыдущей, то пользователям потребуется некоторое время, чтобы привыкнуть к новому внешнему виду, возможно структуре, пользовательским сценариям. Такие изменения могут поначалу оказать негативное влияние на коэффициент конверсии сайта (прим.ред: постоянным пользователям нужно перестроиться).

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

 

Как измерять?

Есть ещё ряд других вещей, оказывающих влияние на результат. Например, сезонный спад, снижение интереса к бренду, ухудшение скорости загрузки страниц, падение сайта на сервере. Стоит обратить внимание на показатели:

  • Общая видимость сайта в поиске (Dekstop и Mobile)
  • Позиции сайта по ключевым запросам (Dekstop и Mobile)
  • Поведенческие показатели (отказы, среднее время на странице)
  • Количество визитов на ключевые страницы (заходит ли в конкретные категории столько же трафика, как и раньше?)
  • Коэффициент конверсии по типу страниц (прим.ред: не упала ли ощутимо конверсия?)
  • Коэффициент конверсии по устройствам (увеличился/уменьшился ли CR для Dekstop, Mobile с момента запуска?)

 

Дополнение: «Полезные инструменты»

Краулеры

  • Screaming Frog : софт-легенда. Идеально подходит для сканирования небольших и средних сайтов.
  • Sitebulb : сканер с удобным пользовательским интерфейсом, хорошо организованными отчетами и множеством полезных визуализаций.
  • Deep Crawl : облачный сканер с возможностью сканирования тестовых версий сайтов и сравнения результатов сканирования. Хорошо справляется с большими сайтами.
  • Botify : еще один мощный облачный сканер;
  • On-Crawl : краулер и анализатор логов сервера с множеством удобных функций для определения бюджета сканирования, качества контента и проблем с производительностью.

 

Удобные дополнения в Chrome:

  • Web Developer : набор инструментов, включающий функционал вкл/выкл JavaScript, CSS, фото.
  • User agent switcher : переключение между пользовательскими агентами, включая Googlebot и т.д.
  • Ayima Redirect Path : инструмент для проверки редиректов.
  • SEO Meta в 1 клик : инспектор мета-данных.
  • Scraper : простой способ спарсить данные сайта в таблицу.

 

Инструменты мониторинга сайта:

  • Uptime Robot : бесплатный мониторинг работоспособности сайта.
  • Robotto : бесплатный инструмент мониторинга robots.txt.
  • Инструменты Pingdom : отслеживает время работы сайта.
  • SEO Radar : отслеживает все критические элементы SEO и отправляет оповещения при их изменении.

 

Инструменты производительности сайта:

 

Инструменты проверки структурированных данных:

 

Инструменты проверки оптимизации под Mobile:

 

Анализ обратных ссылок:


 

Автор материала: Modestos Siotos — технический директор по SEO в iCrossing UK .

Перевод, адаптация: HarryChy.

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

Кому и чем могу быть полезен?

SEO-консалтинг на этапе продвижения

Если нужен результат, но не готовы ежемесячно оплачивать опытного SEO-специалиста. 1 раз в 3 месяца - аудит, план действий и надзор. Если есть кому внедрять все рекомендации.

SEO-аудит коммерческого сайта

Если у ресурса есть проблемы в поисковом ранжировании: стагнация, ступор. Если нужно разово найти слабые места в SEO-стратегии и получить результат за 1-3 месяца после их исправления.

Конверсионная оптимизация

Если у сайта - трафик от 15 тыс/мес, данные от 6ти мес. Если нужна серьезная CRO-программа с гарантией. Исследования, тесты, ТЗ и выход за 90 дней на новый уровень конверсии трафика.

Конверсионный
аудит

Если у сайта - трафик от 5 тыс/мес, есть данные от 2х месяцев. Если нужен разовый аудит за 7-21 дней со списком рекомендаций по устранению 5-20 узких мест в конверсии.