Корпоративный сайт
apg-is.ruПоисковый контур инженерной компании: корпоративные направления и проектная тематика.
КЕЙС
ИНЖИНИРИНГ / SEO
АПОГЕЙ
Два поисковых контура: инженерный B2B и продукт УККРР.
apg-is.ruapg-it.ru
НАПРАВЛЕНИЕ · 01
Инженерный B2B: семантика, структура и проектные доказательства
Для корпоративного сайта apg-is.ru поисковая структура строилась вокруг разных формулировок инженерной потребности: вид работ, система или технология, задача и объект, отраслевой контекст, опыт компании.
Предметный язык бизнеса переводился в структуру страниц и поисковых точек входа. Проектная страница здесь — не декоративное портфолио, а отдельный уровень поисковой архитектуры.
КЕЙС · 01 · ИНЖЕНЕРНЫЙ B2B / SEOОт языка инженеров к поисковой архитектуре apg-is.ruКак я связывал виды работ, технические системы и реальные проекты с отдельными задачами поиска — вместо одной общей страницы «Услуги».
01 / ОТ ОБЩЕГО САЙТА К ЗАДАЧЕ ЗАКАЗЧИКА
Искать подрядчика и искать инженерное решение — не одно и то же
АПОГЕЙ работает не с одной массовой услугой, а с разными инженерными направлениями. В ранних материалах сайта был большой приветственный блок и баннер программного продукта «План-Контроль». Они знакомили с компанией, но не давали отдельного ответа человеку, который приходит из поиска с конкретной технической задачей.
Поэтому я начинал не с SEO-текстов: сначала разделял темы, которым нужна собственная содержательная страница, и задачи, которые логичнее раскрыть внутри более широкого направления. Иначе соседние страницы начинают отвечать на один запрос, а узкая задача остаётся без своего входа.
Поисковая архитектура начинается там, где язык бизнеса встречается с конкретным вопросом заказчика — и на сайте есть понятный ответ.
КАК ФОРМУЛИРУЕТ ЗАДАЧУ ЗАКАЗЧИК
Не «прочитать о компании», а найти решение
Модернизировать АСКУЭ и организовать технический учёт
Спроектировать электроснабжение, выполнить СМР или ПНР
Внедрить диспетчеризацию, телемеханику или СКС
Найти похожий выполненный объект и оценить опыт подрядчика
02 / КАРТА СПРОСА
Одна инженерная компания — пять способов искать её в интернете
Я собирал семантику не как список частотных слов, а как карту поисковых намерений: человек может искать работу, систему, задачу, отраслевой контекст или похожий выполненный объект.
01
Вид работ
Проектирование, ПНР, СМР, аудит, комплексная поставка. Коммерческая страница конкретной услуги.
02
Инженерная система
АСКУЭ и АИИСКУЭ, РЗА, СКС, телемеханика, диспетчеризация. Профильная посадочная или предметный раздел.
03
Задача заказчика
Модернизация учёта, оснащение объекта, управление замечаниями. Страница услуги и релевантный проект.
04
Отраслевой контекст
Нормативные требования, в том числе проекты АИИСКУЭ по 522-ФЗ. Содержательный ответ с нужным контекстом.
05
Опыт на похожем объекте
Заказчик ищет подрядчика, выполнявшего аналогичную инженерную задачу. Карточка конкретного выполненного проекта.
03 / ПРЕДМЕТНЫЙ ЯЗЫК → СТРУКТУРА САЙТА
Внутренние технические документы стали картой предметных тем
Я не переносил внутренние подразделения в бесконечную страницу «Услуги». На текущем apg-is.ru отдельно представлены автоматизация, проектно-изыскательские работы, комплексная поставка, энергетический аудит и другие направления. Но для содержательной страницы нужно понимать и язык конкретных операций.
В актуальном прайс-листе АПОГЕЯ на 2025 год перечислены 15 типовых операций. Меня интересовали не цены для публичной страницы, а сущности, которыми реально оперирует бизнес: интеллектуальные приборы учёта, каналы связи, УСПД, телемеханика, базы данных.
Я сопоставлял эти формулировки с поисковыми запросами, техническими системами и выполненными объектами. За отдельной страницей оставалась собственная задача: что решается, для каких объектов, с какими системами, какой опыт это подтверждает и как обратиться.
15 типовых операцийПредметный материал компании, прайс-лист 2025 года; не SEO-показатель.
Связать интеллектуальный прибор учёта с ПО верхнего уровня
Настроить ИПУ для телесигнализации и телемеханики
Создать и наполнить базу данных по каналам связи
Настроить УСПД и централизованное управление устройствами
Не список цен → источник технической терминологии
Услуга→система→операция→объект→выполненный проект
04 / ПРОЕКТЫ — ВТОРОЙ УРОВЕНЬ АРХИТЕКТУРЫ
Страница услуги объясняет компетенцию. Проект показывает, где она применялась
Портфолио АПОГЕЯ охватывает энергетические, промышленные и инфраструктурные объекты: АСКУЭ, СКС, технический учёт, видеостены, мультимедиа, безопасность и другие системы. В поисковой архитектуре выполненный объект не должен быть просто фотографией рядом с услугой.
40отдельных карточек выполненных проектов на apg-is.ru в текущей версии портфолио компании.
КОММЕРЧЕСКАЯ СТРАНИЦА
Какие работы выполняет компания?
Объясняет услугу, типы объектов и систем, состав работ и условия обращения.
СТРАНИЦА ВЫПОЛНЕННОГО ПРОЕКТА
Где это уже делали и насколько задача похожа?
Показывает конкретный объект, инженерную задачу, систему и связь с нужным направлением.
Модернизация АСКУЭИнженерный контекст для направления учёта электроэнергии.
Строительство СКСПредметное подтверждение опыта в сетевой инфраструктуре.
Оснащение зала заседанийКонкретный объект для мультимедийного направления.
05 / КАК ЗАПРОС ПОЛУЧАЕТ СВОЮ СТРАНИЦУ
Не «один ключ — одна страница». Один ясный ответ — одна самостоятельная задача
Одно техническое слово ещё не говорит, какая страница нужна человеку. Например, запросы вокруг АСКУЭ и АИИСКУЭ могут вести к проектированию, модернизации, ПНР, нормативному контексту или поиску выполненного объекта. Я разделял эти намерения, чтобы страницы не конкурировали друг с другом.
ОБЩАЯ ПРЕДМЕТНАЯ ОБЛАСТЬАСКУЭОдна система — разные вопросы заказчика
Проектирование АСКУЭКоммерческая страница о проектировании.
Модернизация учётаСодержательная посадочная под эту задачу.
АИИСКУЭ и 522-ФЗРелевантный отраслевой и нормативный контекст.
Похожий выполненный объектКарточка проекта как подтверждение опыта.
Услуга→релевантный проект→смежное направление→обращение
06 / СМЫСЛ ПРОДЕЛАННОЙ РАБОТЫ
Архитектура должна показывать реальную инженерную компетенцию, а не множить одинаковые тексты
Для меня правильная структура — это когда виды работ, технические системы и проекты связаны, но не подменяют друг друга. Человек находит ответ на свою задачу и может посмотреть похожий выполненный объект.
Я не превращал все 40 карточек в одинаковые SEO-страницы с заменённым названием. Смысл отдельного проекта — сохранить его инженерную задачу, контекст и полезную связь с коммерческим направлением.
Направление отвечает на самостоятельную задачу, а не растворяется в общем перечне.
Технические термины соотносятся с реальными работами и системами компании.
Карточка проекта сохраняет объект, инженерную задачу и связь с услугой.
МАТЕРИАЛЫ КЕЙСА
Как связаны аудит, семантика и архитектура
Здесь можно посмотреть рабочий разбор структуры, открыть книгу с URL и тематическими кластерами, изучить семантическую модель и карту направлений. Изображения открываются в полном размере, таблицы — отдельными файлами.
Аудит структуры двух сайтов
Карта поисковой архитектуры apg-is.ru
НАПРАВЛЕНИЕ · 02
УККРР: отдельный продуктовый поисковый контур
apg-it.ru решает другую задачу, чем корпоративный B2B-сайт: здесь человек выбирает отдельный программный продукт, а не подрядчика по инженерным работам.
Поэтому структуру сайта я выстраивал вокруг проблемы, ролей участников, функций и сценария использования, переводя техническую документацию УККРР в понятную поисковую и контентную модель — вместо каталога услуг.
КЕЙС · 02 · УККРР / ПРОДУКТОВЫЙ ПОИСК25 страниц технической презентации → продуктовая архитектура apg-it.ruКак я переводил технические функции УККРР в понятный путь пользователя: от проблемы и роли до сценария работы и отдельной поисковой структуры продукта.
01 / ДВА САЙТА — ДВА РАЗНЫХ ВОПРОСА
Продукт нельзя просто добавить в каталог инженерных услуг
apg-is.ru объясняет, какие инженерные работы компания может спроектировать, внедрить или выполнить. apg-it.ru отвечает на другой вопрос: поможет ли УККРР управлять работами, сроками, заявками и участниками проекта.
На корпоративном сайте человек ищет «проектирование АСКУЭ» или «ПНР электроснабжения». В продуктовом поиске он формулирует проблему иначе: «контроль работ на строительном объекте», «учёт замечаний подрядчиков», «программа для управления работами на объекте».
Поэтому для УККРР я выстраивал отдельную продуктовую информационную воронку, а не ещё одну ветку каталога B2B-услуг.
Один бизнес, но две разные задачи поиска: выбрать инженерного подрядчика или понять, как использовать программный продукт.
ЧТО ИЩЕТ ПОЛЬЗОВАТЕЛЬ ПРОДУКТА
Как контролировать задачи, заявки и замечания?
Какая роль у заказчика, подрядчика и исполнителя?
Как выглядит последовательность работы в системе?
Есть ли реальные сценарии и основания доверять продукту?
02 / ОТ ТЕХНИЧЕСКОЙ ПРЕЗЕНТАЦИИ К ПОНЯТНОЙ СТРАНИЦЕ
25 страниц функций я переводил в последовательность выбора
Исходная презентация УККРР показывает создание договора, ввод данных, импорт XLS, привязку операторов, фильтры, отчётные формы и выгрузку; отдельно — назначение заявки бригаде, карту, журнал действий и мобильное приложение.
Для человека, знакомого с продуктом, это подробная документация. Но посетителю из поиска сначала нужно понять что это за система, кто в ней работает и какую задачу она решает. Именно в такой последовательности я собирал продуктовый сценарий сайта.
УККРР представлен как программное обеспечение для контроля выполнения инженерных работ: проектных, монтажных, пусконаладочных и технического обслуживания оборудования.
Технический материал → продуктовая логикаНе переносить экран за экраном, а объяснить последовательность использования.
Что такое УККРР и какие работы контролирует система
Кто участвует в процессе и какие у каждого задачи
Постановка задач, данные проектов, статистика и взаимодействие
Порядок работы, мобильные сценарии и следующий шаг пользователя
Специалисты по организации строительстваВидят проект и контроль выполнения работ.
Инженеры подрядчиков и заказчиковРаботают с инженерными задачами и данными проекта.
Монтажные группы и исполнителиПолучают задачи и взаимодействуют с ними в работе.
03 / СЦЕНАРИЙ ВМЕСТО СПИСКА ФУНКЦИЙ
Шесть этапов показывают, как человек работает в системе
На текущей продуктовой странице функциональность выстроена в последовательность: от создания договора до отчёта. Пользователю не нужно сначала изучать всю техническую презентацию.
Создание договораНачало рабочего контура проекта.
Ввод данныхПодготовка информации и импорт XLS.
Привязка операторовСвязь участников с договором и задачами.
Настройка и фильтрыПараметры и нужные срезы информации.
РедактированиеОбновление договора и связанных данных.
Отчёты и выгрузкаРезультат процесса в форме отчётных данных.
Отдельный мобильный контур: работа с заявкой, создание новой, поиск и оперативное изменение задач и планов. Для участников на строительном объекте это самостоятельный сценарий использования, а не мелкая дополнительная функция.
04 / ПОИСКОВАЯ МОДЕЛЬ ПРОДУКТА
Здесь семантика строится не вокруг инженерных услуг
Для УККРР я рассматривал четыре слоя интереса. Один пользователь ищет способ контролировать сроки и замечания; другой хочет понять работу заказчика или подрядчика; третий — конкретные функции: заявки, фильтры, карты, отчёты.
У этих запросов разная глубина. Структура должна отвечать на нужный вопрос последовательно, а не повторять одинаковое описание программы на каждой странице.
ПроблемаКонтроль работ, сроков, заявок и замечаний.
РольРабочие задачи заказчика, подрядчика, инженера и монтажной группы.
ФункцияДоговоры, заявки, фильтры, карты, документы и отчёты.
ДовериеСценарии применения, регистрация ПО и подтверждаемая информация о продукте.
Мобильная работа — отдельный поисковый интерес. Заявка, её ввод, поиск и оперативное обновление на месте работ должны быть понятны без чтения всей документации продукта.
05 / ДВА ЧИСТЫХ ПОИСКОВЫХ КОНТУРА
Разделение доменов сохраняет смысл, семантику и путь пользователя
Инженерные работы, системы и объекты требуют одного набора посадочных страниц. Управление проектом, заявки, сроки и мобильная работа — другого. Обе темы могут относиться к одной компании, но не должны растворяться в одной общей странице.
apg-is.ruКорпоративный инженерный B2B
«Можете ли вы спроектировать, смонтировать или модернизировать?» Человек проверяет компетенцию подрядчика, технические системы и выполненные проекты.
apg-it.ruОтдельный программный продукт УККРР
«Поможет ли система управлять работами и участниками?» Человек изучает назначение ПО, роли, функции, сценарии, интерфейс и доверие к продукту.
Результат моей работы — две разные модели объяснения и поиска. Корпоративный сайт сохраняет связь с собственным ПО компании и направляет к УККРР, но техническая разработка самой программы не относится к моей роли. На продуктовом сайте отдельно представлены три группы участников и шесть этапов сценария. Это структура содержания, а не показатели SEO-трафика.
МАТЕРИАЛЫ КЕЙСА
Продуктовая карта: от проблемы до обращения
На карте собраны разные уровни продуктовой архитектуры УККРР: пользователи, рабочий процесс, функции, мобильные сценарии и основания доверия. Она помогает увидеть, почему для apg-it.ru нужна собственная структура, а не копия каталога инженерных услуг.
КЕЙС · 03 · SEO / ДВА ДОМЕНАДва домена → единый SEO-цикл контроля и развитияКак я связывал архитектуру страниц, семантику, индексацию и поисковую аналитику для apg-is.ru и apg-it.ru — без смешения инженерного B2B и продуктового спроса.
01 / SEO ЗАКЛАДЫВАЛОСЬ В РАЗРАБОТКУ
Сначала архитектура страницы, потом — поисковый контроль
Для меня структура сайта и SEO в этом проекте были одной задачей. Заголовки, названия страниц, тематические разделы, мета-информация, внутренние ссылки и связь коммерческих страниц с проектами работали внутри заранее определённой архитектуры.
Если сначала собрать сайт только по внутренней логике компании, а потом «подключить SEO», быстро выясняется, что части спроса просто некуда приземляться. Поэтому семантика влияла на архитектуру ещё на этапе разработки.
Ключевой вопрос был не «где добавить ключевое слово», а какая страница должна стать точкой входа для конкретной задачи.
БАЗОВАЯ СВЯЗКА
01Спрос и формулировка задачи
02Релевантная страница и структура
03Индексация и поисковая реакция
04Поведение и следующий шаг развития
02 / ПОИСКОВАЯ АНАЛИТИКА КАК ОДИН КОНТУР
Три инструмента отвечали на разные части одного вопроса
Яндекс Вебмастер, Google Search Console и Roistat я не рассматривал как независимые сервисы. Они дополняли друг друга: от того, какую страницу считает релевантной поиск, до поведения пользователя после перехода.
Яндекс Вебмастер
Запросы, показы, клики, CTR, средняя позиция и URL, который поисковик связывает с конкретной формулировкой.
Google Search Console
Второй слой проверки: какие темы получают показы, какие страницы связаны с запросами и где появляется потенциал для расширения.
Roistat
Маркетинговый слой: не только «нас нашли», но и какая посадочная участвовала в пути пользователя и обращении.
запрос→URL→индексация / видимость→поведение→решение по структуре
03 / НЕ «РАЗ В МЕСЯЦ СНЯТЬ ПОЗИЦИИ»
Рабочий цикл повторялся по мере развития бизнеса
На длинном проекте поисковая работа была не отчётом по одной метрике, а повторяющейся системой: увидеть сигнал, сопоставить его с архитектурой, встроить новый материал и проверить реакцию поиска.
От поискового сигнала — к следующему изменению сайта
01СигналКакие запросы и страницы уже получают видимость.
02СопоставлениеЕсть ли у запроса нормальная посадочная и нет ли конкуренции страниц.
03Новое у бизнесаПроект, система, направление или технический документ.
04РешениеНовая страница, расширение текущей, проектная карточка или связь между разделами.
05КонтрольИндексирование, запросы и релевантный URL после обновления.
06ПоведениеЧто происходит после перехода и что нужно улучшить дальше.
Пятилетний горизонт важен именно здесь: сайт, проекты, документы и продукт менялись, поэтому архитектуру приходилось развивать так, чтобы новые материалы не разрушали уже существующие точки входа.
04 / ДВА ДОМЕНА — ОДИН УПРАВЛЯЕМЫЙ SEO-КОНТУР
Контроль общий, поисковые маршруты разные
apg-is.ru и apg-it.ru относятся к одному бизнесу, но отвечают на разные типы спроса. Управлять ими как дублями нельзя: у корпоративного B2B и продуктового контура разные намерения, страницы и логика следующего действия.
apg-is.ruКорпоративный инженерный B2B
- работы и инженерные системы
- проектные страницы как доказательство компетенции
- тематические посадочные и long-tail через реальные объекты
apg-it.ruОтдельный продуктовый контур УККРР
- проблема и сценарий использования
- роли участников и функциональные блоки
- путь от задачи пользователя к продукту и обращению
общая логика контроляСемантикаСтруктураИндексацияАналитика
Моя задача была не смешать два сайта в одну универсальную витрину, а поддерживать две разные модели поиска внутри единого цикла семантики, структуры, индексации и аналитики.
05 / АРХИТЕКТУРА ДОЛЖНА ВЫДЕРЖИВАТЬ ИЗМЕНЕНИЯ
Пять лет — это не поддержка одного и того же сайта
Добавлялись новые выполненные объекты, развивался программный продукт, появлялись новые документы и менялось публичное представление компании. Каждый новый материал нужно было встроить в уже работающую структуру.
Новый проект не автоматически становился отдельной посадочной. Его можно было оставить в портфолио, связать с услугой, использовать как подтверждение компетенции или расширить тематический блок — в зависимости от поисковой задачи.
Новый объектПроверить, усиливает ли он существующую тему или открывает отдельный поисковый вход.
Новая система или направлениеСопоставить с запросами и решить, нужна ли собственная посадочная.
Новый технический документПеревести внутренний язык бизнеса в понятную предметную структуру.
Изменение продукта УККРРСохранять логику «проблема → сценарий → функция → подтверждение → действие», а не наращивать список функций.
Главный результат — два поисковых маршрута, а не «два сайта».
На одном домене заказчик приходит через инженерную задачу или выполненный объект. На втором — через проблему управления проектом и сценарий использования ПО. SEO остаётся частью архитектуры и развития, а не отдельной надстройкой после запуска.
МАТЕРИАЛЫ КЕЙСА
Индексация, семантика и двухдоменная архитектура
Три материала показывают разные уровни одного рабочего контура: контроль важных URL, связь семантики со структурой и общую модель двух доменов.
