Как проверить SEO страницы и составить список исправлений

Проверка SEO страницы должна заканчиваться списком воспроизводимых проблем — для каждой нужны адрес, наблюдение, возможное последствие и способ проверить исправление

Отчёт на десятки страниц может выглядеть убедительно и всё равно не помогать работе — особенно если в нём одинаковым красным цветом отмечены недоступная страница и длинное описание

Начнём с одного URL — так проще отделить фактическую ошибку от предположения и понять, кому передать задачу

Зафиксируйте объект проверки

Запишите полный адрес, дату, устройство и сценарий — например, «страница ремонта кофемашин, посетитель хочет узнать условия передачи аппарата»

Параметры, другой протокол или поддомен могут привести на иную версию страницы — проверка главной не подтверждает доступность нужной услуги

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

Уточните и цель проверки: найти причину отсутствия в поиске, подготовить выпуск или оценить содержание — для этих задач понадобится разная глубина диагностики

Сначала проверьте доступность и индексирование

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

В кабинете поисковика проверьте именно нужный URL — статус в индексе и возможность получить текущую страницу относятся к разным проверкам

Для Google используйте проверку URL в Search Console, для Яндекса — инструменты индексирования и ответа сервера — сохраните результат с датой, а не только зелёный значок в пересказе

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

Google описывает действие запрета в документации noindex — Яндекс отдельно предупреждает, что доступность для индексирования не равна участию в поиске Анализ индексации страницы

Проверьте, на какой адрес указывает canonical

Canonical сообщает предпочтительный адрес среди одинаковых или похожих страниц — в отчёте важно записать его фактическое значение, а не просто наличие тега

Учебная ситуация: проверяем страницу «Ремонт кофемашин», а в canonical осталась ссылка на старый шаблон «Ремонт чайников» — тег есть, но он указывает не туда, куда ожидала команда

Это основание проверить шаблон и выбранную основную версию, а не автоматически ставить всем страницам один и тот же canonical

У Google выбор канонической страницы не сводится к одной директиве — детали приведены в документации по объединению дублей

Где взять noindex, canonical и код ответа

Ниже — маршрут для Chrome на компьютере — он позволяет посмотреть данные, не меняя код сайта

1 — Посмотрите HTML, который получил браузер

Откройте нужный URL и через контекстное меню выберите просмотр исходного кода страницы — в поиске по тексту найдите name="robots", noindex и rel="canonical"

В учебном примере в исходном HTML могли оказаться такие строки

<meta name="robots" content="noindex">
<link rel="canonical" href="https://example.test/services/repair/">

Первая строка содержит запрет индексирования, вторая — адрес предпочтительной версии — перепишите значения в журнал целиком, а затем сравните с назначением и ожидаемым URL страницы

Это пример для распознавания, его не нужно вставлять в свой сайт — домен example.test здесь условный

Если строка не найдена, записывайте «не обнаружено в исходном HTML» — это ещё не проверка заголовков ответа и не доказательство отсутствия всех ограничений

2 — Посмотрите ответ основного документа

Откройте инструменты разработчика через меню браузера, перейдите во вкладку Network — «Сеть» — и обновите страницу при открытой панели

Выберите запрос основного HTML-документа — не изображение, шрифт или файл аналитики — в Headers посмотрите Request URL, Status Code и Response Headers

Если адрес перенаправляется, включите Preserve log перед повторной загрузкой, чтобы не потерять переходы — в журнале нужны и исходный, и конечный адрес

Найдите X-Robots-Tag в заголовках ответа — запрет может приходить здесь, даже когда его нет в HTML

Request URL: https://example.test/services/repair/
Status Code: 200 OK
Response Headers:
X-Robots-Tag: noindex

В таком учебном ответе сервер успешно отдал страницу, но отдельно сообщил запрет индексирования — код200 не отменяет noindex

Расположение данных и сохранение запросов описаны в справке Chrome DevTools Network

3 — Сопоставьте результат с кабинетом поисковика

В Google Search Console вставьте полный URL в верхнюю строку проверки — сначала прочитайте сведения об известной Google версии, затем при необходимости запустите проверку страницы на сайте

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

Выбранный Google canonical нужно смотреть в данных индекса — live-тест не предсказывает этот выбор Справка проверки URL

Для Яндекса точный маршрут и разделение инструментов описаны в диагностике индексации

Когда самостоятельной проверки недостаточно

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

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

Не публикуйте полный сетевой журнал своего личного кабинета — для задачи обычно достаточно нужного URL, кода и относящихся к нему заголовков без cookies и токенов

Посмотрите на содержание глазами покупателя

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

Title, H1 и описание должны относиться к той же задаче, которую решает страница — наличие нужной фразы не спасает текст о другом продукте

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

Подготовка таких ответов разобрана в плане оптимизации страницы — в аудите достаточно показать конкретный пропуск и назвать источник недостающих сведений

Пройдите один путь до результата

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

Если форма подключена, тестируйте её по согласованному тестовому сценарию с владельцем — не отправляйте случайные или чужие персональные данные

Проверьте и ошибку: человек должен понимать, что пошло не так и что он может сделать дальше — сообщение «успешно» при недоставленном запросе не подтверждает исправность формы

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

Запишите находки так, чтобы их могли исправить

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

Последняя строка отличается от первых — предупреждение сервиса нужно сначала оценить по смыслу, а не механически сокращать название до заданного количества знаков

В каждом замечании приложите доказательство: строку ответа сервера, значение тега, снимок блока или точные действия — формулировка «SEO плохое» не позволяет повторить проверку

Назначьте порядок работ

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

Приоритет меняется по ситуации — например, неработающая форма важна для бизнеса даже у страницы, которая уже хорошо находится в поиске

Не складывайте число предупреждений разных проверяющих сервисов в общий «процент плохого SEO» — они могут проверять одно и то же разными правилами

Как прочитать противоречивый отчёт сервиса

Предположим, один проверяющий инструмент ставит странице высокий балл, а другой показывает ошибки — сначала сравните, что именно они проверяли

Один мог анализировать исходный HTML, другой — страницу после выполнения JavaScript — также могут различаться адрес, устройство, дата, настройки доступа и правила оценки

Для каждого спорного пункта задайте два вопроса: какое наблюдение стоит за предупреждением и мешает ли оно задаче этой страницы

Например, отсутствие разметки товара у статьи об обслуживании техники не означает, что нужно срочно добавить Product — сначала определите, что действительно представляет собой страница

А вот ссылка на недоступный документ остаётся воспроизводимой проблемой независимо от общего балла — её можно открыть и проверить без спора о шкале инструмента

Что делать после исправлений

Повторите именно проваленный сценарий, затем соседние действия — исправление ссылки не должно сломать доступ к другим документам

Сохраните результат проверки и дату выпуска — изменения индекса могут появиться позже, поэтому статус «исправлено в коде» и статус «поисковик переобошёл» держите отдельно

Если основная проблема остаётся в Яндексе, продолжите диагностику по статусу конкретного URL

При обновлении существующего сайта используйте план сохранения поисковых адресов при редизайне — этот аудит не заменяет карту перенаправлений

Скачать журнал SEO-проверки — с заполненным замечанием и пустыми строками для своего сайта

Самопроверка отчёта

Отметьте, что уже есть в вашем журнале — это проверка полноты задания, не оценка вероятности попадания в топ

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

Источники проверены 30 октября 2026 года — журнал и приоритеты учебного примера подготовлены редакцией KEIVO