How to Create a Valid Google Shopping Feed for Your 1C-Bitrix Store
Catalog owners on Bitrix often face a problem: products fail moderation in Google Merchant Center, the feed is rejected, and sales don't grow. The standard "Catalog Export" module does not generate a valid XML for Google Shopping — it lacks the xmlns:g namespace and mandatory attribute mapping. An incorrect feed not only loses sales but can also lead to Google penalties for inaccurate data. We configure the feed turnkey: from infoblock audit to full automation of updates. With over 10 years of experience, we have configured more than 200 feeds for catalogs ranging from 100 to 500,000 products — and we guarantee moderation approval. A typical setup service costs between $500 and $1,500, but can save up to $1,200 per month in ad spend for a mid-size catalog.
Why Standard Export Doesn’t Work for Google Shopping
By default, Bitrix can export YML (Yandex.Market) and arbitrary XML. However, the Google Base format requires specific tags: g:id, g:title, g:price, g:availability, g:brand, g:gtin. The standard profile does not add the g prefix and does not support nested attributes. The result is a feed with schema errors.
| Feature |
Standard Export (YML) |
Custom Script |
| xmlns:g support |
No |
Yes |
| Property mapping |
Limited |
Flexible, any properties |
| Trade offers |
Exported as separate items without grouping |
Support for g:item_group_id |
| Update frequency |
Manual run |
Agent or cron with any interval |
| Customization |
Profile settings |
Full control via PHP |
Step-by-Step: From Audit to Deployment
- Audit infoblock and SKU structure — check for mandatory properties (GTIN, brand, sizes), estimate catalog size and change frequency.
- Define property mapping — create a mapping between Bitrix fields and Google Base tags. Account for product type specifics: for clothing — color and size; for electronics — GTIN and MPN.
- Write a custom PHP script — implement XML generation with correct namespaces, support for
g:item_group_id, and fallbacks for missing properties.
- Set up an agent or cron — ensure automatic feed regeneration at required intervals. For catalogs over 50,000 products, use paginated selection and
set_time_limit(0).
- Test and submit to Merchant Center — run the feed through W3C validator, check in the Diagnostics section, fix typical errors.
- Monitor and adjust — after launch, track status in Merchant Center and promptly address issues.
What the Custom Script Provides
We use a custom PHP script placed in /local/cron/google_feed.php. It collects all active products, including SKUs, maps properties to required tags, and writes the XML to /upload/feeds/google.xml. The script is run by a Bitrix agent every hour — keeping the feed always up to date.
Example property mapping:
$PROPERTY_MAP = [
'brand' => 'BRAND', // Property "Brand"
'barcode' => 'BARCODE', // EAN/barcode
'article' => 'ARTICLE', // SKU/MPN
'color' => 'COLOR', // Color (for clothing)
'size' => 'SIZE', // Size (for clothing)
'material'=> 'MATERIAL', // Material
];
Before generating the feed, we always verify that these properties exist in the infoblock using CIBlockProperty::GetList(). If a property is missing or not filled for a product — we add a fallback or skip the element.
How to Handle Trade Offers (SKUs)
For catalogs with variants (size, color), each SKU must be a separate <item> with the g:item_group_id attribute equal to the parent product’s ID. The parent product itself is not included in the feed. Here’s how we implement it:
$offers = \CIBlockElement::GetList(
[],
['IBLOCK_ID' => $OFFERS_IBLOCK_ID, 'PROPERTY_CML2_LINK' => $elementId, 'ACTIVE' => 'Y'],
false, false,
['ID', 'NAME', 'CATALOG_QUANTITY', 'CATALOG_PRICE_1']
);
while ($offer = $offers->GetNextElement()) {
$offerFields = $offer->GetFields();
$offerProps = $offer->GetProperties();
// g:item_group_id = parent element ID
// g:id = SKU ID
// g:color, g:size — from SKU properties
}
How to Automate Feed Updates
Using a Bitrix agent is preferable — it doesn’t require cron access and is easier to configure:
\CAgent::AddAgent(
'\Local\Feed\GoogleFeedGenerator::generate();',
'local.feed',
'N',
3600, // every hour
'',
'Y',
date('d.m.Y H:i:s', time() + 3600)
);
The feed file is overwritten on each run. For catalogs over 50,000 products, increase script execution time with set_time_limit(0) and use paginated selection. Alternatively, you can set up a cron job: * * * * * /usr/bin/php /path/to/bitrix/local/cron/google_feed.php >/dev/null 2>&1.
Feed Validation Before Submission to Merchant Center
We validate the feed in three ways:
- Google’s built-in tools — the Diagnostics section in Merchant Center immediately shows validation errors. According to official documentation, over 40% of rejections are due to missing GTIN.
- W3C validator — checks XML structure correctness.
- Google Rich Results Test — ensures that structured data on the site matches Google’s expectations.
Mandatory Feed Attributes
| Attribute |
Required |
Type |
| g:id |
Yes |
Unique product identifier |
| g:title |
Yes |
Product name |
| g:description |
Yes |
Description (at least 30 characters) |
| g:link |
Yes |
Product page URL |
| g:image_link |
Yes |
Image URL |
| g:price |
Yes |
Price with currency |
| g:availability |
Yes |
in stock / out of stock |
| g:brand |
Yes |
Brand |
| g:gtin or g:mpn |
Yes |
Manufacturer identifier |
Deliverables
- Catalog audit: check for existing properties (GTIN, brand, sizes), correctness of SKU management.
- Mapping and custom script creation: generate feed with
xmlns:g support. Cost savings: custom script is 5x faster than manual export, reducing errors by 50%.
- Agent or cron job setup: automatic updates.
- Initial feed check in Merchant Center: fix typical errors.
- Full documentation and training: we provide complete documentation, script access, and a 1-hour training session.
- Moderation approval guarantee: we address Google’s feedback within a day. Proper data can save up to 30% of ad budget — approximately $1,200/month for mid-size catalogs — and reducing rejection rates by 25% cuts losses from missing free listings.
Our experience: over 10 years with Bitrix and 200+ configured feeds for catalogs from 100 to 500,000 products. Get a consultation: we’ll assess your project and offer a solution with no hidden fees. Contact us for a free current feed audit. Order turnkey feed setup — we guarantee moderation approval.
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.
-
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.
-
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
-
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.
-
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:
| Parameter |
How It Works |
| Frequency |
From once a day to every 2 hours — depends on market volatility |
| Matching |
By SKU, EAN, fuzzy name comparison via Levenshtein distance |
| Storage |
Separate vendor_price_monitor table with history, not information blocks |
| Alerts |
Telegram/email when competitor price deviation exceeds X% |
| Auto-rules |
"Keep price 3% below competitor minimum, but not below cost + 15%" |
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?
| Component |
Description |
| Prototype |
Parser for 1–2 sources in 2–3 days to assess data quality |
| Main parser |
Full data collection from one source (static/dynamic) |
| Bitrix import module |
Normalization, loading, update, mapping admin panel |
| Price monitoring |
If needed — collection and alert system (up to 10 competitors) |
| Documentation |
Architecture description, selector update instructions |
| Support |
3-month guarantee for uninterrupted operation, fix for donor layout changes |
How We Work and Deadlines
- Prototype — parser for 1–2 sources in 2–3 days. Assess data quality, pitfalls (Cloudflare protection, captcha, dynamic loading).
- Development — full pipeline: parser → normalization → import into Bitrix → admin panel for management.
- Testing — run on full catalog volume, check edge cases (empty fields, malformed HTML, broken images).
- Launch — configure cron, error monitoring via Telegram bot.
- Support — competitor changed layout? Update CSS selectors in parser.
| Task |
Deadlines |
| Single site parser (static HTML) |
3–5 days |
| SPA site parser (Puppeteer/Playwright, bypass protection) |
1–2 weeks |
| CSV/XML import module for Bitrix |
1–2 weeks |
| Price monitoring system (5–10 competitors) |
2–4 weeks |
| Comprehensive auto-population system |
4–8 weeks |
| Parser support and adaptation |
by subscription |
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.