Архитектура сайта для SEO: структура без потери трафика

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

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

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

Поэтому SEO-архитектуру следует проектировать одновременно с функциональными требованиями, моделями данных и шаблонами страниц. Оптимизация не должна начинаться после завершения разработки, когда все неудачные решения уже аккуратно распределены по production.

Что входит в архитектуру сайта

Архитектура включает не только список разделов в основном меню. В неё входят:

• иерархия разделов и страниц;
• типы документов и шаблоны;
• правила формирования URL;
• основная и дополнительная навигация;
• хлебные крошки;
• внутренняя перелинковка;
• категории, теги и фильтры;
• пагинация;
• канонические адреса;
• многоязычные и региональные версии;
• рендеринг контента;
• служебные страницы;
• robots.txt и sitemap.xml;
• коды ответа и перенаправления;
• структурированные данные;
• контроль индексации.

Эти элементы должны работать как единая система. Хороший URL не исправит страницу, которую невозможно найти через ссылки, а sitemap не заменит понятную навигацию.

Какие задачи решает SEO-архитектура

Помогает обнаруживать страницы

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

Показывает отношения между материалами

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

Распределяет внутренние ссылки

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

Предотвращает дублирование

Единые правила URL, canonical, фильтров и параметров уменьшают число адресов с одинаковым или почти одинаковым содержанием.

Снижает каннибализацию

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

Упрощает развитие проекта

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

Начинайте с задач бизнеса

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

Зафиксируйте:

• основные направления;
• приоритетные услуги или товары;
• категории клиентов;
• регионы работы;
• способы оказания услуги;
• ограничения;
• связанные продукты;
• планируемые направления;
• необходимые интеграции;
• целевые действия.

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

Семантическое ядро как основа структуры

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

Для каждого кластера определяются:

• основная тема;
• дополнительные запросы;
• поисковый интент;
• тип страницы;
• уровень структуры;
• целевая аудитория;
• приоритет;
• существующий или будущий URL;
• связанные материалы.

Один кластер не всегда равен одному запросу

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

Один кластер не всегда равен одной странице навсегда

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

Составьте карту типов страниц

До проектирования URL необходимо определить, какие типы страниц будут существовать.

Типичный корпоративный сайт может содержать:

• главную страницу;
• раздел услуг;
• страницу конкретной услуги;
• раздел проектов;
• страницу проекта;
• раздел статей;
• рубрику блога;
• статью;
• страницу сотрудника;
• контакты;
• FAQ;
• документы;
• региональную страницу;
• служебную страницу.

Для интернет-магазина добавляются:

• категория;
• подкатегория;
• карточка товара;
• страница бренда;
• фильтр;
• результаты поиска;
• корзина;
• оформление заказа;
• личный кабинет.

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

Проектируйте структуру через связи, а не только через URL

Адрес страницы может отражать тематику, но поисковая система понимает относительную важность и положение материала прежде всего через ссылки между страницами.

Например, URL:

/services/development/corporate/

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

Правильная связь выглядит так:

1. Главная страница ссылается на раздел услуг.
2. Раздел услуг ссылается на направление разработки.
3. Направление ссылается на корпоративные сайты.
4. Страница корпоративных сайтов ссылается на связанные статьи и проекты.
5. Связанные материалы возвращают пользователя к услуге.

Глубина вложенности

Правило «любая страница за три клика» является полезным ориентиром, но не универсальным требованием поисковых систем. Для крупного каталога естественная глубина может быть больше.

Важно другое:

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

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

Ширина структуры

Слишком широкое меню с десятками равнозначных пунктов затрудняет выбор. Слишком узкая структура создаёт лишнюю вложенность.

При проектировании учитывайте:

• число основных направлений;
• сходство разделов;
• частоту использования;
• приоритет бизнеса;
• поисковый спрос;
• возможность дальнейшего расширения.

Связанные услуги можно объединять в направление, но не следует создавать искусственную категорию только ради дополнительного уровня URL.

Основная навигация

Главное меню должно показывать основные разделы сайта. Оно не обязано содержать ссылки на каждую страницу.

Хороший пункт меню:

• имеет понятное название;
• соответствует содержанию раздела;
• не дублирует соседний пункт;
• ведёт на доступный URL;
• работает без обязательного выполнения JavaScript;
• показывает активное состояние.

Ссылки должны быть настоящими ссылками

Для навигации используйте:

<a href="/services/">
    Услуги
</a>

Элементы div, span или кнопки с JavaScript-переходом не являются надёжной заменой обычной ссылке.

Мобильное меню

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

Хлебные крошки

Хлебные крошки показывают путь от общего раздела к текущей странице.

Они помогают:

• понимать положение страницы;
• возвращаться на уровень выше;
• создавать ссылки на родительские разделы;
• поддерживать единую иерархию;
• формировать BreadcrumbList.

Хлебные крошки должны отражать логическую структуру, а не историю кликов пользователя.

Пример:

Главная
→ Разработка сайтов
→ Корпоративные сайты

На главной странице хлебные крошки обычно не нужны.

Правила формирования URL

URL должен быть стабильным, понятным и единообразным.

Используйте читаемые слова

Адрес:

/services/site-audit.html

понятнее, чем:

/index.php?id=147&section=3

Используйте дефисы

Для разделения слов применяется дефис:

/blog/site-architecture.html

Не добавляйте лишние данные

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

Соблюдайте единый регистр

Практичнее использовать нижний регистр и перенаправлять альтернативные варианты.

Определите правило завершающего слэша

Можно использовать адреса со слэшем или без него. Важно выбрать один вариант и обеспечить перенаправление со второго.

Для данного проекта принято правило:

• разделы с дочерними страницами заканчиваются символом /;
• конечные страницы заканчиваются .html.

Не меняйте URL из-за косметики

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

Канонический адрес

Canonical указывает предпочтительный адрес среди одинаковых или очень похожих страниц.

Он полезен для:

• параметров рекламных кампаний;
• вариантов сортировки;
• технических дублей;
• одинакового материала в нескольких разделах;
• альтернативных форматов документа;
• адресов с незначащими параметрами.

Self-canonical

Каноническая страница может ссылаться сама на себя:

<link
    rel="canonical"
    href="https://example.com/services/audit.html"
>

Canonical является сигналом, а не приказом

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

Согласуйте все сигналы

Внутренние ссылки, sitemap, перенаправления и canonical должны указывать на один и тот же предпочтительный адрес.

Не используйте canonical вместо исправления структуры

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

HTTP, HTTPS, www и зеркала

Выберите один основной вариант домена:

• https://example.com/;
• или https://www.example.com/.

Все альтернативы должны перенаправляться непосредственно на основной вариант:

• HTTP на HTTPS;
• www на адрес без www или наоборот;
• вариант с неправильным слэшем;
• смешанный регистр;
• старые домены.

Избегайте цепочек:

http
→ https://www
→ https без www
→ конечный URL

Лучше выполнить одно перенаправление сразу на итоговый адрес.

Категории и подкатегории

Категория должна объединять самостоятельную группу материалов и помогать пользователю выбирать.

Для каждой категории определите:

• название;
• назначение;
• тип дочерних страниц;
• основной интент;
• поля шаблона;
• правила сортировки;
• метаданные;
• перелинковку;
• пагинацию;
• индексацию.

Категория из одного элемента обычно не улучшает структуру. Возможно, этот материал следует разместить уровнем выше.

Теги блога

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

Индексируемый тег должен:

• иметь понятную тему;
• содержать достаточное количество материалов;
• не дублировать рубрику;
• иметь спрос или навигационную ценность;
• получать внутренние ссылки;
• иметь уникальные метаданные;
• обновляться по мере публикации материалов.

Разовые авторские метки вроде «интересное», «важное» и «полезное» редко создают самостоятельную SEO-страницу. Зато превосходно создают мусорную таксономию, потому что человеческая тяга подписывать всё подряд почти неистребима.

Фильтры и faceted navigation

Фасетная навигация позволяет сочетать характеристики: бренд, материал, размер, назначение, регион и другие параметры.

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

Разделите фильтры на группы

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

Индексируемые комбинации

Отдельная страница фильтра оправдана, если:

• существует самостоятельный спрос;
• результат стабилен;
• есть достаточное количество элементов;
• можно подготовить уникальные метаданные;
• страница решает отдельную задачу;
• она получает внутренние ссылки;
• URL не меняется случайным образом.

Неиндексируемые комбинации

Для остальных фильтров стратегия выбирается по размеру сайта и поведению роботов:

• не создавать отдельный URL;
• не размещать crawlable-ссылки на бесконечные комбинации;
• использовать noindex, если страницу нужно обходить, но не показывать в поиске;
• ограничивать обход через robots.txt, если проблема заключается именно в расходовании ресурсов сканирования;
• применять canonical только для действительно дублирующих страниц;
• не добавлять технические URL в sitemap.

Нельзя одновременно закрыть страницу в robots.txt и ожидать, что робот увидит размещённый на ней noindex или canonical. Сначала необходимо определить цель: запретить обход, запретить индексацию или объединить дубли.

Сортировки

Параметры сортировки обычно не создают новое содержание:

?sort=price
?sort=date
?sort=popular

Такие URL не должны становиться отдельными посадочными страницами.

Рекомендуется:

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

Пагинация

Пагинация разбивает длинный список на несколько страниц.

Каждая страница должна иметь отдельный URL:

/blog/?page=2
/catalog/?page=3

Каждая страница пагинации должна быть доступна

Используйте обычные ссылки:

<a href="/blog/?page=2">
    2
</a>

Робот не обязан нажимать кнопку «Показать ещё» или прокручивать страницу так, как это делает пользователь.

Self-canonical для страниц пагинации

Страница 2 не является дублем страницы 1, поскольку содержит другой набор элементов. Поэтому для неё обычно указывается собственный canonical.

Не канонизируйте всю пагинацию на первую страницу

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

Связывайте страницы последовательно

Каждая страница должна ссылаться как минимум на следующую. Можно также показывать предыдущую, соседние номера и ссылку на начало списка.

Бесконечная прокрутка

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

Внутренняя перелинковка

Перелинковка связывает материалы по смыслу и направляет пользователя к следующему действию.

Вертикальные связи

• главная страница → раздел;
• раздел → подраздел;
• подраздел → конкретная страница;
• дочерняя страница → родительский раздел.

Горизонтальные связи

• связанные услуги;
• похожие товары;
• статьи одного кластера;
• соседние проекты;
• альтернативные решения.

Контекстные ссылки

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

Понятный вариант:

<a href="/blog/seo/semantic-core.html">
    сбор семантического ядра
</a>

Менее полезный вариант:

<a href="/blog/seo/semantic-core.html">
    подробнее
</a>

Блоки связанных материалов

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

Сиротские страницы

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

Sitemap.xml

XML-карта помогает сообщить поисковым системам о предпочтительных URL.

В sitemap следует включать:

• канонические страницы с кодом 200;
• страницы, разрешённые для индексации;
• актуальные URL;
• действительно важные материалы.

Не следует включать:

• перенаправления;
• страницы 404;
• noindex;
• дубли;
• технические параметры;
• закрытые кабинеты;
• результаты внутреннего поиска;
• случайные фильтры.

lastmod

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

Sitemap index

Большой проект может разделять карты по типам:

• страницы;
• товары;
• категории;
• статьи;
• изображения;
• видео;
• языковые версии.

Это упрощает контроль индексации и поиск ошибок.

Robots.txt

robots.txt управляет доступом роботов к URL, но не является надёжным способом исключения страницы из результатов поиска.

Файл подходит для:

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

Не закрывайте важные CSS и JavaScript

Поисковый робот должен иметь возможность отобразить страницу и понять её содержание. Блокировка необходимых ресурсов может помешать рендерингу.

Не защищайте конфиденциальные данные robots.txt

Файл доступен публично. Закрытые материалы необходимо защищать авторизацией и серверными правами.

Не используйте robots.txt для canonical

Если робот не загрузит страницу, он не увидит её содержимое и каноническую ссылку.

Noindex

Директива noindex сообщает, что страницу не нужно показывать в результатах поиска.

Она подходит для:

• служебных страниц;
• внутреннего поиска;
• личного кабинета при отсутствии авторизации;
• временных страниц;
• неценных фильтров, которые всё же необходимо обходить;
• технических листингов.

Чтобы робот увидел noindex, URL должен быть доступен для обхода. Поэтому сочетание Disallow и noindex требует понимания последовательности обработки.

Результаты внутреннего поиска

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

Рекомендуется:

• добавить noindex;
• не включать в sitemap;
• не использовать в основной перелинковке;
• ограничить обход параметров при необходимости;
• не превращать поиск в генератор посадочных страниц.

JavaScript и рендеринг

Для SEO важно, чтобы основной контент и ссылки были доступны поисковому роботу.

Серверный рендеринг

Сервер возвращает готовый HTML с содержанием. Это упрощает первичное получение текста, ссылок и метаданных.

Статическая генерация

Страницы создаются заранее во время сборки. Подход хорошо работает для контента, который не меняется при каждом запросе.

Клиентский рендеринг

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

Гибридная архитектура

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

Требования к JavaScript-сайту

• основной текст доступен после рендеринга;
• ссылки используют <a href>;
• каждая индексируемая страница имеет отдельный URL;
• сервер возвращает корректный код ответа;
• title и description соответствуют странице;
• canonical присутствует в head;
• страницы работают при прямом открытии URL;
• маршруты не зависят только от состояния браузера;
• контент не появляется только после клика;
• ресурсы не закрыты в robots.txt;
• sitemap содержит канонические URL;
• ошибки рендеринга контролируются.

Soft 404 в JavaScript-приложениях

SPA может показывать сообщение «Страница не найдена», но возвращать код 200. Для поискового робота это выглядит как обычная успешная страница.

Несуществующий URL должен возвращать:

• 404, если страницы нет;
• 410, если она удалена окончательно;
• 301 или 308, если существует однозначная замена.

Шаблоны страниц

SEO-требования следует заложить в шаблоны, а не добавлять вручную для каждого документа.

Шаблон должен поддерживать:

• уникальный title;
• description;
• один H1;
• структуру H2–H3;
• canonical;
• robots meta;
• хлебные крошки;
• дату публикации и изменения;
• автора, если он нужен;
• связанные материалы;
• изображение и alt;
• структурированные данные;
• правильный код ответа.

В данном проекте отдельного поля pagetitle или ручного H1 нет. Основной заголовок выводится из menutitle, а при его отсутствии — из title.

Заголовки H1–H3

На странице должен быть один основной H1, обозначающий тему документа.

Подзаголовки:

• формируют логическую структуру;
• помогают просматривать материал;
• не пропускают уровень без причины;
• не используются только ради оформления;
• соответствуют содержанию раздела.

Название сайта, логотип, футер и повторяющиеся элементы не должны создавать дополнительные H1.

Title и description

Для проекта используются внутренние требования:

• title — 50–60 символов;
• description — 140–160 символов.

Эти значения помогают контролировать качество метаданных, но поисковая система может формировать сниппет на основе содержимого страницы и запроса пользователя.

Метаданные должны:

• быть уникальными;
• точно описывать страницу;
• соответствовать интенту;
• не содержать бессмысленного перечисления ключевых слов;
• не дублироваться между шаблонами.

Структурированные данные

Структурированные данные помогают описывать тип страницы и её сущности. Они не гарантируют расширенный результат и не заменяют видимое содержание.

В зависимости от страницы могут использоваться:

• Organization;
• LocalBusiness;
• BreadcrumbList;
• Article или BlogPosting;
• Product и Offer;
• JobPosting;
• VideoObject;
• другие поддерживаемые типы.

Разметка должна соответствовать странице

Данные в JSON-LD должны совпадать с видимым содержанием: названием, ценой, наличием, датой, автором и другими полями.

FAQPage

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

Проверка

Структурированные данные следует проверять валидатором и инструментом тестирования расширенных результатов.

Многоязычная архитектура

Каждая языковая версия должна иметь отдельный URL.

Возможные варианты:

• example.com/en/;
• example.com/de/;
• en.example.com;
• отдельный национальный домен.

Для большинства проектов подкаталоги проще поддерживать и связывать.

Hreflang

Языковые и региональные аналоги связываются с помощью hreflang.

Требования:

• каждая версия ссылается на остальные;
• используются абсолютные URL;
• коды языка и региона корректны;
• страницы являются аналогами;
• canonical указывает на страницу того же языка;
• при необходимости используется x-default.

Не подменяйте язык только по IP

Автоматическая подмена содержания на одном URL усложняет обнаружение всех версий. Пользователь должен иметь возможность выбрать язык и получить отдельный адрес.

Региональные страницы

Отдельная страница региона оправдана, если существует самостоятельная ценность:

• реальный офис или подразделение;
• отдельные условия работы;
• региональные цены;
• локальные проекты;
• сроки выезда или доставки;
• региональные контакты;
• самостоятельный спрос.

Страница, в которой меняется только название города, создаёт дубли и почти не помогает пользователю.

Мобильная версия

Основной контент, ссылки и метаданные должны быть доступны на мобильной версии.

Проверьте:

• совпадение значимого содержания;
• доступность навигации;
• работу раскрывающихся блоков;
• размер элементов управления;
• отсутствие горизонтальной прокрутки;
• видимость H1;
• изображения и alt;
• структурированные данные;
• canonical и hreflang;
• скорость загрузки.

Скрытие важного текста из мобильной версии ради компактности может повредить не только пользователю, но и пониманию страницы поисковой системой.

Скорость и Core Web Vitals

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

На этапе проектирования определите:

• способ рендеринга;
• правила кэширования;
• форматы изображений;
• адаптивные размеры;
• загрузку шрифтов;
• критические стили;
• разделение JavaScript;
• приоритет основного изображения;
• ограничение сторонних скриптов;
• контроль смещения блоков.

LCP

Основной крупный элемент должен загружаться быстро. Не следует лениво загружать главное изображение первого экрана.

INP

Интерфейс должен быстро реагировать на действия. Длинные задачи JavaScript необходимо сокращать или разделять.

CLS

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

Коды ответа сервера

Не перенаправляйте все удалённые страницы на главную

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

Страница 404

Полезная страница ошибки может содержать:

• объяснение;
• основное меню;
• поиск;
• ссылки на популярные разделы;
• контакты.

При этом сервер должен возвращать код 404, а не 200.

Редиректы при изменении URL

Для каждого старого URL составляется таблица соответствий.

Перенаправление должно вести:

• на максимально близкий материал;
• сразу на конечный URL;
• без циклов;
• без цепочек;
• с сохранением пути пользователя.

После переноса необходимо обновить:

• внутренние ссылки;
• sitemap;
• canonical;
• hreflang;
• структурированные данные;
• рекламные ссылки;
• внешние интеграции.

Архитектура при редизайне

Редизайн не обязательно требует изменения URL и структуры. Если текущая архитектура работает, визуальное обновление следует отделить от переноса.

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

Страницы доверия

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

• о компании;
• контакты;
• реквизиты;
• команда;
• условия работы;
• оплата;
• доставка и возврат;
• политика обработки данных;
• кейсы;
• авторы материалов.

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

Служебные разделы

Архитектура должна заранее учитывать:

• административную панель;
• личный кабинет;
• корзину;
• оформление заказа;
• предварительный просмотр;
• тестовые страницы;
• результаты поиска;
• API;
• файлы экспорта;
• страницы благодарности.

Для каждого типа определяется:

• требуется ли авторизация;
• нужна ли индексация;
• какой код ответа возвращается;
• есть ли canonical;
• должен ли URL попадать в sitemap;
• кто может создавать ссылку.

Crawl budget без мифологии

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

Проблема становится значимой для:

• крупных интернет-магазинов;
• миллионов параметрических URL;
• часто обновляемых площадок;
• агрегаторов;
• сайтов с большим количеством дублей;
• медленных серверов;
• проектов с ошибками 5xx;
• календарей и бесконечных архивов.

Не следует закрывать половину небольшого сайта в robots.txt только ради «экономии crawl budget». Иногда SEO-оптимизация удивительно напоминает лечение несуществующей болезни побочными эффектами настоящих лекарств.

Логи сервера

Логи показывают, какие URL действительно запрашивают поисковые роботы.

С их помощью можно найти:

• часто сканируемые параметры;
• 404 и 5xx;
• редкие обходы важных страниц;
• циклические URL;
• старые адреса;
• неожиданные фильтры;
• медленные ответы;
• обращения к закрытым разделам.

Мониторинг после запуска

Контролируйте:

• индексацию;
• выбранные canonical;
• исключённые страницы;
• ошибки sitemap;
• robots.txt;
• 404 и 5xx;
• цепочки редиректов;
• Core Web Vitals;
• мобильное отображение;
• структурированные данные;
• появление новых параметров;
• каннибализацию.

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

Этапы проектирования SEO-архитектуры

Шаг 1. Описать бизнес-направления

Зафиксировать продукты, услуги, аудитории и регионы.

Шаг 2. Собрать семантику

Определить поисковые задачи и кластеры.

Шаг 3. Создать карту типов страниц

Определить шаблоны, поля и назначение каждого типа.

Шаг 4. Распределить кластеры

Назначить одну основную страницу для каждой самостоятельной задачи.

Шаг 5. Построить иерархию

Связать главную, разделы, подразделы и конечные страницы.

Шаг 6. Утвердить URL

Зафиксировать регистр, слэши, расширения, параметры и языковые версии.

Шаг 7. Спроектировать перелинковку

Определить меню, хлебные крошки, родительские и тематические связи.

Шаг 8. Описать индексацию

Для каждого типа указать canonical, robots, sitemap и код ответа.

Шаг 9. Выбрать рендеринг

Обеспечить доступность основного HTML, ссылок и метаданных.

Шаг 10. Подготовить карту перенаправлений

Для существующего сайта сопоставить старые и новые URL.

Шаг 11. Провести тестовый обход

Использовать crawler до открытия сайта для индексации.

Шаг 12. Проверить после запуска

Сравнить фактические коды, canonical, sitemap и внутренние ссылки с проектом.

Документ архитектуры

Результат проектирования удобно оформлять в таблице.

Проверка перед запуском

• Все важные страницы доступны по ссылкам.
• Нет сиротских URL.
• Навигация использует <a href>.
• URL соответствуют утверждённым правилам.
• HTTP перенаправляется на HTTPS.
• Выбран единый вариант www.
• Слэши обрабатываются единообразно.
• Нет цепочек перенаправлений.
• Canonical соответствует конечному URL.
• Страницы пагинации имеют отдельные URL.
• Фильтры не создают бесконечные комбинации.
• Результаты внутреннего поиска не индексируются.
• Sitemap содержит только канонические страницы.
• Robots.txt не блокирует важные ресурсы.
• Тестовый домен закрыт от индексации.
• Production открыт после окончательной проверки.
• Каждая страница имеет один H1.
• Title и description уникальны.
• Хлебные крошки отражают структуру.
• Структурированные данные соответствуют содержанию.
• Мобильная версия содержит основной контент.
• Коды 404 и 5xx работают корректно.
• Настроен мониторинг.

Типичные ошибки архитектуры

Структура строится только по меню

Не учитываются статьи, фильтры, служебные страницы и внутренняя перелинковка.

Раздел создаётся под каждый запрос

Появляются почти одинаковые страницы и каннибализация.

URL меняются при каждом редизайне

Проект регулярно теряет накопленные сигналы и создаёт цепочки перенаправлений.

Вся пагинация канонизируется на первую страницу

Разные наборы элементов ошибочно объявляются дублями.

Все фильтры индексируются

Количество URL растёт быстрее каталога.

Все фильтры закрываются одинаково

Ценные посадочные страницы теряются вместе с техническими комбинациями.

Robots.txt используется вместо noindex

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

JavaScript-навигация не создаёт ссылок

Страницы доступны пользователю, но плохо обнаруживаются роботом.

Sitemap заменяет перелинковку

URL присутствует в файле, но никак не связан с остальным сайтом.

Удалённые страницы ведут на главную

Поисковая система и пользователь не получают подходящей замены.

Мобильная версия урезана

Важный текст и ссылки присутствуют только на компьютере.

Микроразметка не соответствует странице

В JSON-LD указаны данные, которых пользователь не видит.

Нет контроля после релиза

Новые параметры, страницы и ошибки накапливаются незаметно.

Вывод

SEO-архитектура сайта начинается не с robots.txt и не с генерации sitemap. Сначала определяются задачи бизнеса, поисковые интенты, типы страниц и связи между ними.

Хорошая структура помогает пользователю находить информацию, а поисковым роботам — обнаруживать и понимать важные страницы. Для этого необходимы crawlable-навигация, стабильные URL, осмысленная перелинковка, корректные canonical и управляемые фильтры.

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

Архитектура не заканчивается после запуска. Её необходимо контролировать по логам, отчётам индексации, кодам ответа и фактическим внутренним ссылкам. Тогда SEO и разработка перестают исправлять последствия решений друг друга и начинают работать как одна система.