SEO в highload SPA проектах: когда документов, ключей и трафика миллионы — разбор RUTUBE

Основные сложности highload

Самая большая проблема highload — это его объем. А при больших объемах стандартные инструменты перестают выполнять свои функции надлежащим образом. К примеру, тот же лист Excel тащит не более 1 100 000 строк. То есть, если в работе у вас имеется сегмент, превышающий данный показатель, на одном листе состакать информацию по нему уже не удастся.

Индексация

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

Допустим, у вас очень много видео. Тогда карту сайта необходимо делить на чанки (отдельные информационные блоки) ориентировочно по 5 000-6 000 взаимосвязанных друг с другом URL-адресов. Откуда поиск их вполне нормально забирает.

Делая валидную карту, вы основательно упрощаете себе жизнь. Если в карте у вас будут все документы сайта с кодом 200, то Яндекс подготовит вам датасеты по каждому URL. В итоге из вашей карты собираются данные (можно посмотреть подокументно, когда и какой бот приходил, находится ли документ в индексе плюс title, description и т. п.). Другими словами — формируется полноценная документная история.

Вторая история — все что связано с позициями. Допустим, у вас имеется 5 миллионов документов, каждый из которых продвигается минимум по 10-15 запросам. На выходе получается, мягко говоря, внушительная цифра. Обрабатывать такое количество документов стандартными инструментами довольно проблематично и что самое главное — очень долго.

Чтобы упростить задачу, можно забрать датасеты из панели веб-мастера Яндекса и составить специальные скрипты для их разбора. Тогда скрипт будет разбирать датасеты, складывать их в базу (где с приходом нового дата-сета производятся плановые обновления).

Составляя валидную карту сайта, важно помнить

• Карты делаются отдельно для поисковых систем Яндекс и Google.
• Для видео-объектов в Google html-разметка делается прямо в карте.
• Для видео-объектов в Яндекс используется ovs-разметка.
• Необходим разбор датасетов Яндекса.
• Создание автоматизации проверки в Google.

При этом с Google в этом плане не все так просто. В нем нет тех же датасетов, которые можно разобрать (как в Яндекс), API имеет существенные ограничения.

Чем гоним в индекс

• Google Indexing API.
• IndexNow.
• Ловец ботов и динамические блоки.

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

Однако про первые два пункта забывать также не стоит. Google Indexing API и IndexNow — два отличных инструмента, которые позволяют информировать системы об изменении, добавлении, удалении документов на проекте напрямую. Что весьма удобно, особенно если речь идет об огромном количестве контента.

Позиции

Когда по большому объему семантики необходимо понять что происходит по позициям, задача решается следующим образом:

• для Яндекса — это разбор датасетов;
• для Google — GSC API;
• внутренняя автоматизация (вплоть до работы с выдачей).

Коды ответа сервера

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

• разделить проект на сегменты, которые будет удобнее мониторить. Проще говоря — разложить информацию по разным папкам (допустим, по типам документов) и планомерно их проверять. К примеру, с помощью поискового бота (краулера), который будет системно «гулять» по сайту и смотреть, какие коды ответа отдаются;
• анализировать датасеты, выгруженные из Яндекса. Здесь тоже важно смотреть на код ответа, который получает бот поисковой системы;
• мониторить логи, выяснять что получает бот. В данном случае хорошо когда все логи собраны в отдельной базе данных. Из этой базы данных системно делаются выемки;
• отключать документы в системе перелинковки, если посадка отдает 404. О выдаче 404 ошибки можно узнать с помощью краулера, изучения датасетов, статистики в GSC или панели веб-мастера Яндекса.

Обратите внимание — учитывая большой объем документов, необходимо проводить системную оценку регулярно. В противном случае полного понимания происходящего достичь не удастся.

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

Сложности с перелинковкой

Еще один важный момент. Когда вы работаете с highload (а вы наверняка при этом занимаетесь SEO, наполнением, получением вхождений и т. п.), необходима перелинковка.

Однако нередко в перелинковке не учитывается код ответа документа. Допустим, у вас есть 10 посадочных страниц. Документов, на которые проставлены ссылки с других документов в системе перелинковки (в зависимости от анкора листа их обычно достаточно много).

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

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

Краулинговый бюджет

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

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

Для наглядности стоит привести пару кейсов.

Кейс по Яндексу

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

В нашем проекте мы в первую очередь начали отдавать на эти документы 301 редирект (переадресацию). Но подождав примерно месяц, никаких существенных изменений мы не заметили. Бот как приходил, скажем 1 000 раз, в попытках собрать информацию с этих страниц, так и продолжал приходить.

Через полтора месяца мы попробовали давать 404 код ответа. Выдержали тот же временной промежуток, но ситуация не изменилась. Следом использовали 410 код ответа (в отличие от 404 он указывает, что документ удален не временно, а навсегда). Однако по факту и это не сработало. Спасением, как ни странно, стала поддержка Яндекса.

Кейс по Google

Если проект достаточно большой, наверняка предусмотрен отдел аналитики, где чаще всего специалисты работают через GTM (Google Tag Manager). По факту, если что-то идет не так, Google начинает находить огромное количество документов с ошибкой 404, а также представляющих собой URL проекта, к которому стакается обращение к социальной сети.

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

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

Берегите то, что скрыто

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

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

В результате не обошлось без казуса. Из базы данных эти URL с паролями стали попадать в систему перелинковки статейника. В блоках предварительного просмотра появились готовые ссылки с паролями совершенно бесплатно. То есть, при переходе по такой ссылке пользователя выкидывало на закрытый (по факту) документ.

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

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

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

Анализ логов

Анализ логов заключается:

• в изучении кодов ответа поисковым ботам;
• в сборе данных (какие документы смотрел бот, когда именно, насколько часто приходил в течение суток);
• в систематическом обогащении внутренней системы автоматизации.

Агрегация данных и дашборды

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

• Tableau. Безусловно, в плане скорости — это не лучшее решение. Однако инструмент идеально подходит для работы на highload, предполагающей обработку миллионов строк.
• Redash. Этот инструмент больше подходит для оперативного мониторинга. Он позволяет с помощью SQL-запросов вынимать определенные данные из базы, что весьма удобно.
• Grafana. Данный инструмент можно назвать средой, в которой генерируются наглядные инфраструктурные истории (в основном графики) по нагрузке на сервера, по кодам ответов и т. п.
• Google Data Studio. Пригодится для систематизации полученных данных и составления отчетности.
• Как вариант можно использовать собственные разработки.

Обогащение:

• API Yandex Webmaster;
• API GSC;
• API Yandex Metrika.

Single Page App (SPA)

Теперь поговорим непосредственно про SPA. Single Page App представляет собой методологию сборки сайта при наличии шаблона, в который, в зависимости от ситуации, сэтятся различные документы. То есть как такового перехода с документа на документ может и не быть.

На самом деле, когда вы занимаетесь SEO в highload SPA проектах — это ежедневная война. Потому что на сегодняшний день поиск все-таки не готов достаточно хорошо разбирать JavaScript сайта.

Основные особенности работы со SPA-проектами

• Необходимость использовать SSR.
• Необходимость пререндера (когда поисковому боту отдается пререндер-версия документа). Но здесь есть один нюанс. Если контента много (главная страница равна 15-20 скроллам) и он тяжелый, предстоит выполнить удаление js кода.
• Контроль за метаданными. Особенно актуально, если у вас огромное количество документов в обработке. Так как мета может сэтиться от других документов — распространенная проблема. Поэтому ваш краулер должен собирать два вида метаданных: данные с нижнего уровня и, например, через Selenium (инструмент для автоматизации действий веб-браузера) в роли визуализатора браузера. Полученные данные краулер сверяет с базой и выявляет соответствия/несоответствия.Также распространена ситуация, когда мета не сэтится при клиентских переходах (часть разметки остается не видна).
• Контроль роутинга. Роутинг — это история о том, как строятся переходы на вашем проекте. При наличии слишком сложной системы, большого количества бизнес-логики нередко случаются сбои. Например, через папку статьи начинают вылетать документы из других разделов.То есть вы переходите на какой-то документ, добавляя к его URL название нужной папки. Но несмотря на то что такого документа быть не должно, он отдается с кодом 200. При таком раскладе генерируется и в дополнение дублируется огромное количество документов, которые по существу не имеют места быть. И если речь идет о миллионах страниц — это становится настоящей проблемой. Подобные ситуации необходимо постоянно мониторить и решать как можно быстрее.С распространением дублей также связана проблема доступа к техническим документам. Дубли технических документов висят на уникальных URL, но при этом они очень похожи.

• Микроразметка. Пользу микроразметки сложно недооценить. Она несет огромное количество трафика. Если говорить, например, о видео, то трафик, который льется из Яндекс и Google, весьма существенный. Без использования микроразметки он, к сожалению, останется недосягаемым.Соответственно, все что касается расширенных сниппетов (если у вас в работе крупный статейник или видеохостинг и т. п.) предполагает наличие микроразметки. Причем вся. Так как у поисковых систем Яндекс и Google в отношении нее разные предпочтения. Поэтому размечайте все, валидно (где это возможно), подтягивайте как можно больше полезной информации.

• Подмена URL вместо редиректа. Еще одна огромная боль SPA-проектов. Потому что многие разработчики просто не видят разницы. Для них на первом месте простая механика действий (перехода в данном случае). На практике, когда вся эта история мониторится поисковым ботом, возникает немало вопросов, связанных с редиректами.Допустим, вы перетаскиваете какой-то крупный раздел. И вроде бы все хорошо, переходы работают, но вес не передается. И не будет передаваться, если задействована подмена URL вместо редиректа. Для SEO такая ситуация критична.

• Пагинация — еще одна тяжелая история для крупных SPA-проектов. Потому что в их случае обычный lazy loading (бесконечный скролл) попросту не работает. Бесконечный скролл не подразумевается нумерацию страниц или наличие клавиши «загрузить еще» и т.п. Весь контент подгружается динамически за пользователем, который его просматривает. И если взять этот документ и посмотреть что сохранилось в кэше поисковой системы — это будет просто первый экран.Пагинация нужна и она должна быть видимой. Нумерация страниц, а лучше клавиша «загрузить еще», в которой будет ссылка без подмены URL.

• Скорость загрузки. Высокая скорость загрузки важна всегда. Но если говорить про крупные проекты и тяжелый контент — жизненно необходима. Работать над ней нужно системно. Потому что при внесении изменений в дизайн сайта, переработке шаблона или докрутки бизнес-логик все может вернуться на круги своя (скорость снова снизится). Что в итоге неизбежно приведет к оттоку аудитории.Современные пользователи (приверженцы мобильных версий сайтов) не готовы ждать даже 1,5-2 минуты загрузки.
• GTM как источник проблем. Работая с этим сервисом необходимо соблюдать осторожность. Вернее — постоянно мониторить ситуацию. Так как в противном случае также можно столкнуться с генерацией несуществующих документов, уменьшением краулингового бюджета и т. п.
• Изменения на фронте, а вы не в курсе. Когда вы работаете в крупном проекте, в котором участвуют много команд, необходимо держать руку на пульсе. Важно понимать, что собираются делать люди, с которыми вы ведете общее дело. Ведь о проблеме лучше узнать до ее появления, как и о появлении нововведений. Работайте вместе, обсуждайте нюансы, договаривайтесь и обязательно учитывайте пожелания друг друга — это в идеале.

Наращивание компетенций

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

• JS (JavaScript). Владеть данным языком очень полезно, так как на нем работает основная масса фреймворков;
• API. Умение работать со всевозможными API также имеет немаловажное значение. Если вы понимаете как это устроено, знаете определенные инструменты, позволяющие взаимодействовать с API других сервисов — работать будет гораздо проще;
• Python. Очень удобный лаконичный синтаксис. Огромное количество его модулей и библиотек позволяют без проблем решать большинство разношерстных задач;
• Selenium. Отличный инструмент, с помощью которого можно вынимать и просматривать данные из SPA-проектов. Потому что если вы просто попробуете спарсить их напрямую, получите кучу скриптованного кода и останетесь без контента. Именно Selenium поможет собрать уже отрендеренную информацию в документах;
• SQL (язык структурированных запросов). Еще один хороший навык в копилку SEO-специалиста. К тому же изучить его довольно просто. Базовых навыков: как написать, как достать, добавить новое условие, слить из выгрузки и т. п. вполне достаточно;
• GIT (распределенная система управления версиями). В ней также неплохо разбираться. Если вы что-то кодите или участвуете в разработке, вам это пригодится. Как строятся версии, как они межатся — все это необходимо знать. Хотя бы на базовом уровне.
• Docker. Очередной полезный инструмент разработчиков, который позволяет сделать некую распаковку проекта.

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

• как работает SPA, разбираться во всех его тонкостях и сложностях, которых действительно очень много;
• как действует инфраструктура. Хотя бы на базовом уровне: что такое HTTP-заголовки, что в них передается, как связаны друг с другом сервера, что такое статика проекта и т. п.;
• как ведется разработка. Опять же хотя бы на базовом уровне;
• как работает тестирование. На больших проектах это критичный момент. Потому что если что-то непроверенное или недопроверенное попадает в прод (боевой сервер, где размещается информация непосредственно для пользователей), последствия могут оказаться весьма плачевными;
• как парсить все и вся, чтобы с любой площадки получить то что нужно.