Поддомен или папка: где разместить новый раздел сайта

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

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

Один адрес ещё не объясняет устройство проекта

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

Спросите разработчика, как именно меняется выпуск. Можно ли обновить раздел без остановки остальных частей? Что произойдёт при его ошибке? Какие данные и компоненты остаются общими? Эти ответы определяют эксплуатационную независимость. Не считайте её подтверждённой только названием адреса. Аналогично общая шапка не доказывает, что вход, поиск и настройки доступны одинаково во всех частях.

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

Как посетитель попадёт в новый раздел и вернётся

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

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

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

Доступ и браузерные границы проверяются отдельно

В описании same-origin policy на MDN origin определяется сочетанием схемы, хоста и порта. Разные пути на том же origin и другой хост — не одно и то же для браузерных правил. Но это не означает, что любой поддомен автоматически решает все вопросы защиты. Настройки приложения, доступа и обмена требуют отдельной проверки; адрес является частью условий, а не готовой системой безопасности.

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

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

Для поиска сначала нужна понятная структура содержимого

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

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

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

Аналитика должна отражать переход, а не терять его

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

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

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

Что передать на разработку и принять после запуска

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

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