Development of a website for a law firm using 1C-Bitrix

Law Firm Website Development on 1C-Bitrix

A law firm website operates under constraints that most business sites never face. Google classifies legal content as YMYL (Your Money or Your Life) and applies E-E-A-T evaluation with the same rigor it reserves for medical and financial sites. A dental clinic can rank locally with mediocre content. A law firm cannot. Without authored articles tied to named attorneys with verifiable credentials, the site won't break into the top 10 for any competitive query. Bitrix can power this kind of site, but the data architecture must encode E-E-A-T signals from day one — retrofitting an author attribution model onto a live site with 200 anonymous blog posts is a project in itself.

E-E-A-T as Data Architecture

E-E-A-T stands for Experience, Expertise, Authoritativeness, Trustworthiness. For a legal site, each component translates into specific info block properties and Schema.org markup.

Experience means demonstrating that the content author actually practices what they write about. In Bitrix terms: every blog article has a PROPERTY_AUTHOR_ID linking to the Attorneys info block. The attorney's profile card contains not a generic biography but a list of cases they worked on, publications in legal journals, and bar admission dates. Google's quality raters are trained to look for exactly this — first-person practice signals, not theoretical overviews.

Expertise means verifiable credentials. The Attorneys info block stores PROPERTY_BAR_ADMISSION (admission number and date), PROPERTY_EDUCATION (multiple — university, degree, year), PROPERTY_CERTIFICATIONS (multiple — professional development, specialized certifications). These fields aren't decorative — they feed directly into Schema.org Person markup with hasCredential, alumniOf, and knowsAbout properties.

Authoritativeness comes from external recognition. On the site level, this means: external publications by the firm's attorneys (stored in PROPERTY_EXTERNAL_PUBLICATIONS — URL plus publication name), conference speaking engagements, media citations. Each external publication becomes a sameAs link in the attorney's Schema.org markup, connecting the on-site profile to the broader web presence.

Trustworthiness is the baseline. SSL certificate, physical address in the footer, company registration details, links to bar association registries. Technically: an "About" page with Schema.org LegalService including address, telephone, foundingDate, numberOfEmployees, and links to legal directory profiles.

The critical insight: E-E-A-T is not a one-time checklist. It's a data model that forces the content manager to assign an author when publishing any article, and forces profile updates when an attorney wins a case or publishes externally. If the info blocks are designed correctly, E-E-A-T compliance is structural. If they're not, within six months the blog fills with unattributed articles, and Google's algorithms notice.

Content Architecture: Info Blocks and Relationships

The data model for a legal site is more complex than for an e-commerce store. There are no "products" — there are entities linked through cross-references that create a content graph.

Info block: Practice Areas

Top-level sections: Corporate Law, Litigation, Intellectual Property, Tax Law, Employment Law. Each section isn't just a page with text — it's a container with elements representing sub-practices. Corporate Law contains M&A, Due Diligence, Shareholder Agreements, Restructuring. Each element includes:

• DETAIL_TEXT — in-depth description (3000-5000 characters), written by an attorney, not a copywriter
• PROPERTY_LEAD_ATTORNEY — link to the lead attorney (type E:Iblock, reference to Attorneys info block)
• PROPERTY_RELATED_CASES — links to relevant case results (multiple, type E:Iblock)
• PROPERTY_RELATED_ARTICLES — links to related blog posts (multiple, type E:Iblock)

The b_iblock_section table stores sections, b_iblock_element stores sub-practices. The E:Iblock link properties create a graph that Google follows through internal links: practice page links to attorney profile, which links to case results, which link to blog articles, which link back to the practice. This graph is the foundation of topical authority.

Info block: Attorneys

This is the central info block for E-E-A-T. Minimum property set:

The attorney profile template (bitrix:news.detail) renders all of this, and the Schema.org block is built dynamically in component_epilog.php:

{
  "@context": "https://schema.org",
  "@type": "Attorney",
  "name": "John Smith",
  "jobTitle": "Partner, Head of Corporate Practice",
  "worksFor": {
    "@type": "LegalService",
    "name": "Firm Name"
  },
  "hasCredential": {
    "@type": "EducationalOccupationalCredential",
    "credentialCategory": "Bar Admission",
    "recognizedBy": {
      "@type": "Organization",
      "name": "State Bar Association"
    }
  },
  "alumniOf": {
    "@type": "CollegeOrUniversity",
    "name": "Harvard Law School"
  },
  "knowsAbout": ["Corporate Law", "M&A", "Due Diligence"]
}

Info block: Case Results

Legal ethics require anonymization. You cannot publish client names without consent, and settlement amounts are often covered by NDA. So a case element contains:

• DETAIL_TEXT — narrative in "Situation, Task, Solution, Result" format, no names
• PROPERTY_PRACTICE — link to the practice area (E:Iblock)
• PROPERTY_ATTORNEYS — attorneys who worked on the matter (multiple, E:Iblock)
• PROPERTY_RESULT_TYPE — outcome type: L (list) — "Case Won", "Settlement Reached", "Claim Reduced", "Criminal Case Dismissed"
• PROPERTY_YEAR — year (for filtering)
• PROPERTY_INDUSTRY — client's industry (for industry-based filtering)

The case results section isn't a portfolio in the traditional sense. It's proof of Experience in E-E-A-T. Google evaluates whether the site shows evidence of real practice, not just theoretical articles. Cases linked to specific attorneys and practice areas create that evidence.

The Legal Blog: SEO Engine for YMYL Content

The blog is a "Publications" info block with category sections: Corporate Law, Tax, Case Law, Legislative Updates. But one thing is non-negotiable for a legal blog: authorship.

Every article must have PROPERTY_AUTHOR_ID — a link to an attorney in the Attorneys info block. Not "Editorial Team", not "Law Firm X", but a named individual with a license, education credentials, and published case results. The article template (bitrix:news.detail) pulls the author's data via CIBlockElement::GetList on PROPERTY_AUTHOR_ID and renders an author box:

• Author photo
• Name and title
• Specialization (link to practice area)
• Bar admission date
• Article count and case count

This block is marked up as author within the Schema.org Article:

{
  "@type": "Article",
  "headline": "Tax Audit Checklist: What Every Business Needs to Prepare",
  "author": {
    "@type": "Person",
    "@id": "/attorneys/john-smith/",
    "name": "John Smith",
    "jobTitle": "Senior Associate, Tax Practice",
    "hasCredential": { "..." }
  },
  "publisher": {
    "@type": "LegalService",
    "name": "Firm Name"
  },
  "datePublished": "2025-10-15",
  "dateModified": "2025-11-02"
}

Note the @id on the author — it's a reference to the attorney's profile page. Google aggregates all articles by the same author into an "author graph", which strengthens the E-E-A-T signal of each individual article. If an attorney has written 15 articles on tax law, each subsequent article ranks better than the last.

Typical high-traffic article types for a legal blog:

• "How to Register an LLC in 2025" — procedural content, high search volume
• "Tax Audit Preparation Checklist" — utility content, high conversion
• "Employment Law Changes Effective January 2025" — news content, traffic spike on publication
• "Shareholder Agreements: When You Need One and What to Include" — deep expert content

Online Consultation Booking: Form to CRM Lead

The consultation form isn't just "name + phone + message". For a law firm, routing matters: a client with a tax question shouldn't land with an IP attorney.

Implementation via bitrix:form.result.new (the form module) or a custom component with Bitrix24 REST API. Form fields:

• Name, phone, email — standard
• Practice area — dropdown, populated from the Practice Areas info block sections via API
• Preferred attorney — optional, list from the Attorneys info block
• Urgency — three levels: "Scheduled consultation", "Within 3 days", "Urgent (24 hours)"
• Brief description — textarea

On submission, a lead is created in Bitrix24: crm.lead.add with TITLE (auto-generated: "Consultation: Tax Law — Smith"), SOURCE_ID, UF_CRM_PRACTICE_AREA, UF_CRM_PREFERRED_ATTORNEY, UF_CRM_URGENCY. If a preferred attorney is specified, the lead is assigned directly. Otherwise, routing by UF_CRM_PRACTICE_AREA via a CRM business process.

Client Portal: Documents and Case Status

The client portal goes beyond the public site. Implementation on Bitrix via the extranet module or a custom authenticated section.

Structure: user groups per client (each client is a separate group), Highload block "Documents" with fields CLIENT_GROUP_ID, FILE, CASE_ID, STATUS, DATE_UPLOAD. The client sees only their documents — filtered by $USER->GetUserGroupArray().

Case status — a Highload block "Cases" with fields CLIENT_GROUP_ID, PRACTICE_ID, STATUS (list: "Document Preparation", "Filed with Court", "Hearing Scheduled", "Decision Rendered"), ATTORNEY_ID, NEXT_ACTION, NEXT_ACTION_DATE. The client sees a timeline of their case without details the attorney isn't ready to disclose.

Document Templates: Gated Content for Lead Generation

A section with downloadable templates (contracts, powers of attorney, applications) serves as a lead generation tool. The visitor sees the document title and description but must enter their email to download. Implementation: a "Document Templates" info block with PROPERTY_FILE (file) and PROPERTY_PREVIEW_TEXT (description). The "Download" button triggers an AJAX form with an email field. After submission: the email is added to a Bitrix24 segment via crm.contact.add, and the visitor receives a direct link with a single-use token. The token is stored in a Highload block DownloadTokens with a 24-hour TTL.

Multi-Office Support and Schema.org

For firms with multiple offices, each office is stored in a Highload block: CITY, ADDRESS, PHONE, EMAIL, COORDINATES, WORKING_HOURS, MAP_EMBED. The homepage includes a city selector that persists in a cookie and controls which contact details appear in the header and footer.

The top-level Schema.org for the firm:

{
  "@context": "https://schema.org",
  "@type": "LegalService",
  "name": "Firm Name",
  "url": "https://site.com",
  "logo": "https://site.com/logo.png",
  "foundingDate": "2005",
  "numberOfEmployees": {
    "@type": "QuantitativeValue",
    "value": 25
  },
  "address": [
    {
      "@type": "PostalAddress",
      "addressLocality": "New York",
      "streetAddress": "123 Park Avenue"
    }
  ],
  "employee": [
    { "@type": "Attorney", "@id": "/attorneys/smith/" },
    { "@type": "Attorney", "@id": "/attorneys/johnson/" }
  ],
  "knowsAbout": ["Corporate Law", "Litigation", "Tax Law", "IP Law"]
}

Stages and Timelines

1. Analysis, content strategy (1-2 weeks) — practice structure, content map, E-E-A-T requirements
2. Design (2-3 weeks) — attorney profile UI, blog, case results, mobile layouts
3. Core development (3-5 weeks) — info blocks, relationships, templates, Schema.org markup
4. Content modules (2-3 weeks) — blog, case results, document templates, forms
5. Integrations (1-2 weeks) — CRM, client portal, email marketing
6. Testing, SEO audit (1-2 weeks) — E-E-A-T signal validation, structured data, Core Web Vitals

These timelines assume that content — practice descriptions, attorney profiles, the first 15-20 blog articles — is prepared in parallel with development. If no content exists, add 4-6 weeks for working directly with the firm's attorneys. Legal content cannot be written by a generic copywriter — Google's systems are specifically trained to detect the difference.