Как и зачем проводить сравнительный аудит десктопной и мобильной версий сайта

Автор – Эверетт Сайзмор (Everett Sizemore), директор маркетингового агентства Inflow и эксперт Moz. 

Google всё ещё ранжирует страницы на основании контента, кода и ссылок, которые он находит с помощью десктопного краулера. Однако сейчас инженеры поиска работают над переходом к мобильным краулерам и так называемому mobile-first индексу. Запуск этого изменения, вероятно, будет производиться постепенно. Но мы прозвали тот день, когда оно вступит в силу по всему миру, «часом Ч» (поскольку термин «мобайлгеддон» уже занят).

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

Что такое сравнительный аудит?

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

Когда такой аудит необходим?

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

Этот тип анализа также полезен для мобильных сайтов на отдельном URL, но это тема отдельной статьи.

О чём он расскажет? Как он поможет?

• Является ли мобильная версия сайта «оптимизированной» и доступной для сканирования?
• Все ли заголовки в ответах сервера и теги настроены правильно и аналогичным образом в обеих версиях?
• Отсутствует ли в мобильной версии важный текстовый контент? Скрыт ли он?

Почему сравнительные аудиты могут уберечь вас от проблем

Наверное, последняя вещь, которую вы хотите увидеть в день Ч – это крупный спад трафика.

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

Аудит также поможет вам улучшить ранжирование своего ресурса прямо сейчас.

Я знаю отличную SEO-команду, занимающуюся поисковой оптимизацией крупного бренда, которая в течение нескольких месяцев не знала о том факте, что на всём мобильном сайте (на миллионах страниц) теги Title содержали одну и ту же фразу: «Название компании – мобильный сайт».

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

• У одного типа страниц на мобильном сайте имелась ошибка на уровне шаблона, которая разбивала теги rel=canonical, но только на мобильных устройствах. Причём это происходило таким образом, что Google предоставлялись противоречивые инструкции в зависимости от того, обрабатывалась страница как мобильная или десктопная. Аналогичная ситуация наблюдалась со всеми тегами на странице, включая директивы в метатеге robots. Это также могло происходить с HTTP-заголовками в ответах сервера.
• В футере мобильного сайта было практически вдвое меньше навигационных ссылок. Как это повлияет на передачу PageRank ключевым страницам при mobile-first индексации?
• На страницах товаров на мобильном сайте было больше похожих товаров. Опять же, как это повлияет на поток PageRank и глубину сканирования после запуска mobile-first индекса?
• Важный контент был скрыт в мобильной версии. По словам представителей Google, это допустимо, если пользователь может развернуть блок или открыть вкладку, чтобы прочитать скрытое содержимое. Однако в данном случае, такой возможности не было. Контент находился в HTML-коде, но был скрыт для мобильных пользователей, и не было никакого способа сделать его видимым.

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

Это звучит сложно, но на самом деле сводится к нескольким простым шагам:

• Просканируйте сайт как десктопный пользователь;
• Просканируйте сайт как мобильный пользователь;
• Объедините полученные данные;
• Проверьте их на наличие несоответствий и ошибок.

Screaming Frog даёт возможность просканировать сайт как user-agent Googlebot Mobile. Вам может понадобиться рендеринг JavaScript.

Вы также можете провести две проверки (мобильную и десктопную) с помощью DeepCrawl. Однако отчёты типа «Mobile Word Count Mismatch» пока не работают на динамических сайтах, даже после двух обходов.

Чтобы получить эти данные, нужно сделать так, как и в Screaming Frog: провести два сканирования, экспортировать два отчёта и использовать функцию ВПР (VLOOKUP) в Excel для сравнения столбцов с URL-адресом, являющимся уникальным идентификатором.

Ниже – упрощённый пример с использованием экспорта из DeepCrawl:

Как видно на скриншоте выше, страницы категорий, такие как /category/cro/, между разными типами устройств сильно отличаются – не только тем, как они появляются, но также и тем, какой код и контент доставляются и отображаются в качестве исходного кода. Самое большое отличие заключается в том, что пост-тизеры на мобильных устройствах исчезают, что объясняет несоответствие в количестве слов.

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

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

DeepCrawl

Мы работаем над отчётами Changed Metrics (изменения в метриках), который будет автоматически показывать страницы, у которых заголовки и описания менялись между сканированиями. С помощью этих данных можно будет определять различия на динамических сайтах при изменении агента пользователя. Но на данный момент это можно сделать только вручную путём выгрузки и объединения результатов двух сканирований, а затем определения различий.

Moz Pro

Питер Мейерс (Dr. Pete) говорит, что в настоящее время они работают над сравнением десктопных и мобильных позиций в ранжировании для выявления предупреждающих знаков, чтобы Moz мог оповещать своих клиентов о возможных проблемах. Это будет очень полезная функция, дополняющая анализ on-page различий.

Sitebulb

При выборе режима «mobile-friendly» Sitebulb сканирует сначала сайт целиком, а затем – выборку из (до) 100 страниц, после чего проводит их повторное сканирование с помощью краулера, обрабатывающего JavaScript. Это то, что создаёт их «mobile-friendly» отчёт.

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

Screaming Frog

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

Тем не менее, в описанном ниже процессе мы используем Screaming Frog – просто потому, что мы лучше с ним знакомы.

Настройка проверщика различий

Один из моих SEO-героев, Дэвид Соттимано, кастомизировал  Javascript Diff Algorithm, чтобы частично автоматизировать проведение сравнительных аудитов.

Вы можете сделать копию по ссылке. Следуйте инструкциям на вкладке Readme. Примечание. Это экспериментальный инструмент, работа над которым продолжается.

Использование хэш-значений для быстрого поиска различий

Как говорится в руководстве по Screaming Frog от Lunametrics, «хэш-значение – это количество URL-адресов, которые возможно содержат дублированный контент. Этот счетчик фильтрует все повторяющиеся страницы, найденные с помощью хэш-значения. Если два хэш-значения совпадают, значит, страницы имеют аналогичный контент».

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

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

Сравнительный аудит с использованием Screaming Frog и Excel

Проведите два сканирования

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

1. Сканирование №1. Десктопные настройки

Configurations ---> Spider

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

Configurations ---> HTTP Header ---> User-Agent

2. Запустите первое сканирование. 3. Сохраните результаты и выгрузите данные.

После окончания сканирования сохраните данные как desktop-crawl.seospider, затем нажмите кнопку «Export» (в левом верхнем углу) и выберите отчёт «Export All URLs».

4. Обновите настройки user-agent для второго сканирования.

Нажмите кнопку «Clear» в Screaming Frog и измените конфигурацию User-Agent на следующую:

5. Запустите второе сканирование. 6. Сохраните результаты и выгрузите данные.

После окончания сканирования сохраните данные как mobile-crawl.seospider, затем нажмите кнопку «Export» (в левом верхнем углу) и выберите отчёт «Export All URLs». Сохраните отчёт как mobile-internal_all.csv.

Перенесите экспортированные данные в Excel

• Импортируйте каждый CSV-файл на отдельный лист.
• Создайте ещё один лист и перенесите URL-ы из столбца «Address» из каждого листа. Удалите дубликаты.
• Используйте функцию ВПР (VLOOKUPS) или другие методы, чтобы подтянуть соответствующие данные из каждого листа.

В итоге вы получите что-то вроде этого:

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

Ошибки и различия, на которые нужно обратить внимание

• Совпадает ли количество навигационных ссылок на мобильном и десктопном сайте?

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

• Разные HTTP-заголовки в ответах сервера в зависимости от агента пользователя

Это одна из тех вещей, которые могут вызвать проблемы с кэшированием. Однако Google говорит использовать этот подход в тех случаях, когда в мобильной и десктопной версиях сайта с одним и тем же URL контент значительно разнится. Мой совет: избегайте использования Vary User-Agent в тех случаях, когда различия между версиями являются минимальными (например, упрощённая навигация, оптимизированные изображения, обтекаемый макет и т.п.). Используйте этот приём только в том случае, если отсутствуют целые параграфы контента и другие важные элементы.

• Различия во внутренних ссылках

Если в футере десктопного сайта содержится 20 ссылок на товары-бестселлеры и категории с использованием оптимизированного анкорного текста, а на мобильном сайте – всего лишь 5 (например, «Контакты», «О нас» и т.п.), то было бы хорошо задокументировать это, чтобы вы знали, что нужно протестировать, если после перехода на mobile-first индексацию позиции сайта просядут.

• Метатеги и директивы

Совпадают ли в обоих версиях сайта теги Title, метаописания, директивы в метатеге robots, атрибуты rel=canonical, rel=next/prev? Выявлений расхождений сейчас поможет предотвратить катастрофу в будущем.

• Длина контента

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

Представьте, что Google перешёл на mobile-first индексацию, ваши трафик сократился, и вы пытаетесь выяснить, в чём причина. Коррелирует ли меньшее количество контента в мобильной версии с более низкими позициями в ранжировании? Возможно да, а, возможно, и нет. Но я бы проверил этот пункт.

• Скорость

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

• Рендеринг

Иногда Javascript и другие файлы, необходимые для мобильного рендера, могут отличаться от тех, которые нужны для десктопного рендера. Таким образом, может возникнуть ситуация, когда один набор ресурсов может быть заблокирован в файле robots.txt, а другой – нет. Убедитесь, что обе версии сайта полностью обрабатываются без заблокированных ресурсов.

Что нужно сделать, чтобы подготовиться к mobile-first миру:

• Выясните, есть ли различия в основном контенте, тегах и ссылках между мобильной и десктопной версиями сайта.
• Если они есть, разберитесь, в чём именно они состоят и потратьте время на то, чтобы подумать, как это может отразиться на ранжировании, если Google начнёт анализировать только мобильную версию.
• Уберите те различия, которые должны быть устранены незамедлительно. Например, отсутствующие или неправильно настроенные атрибуты rel=canonical, метатеги robots и теги Title.
• Отметьте те пункты, которые нужно будет протестировать после запуска mobile-first индекса. Если позиции сайта просядут, вы будете к этому готовы.

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