Как выбрать точки роста по поисковым отчётам

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

Возьмём знакомые страницы B, C и D и небольшой поисковый отчёт. По нему выберем одну обоснованную гипотезу, определим изменение и способ наблюдения. Результатом станет запись в рабочем журнале, а не обещание определённой позиции: данные помогают поставить вопрос, но не раскрывают все причины поведения поисковой системы и пользователей.

Отчёт и границы данных

Продолжим вымышленный учебный сценарий на https://example.com. B — старый урок «Запросы LINQ to XML», C — статья «Статический сайт из Markdown», D — общий каталог. Все числа ниже придуманы для разбора; это не выгрузка ProfessorWeb, не результаты внедрения и не подтверждение реальной индексации его страниц.

Для самостоятельной работы используется отдельная таблица seo-audit/opportunities-example.csv. Она не заменяет технические наблюдения A–H. В ней заданы период sample_period, источник google, устройство desktop, страна sample_country и признак data_kind=fictional. В настоящей выгрузке сохраняйте действительные значения этих измерений.

URL	Запрос	Показы	Клики	Средняя позиция
B	запросы linq to xml	1200	36	6,8
B	linq xml примеры	400	8	9,2
C	статический сайт из markdown	900	18	7,4
C	markdown в html	500	5	12,6
D	каталог уроков программирования	300	6	5,1

Показ и клик описывают разные события: результат был учтён как показанный, а затем пользователь мог перейти по нему. CTR выражает долю кликов относительно показов. Средняя позиция агрегирует положение результатов в выбранном отчёте и не является постоянным местом страницы. Эти определения приведены в справке об эффективности Google Поиска.

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

CTR как начало исследования

Для первой строки вычислим долю кликов:

CTR = клики / показы × 100%

B: «запросы linq to xml»
36 / 1200 × 100% = 3%

C: «статический сайт из markdown»
18 / 900 × 100% = 2%

Дополняя таблицу таким же расчётом, получим 2% для второго запроса B, 1% для «markdown в html» и 2% для D. Теперь возникает соблазн объявить C самой плохой страницей. Однако CTR относится к определённому запросу и окружению результата. Разные задачи, позиции, конкурирующие результаты и вид выдачи делают прямую оценку «хорошо/плохо» преждевременной.

Рассмотрим запрос «markdown в html». Он может означать желание быстро преобразовать текст, найти библиотеку или понять устройство сборщика. Наша C рассказывает о статическом сайте. Пользователь, которому нужен онлайн-конвертер, может увидеть статью и осознанно выбрать другой результат. Низкая доля переходов тогда объясняется различием задачи, а не обязательно неудачным описанием страницы.

У запроса «статический сайт из markdown» связь с C очевиднее. Если статья действительно объясняет этот процесс, стоит посмотреть, ясно ли название и первый экран сообщают о результате обучения. Пока это кандидат для исследования. Мы ещё не знаем, какой сниппет показан в каждой ситуации, кто находится рядом и насколько полезной оказалась сама статья.

Можно рассчитать суммарный CTR для показанных строк B: 44 клика на 1600 показов дают 2,75%. Для показанных строк C: 23 на 1400 — приблизительно 1,64%. Это взвешенная доля, а не среднее арифметическое двух процентов. Но даже такой аккуратный расчёт описывает только наш небольшой набор строк.

В реальном Search Console часть запросов скрывается ради конфиденциальности, а таблица может не содержать все строки. Кроме того, данные агрегируются по-разному в зависимости от измерения. Поэтому сумма выбранных запросов не обязана совпадать с итогом диаграммы. Группировка и ограничения данных Search Console.

Выбор одной гипотезы

Сравним три направления работы. Для B можно подробнее раскрыть примеры запросов XML. Для C можно уточнить границы материала и описание результата. Для D можно сделать выбор учебного направления понятнее. Ни один вариант пока не считается доказанной причиной роста: требуется сопоставление отчёта и действительного содержимого.

В учебном сценарии выберем C по запросу «статический сайт из markdown». У этой строки достаточно показов, чтобы задуматься о представлении страницы, и понятная связь с её названием. Запрос «markdown в html» сохраним отдельно: сначала выясним его задачу, прежде чем менять всю статью ради этой формулировки.

Хорошая гипотеза связывает наблюдение, предполагаемый механизм и ограниченное действие. Формулировка «у C мало кликов, надо сделать SEO» не объясняет ни изменения, ни критерий проверки. Более точный вариант: «в описании C недостаточно ясно названы исходник, сборка и получаемый HTML; согласуем метаданные и вступление с фактическим учебным результатом».

Обратите внимание на условие «с фактическим результатом». Сначала откройте сам материал и убедитесь, что он содержит обещаемое объяснение. Если в статье нет готового примера, нельзя добавить слова «полный рабочий проект» только для привлекательности. В таком случае гипотеза требует содержательной доработки, а не одного нового метатега.

Занесём подготовленную запись в журнал изменений. Это пример планируемого действия: поле даты оставлено неизвестным, поскольку оно не описывает выполненное внедрение.

change_id,url_id,hypothesis,change,expected_observation,changed_at,rollback
opportunity-C-01,C,Результат урока недостаточно ясно описан,Согласовать title и описание со вступлением,Опубликованный документ точно описывает имеющийся пример,unknown,Вернуть прежнюю редакцию метаданных и вступления

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

Средняя позиция и ожидаемая польза

Средняя позиция 12,6 у второго запроса C часто привлекает внимание как возможность «вывести страницу из второй десятки в первую». Но среднее не сообщает, что каждый пользователь видел её ровно на этом месте. Оно может объединять заметно разные наблюдения. Показатель полезен для отбора, а конкретное действие следует выбирать по задаче читателя и содержимому.

Учитывайте и абсолютное количество показов. Изменение доли переходов для строки с несколькими показами может выглядеть огромным в процентах из-за одного клика. Для большой библиотеки полезно начинать с материалов, где есть понятная потребность, достаточное количество данных и выполнимая редакционная задача. Здесь «достаточно» определяется точностью нужного решения, а не универсальным числом из чужого чеклиста.

Можно оценить чувствительность результата к выбранному допущению. Если при тех же 900 показах доля кликов C составила бы 3%, получилось бы 27 кликов вместо 18. Разница равна девяти. Это арифметический сценарий, а не прогноз: изменение заголовка не фиксирует число показов, позиции и решения пользователей на прежнем уровне.

Такой расчёт помогает сравнивать затраты. Если доработка требует большого исследования и нового учебного проекта, несколько предполагаемых дополнительных кликов не делают её автоматически приоритетной. Возможно, материал важен как вход в целый курс, а его полезность следует оценивать шире. Тогда зафиксируйте эту цель, вместо того чтобы объявлять всю работу доказанной одной формулой CTR.

Наблюдение после изменения

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

Не меняйте одновременно адрес C, содержание, заголовок, всю навигацию и рекламу, если задача — исследовать одну гипотезу. Большое обновление иногда необходимо, но оно затрудняет объяснение причины. В журнале тогда следует записать совокупность изменений, а вывод формулировать соответственно осторожно.

Сравнение до и после само по себе не является строгим экспериментом. За это время могли измениться спрос, состав результатов, новые страницы библиотеки и внешний контекст. Сохранённая B может служить ориентиром для наблюдений, но она не становится идеальной контрольной группой: запросы LINQ и Markdown имеют разные особенности. Не вычитайте изменение B из C механически, будто это доказанная поправка на все внешние факторы.

Для данных Яндекса создавайте отдельный набор. Его правила подсчёта и охват нужно читать в собственном контексте. В частности, в отчётах доступны группировки по запросам и URL, показы и клики. Мониторинг поисковых запросов Яндекса. Числа двух систем не следует складывать в один «CTR сайта» без явного определения такого показателя.

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