Разработка сайта юридической компании на 1С-Битрикс

Разработка сайта юридической компании на 1С-Битрикс

Сайт юридической компании — это не визитка. Это инструмент, который должен пройти проверку Google на YMYL (Your Money or Your Life), выдержать E-E-A-T-оценку и при этом конвертировать посетителя в клиента. Юридическая тематика входит в тройку самых жёстких ниш по требованиям к качеству контента: рядом — медицина и финансы. Если сайт стоматологии может ранжироваться с посредственным контентом за счёт локальных факторов, то сайт юридической компании без авторских статей, привязанных к конкретным юристам с подтверждённой квалификацией, просто не попадёт в топ-10. Битрикс позволяет собрать такой сайт, но архитектура данных должна с самого начала учитывать E-E-A-T-сигналы — иначе потом придётся переделывать контентную модель на живом проекте.

E-E-A-T как основа архитектуры, а не SEO-надстройка

E-E-A-T — это Experience, Expertise, Authoritativeness, Trustworthiness. Для юридического сайта каждый компонент имеет конкретную техническую реализацию.

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

Expertise — подтверждённая экспертиза. Поля инфоблока «Юристы»: PROPERTY_BAR_ADMISSION (дата и номер допуска), PROPERTY_EDUCATION (множественное — вуз, степень, год), PROPERTY_CERTIFICATIONS (множественное — сертификаты, повышение квалификации). Эти данные не просто выводятся на страницу — они размечаются через Schema.org Person с полями hasCredential, alumniOf, knowsAbout.

Authoritativeness — ссылки и упоминания. Технически на стороне сайта это реализуется через: публикации юристов в сторонних изданиях (хранятся в свойстве PROPERTY_EXTERNAL_PUBLICATIONS — URL + название издания), участие в конференциях, цитирование в СМИ. Каждая внешняя публикация — это sameAs в Schema.org-разметке юриста.

Trustworthiness — доверие. SSL, юридический адрес в футере, реквизиты компании, ссылки на реестры (адвокатская палата, ЕГРЮЛ). На техническом уровне: страница «О компании» с Schema.org LegalService, включающим address, telephone, foundingDate, numberOfEmployees, ссылки на профили в юридических каталогах.

Ключевой момент: E-E-A-T — это не чеклист, который заполняешь один раз. Это архитектура данных, которая заставляет контент-менеджера при каждой публикации статьи указывать автора, а при каждом обновлении профиля юриста — добавлять новые кейсы и публикации. Если инфоблоки спроектированы правильно, E-E-A-T поддерживается автоматически. Если нет — через полгода на сайте будут анонимные статьи без авторства, и Google это увидит.

Контентная архитектура: инфоблоки и связи

Структура данных для юридического сайта сложнее, чем для интернет-магазина. Здесь нет «товаров» — есть сущности, связанные перекрёстными ссылками.

Инфоблок «Практики» (Practice Areas)

Разделы верхнего уровня: Корпоративное право, Судебные споры, Интеллектуальная собственность, Налоговое право, Трудовое право. Каждый раздел — это не просто страница с текстом. Это контейнер с элементами — подпрактиками. Корпоративное право → M&A, Due Diligence, Акционерные соглашения, Реструктуризация. Каждый элемент содержит:

• DETAIL_TEXT — развёрнутое описание (3000-5000 знаков), написанное юристом, а не копирайтером
• PROPERTY_LEAD_ATTORNEY — привязка к ведущему юристу (тип E:Iblock, ссылка на инфоблок «Юристы»)
• PROPERTY_RELATED_CASES — привязка к релевантным кейсам (множественное, тип E:Iblock)
• PROPERTY_RELATED_ARTICLES — привязка к статьям блога по теме (множественное, тип E:Iblock)

Таблица b_iblock_section хранит разделы, b_iblock_element — подпрактики. Свойства связи (E:Iblock) создают граф, который Google видит через внутреннюю перелинковку: страница практики → профиль юриста → кейсы → статьи → обратно к практике. Этот граф — основа topical authority.

Инфоблок «Юристы» (Attorneys)

Это центральный инфоблок для E-E-A-T. Минимальный набор свойств:

Шаблон карточки юриста (bitrix:news.detail) выводит все эти данные, а блок Schema.org формируется динамически в component_epilog.php:

{
  "@context": "https://schema.org",
  "@type": "Attorney",
  "name": "Иванов Александр Петрович",
  "jobTitle": "Партнёр, руководитель практики корпоративного права",
  "worksFor": {
    "@type": "LegalService",
    "name": "Название компании"
  },
  "hasCredential": {
    "@type": "EducationalOccupationalCredential",
    "credentialCategory": "Bar Admission",
    "recognizedBy": {
      "@type": "Organization",
      "name": "Адвокатская палата г. Москвы"
    }
  },
  "alumniOf": {
    "@type": "CollegeOrUniversity",
    "name": "МГУ им. М.В. Ломоносова"
  },
  "knowsAbout": ["Corporate Law", "M&A", "Due Diligence"]
}

Инфоблок «Кейсы» (Case Results)

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

• DETAIL_TEXT — описание в формате «Ситуация → Задача → Решение → Результат», без имён
• PROPERTY_PRACTICE — привязка к практике (E:Iblock)
• PROPERTY_ATTORNEYS — юристы, участвовавшие в деле (множественное, E:Iblock)
• PROPERTY_RESULT_TYPE — тип результата: L (список) — «Выигранное дело», «Мировое соглашение», «Снижение суммы требований», «Прекращение уголовного дела»
• PROPERTY_YEAR — год (для фильтрации)
• PROPERTY_INDUSTRY — отрасль клиента (для фильтрации по индустрии)

Раздел кейсов — это не портфолио в привычном смысле. Это доказательство Experience в E-E-A-T. Google оценивает, есть ли на сайте признаки реальной практики, а не только теоретические статьи. Кейсы, привязанные к конкретным юристам и практикам, создают эту связь.

Юридический блог: SEO-машина для YMYL-ниши

Блог — это инфоблок «Публикации» с разделами-категориями: Корпоративное право, Налоги, Судебная практика, Новости законодательства. Но для юридического блога критична одна вещь, которую многие игнорируют: авторство.

Каждая статья обязана иметь PROPERTY_AUTHOR_ID — привязку к юристу из инфоблока «Юристы». Не абстрактный «Редакция», не «Юридическая компания Х», а конкретный человек с лицензией, образованием и опубликованными кейсами. При выводе статьи шаблон bitrix:news.detail подтягивает данные автора через CIBlockElement::GetList по PROPERTY_AUTHOR_ID и рендерит блок:

• Фото автора
• Имя и должность
• Специализация (ссылка на практику)
• Дата допуска к адвокатуре
• Количество статей и кейсов

Этот блок размечается как author в Schema.org Article:

{
  "@type": "Article",
  "headline": "Как пройти налоговую проверку: чек-лист для бизнеса",
  "author": {
    "@type": "Person",
    "@id": "/attorneys/petrov-ivan/",
    "name": "Петров Иван Сергеевич",
    "jobTitle": "Старший юрист, налоговая практика",
    "hasCredential": { ... }
  },
  "publisher": {
    "@type": "LegalService",
    "name": "Название компании"
  },
  "datePublished": "2025-10-15",
  "dateModified": "2025-11-02"
}

Обратите внимание на @id у автора — это ссылка на его профиль. Google связывает все статьи одного автора в единый «авторский граф», что усиливает E-E-A-T каждой отдельной статьи. Если юрист написал 15 статей по налоговому праву, каждая следующая ранжируется лучше предыдущей.

Типичные SEO-статьи для юридического блога, которые дают трафик:

• «Как зарегистрировать ООО в 2025 году» — процедурный контент, высокий поисковый объём
• «Чек-лист подготовки к налоговой проверке» — утилитарный контент, высокая конверсия
• «Изменения в Трудовом кодексе с 1 января 2025» — новостной контент, пик трафика при публикации
• «Корпоративный договор: когда он нужен и что в нём прописать» — глубокий экспертный контент

Онлайн-консультация: от формы до CRM-лида

Форма записи на консультацию — это не просто «имя + телефон + сообщение». Для юридической компании критически важна маршрутизация: клиент с вопросом по налогам не должен попадать к юристу по IP.

Реализация через bitrix:form.result.new (модуль form) или кастомный компонент с REST API Битрикс24. Поля формы:

• Имя, телефон, email — стандартно
• Область права — выпадающий список, подтягивается из разделов инфоблока «Практики» через API
• Предпочтительный юрист — опционально, список из инфоблока «Юристы»
• Срочность — три уровня: «Плановая консультация», «В течение 3 дней», «Срочно (24 часа)»
• Краткое описание ситуации — textarea

При отправке формы создаётся лид в Битрикс24: crm.lead.add с полями TITLE (формируется автоматически: «Консультация: Налоговое право — Иванов»), SOURCE_ID, UF_CRM_PRACTICE_AREA, UF_CRM_PREFERRED_ATTORNEY, UF_CRM_URGENCY. Если указан предпочтительный юрист — лид сразу назначается на него. Если нет — роутинг по UF_CRM_PRACTICE_AREA через бизнес-процесс в CRM.

Клиентский портал: документы и статус дела

Личный кабинет клиента — это отдельная история, выходящая за рамки публичной части. Реализация на Битриксе через модуль extranet или кастомный раздел с авторизацией.

Структура: группы пользователей по клиентам (каждый клиент — отдельная группа), Highload-блок «Документы» с полями CLIENT_GROUP_ID, FILE, CASE_ID, STATUS, DATE_UPLOAD. Клиент видит только свои документы — фильтрация по $USER->GetUserGroupArray().

Статус дела — Highload-блок «Дела» с полями CLIENT_GROUP_ID, PRACTICE_ID, STATUS (список: «Подготовка документов», «Подано в суд», «Назначено заседание», «Вынесено решение»), ATTORNEY_ID, NEXT_ACTION, NEXT_ACTION_DATE. Клиент видит timeline своего дела без деталей, которые юрист не готов раскрывать.

Мультиофисность и Schema.org

Если у компании несколько офисов — каждый офис хранится в Highload-блоке с полями: CITY, ADDRESS, PHONE, EMAIL, COORDINATES, WORKING_HOURS, MAP_EMBED. На главной странице — выбор города, который сохраняется в cookie и влияет на вывод контактов в шапке и футере.

Schema.org для юридической компании:

{
  "@context": "https://schema.org",
  "@type": "LegalService",
  "name": "Название компании",
  "url": "https://site.ru",
  "logo": "https://site.ru/logo.png",
  "foundingDate": "2005",
  "numberOfEmployees": {
    "@type": "QuantitativeValue",
    "value": 25
  },
  "address": [
    {
      "@type": "PostalAddress",
      "addressLocality": "Москва",
      "streetAddress": "ул. Тверская, 1"
    }
  ],
  "employee": [
    { "@type": "Attorney", "@id": "/attorneys/ivanov/" },
    { "@type": "Attorney", "@id": "/attorneys/petrov/" }
  ],
  "knowsAbout": ["Corporate Law", "Litigation", "Tax Law", "IP Law"]
}

Скачивание шаблонов документов: gated content

Раздел с шаблонами (договоры, доверенности, заявления) — это инструмент лидогенерации. Посетитель видит название и описание документа, но для скачивания вводит email. Реализация: инфоблок «Шаблоны документов» с PROPERTY_FILE (файл) и PROPERTY_PREVIEW_TEXT (описание). Кнопка «Скачать» вызывает AJAX-форму с полем email. После ввода: email добавляется в сегмент Битрикс24 через crm.contact.add, посетителю выдаётся прямая ссылка с одноразовым токеном на скачивание. Токен — запись в Highload-блоке DownloadTokens с TTL 24 часа.

Этапы и сроки

1. Аналитика, контент-стратегия (1-2 недели) — структура практик, карта контента, E-E-A-T-требования
2. Дизайн (2-3 недели) — UI профилей юристов, блога, кейсов, мобильная версия
3. Разработка ядра (3-5 недель) — инфоблоки, связи, шаблоны, Schema.org-разметка
4. Контентные модули (2-3 недели) — блог, кейсы, шаблоны документов, формы
5. Интеграции (1-2 недели) — CRM, клиентский портал, email-маркетинг
6. Тестирование, SEO (1-2 недели) — проверка E-E-A-T-сигналов, микроразметка, Core Web Vitals

Сроки предполагают, что контент (тексты практик, профили юристов, первые 15-20 статей блога) готовится параллельно с разработкой. Если контента нет — закладывайте дополнительно 4-6 недель на работу с юристами компании, потому что писать юридический контент за них копирайтер не может — Google это распознаёт.