Короткий ответ: для основного раздела сайта обычно лучше папка: example.ru/blog/ или example.ru/catalog/. Она сохраняет общую структуру, навигацию, аналитику и путь к заявке. Поддомен help.example.ru оправдан, когда раздел действительно самостоятельный: работает на другой платформе, имеет отдельную команду, аудиторию, авторизацию или требования к инфраструктуре. Сам по себе поддомен не даёт преимущества в SEO, а перенос в папку не гарантирует рост.
В чём практическая разница
Папка находится на основном хосте, а поддомен использует отдельное имя перед доменом. Для посетителя разница невелика, но для команды меняются DNS, сертификаты, серверные правила, cookie, авторизация, аналитика и мониторинг.
Когда выбирать папку
Раздел работает на общую воронку
Если блог отвечает на вопросы клиентов, объясняет услуги и ведёт на коммерческие страницы, адрес /blog/ понятнее. Посетитель остаётся на том же сайте, видит знакомое меню и быстрее переходит к следующему шагу. Команде легче выстроить внутреннюю перелинковку между статьями и услугами.
Это часть одного каталога или бизнеса
Разделы /catalog/, /services/ и /cases/ обычно входят в общую структуру. Большой объём сам по себе не требует поддомена. В папках проще поддерживать хлебные крошки, шаблоны карточек и единые правила URL.
Раздел поддерживает та же команда
Если одни люди отвечают за контент, разработку, аналитику и заявки, поддомен чаще добавляет настройки, а не пользу. На одном хосте также проще видеть цепочку «статья - услуга - форма - благодарность». Цели и CRM всё равно нужно настраивать, но риск потерять источник из-за разных cookie и счётчиков ниже.
Когда поддомен оправдан
Раздел является отдельным продуктом
Например, основной сайт рассказывает о компании, а на поддомене работает веб-сервис с авторизацией и собственными релизами. Его интерфейс, нагрузка и требования к безопасности отличаются от маркетингового сайта. Размещать приложение в папке только ради SEO может быть дороже и сложнее.
Нужна независимая инфраструктура
Поддомен уместен, если раздел обслуживает другой провайдер, ему нужны собственные DNS-записи, сертификаты, правила безопасности или масштабирования. Отдельная база знаний, документация API и партнёрский портал тоже могут жить по своим сценариям. Но заранее решите, какие страницы должны индексироваться и как посетитель вернётся на основной сайт.
Платформа не поддерживает папку
Некоторые SaaS-сервисы подключаются только к отдельному хосту. Это нормальный технический компромисс. До запуска проверьте HTTPS, canonical, robots.txt, карту сайта, аналитику, формы и навигацию: настройки по умолчанию могут не подходить вашему сценарию.
Как принять решение: шесть шагов
1. Опишите роль раздела
Одного предложения достаточно. «Блог отвечает на вопросы покупателей и ведёт к услугам» говорит в пользу папки. «Панель, где клиент после входа управляет проектами» описывает самостоятельный продукт. Если роль нельзя объяснить без множества оговорок, менять архитектуру рано.
2. Сравните аудиторию и целевое действие
Те же посетители, услуги и призыв к действию - аргумент за папку. Другая аудитория, отдельный вход и иной результат визита - за поддомен. Не делите сайт только по формату контента, если путь клиента остаётся общим.
3. Проверьте ограничения платформы
Запишите, где размещён раздел, как выходят обновления, кто управляет DNS и сертификатами, что умеет CMS. Папку иногда делают через обратный прокси, но его сложность должна быть оправдана. Поддомен проще запустить, однако маркетинг потом может годами поддерживать разрозненные системы. Сравнивайте не только срок запуска, но и дальнейшую эксплуатацию.
4. Назначьте ответственных
Для поддомена нужны владельцы HTTPS, резервных копий, прав доступа, robots.txt, sitemap, аналитики, мониторинга ошибок и шаблонов. Автоматизация помогает, но не отменяет ответственности. Если никто не готов поддерживать отдельный хост, это сильный довод не создавать его.
5. Спроектируйте связи
Посетитель должен находить связанные материалы и следующий шаг независимо от формата. Добавьте переходы из основного сайта в раздел и обратно. Одной ссылки в футере мало: контекстная ссылка из инструкции на подходящую услугу лучше продолжает задачу человека.
6. Проверьте аналитику и формы
Уточните работу cookie, согласий, сквозной аналитики и передачи источника в CRM. После запуска пройдите реальный путь: откройте входную страницу, перейдите в раздел, отправьте тестовую форму и проверьте данные в конечной системе. Наличие кода счётчика ещё не доказывает, что измерение работает.
Техническая проверка папки
- Рабочие страницы отвечают кодом 200 и доступны по одному итоговому URL.
- Меню и хлебные крошки показывают место раздела в общей структуре.
- Canonical ведёт на предпочтительный адрес этой же страницы.
- Sitemap содержит только индексируемые канонические URL.
- Нет дублей со слешем и без него, разным регистром и лишними параметрами.
- Внутренние ссылки ведут сразу на итоговые адреса без цепочек редиректов.
- Аналитика охватывает путь от входной страницы до обращения.
Если содержимое отдаётся через обратный прокси, проверьте заголовки, кеширование, реальный IP, абсолютные ссылки и ошибки. Несуществующий материал должен возвращать честный 404, а не шаблон основного сайта с кодом 200.
Техническая проверка поддомена
- DNS указывает на нужную инфраструктуру, HTTPS работает без предупреждений.
- Основной сайт и поддомен связаны понятной навигацией.
- Robots.txt не закрывает полезные страницы настройкой тестовой среды.
- Canonical не ведёт со всех страниц на главную: разные документы не становятся эквивалентными от одной ссылки.
- Sitemap содержит доступные канонические URL этого раздела.
- При переходе между хостами источник и сеанс сохраняются в соответствии с моделью измерения.
- Формы, авторизация, CORS, callback URL и cookie проверены на реальных сценариях.
- Хост включён в мониторинг доступности, сертификатов и серверных ошибок.
Отдельно проверьте HTTPS и смешанный контент. Поддомен не должен становиться технической серой зоной, о которой вспоминают после истечения сертификата или пропажи данных.
Практический пример
У компании есть сайт услуг, новый блог и база знаний для клиентов. Блог помогает выбрать услугу, разбирает ошибки и ведёт к заявке. У него общий дизайн, один редактор и та же воронка, поэтому логичный адрес - example.ru/blog/.
База знаний работает в отдельной системе поддержки. У неё собственный поиск, материалы обновляет другая команда, а часть инструкций доступна только после входа. Для неё подходит help.example.ru. Открытые статьи связывают с основным сайтом, закрытые служебные страницы не отдают поиску.
Если раздел уже на поддомене
Не переносите его в папку только ради ожидаемого SEO-эффекта. Сначала оцените поисковый трафик, внешние ссылки, индексируемые URL, конверсии и ограничения платформы. Такой перенос - полноценная миграция с риском ошибок.
Если деловая или техническая причина есть, сопоставьте каждый старый URL с новым, настройте прямые постоянные редиректы, обновите canonical, sitemap, внутренние ссылки и интеграции. Порядок действий описан в материале про редиректы при переезде сайта. После запуска проверьте категории, статьи, файлы, формы, ответы 404 и самые посещаемые адреса.
Не направляйте весь поддомен на одну страницу. Для каждого старого материала нужен точный или близкий аналог. Если его нет, корректный ответ 404 или 410 честнее редиректа на главную: посетитель не попадёт в ложный контекст, а команда заметит пробел в карте переноса.
Ограничения и частые ошибки
Поддомен «для усиления SEO»
Архитектура не заменяет полезный контент, понятные страницы и связи между ними. Отдельный хост добавляет работу, но сам по себе не повышает позиции.
Блог и услуги без связей
Статьи могут получать трафик, но без следующего шага он плохо помогает бизнесу. Нужны уместные ссылки, меню и согласованные призывы к действию. Логотипа со ссылкой на главную недостаточно.
Canonical вместо редиректа
Canonical сообщает о предпочтительной версии поисковой системе, но не переводит пользователя. Если страница навсегда переехала и имеет прямой аналог, старый URL должен отвечать постоянным серверным редиректом.
Тестовый хост открыт для поиска
Копия сайта может попасть в индекс. До запуска ограничьте доступ надёжным способом, а после релиза убедитесь, что служебная среда не появилась во внутренних ссылках и карте сайта.
Формы проверены только визуально
Переход на поддомен может обрывать источник или сеанс, а форма - терять данные из-за CORS, cookie или интеграции. Проверяйте путь до появления обращения в CRM, а не только сообщение «отправлено».
Одновременно меняются платформа, URL и дизайн
После такого релиза трудно найти причину падения трафика или поломки функции. По возможности разделяйте изменения, храните список исходных страниц и документируйте выпуск. После запуска используйте регулярный SEO-мониторинг.
Практический чек-лист
- Роль раздела сформулирована одним предложением.
- Определены аудитория, целевое действие и связь с общей воронкой.
- Проверено, может ли платформа безопасно работать в папке.
- Назначены ответственные за контент, разработку, данные и инфраструктуру.
- Учтены DNS, HTTPS, резервное копирование и мониторинг.
- Спроектированы меню, хлебные крошки и контекстные ссылки.
- Заданы правила для canonical, robots.txt и sitemap.
- Проверены cookie, согласия, формы, CRM и сохранение источника.
- Для миграции подготовлена карта старых и новых URL.
- Есть план проверки кодов ответа, контента и форм после запуска.
- Решение принято по задаче бизнеса, а не по обещанию быстрого роста.
FAQ
Что лучше для SEO: поддомен или папка?
Для раздела, тесно связанного с основным сайтом, чаще практичнее папка. Поддомен выбирают при реальном обособлении продукта, аудитории или инфраструктуры. Универсального преимущества в позициях нет.
Нужно ли переносить существующий блог?
Не обязательно. Найдите деловую или техническую причину, изучите данные и оцените риск. Миграция только ради надежды на рост может принести больше ошибок, чем пользы.
Можно ли разместить магазин на поддомене?
Можно, если он технически и операционно отделён. Если каталог является основным способом продажи, папка часто упрощает навигацию, путь покупателя и аналитику.
Нужен ли поддомену отдельный sitemap?
Удобно формировать карту с каноническими URL этого хоста и отдельно следить за обработкой. Закрытые страницы, параметры и случайные дубли в неё не включают.
Как связать поддомен с основным сайтом?
Добавьте навигацию в обе стороны, контекстные ссылки и согласованный путь к целевому действию. Не прячьте единственную связь в футере.
Нужен ли canonical со всех страниц поддомена на главную?
Нет. Он должен вести на эквивалентную предпочтительную страницу. Массовая ссылка на главную не делает разные документы дублями и мешает диагностике.
Как проверить решение после запуска?
Проверьте коды ответа, контент, canonical, sitemap, ссылки, HTTPS, формы и сохранение источника. Затем наблюдайте за индексированием, входными страницами, серверными ошибками и обращениями, сравнивая результат с исходным состоянием.
Итог
Папка подходит разделам, которые остаются частью одного сайта и одной воронки. Поддомен нужен самостоятельным продуктам и технически обособленным системам. Хорошая архитектура делает путь пользователя понятным, не создаёт лишней нагрузки и проверяется реальными сценариями.
Если хотите разобрать архитектуру, миграцию и технические сигналы для вашего сайта, напишите в Telegram. Для подготовки структуры, черновика и FAQ с последующей редакторской проверкой можно использовать XelaGroup.
Нужно выбрать архитектуру раздела?
Разберём роль страниц, технические ограничения, связи, перенос и контроль после запуска.

