Техническая оптимизация в SEO

Почему ее избегают SEO-агентства, штатные специалисты и программисты.

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

Просто взгляд человека 8 лет проработавшего в отрасли.

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

В отделе было 2 активно программирующих специалиста. Позже появились 2 штатных SEO программиста. И параллельно еще 2 человека ( в том числе и я начали) программировать.

Также последние 4 года я консультирую кампании по SEO в частном порядке. И это очень помогает не отставать от трендов и тематик. Набирать фактический материал, сравнивать тематики между собой.

Среди них крупные новостные проекты, мелкие и крупные e-comm проекты.

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

Крупные телеком проекты, сервисы доставки еды, доставка продуктов.

Большая часть проектов связана с редизайном сайта.

Техническая оптимизация в SEO

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

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

Почему эта часть часто игнорируется или упускается из виду агентствами или специалистами.

Почему программисты не в восторге от советов seo-специалиста по части оптимизации верстки.

На какие моменты обращать внимание.

Статья будет полезна как заказчикам seo услуг, нанимателям seo-специалистов, программистам, так и самим seo-специалистам.

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

От это выиграет каждый из участников процесса. Заказчик получит более качественную seo услугу. Программисту будет проще понять сеошника, а сеошнику проще объяснить свои пожелания.

В конце статьи будут полезные ссылки. Также будут иллюстрации технического состояния нескольких реальных сайтов.

Завязка

Часто работы по SEO разделяют на:

  • семантическую составляющую
  • ссылочную
  • техническую

До 2014 в золотой век seo-оптимизации - основная часть работы большинства агентств и специалистов заключалась в закупке ссылок.

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

Также агентства и специалисты любят разного рода авто аудиты - где вылезает большой перечень ошибок на сайте типа - нет title’ов и description’ов у части страниц, есть дубли и т.п.

Трудозатраты на такие аудиты минимальны, работа для заказчика обозначена на несколько недель вперед. И она кстати дает результат.

Что еще любят делать seo специалисты и агентства - правильно! Собирать семантику.

Две недели сидел над семантикой, чистил ее, кластеризовал. Взял за это пол зарплаты. А что на выходе? Файлы, которые не открываются из-за размера. И в лучшем случае рекомендация - создавайте посадочные страницы под эти фразы.

Техническая оптимизация в SEO

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

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

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

Почему техническая оптимизация?

Первое - про семантику написано много. Про ссылки также много.

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

Третье - хочу лишний раз привлечь внимание seo-специалистов к необходимости изучать техническую часть. Осваивать смежные дисциплины, обработку данных, веб-программирование, сети. Это все повысит уровень отрасли - качество услуг и качество коммуникации с заказчиком и разработкой.

И кстати даст вам конкурентное преимущество перед менее технически подкованными специалистами.

Что входит в техническую составляющую

Наличие seo базы

Meta информация, robots.txt, sitemap.xml, правильные редиректы, https протокол с нормальным сертификатом и много другой мелочи. Это затрагивать не будем - про это много пишут. И это делается легко с точки зрения разработки. Обычно легко.

Доступность контента для поисковых роботов.

Объем контента относительно кода страницы. Его положение на странице. Возможность в принципе его увидеть/получить при выключенном js.

Вы будете смеяться, а владельцы таких сайтов рыдать - но есть сайты, в которых программисты сделали оптимизацию, перевели на новый фреймворк, например, сайт стал быстрее. Но для поисковика он стал 1 страницей, например как SPA (single page application).

Или при выключенном js на сайте вместо контента висит замечательная надпись - сайт без js не работает.

Проблема данного сайта давно известна, но видимо не в приоритете.
Проблема данного сайта давно известна, но видимо не в приоритете.

Или сайт при выключенном js не отдает контент. Программисты будут уверять вас, что гугл парсит js, все будет здорово.

Но во-первых, у доброй половины сайтов Яндекс является основным источником seo трафика в силу тематики проекта или региональной принадлежности (кто не в курсе Гугл очень слабо отличает Варшаву от Екатеринбурга, для него это все Восточная Европа).

Во-вторых, у Гугла несколько ботов, которые ходят по сайту как хотят. Часть страниц спарсит бот, умеющий парсить js, а часть страниц обычный бот. И половина ваших страниц в индекс не войдет.

И кроме того - бот умеет парсить js, но нет ни фразы о том, что этот контент участвует в ранжировании.

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

Хотя сайт летал, свистел и пердел в соответствии со всеми новомодными свистелками.

Есть хороший вариант перевода на js, когда значимая для поисковиков часть контента рендерится на сервере или когда создается HTML копия сайта для поисковиков. И технологии развиваются. Надеюсь мы увидим в ближайшем будущем алгоритмы, которые реально индексируют и ранжируют js сайты. Но сейчас это риск.

Скорость работы сайта.

Можно посмотреть факторы скорости, которые мониторит Яндекс.
Можно посмотреть факторы скорости, которые мониторит Яндекс.
Это лежит в Метрике, в Стандартных отчетах - Мониторинг
Это лежит в Метрике, в Стандартных отчетах - Мониторинг

Здесь куча показателей - но в целом они зависят от следующих вещей:

  • Непосредственно бизнес процесс.
    Если сайт предполагает кучу действий типа определения региона, определения группы пользователей по кукам, подгрузку большой базы в динамике - все это сделает загрузку более долгой. Чем у сайта - где в статике отдается 300 000 страниц с текстовым контентом.

Это часто не зависит ни от программистов, ни от seo агентств, ни от текущей команды маркетинга и продукта. Часто команде достается готовое наследие, с которым нужно работать. И часто это то, что нельзя изменить. И иногда бизнес процесс становится камнем преткновения для seo (ха-ха) и вообще для маркетинга.

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

  • Какую технологию выбрали ваши разработчики

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

Эта составляющая может существенно добавить времени еще до начала отрисовки. То есть сайт просто висит для пользователя, пока там происходит внутренняя кухня, в течение нескольких секунд. Иногда в течении десятков секунд. Отказы растут, деньги падают. Занавес.

И эта та часть, которая зависит от разработки. Но не всегда и не полностью.

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

Все мы можем себе представить, что такое лишиться кислорода на 1 минуту. Это в принципе терпимо. Но если в этот момент вы бежите с сумками в руках - есть риск задохнуться.

Для действующего бизнеса потерять работающий сайт даже на 1 час бывает очень больно. А иногда сайт ломается надолго. В общем тяжелая наследственность это очень проблемно.

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

Пример этой весны - заказчик хочет редизайн сайта.

Давно назрело. Заказчик очень тщательно вникает в возможные варианты. Но у заказчика нет своей команды разработки. Есть 2 человека. И нет времени и денег, чтобы командой из 5-8 человек пилить сайт в течение полугода.

Заказчик выбирает Битрикс, сеошник обливаются кровавыми слезами. Но это реалии бизнеса. Для текущего заказчика это был единственный приемлемый вариант исходя из денег/сроков/команды.

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

И также он не любим многими разработчиками, потому что он сделан явно не для разработчиков.

  • Сервера - как они организованы, какое железо используется. На моей памяти когда Рамблер Новости переехали на старые сервера (почему-то с SSD переехали на HDD) - скорость ответа сервера упала в несколько раз и seo трафик упал следом. Все это произошло за 1-2 дня. Также быстро тогдашний продакт добилась возврата серверов и seo трафик вернулся также в течение 1-2 дней. За это продакту отдельное спасибо.

Так вот почти никто в кампании обычно не знает, чем занимается девопс или сисадмин. Что там можно настраивать? У многих компаний нет своего сисадмина. Что такое DNS и прочие штуки связанные именно с железом, где хранится ваш сайт?

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

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

Часто это связано с покупкой нового сервера или сменой тарифа. И это решение обычно откладывается. В ущерб прибыли компании.

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

  • Как происходит кеширование.
    Тут подбираемся к зоне ответственности разработчиков и сисадминов.
    Я периодически вижу сайты, у которых при каждой загрузке страницы заново загружаются по 5-8 шрифтов. И часто на данной странице ни один из них не используется. Шрифты весят обычно не мало. Но это тонкий момент.

    Также часто загружаются варианты картинок, которые для данного экрана вообще не используются.

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


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

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

Скорость Яндекс Недвижимости, например, заметно хуже, чем у Авито Недвижимости.  Но у Авито нет своего поисковика и спец выдачи.
Скорость Яндекс Недвижимости, например, заметно хуже, чем у Авито Недвижимости.  Но у Авито нет своего поисковика и спец выдачи.
Также у Авито есть Progressive Web App. Ребята молодцы, вкладываются в технологическую составляющую.
Также у Авито есть Progressive Web App. Ребята молодцы, вкладываются в технологическую составляющую.

Верстка страницы

Это уже в чистом виде зона ответственности разработчиков.

Большинство разработчиков понятия не имеют о требованиях поисковых систем. Это нормальная ситуация. Потому как создать продукт в короткие сроки - это уже хорошо. Если продукт не лагает - разработчик гений. Какие seo требования?

Есть куча мелких нюансов. Самые известные:

  • Заголовок H1 должен быть на странице в количестве 1 штука. Стабильно каждый второй сайт в моем аудите - либо не имеет этого заголовка, либо имеет несколько заголовков на странице.
  • Инлайн стили - это когда не в отдельном css файле, а прямо в верстке страницы. В большинстве случаев это зло с точки зрения seo.
    Это раздувает размер страницы, уменьшает количество полезного контента на странице. И такие стили, так же как и js теги надо выносить в отдельные файлы. Но не всегда. Иногда из соображений скорости надо засунуть тег script прямо в тело страницы.
  • А еще нужно указывать какой скрипт в какой последовательности грузить, чтобы не блочить отрисовку страницы или выдачу основного текстового контента.
    Такие вещи программист знать не обязан. Поэтому с одной стороны ценятся программисты, знающие seo требования. С другой стороны ценятся сеошники умеющие программировать. Таких почти нет, обычно уходят в программисты.
  • Или как сделать сеошный заголовок h1, но так чтобы глаза у пользователя не лопнули от ключевиков. Приходится такой заголовок маскировать под второй заголовок страницы. И чтобы визуально он был пониже. А для поискового робота - повыше.

Смех и слезы в том, что это настолько простые вещи для квалифицированного сеошника, что их достаточно один раз объяснить квалифицированному программисту - и он дальше все будет делать “как надо”.

Но! Технически грамотных сеошников раз-два и обчелся. Я не утрирую.

И это первая причина почему сеошники и агентства не любят техническую оптимизацию.

Если сеошник хорошо разбирается в технической части - он быстро становится программистом.

Когда сеошник в агентстве набирается опыта - он уходит в штат в кампанию или во фриланс.

6 человек из SEO команды Рамблера умели программировать. Сейчас:

  • двое работает разработчиками
  • один тимлидом разработки
  • один руководителем SEO одного из продуктов Яндекса
  • один seo-программистом
  • один сейчас пишет эту статью и основную часть времени занимается маркетинговой аналитикой и другими задачами маркетинга, иногда программирует под нужды отдела и частным образом консультирует клиентов по части SEO

Еще немного про скорость

Почему про скорость столько текста написал - потому что это важный фактор ранжирования.

И важный фактор для пользовательского поведения.

Задача решается с большей вероятностью, если она нужна нескольким функциям в компании.

Например, скорость нужна и seo-специалисту, и бизнесу. Потому что улучшение скорости загрузки снижает отказы. И потому что скорость поглощения страниц поисковым роботом становится выше. И потому что меньший bounce rate косвенно влияет на повышение позиций в поиске.

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

А поскольку нет шкалы - что мы изменили скорость на 10 пунктов в Google Lighthouse и сайт получил 1000 новых позиций, или переходов из SEO или заказов из SEO. Задача на полгода с неточно прогнозируемым эффектом вызывает скепсис.

Что нужно знать про скорость:

  • Абсолютные метрики важны. Но имеет смысл в первую очередь ориентироваться на показатели ваших конкурентов в поиске. Нужно быть как минимум не хуже конкурентов. И не нужно стремиться к идеалу в ущерб остальным задачам.
    Конкуренты в поиске - это не всегда конкуренты по бизнес модели. Это сайты, которые показываются по вашим ключевым запросам в поисковиках Яндекс и Google в первую очередь.
  • Google Speed Insight - алгоритм учитывающий скорость работы сайта
  • Google Lighthouse - можно сделать аудит составляющих скорости вашего сайта и сайтов конкурентов глазами Google. Обращайте внимание на раздел Performance. Есть браузерное расширение или часть функционала консоли в Chrome.
    Я использую расширение
  • Предзагрузка скриптов, картинок тут

Почему техническую оптимизацию часто игнорируют:

  • Не умеют, не разбираются. Этим грешат субподрядчики и штатные seo-специалисты.
  • Долго делать, результат может быть отсроченным. А быстрые победы нужно в первый месяц. обычно актуально для seo подрядчиков.
  • Невозможно спрогнозировать результат. Это в целом причина, почему seo задачи не долетают до разработки.
  • Связано с серьезной переработкой сайта. То, что часто не нужно бизнесу. Или разработчикам/подрядчикам. Это время и затраты ресурсов.
  • Связано с покупкой серверов, сменой тарифа или хостера. Это также затраты.
  • Нет коммуникации с разработкой. Сеошник не донес важность, не смог аргументировать или показал себя некомпетентным в технической части.

В завершение хочу отметить - не нужно пытаться вылизать все пункты по технической части. Здесь также есть приоритетные задачи и задачи с минимальным влиянием на трафик.

Я пользуюсь либо квадратом: Легко/Сложно - Много эффекта/Мало эффекта.

Либо 3 факторным показателем:

Эффект (1-10 баллов) * Скорость реализации (часы, дни, недели) * Сложность ( 1-10 баллов связано ли с переработкой текущей структуры или процессов)

Если эффект можно посчитать в приросте seo переходов или заказов - делаю и так.

Когда у вас есть таблица с 30-ю seo доработками и есть баллы напротив каждой задачи - вопрос приоритезации упрощается. Сложность и скорость реализации обычно оценивает разработка.

Надеюсь, что примените что-то в своей практике и спасибо, что дочитали до конца.

1414
23 комментария

Полезная статья, спасибо

1
Ответить

Статья оч крутая. Вопрос а что любить если не битрикс? С учетом того что сейчас в рф многие гоняют на вордпресе битриксе и тильде

1
Ответить

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

Ответить

Могу рекомендовать Wordpress, если все-таки ориентироваться на рейтинги и популярность CMS по всему Интернету, а не по нашему несчастному чебурнету) А там Wordpress все конкуренции, что способствует многочисленным решениям и плагинам под любую задачу.

Ответить

Я конечно не уверен, но я прочитал и не совсем понял о чем статья. То ли о важности технической оптимизации, то ли о личном опыте и утверждении того, что мало SEOшников, которые знаются на технической части, но в таком случае весь совет сводиться к "учитесь веб-разработке". Грамотный SEOшник не будучи веб-разработчиком с многолетним стажем в любом случае сможет объяснить что ему конкретно надо от разработчика, тут уже индивидуально от человека зависит умение объяснить и растолковать. Если человек тугой, то не важно кто он по специальности.
Вроде и полезная инфа, а вроде непонятно. Может я плохо вчитывался..

1
Ответить

Можно дополнить данный список анализом логов сайта, дает очень много информации для "подумать", например- можем найти ошибки, например, существующие на мобильной версии сайта при их отсутствии в десктопной, найти ошибки 4хх и лишние 3хх (которых нет в перелинковке сайта), съедающие краулинговый бюджет, и вообще посмотреть на сайт глазами поискового бота (а это не сможет ни один парсер). Для анализа удобно использовать софт типа Screaming Frog Log File Analyzer

1
Ответить

половина статьи про личный опыт автора в рамблере, который неинтересен,
вторая половина, про азы SEO оптимизации, которые открывает для себя любой программист после первого же проекта с нормальным SEO-оптимизатором. После прочтения возник всего один вопрос, зачем это на VC ?

Ответить