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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Третье - хочу лишний раз привлечь внимание 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 шрифтов. И часто на данной странице ни один из них не используется. Шрифты весят обычно не мало. Но это тонкий момент.
  
  Также часто загружаются варианты картинок, которые для данного экрана вообще не используются.
  
  Программисты иногда любят сделать все основательно и на каждую страницу отдавать весь контент для всех вариантов устройств.
• Проверьте как сжаты картинки, какие форматы картинок используются, есть ли ленивая загрузка и прочие фишечки.
  
  
  

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

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

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

• Заголовок H1 должен быть на странице в количестве 1 штука. Стабильно каждый второй сайт в моем аудите - либо не имеет этого заголовка, либо имеет несколько заголовков на странице.

• Инлайн стили - это когда не в отдельном css файле, а прямо в верстке страницы. В большинстве случаев это зло с точки зрения seo.
  Это раздувает размер страницы, уменьшает количество полезного контента на странице. И такие стили, так же как и js теги надо выносить в отдельные файлы. Но не всегда. Иногда из соображений скорости надо засунуть тег script прямо в тело страницы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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