ביקורת מקיפה לאתר 1C-Bitrix וסקירת קוד

ביקורת אתרי 1C-Bitrix: סקירת קוד, ניתוח ביצועים, אבטחה, SEO. בדיקה מקיפה של הפרויקט עם המלצות לשיפור.
השירותים שאנו מציעים

הכישורים שלנו:

שאלות נפוצות

ביקורת אתר ביטריקס: מצאו בעיות לפני שהן מוצאות אתכם

תארו לעצמכם: אתם פותחים פרויקט מצוות קודם — init.php מכיל 3,000 שורות, OnBeforeIBlockElementUpdate מקוננים, יש dump.sql בגודל 4GB בשורש האתר, ותיקיית upload/ גדולה יותר מבסיס הנתונים. אנחנו רואים פרויקטים כאלה כל שבוע. וזה לא חריג — זו הנורמה עבור ביטריקס אחרי כמה שנים של פיתוח פעיל ללא בקרת איכות. ביקורת של אתר 1C-Bitrix היא הדרך היחידה להעריך באופן אובייקטיבי את המצב האמיתי של פרויקט לפני השקעה בשיפורים או בהרחבה. היא חושפת צווארי בקבוק בקוד, בבסיס הנתונים, בתצורת השרת ובאבטחה. הכי חשוב — היא מראה מה לתקן כדי להפוך את האתר למהיר יותר ולמנוע קריסות במהלך מכירות שיא. ביקורת סדירה של אתר 1C-Bitrix מחזירה את ההשקעה תוך 2–3 חודשים: החיסכון באחסון משמעותי, וזמן תיקון השגיאות נחתך פי שלושה בהשוואה לגישה ריאקטיבית.

למה יש צורך בביקורת אתר ביטריקס?

החלפת קבלנים — אתם מקבלים פרויקט מצוות אחר ולא יודעים אילו "מוקשים" נשארו בקוד. Event handlers ב-init.php, סקריפטים שנשכחו, קבצי ליבה ששונו — כל אלה יכולים להתפוצץ ברגע הגרוע ביותר. פעם מצאנו 47 handlers בפרויקט אחד, 12 מהם מתים — בלוקי מידע נמחקו, אבל הקוד המשיך לקרוא ל-CIBlockElement::GetList() בכל כניסה. במשך כמה שנים של עומס כזה — מיליוני שאילתות מיותרות לבסיס הנתונים.

ירידה במיקומים — כמעט תמיד יש סיבות טכניות לאובדן תנועה אורגנית: כפילויות דפים, canonical שבורים, 50,000 כתובות URL זבל באינדקס. ביקורת תראה איפה גוגל מאבדת את התנועה שלכם. בפרויקט טיפוסי אחד, מספר כתובות ה-URL עם פרמטרי מיון הגיע ל-300,000 — כל שילוב של PAGEN_1=2&sort=price קיבל אינדקס בנפרד.

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

חשד לפריצה — מיילים ספאם מהשרת, הפניות לקזינו בתנועה סלולרית, קבצים מוזרים ב-/bitrix/modules/. ביקורת אבטחה תחשוף דלתות אחוריות ו-web shells.

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

מה מסתתר ב-init.php ובבסיס הנתונים?

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

init.php ו-event handlers — מזבלת הקוד העיקרית. שם מצטברים OnAfterUserLogin, OnBeforeOrderAdd, OnAdminContextMenuShow שאף אחד לא מרפקטור במשך שנים. בפרויקט אחד מצאנו 47 handlers, 12 מהם מתים (בלוקי מידע נמחקו, אבל הקוד המשיך לקרוא ל-CIBlockElement::GetList() בכל כניסה). ביקורת מנקה נטל כזה ומפחיתה את עומס השרת.

גרסאות ותאימות. גרסת ליבה — אם היא מתחת ל-22.0, העדכון קריטי (PHP 8.1 לא נתמך). מודולים מ-Marketplace לעיתים קרובות מתנגשים אחרי עדכונים. רישיון ללא מפתח פעיל — אין עדכוני אבטחה.

תצורת שרת. PHP memory_limit < 256M — בעיות עם קטלוגים של 10,000+ פריטים. OPcache revalidate_freq = 0 בסביבת production — CPU עמוס. MySQL innodb_buffer_pool_size צריך להיות 70–80% מה-RAM. ב-MySQL 8.0+ query_cache הוסר, אבל הוא נשאר בקונפיגים ישנים — מייצר שגיאות בלוגים. היעדר expires לקבצים סטטיים ב-nginx — כל רענון דף מוריד JS/CSS מחדש.

בסיס נתונים — החלק המעניין ביותר. טבלת b_event_log גדלה לג'יגה-בייטים ללא הגדרות ניקוי. בפרויקט אחד היא תפסה 12 GB, למרות שנכתבו 500,000 רשומות ביום. טבלת b_search_content_text עם אינדקס full-text יכולה לשקול יותר מהתוכן עצמו. טבלאות ממודולים שנמחקו (b_forum_*, b_learning_*) תופסות מקום ומאטות גיבויים. אנחנו מפעילים slow query log, מחכים יום, מנתחים. שאילתה אחת ל-b_iblock_element_property ללא אינדקס יכולה להאט את כל האתר — תיעדנו עיכובים של עד 7 שניות לדף.

מערכת קבצים. /upload/resize_cache/ — שוקל עשרות ג'יגה-בייטים, מאחסן שינויי גודל של תמונות שנמחקו מזמן. גיבויים בשורש — backup_old.tar.gz ליד index.php, נגישים דרך קישור ישיר. קבצי ליבה ששונו ידנית יוחלפו במהלך עדכון, והלוגיקה המותאמת אישית תיעלם בשקט.

איך ביקורת SEO מסירה כפילויות וזבל מהאינדקס?

פרמטרי סינון ומיון מייצרים אלפי כתובות URL: /catalog/?PAGEN_1=2, /catalog/?sort=price&order=asc — כל אחת מקבלת אינדקס כדף נפרד. מודול ה-SEO של ביטריקס יכול להגדיר canonical, אבל כברירת מחדל הוא לא עושה זאת עבור כתובות URL עם פרמטרים. robots.txt הסטנדרטי חוסם /bitrix/, אבל לא חוסם /search/, /personal/, /ajax/ — יש אלפי דפי זבל נוספים. מחולל ה-sitemap.xml של ביטריקס לפעמים כולל פריטים לא פעילים ודפי 404. ללא נתונים מובנים Schema.org (Product, BreadcrumbList, Organization), הסניפטים בתוצאות החיפוש משעממים. Core Web Vitals: LCP > 2.5s במובייל הוא נפוץ עבור ביטריקס לא אופטימלית — תמונות לא מותאמות ו-JS חוסם הם האשמים. בממוצע, אחרי ביקורת אנחנו מפחיתים את האינדקס ב-60–80% — מסירים כפילויות, מגדירים canonical ו-noindex תקין. הזמינו ביקורת SEO כדי להחזיר לאתר את התנועה שהוא מאבד עכשיו.

למה לבדוק אבטחת ביטריקס?

SQL injections דרך $_REQUEST ברכיבים מותאמים אישית — מפתחים קודמים לא תמיד משתמשים ב-$DB->ForSql(). XSS בעת הצגת קלט משתמש ללא htmlspecialcharsbx(). טפסי העלאת קבצים מותאמים אישית שלא בודקים MIME type וסיומת — מעלים .php בתור "תמונה" ומקבלים web shell. ממצאים טיפוסיים: מודול "Proactive Protection" מושבת (WAF לא עובד, לוג חדירות ריק), פאנל ניהול ללא הגבלת IP (/bitrix/admin/ פתוח לעולם), adminer.php או phpMyAdmin בשורש — נשכחו אחרי מיגרציה, קוד מוסתר ב-.htaccess עם הפניית תנועה סלולרית דרך RewriteCond %{HTTP_USER_AGENT}, קבצי ליבה ששונו עם הכנסות eval(base64_decode(...)). בפרויקט אחד מצאנו 23 קבצים כאלה — האתר הפיץ תוכן ספאם דרך AMP במשך חודשים. קראו עוד על SQL injection ו-cross-site scripting. צרו קשר לבדיקת אבטחה של הפרויקט שלכם — נמצא נקודות תורפה שסורקים מפספסים.

איך אנחנו משפרים ביצועים?

אנחנו עושים profiling עם Blackfire או Tideways — רואים אילו פונקציות צורכות CPU. מועמד תדיר הוא CIBlockElement::GetList() בלולאה (N+1 קלאסי). אנחנו בודקים hit rate של OPcache, Memcached ו-Bitrix managed cache. אם קאש composite מתאפס בכל הזמנה, הוא חסר תועלת — פעם הפחתנו איפוסים מ-80% ל-2% על ידי הגדרת תגים נכונה. Bitrix agents — אם agents_use_crontab לא מופעל, הם רצים על כניסות משתמשים; סוכן כבד = איטי למבקר אקראי. בדיקות עומס: RPS בסיסי, ירידה בביצועים בעומס פי 2 ו-5, התנהגות בחריגה מהמגבלה (השפלה הדרגתית או 502 Bad Gateway?). בפרויקט אחד גילינו ש-RPS השיא היה 12, ואחרי אופטימיזציה הפך ל-150 — עלייה של פי 12.5.

מה אנחנו מחפשים בקוד?

אנחנו מעריכים פיתוחים מותאמים אישית של צוותים קודמים: האם הם משתמשים ב-D7 ORM או רק ב-$DB->Query() שעוקף הכל. PSR-12, autoloading, מבנה מודולים — או הכל בקובץ אחד. N+1 — GetList() בתוך while($arItem = $rsItems->Fetch()) — קלאסי. קבצי ליבה ששונו (bitrix/modules/sale/lib/) עם עריכות ידניות — עדכונים ישברו הכל. פתרונות "זמניים" שחיים שלוש שנים — // TODO: переделать מהשנה שעברה. בממוצע, אנחנו מוצאים 15–25 בעיות בקוד בפרויקט, חצי מהן עם פוטנציאל לאובדן נתונים.

פורמט הדוח

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

כל בעיה מתוארת לפי סכמה: מה מצאנו → איפה → איך זה משפיע → איך לתקן → מאמץ. אנחנו מספקים את הדוח ב-PDF וב-Google Docs לשיתוף פעולה. חמישה סימנים שאתר ביטריקס צריך ביקורת: init.php גדל מעל 2,000 שורות; בסיס הנתונים עולה על 5 GB, וטבלת b_event_log מעל 1 GB; דפים נטענים יותר מ-3 שניות במובייל; Search Console מראה עשרות אלפי דפים באינדקס עם שגיאות; מצאתם קבצים עם תוכן חשוד ב-/bitrix/modules/. אם לפחות נקודה אחת מתאימה — הגיע הזמן להזמין ביקורת.

איך אנחנו מבצעים ביקורת?

  1. גישה — פאנל ביטריקס, SSH, בסיס נתונים, Yandex.Webmaster, Search Console.
  2. אוטומציה — "Quality Monitor" של ביטריקס, Screaming Frog, GTmetrix, סורקי אבטחה. תופסים 60% מהבעיות.
  3. ניתוח ידני — 40% הנותרים. ארכיטקטורה, קוד, לוגיקה עסקית, תצורה — רק עם הידיים. כל ביקורת מונחית על ידי מפתח בכיר עם 10+ שנות ניסיון.
  4. דוח עם סדרי עדיפויות.
  5. דיון — פגישה איתכם, מענה על שאלות, הסכמה על תוכנית תיקון.

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

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

  • דוח מתועד עם תיאור כל בעיה והמלצות לתיקון.
  • רשימת בדיקה של נקודות תורפה קריטיות וסדר העדיפות שלהן.
  • רשימת הצעות לאופטימיזציית ביצועים עם הערכת השפעה.
  • ייעוץ לאחר הביקורת — סקירת תוצאות, תעדוף משימות.
  • גישה לתוצאות בדיקות (צילומי מסך, לוגי profiling, נתונים גולמיים).

סוגי ביקורת ולוחות זמנים

סוג לוח זמנים למי
אקספרס (checklist) 2–3 ימים הערכה מהירה, אתרים קטנים
טכנית 3–5 ימים זיהוי בעיות תשתית
SEO 3–5 ימים ירידה במיקומים, זבל באינדקס
אבטחה 5–7 ימים אתרים עם תשלומים, נתונים אישיים
ביצועים 3–5 ימים איטיים, קריסות תחת עומס
מקיפה 2–3 שבועות תמונה מלאה לפני השקעות רציניות

ביצענו 50+ ביקורות של פרויקטי ביטריקס — מחנויות מקוונות ועד פורטלים ארגוניים. הניסיון שלנו מראה: בממוצע, ביקורת מחזירה את ההשקעה תוך 2–3 חודשים על ידי הפחתת עלויות אחסון וקיצור זמן תיקון השגיאות (פי 3 מהר יותר מגישה ריאקטיבית). ביקורת סדירה היא הדרך הטובה ביותר להאריך את חיי הפרויקט.

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