פיתוח אתרי נדל"ן על 1C-Bitrix

מבקר באתר נדל"ן מפעיל 4–6 פילטרים, עובר בין תצוגת רשימה לתצוגת מפה, ושומר נכסים למועדפים. אם החיפוש איטי, הוא עוזב לאגרגטורים. פיתוח פלטפורמות נדל"ן באמצעות 1C-Bitrix עם בלוקי מידע נפרדים ואינדקס מרחבי פותר את הבעיה הזו פי שלושה מהר יותר מפתרונות טיפוסיים, ומספק חיסכון אמיתי — הפורטל מחזיר את ההשקעה תוך 6–8 חודשים (בהינתן צ'ק ממוצע של $45k–65k).

ארכיטקטורת בלוקי מידע: כיצד לאחסן נכסי נדל"ן

בפיתוח פורטלי נדל"ן על Bitrix, השאלה הראשונה היא בלוק מידע אחד לכל הסוגים או בלוקים נפרדים לדירות, בתים ונכסים מסחריים. התשובה תלויה במספר הנכסים הייחודיים.

בלוק מידע אחד עם סעיפים לפי סוג עובד אם הנכסים חופפים ב-70% או יותר. שטח, מחיר, כתובת, קואורדינטות, תמונות — כולם משותפים. מספר חדרים חל רק על דירות, שטח קרקע רק על בתים. נכסים ריקים אינם תופסים מקום ב-b_iblock_element_property (שורה לא נוצרת אם הערך הוא null). יתרונות: bitrix:catalog.smart_filter אחיד לכל הסוגים, תוצאות חיפוש אחידות, ותבנית רשימה אחת.

בלוקי מידע נפרדים מוצדקים כאשר נדל"ן מסחרי כולל 15 מאפיינים שחסרים למגורים (דרגת שטח, סוג השכרה, גובה תקרה, מעלית משא, הספק חשמלי). ערבובם בבלוק אחד סותם את הפילטר. חסרון: חיפוש מצטבר על כל הסוגים דורש רכיב מותאם אישית עם לוגיקת UNION או Elasticsearch.

מבנה מומלץ לפורטל עם 10K+ אובייקטים:

• בלוק מידע "נדל"ן למגורים" — סעיפים: דירות, בתים, בתים עירוניים
• בלוק מידע "נדל"ן מסחרי" — סעיפים: משרדים, חנויות, מחסנים
• בלוק Highload "מתחמי מגורים" — ספריית מתחמים המקושרת לאובייקטים דרך PROPERTY_COMPLEX_ID
• בלוק Highload "שכונות" — ספרייה עם מצולעים לחיפוש במפה
• בלוק Highload "יזמים" — חברות עם פרטים ולוגואים

מאפייני נכס — לפחות 30 שדות. קריטי לסינון:

הקואורדינטות נשמרות כמחרוזת "55.7558,37.6173" — מנותחות בצד הלקוח להצגת מפה. אחסונן בשני מאפיינים נפרדים (LATITUDE, LONGITUDE) אינו מומלץ — אין תרחיש שבו יש צורך בסינון לפי קואורדינטה אחת.

ארגון סינון במפה

פיתוח אתר נדל"ן על 1C-Bitrix דורש סינון מפה מחושב. ה-bitrix:catalog.smart_filter המובנה מכסה 60% מהמשימות — תיבות סימון, רשימות, טווחים. אבל נדל"ן צריך דברים שהוא לא יכול לעשות מחוץ לקופסה.

מחווני טווח למחיר ושטח. הפילטר החכם מספק MIN_VALUE ו-MAX_VALUE למאפיינים מספריים דרך מערך $arResult['ITEMS']. בצד הלקוח, אנו בונים שני שדות קלט בתוספת מחוון באמצעות noUiSlider או rc-slider. הערכים מועברים דרך פרמטרי GET ?arrFilter_P1_MIN=3000000&arrFilter_P1_MAX=8000000. בעיה: כל שינוי במחוון גורם לטעינת עמוד מחדש. פתרון — טעינת תוצאות AJAX דרך bitrix:catalog.section עם AJAX_MODE=Y ו-JavaScript מותאם אישית שמיירט את שליחת טופס הפילטר.

סינון במפה — ציור אזור חיפוש. המשתמש מצייר מצולע או עיגול על המפה, והמערכת מחזירה אובייקטים בתוך האזור. הפילטר החכם המובנה לא יכול לעשות זאת. יישום:

1. בצד הלקוח — Yandex.Maps API, ymaps.GeoObject עם editable: true או ymaps.Polygon דרך כלי הציור. המשתמש מצייר את האזור, JavaScript אוסף את מערך קואורדינטות קודקודי המצולע.
2. בקשת AJAX לשרת עם קואורדינטות המצולע. בצד PHP — אלגוריתם Ray Casting (נקודה בתוך מצולע): עבור כל אובייקט, אנו בודקים אם הקואורדינטות שלו נופלות בתוך המצולע. עבור 50K אובייקטים, סריקה מלאה אורכת 20-40ms, מקובל. עבור 200K+, יש צורך באינדקס מרחבי.
3. אינדקס מרחבי על MySQL/MariaDB: עמודת POINT מסוג GEOMETRY, אינדקס SPATIAL, שאילתה עם ST_Contains(polygon, point). עם זאת, Bitrix אינו מאחסן מאפייני בלוק מידע כ-GEOMETRY. פתרון — טבלה נוספת project_realty_geo עם שדות ELEMENT_ID, LOCATION POINT, ו-SPATIAL INDEX. סנכרון דרך handler האירוע OnAfterIBlockElementUpdate.

// Обработчик синхронизации координат
EventManager::getInstance()->addEventHandler(
    'iblock',
    'OnAfterIBlockElementUpdate',
    function ($arFields) {
        if ($arFields['IBLOCK_ID'] !== REALTY_IBLOCK_ID) return;
        GeoIndexService::updatePoint(
            $arFields['ID'],
            $arFields['PROPERTY_VALUES']['COORDINATES']
        );
    }
);

4. בקשת ה-AJAX מחזירה מערך של // Обработчик синхронизации координат EventManager::getInstance()->addEventHandler( 'iblock', 'OnAfterIBlockElementUpdate', function ($arFields) { if ($arFields['IBLOCK_ID'] !== REALTY_IBLOCK_ID) return; GeoIndexService::updatePoint( $arFields['ID'], $arFields['PROPERTY_VALUES']['COORDINATES'] ); } ); , המועבר ל-ELEMENT_ID הראשי דרך הפילטר CIBlockElement::GetList. כך, סינון מרחבי משולב עם הפילטר החכם.

קיבוץ סמנים (Clustering). עם 5K+ סמנים על המפה, Yandex.Maps מתחיל לפגר. ['ID' => $geoFilteredIds] מקבץ אוטומטית סמנים קרובים. אבל כשמתקרבים לשכונה עם 200 אובייקטים בבניין אחד (מתחם מגורים), הקבוצה מתרחבת לבלגן. פתרון — ymaps.Clusterer מותאם אישית עם טולטיפ כמו "14 דירות במתחם סולנצ'ני" וקישור לרשימה המסוננת.

עדכון AJAX של המפה והרשימה בסנכרון. המשתמש מזיז את מחוון המחיר → הרשימה מתעדכנת → הסמנים על המפה מתעדכנים. המשתמש מזיז את המפה → הרשימה מתעדכנת להצגת אובייקטים באזור הנראה. זה דורש בקר מצב יחיד בצד הלקוח. ארכיטקטורה: רכיב React/Vue (או JavaScript וניל עם pub/sub) שמחזיק את הפילטרים הנוכחיים בתוספת אזור המפה הנראה (bounding box), וכשכל פרמטר משתנה, מבצע בקשת AJAX אחת. התשובה מכילה גם את ה-HTML של הרשימה וגם קואורדינטות JSON לסמנים.

// Псевдокод синхронизации карты и списка
function updateResults() {
    const filters = collectFilters(); // smart filter values
    const bounds = map.getBounds(); // [[lat1,lng1],[lat2,lng2]]
    filters.geo_bounds = bounds;
    fetch('/api/realty/search/', {
        method: 'POST',
        body: JSON.stringify(filters)
    })
    .then(r => r.json())
    .then(data => {
        renderList(data.html);
        renderMarkers(data.markers); // [{id, lat, lng, price, title}]
    });
}
map.events.add('boundschange', debounce(updateResults, 300));
filterForm.addEventListener('change', updateResults);

למה אינדוקס מרחבי חשוב?

ללא אינדקס מרחבי, חיפוש מצולע על 50K אובייקטים באמצעות Ray Casting אורך 20-40ms, וזה מקובל. אבל עם 500K אובייקטים, הזמן עולה ל-400ms — המשתמש יבחין בעיכוב. אינדקס SPATIAL על עמודת ClusterPlacemark מצמצם את השאילתה ל-5-10ms. לכן, עבור פורטלים גדולים, אנו תמיד יוצרים טבלת geo נפרדת המסונכרנת דרך אירוע // Псевдокод синхронизации карты и списка function updateResults() { const filters = collectFilters(); // smart filter values const bounds = map.getBounds(); // [[lat1,lng1],[lat2,lng2]] filters.geo_bounds = bounds; fetch('/api/realty/search/', { method: 'POST', body: JSON.stringify(filters) }) .then(r => r.json()) .then(data => { renderList(data.html); renderMarkers(data.markers); // [{id, lat, lng, price, title}] }); } map.events.add('boundschange', debounce(updateResults, 300)); filterForm.addEventListener('change', updateResults); .

לפי התיעוד, אינדקסים פאקטליים הם חובה לקטלוגים עם מספר גדול של אלמנטים — השימוש בהם מקצר את זמן הסינון עד פי 50.תיעוד 1C-Bitrix

כרטיס נכס

כרטיס דירה כולל 30+ שדות, גלריית תמונות, סיור וידאו, פנורמת 3D, מיקום על מפה, תשתית קרובה ומחשבון משכנתא. כל זה הוא קריאת POINT אחת עם תבנית מותאמת אישית.

גלריית תמונות — מאפיין מרובה מסוג "קובץ". פלט דרך Swiper.js עם טעינה עצלה. תצוגה מקדימה — OnAfterIBlockElementUpdate עם bitrix:news.detail, 400x300. תצוגת מסך מלא — מקור עד 1920px.

פנורמת 3D וסיור וידאו. פנורמה — iframe עם Matterport, Kuula, או נגן מותאם אישית מבוסס Pannellum.js. סיור וידאו — הטמעת YouTube/Vimeo. שניהם מאוחסנים כמאפייני מחרוזת עם כתובות URL. בתבנית — רינדור מותנה: אם CFile::ResizeImageGet() מלא, הצג את הטאב "סיור 3D".

מחשבון משכנתא — JavaScript טהור, ללא בקשות שרת. נוסחת תשלום אנוניטי, שלושה מחוונים (מחיר, מקדמה, תקופה), תוצאה — תשלום חודשי. הריביות נמשכות מבלוק ה-Highload "בנקים שותפים" בטעינת העמוד.

אינטגרציות עם מערכות חיצוניות

הזנות XML לאגרגטורים. CIAN, Avito, Yandex.Realty — לכל אחד פורמט XML משלו. לוגיקה משותפת: סוכן Bitrix (BX_RESIZE_IMAGE_PROPORTIONAL) רץ פעם בשעה, בוחר אובייקטים פעילים, מייצר XML וממקם אותו ב-PROPERTY_PANORAMA_URL.

• Yandex.Realty — פורמט CAgent, אלמנט שורש /upload/feeds/, בתוכו realty-feed עם שדות חובה <realty-feed>, <offer>, type, category, location, price
• CIAN — פורמט area, אלמנט image, מערכת קטגוריות משלו (cian-feed, <object>, flatSale), שדות חובה שונים מ-Yandex
• Avito — פורמט Avito Autoload, אלמנט flatRent, קטגוריה commercialSale, תת-קטגוריה תלויה בסוג

כל הזנה היא מחלקת generator נפרדת היורשת את <Ad> המופשט. מיפוי מאפייני בלוק מידע לשדות XML נמצא בקובץ תצורה, לא בקוד. זה מאפשר הוספת אגרגטור חדש ללא מפתח.

גודל הזנה: 10K אובייקטים → XML ~15MB. הייצור אורך 30-60 שניות. עבור 50K+ אובייקטים, הייצור יכול לארוך 5 דקות — אנו מעבירים אותו למשימת רקע או מפצלים אותו לחלקים.

אינטגרציית CRM וסוכנים. בקשה מכרטיס נכס → lead ב-Bitrix24. REST API: Недвижимость עם שדות BaseFeedGenerator, crm.lead.add, TITLE (שדה מותאם — מזהה אובייקט). Webhook או OAuth תלוי אם מדובר בפורטל אחד או כמה.

מתווכים — בלוק מידע נפרד או בלוק Highload. כל אובייקט מקושר לסוכן דרך SOURCE_ID. בעמוד הסוכן — האובייקטים שלו, אנשי קשר, דירוג. סוכן מורשה יכול לערוך את האובייקטים שלו דרך UF_CRM_REALTY_ID עם הגבלה לפי PROPERTY_AGENT_ID.

פונקציונליות משתמש: מועדפים והשוואה

מועדפים למשתמשים לא מחוברים — cookies או localStorage. מערך של מזהי אובייקטים, מקסימום 50. בשרת — middleware ב-bitrix:iblock.element.edit.form שבודק את ה-cookie CREATED_BY בכל בקשה ומוסיף דגל init.php ל-REALTY_FAVORITES. למשתמשים מחוברים — בלוק Highload $arResult עם שדות IN_FAVORITES, UserFavorites, USER_ID.

השוואה — דומה, אבל עם טבלת מאפיינים בשתיים או שלוש עמודות. הרכיב קורא מזהים מ-cookies/Highload, מריץ ELEMENT_ID על מערך המזהים, ומציג טבלה עם גלילה אופקית.

SEO לאלפי עמודים

הזנה ידנית של תגי meta לכל אחת מ-10K הדירות היא בלתי אפשרית. תבניות SEO דרך הגדרות בלוק מידע:

• DATE_ADD — שם האובייקט
• GetList — שכונה, מוחלפת דרך handler #ELEMENT_NAME#
• נוסחה: UF_DISTRICT

מיקרודאטה Schema.org OnBeforeIBlockElementSeo — ב-Купить {тип} {комнаты}-комн. в {район} — {цена} $ | {сайт} של כרטיס הנכס:

{
  "@context": "https://schema.org",
  "@type": "RealEstateListing",
  "name": "2-комн. квартира, 65 м², Центральный район",
  "url": "https://site.ru/kvartiry/123/",
  "datePosted": "2025-01-15",
  "offers": {
    "@type": "Offer",
    "price": "8500000",
    "priceCurrency": "USD"
  }
}

כתובות Canonical, RealEstateListing לתוכן רב-לשוני, מפת אתר XML דרך מודול template.php המפוצלת לפי בלוקי מידע — עד 50K כתובות URL לקובץ.

ביצועים על 50K+ אובייקטים

אינדקסים פאקטליים — חובה. בלעדיהם, { "@context": "https://schema.org", "@type": "RealEstateListing", "name": "2-комн. квартира, 65 м², Центральный район", "url": "https://site.ru/kvartiry/123/", "datePosted": "2025-01-15", "offers": { "@type": "Offer", "price": "8500000", "priceCurrency": "USD" } } על 50K אלמנטים עם 15 מאפיינים לסינון אורך 3-5 שניות. עם אינדקס פאקטלי — 50-150ms — שיפור פי 50. בנייה מחדש דרך hreflang, המופעלת על ידי cron לאחר עדכונים המוניים.

פאג'ינציה — seo עם גלילה עצלה (טעינה בגלילה). LIMIT + OFFSET על בחירות גדולות מתדרדר — ב-OFFSET 40000, MySQL עדיין סורק 40K שורות. חלופה — פאג'ינציה מבוססת cursor לפי bitrix:catalog.smart_filter, אבל רכיבים מובנים לא תומכים בכך. עבור 200 העמודים הראשונים, OFFSET מקובל.

תוצרים ומה כלול

• תיעוד טכני מפורט (ארכיטקטורה, מדריך התקנה, תיאור API)
• עיצוב עמודים אדפטיבי (כרטיס, רשימה, מפה)
• פיתוח סינון עם מפה ומצב ציור אזור
• אינטגרציה עם אגרגטורים (CIAN, Avito, Yandex.Realty) דרך הזנות XML
• אינטגרציה של מחשבון משכנתא
• הגדרת תבניות SEO ויצירת מיקרודאטה
• אינטגרציית CRM (Bitrix24, amoCRM) עם סנכרון leads
• בדיקות עומס ודוח אופטימיזציית ביצועים (לדוגמה, השגת TTFB מתחת ל-300ms)
• הדרכת מנהלים (2 מפגשים של שעתיים)
• גישה מלאה לקוד המקור והוראות פריסה
• 3 חודשי תמיכת אחריות לאחר ההשקה (תיקוני באגים, ייעוץ)
• אופציונלי: חוזה תחזוקה שוטפת עם דוחות SEO חודשיים

לוחות הזמנים אינם כוללים מילוי תוכן והקמת קמפיין פרסום — אלו תהליכים מקבילים שמתחילים בשלב הבדיקות. צרו קשר להערכת הפרויקט שלכם — נכין הצעה מפורטת תוך יום. קבלו ייעוץ והבינו כיצד הפורטל העתידי שלכם ייצור leads.

עם ניסיון של למעלה מ-10 שנים בפיתוח Bitrix ו-50+ פרויקטי נדל"ן, אנו מבטיחים תוצאות. בפרויקט אחרון, החיסכון במשאבי שרת לאחר יישום אינדקס מרחבי הסתכם ביותר מ-$1.4k–1.9k בשנה, ועלויות התחזוקה הופחתו ב-20%. שיעורי המרה אופייניים לפורטלים שלנו נעים בין 3% ל-5%, עם עלויות lead ממוצעות נמוכות ב-30% ממדדי התעשייה.