Соберите структуру сайта SEO за 7 шагов: схема и чек-лист

SEO-структура начинается с реестра будущих URL. Для каждой страницы указывают поисковое намерение, тип, родительский раздел, внутренние ссылки, язык, canonical, присутствие в sitemap и целевое действие. Такой реестр переводит семантику в задание для дизайнера, разработчика, редактора и SEO-специалиста.

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

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

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

До сбора семантики запишите ограничения CMS, число языков, правила формирования URL, доступные шаблоны и владельца контента. Эти условия влияют на стоимость структуры сильнее, чем число строк в таблице.

Соберите запросы из планировщиков, Search Console, рекламных кампаний, подсказок поиска, внутреннего поиска сайта и вопросов отдела продаж. Данные из рекламы полезны тем, что содержат реальные формулировки и сведения о заявках. Search Console раскрывает запросы уже видимых страниц.

Кластер объединяет запросы с общей задачей пользователя и близким составом результатов поиска. Фразы «создание интернет-магазина» и «разработка каталога с оплатой» могут требовать одной страницы, если выдача и коммерческое предложение совпадают. Запросы «цена интернет-магазина» и «этапы разработки» иногда раскрываются на той же странице отдельными разделами.

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

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

Каждая строка реестра отвечает на восемь вопросов: какой спрос обслуживает страница, какой у нее тип, кто родитель, какие адреса ведут на нее, какой язык используется, какая версия указана в canonical, входит ли URL в sitemap и какое действие ожидается.

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

Иерархия должна отражать выбор пользователя и отношения между сущностями. Страница «SEO-продвижение» может быть родителем для аудита, технической оптимизации и сопровождения. Статья о canonical ведет к услуге SEO и к материалу о дублях. Кейс ведет к примененной услуге.

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

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

Хлебные крошки подтверждают положение страницы в иерархии. Они требуют одинаковой последовательности в интерфейсе и структурированных данных. Смена родителя должна обновлять навигацию, ссылки и реестр.

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

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

Robots.txt регулирует обход. Закрытый там адрес может остаться известным поисковой системе по внешним и внутренним ссылкам. Для удаления страницы из поиска используют доступную для робота директиву noindex, корректный HTTP-статус или удаление по установленной процедуре. Одновременная блокировка обхода и noindex мешает роботу прочитать директиву.

Sitemap содержит канонические адреса со статусом 200, предназначенные для поиска. Файл ускоряет обнаружение и дает отчет по отправленным URL, но не заменяет навигацию и внутренние ссылки. Дата lastmod должна отражать существенное изменение страницы.

Для русской и казахской версий используйте отдельные URL. Каждая страница указывает на себя и на эквивалентные версии через hreflang. Значение x-default применяют для страницы выбора языка или версии, которую нужно показать при отсутствии точного языкового соответствия. Оно не заменяет ru-KZ и kk-KZ.

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

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

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

Сверьте каждый адрес с реестром. Проверьте HTTP-статус, Title, H1, canonical, robots, hreflang, внутренние ссылки, хлебные крошки, sitemap и целевое событие. Для страниц с формой проведите тестовую отправку и проверьте запись в CRM.

URL Inspection в Search Console показывает доступность конкретного адреса, последний обход, выбранный canonical и проблемы индексирования. Проверка опубликованного URL дополняет анализ исходного HTML. Оператор site: дает приблизительную выборку и подходит для быстрой проверки отдельных примеров. Решение о приемке принимают по URL Inspection, отчетам Search Console, sitemap и журналам сервера.

Отдельно проверьте мобильный рендеринг и Core Web Vitals. Показатели LCP, INP и CLS оценивают загрузку основного элемента, отзывчивость и визуальную стабильность. Для крупных шаблонов проверяйте полевые данные и лабораторные замеры, потому что они отвечают на разные вопросы.

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

+## Что передать дизайнеру, разработчику и редактору

Дизайнеру нужен список типов страниц, обязательных блоков и целевых действий. Для услуги это могут быть условия, состав, цена, кейсы, FAQ и форма. Для категории - описание, товары, фильтры, подкатегории и ссылки на материалы. Макет должен учитывать длинные заголовки, казахский перевод, пустые состояния и мобильную навигацию.

Разработчик получает правила URL, canonical, hreflang, sitemap, robots, редиректов, пагинации и фасетов. Для каждого шаблона указывают обязательные метаданные, хлебные крошки, структурированные данные, события аналитики и HTTP-статусы. Отдельно описывают обработку пустой категории, снятого товара, измененного slug и параметрической страницы.

Редактор получает кластер, намерение, тип страницы, H1, вопросы покупателя, доказательства и внутренние ссылки. Текст готовят под конкретный URL. Один абзац нельзя механически копировать на все города или категории с заменой названия. Локальная страница требует собственных условий и фактов.

Задание должно содержать критерии приемки. Формулировка «настроить SEO» не дает проверяемого результата. Перечень «самостоятельный canonical, взаимный hreflang, статус 200, URL в sitemap, две входящие ссылки и событие формы в аналитике» можно проверить до публикации.

Ответственность распределяют по полям реестра. SEO-специалист утверждает спрос и правила индексирования. Редактор отвечает за содержание и метаданные. Разработчик отвечает за шаблон и технические директивы. Владелец продукта принимает целевое действие и коммерческие условия. Такой порядок сокращает спор после релиза.

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

Карта редиректов сопоставляет старый адрес с наиболее близким новым. Массовый редирект всех удаленных страниц на главную создает слабое соответствие и может восприниматься как мягкий 404. Если эквивалента нет, страница отвечает 404 или 410, а внутренние ссылки удаляются.

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

Первые недели после миграции контролируйте ошибки 404, цепочки редиректов, выбранные canonical, страницы без входящих ссылок и изменения в Search Console. Журналы сервера показывают, какие адреса обходит робот и где он получает ошибку. Значимые отклонения сопоставляют с картой миграции.

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

В каталоге на 28 000 SKU действовали русская и казахская версии, а параметры фильтра создавали большое число адресов. Команда собрала правила для категорий и фасетов, оставила в индексе фильтры с подтвержденным спросом и настроила языковые соответствия.

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

Отчет по такому проекту должен содержать число отправленных и индексируемых URL, причины исключения, выбранные canonical, ошибки hreflang, страницы без входящих ссылок, переходы по типам страниц и действия на коммерческих адресах. Общая фраза о росте не заменяет эти показатели.

Для сайта услуг структура, реестр URL, семантика, правила метаданных и приемка могут стоить 220 000-380 000 ₸. Плановый срок составляет 2-4 недели при готовом перечне услуг, одной CMS и доступных материалах.

Для каталога с русской и казахской версиями, фасетами и правилами генерации стоимость составляет 480 000-920 000 ₸. Плановый срок 6-10 недель зависит от числа шаблонов, качества выгрузки товаров, ограничений CMS, готовности переводов и количества индексируемых фильтров.

Разработка шаблонов, написание всего контента, перевод, миграция данных и дальнейшее SEO-сопровождение считаются отдельно, если они не входят в согласованный состав. Смета должна перечислять итоговые файлы, число типов страниц и правила приемки.

+## Контроль структуры после запуска

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

Сверяйте реестр с sitemap и обходом. Ищите адреса, которые есть на сайте, но отсутствуют в плане, а также запланированные страницы без публикации. Отдельный список нужен для редиректов, ошибок 404 и страниц, выбранных Google как другой canonical.

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

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

Индексируют заранее выбранные комбинации со спросом, товарами, самостоятельным содержанием и стабильным URL. Остальные фильтры работают для выбора товара без добавления в sitemap.

x-default указывает страницу выбора языка или версию для пользователя без точного языкового соответствия. Русская и казахская страницы сохраняют собственные hreflang и canonical.

Оператор дает приблизительную выборку. Для конкретного URL используйте URL Inspection, отчеты Search Console, sitemap, HTTP-ответ и проверку исходного HTML.

Отправляйте sitemap после приемки канонических URL со статусом 200. Обновляйте lastmod при существенном изменении и удаляйте адреса, закрытые от индексирования.

Закажите SEO-продвижение сайта, если реестр URL уже существует и требуется рост видимости. Для проектирования новой структуры совместите SEO с разработкой сайта. Пример совместной работы опубликован в кейсе о сайте и SEO для инжиниринговой компании.