Как cookie-монстр снизил показатели видимости (visibility) на 22%
В прошлом году команда одной из ведущих немецких компаний в сфере недвижимости приняла решение перейти на новую систему управления контентом (CMS). Целями миграции были, среди прочего, увеличение скорости загрузки страниц и создание современного, перспективного сайта со всеми необходимыми функциями. Одним из основных факторов перехода на новую CMS было и расширение возможностей для продвижения сайта и предоставление редакторам контента возможности более свободно работать над созданием страниц без привлечения разработчиков.
Оценив несколько предлагаемых вариантов, клиент остановился на системе Contentful: современный набор используемых в ней технологий обеспечивает удобство использования системы, как для редакторов, так и для разработчиков. С технической точки зрения Contentful является гибкой CMS, что позволяет выбирать, какую стратегию рендеринга использовать.
В настоящее время мы осуществляем миграцию сайта в несколько этапов (волн), чтобы снизить риск возникновения проблем, которые могут иметь масштабные негативные последствия. Так, например, во время первой волны миграции мы столкнулись с проблемой в получении согласия на обработку Cookie-файлов, что привело к потере видимости (visibility) почти на 22% за пять дней. В этой статье я опишу проблемы, с которыми мы столкнулись, и способы их решения.
Настройка первой тестовой волны
Для первой тестовой волны мы выбрали 10 SEO-страниц с высоким трафиком, но низкими показателями конверсии. Для них мы создали инфраструктуру для отчетности и мониторинга:
- Отслеживание рейтинга наиболее релевантных ключевых слов.
- Панель инструментов SEO (DataStudio, Moz Pro, SEMRush, Search Console, Google Analytics)
- Регулярный переобход страниц.
После этапа всестороннего планирования и тестирования мы перенесли первые 10 SEO-страниц на новую CMS. Хотя на этапе тестирования возникло несколько проблем (увеличение времени загрузки, увеличение объектной модели HTML-документа и т. д.), мы решили начать работу, т.к. не увидели серьёзных препятствий.
Первая оценка эффективности работы
Воодушевившись результатами первого этапа работ, на следующий день мы проверили производительность мигрированных страниц.
То, что мы увидели, нас совсем не обрадовало.
За ночь видимость отслеживаемых ключевых слов для мигрированных страниц снизилась с 62,35% до 53,59% — мы потеряли 8,76% видимости за один день!
Для выяснения причин такого резкого падения рейтинга мы провели еще одно доскональное тестирование. Помимо прочего, мы проверили охват/индексацию, наличие метатегов, структурированные данные, внутренние ссылки, скорость загрузки страницы и оптимизацию для мобильных устройств.
Повторная оценка эффективности работы
Дата кэширования всех статей была свежей (уже после миграции), контент был полностью проиндексирован и распознан Google. Кроме того, мы смогли исключить несколько факторов риска миграции (изменение URL-адресов, контента, метатегов, разметки и т. д.), поскольку никаких изменений не произошло.
Видимость отслеживаемых ключевых слов снова упала — до 40,60% в течение следующих нескольких дней, в результате чего общее падение составило почти 22% за пять дней. Это было чётко видно в сравнении с конкуренцией отслеживаемых ключевых слов, показатели видимости выглядели аналогично.
Поскольку другие факторы риска миграции, а также влияние обновлений Google были исключены в качестве источников ошибок, причиной явно была техническая проблема. Потенциальными причинами могут быть большое количество JavaScript, низкие показатели Core Web Vitals или более крупная и сложная объектная модель документа (DOM).
Для справки: модель DOM представляет страницу в виде объектов и узлов для того, чтобы языки программирования, такие как JavaScript, могли взаимодействовать со страницей и изменять её стиль, структуру и содержимое.
Следуйте за хлебными крошками, или исследование возникшей ситуации
Нам нужно было как можно быстрее выявить проблему, устранить её, минимизировать дополнительные негативные последствия и потери трафика. У нас, наконец, появилась первая идея того, какая техническая проблема могла стать причиной. Это произошло, когда один из наших инструментов показал, что количество страниц с большим количеством внешних ссылок, а также количество страниц с максимальным размером контента увеличилось. Важно, чтобы контент на страницах не превышал максимально допустимый размер, поскольку страницы с очень большим объемом основного контента могут быть проиндексированы не полностью. Что касается большого количества внешних ссылок, важно, чтобы все внешние ссылки были надежными и релевантными для пользователей. Нам показалось подозрительным, что количество внешних ссылок выросло таким образом:
Значения обеих метрик были непропорционально высокими по сравнению с количеством мигрированных страниц. Но почему?
Проверив, какие внешние ссылки были добавлены на мигрированные страницы, мы увидели, что Google считывает и индексирует форму согласия на использование файлов Cookie для всех этих страниц. Мы выполнили поиск по сайту, проверив наличие согласия на использование файлов Cookie, и убедились, что наша теория подтвердилась.
Это привело к возникновению следующих проблем:
- Из-за индексации формы согласия на использование файлов Cookie для каждой страницы было создано множество дублированного контента.
- Размер контента мигрированных страниц резко увеличился. Это стало проблемой, поскольку страницы с большим объемом основного контента могут быть проиндексированы не полностью.
- Резко увеличилось количество внешних исходящих ссылок.
- В сниппетах для поисковой выдачи неожиданно появилась дата. Обычно, это свойственно блогам или новостным статьям, в то время как большинство статей на сайте клиента являются вечнозеленым контентом. Кроме того, из-за появления даты мета-описание было обрезано.
Но почему так происходило? CMP-провайдер Cookiebot утверждает, что сканеры поисковых систем получают доступ к сайтам, автоматически соглашаясь с использованием файлов Cookie. Следовательно, они получают доступ ко всему контенту, при этом формы согласия на использование файлов Cookie не индексируются сканером.
Так почему же этого не произошло с мигрированными страницами? Мы просканировали страницы с помощью различных пользовательских программных агентов, но так и не смогли найти следов Cookiebot в исходном коде.
Изучение моделей DOM Google и поиск решения
Мигрированные страницы отображаются с использованием динамических данных, поступающих из CMS Contentful и плагинов. Плагины содержат только код JavaScript, а иногда получают его от партнера. Одним из таких плагинов был партнер-менеджер файлов Cookie, который извлекает HTML-код согласия на использование этих файлов вне нашего кода. Вот почему мы не нашли следов HTML-кода согласия на использование файлов Cookie в исходниках. Мы видели следы более крупной модели DOM, но проследили её только до фреймворка Nuxt, установленного по умолчанию.
Чтобы убедиться, что Google считывает копию согласия на использование файлов Cookie, мы использовали инструмент проверки URL в Google Search Console. Мы сравнили DOM мигрированной страницы с DOM страницы, не попавшей в первоначальную миграцию. Наконец, в DOM мигрированной страницы мы нашли содержимое согласия на использование файлов Cookie:
Еще кое-что, что привлекло наше внимание, это файлы JavaScript, загруженные на страницы, не попавшие в миграцию. На нашем сайте есть два сценария для получения согласия на использование файлов Сookie: один для показа баннера и получения согласия (uc) и другой, который импортирует содержимое баннера (cd).
- Единственным скриптом, загруженным на старые страницы, был uc.js, который отвечает за баннер согласия на использование файлов Cookie. Это единственный сценарий, который нам нужен на каждой странице для обработки согласия пользователя. Он отображает баннер согласия на использование файлов Cookie без индексации содержимого и сохраняет решение пользователя (согласен / не согласен с использованием файлов Cookie).
- Для мигрированных страниц, помимо uc.js, также загружался файл cd.js. Его стоит использовать, если вы хотите показать пользователю больше информации о файлах Cookie и проиндексировать данные этих файлов. Мы думали, что оба файла зависят друг от друга, и ошиблись: uc.js может работать отдельно. Именно наличие на странице файла cd.js стало причиной того, что содержимое баннера Cookie было обработано и проиндексировано поисковой системой.
Потребовалось некоторое время, чтобы найти его, потому что мы думали, что второй файл был просто дополнением для первого. Мы решили, что простое удаление загруженного файла cd.js будет отличным решением.
Оценка эффективности после решения проблемы
В тот день, когда мы удалили файл, видимость ключевых слов составляла 41,70 %, что все еще было на 21 % ниже показателей до миграции.
Однако на следующий день после удаления файла видимость увеличилась до 50,77%, а еще через день почти вернулась к норме в 60,11%. Показатели предполагаемого трафика были аналогичными.
В заключение
Я знаю, что многие SEO-специалисты сталкивались с подобными незначительными проблемами. Казалось бы, мелочь, однако она привела к значительному падению видимости и трафика при миграции. Вот почему я предлагаю выполнять миграцию этапами и выделять достаточное количество времени для изучения технических ошибок до и после неё. Кроме того, крайне важно внимательно следить за показателями сайта в течение нескольких недель после миграции. Это мои ключевые выводы по этому проекту. В начале мая 2022 года мы завершили вторую волну миграции, и я могу уверенно заявить, что серьезных ошибок пока не выявлено. Мы надеемся полностью завершить миграцию сайта к концу июня 2022 года.