Прокачка сайта за 3 недели: подготовились к Core Web Vitals, увеличили трафик с Google и автоматизировали рутины

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

Недавно к нам на поисковое продвижение зашел новый проект — организация, оказывающая услуги по вывозу строительного мусора «Увозов» — с проблемой: трафик с органической выдачи Google сильно провисает по сравнению с Яндексом.

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

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

Так получилось и на этом проекте: несмотря на то, что сайт новый и требует доработок, он все равно получал высокие позиции в Яндексе, а вот Google не давал ему ни единого шанса — либо задвигал страницы на 10–20 страницы поиска, либо вообще не показывал их. Например, по запросу «вывоз мусора» в Яндексе сайт был в пятерке лидеров, а в Google по этому же запросу его в выдаче не было.

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

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

На этом проекте в красной зоне оказались 4 пункта проверки из 6. Особенно нас волновали значения Largest Contentful Paint (скорость загрузки основного контента) и Time to Interactive (время загрузки для взаимодействия). Это 2 из 3 показателей новых факторов ранжирования Google — Core Web Vitals, которым сайт нашего клиента не соответствовал. С запуском Core Web Vitals он потерял бы еще больше позиций в Google, а со временем — и в Яндексе.

Работу по увеличению скорости сайта мы провели в два этапа:

1. Поменяли конструктор верстки.
2. Переехали на новый хостинг.

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

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

Elementor мы заменили на блочный редактор Gutenberg — инструмент самого WordPress. Так как возможности Gutenberg пока ограничены — например, сложно работать с отступами, рамками, радиусами — мы расширили его функциональность двумя плагинами: GenerateBlocks и Gutenberg Blocks — Ultimate Addons for Gutenberg.

На выходе мы получили красивые шустрые страницы и уже на этом этапе существенно улучшили показатели скорости загрузки.

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

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

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

Это решение помогло нам добиться максимально хороших показателей скорости загрузки: Largest Contentful Paint снизили с 3,7 до 0,9 секунды, а Time to Interactive — с 5,7 до 1,4 секунды.

Сайт нашего клиента фактически имеет 4 версии:

1. Основную, доступную по домену.
2. Адаптивную под мобильные устройства.
3. Ускоренную версию под мобильную выдачу Яндекса — турбо-страницы.
4. Ускоренную версию под мобильную выдачу Google — AMP-страницы.

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

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

Мы заменили AMP for WP на AMP — проект с открытым исходным кодом, в развитии которого принимает участие сам Google.

Использовать его ранее мы не могли. Дело в том, что он ограничивает для каждой страницы бюджет на использование CSS — не более 75 килобайт. Если страница укладывается в выделенный бюджет, она рендерится с сохранением основных стилей, но стоит ей выйти за ограничение — она «ломается» и ей становится невозможно пользоваться. Сделать отдельный шаблон в этом плагине нельзя.

Страницы, созданные в Elementor, в этот лимит не укладывались — в среднем они весили от 100 килобайт. Поэтому приходилось работать с AMP for WP, где есть возможность задать уникальную вёрстку для каждой страницы.

С Gutenberg страницы весили почти в два раза меньше — самая «нагруженная» различными элементами страница расходовала не более 70 килобайт.

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

В ходе разработки нового сайта мы наткнулись на плагин PWA for WP, который в несколько кликов превращает сайт в прогрессивное веб-приложение (PWA).

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

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

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

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