SEO — это не PageSpeed: что автоматические аудиты не рассказывают о поиске

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

Например, в качестве проблемы приводился URL с %D0... в адресе — хотя это обычный percent-encoding кириллицы. Или показатель SEO 92% из автоматического аудита интерпретировался почти как «страница на 92% оптимизирована».

На этом я и решил отдельно разобраться, где заканчивается технический аудит и начинается настоящее SEO.

Что на самом деле проверяет автоматический SEO-аудит

Автоматический аудит смотрит на то, что можно проверить технически: есть ли title, есть ли meta description, есть ли lang у документа, есть ли alt у изображений, корректно ли используются некоторые HTML-элементы.

Это полезные проверки. Но они не отвечают на главный вопрос SEO: насколько эта страница соответствует поисковому запросу и действительно полезна человеку, который этот запрос вводит?

У страницы может быть идеальный технический score и при этом не быть причин занимать высокие позиции в поиске. Потому что SEO — это не только набор HTML-атрибутов.

И это первое, о чём стоит договориться: автоматический инструмент показывает симптом, а специалист должен найти причину. Всё остальное в статье — про это различие.

alt — это не просто SEO-галочка

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

Но это не означает, что достаточно добавить ключевую фразу в alt каждой картинки и получить SEO-буст. Для декоративного изображения вообще может быть правильнее оставить пустой alt, чтобы скринридер не озвучивал пользователю лишний визуальный шум.

Поэтому вопрос должен звучать не «у всех изображений есть alt?», а «есть ли у этого изображения смысл, который нужно передать пользователю и поисковой системе?»

lang не делает страницу локализованной

Ещё одна распространённая рекомендация — добавить атрибут lang?Атрибут HTML, который указывает язык документа. Например, lang="ru". Помогает браузерам и скринридерам корректно обрабатывать текст. в HTML — например, <html lang="ru">. Это действительно полезно: браузеру и вспомогательным технологиям становится понятнее, на каком языке написан документ. Для accessibility это особенно важно — скринридер может корректнее выбрать правила произношения.

Но отсутствие lang не означает автоматически, что поисковая система неправильно проиндексирует страницу. И тем более lang="ru" не создаст английскую версию сайта. Это хороший пример того, как техническая рекомендация из автоматического аудита превращается в слишком широкое SEO-утверждение.

Percent-encoding в URL — не проблема само по себе

Иногда в адресной строке можно увидеть что-то вроде:

/search?q=%D0%B4%D0%B8%D0%B7%D0%B0%D0%B9%D0%BD

На первый взгляд это выглядит страшно. Но %D0%B4... — обычное percent-encoding?Способ кодирования символов в URL. Кириллица и другие символы заменяются на %XX, где XX — шестнадцатеричный код символа. Так работает весь интернет, это норма.. Кириллица и другие символы кодируются в URL именно так. Само наличие закодированных символов не означает проблему с SEO.

Настоящие проблемы могут появиться в другом месте. Например, если сайт создаёт огромное количество URL с параметрами:

/search?q=дизайн
/search?q=дизайн&page=2
/search?q=дизайн&sort=price
/search?q=дизайн&filter=color

и поисковая система начинает видеть множество дублирующих или малополезных страниц. Тогда уже нужно разбираться с архитектурой URL, индексацией, canonical?HTML-тег, который указывает поисковику «главную» версию страницы из нескольких похожих. Помогает бороться с дублями., параметрами и внутренней структурой сайта.

Проблема не в %D0. Проблема — в том, какие страницы вообще создаёт сайт и какие из них должны попадать в поиск.

Один мобильный скриншот не доказывает отсутствие адаптива

Ещё одна интересная ситуация возникает при анализе мобильной версии. Допустим, автоматический инструмент сделал скриншот страницы на определённой ширине, и интерфейс выглядит странно. Можно написать: «здесь не хватило адаптивности».

Но прежде чем делать такой вывод, стоит проверить, действительно ли проблема воспроизводится. Например, посмотреть интерфейс на ширинах 360, 375, 390 и 412 px?Viewport — видимая область страницы на устройстве. Ширина viewport у разных телефонов разная: 360, 375, 390, 412 px и другие. Дизайн должен работать на всех. и посмотреть, как интерфейс ведёт себя при изменении ширины.

Некоторые проблемы возникают не потому, что адаптива вообще нет, а потому что конкретный breakpoint?Ширина окна, при которой layout меняется. Например, при 768px меню превращается в «бургер». Неудачно выбранный breakpoint = развалившийся интерфейс. выбран неудачно, JavaScript не успевает перестроить интерфейс или инструмент зафиксировал промежуточное состояние страницы.

Скриншот показывает результат конкретного рендера. Он не всегда показывает причину проблемы. Для дизайнера это особенно важное различие — и, пожалуй, главная мысль этой статьи.

В своей работе я обычно начинаю проектирование мобильного интерфейса с viewport 390 px, а затем проверяю, как система ведёт себя на соседних ширинах — например 360, 375 и 412 px.

Одна ширина — это не мобильная версия

«Мобильный дизайн» часто сводят к одному макету: 375 × 812. Но реальные устройства используют разные ширины viewport. Интерфейс, который прекрасно выглядит на одной ширине, может начать разваливаться на соседней.

Поэтому адаптивность — это не наличие одного мобильного макета в Figma. Это способность интерфейса сохранять понятную структуру между разными состояниями viewport. Особенно это важно для:

• навигации;
• карточек;
• таблиц;
• фильтров;
• кнопок;
• sticky-элементов;
• форм;
• сложных B2B-интерфейсов.

Автоматический аудит видит только одно состояние. Реальная работа — в том, чтобы пройти по нескольким ширинам и увидеть, где интерфейс ломается и почему.

«SEO 92%» — что это вообще значит?

Это, пожалуй, главный вопрос. Если автоматический инструмент показывает SEO — 92, это не означает, что страница оптимизирована на 92%. Это означает, что страница прошла определённый набор автоматических проверок.

Но эти проверки не знают:

• по какому запросу должна ранжироваться страница;
• какой у пользователя поисковый интент?Намерение пользователя, когда он вводит запрос. Ищет информацию, хочет купить, сравнивает варианты, ищет конкретный сайт. От интента зависит, какая страница должна быть в топе.;
• насколько хорошо страница закрывает этот интент;
• какие страницы конкурентов уже находятся в выдаче;
• насколько качественно устроена структура сайта;
• есть ли каннибализация?Ситуация, когда несколько страниц сайта имеют пересекающуюся релевантность и могут конкурировать за одни и те же интенты. Из-за этого сложнее контролировать, какая страница должна ранжироваться. между страницами;
• какие страницы реально индексируются;
• какие запросы дают показы и клики;
• насколько релевантен контент;
• как устроена внутренняя перелинковка.

Поэтому SEO score — это технический сигнал, а не оценка поискового потенциала страницы.

SEO начинается с поискового запроса

Если я хочу проверить страницу, я сначала должен понимать, зачем она вообще существует в поиске. Допустим, есть страница «Дизайн личного кабинета». Я не могу просто спросить: «у неё хорошее SEO?»

Нужно спросить: под какие поисковые запросы она должна ранжироваться? Например:

• дизайн личного кабинета;
• дизайн личного кабинета UX UI;
• дизайн личного кабинета пользователя;
• UX дизайн личного кабинета.

А затем уже смотреть цепочку: запрос → интент → конкуренты → текущая выдача → содержание страницы → структура сайта. И только после этого можно говорить о поисковой оптимизации.

Техническое SEO — только один слой

Мне нравится разделять сайт на несколько уровней.

Технический уровень. HTML, индексация, canonical, robots.txt, sitemap.xml, URL, structured data?Разметка Schema.org, которая помогает поисковикам понять структуру и тип контента. В некоторых случаях позволяет странице претендовать на расширенное представление в выдаче., скорость загрузки.

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

Контентный уровень. Поисковый запрос, интент, содержание страницы, полнота ответа, структура текста.

UX-уровень. Понятность интерфейса, сценарии, мобильная адаптация, доступность, читаемость и взаимодействие.

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

Автоматический SEO-аудит в основном видит первый слой. А реальное SEO работает сразу на нескольких.

Что я бы проверял вручную

Если автоматический аудит показывает проблему, я не воспринимаю её как готовый диагноз. Я сначала задаю вопрос: что именно здесь сломано и к какому слою это относится?

Такой подход помогает не превращать технический аудит в список страшных красных пунктов.

Хороший SEO-аудит не заканчивается PageSpeed

PageSpeed, Lighthouse и похожие инструменты я бы воспринимал как первый диагностический слой. Они отлично подходят, чтобы быстро найти технические проблемы. Но после этого начинается настоящая работа:

Поисковый запрос → интент → структура → контент → техническая реализация → UX → конкуренты → индексация → аналитика.

Именно поэтому показатель вроде «92% SEO» сам по себе почти ничего не говорит о том, насколько хорошо страница будет работать в поиске.

Инструмент может сказать: «у вас отсутствует такой-то атрибут». Но только человек может задать следующий вопрос: «почему это важно именно для этой страницы и действительно ли это влияет на её поисковую задачу?»

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