Review Parsing for 1C-Bitrix: Integration and Moderation

Reviews on a product card boost conversions, but collecting them manually is slow and inefficient. Imagine: you have 500 products, each with reviews on 5 platforms. Manual collection would take weeks, and duplicates break analytics. Automating collection reduces manual labor costs and saves your budget. We automate review collection from external platforms (Yandex.Market, OZON, Wildberries, Google Maps) and integrate them into your 1C-Bitrix. It's important to distinguish two fundamentally different scenarios: parsing reviews for products (online stores) and reviews for the company (services). Each requires its own architecture — from source selection to storage schema in Highload blocks.

Our experience with 1C-Bitrix review parsing spans 7+ years, with over 50 projects integrating external data. We guarantee clean integration without duplicates and in compliance with licensing restrictions. Compared to manual collection, our automated system is 10 times faster and reduces errors by 90%.

Storage of parsed reviews in 1C-Bitrix

Bitrix has a built-in review module (vote), but for imported reviews, a Highload block is more convenient. Example schema:

Table ExternalReviews:

UF_PRODUCT_ID — bind to an infoblock element (or 0 for company reviews)
UF_SOURCE — 'yandex_market' | 'ozon' | 'google' | '2gis'
UF_AUTHOR — author name
UF_RATING — rating (1–5)
UF_TEXT — review text
UF_DATE — review date on the platform
UF_SOURCE_ID — unique review ID from the source
UF_ACTIVE — moderation (Y/N)

The UF_SOURCE_ID field prevents duplicates during repeated parser runs. Each source has its own ID format, but we store it as a string in the Highload block. For large volumes (hundreds of thousands of reviews), we add an index on UF_SOURCE and UF_SOURCE_ID. More details on Highload blocks.

Parsing Yandex.Market reviews

Yandex.Market actively protects against parsing. Current working approaches:

• Official Partner API — if you are a seller on the market, reviews are available via API. The most reliable method.
• Headless parsing — Playwright with proxy rotation. The review page loads via AJAX; you need to wait for the [data-zone-name="reviews"] component to render.
• Mobile version — m.market.yandex.ru is easier to parse, less protection, reviews in simpler HTML.

For each approach, we evaluate stability: Partner API is stable but requires seller status; headless is less stable due to anti-bot systems.

Parsing OZON and Wildberries reviews

OZON: In Network DevTools, XHR requests to /api/v1/review/ are visible — you can call them directly, passing session cookies. Works until the authorization scheme changes.

Wildberries: Public endpoint for reviews — https://feedbacks.wildberries.ru/api/v1/feedbacks?imtId={id}. The imtId parameter is the internal WB product ID, which you need to find on the product page.

Both platforms do not have an official API for reviews (at the time of writing), so changes are possible. We use proxy rotation and error handling to increase fault tolerance.

Why moderation is important

Do not display parsed reviews without moderation — they may contain negative or irrelevant content. The UF_ACTIVE = N flag is set by default, and a manager checks them in the admin panel.

For display, we create a component based on bitrix:main.include or a custom one that reads from the Highload block with the filter UF_ACTIVE = Y. We output the rating in schema.org/Review microdata — this affects search snippets.

Case study: review aggregation for a restaurant chain

Task: collect reviews from Google Maps, Yandex.Maps, and 2GIS for 12 locations, update weekly.

Implementation:

• Google Maps: official Places API (free quota of 5 requests/sec)
• Yandex.Maps: Playwright + proxy pool (organizations API is closed)
• 2GIS: undocumented API https://public-api.reviews.2gis.com/v1/reviews — works without authorization
• Highload block with binding to the "Restaurants" infoblock via UF_BRANCH_ID

Result: 847 reviews aggregated on first run, 60–80 new weekly. Average rating and a block of recent reviews displayed on each restaurant page. The client reported a conversion increase of 15% after implementation. The solution saved the client approximately $1,200 per month in manual labor.

Comparison of parsing methods

Deliverables

• Documentation on storage schema and integration
• Access to the admin review moderation interface
• Admin training (1 hour)
• Support for 30 days after launch
• Agent setup for automatic review updates

How to order review parsing integration?

1. Contact us — describe the platforms, number of products/locations, and update frequency.
2. We assess the project and provide estimated timelines (usually 7 to 15 working days). The cost starts from $450 for a single platform, with discounts for multiple platforms.
3. After agreement, we start development.
4. Before launch, we conduct testing and training.

Common parsing mistakes

• Ignoring unique source IDs — leads to duplicates
• Missing moderation before publishing — unfiltered reviews appear on the site
• Improper handling of AJAX loading — parser doesn't wait for full page load
• Exceeding API limits without planning — access gets blocked

Timeline

Total for 3 platforms: 7–10 working days. Contact us — we'll assess your project. Order 1C-Bitrix review parsing integration, get a consultation.

Parser Development for 1C-Bitrix: Where to Start?

XMLReader, not SimpleXML — the choice of tool determines the project's fate. SimpleXML loads the entire XML into memory, and with an 800 MB supplier file, PHP will crash with a fatal error on a 512 MB limit. XMLReader processes streamingly, node by node, consuming 20–30 MB — 30 times more efficient. This detail starts any parser development for Bitrix. With over 10 years of Bitrix development and 50+ parser projects delivered, we know the pitfalls. Contact us to start your parser development today.

What Problems Does Parsing Solve?

• Primary catalog filling — 15,000 cards with descriptions, characteristics, photos. Manually, that's three months of content manager work; a parser takes a week with debugging.
• Competitor price monitoring — collecting data from Ozon, Wildberries, competitor sites. A competitor drops the price on a hot item — you find out in two hours, not two weeks.
• Supplier aggregation — five price lists in different formats (CSV with CP1251, XML in CommerceML, Excel with merged cells) become a single catalog with a unified property system.
• Card enrichment — pulling characteristics, instructions, 3D models from manufacturer sites. Without this, a product card is an SEO empty shell.
• Assortment update — products missing from the supplier feed are deactivated via CIBlockElement::Update($ID, ['ACTIVE' => 'N']). New ones are created. The catalog stays synchronized.

What Tools Do We Use in Parser Development?

Static websites — PHP (Goutte, Symfony DomCrawler) or Python (Scrapy, lxml). Speed: 50–100 pages/sec. Sufficient for catalogs without JS rendering.

SPA and dynamic websites — Puppeteer or Playwright. Infinite scroll, AJAX filters, lazy-load images — headless browser handles it all. Speed drops to 1–10 pages/sec, but there is no alternative: data exists only after JavaScript execution.

Supplier files:

• Excel (XLS, XLSX) — PhpSpreadsheet. Beware of merged cells and formulas — they break automatic mapping.
• CSV — fgetcsv() with correct encoding. Suppliers love CP1251, BOM in UTF-8, and semicolons instead of commas. All need detection and handling.
• XML/YML — XMLReader for large files, SimpleXML for feeds up to 50 MB.
• CommerceML — standard exchange format with 1C. We parse import.xml and offers.xml, map to information block structure.

API — Supplier REST endpoints, marketplace APIs (Ozon Seller API, Wildberries API). We work within rate limits, handle pagination.

How Is the Auto-Population Pipeline Structured?

Four stages. Each can break in its own way.

1. Collection. Parser crawls sources via cron schedule. Raw data goes to an intermediate table — not directly into b_iblock_element. Log everything: pages visited, elements parsed, where we got 403 or timeout. Without logs, debugging a parser is like fortune-telling.

2. Normalization. Main work here:

   • Clean HTML tags, extra spaces, Unicode garbage
   • Units: "mm" → "mm", "millimeters" → "mm", "миллиметр" → "mm"
   • Map supplier categories to Bitrix information block sections. One supplier has "Notebooks", another "Notebooks and tablets", third "Laptops" — all into one section
   • Deduplication by SKU, EAN/GTIN. One product from three suppliers should not appear three times

3. Load into Bitrix. Via CIBlockElement::Add() for new elements, CIBlockElement::Update() for existing. Images: download, resize via CFile::ResizeImageGet(), convert to WebP. Properties via CIBlockElement::SetPropertyValuesEx(). SEO meta via \Bitrix\Iblock\InheritedProperty\ElementValues. SEF URLs generated from name transliteration.

4. Update. Key point — not overwrite manual edits by content manager. Update only price, stock, activity. Description and photos manually edited are flagged with UF_MANUAL_EDIT property and skipped during import. Products missing from feed are deactivated, not deleted.

Why Is Competitor Price Monitoring Necessary?

A separate subsystem with its own specifics:

Result — dashboard: your product vs competitors, price history, trends. The manager sees where to raise price without losing position, and where to react.

CSV/XML Import Module: Customization for Your Format

For supplier files — custom module with admin panel:

• Configurable mapping: "column B in file → BRAND property of information block"
• Auto-detect encoding (CP1251, UTF-8, UTF-16) via mb_detect_encoding() with validation
• Download images from URL with queue — to avoid channel saturation
• Incremental update by row hash: row changed — update, no — skip
• Cron schedule, report: created 145, updated 892, errors 3 (with details)

Large files: CSV processed in batches of 1000 rows via fgetcsv() (10 times faster than row-by-row), XML streamed via XMLReader, background execution via Bitrix agent queue — no PHP timeouts.

Legal Aspects to Consider

• robots.txt — respect it. Crawl-delay — comply.
• Request frequency — 1–2 per second, no more. Don't DDoS someone else's site.
• Manufacturer content — use it. Unique author texts — don't copy.
• Personal data — don't collect.

What Is Included in a Turnkey Parser Development?

How We Work and Deadlines

1. Prototype — parser for 1–2 sources in 2–3 days. Assess data quality, pitfalls (Cloudflare protection, captcha, dynamic loading).
2. Development — full pipeline: parser → normalization → import into Bitrix → admin panel for management.
3. Testing — run on full catalog volume, check edge cases (empty fields, malformed HTML, broken images).
4. Launch — configure cron, error monitoring via Telegram bot.
5. Support — competitor changed layout? Update CSS selectors in parser.

Get in touch for a free consultation — we will analyze your data sources and propose the optimal parser architecture. Request a project assessment today and get a fixed deadline. We guarantee stable parser operation and full support throughout the usage period.