Сначала определить структуру сайта
SEO начинается со структуры. До разработки или переноса контента нужно определить, какие отдельные поисковые задачи действительно требуют собственных страниц.
Страница должна иметь понятное назначение. Создание большого количества почти одинаковых URL под близкие формулировки обычно усложняет структуру и создаёт дублирование.
- Главная страница.
- Отдельные страницы основных услуг.
- Категории и товары для каталога, если они нужны.
- Информационные статьи под самостоятельные темы.
- Контакты и информация о компании.
- Служебные страницы только там, где они действительно требуются.
Зафиксировать URL до публикации
Адреса страниц лучше определить до запуска. Когда сайт уже попал в индекс, массовое изменение URL требует перенаправлений и создаёт лишний этап для поисковых роботов.
URL должен быть стабильным, понятным и использоваться одинаково во внутренних ссылках, canonical и sitemap.
- Не создавать несколько адресов для одной и той же страницы.
- Выбрать единый формат со слешем или без него.
- Исключить случайные параметры из индексируемых адресов.
- Не менять рабочие URL без необходимости.
- При переносе старого сайта подготовить карту 301-редиректов.
Проверить доступность страниц для индексации
Перед запуском нужно убедиться, что публичные страницы доступны без авторизации и возвращают корректный HTTP-код. Временные ограничения тестового окружения не должны случайно перейти на рабочий сайт.
Особенно часто после разработки остаются noindex, запреты в robots.txt или серверная авторизация.
- Основные страницы возвращают HTTP 200.
- На нужных страницах отсутствует noindex.
- Googlebot и другие поисковые роботы не заблокированы случайно.
- Контент доступен без логина.
- Страницы не перенаправляются по цепочке из нескольких редиректов.
- Ошибочные URL корректно возвращают 404 или 410.
Настроить robots.txt без лишних запретов
robots.txt управляет обходом URL, но не является заменой noindex. Файл должен закрывать только те технические разделы, которые действительно не требуется обходить.
После переноса с тестового домена нужно отдельно проверить, что глобальный Disallow не остался на рабочей версии.
- Проверить robots.txt после выкладки на production.
- Не блокировать CSS, JavaScript и изображения, необходимые для отображения страницы.
- Не использовать robots.txt как единственный способ удаления страницы из поиска.
- Указать адрес sitemap.xml.
Проверить canonical и дубли страниц
Canonical помогает поисковой системе понять предпочтительную версию среди похожих URL. На обычной уникальной странице он чаще всего должен указывать на её собственный основной адрес.
Особое внимание требуется сайтам с параметрами, фильтрами, версиями URL со слешем и без него, а также при переносе со старого домена.
- Canonical использует абсолютный правильный URL.
- HTTPS-страница не ссылается canonical на HTTP.
- Canonical не указывает на 404 или редирект.
- Внутренние ссылки ведут на ту же предпочтительную версию.
- Sitemap содержит именно canonical-адреса.
Подготовить title, description и заголовки
У каждой важной страницы должен быть собственный понятный title и основной заголовок H1. Description помогает сформировать понятное описание страницы, хотя поисковая система может выбрать другой фрагмент для сниппета.
Заголовки должны описывать содержимое страницы, а не использоваться только ради повторения ключевых запросов.
- Уникальный title для основной страницы.
- Один понятный H1.
- Логичная иерархия H2 и H3.
- Description соответствует содержимому.
- Нет шаблонных заголовков вида «Главная» или «Страница 1».
- Текст и мета-данные не конфликтуют между собой.
Настроить внутренние ссылки
Поисковому роботу и пользователю должно быть понятно, как добраться до важных страниц. Ключевые разделы не должны существовать только в sitemap или открываться исключительно через JavaScript-сценарий.
Внутренняя перелинковка также показывает связи между услугами, материалами и смежными темами.
- Основные страницы доступны из навигации или связанных разделов.
- Ссылки используют обычные href.
- Нет ссылок на удалённые или тестовые URL.
- Анкор описывает страницу назначения.
- Статьи связаны с релевантными услугами и другими материалами.
Сформировать sitemap.xml
Sitemap помогает поисковой системе обнаруживать канонические страницы сайта. В карту не стоит включать служебные, закрытые, перенаправляемые или неканонические URL.
После публикации sitemap можно отправить через Google Search Console и другие инструменты поисковых систем.
- В sitemap только рабочие HTTP 200 страницы.
- Нет URL с noindex.
- Нет редиректов и 404.
- Используются основные canonical-адреса.
- Новые важные страницы автоматически добавляются в карту.
Проверить мобильную версию
Перед запуском нужно проверять не только адаптивность блоков, но и полноту содержимого. Основная информация, ссылки и действия должны быть доступны на смартфоне так же, как на десктопе.
Отдельно стоит проверить формы, меню, модальные окна, размеры элементов и отсутствие горизонтальной прокрутки.
- Нет горизонтального скролла.
- Текст читается без масштабирования.
- Кнопки и ссылки удобно нажимать.
- Основной контент не скрыт на мобильной версии.
- Формы корректно работают с мобильной клавиатурой.
- Изображения не выходят за размеры контейнера.
Проверить скорость и стабильность интерфейса
Медленный сайт ухудшает пользовательский опыт ещё до того, как начинается работа с SEO. Перед запуском стоит проверить крупные изображения, блокирующие ресурсы, тяжёлый JavaScript и скачки макета.
Для диагностики удобно использовать PageSpeed Insights и инструменты разработчика браузера, но оптимизировать нужно реальные проблемные элементы, а не только стремиться к определённому числу в тесте.
- Изображения отдаются в подходящем размере.
- Для картинок указаны width и height.
- Тяжёлые скрипты не загружаются без необходимости.
- Нет заметных скачков блоков при загрузке.
- Основной контент появляется без долгой задержки.
Добавить подходящую структурированную разметку
Schema.org должна описывать реально видимый контент страницы. Не нужно добавлять типы разметки только ради возможности получить расширенный результат.
После внедрения разметку стоит проверять валидатором и Rich Results Test для тех типов, которые поддерживаются Google.
- Organization на подходящей странице компании.
- Article для статей.
- BreadcrumbList для хлебных крошек.
- Product и Offer для подходящих товарных страниц.
- FAQPage только там, где это соответствует видимому содержимому и требованиям поисковой системы.
Подключить аналитику до запуска рекламы
Если после публикации планируется реклама или оценка эффективности SEO, основные события лучше подготовить заранее. Иначе первые обращения и переходы окажутся без нормальной аналитики.
- Счётчик аналитики установлен один раз.
- Отслеживаются отправки форм.
- Настроены клики по ключевым контактам.
- UTM-метки не ломают canonical.
- Тестовые обращения отделяются от реальных данных.
Что сделать сразу после запуска
После публикации нужно проверить сайт уже снаружи, а не только на сервере разработчика. Поисковая система должна видеть те же страницы, которые доступны обычному посетителю.
В Google Search Console можно подтвердить сайт, отправить sitemap и проверить отдельные URL через инструмент проверки страниц.
- Открыть сайт с нескольких устройств и сетей.
- Проверить robots.txt и sitemap.xml по публичным URL.
- Добавить ресурс в Google Search Console.
- Отправить sitemap.
- Проверить несколько ключевых страниц через URL Inspection.
- Следить за ошибками индексации после первого обхода.
Итоговый SEO-чек-лист перед публикацией
Новый сайт не обязан быть идеально оптимизирован в первый день, но базовые технические ошибки лучше не выпускать в production.
- Структура и URL утверждены.
- Основные страницы доступны с HTTP 200.
- Нет случайного noindex.
- robots.txt проверен.
- Canonical корректны.
- Title и H1 заполнены.
- Внутренние ссылки работают.
- Sitemap.xml содержит рабочие URL.
- Мобильная версия проверена.
- Изображения оптимизированы.
- Schema соответствует содержимому.
- Формы и цели аналитики протестированы.
- Search Console готова к проверке после публикации.