Developing an ad portal on 1C-Bitrix

Development of Classified Portal on 1C-Bitrix

A person wants to sell a sofa. Takes photos, writes description, goes to the site — and hits a form with 30 fields, half of which are unclear. Leaves. Goes to Avito. If a classified portal loses the user at submission — everything else (moderation, search, monetization) doesn't matter. Designing a classified on 1C-Bitrix starts with user scenario, not database architecture.

Architecture of Content Model

A classified is a user content catalog with categories, where each category has its own characteristics. A car is described by make, model, year, mileage. An apartment by area, floor, number of rooms. A smartphone by model, condition, storage.

In 1C-Bitrix this is implemented through info blocks with custom properties:

• One info block — all listings, category determined by section
• Dynamic properties — property set depends on selected category. Implemented through multiple properties with visibility binding to section (frontend logic) or separate info blocks per major category

Second approach is preferable for portals with fundamentally different item types (cars, real estate, services). Each info block has clean schema, indices optimized for specific filters, no empty "garbage" fields.

Listing element contains:

• Title, description, price (with currency)
• Category + subcategory (info block sections, up to 3–4 levels)
• Photos (multiple "File" property, up to 10–20 images)
• Geolocation (city, district — reference or coordinates for map)
• Seller contacts (phone, messenger — hidden until authorization)
• Status: draft, moderation, active, sold, removed, blocked
• Listing type: private / business
• Placement period and expiration date

Listing Submission — Critical Scenario

Submission form should be step-by-step:

1. Category Selection — tree with search, popular categories highlighted
2. Field Filling — only relevant for selected category, minimal required fields
3. Photo Upload — drag-and-drop, crop, rotate, compress on client before send
4. Preview — how listing will look in search and on page
5. Publish — with optional paid services (boost, highlight)

Implemented through custom component based on bitrix:iblock.element.add.form or fully custom form with REST API on frontend. Second option gives UX control — real-time validation, upload progress bar, draft auto-save.

Auto-save. User fills half the form, closes tab. On return — draft is there. Implemented through localStorage + server save every 30 seconds via AJAX.

Moderation

User content without moderation is spam, fraud, and banned items on day one.

Multi-level moderation system:

• Automatic Filtering — stop-words, duplicate check (photo and text hashes), phone number detector in text (attempt to bypass contact hiding)
• Manual Pre-moderation — for new users (first 3–5 listings)
• Post-moderation — for users with history, listing publishes immediately but queued for check
• User Reports — "Report" button with reason selection, auto-hide at threshold

Moderation interface is separate admin page with status, category, date filters. Hot keys for fast processing: approve, reject, request revisions.

Search and Filtering

Search is the main navigation. User doesn't browse catalog, sets parameters: "apartment, 2 rooms, Minsk, up to $50,000".

Filter Component:

• Faceted filters by info block properties — use facet index module (iblock_facet) for speed
• Price ranges with slider
• Geo-filter — city/district selection or radius on map
• Sorting: by date, price, relevance
• Save search — user subscribes and gets notifications on new listings

Full-text Search — Elasticsearch for auto-completion, typo correction, synonym search (e.g., "odnushka" → "1-room apartment").

For large portals (100,000+ listings) filtering through standard CIBlockElement::GetList doesn't scale. Solution — move data to Elasticsearch or Sphinx, filter on search engine side, return element IDs back to Bitrix for display.

User Personal Cabinet

Personal cabinet is second most important after search.

Cabinet Functions:

• My Listings — list with status filters, quick edit, renew, remove
• Favorites — saved listings from other users
• Messages — internal correspondence between buyer and seller (without contact reveal until deal)
• Notifications — new messages, listing status change, search subscription results
• Reviews — seller rating from transaction history
• Balance and Payments — for monetization through paid services

Internal messaging is implemented through custom module or B24 "Web Messenger" module (im). Second option provides real-time delivery but interface needs customization.

Monetization

Free platform without monetization is a losing project. Revenue models:

Paid Services for Listings:

• Boost in search (for N hours/days)
• Highlight with color or frame in feed
• VIP placement at section top
• Increase photo limit

Seller Subscriptions:

• Free tier: N listings per month
• Paid: unlimited + view stats + priority in output

Advertising:

• Banners in catalog and on listing pages (module advertising)
• Contextual blocks bound to categories

Payments accepted through "Store" module (sale): service order, payment via payment processor (YooKassa, CloudPayments, Stripe), auto-apply service after payment. Recurring payments for subscriptions via card tokenization.

User Balance. Internal account, topped up via payment system. Deduction on service activation. Implemented through module sale internal accounts or custom table.

SEO for Classifieds

Listing portal generates thousands of pages. SEO strategy:

• Unique title and description for each listing — templated from properties: "{Title} — buy in {City}, price {Price}"
• Clean URLs — /category/subcategory/id-slug/
• Filters as Landing Pages — /apartments/minsk/2-bedroom/ — separate page with meta tags, not URL parameter
• Noindex for Empty Categories and Removed Listings
• Sitemap — dynamic generation, update on publish/remove
• Structured Data Product or Offer per Schema.org

Performance and Scaling

A classified portal is high-load. 100,000 listings × 5 photos = 500,000 files. Thousands of concurrent searches with filtering.

Optimization Stack:

• Composite cache for listing and category pages
• Facet index for fast filtering
• Elasticsearch/Sphinx for full-text search
• CDN for images with auto-resize (via BX_RESIZE_IMAGE_PROPORTIONAL or external service like imgproxy)
• Queues — photo processing, notification sending, search engine indexing via Bitrix agents or RabbitMQ
• Separate DB server, read replica at load over 500 RPS