Пример из практики: как печенье-монстр съело 22% нашей видимости

В прошлом году команда Homeday — одной из ведущих компаний в сфере недвижимости в Германии — приняла решение перейти на новую систему управления контентом (CMS). Целью миграции было, среди прочего, увеличение скорости страницы и создание современного, ориентированного на будущее веб-сайта со всеми необходимыми функциями. Одним из основных мотивов миграции было предоставление редакторам контента возможности более свободно работать над созданием страниц без помощи разработчиков.

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

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

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

Для первой тестовой волны мы выбрали 10 SEO-страниц с высоким трафиком, но низкой конверсией. Мы создали инфраструктуру для отчетности и мониторинга этих 10 страниц:

• Отслеживание рейтинга наиболее релевантных ключевых слов
• Панель инструментов SEO (DataStudio, Moz Pro, SEMRush, Search Console, Google Analytics)
• Регулярные сканирования

После этапа всестороннего планирования и тестирования мы перенесли первые 10 SEO-страниц на новую CMS в декабре 2021 года. Хотя на этапе тестирования возникло несколько проблем (увеличение времени загрузки, увеличение объектной модели HTML-документа и т. д.), мы решили начать работу. так как мы не видели большого блокировщика и хотели перенести первую тестовую волну до Рождества.

Первый обзор производительности

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

То, что мы увидели дальше, нас совсем не порадовало.

За ночь видимость отслеживаемых ключевых слов для перенесенных страниц снизилась с 62,35% до 53,59% — мы потеряли 8,76% видимости за один день!

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

Второй обзор производительности

У всех статей была дата кеша после переноса, а контент был полностью проиндексирован и прочитан Google. Кроме того, мы могли исключить несколько факторов риска миграции (изменение URL-адресов, контента, метатегов, макета и т. д.) как источники ошибок, поскольку никаких изменений не произошло.

Видимость наших отслеживаемых ключевых слов снова упала до 40,60% в течение следующих нескольких дней, в результате чего общее падение составило почти 22% за пять дней. Это также было ясно показано в сравнении с конкуренцией отслеживаемых ключевых слов (здесь «оценочный трафик»), но видимость выглядела аналогично.

Поскольку другие факторы риска миграции, а также обновления Google были исключены как источники ошибок, это определенно должна была быть техническая проблема. Потенциальными причинами могут быть слишком много JavaScript, низкие баллы Core Web Vitals или более крупная и сложная объектная модель документа (DOM). DOM представляет страницу в виде объектов и узлов, чтобы языки программирования, такие как JavaScript, могли взаимодействовать со страницей и изменять, например, стиль, структуру и содержимое.

По крошкам печенья

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

Оба показателя были непропорционально высокими по сравнению с количеством страниц, которые мы перенесли. Но почему?

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

Это привело к нескольким проблемам:

1. Для каждой страницы было создано множество дублированного контента из-за индексации формы согласия на использование файлов cookie.
2. Размер содержимого перенесенных страниц резко увеличился. Это проблема, поскольку страницы с очень большим объемом основного контента могут быть проиндексированы не полностью.
3. Резко увеличилось количество внешних исходящих ссылок.
4. Наши фрагменты внезапно показали дату в поисковой выдаче. Это предполагает блог или новостную статью, в то время как большинство статей на Homeday — это вечнозеленый контент. Кроме того, из-за появления даты мета-описание было обрезано.

Но почему это происходило? По словам нашего поставщика услуг, Cookiebot, сканеры поисковых систем получают доступ к веб-сайтам, имитируя полное согласие. Следовательно, они получают доступ ко всему контенту и копии из баннеров согласия на использование файлов cookie не индексируются сканером.

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

Изучение DOM Google и поиск решения

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

Чтобы убедиться, что Google считывает копию с баннера согласия на использование файлов cookie, мы использовали инструмент проверки URL в Google Search Console. Мы сравнили DOM перенесенной страницы с DOM неперенесенной страницы. В DOM перенесенной страницы мы, наконец, нашли содержимое согласия на использование файлов cookie:

Еще кое-что, что привлекло наше внимание, это файлы JavaScript, загруженные на наши старые страницы, по сравнению с файлами, загруженными на наших перенесенных страницах. На нашем веб-сайте есть два скрипта для баннера с согласием на использование файлов cookie, предоставленные третьей стороной: один для показа баннера и получения согласия (uc) и другой, который импортирует содержимое баннера (cd).

• Единственный скрипт, загруженный на наши старые страницы, был uc.jsкоторый отвечает за Баннер согласия на использование файлов cookie. Это единственный сценарий, который нам нужен на каждой странице для обработки согласия пользователя. Он отображает баннер согласия на использование файлов cookie без индексации содержимого и сохраняет решение пользователя (если он согласен или не согласен с использованием файлов cookie).
• Для перенесенных страниц, помимо uc.js, также был cd.js загрузка файлов. Если у нас есть страница, на которой мы хотим показать пользователю больше информации о наших файлах cookie и проиндексировать данные файлов cookie, тогда мы должны использовать файл cd.js. Мы думали, что оба файла зависят друг от друга, что неверно. uc.js может работать отдельно. Файл cd.js был причиной того, что содержимое баннера cookie было отрисовано и проиндексировано.

Потребовалось некоторое время, чтобы найти его, потому что мы думали, что второй файл был просто предварительным требованием для первого. Мы решили, что решением будет простое удаление загруженного файла cd.js.

Обзор производительности после внедрения решения

В тот день, когда мы удалили файл, видимость ключевых слов составляла 41,70 %, что все еще было на 21 % ниже, чем до миграции.

Однако на следующий день после удаления файла наша видимость увеличилась до 50,77%, а на следующий день почти вернулась к норме в 60,11%. Расчетный трафик вел себя аналогично. Какое облегчение!

Вывод

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

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