Setting Up QR Codes for 1C-Bitrix: Redirects and Analytics
We set up QR codes for online stores on 1C-Bitrix so that your offline channel generates measurable sales. A typical scenario: you printed 1000 labels with QR codes, but a month later the catalog structure changed—all links broke. Our engineers solve this at the design stage by choosing the right URL strategy—by article or product ID. Over many years, we have implemented more than 30 projects integrating QR codes into trade catalogs—from small online stores to chains with 50,000 products. In this article, we break down which technical solutions work in production, how to avoid broken links, and why caching is critical for thousands of products. If you need a ready-made setup, contact us—we will estimate the project within 1 day.
A warehouse worker scans a QR code on a box and lands on the product page in the catalog. A marketer prints a QR on a price tag in an offline store—the customer scans and sees reviews, specs, and a "Buy" button. The task is technically simple, but the implementation details determine whether the system will work stably with thousands of products.
Which URL to Choose for the QR Code?
A QR code is an encoded URL. The question is which URL to encode so that it does not break when the catalog structure changes.
Direct link to product (https://shop.by/catalog/product/artikul-123/)—works until the SEO URL changes. Rename a catalog section—all printed QR codes become broken.
Redirect by ID (https://shop.by/qr/1234/)—more reliable. A PHP page or handler in urlrewrite.php is created that, based on the product ID, gets the current URL via CIBlockElement::GetByID() and performs a 301 redirect. The QR code does not depend on the catalog structure.
Redirect by XML_ID or article (https://shop.by/qr/?sku=ART-0042)—the best option for 1C integration, where the article is the main identifier. According to Bitrix documentation, the API allows searching for an element by any property. The handler looks for the element by the ARTICLE property and redirects.
| Link Type |
Reliability |
When to Use |
| Direct URL |
Low (breaks on SEO change) |
Temporary promotions where catalog is not edited |
| Redirect by ID |
High (independent of SEO) |
Stable QR codes on permanent media |
| Redirect by article |
Very high (resistant to moves) |
1C integration, frequent catalog updates |
How to Speed Up QR Code Generation?
On the server, QR codes are generated with a PHP library. Two working options:
-
chillerlan/php-qrcode—compact, no dependencies, generates SVG and PNG.
- endroid/qr-code—more features (logo inside QR, colors), but heavier.
Install via Composer: composer require chillerlan/php-qrcode. Generation in the catalog.element component: in result_modifier.php, add code that creates an SVG string of the QR for the current product. The SVG is embedded into the template via $arResult['QR_CODE_SVG'].
For bulk generation (catalog printing, labels), create a separate page /admin/qr-export/ that generates a PDF with QR codes for selected products. The TCPDF or Dompdf library handles the task.
Caching and Performance
Generating one QR code takes 5–15 ms. On a catalog page with 30 products, that's up to 450 ms just for QR codes. Solution: generate the QR once and save it as a file in /upload/qr/{ELEMENT_ID}.svg. When the product URL changes (event OnAfterIBlockElementUpdate), delete the file so that a new one is generated on the next request.
Optimization example: with a catalog of 10,000 products, server time savings reach up to 80%
Without caching, each time the product list is viewed, 10,000 QR codes would be regenerated. With caching, it's only on first access or after a product update. This reduces server load and speeds up page loading.
UTM Parameters and Analytics
Add UTM parameters to the URL inside the QR: ?utm_source=qr&utm_medium=offline&utm_campaign=price_tag. This allows tracking in Yandex.Metrica and Google Analytics how many conversions offline media generate. The parameters do not affect the redirect—the handler simply passes them through.
How the Turnkey Setup Works?
| Stage |
Action |
Result |
| Analysis |
Study catalog structure and requirements |
Choose URL strategy (article or ID) |
| Development |
Create redirect handler and caching |
Stable QR codes |
| Integration |
Generate QR on product page (SVG) + bulk PDF export |
Ready files for printing |
| Testing |
Check redirects, UTM, performance |
Error-free operation |
| Deployment |
Upload to production server, documentation |
30-day support |
What Is Included in the Turnkey QR Setup?
The comprehensive setup includes:
- Analysis of the current URL structure and selection of the optimal strategy (article or ID)
- Development of a redirect handler with caching
- Integration of QR code generation on the product page (SVG embed)
- Setup of bulk QR export to PDF for printing on price tags and labels
- Addition of UTM parameters with the ability to change campaigns without reprinting QR codes
- User documentation and instructions for marketers
- Free support for 30 days after launch
Order the QR code setup—we will calculate the cost within 1 working day. Get a ready-made solution with a guarantee of stable operation for any catalog size. Contact us for a consultation.
Why URL Structure Matters in Bitrix Migration?
Skipping URL mapping during a website migration to Bitrix crashes organic traffic by 50–80% in two weeks. WordPress uses /product/item-name/, OpenCart uses /index.php?route=product/product&product_id=123, Bitrix defaults to /catalog/section/element/. Without a 301 redirect map, search engines index mass 404s. We start every migration with Screaming Frog scanning the old site, then compile a complete redirect map before writing a single line of code. Proper migration requires full URL mapping — every indexed page gets a correspondent.
Over seven years we have completed 50+ projects: landing pages, catalogs with 300,000 products, e‑commerce stores. Typical duration 2–8 weeks. Contact us for a free project estimate within one day.
How Migration Preserves SEO Positions
Losing organic traffic is the biggest fear, and it's justified. Here is how we avoid it.
-
URL mapping 1:1 — where possible, via
CUrlRewriter and infoblock SEF settings we keep the exact structure. When impossible — 301 redirect. Auto‑generation of redirect map: parse Screaming Frog export, match with new element slugs, generate nginx config. Each redirect verified with curl -I after switching.
- Transfer of meta tags — title, description, h1 moved into properties
ELEMENT_META_TITLE and ELEMENT_META_DESCRIPTION. Canonical via Bitrix SEO component. Duplicates cut: www/non‑www, http/https, sorting parameters. Sitemap: new sitemap.xml generated by Bitrix seo module, submitted to Search Console immediately after DNS switch.
- Speed comparison — Bitrix processes a catalog of 100,000 products 3x faster than OpenCart due to tagged caching and query optimization for
b_catalog_product.
What Data Gets Transferred?
Content — pages, articles, news → information infoblocks. Catalog: categories → sections, products → elements linked to b_catalog_product, properties → infoblock properties or highload directories. Images, reviews, FAQ.
E‑commerce — products with trade offers (SKUs), prices in b_catalog_price (multi‑currency via b_catalog_currency), stock balances b_catalog_store_product, discounts (b_sale_discount), order history (b_sale_order + b_sale_basket).
Users — client base b_user plus custom UF fields. Passwords are hashed differently: WordPress — phpass, OpenCart — SHA1+salt, Drupal — SHA512. We write a custom CUser::LoginByHash with fallback to old algorithm — client enters password once, system rehashes to Bitrix bcrypt.
SEO data — meta tags, alt attributes, URL structure. Main task: preserve every indexed URL or set 301.
Media — images, documents, videos — transferred preserving paths and optimized via CFile::MakeFileArray().
How to Plan a Successful Migration: 5 Key Steps
-
Audit — scan with Screaming Frog: all URLs, status codes, meta tags. Analyze DB structure, custom modifications, integrations. Create migration map.
-
Architecture design — map content types → infoblocks, fields → properties, directories → highload blocks. Architecture must be convenient for Bitrix administration.
-
Migration scripts — PHP scripts read from old DB (or API), transform and write via Bitrix API (
CIBlockElement::Add, \Bitrix\Sale\Order::create). Re‑run during testing.
-
Staging — full migration to test server. Verify integrity: product count, properties, URLs, filters.
-
Final migration & switching — delta import, DNS switch, monitoring.
Detailed stage timeline
| Stage |
Duration |
Activities |
| Audit |
1–3 days |
Full site scan, integration register |
| Architecture |
2–5 days |
Infoblock design, field mapping |
| Scripts |
3–10 days |
PHP based migration engine |
| Staging |
1–2 days |
Full dry run, integrity checks |
| 301 redirects |
1–2 days |
Map in .htaccess or nginx.conf |
| Final migration |
1 day |
Delta import, DNS switch |
| Post‑migration |
2–4 weeks |
Monitor Search Console, fix crawl errors |
| Deliverable |
Description |
| Documentation |
Redirect map, mapping description, DB schema |
| Access |
Admin panel, FTP/SSH, API keys |
| Training |
Video tutorials or on‑boarding session |
| Support |
2 weeks post‑migration monitoring, bug fixing |
| Guarantee |
Rollback to old site within 48 hours |
Typical Migration Mistakes and How to Avoid Them
Each of these errors has caused loss of positions and clients.
- Loss of URLs without redirects — the most destructive mistake.
/product/123 instead of /catalog/item-name.html — without 301 this means mass 404s and traffic collapse. We auto‑generate the map and verify every redirect after switching.
- Content duplication — one product accessible with and without www, via HTTP and HTTPS, with GET filter parameters → five URLs instead of one. SEO weight dilutes. Set up canonical, 301 for variants,
robots.txt with Disallow for parameters.
- Broken images — absolute URLs in content (
src="https://old-site.ru/img/photo.jpg"), quality loss during compression. Replace with relative paths, transfer preserving structure, check HTTP 200 for each file.
- Loss of meta tags and microdata — title, description, Schema.org may not transfer. Do full mapping and verify on staging.
- Broken forms and integrations — changed IDs, API keys, webhooks. Compile integration register before start and test each after.
- Mobile version — old
m.site.ru → responsive Bitrix. Without mobile URL redirect → 404 for mobile users. Include in redirect map.
Timelines and Cost Savings
| Project type |
Timeline |
Notes |
| Informational site (up to 500 pages) |
2–4 weeks |
Content + design + redirects |
| E‑commerce store (up to 10,000 products) |
4–8 weeks |
Catalog + orders + integrations |
| Large store (100,000+ products) |
2–4 months |
Custom scripts + load testing |
Businesses typically save $3,000–$8,000 annually after migration — no old CMS license fees, reduced plugin and hosting costs. Annual hosting savings alone can reach $1,200. Add the affordable licensing cost of 1C‑Bitrix — it pays off quickly.
Contact us for a free migration estimate. We also provide a preliminary calculation within one day — request a consultation with our Bitrix specialists.
