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

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

Сайт юридичної компанії працює в умовах, яких більшість бізнес-сайтів ніколи не зустрічає. Google класифікує юридичний контент як YMYL (Your Money or Your Life) і застосовує E-E-A-T-оцінку з тією ж суворістю, що й до медичних та фінансових сайтів. Стоматологічна клініка може ранжуватися локально з посереднім контентом. Юридична компанія — ні. Без авторських статей, прив'язаних до конкретних юристів із підтвердженою кваліфікацією, сайт не потрапить у топ-10 за жодним конкурентним запитом. Бітрікс дозволяє побудувати такий сайт, але архітектура даних має враховувати E-E-A-T-сигнали з першого дня — перебудовувати модель авторства на живому сайті з 200 анонімними статтями блогу — це окремий проєкт.

E-E-A-T як архітектура даних

E-E-A-T — це Experience (досвід), Expertise (експертиза), Authoritativeness (авторитетність), Trustworthiness (довіра). Для юридичного сайту кожен компонент має конкретну технічну реалізацію в інфоблоках і Schema.org-розмітці.

Experience означає демонстрацію того, що автор контенту реально практикує те, про що пише. В термінах Бітрікса: кожна стаття блогу має PROPERTY_AUTHOR_ID — посилання на інфоблок «Юристи». Картка юриста містить не загальну біографію, а список справ, у яких він брав участь, публікації в юридичних виданнях, дату допуску до адвокатури. Оцінювачі якості Google шукають саме це — сигнали реальної практики, а не теоретичні огляди.

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/petrenko-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-ліда

Форма запису на консультацію — це не просто «ім'я + телефон + повідомлення». Для юридичної компанії критично важлива маршрутизація: клієнт із питанням щодо податків не повинен потрапити до юриста з інтелектуальної власності.

Реалізація через 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 своєї справи без деталей, які юрист не готовий розкрити.

Шаблони документів: gated content для лідогенерації

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

Мультиофісність та 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.ua",
  "logo": "https://site.ua/logo.png",
  "foundingDate": "2005",
  "numberOfEmployees": {
    "@type": "QuantitativeValue",
    "value": 25
  },
  "address": [
    {
      "@type": "PostalAddress",
      "addressLocality": "Київ",
      "streetAddress": "вул. Хрещатик, 1"
    }
  ],
  "employee": [
    { "@type": "Attorney", "@id": "/attorneys/ivanenko/" },
    { "@type": "Attorney", "@id": "/attorneys/petrenko/" }
  ],
  "knowsAbout": ["Corporate Law", "Litigation", "Tax Law", "IP Law"]
}

Етапи та терміни

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 це розпізнає.