Технический базовый аудит: дополнительное
Есть такие проверки в рамках базового технического аудита, которые, с одной стороны, исключить из базового «рука не поднимается», но они не приносят какого-то прорывного результата, с другой стороны. Такие проверки мы отнесем к дополнительным. Кроме прочего, к ним относятся:
- Несколько h1 на одной странице
- Отсутствует метаописание
- Не 301-е редиректы
- iframe
- flash
- Мобильная адаптация
- Редирект с www и https
- Отсутствие ssl-сертификата
Известно, что на каждой веб-странице должен быть тег заголовка h1 и должен быть только один. Соответственно, если тег h1 отсутствует, это критичная проблема, а если их на странице несколько, то проблема тоже есть, но в этом случае её критичность ниже. Существуют разные точки зрения на множественный тег заголовка на странице. Одни считают, что стандарт html5 это в принципе допускает. Другие считают, что это недопустимо, и приводит к существенному снижению ранжирования. Третьи, что это не так принципиально, так как поисковики примут во внимание только первый тег.
Моя позиция по данному вопросу в некотором смысле промежуточная: скорее всего, поисковики будут ориентироваться на какой-то один из теговой, вероятнее всего, первый, но наличие множественности тега все равно заметят, и это чуть-чуть ухудшит ранжирование. То есть, подправить это, безусловно стоит, но если было замечено, что такая ошибка есть, и она на странице довольно давно, то это не катастрофа.
Отсутствие метаописания на странице (мета-тега description) находится примерно в той же «весовой категории». Исправить это, конечно, надо, особенно потому, что метаописание очень часто (особенно Гуглом) берется за основу формирования сниппета и, следовательно, влияет на конверсию страницы. Но после исправления не стоит ждать, что появившееся метаописание резко увеличит результаты по трафику и позициям.
Рассмотрим другую часто встречающуюся ошибку, когда на сайте вместо 301-х редиректов используются какие-то другие редиректы (302, 303 и т.д.) Идея в том, что 301-й редирект специально предназначен для передачи «веса» страницы-донора странице-акцептору. При всех же остальных видах редиректов такой передачи не происходит, поэтому снижается ссылочная связанность сайта, и это может сказаться значимо на ранжировании страниц, на которых ведет редирект. Поэтому это, конечно, нужно подправить.
Следующие два пункта, которые нужно рассмотреть, это наличие тега iframe и использование на сайте технологии flash в отношении значимого контента. В некоторых случаях использование iframe оправдано и даже необходимо, но иногда его используют избыточно, а надо знать, что контент внутри этого тега не индексируется. Более того, использование слишком сложных конструкций внутри тега iframe (например, подгрузка скриптом другого кода, содержащего iframe или еще код, подгружающий третий) может привести к бану сайта поисковиками, так как они могут счесть такие ничем не оправданно сложные схемы загрузки частей веб-страницы попыткой их обмануть и представить пользователю и роботу поисковика в итоге разный контент. Содержимое flash-а также не индексируется, так что хоть сколько-нибудь ценный контент из него стоит перенести в html.
Роль мобильной адаптации сайта, на мой взгляд, несколько преувеличена. Да, конверсию сайта с мобильного она увеличивает, а вот насколько она влияет на ранжирование главным образом десктопной версии – это большой вопрос. На десктопную, вероятнее всего, мало влияет, на мобильную влияет, но тоже не слишком радикально. Поэтому здесь разумным представляется предложить отталкиваться от конверсии: если у вас контентный сайт, и он конвертирует посетителей даже без мобильной адаптации, скорее всего, добавление адаптивной верстки изменит ранжирование не значительно. И наоборот, если у вас интернет-магазин, и пользователи, заходящие на сайт с мобильного сразу убегают с него, так как ничего разглядеть невозможно, то адаптивная верстка может спасти ситуацию как в отношении конверсии, так и заметно улучшить ранжирование.
У сайта должно быть одно главное зеркало, и со всех остальных зеркал должен идти 301-й редирект на это главное зеркало. Но это правило частенько не соблюдается, чаще всего это касается префикса www и указания на защищенный протокол https. В итоге сайт часто имеет 4 равноправных, с точки зрения поисковика, версии – с www и без www, c https и без https. И сила всего сайта «распыляется» между этими четырьмя зеркалами. Для того, чтобы этого «распыления» не происходило, нужно из четырех зеркал выделить одно главное (лучше всего взять вариант с https и без www) и со всех оставшихся трех вариантов организовать 301-й редирект на это главное зеркало.
Кроме того, отдельный повод задуматься – это отсутствие вообще у сайта доступности по защищенному протоколу. Здесь тоже все не так однозначно. Если у сайта нет ssl-сертификата, и, следовательно, он не доступен по протоколу https, то само по себе это еще ни о чём не говорит. Есть, конечно, информация о том, что «незащищенным» сайтам поисковики меньше доверяют и поэтому они ранжируются хуже, но моим наблюдениям это зависит от типа сайта. Есть много кейсов, где показано, что переход на https не привел ни к какому улучшению трафика, а в Яндексе это наоборот приводит к временному снижению трафика (пока автоматическая склейка зеркал не завершится). Поэтому защищенный протокол сам по себе не панацея. Но его обязательно стоит использовать, если сайт редактирует большая и территориально распределенная команда, а уж особенно, если у вас UGC-сайт (User-generated content). Так как если хотя один из пользователей захочет зайти на сайт под своим паролем из кафешки, для незащищенного сайта пароль может быть перехвачен и, соответственно, сайт будет скомпрометирован. И наоборот, если контент сайта редактирует один человек, и он же владелец, и он не заходит под своим аккаунтом через публичный вай-фай, то он может быть пока спокоен.