1C-Bitrix Catalog Website Without Shopping Cart

We develop catalog websites on 1C-Bitrix without a shopping cart — when products are displayed but not sold online. Typical cases: industrial equipment, building materials, auto parts, real estate. The price depends on volume, region, or exchange rate — publishing a fixed price is pointless. Or the item is one-off: one excavator, one property — a cart is absurd here.

From Bitrix's perspective, this is a fundamentally different architecture. Not an "online store minus cart," but a separate project class with its own solutions at every level — from license to infoblock structure.

License: 'Start' vs 'Standard'

The first question affecting the budget. The 'Start' edition does not include the sale and catalog modules. That means: no SKUs, no price types, no cart, no orders. For a catalog without a cart, that's exactly what's needed. The 'Standard' edition includes catalog, but allows selective use: enable trade catalog properties for an infoblock but not connect sale. This gives SKUs and multiple prices without a cart.

License savings: 'Start' edition starts at 5,400 RUB, 'Standard' from 35,000 RUB. For a catalog up to 5,000 items, choosing 'Start' can save up to 50% of the license budget.

The choice depends on the scenario:

On 'Start', the catalog is built entirely on the iblock module. A product is an infoblock element, a category is a section. Infoblock properties are product characteristics. That's all. No trade wrappers.

Infoblock Structure Without SKUs

Catalog Without SKUs

One infoblock — one catalog. No 'product → SKU' link via PROPERTY_CML2_LINK. No b_catalog_product table. No b_catalog_price.

Typical structure for an industrial equipment catalog:

Infoblock 'Equipment Catalog' (type catalog, API code equipment):

• Sections — categories (Pumps → Centrifugal → Horizontal)
• Elements — product items
• Properties:
  • MANUFACTURER (dictionary, linked to Highload-block) — manufacturer
  • ARTICLE (string, indexed) — article number
  • POWER (number) — power, kW
  • WEIGHT (number) — weight, kg
  • MATERIAL (list) — housing material
  • DOCS (file, multiple) — PDF documentation
  • GALLERY (file, multiple) — photos
  • PRICE_ON_REQUEST (checkbox) — price on request
  • IN_STOCK (list: 'In stock', 'On order', 'Discontinued')

Directories are stored in Highload-blocks. Manufacturers, units of measurement, countries. HLBlock for 'Manufacturers' — table b_hlbd_manufacturers with fields UF_NAME, UF_LOGO, UF_COUNTRY, UF_WEBSITE. Linking from infoblock via property of type 'Directory'.

Key point: without SKUs there is no b_iblock_element_property table multiplier. If a product has 15 properties and no SKU — that's 15 rows in EAV per element. With SKUs of 5 variations — 75 rows. For 10K items, the difference between 150K and 750K rows is noticeable during filtering.

Filtering: catalog.smart.filter Without the catalog Module

The bitrix:catalog.smart.filter component works with infoblocks even without the catalog module. But there is a nuance: facet indexes (b_catalog_sm_*) are only available when the catalog module is connected. On 'Start', there are no facets.

Without facets, filtering is done via direct queries to b_iblock_element_property. For a catalog up to 10-15K items with 10 filterable properties, it's acceptable: 100-300ms. For 50K+, it hurts: 2-5 seconds.

Alternatives to filter without facets:

1. Custom filter on D7 ORM — Bitrix\Iblock\Elements\ElementXxxTable (where Xxx is the infoblock API code). Generated automatically, allows building queries via ::getList() with filter, select, runtime. Advantage: full control over SQL, ability to add caching of filter results.
2. Elasticsearch / Sphinx — for catalogs from 50K items. Indexing via agent or event handler OnAfterIBlockElementUpdate. Filtering: 5-20ms on any volume. Disadvantage: additional infrastructure.
3. Filter on Highload-block — if the catalog is moved to HLBlock, filtering uses a flat table with indexes. Fast, but loses standard SEO components of infoblocks.

Recommendation for most projects: standard catalog.smart.filter + proper indexes in the database. Custom only when data proves necessity.

CIBlockElement::GetList vs D7 ORM

Old API: CIBlockElement::GetList($arOrder, $arFilter, $arGroupBy, $arNavStartParams, $arSelectFields). Works, documented, thousands of examples. Problem: no strict typing, no autocomplete in IDE, filters via array conventions (">=PROPERTY_POWER" => 100).

D7 API: \Bitrix\Iblock\Elements\ElementEquipmentTable::getList([...]). Strict types, fluent interface, runtime fields, registerRuntimeField() for computed columns. IDE understands structure, refactoring is safe.

Practical rule: new code on D7, existing code — don't rewrite for the sake of rewriting. CIBlockElement::GetList won't disappear, Bitrix supports backward compatibility for decades. But if you're building a filter or aggregation from scratch, D7 gives predictable SQL and the ability to profile each query via \Bitrix\Main\Diag\SqlTracker. D7 ORM generates predictable SQL, typically yielding a 2-3x performance gain over CIBlockElement::GetList on complex filters.

SEO for Catalog on Infoblocks

The iblock module has built-in SEO templates. Configured at the infoblock level: 'SEO' tab → templates for sections and elements. Variables:

• {=this.Name} — element/section name
• {=this.PreviewText} — preview text
• {=this.property.MANUFACTURER} — property value
• {=parent.Name} — parent section name

<title> template for a product: {=this.Name} — {=this.property.MANUFACTURER} {=parent.Name}. For a catalog without a cart, replace 'buy' with 'characteristics and price' or 'order'.

SEO-friendly URLs are configured via URL template in the catalog.section / catalog.element component parameters:

• Section: /catalog/#SECTION_CODE#/
• Element: /catalog/#SECTION_CODE#/#ELEMENT_CODE#/

SECTION_CODE and ELEMENT_CODE are automatically generated from names (transliteration) when the infoblock option 'Transliterate character code when adding element' is enabled.

Microdata — Schema.org Product without Offer (no price for purchase). Specify name, description, image, brand, sku (article number). For 'price on request' — omit offers or use priceSpecification with priceCurrency without price. Google understands, Yandex accepts via Webmaster.

Product Comparison Without the sale Module

The standard comparison in Bitrix (bitrix:catalog.compare.list) depends on the catalog module. On 'Start', it doesn't work. Solution: custom comparison component.

Storage: array of selected product IDs in $_SESSION['COMPARE_LIST'][IBLOCK_ID] or in cookies (for unauthenticated users). Output: CIBlockElement::GetList by ID array with selection of all properties, rendered as a table 'property — value per product'. Implementation: 8-12 hours of development, including JS for add/remove without page reload.

On React frontend (headless/SPA approach) — comparison stored in state or localStorage, data fetched via REST API /rest/iblock.element.get or custom controller.

'Request Price' Instead of 'Buy'

Central UX pattern of a catalog without cart. Implementation via webform module or custom handler.

Form is linked to the catalog element: hidden fields pass ELEMENT_ID and ELEMENT_NAME. The manager receives an email: 'Price request for [product name], article [XXX], from [name, phone, email]'. Data saved in an application infoblock or Highload-block — to track conversion.

CTA button variants by industry:

• Equipment: 'Request commercial offer'
• Real estate: 'Book a viewing'
• Auto parts: 'Check availability and price'
• Custom furniture: 'Calculate cost'

1C Exchange Without the sale Module

The catalog module supports exchange via CommerceML (/bitrix/admin/1c_exchange.php). On 'Start', this is not available. Alternative: custom import via CSV/XML or REST API.

For a catalog without cart, exchange is usually one-way: 1C → site. Nomenclature, stock balances, characteristics. Implemented via:

• Agent (CAgent) on schedule, parsing XML export from 1C
• Cron task calling import script via CLI
• REST API, if 1C can send HTTP requests (via HTTPСоединение processing)

When using 'Standard' with the catalog module — standard CommerceML exchange works fully; the sale module is simply not connected.

Catalog vs Store

A catalog without a cart is justified if at least two conditions are met:

• Prices are non-public or depend on context (volume, region, contract)
• The deal requires negotiations — cannot be completed in 2 clicks
• Assortment is complex: product described by 15+ characteristics, selected by specification
• No warehouse logistics on the site side

If a cart is needed six months later, transitioning from catalog to store with proper architecture (infoblocks, separated logic) takes 2-4 weeks: connecting the sale module, adding price types, configuring payment systems and delivery services. Catalog data remains unchanged.

What's Included in Development

• Technical specifications and prototypes
• Structure of infoblocks and HL-blocks
• Catalog design, product card, filter
• Layout and integration with Bitrix
• Configuration of filtering, comparison, request forms
• SEO templates and microdata
• Data import and 1C exchange (if needed)
• Testing and handover for operation

Stages and Timelines

1. Design (3-5 days) — infoblock structure, filterable property map, Figma prototypes
2. Design (1-2 weeks) — catalog, product card, filter, comparison, request forms
3. Development (2-5 weeks) — layout, Bitrix integration, filter setup, feedback forms, SEO
4. Content and import (3-7 days) — product loading, 1C exchange setup if needed
5. Testing and launch (3-5 days) — cross-browser, mobile version, PageSpeed, handover

We have been on the market for over 5 years, implemented 40+ catalogs on Bitrix. Experience in industry, construction, distribution. Bitrix Documentation.

Contact us to discuss your project. Order catalog development — get an offer within a day.

How to properly design infoblocks?

When developing a 1C-Bitrix website, we see dozens of projects where poor infoblock structure slows down the site. Typical scenario: the client asks for a "product catalog." The developer creates one infoblock catalog, puts 15 properties in it. Six months later – 40 properties, 8 of which are used only for one category. The filter lags, the b_iblock_element_property table grows to millions of rows, CIBlockElement::GetList runs for 3 seconds. Consequences – conversion drop, loss of customers, additional optimization costs. In one project after catalog refactoring, page generation time dropped from 4.2 to 0.8 seconds, and annual support costs were reduced by over $10,000 through eliminated redundant queries and agents.

Our approach: design infoblocks before writing a single line of code. Separate infoblocks for entities (products, categories, brands), dictionary properties via highload blocks, trade offers for SKUs. This builds performance for years. If you want a preliminary audit of your infoblock schema, contact us for a free review of common mistakes and recommendations.

Why 1C-Bitrix outperforms most CMS for business

The choice of CMS is dictated by business needs, not preferences. Native 1C exchange via catalog.import.1c provides two-way synchronization of products, prices, balances, and orders through CommerceML without third-party modules — five times faster than developing custom exchange on OpenCart or WordPress, saving hundreds of thousands of rubles. Proactive security module includes WAF, file integrity control, SQL injection protection, and two-factor authentication; it's certified for FSTEK requirements. Modular architecture lets you enable only needed modules — iblock, catalog, sale, search — reducing DB queries per hit. Regular patches close vulnerabilities faster than open-source projects (average CVE fix time two weeks). Official documentation is maintained on the vendor's site.

What highload blocks are and how they speed up the catalog

Highload blocks are an alternative to extended infoblock properties when the list of values can grow to thousands of entries. Typical example: manufacturers, countries, colors. If stored as list properties in an infoblock, each filter triggers a full scan of b_iblock_property_enum table. With HL-blocks, selection uses indexes – filter response time drops from 1–2 seconds to 50 ms. We use HLB component and custom queries via Bitrix\Highloadblock\DataManager. This is critical for catalogs with 100,000+ items.

From our practice: an online store with 500,000 items. Standard filter by brand took 4 seconds. The server couldn't handle 50 concurrent requests – pages crashed. We moved the brand directory to an HL-block, added tagged caching for 15 minutes, and set up an agent to clear cache on change. After optimization, filter time was 120 ms, average LCP was 1.8 seconds. The project runs stable without failures.

What integrations are critical for 1C-Bitrix stores

Each e‑commerce project requires reliable connections with payments, fiscalization, logistics, and CRM. We integrate YooKassa, CloudPayments, Tinkoff, Apple Pay, Google Pay for payments; ATOL and OrangeData for 54-FZ compliance via sale.cashbox; CDEK, Boxberry, PEC, Russian Post, Yandex.Delivery for logistics; Bitrix24, amoCRM, Roistat, Calltouch, Mindbox for analytics and CRM. All integrations are configured with proper error handling and fallback logic.

What's included in 1C-Bitrix website development

Each project includes a full set of documentation and artifacts to prevent knowledge loss after handover.

• Technical specification – user stories, infoblock diagrams, integration schemas.
• Source code in Git – with commit history, release tags, branching rules.
• Administrative documentation – description of custom components, deployment instructions, list of agents and events.
• Staff training – up to a 3-hour webinar: admin panel, order management, price settings. Recorded for later review.
• Access to staging during development – test before production deployment.
• Warranty support – bug fixes for 30 days after launch. Post-warranty support packages with SLA (response 2 hours, resolution 8 hours).

Our process and technologies

Tech stack: mobile-first markup, tested on physical devices (iPhone, iPad, Android). Use BrowserStack for Safari on iOS. Performance goals: LCP < 2.5 s, FID < 100 ms, CLS < 0.1. Enable composite site (composite module), CDN, tagged caching, WebP/AVIF, lazy loading. SEO: Schema.org via JSON-LD, auto-generation of sitemap.xml via seo module, canonical and hreflang for multilingual versions. robots.txt blocks /bitrix/ from indexing. CI/CD: Git, auto-deploy via GitLab CI, staging. DB migrations: sprint.migration module with versioning.

Process:

1. Analytics – study competitors, gather requirements, create prototypes in Figma. Output: technical specification with user stories.
2. Design – UI/UX with design system. Components are reusable.
3. Development – write components with custom templates in local/templates/. Business logic in local/modules/.
4. Testing – functional, cross-browser, load testing (up to 1000 requests). Critical bugs fixed before launch.
5. Launch – deploy to production, monitoring via UptimeRobot, alerts in Telegram. Fixes for first 48 hours.

Multilingual support and redesign

Full localization via language files lang/ and SITE_ID mechanism. hreflang for each version. Regional versions with different prices and content – IP detection (main.geo) or manual selection. Multidomain – unified management of multiple domains.

Redesign without losing rankings: performance audit (PageSpeed, WebPageTest), SEO (Screaming Frog). New template in local/templates/ with preserved URL structure. 301 redirects only if URL changes significantly. Kernel update, migration to D7 ORM, infoblock restructuring, migration via sprint.migration with Git.

Guarantee and support

We have been working with 1C-Bitrix for 12+ years, completed 500+ projects. Certified developers on staff. Fixed price in contract – no surprises. Warranty period covers code errors. After warranty, subscription packages with SLA (response time 2 hours, resolution 8 hours). 24/7 availability monitoring, alerts in Telegram. Get a consultation and preliminary estimate: contact us via the form on the website or chat – we'll respond within an hour. Order turnkey development – we'll design infoblocks, integrate 1C, and speed up the catalog. If you already have a site on another CMS, order a performance audit and migration to Bitrix.