Техническое SEO: доступы, требования и проверка релиза

Что подготовить до технического SEO

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

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

Инвентаризация страниц и владельцев

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

Составьте контрольную выборку URL: типовой адрес, новый, изменённый, удалённый, параметризованный и ошибочный. Добавьте несколько глубоких страниц, до которых трудно добраться из меню. Зафиксируйте ответы сервера, canonical, robots, заголовок, основной текст и путь внутренних ссылок. Этот набор станет основой сравнения до и после релиза.

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

Доступы и исходные измерения

Нужны доступные владельцу проекта данные поисковых кабинетов, аналитика, sitemap, robots.txt, история переездов и сведения о публикации. Логи сервера полезны, если нужно изучить фактические обращения роботов; они не заменяют данные об индексации. Передавайте доступы через штатные роли. Не публикуйте пароли, токены и выгрузки с персональными данными в общем документе ТЗ.

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

Разработчику нужен способ воспроизвести проблему: адрес, устройство, состояние авторизации, запрос и фактический ответ. Скриншот без URL и времени проверки недостаточен. Для динамического сайта отдельно проверьте исходный HTML и результат выполнения JavaScript. Важные сведения должны присутствовать в том виде страницы, который действительно получает поисковая система, с учётом возможностей конкретного робота.

Обход, индексация и канонические адреса

Разделяйте три вопроса: может ли робот запросить URL, можно ли индексировать страницу и какой адрес предпочтителен для дублей. robots.txt управляет обходом и не является средством защиты секретных данных. Запрет обхода также может помешать роботу увидеть указание noindex на странице. Правило для каждого класса URL следует проверять целиком, а не включать несколько запретов на всякий случай.

Укажите, какие варианты адреса должны перенаправляться: протокол, домен, регистр, завершающий слеш и устаревшие пути. Canonical — сигнал о предпочтительном адресе среди сходных страниц, а не способ скрыть любую нежелательную страницу. Google рекомендует согласовывать канонические сигналы; внутренние ссылки, sitemap и перенаправления не должны противоречить выбранному основному URL.

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

Требования к шаблонам и внутренним ссылкам

Для каждого индексируемого шаблона задайте источник title, description, H1, canonical и основного текста. Правила должны учитывать отсутствие данных и предельную длину фактического значения. Уникальность не достигается механической перестановкой одинаковых слов. Заголовок должен описывать содержание страницы, а description — помогать понять, что на ней можно получить.

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

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

Производительность как проверяемое требование

Фраза «сайт должен быть быстрым» не даёт критерия приёмки. Зафиксируйте шаблоны, устройства, сеть, инструменты и условия измерения. Лабораторная проверка помогает находить причины, а данные реальных посещений — оценивать опыт аудитории. Не сравнивайте результаты разных режимов так, будто это одно измерение, и не делайте вывод по единственному удачному прогону.

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

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

Как записать задачу разработчику

Пример: «Для опубликованной статьи без параметров сервер отдаёт HTTP 200, canonical указывает на её постоянный HTTPS-адрес, в HTML нет noindex, URL присутствует в sitemap и доступен по внутренней ссылке». Дополните пример реальным адресом, шаблоном и ожидаемым поведением черновика. Это конкретнее формулировки «исправить индексацию блога».

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

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

Приёмка релиза и наблюдение после него

Перед переключением проверьте стенд, карту редиректов, критические шаблоны и возможность отката. После выкладки повторите проверки на публичном домене: настройки прокси и окружения способны изменить заголовки и адреса. Сверьте sitemap, robots.txt, канонические ссылки и основные пользовательские действия. Не ограничивайтесь тем, что сборка завершилась без ошибки.

Дальнейший контроль разделите по срокам. Доступность и ответы сервера проверяются сразу, а переобход и изменение поисковых показателей требуют наблюдения. В отчёте различайте «исправление развернуто», «робот посетил страницу» и «страница появилась в индексе». Это три разных факта. Отсутствие мгновенного роста трафика не доказывает технический провал, как и рост не доказывает единственную причину.

Шаблон ТЗ в приложении содержит реестр типов страниц, доступов, дефектов и контрольных URL. Заполните его перед оценкой работ и сохраняйте версии после каждого релиза. Достаточный результат подготовки — понятный список изменений с зависимостями и доказательствами приёмки. Такой документ помогает последовательно устранять препятствия, сохраняя рабочий сайт и его полезное содержание.