Погружение в техническое SEO — простой и понятный гайд

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

Из-за обилия информации по теме в ней достаточно просто утонуть, поэтому постарался разложить все по полкам, чтобы начинающим и middle специалистам было проще вникнуть в суть. А senior и так все знают 😉

На мой личный взгляд любой SEO специалист обязан разбираться в техничке по нескольким причинам:

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

Сюда входят:

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

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

А вот с некоторыми показателями технического SEO гораздо сложнее. Для ряда параметров возможны только бинарные варианты самой реализации (внедрено / не внедрено) и ее качества (корректно / не корректно). Спасает то, что практически вся необходимая информация есть в документации, ниже дам простые и понятные инструкции где что смотреть и как оно должно работать.

Всё просто:

Особый случай про капкан индексации описывал тут — https://vc.ru/seo/1538256-kak-pravilno-zapreshat-google-indeksirovat-vash-sait.

Обязательно проверяем, что у нас корректно формируются xml сайтмапы и что туда попадают только страницы с кодом ответа 200, каноничные (см ниже), открытые для индекса. При этом размер sitemap.xml файла не более 50Мб и в нем не более 50к ссылок — https://developers.google.com/search/docs/crawling-indexing/sitemaps/overview?hl=ru

Для всех целевых страниц, которые хотим видеть в выдаче настраиваем 200, для неактуальных страниц — 404 или 301. Регулярно проверяем, чтобы в рамках сайта не было ссылок на страницы с кодом ответа 404. Наличие 301 нежелательно, но не критично, особенно если у вас небольшой сайт.

Из HTTP заголовков вам может пригодиться только X-Robots-Tag для закрытия страниц от индекса в особых случаях и If-Modified-Since + Last-Modified для гибкого управления сканированием вашего сайта. Отличная документация по HTTP заголовкам — https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers

Настраивается на основную версию страницы (та, которая без get-параметров — utm-меток, ref_id и тд). Для всех страниц с get-параметрами настраиваем canonical на основную версию страницы. Canonical всегда указывается в абсолютном формате. Ссылка на документацию — https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls?hl=ru

Подробно описывал тут — https://vc.ru/seo/1343095-hreflang-tegi-osnova-multiyazychnogo-seo

Этот параметр стоит особняком, тк его можно проверить, при этом нельзя измерить и он небинарный. Вкратце рендер — это то, как поисковый бот видит страницы вашего сайта. Проверяется в консоли Google и выдаче Яндекса через проверку сохраненной копии (в Google это сделать уже не получится) либо через Яндекс Вебмастер. В большинстве случаев бот должен видеть то же, что и пользователь. Об одном из исключений писал тут — https://vc.ru/seo/1519629-soft-404-poidi-tuda-ne-znayu-kuda-prinesi-to-ne-znayu-chto.

Если вам захочется почитать про JS фреймворки aka SPA сайты и виды рендеринга, вот отличная статья моего коллеги — https://vc.ru/seo/1262880-kak-podruzhit-saity-na-javascript-s-seo-ssr-ssg-isg-chto-eto-voobshe-takoe

Настройка базовых правил редиректов:

Исключаем ссылки на страницы с кодом ответа не 200 в рамках сайта. Для поиска таких ссылок используем Screaming Frog либо Site Analyzer. Сторонние онлайн-чекалки, которые предоставляет ahrefs или semrush не рекомендую — у них нет гибкой настройки параметров и они могут сильно подвесить ваш сайт. Оставьте их для красивых агентских аудитов 😉

Текст данного блока статьи любезно подготовил https://vc.ru/u/253094-viktor-petrov. Все пункты — из реальной практики, что попадалось за последние 2-3 года.

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

Типический пример: сталкиваясь с нашествием ботов из Metropolitan branch of PJSC MegaFon, ретивые вебмастера блокируют визиты оттуда. А это – вовсе не какой-то вай-фай в метро, это крупнейший филиал «Мегафона» вообще, притом не только Москва в ряде случаев (какое-то время все SIM-карты «Мегафона» изначально были привязаны к московскому региону).

Примерно такая же история – с блокировкой регионов и других стран. «Зачем мне заходы из Голландии?» –примерно так и рассуждает вебмастер, обрубая визиты тех, кто постоянно сидит под VPN на родине-матушке, в Российской Федерации.

Устоявшееся мнение о важности микроразметки — это способ вывести красивый сниппет в выдаче. Да, информативный сниппет положительно влияет на кликабельность ссылки, обращая на себя внимание, всё верно.

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

Для поисковой системы всё это бесполезная информация и путаница, лишь мешающая разобраться, где тут у вас что и зачем. Хорошая разметка подразумевает структурирование всего сайта, и каждому типу контента назначается собственная схема: вот главная страница сайта такой-то организации, расположенной по такому вот офлайн-адресу. Тут у нас – товары, тут статьи об этих товарах, вот информация об авторах, а вот подтверждение информации на сторонних ресурсах. Всё по полочкам.

Да, это всё ещё не работает, как задумано и обещано, но считайте свои метаданные письмом в будущее – которое когда-нибудь вам ответит.

Google – старый зануда, который при всём его склерозе всё записывает, хотя не всегда помнит, куда записал и зачем. И вот по итогам вы полностью обновили сайт года три назад, сменив структуру, CMS, настроив постраничные редиректы. А старый больной гуглобот продолжает ходить по давно убитым URL. Это предыстория.

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

Но не все дропы одинаково полезны. Домену может быть 20 лет, но всё это время он был в статусе припаркованного, или сайт был полностью деиндексирован лет 5 назад. Такой «дроп» не даст вам ничего, кроме чека за его покупку – он и раньше не имел никакой ценности для поисковых систем. Чтобы воспользоваться им во благо, надо для начала поднять сайт, вернуть его в индекс, а потом аккуратно подклеить к своему сайту.

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

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

В священных книгах сеошников есть заповедь: «Найдено не значит просканировано. Просканировано не значит проиндексировано. Проиндексировано не значит ранжируется». К этому можно добавить ещё «Ранжируется – не значит, что конвертируется» и всё такое, но сейчас речь о другом.

Вебмастера до сих пор пытаются управлять индексированием с помощью файла robots.txt, который сделан для управления сканированием. Всё просто: если робот не должен даже нос совать в ваши служебные и технические адреса – вносим директиву в robots.txt. Если речь идёт об обычном контенте, который не нужен в поиске – настраиваем это с помощью мета “robots”, канонических адресов и т.п. Потому что то, что робот не может просканировать, он может всё равно показывать в поиске, если сочтёт, что это важно (на этот URL есть трафик, ссылки и т.п.).

Момент, на который нечасто обращают внимание при аудитах. Формально thin content объединяет некачественный, малопопулярный, избыточный или недостаточный контент – всё, что поисковые системы не хотят индексировать.

У контента такого рода есть и чисто техническая сторона: объём, грамматика и уникальность. Эти недочёты можно легко выявить программно, с помощью той же Screaming Frog SEO Spider. На что конкретно нужно смотреть:

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

Canonical – не приказ для робота, это вежливая просьба. При ряде условий эта директива может быть проигнорирована. Вот некоторые из них:

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

Пример: помимо мета “robots’, содержащего указания роботам по индексированию (индексировать или нет, следовать по ссылкам или игнорировать) для управления индексированием учитывается ещё серверный заголовок X-Robots-Tag, который ещё до загрузки страницы передаёт точно те же директивы.

По идее, используется X-Robots-Tag для управления документами, отличными от HTML: файлами PDF, Word и т.п., в которых не предусмотрены метаданные такого рода. На хорошем виртуальном хостинге с проблемами такого типа вы едва ли столкнётесь. Другое дело, если вы используете выделенный виртуальный сервер, за настройки которого отвечаете вы сами или ваш вебмастер. И напортачить тут проще простого: ошибочная настройка может разом скрыть вообще все ресурсы одного типа, закрыть от индексирования целые разделы, а вы будете думать, почему сайт никак не хочет ранжироваться по каким-то запросам и искать переспам в тексте, ловить зловредных ботов или отклонять ссылки.

У меня есть готовый чек-лист, который позволяет провести технический анализ сайта по 70 параметрам. Я не люблю листать длинные и слабо структурированные портянки документов, поэтому сделал чек-лист в формате google таблицы. На основании него легко скорить найденные проблемы и готовить таблицу для внесения изменений на сайте для dev команды.

Готов поделиться им с вами абсолютно бесплатно, для этого достаточно оставить комментарий под этой статьей ("хочу чеклист" либо выразить благодарность авторам) и подписаться на мой канал https://t.me/seo_team_lead

Tech SEO — не просто важная составляющая поискового продвижения, это его основа. Поначалу количество информации, особенно если у вас нет технического бэкграунда, может казаться просто ошеломляющим. Надеюсь эта статья поможет вам разобраться в предмете, откинуть все ненужное, а нужное понять и легко уложить все в голове.

Статья подготовлена автором канала SEO PM совместно с Tech SEO гуру Виктором Петровым. Если вам необходима профессиональная консультация по SEO — пишите в ЛС или оставляйте комментарий под этой статьей.