SEO как инженерный эксперимент: как отделять гипотезу, наблюдение и причинность

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

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

Гипотеза — это ещё не результат

В разработке предположение не становится доказанным только потому, что выглядит логичным. Сначала появляется гипотеза, затем способ её проверить, и только потом — данные.

То же правило полезно применять к SEO.

Допустим, мы предполагаем:

Если на слабую страницу начнут ссылаться более сильные тематические доноры, её поисковая видимость может измениться.

Это гипотеза.

Она может быть разумной, опираться на прошлый опыт или совпадать с результатами других проектов. Но до появления собственных наблюдений она всё равно остаётся предположением.

Поэтому формулировать гипотезу лучше так, чтобы позже было понятно, что именно мы собирались измерять.

Слабый вариант:

Хорошие ссылки гарантированно выведут страницу в топ.

Более полезный вариант:

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

Вторая формулировка не объявляет победителя до начала эксперимента и сразу задаёт набор необходимых данных.

Сначала нужно знать состояние системы

Представим, что разработчик оптимизировал сервис и после изменений время ответа составляет 200 миллисекунд.

Хорошо это или плохо?

Без предыдущего значения ответить невозможно.

Если раньше было 900 миллисекунд — результат заметный. Если 120 — система стала медленнее.

В SEO действует та же логика.

Перед началом активных изменений у целевой страницы полезно сохранить исходное состояние:

• • URL;
  • дату и время замера;
  • Title;
  • H1;
  • основную версию текста;
  • состояние индексации;
  • позицию по целевому запросу;
  • показы и клики;
  • число ссылающихся доменов;
  • известные бэклинки;
  • выбранные внешние ссылочные метрики;
  • основные внутренние ссылки.

Такой снимок можно рассматривать как baseline — исходное состояние системы перед экспериментом.

Без него последующий график способен показать изменение, но не показывает, откуда оно началось.

Изменение без логирования трудно нормально объяснить

Представим другой инженерный сценарий.

В приложение одновременно внесли три изменения:

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

После релиза производительность выросла.

Какое из трёх изменений дало эффект?

Без дополнительных данных ответить сложно.

В SEO происходит нечто похожее.

За несколько дней можно:

• получить новые внешние ссылки;
• изменить Title;
• добавить новые разделы;
• перестроить внутреннюю перелинковку;
• дождаться переиндексации;
• увидеть движение позиции.

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

Поставили ссылки — позиции выросли.

Но реальная последовательность могла быть намного сложнее.

Поэтому журнал изменений в SEO выполняет примерно ту же функцию, что changelog в разработке.

Как может выглядеть простой SEO-changelog

Журнал не обязан быть сложным.

Гораздо важнее другое: значимые события не должны исчезать из истории эксперимента.

Ссылка появилась — это факт. «Ссылка сработала» — уже вывод

Для анализа удобно разделять четыре уровня.

1. Событие

На внешней странице появилась ссылка.

2. Наблюдение

Через некоторое время изменилась позиция акцептора.

3. Временная связь

Изменение позиции произошло после появления ссылки.

4. Причинное объяснение

Именно эта ссылка стала причиной изменения.

Первые три уровня сравнительно легко зафиксировать.

С четвёртым всё сложнее.

Если два события произошли последовательно, это ещё не означает, что первое автоматически вызвало второе.

Такая осторожность не делает эксперимент менее полезным. Наоборот, она позволяет отделить данные от истории, которую мы хотели бы увидеть.

Почему в SEO трудно изменить только одну переменную

Идеальный эксперимент выглядит просто:

одна система → одна переменная → два состояния → сравнение.

В поиске такую чистоту получить трудно.

Причина в том, что часть системы находится вне нашего контроля.

За время эксперимента способны измениться:

• конкуренты;
• состояние поисковой выдачи;
• индексация;
• внутренние ссылки;
• содержание акцептора;
• страницы-доноры;
• другие внешние ссылки;
• возраст самой страницы.

Поэтому цель — не притворяться, будто лишних переменных нет.

Полезнее сделать известные изменения видимыми.

Если одновременно со ссылкой изменился H1 — это нужно записать.

Если статья две недели оставалась без изменений — это тоже стоит знать.

Изменения не обязательно запрещать — их нужно фиксировать

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

Но это не всегда разумно.

Представим, что обнаружилась реальная ошибка:

• некорректный факт;
• сломанная внутренняя ссылка;
• непонятный фрагмент текста;
• ошибка в метаданных.

Оставлять проблему только ради эксперимента странно.

Более практичная логика:

изменение можно внести, но его нужно записать.

Например:

20 августа
Изменён Title.
Причина: старый вариант слишком общий.

22 августа
Добавлена внешняя ссылка с нового донора.

24 августа
Зафиксирована переиндексация целевой страницы.

После этого финальный результат можно анализировать с учётом реальной истории, а не вымышленной стабильности.

Страницу можно версионировать почти как программный продукт

У приложения есть релизы и версии. У экспериментального документа тоже фактически появляются разные состояния.

Это особенно заметно, если статья развивается по ходу наблюдений.

Условно можно представить историю так:

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

Но внутри проекта полезно знать, какая версия страницы существовала в момент конкретного замера.

Для внешних ссылок нужен отдельный лог

Похожую историю можно вести для ссылочных событий.

Для каждого размещения достаточно фиксировать:

• домен;
• URL страницы-донора;
• URL акцептора;
• анкор;
• дату публикации;
• дату индексации;
• роль размещения;
• дату следующего замера.

После этого вместо фразы:

Мы получили несколько ссылок с PBN.

появляется конкретная последовательность событий.

Это особенно полезно для управляемой сетки, где участник сам контролирует большую часть параметров размещения.

Метрика должна отвечать на конкретный вопрос

Одна из типичных ошибок аналитики — искать универсальную цифру, которая якобы покажет весь результат сразу.

Но разные показатели описывают разные свойства системы.

Поэтому изменение одной метрики не следует автоматически переводить на язык другой.

Например, рост стороннего рейтинга домена можно фиксировать как изменение внешней метрики. Но сам по себе он ещё не отвечает на вопрос о том, насколько изменилась оценка страницы внутри Google.

Нулевой результат тоже нужно сохранять

Иногда самые неудобные данные оказываются самыми полезными.

Представим:

ссылка опубликована → страница проиндексирована → прошло десять дней → заметного изменения позиции нет.

Это полноценный результат наблюдения.

Он не доказывает, что ссылка «бесполезна».

Но удалять его из истории только потому, что он не поддерживает желаемую гипотезу, нельзя.

Нормальный журнал должен хранить:

• рост;
• падение;
• отсутствие заметной динамики;
• проблемы с индексацией;
• неожиданные изменения;
• события, которые противоречат исходному предположению.

Иначе финальный кейс превращается не в эксперимент, а в подборку удачных моментов.

Положительный результат тоже полезно пытаться опровергнуть

Это привычная инженерная дисциплина.

Если результат оказался именно таким, как ожидалось, возникает соблазн сразу завершить анализ.

Допустим:

После третьего ссылочного этапа позиция заметно улучшилась.

Вместо мгновенного вывода стоит проверить:

• менялся ли сам акцептор;
• появились ли другие внешние ссылки;
• изменилась ли индексация;
• что происходило с конкурентами;
• сохранился ли эффект через следующие замеры;
• повторялось ли похожее движение после других этапов.

Чем лучше результат выдерживает альтернативные объяснения, тем интереснее становится исходная гипотеза.

Повторяющийся паттерн интереснее одного скачка

Единичное движение позиции может оказаться кратковременным.

Значительно интереснее последовательность:

изменение → наблюдение → новое изменение → похожее наблюдение → повторение.

Например:

1. после первого этапа появляется положительная поисковая динамика;
2. после второго одновременно изменяются внешние ссылочные показатели;
3. после третьего движение сохраняется;
4. изменения самой страницы при этом задокументированы.

Такой результат всё ещё не превращает SEO в лабораторный эксперимент.

Но один случай постепенно становится наблюдаемым паттерном.

Можно ли использовать контрольную группу

В идеальном тесте хотелось бы иметь второй максимально похожий объект, на который воздействие не оказывается.

Тогда сравнение выглядело бы так:

экспериментальный объект ↔ контрольный объект.

В SEO это сложно.

Даже две внешне похожие страницы отличаются:

• доменом;
• историей;
• внутренним окружением;
• ссылками;
• возрастом;
• индексацией;
• конкурентной выдачей.

Поэтому отсутствие идеальной контрольной группы не делает наблюдение бессмысленным.

Но оно ограничивает силу причинных выводов.

И это ограничение полезнее указать прямо, чем скрывать его за уверенной формулировкой.

Как не подгонять критерии после получения результата

Один из самых простых способов — определить правила заранее.

До запуска можно записать:

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

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

Особенно важно сохранить отрицательные сценарии. Если гипотеза не подтверждается, это тоже часть эксперимента.

При чём здесь GEO и ответы нейросетей

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

Сначала определяется базовый набор вопросов.

Например:

• что означает исследуемый термин;
• с чем он связан;
• кто связан с его происхождением;
• существует ли практический эксперимент;
• известны ли его результаты.

Затем для каждого замера сохраняются:

• дата;
• система;
• точная формулировка запроса;
• полученный ответ;
• наличие сущности;
• корректность объяснения;
• наличие источника.

Это не гарантирует появления нужного ответа.

Но вместо абстрактной цели «хотим попасть в нейросети» появляется наблюдаемая процедура.

Упоминание сущности и ссылка на источник — разные события

В GEO-наблюдении тоже полезно разделять уровни.

1. Термин не появляется.
2. Термин появляется без понятного объяснения.
3. Система даёт корректное базовое определение.
4. В ответе присутствуют нужные связанные сущности.
5. Система показывает источники.
6. Среди источников появляется целевая страница.

Это разные результаты.

Поэтому простая отметка «ИИ знает термин — да/нет» теряет много информации.

Финальный отчёт должен показывать историю, а не только результат

В конце эксперимента удобно разделить отчёт на четыре вопроса.

Что произошло?

Фактические изменения позиций, ссылок и других показателей.

Что совпало с гипотезой?

Наблюдения, которые соответствуют первоначальному ожиданию.

Что не совпало?

Отрицательные и неожиданные результаты.

Что осталось недоказанным?

Причинные или универсальные выводы, для которых одного эксперимента недостаточно.

Последний блок не ослабляет кейс.

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

Минимальная инженерная схема SEO-эксперимента

Если убрать детали, останется достаточно простой процесс:

Гипотеза
↓
Исходное состояние
↓
Изменение
↓
Лог событий
↓
Наблюдение
↓
Повторный замер
↓
Интерпретация
↓
Ограничения

По сути, это обычная работа со строгой системой, ведение которой честно объясняет одну переменную.

Вывод

SEO-эксперимент становится намного полезнее, когда его перестают воспринимать как поиск одного удачного скриншота.

Инженерная логика требует нескольких простых вещей:

зафиксировать старт → зафиксировать изменения → исследовать эти данные → сохранить неудобные результаты → отделять наблюдение от причинного результата.

Эта схема не допускает неопределенности поисковой системы.

Она делает неопределенность видимой.

После этого можно сказать не только «позиция выросла», но и объяснить:

что сердце до роста, какие события ему предшествовали, что мне было одновременно и официально далеко позволяют зайти выводы.

В этом смысле хорошие SEO-ключи гораздо ближе к журналу инженерного эксперимента, чем к рекламному отчёту.

Источники и дополнительные материалы

• Sape — условия конкурсного SEO-эксперимента
  
• Центральный материал и журнал результатов эксперимента