Белое SEO

Происхождение и история термина

Разделение полезной оптимизации и поисковых манипуляций складывалось вместе с публичными правилами для владельцев сайтов. Google сообщает, что выпустил Webmaster Guidelines в 2002 году: рекомендации объясняли, как создавать сайты для посетителей из поиска. ^[7] Это веха развития подхода, а не дата изобретения выражения white hat SEO.

В апреле 2012 года инженер Google Мэтт Каттс уже использовал этот термин в официальном объяснении борьбы с вебспамом. Он противопоставлял улучшение сайта попыткам добиться незаслуженно высокого места: например, чрезмерному повторению ключевых слов и манипуляциям ссылками. В его описании добросовестный специалист помогает поиску находить страницы, а людям — понимать их содержание. ^[6]

В октябре 2022 года Google переименовал руководство в Search Essentials и разделил материал на технические требования, правила против спама и основные рекомендации. При обновлении добавились более конкретные примеры нарушений. ^[7] Так принцип полезной оптимизации получил более подробное практическое выражение: общую этическую установку можно сопоставлять с опубликованными условиями поисковика. Дата первого употребления термина этими документами не установлена.

Суть и механизм

SEO расшифровывается как Search Engine Optimization — поисковая оптимизация. ^[6] Чтобы понять её задачи, удобно проследить путь от страницы к читателю.

Сначала поисковая система должна получить содержание. Поисковый робот — программа, которая переходит по ссылкам для последующего индексирования, то есть подготовки материала к поиску. Файл robots.txt сообщает роботам правила обхода. ^[4] На этом этапе проверяют, не мешают ли собственные настройки сайта доступу к нужным материалам.

Затем нужно ясно представить тему. Google рекомендует использовать слова читателей в заголовках и других описательных элементах, а ссылки делать доступными роботу. ^[1] Например, в учебной задаче заголовок «Как выбрать размер велосипеда» понятнее посетителю, чем внутреннее название товара «Модель серии Б». Решение состоит в точном описании содержания, а не в накоплении повторов запроса.

После перехода человеку нужен ответ и понятный следующий шаг. Яндекс связывает качество сайта с самостоятельной ценностью содержания и соответствием ожиданиям посетителя. ^[2] Поэтому в нашем примере одной замены заголовка недостаточно: страница должна действительно объяснять выбор размера.

Навигацию можно проверять по отдельному ориентиру. Консорциум W3C в руководстве по доступности веб-контента WCAG 2.2 требует, чтобы назначение ссылки определялось из её текста либо из текста вместе с программно связанным контекстом; предусмотрено исключение для случаев, неоднозначных для пользователей вообще. ^[5] Это критерий доступности интерфейса, а не формула поискового ранжирования — порядка страниц в результатах поиска.

Виды и классификации

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

Белый и чёрный подходы различаются целью и способом действий. В историческом объяснении Google чёрный вебспам ищет обходные способы поднять позиции без пользы для пользователя. ^[6] Поэтому наличие технических работ в договоре само по себе ещё не описывает стратегию целиком.

Как применяется на практике

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

Учебный пример. Магазин разместил руководство по выбору велосипеда. Посетитель видит нужный заголовок, но ссылки на таблицы размеров ведут к удалённым страницам, а оставшиеся подписаны одинаково: «Здесь». Команда сохраняет список из 100 проверяемых переходов и обнаруживает 10 ошибочных.

Разработчик исправляет восемь адресов. Редактор меняет подписи на «Таблица размеров детских велосипедов» и «Таблица размеров взрослых велосипедов», затем сверяет названия с содержанием страниц. Такая работа следует принципу понятного назначения ссылки из WCAG. ^[5] Причина исправления ясна: человек не мог получить обещанную информацию. Непосредственный результат тоже проверяем: восемь переходов теперь ведут к нужным материалам. Две оставшиеся ошибки команда фиксирует как незавершённые задачи, а не скрывает за общей оценкой качества.

Как измерить или проверить

В учебном примере доля ошибочных переходов — число ошибок, делённое на число проверенных переходов, умноженное на 100%. До правки получаем 10 / 100 × 100% = 10%, после — 2 / 100 × 100% = 2%. Снижение составляет 8 процентных пунктов. Если выражать его относительно исходной доли, получим 80%: восемь устранённых ошибок из десяти. Это два способа описать один результат, а не разные достижения.

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

Для автоматической диагностики страницы подходит Lighthouse. Инструмент проверяет, среди прочего, производительность, доступность и SEO, затем формирует отчёт с объяснениями находок. ^[3] Практический порядок работы — изучить конкретную неудачную проверку, исправить причину и повторить её. Это полезнее, чем записать один итоговый балл без перечня изменений.

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

Ошибки, ограничения и спорные вопросы

Обещание первого места подменяет контролируемую работу неконтролируемым результатом: Google прямо не гарантирует даже обход и индексирование при выполнении своих условий. ^[1] Аналогично высокий балл автоматического отчёта относится к выполненным проверкам страницы, а не служит сертификатом всей стратегии. ^[3]

Другая ошибка — искать разрешение в молчании правил. Яндекс предупреждает: отсутствие способа искусственного влияния в перечне нарушений не означает, что он допустим. ^[2] Для спорного действия полезно записать, какую задачу посетителя оно решает и что именно меняет на сайте.

Наконец, robots.txt управляет взаимодействием с роботами, но не защищает закрытые данные. RFC 9309 прямо отделяет этот протокол от авторизации доступа. ^[4] Если в задании смешаны поисковая оптимизация и защита информации, результаты этих работ нужно проверять отдельно.

Частые вопросы

Связанные термины

• seo
• chernoe-seo
• indeksatsiya
• robots-txt
• perespam
• skorost-zagruzki-sayta