Meta tags in Bitrix break during bulk product import
Bulk catalog import into Bitrix breaks meta tags not because of a code error, but because of the order of operations within the exchange. Data from 1C or an export file arrives in several passes: first trade offers and prices, then properties and binding to sections.
The meta tag template is assembled from fields that do not yet exist at the moment the card is saved — and the page goes into the index with an empty title or a title like "Product" without category and brand.
The second source of failure is the template itself. If it contains only the element name and section name, hundreds of cards in the same catalog get identical title and description.
Duplicate title and description are worse than empty meta tags: the search engine selects one address from a group of similar pages, the rest drop out of the search results — along with them, cards that managed to update prices and stock in the same export also decline.
The third failure is not immediately noticeable. Updating prices and stock changes the composition of the catalog: a product goes to the archive, moves to another section, appears in a new collection.
Meta tags remain from the previous version — a removed item continues to collect traffic to a page without an offer, while a new one enters the index with empty markup.
Empty meta tags and duplicates cannot be fixed with a one-time edit: each subsequent upload brings them back until the template is tied to fields that are actually filled during the exchange.
We explain how this is closed — from substitution rules and duplicate checks to result control after each export.
What changes after implementing SEO field templates
After enabling SEO field templates, card markup no longer depends on who filled the fields manually and when.
Substitution rules assemble the title and description from product attributes — category, brand, name, key characteristic — and on the 1C-Bitrix platform they are applied at the information block level, not to an individual card.
Values remain overridable: for flagship items, the editor sets the text manually, and the rule does not overwrite it.
The share of cards with correct markup in a catalog of several thousand items grows from a third to 95% and above — this is visible in the before-and-after report, not estimated by eye.
At the same time, the share of duplicates falls: the description no longer matches verbatim across hundreds of items because the rule inserts differing parts — category, brand, characteristic, range.
Preparing a catalog section is accelerated through inheritance: a new category takes the rule from the parent section, and instead of manually filling each card, the engineer configures one template.
An edit in one place changes the markup of the entire section — launching a category that previously took days is reduced to checking substitutions on a sample and targeted exceptions.
What remains is the regulation: handling empty attributes so that extra separators do not get into the title, the priority of manual values over the template, and a test run before rolling out to the entire catalog.
After that, the markup is predictable, and expanding the assortment does not recreate a queue of manual filling tasks.
Forms of storing rules: information block, module, or external service
Markup generation rules can be kept in three places: in the standard 1C-Bitrix information block, in a separate module on custom fields, or in an external service.
The choice is determined by the number of fields in the template, who edits the rules — a content manager or a developer — and what happens during bulk catalog export.
The requirement for any option is the same: the rules must survive reindexing, platform updates, and product import, otherwise the markup will "drift" across hundreds of pages at once. Below are the alternatives that are actually chosen between on a live catalog.
| Option | When it fits | Limitations |
|---|---|---|
| Standard information block | One catalog, template like "{Name} — buy in {City}", edits by a content manager | Complex rules — conditions by stock, categories, languages — cannot be expressed, logic spreads across section settings |
| Custom fields and a separate module | Own fields for meta tags, different templates by category, calculations by related properties | The module must be maintained during platform updates, migration between sites is more difficult |
| External service | Multiple sites and catalogs, unified rules, export of markup to related systems | Synchronization delay, data exchange, and access separation; if the service is unavailable, markup is not updated |
In practice, they start with the standard information block, and when there are more than a dozen rules, the logic is moved to a module and only manual overrides for individual cards are left in the information block.
Workflow: from markup audit to handover of the regulation
The work goes from capturing the current state to a regulation according to which editors then work independently. The order removes the main risk: templates are not implemented immediately on the live site, so no page loses markup while the rules are being fine-tuned.
- Markup audit. We export titles and descriptions for all page types — catalog, product cards, articles, sections. We record where values are duplicated, where they are empty, and where they are set manually.
- Discrepancy map. We compare the audit snapshot with the reference for each template: what is generated automatically, what is edited by hand, where rules conflict between sections. From this it is clear which templates are unified and which require separate logic.
- Rule scheme. We describe substitution by page types: which fields are involved, how empty values are handled, what goes into pagination and filters. We agree on the scheme with you before setup — edits at this step are cheaper than after migration.
- Setup on a test environment. We deploy a copy of the site with a working database, connect the templates, and run generation across the entire set of addresses. We look at non-standard cases: long names, products without descriptions, service sections.
- Check. We go through a control sample of pages and compare the resulting values with the expected ones. Separately, we make sure that old addresses have not lost markup and that no duplicates have appeared.
- Transfer to the live site. We roll out the rules to the working copy and monitor page behavior after the update. Returning to the previous state in case of deviations takes minutes.
- Filling regulation. We hand over the document: what the editor fills in, what is generated automatically, how to check a page before publication. We conduct training and support the first edits.
Set of artifacts: templates, substitution rules, regulations
We hand over the project so that meta tags in Bitrix work without us. Everything related to substitution lies in the repository next to the code: not in chat and not in someone else's head, but in documents that a new engineer or staff editor can figure out on their own.
- Template map — a table "page type → template → data source": product card, catalog section, article, services page, pagination.
- Field priority policies — what wins in a conflict: the value from the card, the auto-template, or a manual editor edit. Without this, it is easy to lose computed values.
- Editor instructions — before/after examples, length restrictions, analysis of typical errors. A person without a technical background edits fields and does not break the template.
- Section binding scheme — where exactly the rules are enabled: information blocks, sections, language versions, individual exceptions. Targeted, not "enabled everywhere".
- Change log — who, when, and why changed the template, and what the previous state was. One rule can be rolled back without affecting the others.
- Set of control checks — a list of pages for acceptance and a checklist before bulk catalog updates.
- Knowledge transfer regulation — a recorded walkthrough with the team and the procedure by which instructions are updated when the site structure changes.
After that, support is not "ping the developer" but editing one document. Describe the task — we will return with an estimate and a plan.
Case study: a catalog of 40 thousand items without duplicate markup
A catalog of 40 thousand items is tens of thousands of cards, each with its own properties, sections, and trade offers.
The markup in it was maintained manually: content managers copied the product name into title and description, some fields remained empty, and some were duplicated between cards in neighboring sections. With such a volume, the markup diverged within a month after the next catalog upload.
Before: manual filling and one-third duplicates
A filled description was present in about 62% of cards; the rest went into search with an empty or truncated description.
Duplicate title and description, differing in word order or case, occurred in almost every third card — search engines merged such pages and left only one in the results.
A new section was launched in two to three weeks: until all cards were processed manually, the section could not be opened.
After: templates based on properties and a single edit point
We moved markup into templates that assemble meta tags from card properties — category, series, product type, availability. The rule defines the order of parts, length, and separators, so identical cards no longer produce identical titles.
The share of duplicates decreased from a third to isolated cases, filled cards grew from 62% to 99%, and a new section now launches in one business day — it is enough to specify the template, and it applies to all items in the section.
Markup maintenance also stopped being a routine: adding a property or section does not require edits in cards, and bulk uploads from the accounting system go through the same template.
We checked the restrictions on field length and structure against the requirements of 1C-Bitrix so that the markup correctly enters the page code and the sitemap.
What to do if part of the markup is already filled in manually
The rule is simple: a manual value is older than a template one — but only for the field that was edited.
Autofilling in Bitrix works at the page property level, so we do not disable the rule entirely but mark a specific field as manually overridden: the others continue to update from the template.
It is more convenient to store priority not as a flag but as the value source: each field has a current value, author, and last modification time. Then a repeated template run skips overridden cells instead of overwriting them.
| Mode | When it fits | Limitations |
|---|---|---|
| Manual field value | Unique pages where the template produces weak text | Control is needed when the section template changes |
| Template rule | Catalog and typical cards | Does not take into account the meaning of a specific page |
| Targeted exception | Individual addresses and subsections | The list must be kept up to date |
| Snapshot freeze | Change of generation logic | Fields stop receiving template improvements |
Exceptions are set by address mask or by tree branch, not by enumerating pages — otherwise the list becomes outdated faster than it can be maintained. For each one, we record the reason: in six months, no one should guess why the field stopped updating.
The edit history closes the main risk of a bulk run: you can see who changed the value and when, and what it was before and after. Returning to the previous version takes minutes instead of restoring from a backup.
Meta tags in Bitrix: technical doubts before starting
Doubts about meta tags almost always come down to one thing: will automation break the catalog and will we get duplicates instead of traffic growth. Below are four questions asked at the start: about load, filter pages, language versions, and behavior during platform updates.
What to do with duplicate filter pages?
Auto-generation of meta tags for catalog slices creates thousands of nearly identical addresses. We provide a canonical address to the main section page, close service parameter combinations in robots.txt, and do not include them in the sitemap. Only slices with unique content enter the index.
Will the catalog load suffer?
Meta tags are assembled when an element is saved and stored in the database, while the page only substitutes ready values. Bulk recalculation runs in background jobs in batches, so catalog output does not drop, and robot crawling does not create peaks. Page merging is performed once during markup, not on every display.
How does this work with multilingualism and regional subdomains?
For language versions, the link is built via hreflang with an indication of the main language; for subdomains, separate title templates with the city and their own canonical address.
This way the versions do not compete with each other in search results and do not dilute the weight of the main site.
What happens during a platform update?
Templates and rules are stored in a separate module and theme files, not in the core — a platform update does not overwrite the settings. Before deployment, we run a check on a copy and keep a configuration rollback.
Let's discuss the task and return with an estimate and a plan
An accurate estimate for meta tags is based not on guesses but on the composition of the catalog and the current rules for outputting titles.
To calculate the scope of work, we need access to the admin panel or a copy of the configuration, a list of information blocks, and a few page examples — a product card, a section, a service page.
If part of the descriptions is already set manually, send an export: we will analyze what to move into templates and what to leave as an exception.
- page types: which sections and cards are involved in automation and how many there are in total;
- where the title and description are currently generated — in the component, in SEO properties, or in information block settings;
- data structure: trade offers, branches, language versions, binding to 1C;
- filled SEO properties: the share of items with manual values that cannot be overwritten;
- access: a test environment or database copy to check output without risk to the live site;
- restrictions: page address template, requirements for title length and structure.
Then we show the implementation plan in stages: audit of the current output, design of templates and substitution rules, assembly on a test environment, verification of results, transfer to the live site.
Handover of the result is not only working code but also a description of templates with examples, rules for exceptions, and instructions for editors. Post-launch support includes monitoring new sections and editing templates when the catalog structure changes.
Describe the task and send what you have at hand — we will return with an estimate of the work and an implementation plan.