SEO при разработке сайта стоит превратить в набор требований, которые можно проверить до запуска. У каждой важной страницы должен быть устойчивый адрес, понятное содержание, управляемые метаданные и доступный путь из других разделов. Поисковый робот должен получать рабочую страницу, а посетитель — пользоваться ею на телефоне без ожидания тяжёлых ресурсов и сломанного интерфейса.
Фраза «сайт готов к SEO» сама по себе не описывает результат. Наличие тегов, карты сайта и разрешения на индексацию не гарантирует ни попадания всех страниц в поиск, ни высоких позиций. Ниже — что согласовать с разработчиком заранее и какие подтверждения запросить при приёмке.
Зафиксируйте границы SEO-основы ещё в задании
В начале проекта разделите три вида работ: разработку возможностей сайта, подготовку содержания и дальнейшее продвижение. Для каждого результата назначьте ответственного. Разработчик может сделать редактор страниц и шаблоны метаданных; сведения об услугах, реальные фотографии и условия работы должен предоставить или подтвердить бизнес. Исследование спроса и регулярная работа с поисковым трафиком требуют отдельного согласованного объёма.
При заказе разработки сайта под ключ попросите включить в задание конкретный перечень SEO-требований и способ их приёмки. Не считайте автоматически включёнными сбор запросов, написание всех текстов или продвижение после запуска: состав работ нужно закрепить.
До прототипа полезно согласовать:
- какие услуги, категории и другие предложения получат самостоятельные страницы;
- какие типы страниц должны быть доступны в поиске;
- кто подготовит тексты, изображения и метаданные к запуску;
- кто сможет обновлять их после передачи сайта;
- на каких заполненных страницах и устройствах будут проверять результат.
Если ещё непонятно, какие запросы относятся к одной странице, начните с связи семантического ядра со структурой сайта. Разработка должна опираться на согласованную карту страниц, иначе технически исправный сайт может не иметь нужного раздела для конкретного предложения.
Продумайте адреса и состояния страниц
Для каждой публичной страницы нужен собственный адрес, который можно открыть напрямую, сохранить и передать другому человеку. Переход из меню и открытие этого же адреса в новой вкладке должны показывать одинаковое содержание. Важное предложение не стоит оставлять только во всплывающем окне без самостоятельной страницы.
Согласуйте правила URL: основной домен и HTTPS, единый регистр, разделители слов, завершающий слеш. Конкретное написание выбирают под структуру проекта; важна последовательность. Изменение названия услуги в редакторе не должно незаметно менять её адрес.
Удобство каталога тоже влияет на адреса. Сортировка, фильтры, поиск и метки рекламных переходов могут создавать много вариантов одной страницы. До разработки определите, какие подборки имеют самостоятельную пользу и содержание, а какие являются служебными вариантами. Не открывайте для поиска все сочетания фильтров по умолчанию.
Canonical сообщает поисковой системе предпочтительный адрес среди дублей или очень похожих страниц. Это сигнал, а не безусловная команда. Он не исправляет различающееся содержание и не должен отправлять все услуги на главную. Внутренние ссылки, карта сайта и canonical должны поддерживать один выбранный адрес.
Отдельно заложите поведение при изменениях. Для постоянного переезда страницы с подходящей заменой нужен постоянный редирект, например 301, на конкретный новый адрес. Для несуществующей страницы — корректный ответ 404, а не сообщение «ничего не найдено» с успешным кодом 200. Все удалённые адреса нельзя механически отправлять на главную.
Что принять: открыть основной адрес, его альтернативный вариант, страницу после изменения адреса и заведомо несуществующий путь. Исполнитель показывает конечные адреса и коды ответа; рабочие страницы возвращают 200, редиректы не образуют цепочек и циклов.
Сделайте метаданные управляемыми, а заголовки — содержательными
У разных страниц должны различаться название в title, описание в description и видимый основной заголовок H1. Они описывают конкретное содержание, а не повторяют список поисковых фраз. Заголовок страницы услуги должен помогать посетителю понять предложение.
В системе управления предусмотрите отдельное редактирование этих полей. Для массового каталога допустимы осмысленные шаблоны на основе данных товара, но редактору нужна возможность исправить исключение. Проверьте, что пустое поле не превращается в одинаковое «Главная» на всём сайте.
Приёмка касается опубликованной страницы: сохранённый текст должен попадать в её код. Красивый предпросмотр в CMS этого не доказывает. Google может выбрать другое название результата или сформировать описание из текста страницы; точное отображение заданного сниппета нельзя обещать.
Учебный пример. У мастерской есть отдельная услуга ремонта кофемашин. H1 «Ремонт кофемашин» и title «Ремонт кофемашин — название мастерской» описывают её точнее, чем «Главная — лучший сервис». Описание следует составить из подтверждённых условий приёма и работы, без выдуманных сроков и гарантий.
Что принять: изменить метаданные одной тестовой страницы через CMS и проверить результат на ней, затем убедиться, что соседняя страница сохранила собственные значения.
Разделите обнаружение, обход и индексацию
Роботу нужно найти адрес, загрузить страницу и обработать её содержание. Разрешение на обход ещё не означает включение в индекс, а включение в индекс — показ по нужному запросу.
До запуска составьте правила для типов страниц. Услуги, подготовленные категории и полезные материалы обычно планируют для поиска. Для внутреннего поиска, технических результатов операций и других служебных страниц решение принимают отдельно. Личный кабинет и непубличные данные должны быть защищены доступом, независимо от SEO-настроек.
Не смешивайте разные инструменты:
robots.txtуправляет обходом. Запрет в нём не является надёжным способом удалить страницу из поиска.noindexв метатеге или HTTP-заголовке запрещает индексацию поддерживающей его поисковой системе. Робот должен иметь возможность загрузить страницу и прочитать это указание.sitemap.xmlсообщает о важных адресах. Наличие страницы в карте не гарантирует её обход и индексацию.
Эти различия действуют и для Google, и для Яндекса. Не закрывайте одновременно страницу от обхода и рассчитывайте, что робот обнаружит на ней новый noindex. И не используйте robots.txt как защиту персональных данных или тестовой среды: закрытый стенд лучше ограничить авторизацией.
Для запуска подготовьте отдельную конфигурацию публичного сайта. После переноса проверьте, что на нужных страницах не остались запреты тестового стенда, а карта сайта содержит рабочие основные адреса без черновиков, служебных результатов и перенаправлений.
Что принять: перечень правил по типам страниц и проверку фактических ответов публичного сервера. После открытия сайта — проверку важных адресов в Яндекс Вебмастере и Google Search Console. Возможность загрузки и индексационные указания можно проверить сразу; фактическое включение нового сайта в индекс не является мгновенным критерием сдачи.
Робот должен получать содержание, даже если интерфейс использует JavaScript
Для страниц, рассчитанных на поиск, в задании стоит требовать доступный основной текст, заголовки и ссылки. Практичный вариант — отдавать их в исходном HTML. Если используется клиентский рендеринг, нужно отдельно проверить, что поисковая система видит нужное содержание после обработки страницы.
Не подгружайте ключевое описание услуги только после клика, ввода в форму или другого действия. Проверка «в моём браузере всё видно» недостаточна: робот может получить пустую оболочку. Ресурсы, необходимые для отображения и обработки страницы, должны быть ему доступны.
Это требование не запрещает интерактивность. Фильтры, формы и удобные переходы могут работать на JavaScript, если важные страницы открываются по собственным адресам и содержат понятный текст.
Что принять: прямое открытие страницы и проверку её HTML или отрендеренного результата поисковым инструментом после запуска. Для каталога дополнительно проверьте переход к следующей части списка: товары не должны оставаться доступными только через действие пользователя без обнаруживаемых ссылок.
Проверьте мобильность и скорость на настоящем наполнении
На телефоне посетителю нужны те же сведения об услуге или товаре, что на большом экране. Компоновку можно менять, длинные разделы — сворачивать, но важный текст не должен исчезать из мобильной версии или загружаться только после действия. Google использует мобильную версию содержания для индексации и ранжирования.
Проверьте меню, карточки, таблицы, формы и всплывающие элементы. Посетитель должен прочитать условия, перейти в нужный раздел и отправить заявку. Важны реальные действия на телефоне: скриншот узкой версии не показывает, перекрывает ли баннер кнопку и удобно ли заполнять форму.
Требование «сайт быстрый» замените согласованным сценарием измерений. Укажите типовые заполненные страницы, устройство, условия сети, включённые внешние сервисы и среду проверки. Пустой шаблон без фотографий, каталога и виджетов не представляет готовый сайт.
В разработку заложите подготовку изображений под размеры показа, разумную загрузку ресурсов, заданные размеры медиа и проверку сторонних скриптов. Контролировать нужно не только появление первого экрана, но и реакцию на действия и смещения элементов во время загрузки.
Ориентиры хороших Core Web Vitals: LCP до 2,5 секунды включительно, INP до 200 мс включительно и CLS не выше 0,1. Они оцениваются на 75-м процентиле загрузок, отдельно для мобильных и настольных устройств. До запуска лабораторные проверки помогают найти проблемы, но не заменяют данные реальных посетителей. В частности, обычный прогон Lighthouse без действий пользователя не измеряет INP.
Что принять: отчёты по выбранным страницам с условиями измерения и проверку основных действий на телефоне. Хорошие показатели помогают качеству сайта, но не гарантируют высокие позиции.
Оставьте бизнесу возможность развивать содержание и связи
Страница не становится полезной только из-за заполненных SEO-полей. Покупателю нужны описание предложения, ограничения, условия заказа и понятный следующий шаг. Согласуйте обязательное содержание каждого типа страниц до дизайна: иначе нужные сведения будет некуда разместить.
Проверьте редактор на реальном материале. Можно ли добавить раздел, таблицу характеристик, изображение с осмысленным альтернативным описанием и ссылку на подходящую услугу? Сохранение текста не должно разрушать заголовки, адаптивное отображение и структуру страницы. Объём определяется вопросом посетителя; универсальная длина «SEO-текста» не нужна.
Внутренние ссылки также надо заложить в шаблоны. Важные страницы должны быть достижимы из навигации или других доступных страниц. Для поискового робота нужны обычные ссылки с адресом в href, а не только обработчики клика. Понятный текст ссылки объясняет, куда она ведёт.
Для владельца это можно проверить простым маршрутом: раздел услуг → нужная услуга → условия или пример → обращение. На каждом шаге есть полезное продолжение, а в отчёте обхода не остаются важные страницы без входящих внутренних ссылок.
Как принять SEO-основу до открытия сайта
Попросите предъявить результаты проверок, привязанные к согласованным требованиям. Таблица ниже подходит как основа протокола приёмки; состав страниц и условия измерений нужно заполнить для своего проекта.
| Результат | Подтверждение |
|---|---|
| Адреса и правила дублей | Согласованная карта страниц; проверка основных URL, вариантов, редиректов и ошибок |
| Управляемые метаданные | Изменение через CMS и проверка опубликованного результата на разных типах страниц |
| Доступность для поиска | Проверка robots.txt, индексационных указаний, canonical и состава sitemap |
| Видимый роботу контент | Проверка текста, заголовков и обнаруживаемых ссылок в HTML или результате рендеринга |
| Работа на телефоне | Прохождение ключевых сценариев на заполненных страницах |
| Производительность | Отчёты с условиями измерений и перечнем проверенных страниц |
| Редактирование и навигация | Пробное обновление содержания и отчёт об обходе согласованного набора URL |
Проверьте каждый используемый тип шаблона и особые состояния: пустой результат, длинный заголовок, отсутствующую страницу, изменение адреса. Для большого каталога согласуйте набор страниц и границы обхода, а результаты автоматической проверки сопоставьте с картой. Ручной просмотр одной главной не подтверждает готовность всего сайта.
Сначала устраните препятствия, которые закрывают важные страницы или делают их содержание недоступным: ошибочные ответы, запреты индексации, неверные адреса, пустой рендеринг. Затем принимайте метаданные, связи, мобильные сценарии и измеренные показатели. Зафиксируйте, кто отвечает за проверку публичной конфигурации сразу после запуска и за наблюдение за индексацией дальше.
Если нужны работы с настройками обхода, дублями и адресами, обсуждайте их в рамках технической SEO-оптимизации сайта. Развитие содержания и работа с поисковым спросом требуют собственного плана после запуска. Если сайт уже работает и нужно обнаружить неизвестные проблемы, используйте чек-лист технического аудита: там задача начинается с диагностики существующего состояния. Здесь результат другой — заранее согласованные и проверенные требования к новому сайту.
