Москва
Портал без карты URL превращается в личный кабинет, который поиск не видит. Сначала — какие сущности в индексе, потом дизайн.
От 400 000 ₽, разово. Смету считаем после состава страниц.
Агрегаторам, отраслевым витринам и сервисам с кабинетами, где часть страниц должна собирать спрос. Не корпоративу на 10 страниц.
ТЗ и каркас, где публичные URL можно продвигать. Сроки и стек считаем после состава сущностей, не «портал под ключ за месяц».
У портала публичный и закрытый контур перемешаны по умолчанию. До дизайна надо зафиксировать, какие сущности должны попадать в индекс, а какие — никогда.
Витрина портала конкурирует с агрегаторами. Побеждает не количество карточек, а полнота и актуальность каждой.
Порталы часто собирают большой информационный трафик, который не конвертируется. Его надо связывать с витриной, иначе это балласт.
Главный риск портала — взрыв дублей на фильтрах, сортировках и пагинации. Это проектная задача, а не задача оптимизатора после запуска.
Разработка портала — это не только интерфейс, каталог и личный кабинет. На выходе должен появиться согласованный набор правил, по которым работают публичные страницы, авторизованные разделы, роли пользователей, фильтры и адреса в поиске.
До начала разработки фиксируется, какие сущности существуют в системе и как они связаны между собой. Это могут быть объекты каталога, компании, услуги, документы, публикации, специалисты, регионы или другие типы данных. Для каждой сущности определяется:
Такой перечень становится основой ТЗ и каркаса будущего сайта. Без него разработка веб-портала быстро превращается в набор разрозненных экранов: каталог существует отдельно, кабинет — отдельно, а поисковая видимость не учитывается в архитектуре.
Клиент получает не абстрактный «портал под ключ», а описанную систему с понятным составом публичных страниц, кабинетов, ролей и служебных разделов. Отдельно прорабатываются правила URL, канонических адресов, шаблонов заголовков и описаний для массовых страниц.
Портал нужен там, где обычного корпоративного сайта недостаточно. Корпоративный сайт рассказывает о компании и её услугах. Портал организует большое количество объектов, пользователей, сценариев и связей между ними.
Информационный портал может объединять публикации, справочные материалы, инструкции, документы и тематические разделы. Но большой объём контента сам по себе не создаёт пользу для бизнеса. Материалы должны помогать посетителю перейти к нужному объекту, услуге или действию.
Например, справочный раздел может вести в каталог, инструкция — объяснять порядок обращения, а публикация — связываться с конкретной услугой или группой объектов. Если информационный контур не связан с коммерческим, портал получает трафик без понятного маршрута к обращению.
Для портала методических разработок особенно важны структура материалов, фильтрация, рубрикация и понятные связи между документами. Пользователь должен быстро найти нужную разработку, понять её назначение и перейти к следующему действию: просмотру, скачиванию, запросу или обращению.
Портал услуг отличается от страницы с перечнем предложений. В нём могут быть разные категории, условия, исполнители, территории, статусы и сценарии обращения. Поэтому нужно заранее определить, какие параметры становятся частью навигации, а какие остаются только фильтрами внутри интерфейса.
Не каждый вариант фильтрации должен создавать отдельную страницу для поисковых систем. Если разрешить индексацию всех комбинаций, появятся многочисленные адреса с похожим или пустым содержанием. Часть таких страниц закрывают от поиска, для других задают канонический адрес, а востребованные сочетания оформляют как полноценные посадочные страницы.
В образовательном портале публичными могут быть описания программ, направлений и материалов, а расписание, результаты, задания и персональные данные — доступны только авторизованным пользователям. Для внутреннего портала компании логика похожая: общая информация может быть открыта, а рабочие документы, задачи и отчёты — доступны по ролям.
Здесь важно не смешивать поисковую оптимизацию с логикой доступа. Страница, которую должен видеть поисковик, не обязана быть доступной для редактирования всем пользователям. И наоборот: раздел, который нужен сотруднику внутри системы, не должен автоматически становиться публичным.
Корпоративный сайт обычно состоит из ограниченного числа разделов: информация о компании, услуги, проекты, контакты, новости. Его задача — представить организацию и привести посетителя к обращению.
Портал предполагает другое устройство. В нём есть каталог объектов, массовые карточки, фильтры, роли, кабинеты, пользовательские действия и большое количество взаимосвязанных страниц. Если для бизнеса достаточно рассказать о компании и собрать обращения, портал будет избыточным и дорогим в сопровождении.
Интернет-магазин строится вокруг товарного каталога, корзины, заказа и оплаты. Портал может включать коммерческий каталог, но его модель часто шире: разные типы пользователей, публикации, документы, заявки, профили организаций, рейтинги, статусы или обмен данными.
Поэтому при разработке b2b-портала важно описать не только карточку объекта, но и отношения между участниками. Один пользователь может представлять организацию, другой — отвечать за заявку, третий — управлять публикациями. Эти сценарии нельзя надёжно заменить обычной формой заказа.
Информационный сайт в основном работает с текстами, статьями и рубриками. Портал может содержать информационный раздел, но не ограничивается им. Его ценность — в сочетании контента, структуры данных, пользовательских ролей и действий.
Если проект называют информационным порталом только из-за большого количества статей, сначала стоит проверить, действительно ли нужна сложная система. Иногда достаточно грамотно спроектированного информационного сайта с поиском, рубрикатором и понятной навигацией.
О разработке портала стоит говорить, если у проекта есть несколько признаков:
Если задача сводится к презентации компании, описанию нескольких услуг и размещению контактов, разумнее рассмотреть разработку сайтов или корпоративный формат.
Отдельный случай — проект, который уже существует, но его трудно развивать. Признаки проблемы: новые разделы создаются вручную, фильтры порождают лишние адреса, сотрудники не понимают права доступа, а пользователи не могут найти нужный объект. Тогда перед переделкой полезен технический аудит, чтобы отделить ошибки архитектуры от проблем продвижения.
Визуальная концепция не отвечает на вопросы о сущностях, ролях и индексируемых страницах. Красивые макеты могут оказаться непригодными для массового каталога или привести к переделке, когда выяснится, что один экран должен работать для нескольких типов пользователей.
Сначала описывают данные и сценарии, затем формируют каркас, и только после этого переходят к визуальному оформлению. Такой порядок помогает связать дизайн с реальной логикой проекта.
Открытый доступ не означает, что страницу нужно показывать поисковым системам. Кабинеты, служебные экраны, пустые результаты фильтра, технические варианты сортировки и персональные разделы обычно не являются самостоятельными посадочными страницами.
Для каждого типа адреса нужны правила: индексировать, закрывать, указывать канонический URL или не создавать страницу вообще.
Фильтры полезны пользователю, но не каждая комбинация параметров имеет самостоятельный спрос и содержательную выдачу. При автоматической генерации адресов портал может создать множество почти одинаковых страниц.
Решение закладывают в архитектуру: определяют допустимые комбинации, шаблоны для ценных страниц и поведение остальных вариантов. Исправлять эти правила после наполнения каталога сложнее, потому что адреса уже могли попасть в индекс и внутренние ссылки.
Для каталога важнее не количество карточек, а их актуальность и полнота. Устаревшая цена, недоступная услуга или неверный контакт ухудшают пользовательский опыт и снижают доверие к площадке.
В ТЗ заранее описывают статусы объектов, порядок снятия с публикации, замену удалённых страниц и действия с временно недоступными предложениями. Иначе сотрудники будут решать эти вопросы вручную и непоследовательно.
Если администратор, редактор, партнёр и обычный пользователь видят одинаковый интерфейс, система быстро становится неудобной и небезопасной. Роли должны быть связаны не только с экранами, но и с действиями: просмотром, созданием, изменением, публикацией, модерацией и удалением данных.
Для кабинетов и внутренней части портала роли описывают отдельно от публичного контура. Это позволяет не выводить рабочую логику на страницы, предназначенные для посетителей и поисковых систем.
Проверять портал нужно не только по внешнему виду. До публикации полезно пройти несколько уровней.
В карте сайта должны быть видны типы сущностей, публичные разделы, кабинеты, служебные страницы и связи между ними. Для каждого массового типа страниц должно быть понятно, откуда берутся данные и по какому шаблону формируется адрес.
Если невозможно объяснить, какие страницы должны собирать поисковый спрос, а какие существуют только для работы пользователя, архитектура ещё не готова.
Нужно пройти путь разных ролей: посетителя, зарегистрированного пользователя, редактора и администратора. Проверяются регистрация, вход, восстановление доступа, создание и изменение данных, отправка заявки, смена статуса и отображение ошибок.
Сценарии проверяют на реальных данных, а не только на пустых макетах. Пустой каталог почти всегда скрывает проблемы с фильтрами, пагинацией и связями между объектами.
Для публичных страниц проверяют доступность для роботов, корректность URL, дубли, канонические адреса, заголовки, описания, внутренние ссылки и обработку удалённых объектов. Отдельно смотрят, не попали ли в индекс кабинеты, служебные страницы и пустые результаты поиска.
После запуска продвижение портала требует отдельной работы: продвижение интернет-портала опирается на уже определённую структуру публичных страниц, а не заменяет её.
SEO-часть работы должна оцениваться по одному и тому же ядру: сравниваются видимость, трафик и обращения. В BURO BAILO отчёт предоставляется раз в месяц и содержит эти показатели в сопоставимом виде.
Договор фиксирует состав работ, KPI — видимость, трафик и заявки — и сроки реакции. Если к четвёртому месяцу при выполненных правках нет движения по среднечастотным запросам, план пересматривается или работы останавливаются. При этом агентство не гарантирует ТОП-1 и конкретное количество заявок и не продаёт оплату «за звонок».
Стоимость разработки портала начинается от 400 000 ₽ разово. Итоговую смету нельзя корректно определить только по названию проекта: она зависит от состава сущностей, количества ролей, публичного и закрытого контуров, правил публикации, фильтров, интеграций и требований к массовым страницам.
На сроки влияют не только программирование и дизайн. В расчёт входят описание логики, согласование ТЗ, подготовка данных, настройка прав, проверка сценариев, перенос существующего контента и тестирование поискового контура. Поэтому срок определяют после фиксации состава сущностей и функций, а не обещают заранее для любого проекта.
Чем раньше согласованы правила URL, индексации и доступа, тем меньше риск переделок после запуска. Для сложного портала это особенно важно: исправление архитектуры на заполненном сайте обычно затрагивает шаблоны, ссылки, данные и пользовательские сценарии одновременно.
Смешанным контуром. В магазине почти всё публичное, в портале часть сущностей должна быть за авторизацией, часть — в индексе, а часть не нужна нигде. Без карты сущностей поиск либо не видит витрину, либо индексирует служебные страницы.
Потому что срок определяется составом сущностей и ролей, а не словом «портал». Сначала фиксируем, что именно должно работать и попадать в поиск, потом считаем стек и сроки. «Портал под ключ за месяц» — это про другой продукт.
Правила генерации адресов описываются в ТЗ до разработки: какие комбинации фильтров создают индексируемую страницу, какие закрываются, где ставится канонический адрес. После запуска это чинится сильно дороже.
