Populating a Blog with Content in 1C-Bitrix
A blog in Bitrix is most often the same infoblock as news, but with a different content structure and different SEO requirements. The problem being solved during population: blog articles must function as landing pages for informational queries, not simply as a text archive. This means a semantic core, internal links between articles, correct heading markup, and a table of contents for long materials.
Blog Infoblock: Differences from News
In a typical Bitrix structure, a blog and news are the same mechanism — the difference is in the settings. For a blog the infoblock is extended with additional properties:
-
READING_TIME— reading time (in minutes, computed automatically) -
AUTHOR_ID— link to an element in the "Authors" infoblock via a property of type "Element" -
RELATED_ARTICLES— multiple property of type "Element" for the "Also Read" block -
TABLE_OF_CONTENTS— auto-generated table of contents (JSON or HTML) -
TAGS— tags, multiple property
A separate "Authors" infoblock (b_iblock_element with authors IBLOCK_ID) allows displaying an author biography and their other articles via CIBlockElement::GetByID() with minimal database queries.
Structure of Long Articles
Blog articles are often longer than 3,000 characters and contain several semantic blocks. Without a table of contents, users do not understand what is ahead and leave. The standard TinyMCE in Bitrix does not generate a table of contents automatically — it must be implemented:
Option 1: PHP script in the component template. After receiving DETAIL_TEXT, parse H2/H3 headings via DOMDocument, assign id attributes to them, and build an array for the table of contents:
$dom = new DOMDocument('1.0', 'UTF-8');
$dom->loadHTML('<meta charset="UTF-8">' . $arResult['DETAIL_TEXT']);
$headings = $dom->getElementsByTagName('h2');
$toc = [];
foreach ($headings as $h) {
$text = $h->textContent;
$id = Cutil::translit($text, 'ru', ['replace_space' => '-', 'replace_other' => '']);
$h->setAttribute('id', $id);
$toc[] = ['id' => $id, 'text' => $text];
}
$arResult['DETAIL_TEXT'] = $dom->saveHTML();
$arResult['TOC'] = $toc;
Option 2: JS on the client. A script finds all h2 elements inside .article-body after the page loads, attaches IDs, and builds a table of contents in the sidebar. Simpler to implement, but the table of contents is not visible until JS executes.
Internal Linking
Blog articles must link to each other by topic. Manually placing links in text is time-consuming and requires updating when new materials are added.
A semi-automated approach:
- In the
RELATED_ARTICLESproperty, a content manager selects 3–5 related articles. - In the template of the detail page, the "Also Read" block renders these elements via
CIBlockElement::GetByID(). - Additionally — a script for automatic keyword detection in the text and highlighting them as links to relevant articles (by the
TAGSproperty).
SEO Optimization During Population
Every blog article is a potential landing page. Minimum SEO settings at the infoblock element level:
-
META_TITLE: target keyword + brand, up to 65 characters -
META_DESCRIPTION: answer to the query + call to action, 150–160 characters - Canonical URL: if the article is accessible via multiple URLs (section + tags), canonical points to the primary one
In Bitrix, canonical is added in the page template:
$APPLICATION->SetPageProperty('canonical', 'https://example.ru/blog/' . $arResult['CODE'] . '/');
If the blog is large (500+ articles), a sitemap is set up via bitrix:main.map.google with a dedicated map for the blog, with priority 0.7–0.8 for recent articles.
Images for the Blog
OG image size is critical for social sharing. The standard is 1200×630 px. In Bitrix, when uploading a detail image the component does not automatically resize for OG. Either require the content manager to upload the image at the correct size, or add automatic resizing:
$ogImage = CFile::ResizeImageGet(
$arResult['DETAIL_PICTURE'],
['width' => 1200, 'height' => 630],
BX_RESIZE_IMAGE_PROPORTIONAL_ALT
);
$APPLICATION->SetPageProperty('og:image', SITE_SERVER_NAME . $ogImage['src']);
Alt text for images is mandatory. In Bitrix it is stored in the DESCRIPTION field of the b_file table record. When uploading through the standard form, the content manager must fill in the "Description" field — that is the alt text.
Categories and Tags: Navigation Structure
A typical mistake is creating 20 tags without a system, resulting in 1–2 articles under each tag. A correct structure:
- Infoblock sections (blog categories) — broad topics: "Marketing", "Development", "Analytics". Displayed as the main blog menu.
- Tags — specific subtopics. Should appear in at least 3–5 articles, otherwise the tag page is meaningless.
Category and tag pages require separate SEO descriptions — done via the section description in b_iblock_section (the DESCRIPTION field) or via section properties.
Population Automation
For a high-frequency blog with regular publishing:
-
Excel/CSV import via the standard
iblockmodule or a custom script usingCIBlockElement::Add() - External source parser — a Bitrix agent running on cron, fetches RSS or an external API, creates draft articles in the infoblock with status "inactive" for editor review
-
OpenAI API for draft generation based on titles and keywords (integration via
\Bitrix\Main\Web\HttpClient)
Timelines
| Volume | What is included | Timeline |
|---|---|---|
| Up to 30 articles | Population, SEO, images, internal linking | 2–3 weeks |
| 30–100 articles | + template with table of contents, authors | 3–6 weeks |
| 100+ articles | + import automation, categorization | 6–10 weeks |
A blog does not deliver traffic immediately — first positions in search appear 2–4 months after publication. But with a properly built population process, each new article strengthens the entire section through internal links and tag-based cross-linking.







