הפניה מ-HTTP ל-HTTPS ב-Bitrix: היכן נשברת השרשרת
האתר נפתח גם בכתובת רגילה וגם בכתובת מאובטחת, ושתיהן מחזירות תוכן אמיתי. חלק מהמדורים כבר הועברו לפרוטוקול מאובטח, וחלק נשארו ברגיל — כך נוצרות כפילויות של כתובות האתר: מנוע החיפוש רואה שני עמודים עם אותו תוכן ומחלק ביניהם את המשקל. אזהרת הדפדפן על חיבור לא מאובטח כאן אינה תקלה אקראית, אלא סימן שכלל המעבר לא הוגדר בכל המקומות.
הקטיעה כמעט תמיד בנקודה אחת: הפניית http https ב-Bitrix רשומה בנקודת כניסה אחת, אף שיש כמה נקודות. הכלל יכול להיות בקונפיגורציה של שרת האינטרנט, בהגדרות האתר עצמו או בשניהם — ואז נוצרת קטיעה בשרשרת ההפניות: הדפדפן מקבל שניים-שלושה מעברים ברצף, מאבד כתובות או נכנס ללולאה.
סיבה נפרדת — תוכן מעורב בעמוד: המסמך עצמו נמסר בפרוטוקול מאובטח, אבל תמונות, סקריפטים וטפסים נמשכים בפרוטוקול רגיל. הדפדפן מסמן חיבור כזה כלא מאובטח וחוסם חלקית את הטעינה — טפסים לא נשלחים, תמונות לא מוצגות.
בהמשך גם הדוחות מתפצלים: אותו עמוד מגיע לאנליטיקה בשתי כתובות, ומקורות ויעדים נספרים לפי מערכי נתונים שונים. נבחן כיצד סוגרים זאת: היכן לבנות שרשרת מעברים אחידה, כיצד להסיר תוכן מעורב ולהביא את כל הכתובות לגרסה אחת.
מה נותנת סכימה אחידה של הפניות מאובטחות
סכימה אחידה של הפניות מאובטחות מביאה את האתר לכתובת קנונית אחת. מנועי החיפוש מפסיקים לראות כפילויות: המראה הראשית והמשניות מתאחדות, ומשקל העמוד אינו מתפזר בין גרסאות עם HTTP ו-HTTPS, עם www ובלעדיו, עם לוכסן בסוף ובלעדיו.
בתוצאות החיפוש נשארת כתובת אחת, ולכן המיקומים אינם מתחלקים בין עותקים, וקישורים חיצוניים עובדים לגרסה אחת של האתר.
עבור המבקר משמעות הדבר היא היעדר אזהרות דפדפן על חיבור לא מאובטח — האמון באתר נוצר עוד לפני הקליק הראשון על התפריט. הדפדפן אינו חוסם טפסים, סקריפטים וווידג'טים חיצוניים, שליחת הפנייה מתבצעת מהניסיון הראשון, והנתונים אינם הולכים לאיבוד בדרך.
שלמות הטפסים חשובה גם מהצד השני: אם המבקר פותח גרסה מאובטחת של העמוד, והטופס נשלח לכתובת ישנה, חלק מהפניות נעלם בלי שיבחינו.
דוחות האנליטיקה מתכנסים. כאשר המעבר אינו קוטע את השרשרת מתג המקור, אנליטיקה מקצה לקצה רואה כניסה אחת לביקור, ולא שניים-שלושה, והערוצים אינם משוכפלים בדוחות. אחרת חלק מהתנועה מיוחס לכניסה ישירה, והחלטות לגבי ערוצים מתקבלות על נתונים מעוותים.
אפקט נפרד — הסרת סוג התקלות במעברים בין גרסאות העמוד: שרשראות ההפניות מתקצרות למעבר אחד, ולא נותרות לולאות ו"קפיצות" בין כתובות.
ב-1C-Bitrix כללים כאלה מתוארים באופן הצהרתי ומיושמים ברמת קונפיגורציית האתר, ולכן מדורים ותת-דומיינים חדשים יורשים את הסכימה בלי עריכה ידנית לכל אחד.
אפשרויות הגדרת הפניות: השוואת גישות
כלל ההפניה חי בארבע רמות — מהמעטפת החיצונית ועד להגדרות בתוך הפלטפורמה. הבחירה משפיעה על ההתנהגות בעת עדכון קונפיגורציית השרת, בעבודה מאחורי פרוקסי הפוך ובריבוי אתרים: אותו כלל בשכבות שונות פועל אחרת, עד כדי לולאה.
מלכודת נפרדת — קביעת הסכימה המקורית. אם הבקשה הגיעה ב-HTTPS לפרוקסי, אך לאתר הגיעה ב-HTTP והכותרת עם הסכימה המקורית אבדה, הפלטפורמה מחשיבה את החיבור ללא מאובטח ובונה קישורים מוחלטים ב-HTTP — מקבלים תוכן מעורב ולולאה בהפניה. לכן את הכלל עצמו ואת זיהוי הסכימה מגדירים באופן עקבי.
| אפשרות | מתי מתאים | מגבלות |
|---|---|---|
| כלל על השרת (.htaccess, קונפיגורציית שרת אינטרנט) | אתר אחד, דומיין טיפוסי; פועל לפני הפעלת האפליקציה | נמחק בעדכון קונפיגורציה; נדרשת גישה לשרת |
| כללים בקונפיגורציית האתר (טיפול בכתובות) | תנאים לפי דומיין או מדור, גישה רק דרך ממשק הניהול | מבוצע אחרי אתחול הפלטפורמה, חלק מהבקשות עוברות ב-HTTP; נדרש איפוס מטמון כללים |
| הגדרות בתוך הפלטפורמה והמודולים שלה | אתר או חנות טיפוסיים, מינימום התערבות | אינו מכסה סקריפטים שירותיים, החלפה עם 1C, סוכנים, אינטגרציות |
| צומת חיצוני לפני האתר (מאזן עומסים, פרוקסי הפוך) | כמה שרתים, נקודת סיום אחת לחיבור מאובטח | נדרשת העברת הסכימה המקורית, אחרת לולאה; הלוגיקה מחוץ למאגר הפרויקט |
בפועל משלבים שכבות: כלל קשיח מציבים על הצומת החיצוני, ובתוך הפלטפורמה מאשרים את הסכימה המאובטחת — המעבר אינו תלוי בכך שאיזה שרת קיבל את הבקשה.
סדר היישום: ממיפוי ועד מסירה
את העבודה מבצעים ברצף: תחילה מתעדים את המצב הקיים, אחר כך מתכננים כללים, ורק לאחר מכן נוגעים בסביבת הייצור. סדר כזה מסיר את הטעות הקלאסית, שבה הפניה מוגדרת "לפי העין" ומקבלים שרשראות הפניות או עמודים שנפלו מהאינדקס.
- מיפוי כתובות ותת-דומיינים. אוספים מפה מהגדרות האתרים, מקונפיגורציית השרת ומהסטטיסטיקה: אילו דומיינים, מראות וכתובות ישנות באמת מגיבים, אילו כבר מחזירים תוכן, ואילו אמורים להוביל לגרסה הקנונית.
- סכימת הפניות. קובעים כתובת ראשית אחת וכלל מעבר אליה מכל השאר — עם חריגים למדורים שירותיים, טפסים, תשלום והחלפת נתונים, שבהם הפניה שוברת את העבודה.
- הגדרה על עותק. מעבירים את הכללים לסביבת בדיקות ומתקנים את קונפיגורציית השרת, ולא רק את הגדרות האתר — אחרת חלק מהכתובות נשארות בגרסה הישנה.
- בדיקה על עותק האתר. מריצים את מפת הכתובות ובודקים קודי תגובה, אורך שרשראות, לולאות, לוכסנים, רישיות ותוכן מעורב. כאן זול יותר למצוא שגיאה מאשר על תנועה חיה.
- העברה לסביבת הייצור. מפעילים את הכללים בשלבים, starting with תת-דומיינים ומראות משניות, ושומרים חזרה לאחור מוכנה: החזרת הקונפיגורציה הקודמת אורכת דקות.
- בקרה לאחר השחרור. בימים הראשונים עוקבים אחר קודי תגובה, גידול בשגיאות, סריקה על ידי רובוטים של מנועי חיפוש. מתעדים את הכללים בקונפיגורציה, כדי שעדכון הליבה לא ימחק אותם.
- מסירה. מוסרים מפת כתובות, סכימת הפניות וסדר חזרה לאחור — כדי שהתמיכה תוכל להוסיף תת-דומיין חדש בלי לנתח את הלוגיקה מחדש.
כך הפניה מ-HTTP ל-HTTPS ב-Bitrix מפסיקה להיות תיקון חד-פעמי והופכת לכלל מנוהל עם תחום אחריות ברור.
מפת הפניות, קונפיגורציות ונוהלים
לאחר סיום העבודה, ההגדרות אינן נשארות "בראש של הקבלן". כל מה שקשור להפניות מתועד במסמכים שנקראים בלי גישה לשרת ולפאנל הניהול. הערכה נאספת עבור קונפיגורציית אתר מסוימת, ולא כתזכורת כללית מהאינטרנט.
- מפת הפניות — טבלה "כתובת ישנה → כתובת חדשה → סוג תגובה → מקור הכלל": רואים מאיפה הגיע כל כלל ואילו כתובות הוא מכסה.
- אוסף כללים וחריגים — סדר טיפול בבקשה: תחילה התאמות מדויקות, אחר כך תבניות, אחר כך מעבר כללי לפרוטוקול מאובטח; בגוש נפרד מפורט מה לא נוגעים בו.
- קונפיגורציות האתר — קבצי עבודה והגדרות מודולים עם הסברים שורה-שורה, איזו הנחיה אחראית למה ומה יקרה אם מסירים אותה.
- תרשים עקיפת חריגים — שרשרת בדיקות בבקשה נכנסת: באיזה שלב הכלל פועל, והיכן הוא עלול שלא לחול.
- נוהל בדיקה — סט כתובות בקרה ותדירות הרצה: אחרי שחרור, אחרי מעבר, בעת חיבור דומיין או מדור חדש.
- הוראה למנהל תוכן — מה לעשות בעת פרסום עמוד או שינוי כתובת, כדי לא ליצור כפילות ולא לשבור הפניה קיימת.
- יומן שינויים — מי, מתי ולמה ערך את הכללים: בניתוח התנהגות בלתי צפויה רואים אחרי איזה שינוי היא החלה.
הוראה למנהל תוכן נכתבת קצר ובשלבים: בדיקת כתובת, הצבת משימה, תוצאה צפויה. כך העריכות מפסיקות להיות תלויות באדם אחד ולא דורשות בכל פעם לפנות למפתח.
מקרה בוחן: הסרנו כפילויות כתובות ותוכן מעורב
איך זה היה
קטלוג על 1C-Bitrix הגיב בכמה כתובות בבת אחת — מאובטחת ולא מאובטחת, עם www ובלעדיו. בחיפוש הצטברו כ-4,800 כתובות, כל חמישית הייתה כפילות, וחלק מהמדורים החזירו כתובת לא מאובטחת. הדפדפן הציג אזהרה, והמבקר עזב לפני שהספיק לראות את המוצר.
מה עשינו
הבאנו הכול לכתובת קנונית אחת: הפניות קבועות מכל שאר הגרסאות, כותרות אבטחה מחמירות, מפת אתר שנבנתה מחדש. קישורים פנימיים בתבניות הוחלפו למאובטחים, ו-canonical הובא לצורה אחידה. בנפרד עברנו על הטפסים — בעת הפניה הפנייה לא צריכה ללכת לאיבוד.
מה נהיה
אחרי חודשיים בחיפוש נשארו כ-3,100 כתובות: הכפילויות נעלמו, ומשקל העמודים התכנס למראה אחת. אין יותר אזהרות על תוכן מעורב, ההפניות פועלות בלי שרשראות — מעברים מכתובות ישנות נשמרו, ולכן המיקומים לא ירדו.
פניות מהטפסים נעשו יציבות יותר: שליחות שלא הגיעו בגלל תקלה בחיבור לא מאובטח נעלמו, ומספר הפניות הכולל גדל בכחמישית. יעדים באנליטיקה הוגדרו כך שבשרשרת הפניות האירוע לא ייספר פעמיים.
במה שונה הפניה על השרת מהגדרה באתר?
הבקשה לא מגיעה לפלטפורמה מיד. תחילה היא מתקבלת על ידי שרת האינטרנט: אם המעבר מתואר בקונפיגורציה שלו, תגובה עם קוד 301 נשלחת ללקוח לפני טעינת ליבת האתר והניתוב. זוהי רמת הטיפול העליונה — המסלול הקצר ביותר והעומס המינימלי על האפליקציה.
הפניה שהוגדרה בתוך האתר פועלת אחרת: הבקשה עוברת הפעלה מלאה של האפליקציה — אתחול הליבה, ניתוח הכתובת, בדיקת הגדרות המודול — ורק אחר כך נוצרת כותרת המעבר. שלבים מיותרים בשרשרת עולים בזמן בכל בקשה, ובזרימה נותנים גידול בעומס על שרת האפליקציה.
עדיפות הכללים נקבעת לפי סדר הטיפול. אם המעבר כבר ניתן ברמת השרת, כלל בהגדרות האתר לא יפעל — הבקשה לא תגיע אליו. מכאן הקונפליקט הטיפוסי בהגדרות: שני כללים לאותה כתובת, קודי תגובה שונים (301 ו-302), ולפעמים שרשרת מעברים בלולאה.
המסקנה — נקודת כניסה אחת. מעבר מ-HTTP ל-HTTPS מתואר ברמת שרת האינטרנט, ובתוך הפלטפורמה נשאר רק מה שדורש לוגיקת אפליקציה: ריבוי אתרים, אזורים, גרסאות שפה. אז אותה כתובת מטופלת באופן צפוי, בלי קשר לעמוד או למדור שנפתח.
בודקים זאת לפי כותרות תגובה ויומנים: כמה מעברים יש בשרשרת, איזה קוד בכל אחד, מי החזיר את התגובה — השרת או הפלטפורמה. המטרה — מעבר אחד בלי כתובות ביניים ועם שמירת הנתיב.
שאלות טכניות נפוצות על הגדרת הפניות
לפני שמוסרים הפניות לעבודה, המהנדסים סוגרים ספקות שעולים לרוב בקבלה: האם תוצאות החיפוש יירדו, מה לעשות עם תת-דומיינים ומדורים, האם פניות מהטפסים יאבדו וכיצד לוודא שהמעבר הושלם לגמרי. להלן — תשובות קצרות לכל אחד.
האם מעבר לכתובת מאובטחת ישפיע על המיקומים בחיפוש?
מבנה הכתובות והתוכן נשארים כשהיו, רק הפרוטוקול משתנה. בהפניה קבועה מנועי החיפוש מעבירים את האותות המצטברים לכתובת המאובטחת, ובאינדקס נשאר עמוד אחד במקום שני עותקים. הסכנה במקום אחר: אם חלק ממשאבי התבנית מחוברים בפרוטוקול לא מאובטח, הדפדפן מסמן את העמוד כלא מאובטח. לכן עוברים על כל החיבורים לפני המעבר, ולא אחריו.
מה יקרה אם ההפניות מוגדרות חלקית?
הכלל צריך לכסות כתובת עם קידומת ובלעדיה, עם לוכסן בסוף ובלעדיו, וגם מדורים מקוננים. הגדרה חלקית נותנת כפילויות עמודים ושרשראות של שניים-שלושה מעברים: זמן התגובה גדל, ומשקל הקישורים הנכנסים אובד. אנחנו מסירים מפת כתובות עם קודי תגובה נוכחיים וסוגרים כל קבוצה בכלל נפרד ברמת השרת.
האם טפסים ופניות לשירותים חיצוניים יישברו?
נשבר מה שמקושר קשיח לפרוטוקול הישן: מטפלי טפסים, סקריפטים של אזור אישי, כתובות בקשות למערכות חיצוניות, אינטגרציות ישנות. לפני המעבר מאמתים את הכתובות האלה ומתקנים אותן למאובטחות, אחרת פניות הולכות לאיבוד. אחרי — שליחות בדיקה וניתוח יומן בקשות השרת.
תת-דומיינים, מדורים וגרסת מובייל — גם להם דרושים כללים?
הפניה בדומיין הראשי אינה משפיעה על תת-דומיינים: בלי כללים משלהם חלק מהאתר נשאר בפרוטוקול לא מאובטח. עבור מדורים נפרדים מציבים כלל ברמת הקטלוג. גרסת המובייל והכתובות הישנות נבדקות בנפרד, כדי שמכל כניסה המשתמש יגיע לכתובת אחת.
נדון במשימה ונחזור עם אומדן ותוכנית
כדי שהניתוח יהיה ענייני ולא מבוסס ניחושים, מספיקים כמה נתוני פתיחה. ככל שהמעטפת הנוכחית מתוארת מדויק יותר, כך יידרשו פחות סבבי תיאום: האומדן ותוכנית העבודה נאספים מקונפיגורציה בפועל, ולא ממילים כלליות.
מה לשלוח להתחלה:
- רשימת דומיינים ותת-דומיינים עם ציון הראשי — ממנו נבנית סכימת הפניה אחידה;
- כללי הפניה נוכחיים: קונפיגורציית שרת אינטרנט, כללים בשורש האתר, הגדרות מודולים;
- תרשים מדורים וכתובות, כולל קטלוג, טפסים ועמודים עם פרמטרים בשורת הכתובת;
- תיאור אינטגרציות: שירותים חיצוניים, קבלת תשלומים, החלפות, אזורים אישיים — כל מה שעלול ליפול בעת שינוי פרוטוקול;
- גישות לפאנל הניהול, לשרת ולרשומות הדומיין;
- נתוני תעודה: האם היא בתוקף או בתהליך חידוש ומי אחראי להנפקה.
בהמשך עובדים כך: מנתחים את הקונפיגורציה, מסמנים כתובות שנותנות כפילויות או שרשראות הפניה ארוכות, ומוסרים תוכנית לפי שלבים עם אחראים. בצוות — מהנדס שרת אינטרנט, מפתח בצד מערכת ניהול האתר ומומחה שבודק כתובות ותוצאות חיפוש לאחר היישום. לוחות זמנים נקובים לפי שלבים: הכנת כללים, העברה לפרוטוקול מאובטח, בדיקת כתובות ישנות ותוצאות חיפוש.
תארו את המשימה ושלחו את הנתונים האלה — נחזור עם אומדן ותוכנית עבודה.