Техническая оптимизация в 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 сайты. Но сейчас это риск.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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