מדוע FAQ ב-Bitrix הורס את החיפוש ואת ההמרה
מדור השאלות ב-Bitrix נבנה לרוב "בחפזון": אינפובלוק אחד, תבנית אחת, והתשובות מוצגות באקורדיון דרך סקריפט. מבחוץ זה נראה מסודר, אבל עבור מנועי החיפוש הדף הופך לאוסף של כותרות זהות ללא תוכן — התשובות נטענות כבר בדפדפן ואינן קיימות בקוד המקור. הרובוט רואה בלוקים ריקים, מאנדקס אותם כבלתי שימושיים ומוריד את המשקל של כל המדור.
הטעות הטיפוסית השנייה — כפילויות. כל שאלה מקבלת כתובת משלה, אבל תגי המטא עוברים בירושה מתבנית האינפובלוק: title זהה, תיאור זהה, כותרת ראשית זהה. עבור החיפוש מדובר בעשרות דפים כמעט זהים, שמתחרים ביניהם ומטשטשים את הרלוונטיות. אם לכך מתווספת ניווט בין דפים ללא כתובות קנוניות, מספר הכפילויות גדל פי כמה.
הבעיה השלישית — היעדר מיקרו-סימון. גם כאשר התשובות נראות בקוד, החיפוש אינו מבין שלפניו שאלה ותשובה, ואינו מציג סניפט מורחב. סימון מסוג FAQPage מסיר את אי-הוודאות הזו: מנוע החיפוש מקבל מבנה מפורש ויכול להציג את השאלה ישירות בתוצאות, ולקחת את הקליק מהמתחרים עוד לפני המעבר לאתר.
בנפרד נפגע החיפוש הפנימי. המודול המובנה מחפש לפי אינדקס, שאליו התוכן של אינפובלוק השאלות לא תמיד נכנס — במיוחד אם התשובה נשמרת במאפיין נפרד או נטענת באופן דינמי. המבקר אינו מוצא את התשובה, פונה לתמיכה או סוגר את הלשונית, אף שהמידע נמצא באתר.
לסיכום: מדור השאלות, שתוכנן להפחית את העומס על התמיכה, מתחיל לפעול לרעת האתר — מאבד מיקומים, אינו נכנס לסניפטים מורחבים ואינו עוזר למשתמש למצוא את התשובה. נבחן כיצד זה נסגר ברמת מבנה האינפובלוק, תבניות ההצגה והגדרות האינדוקס.
מה נותן מדור FAQ שנבנה נכון
מדור FAQ שנבנה נכון הוא לא "עמוד עם שאלות", אלא מקור תנועה מנוהל והקלה על התמיכה.
כאשר השאלות מקובצות לפי נושאים, מסומנות במיקרו-דאטה ומקושרות לכרטיסי מוצרים ושירותים, מנועי החיפוש מתחילים להציג תשובות ישירות בתוצאות החיפוש — שיעור ההקלקות מהחיפוש עולה ללא השקעות נוספות בפרסום. במקביל יורד מספר הפניות לתמיכה: הלקוח מוצא את התשובה בעצמו, בלי להמתין לתשובת הנציג.
מבנה ה-FAQ ב-1C-Bitrix נבנה כך שכל שאלה תהיה ישות נפרדת עם כתובת, כותרת וסימון משלה. זה נותן שלושה אפקטים בבת אחת: העמודים מאונדקסים לפי שאילתות ספציפיות, הקטעים בתוצאות החיפוש תופסים יותר מקום, והקישורים הפנימיים מפיצים משקל בין המדורים המקושרים. בלי מבנה כזה השאלות נשארות טקסט "מת" שהחיפוש כמעט לא מתחשב בו.
מהירות הפרסום היא פרמטר נמדד נפרד. כאשר תבנית השאלה, השדות וכללי הסימון מוגדרים מראש, חומר חדש מופק תוך דקות: מנהל התוכן ממלא טופס, המערכת עצמה יוצרת את העמוד, מוסיפה אותו למפת האתר ומקשרת אותו למדור הנדרש. בפרויקטים שבהם התהליך הזה לא אוטומטי, פרסום של שאלה אחת נמשך ימים ודורש מפתח.
בסופו של דבר ה-FAQ מפסיק להיות "תוספת" לאתר והופך לכלי עבודה: הוא מביא תנועה ממוקדת מהחיפוש, מסיר חלק מהעומס מהתמיכה ומאפשר לסגור במהירות שאילתות מידע חדשות. בהמשך נבחן איך זה בנוי ברמת המבנה וההגדרות.
אפשרויות מימוש FAQ: השוואת גישות
בביטריקס אוספים את מדור השאלות בארבע דרכים, והבחירה נקבעת לא לפי "יופי" אלא לפי מי ובאיזו תדירות יוסיף שאלות. אם את התוכן מנהל עורך בלי גישה לקוד — דרך אחת; אם נדרשת מבנה קשיח ומיקרו-סימון אוטומטי — דרך אחרת.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| אינפובלוקים | עשרות-מאות שאלות, עריכות שוטפות, נדרשים קטגוריות וסינון | דורש הגדרת מאפיינים ותבניות; בלי התאמה אישית הפלט והסימון "מהקופסה" דלים |
| דפים סטטיים | 5-15 שאלות, משתנות לעיתים רחוקות, חשובים המהירות והפשטות | אין חיפוש וקיבוץ; עם גידול מספר השאלות הדף הופך למחסן |
| מודולים מוכנים | נדרש התחלה מהירה עם ממשק וסימון מוכנים | תלות בקוד זר, התאמה אישית מוגבלת, סיכון לקונפליקטים בעדכונים |
| קומפוננטה מותאמת אישית | לוגיקה לא סטנדרטית: קישור לפניות, תפקידים, ריבוי שפות | יקרה יותר בפיתוח ובתחזוקה, נדרשת תיעוד לצוות |
מה לקחת בחשבון בבחירה
אינפובלוקים — פשרה עובדת לרוב: העורך מוסיף שאלה דרך ממשק הניהול המוכר, והמפתח מגדיר פעם אחת תבנית ומיקרו-סימון. דפים סטטיים מוצדקים רק בהתחלה — מעבר לאינפובלוק בהמשך יעלה יותר מאשר להניח מבנה מראש.
מודולים מוכנים חוסכים זמן בהשקה, אך ההיצמדות לקוד זר נותנת את אותותיה כבר בעדכון הראשון של הליבה. קומפוננטה מותאמת אישית נלקחת כאשר FAQ הוא חלק מהלוגיקה העסקית, ולא סתם בלוק טקסטואלי.
שלבי הגדרת מדור שאלות נפוצות במפתח סופי
הגדרת שאלות נפוצות אינה "להתקין רכיב ולהעלות שאלות". המדור חי בתוך אינפובלוק, העמודים שלו מתחרים על מיקומים עם חומרים אחרים באתר, והסימון חייב להתאים למה שהמבקר באמת רואה. לכן אנחנו עובדים בשלבים, מהביקורת ועד לתקנון, כדי שהמדור לא יתפרק חודש אחרי ההשקה.
- ביקורת המדור הנוכחי. בודקים מה כבר קיים: מבנה הקטגוריות, כפילויות של שאלות, עמודי עימוד שבורים, משקל התבנית. בודקים אם עמודי השאלות לא הודבקו לאחד בגלל כותרות זהות ו-canonical — זו הסיבה הנפוצה ביותר לכך שהמדור אינו מאונדקס.
- סכמת נתונים. מתכננים את האינפובלוק: מאפיינים נפרדים לשאלה, לתשובה, לקטגוריה ולסדר התצוגה, קישור למדורי הקטלוג או השירותים. בשלב זה מחליטים אם כל שאלה תהיה עמוד נפרד או בלוק מתרחב — מכך תלויה כל הלוגיקה בהמשך.
- הגדרת רכיבים. בונים את התצוגה על רכיבים סטנדרטיים עם מטמון לפי קטגוריות, מגדירים ניווט עמודים וכתובות קריאות לאדם. מתקנים את התבנית כך שהסימון של השאלה והתשובה יוגש בקוד המקור, ולא ייטען בסקריפט.
- סימון ומטא-נתונים. רושמים כותרות, תיאורים ונתונים מובנים עבור סניפטים מורחבים, ומקשרים את המדור בקישור פנימי לעמודים מקצועיים.
- בדיקת אינדוקס. מגישים מפת אתר, בודקים robots ותגובות שרת, ובודקים כיצד מנועי החיפוש סורקים את עמודי השאלות ואם כתובות שירות נכנסות לאינדקס.
- תקנון תחזוקה. קובעים מי ולפי איזו תבנית מוסיף שאלות, כיצד נבדקות כפילויות והיכן לבצע תיקונים בסימון.
לאחר מסירת התקנון ניתן למלא את המדור בכוחות מנהל התוכן, מבלי לפגוע במבנה ומבלי לשבור את האינדוקס. אם כבר יש לכם מדור שאלות — נתחיל בביקורת ונראה מה מונע ממנו לעבוד.
מה נכלל בתוצאה: תצורה ותיעוד
התוצאה של העבודה — לא "מדור שאלות מוכן", אלא ערכת הגדרות ומסמכים שלפיה המדור חי ומתפתח בלעדינו. להלן — מה בדיוק מועבר ללקוח.
- הגדרות אינפובלוקים: מבנה המדורים ותת־המדורים, מאפיינים של פריטים עבור שאלה ותשובה, שיוך לנושאים, הרשאות להוספה ולעריכה עבור כל תפקיד.
- תבניות תצוגה: רכיבים של רשימה ושל עמוד מפורט, סימון של בלוק "שאלה — תשובה", התנהגות הפתיחה, ניווט בין עמודים והצגת שאלות דומות.
- כללי מיקרו־סימון: איזה סוג סימון שמים על עמוד השאלה, היכן ממקמים את הבלוק עם התשובות, כיצד מקשרים שאלות למדורי שירותים וכיצד בודקים תקינות לפני פרסום.
- מפת המדור: רשימה של כל השאלות עם שיוך לאינפובלוקים, לתבניות ולכתובות עמודים — לפיה רואים לאן להוסיף שאלה חדשה ומה היא תשפיע.
- הוראות לעורך: סדר פעולות שלב אחר שלב להוספת שאלה, דרישות לניסוח הכותרת וטקסט התשובה, עבודה עם תמונות וקישורים, מה לעשות בעת העברת שאלה למדור אחר.
- תקנון פרסום: מי מאשר את הטקסט, באיזה שלב השאלה נכנסת לסימון, באיזו תדירות בודקים מחדש תשובות מיושנות.
- מערך בדיקות: בקרת כפילויות של שאלות, קישורים שבורים בתוך תשובות, תקינות הסימון ומהירות טעינת עמוד המדור.
כל סעיף מועבר בצורה שמתאימה לעבודה: הגדרות — בפאנל הניהול, תבניות — בקבצי התבנית, כללים והוראות — במסמך עם דוגמאות. העורך ללא מפתח מוסיף שאלה חדשה בתוך דקות ספורות ואינו שובר את מבנה המדור.
מקרה בוחן: כיצד מדור השאלות הפסיק לאבד תנועה
הפרויקט — אתר ארגוני על 1C-Bitrix עם מאגר של כ-400 שאלות שנצברו במשך שנים. מדור השאלות הנפוצות היה קיים, אך פעל כמזבלה: שאלות פורסמו ידנית דרך ממשק הניהול, התשובות ישבו בתבנית אחת, לכל עמוד היה title זהה וחסר סימון מיקרו. מנועי החיפוש כמעט לא אינדקסו עמודים כאלה, וחלק מהשאלות שכפלו תוכן של מדורים ראשיים.
מה היה לפני
מתוך 400 שאלות, כ-90 נמצאו באינדקס — שיעור האינדוקס עמד על 22%. מעברים מחיפוש במדור הניבו בממוצע 340 ביקורים בחודש, כאשר 80% מהתנועה הגיעה מעשרה שאלות ישנות. שאלה חדשה פורסמה תוך 3-5 ימים: מנהל התוכן חיכה לתשובה מהמחלקה הרלוונטית, לאחר מכן הרכיב ידנית את העמוד ומילא תגי מטא. מחצית מהשאלות נותרו כך בטיוטות.
מה שינו
בנינו מחדש את המבנה: כל שאלה קיבלה URL נפרד עם כתובת קריאה לבני אדם, כותרת ותיאור ייחודיים, וכן סימון FAQPage — מנוע החיפוש החל להציג את התשובה ישירות בתוצאות. הוספנו קישוריות פנימית: מהתשובה מובילים כעת קישורים לעמודי השירותים הרלוונטיים, ומכרטיסי השירותים — לשאלות קשורות. הפרסום הועבר לטופס: המנהל ממלא שדות, השאלה עוברת לאישור, ולאחר האישור העמוד נבנה אוטומטית.
מה קרה בסוף
שיעור העמודים המאונדקסים עלה מ-22% ל-87% — רוב השאלות נכנסו לאינדקס, כולל הישנות. מעברים מחיפוש עלו מ-340 ל-1,900 ביקורים בחודש, כאשר התנועה התפזרה על פני מאות עמודים ולא על פני עשרה. זמן הפרסום הצטמצם מ-3-5 ימים למספר שעות: צוואר הבקבוק עבר מהטמפלייט לאישור הטקסט. כפילויות עם המדורים הראשיים הוסרו באמצעות כתובות קנוניות, ומיקומי עמודי השירותים רק עלו כתוצאה מכך.
במה שונה FAQ באינפובלוק מדף סטטי
אינפובלוק שומר שאלות כרכיבים עם שדות ומאפיינים, ואילו דף סטטי הוא קובץ אחד שבו הסימון והטקסט נמצאים יחד. מכאן נגזר כל השאר: כמה מהר אתם עורכים תוכן, עד כמה גמישה ההצגה שלו ואיך הוא נראה בעיני החיפוש.
מהירות העריכות היא הדבר הראשון שהעורך חווה. באינפובלוק שאלה מתווספת דרך ממשק הניהול: מילאת שדות, בחרת מדור, שמרת — הרכיב מיד נכנס לרשימה הכללית ולהצגה באתר. בדף סטטי כל עריכה משמעה עבודה עם קובץ: למצוא את בלוק הסימון הנכון, לא לשבור את השכנים, לשמור.
כשהשאלות רבות ומתעדכנות באופן קבוע, הפער מצטבר — עורך בלי גישה לקוד באינפובלוק עובד בעצמו, ואילו בסטטי הוא ממתין בכל פעם למפתח.
גמישות התבניות נקבעת לפי המקום שבו יושבת ההצגה. באינפובלוק הלוגיקה מוצאת לתבנית של רכיב: הגדרתם את הסימון פעם אחת — וכל השאלות החדשות מוצגות באותה צורה, וסינון, מיון וניווט בין דפים מתחברים דרך ההגדרות.
דף סטטי לא נותן שימוש חוזר כזה: כדי לשנות מבנה, עורכים את הסימון ידנית בכל מקום שבו הוא משוכפל, וקל לקבל אי-התאמות בין הדפים.
האינדוקס תלוי לא באופן האחסון, אלא במה שנכנס ל-HTML הסופי. אינפובלוק מחזיר סימון מוכן בשרת, ולכן רובוטי החיפוש רואים את השאלות והתשובות מיד, והמיקרו-סימון של FAQ נוצר בתבנית אוטומטית עבור כל הרכיבים.
דף סטטי מאונדקס באותו אופן, אבל בהדבקה ידנית יש לתחזק את המיקרו-סימון בכל בלוק בנפרד — והוא מתפצל מהתוכן כבר בעריכה הראשונה.
המסקנה המעשית: אינפובלוק מנצח במקום שבו FAQ גדל ומתעדכן, ואילו סטטי מתאים לכמה שאלות בלתי משתנות. לעתים קרובות בוחרים בהיברידי — אחסון באינפובלוק, והצגה בדף נפרד דרך רכיב עם ЧПУ וניווט בין דפים.
ספקות טכניים נפוצים בנוגע ל-FAQ ב-Bitrix
מדור השאלות הנפוצות ב-Bitrix לעיתים רחוקות נשבר "מעצמו" — בדרך כלל הוא מתפצל משאר התשתית של האתר. השאלות והתשובות מאוחסנות באינפובלוק, מוצגות דרך קומפוננטה, נשמרות במטמון יחד עם העמוד ובמקביל משתתפות בסימון מיקרו ובחיפוש באתר.
ברגע שאחת מהקשרים הללו משתנה ידנית, מתחילים לצוף כפילויות, תשובות מיושנות ועמודים שנעלמו מתוצאות החיפוש.
להלן — ספקות טכניים שאיתם פונים אלינו לרוב לתמיכה: כיצד לסמן שאלות כך שיופיעו בקטעי תוצאות מורחבים, כיצד להגדיר מטמון כך שעריכת תשובה תופיע מיד, וכיצד להעביר מאגר שאלות מצטבר ממערכת ישנה ללא אובדן מבנה וכתובות.
כיצד לסמן שאלות כך שמנועי החיפוש יראו אותן?
נוח ליצור סימון מיקרו מאותו אינפובלוק שממנו מוצג המדור — אז השאלה והסימון לא מתפצלים בעת עריכות. אנו בודקים תקינות באמצעות כלים למנהלי אתרים ומקפידים שהסימון לא יוכפל בניווט בין עמודים.
מדוע לאחר עריכת התשובה באתר נשארת הגרסה הישנה?
הקומפוננטה מחזירה עמוד שמור במטמון, ותוקף המטמון אינו מקושר לשינוי אלמנט באינפובלוק. אנו מגדירים איפוס מטמון לפי אירועי שינוי ומפצלים את המטמון לפי קבוצות משתמשים, כך שאורח ומשתמש מאומת יראו טקסט מעודכן.
כיצד להעביר שאלות ממערכת ישנה ללא אובדן כתובות?
אנו אוספים ייצוא, משווים שדות ומעבירים שאלות לאינפובלוק תוך שמירה על הכתובות הקודמות באמצעות כללי עיבוד. עמודים ישנים נסגרים בהפניה מחדש, כדי שתעבורת החיפוש המצטברת לא תלך לאיבוד.
מה לעשות עם כפילויות של שאלות בחיפוש באתר?
הסיבה — מספר עמודים עם תוכן זהה או איחוד ניסוחים שונים של אותה שאלה. אנו מפחיתים חזרות לעמוד קנוני, מגדירים אינדוקס ומחריגים מדורים שירותיים מתוצאות החיפוש.
תארו כיצד בנוי אצלכם כעת מדור השאלות ומה בדיוק מטריד — נחזור עם הערכה ותוכנית עבודה.
נדון במשימה שלכם לסעיף השאלות הנפוצות
כדי לחזור עם הערכה ותוכנית, ולא עם מילים כלליות, עלינו להבין את מבנה המערכת שלכם: באיזו מהדורה פועל הפורטל, כיצד בנוי הסעיף כעת ומה בדיוק אתם רוצים לקבל מהשאלות הנפוצות — בלוק מידע ללקוחות, דפי נחיתה לשאילתות חיפוש או בסיס ידע לעובדים. מכך נגזרים מבנה השאלות, הסימון ודרך התצוגה.
שלחו את מה שיש בהישג יד — בהמשך נשאל שאלות ממוקדות לעניין:
- כתובת האתר וגישה לפאנל הניהול או לסביבת בדיקה;
- רשימת הסעיפים וסוגי הדפים שבהם השאלות הנפוצות אמורות להופיע;
- רשימת השאלות, אם כבר נאספה — בטבלה, במסמך או בייצוא מפניות;
- דוגמאות לדפי מודל שהמראה וההיגיון שלהם מוצאים חן בעיניכם;
- דרישות לתפקידים: מי עורך את השאלות, מי מפרסם, האם נדרש אישור;
- מגבלות לוחות זמנים ותאריכים שבהם הסעיף צריך לפעול;
- איש קשר של מי שמקבל את התוצאה ועונה על שאלות בנוגע לתוכן.
בסיום אתם מקבלים לא אוסף קבצים, אלא סעיף עובד והוראות ברורות עבורו: מבנה שאלות ומדור מוסכמים, תצוגה מוגדרת עם סימון תקין לחיפוש, תבניות דפים בהתאמה לעיצוב שלכם, הרשאות גישה לעורכים ותקנון קצר — כיצד להוסיף ולעדכן שאלות בכוחות עצמכם.
המסירה מתבצעת בסביבת בדיקה: אתם בודקים את התנהגות הסעיף בתרחישים שלכם, אנחנו מתקנים את ההערות ורק לאחר מכן מעלים לאתר הפעיל.
תארו את המשימה בצורה חופשית — מהו הפורטל, איזה סעיף נדרש ובאיזה מועד. נחזור עם הערכה, תוכנית עבודה ורשימה של מה שיידרש מצדכם.