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

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

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

"Начинающий SEO специалист и поисковый робот. Фото в цвете. 2024"
"Начинающий SEO специалист и поисковый робот. Фото в цвете. 2024"

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

  • Это база, которая определяет вашу профпригодность.
  • Вам необходимо корректно ставить задачи для dev команды и уметь общаться с ней на одном языке. В противном случае вы будете постоянно конфликтовать с разработкой, вместо того, чтобы эффективно решать задачи и растить результат.
  • Если вы работаете в реальном IT, а не в потогонке, это дает вам возможность смотреть шире, видеть больше и выглядеть экспертно в глазах технически подкованных коллег

Оглавление

Что такое техническое SEO

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

Сюда входят:

  • доступность сайта для сканирования и индексации
  • коды ответа и HTTP заголовки
  • каноникализация страниц
  • hreflang теги (для мультиязычных сайтов)
  • рендер страниц вашего сайта
  • скорость загрузки страниц и Core Web Vitals
  • настройка корректного зеркала сайта
  • отсутствие цепочек редиректов, битых ссылок и тд

Как измерить техническое SEO

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

  • Скорости загрузки сайта, измеряем тут — https://pagespeed.web.dev/
  • Core Web Vitals — можно смотреть в Search Console, можно сторонние сервисы типа https://calibreapp.com/tools/core-web-vitals-checker. В последнем можно посмотреть данные не по отдельному URL, но по домену в целом. Профит сомнительный, но задумка интересная. Google время от времени убирает старые и добавляет новые CWV, обосновывая это поиском священного грааля пользовательского опыта, так что stay tuned.
CWV здорового человека
CWV здорового человека

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

Казалось бы с таким Page Speed делать в ТОПе нечего
Казалось бы с таким Page Speed делать в ТОПе нечего
Но как показывает практика плохенький Page Speed не особо-то ограничивает ваш рост в органике
Но как показывает практика плохенький Page Speed не особо-то ограничивает ваш рост в органике

Что нельзя измерить

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

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

Всё просто:

  • Что хотим отдавать в индекс оставляем открытым (не запрещаем в robots.txt для сканирования, не запрещаем для индексации через meta robots и X-Robots tag).
  • Всё что не хотим отдавать в индекс — соответственно закрываем.

Особый случай про капкан индексации описывал тут — 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

2. Коды ответа и HTTP заголовки

Для всех целевых страниц, которые хотим видеть в выдаче настраиваем 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

3. Canonical

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

4. Hreflang

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

5. Рендер

Этот параметр стоит особняком, тк его можно проверить, при этом нельзя измерить и он небинарный. Вкратце рендер — это то, как поисковый бот видит страницы вашего сайта. Проверяется в консоли 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

6. Настройка корректного зеркала сайта

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

  • С www / без www
  • http —> https
  • Исключение редиректов с множественным / (https://site.com////)

7. Отсутствие цепочек редиректов, битых ссылок и тд

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

Неочевидные ошибки в техническом (и не только) SEO

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

Блокировки UA на стороне сервера

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

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

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

Микроразметка

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

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

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

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

Подклейка дропов

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

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

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

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

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

Управление индексированием на уровне robots.txt

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

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

«Тонкий» контент

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

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

  • Объём. С давних пор считается, что текст в зоне основного контента (кроме меню и других сквозных блоков) должен быть не менее 300 слов. Фактически вебмастера неоднократно выявляли, что страницы размером менее 600 слов неохотно сканируются гуглоботом. Это вполне логично: для полноценного раскрытия любой темы требуется достаточно объёмный текст. Но фактически ваша страница может ранжироваться и с минимальным объёмом контента (до 100 слов), если поисковая система сочтёт его достаточно ценным.
  • Грамматика. До сих пор можно найти рекомендации вставлять ключевые слова с ошибками, потому что пользователи вводят их таким образом. В этом нет никакого смысла, поскольку ПС в состоянии не только привести ключевые слова к нормативной форме, но способны и понимать смысл. А вот грамматические ошибки могут привести к тому, что URL получит высокий балл оценки «тарабарщины» (gibberish), что является признаком дорвея с сгенерированным контентом – и страница будет отфильтрована.
  • Под уникальностью подразумевается буквальная уникальность текста в рамках сайта. Дубли в индексе не нужны. Чем меньше уникальность – тем выше вероятность, что совпадающие страницы будут склеены, а дублирующийся контент – деиндексирован. Это чисто техническая проблема, выявить которую должен технический аудит. Screaming Frog SEO Spider позволяет выявить как чистые технические дубли, так и нечеткие дубли с высоким показателем совпадения (от 90 до 100%).

Канонические адреса (Canonical)

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

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

  • Канонический адрес указывается для склеивания (консолидации) идентичного контента. Вы не можете склеить несклеиваемое. Даже в случае страниц пагинации контент может сильно отличаться, а это значит, что канонический адрес не будет учтён.
  • Для выбора канонической страницы поисковые системы используют не только оценку совпадения контента: в неменьшей мере влияют и дополнительные сигналы – пользовательские (ПФ) и ссылочные. Под ссылочными в том числе подразумеваются и ссылки в рамках сайта: парой лишних ссылок на неканоническую страницу вполне можно обнулить Canonical.
  • Каноническая страница не может быть закрыта от сканирования, индексирования и отдавать код, отличающийся от 200.
  • Все ссылки, попадающие в sitemap.xml, рассматриваются как канонические. А это значит, что при наличии проблемных моментов поисковая система проигнорирует либо сайтмап, либо Canonical, либо сочтёт, что сайт вообще не очень-то качественный, а вебмастер сам не знает, что несёт.
  • Гугл замечен в том, что в качестве канонической страницы может выбрать страницу на другом сайте – нигде этого не афишируя. Хотя бы поэтому важно следить за уникальностью контента на сайте в рамках всего интернета. Хорошая новость: Яндекс таким пока не балуется, он может один и тот же контент на разных сайтах показывать в одной выдаче.

Противоречивые директивы

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

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

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

Проверка технического SEO на вашем сайте — исчерпывающий чеклист

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

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

Скриншот моего чек-листа
Скриншот моего чек-листа

Заключение

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

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

99
10 комментариев

Все прочитал, теперь я сеошник ))

4
Ответить

Статья подготовлена автором канала SEO PM совместно с Tech SEO гуру Виктором Петровым.

Это многое объясняет))

1
1
Ответить

Ба, какие люди!

1
Ответить

хочу чеклист, сил нет! на канал подписан :)

1
Ответить

Скинул в лс в тг

1
Ответить

абсолютно бесплатноА как это отличается от "бесплатно"? То, что длиннее на слово, я вижу.
И да, я, конечно, хочу чек-лист/чеклист/контрольный список/проверочный список/план-перечень/памятку. Коллекционирую, знаете ли.

Ответить

Обратная связь: прежние чек-листы действительны.

Ответить