Аудит поискового маршрута сайта услуг

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

«ВелоМастер» остаётся учебной моделью. Мы не запускали сайт мастерской, не отправляли обращения и не проверяли его индексирование. Поэтому в таблицах ниже указаны ожидаемые ответы и специально введённые редакционные ошибки, а не результаты реального обхода. Это важно отделить от технического аудита HTTP-ответов, журналов и отчётов поисковых систем.

Сценарий вместо списка всех страниц

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

В первом маршруте человек выбирает диагностику, видит цену 700 ₽, результат осмотра и возможность согласования дальнейшего ремонта. Во втором работа стоит 1200 ₽, товар оплачивается отдельно, а кейс LAB-041 показывает конкретную комбинацию 2490 ₽. В третьем требуется различить приём в Речном и выполнение замены в Центре.

Маршрут	Переход	Ожидаемое содержание	Учебный разрыв
Неизвестный шум	Список услуг → диагностика	Осмотр, 700 ₽, ремонт отдельно	Кнопка обещает немедленный ремонт
Замена цепи	Услуга → запись	1200 ₽ работа, деталь отдельно	Форма теряет отдельную оплату детали
Речной пункт	Филиал → замена	Приём здесь, работа в Центре	Заголовок обещает замену на месте
Пример заказа	Кейс → услуга	2490 ₽ только для LAB-041	Кейс подменяет общий прайс

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

Разделить содержание и техническую доступность

Содержательный маршрут отвечает на вопрос «понятно ли предложение». Технический — «можно ли получить документ и перейти по связи». Поисковый — «видит ли система подходящую опубликованную страницу». У этих уровней разные наблюдения. Открытый HTML сам по себе не доказывает полезность, а согласованный текст не доказывает индексацию.

В учебном отчёте дадим каждому уровню отдельный статус. Это описание будущей работы, а не результат выполненных проверок:

{
  "route": "river-chain-replacement",
  "editorial_state": "Условия приёма и выполнения разделены в ожидаемой версии",
  "http_state": "not_checked",
  "form_submission": "not_implemented",
  "search_index": "not_observed",
  "traffic_result": "not_measured"
}

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

Для технических ссылок Google рекомендует понятные элементы a с href. Применительно к нашему маршруту это значит, что страницы услуг и филиалов должны иметь обычные связи внутри сайта. Содержание текста ссылки остаётся отдельной редакционной задачей: «условия передачи через Речной» яснее, чем «подробнее». Рекомендации Google по ссылкам.

Не нужно выводить из аудита требование менять постоянные адреса. Страница замены цепи сохраняет /services/chain-replacement/, даже если её вводный абзац стал точнее. Если адрес уже используется, содержательная правка обычно не требует миграции. В рамках курса учебные URL ещё не опубликованы, но мы заранее приучаемся отделять изменение текста от изменения идентичности документа.

Приоритет по последствиям ошибки

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

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

Полезно записывать исходный текст и ожидаемую замену рядом. Например: «Замена в Речном сегодня» становится «Приём в Речном, выполнение в Центре после согласования». Мы не обещаем сегодня, поскольку данных о загрузке нет. При последующем чтении другой редактор сможет понять причину правки, а не просто увидеть новую фразу.

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

Последний проход выполняйте с изменённым условием: собственная цепь клиента вместо покупки VM-C9. Работа остаётся 1200 ₽, а итог LAB-041 больше не описывает этот заказ. Если маршрут продолжает обещать 2490 ₽, обнаружен перенос частного примера в общее предложение. Такая смена условия полезнее механического чтения одного идеального сценария.

Граница повторного просмотра

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

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

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