בוחרים לפי הצורך
השירותים שלנו
מחליטים מתוך הבנה
אסטרטגיה וצמיחה
מוצאים את הפתרון
שגיאת שרת היא אירוע טכני עם משמעות עסקית: לקוח עלול לא לראות קטלוג, סורק עלול להאט, ודף שנראה תקין למשתמש אחד עלול להיכשל לאחרים.
מערכת AI Click · עודכן בספטמבר 2026 · כ־6 דקות קריאה
מספר הסטטוס לבדו אינו מספר את כל הסיפור. צריך להפריד בין origin, proxy ו־CDN, לבדוק אם התקלה רציפה או לסירוגין, ולהבחין בין דף שהוסר לבין שירות שאינו זמין. התהליך הבא בנוי על דגימות מוגבלות, שינוי הפיך ותיעוד שאפשר למסור לפיתוח או לאחסון.
500 מציין כשל פנימי בשרת או באפליקציה; 502 מציין בדרך כלל ש־gateway או proxy לא קיבל תשובה תקינה מהשירות שמאחוריו; 503 מציין שירות שאינו זמין זמנית, לעיתים בגלל תחזוקה או עומס; 429 מציין קצב בקשות שנדחה. אלה אינם תוויות לעיצוב דף שגיאה אלא אותות על מצב המערכת. 404 שייך למקרה אחר: משאב לא נמצא, ולא כל 4xx הוא שגיאת שרת. מתחילים מהסטטוס שנצפה, כתובת, זמן, שיטת בקשה ומזהה בקשה, לפני שמציעים שינוי.
אותו אתר יכול להחזיר 502 בקצה בגלל בעיה בין CDN ל־origin, בזמן שהאפליקציה עצמה לא ראתה את הבקשה. לכן משווים כותרות, request ID, זמן ומיקום בדיקה, בלי להסיק שמקור התקלה הוא השרת האחרון שנגיש לנו. דף מותאם אישית של CDN עשוי להיראות שונה מדף האפליקציה. מבקשים מבעל התשתית נתיב ציבורי מאושר, בודקים כותרות שאינן סודיות ומשווים דגימה קצרה ממספר נקודות. אין לעקוף בקרות אבטחה או לחבר כלי בדיקה ישירות לשרת פנימי רק כדי לקבל תשובה מהירה.
תקלה רציפה ניתנת לשחזור כמעט בכל בקשה מאותה סביבה; תקלה לסירוגין עשויה להופיע רק ב־node אחד, בחלון עומס, אחרי cache miss או בבקשות מסוימות. רושמים UTC, URL, שיטת בקשה, סטטוס, latency, כותרות מותרות ו־request ID. דוגמים מעט ובמרווחים סבירים, לא מריצים לולאת retry ולא מבצעים load test בפרודקשן. אם משתמשים מדווחים על בעיה אך הבדיקה מצליחה, מתאמים את הזמן עם לוגים ומזהים. מטרת הדגימה היא בידוד, לא יצירת עומס נוסף או סיפור שנשען על בקשה יחידה.
דף שגיאה שמחזיר 200 הוא מקרה מסוכן: עין אנושית רואה הודעה, אך לקוח וסורק מקבלים אות הצלחה. בודקים status אמיתי, title, תוכן, canonical וקישורים, ולא רק צילום מסך. אם קטגוריה תקולה, לא מחזירים דף ריק עם 200 כאילו זו קטגוריה תקינה. מתקנים את שכבת ההחזרה כך שמצב שגיאה מקבל סטטוס מתאים, תוך שמירה על דף עזר שמסביר למשתמש מה לעשות. אחרי השינוי בודקים גם cache ו־CDN, כי שכבה ישנה עלולה להמשיך להציג תגובה או סטטוס קודמים.
503 מתאים להפסקה מתוכננת וקצרה כאשר השירות באמת אינו זמין. הוא אינו מנגנון קבוע להגנה על עמודים מאינדוקס, ואינו תחליף לתיקון תקלה שנמשכת. Retry-After יכול לספק רמז לזמן ניסיון חוזר, אך אינו הבטחה למועד סריקה או חזרה לתוצאות. מודיעים למשתמש בצורה ברורה, מגבילים את חלון התחזוקה, שומרים נתיב בריאות פנימי מאובטח ומנטרים החזרה לשירות. לאחר סיום, בודקים 200 תקין, תוכן, canonical וקישורים. אם האתר נשאר ב־503, ההשפעה על סריקה ונגישות עלולה להצטבר.
מבחינת חיפוש, תגובות 5xx ו־429 עשויות להאט סריקה, וכשל שנמשך יכול להוביל בהמשך להסרת כתובות מהאינדקס. אין מספר שעות קבוע שמתאים לכל אתר או עמוד. לכן סדר העדיפויות נשען על היקף הכשל: האם כל האתר חסום, האם עמודי השירות המרכזיים נפגעו, או שמדובר בבקשות בודדות בזמן עומס. מתעדים את ההיקף ומטפלים קודם בזמינות. שינוי כותרות SEO או שליחת מפת אתר שוב ושוב אינם תחליף לכך שהשרת יחזור למסור תוכן תקין.
429 אומר שהמערכת דחתה בקשות בגלל קצב או מכסה. זה יכול להגיע מ־CDN, WAF, API או origin, ולעיתים פוגע בסורק לגיטימי ובמשתמשים יחד. בודקים מי הנפיק את התגובה, איזה כלל הופעל, האם יש Retry-After ומה קורה לקצב מתון. לא מבטלים אבטחה, לא מאפשרים הצפה כדי לבדוק אם הבעיה נעלמה, ולא מבצעים mass retry שמחמיר את העומס. התאמה נכונה עשויה להיות cache, כלל מדויק יותר או הגדלת קיבולת מאושרת, אך קודם מזהים מקור וגבולות.
אין לזהות סורק אמיתי רק לפי הטקסט User-Agent, משום שאפשר לחקות אותו. אם כלל אבטחה פוגע בסריקה, צוות התשתית צריך לאמת את מקור הבקשות בשיטה הרשמית המתאימה לפני התאמת הכלל. גם לאחר התאמה משאירים הגנה מפני עומס, ומתעדים אילו נתיבים ולקוחות נכללים בה. לאחר התיקון שומרים חלון מעקב קטן: שיעור שגיאות, זמני תגובה ותוכן שמתקבל. כך אפשר לזהות חזרה של התקלה בלי לייצר בעצמנו תנועה חריגה.
לוגים עוזרים לקשור request ID, זמן, נתיב, upstream, timeout וחריגה. קוראים רק לוגים מאושרים ומסירים טוקנים, כתובות אישיות ונתוני לקוח לפני שיתוף. מבקשים דגימה סביב timestamps במקום להעתיק קובץ שלם. אם אין מזהה משותף, מוסיפים אותו בעתיד כחלק משיפור observability, לא משנים חצי מערכת בזמן תקלה. בודקים אם 500 מקורו בקוד, במסד נתונים או בשירות צד שלישי; אם 502 קשור לתשובה לא תקינה מהשירות שמאחוריו; timeout בשער מתבטא בדרך כלל ב־504; ואם 503 מקורו בתחזוקה או capacity. כל השערה מסומנת כהשערה עד שיש שורה תומכת.
עמוד מוצר שהוסר בכוונה אינו 500, גם אם בעל האתר מעדיף שלא ייראה. בודקים אם הכתובת נועדה להתקיים, אם יש מוצר חלופי רלוונטי ואם נדרשת הפניה או 404 אמיתי. החלפת כל תקלה ב־404 מסתירה בעיית שרת; החלפת כל 404 ב־200 יוצרת דפים מטעים. במקרה היפותטי, חנות שהסירה דגם ישן מחזירה 404 עם ניווט לקטגוריה, בעוד תקלה במסד הנתונים מחזירה 500 ומתועדת לצוות. ההבחנה שומרת על משמעות הכתובות ומאפשרת טיפול עסקי שונה לכל מצב.
לאחר בידוד, משנים משתנה אחד: timeout מאושר, כלל proxy, גרסת אפליקציה או מקור cache. מתעדים ערך קודם, בעלים, חלון שינוי ותנאי חזרה. חזרה לגרסה הקודמת אינו כפתור קסם; מוודאים שהגרסה הקודמת זמינה ושאין migration חד־כיווני שתלוי בגרסה החדשה. אחרי השינוי מבצעים כמה בקשות מוגבלות לכתובות מייצגות, בודקים סטטוס ותוכן, ועוקבים בלוגים. אם אין שיפור, מחזירים ולא מוסיפים שינוי שני כדי לטשטש סיבה. בדיקה על סביבת staging עוזרת, אך אינה מחליפה אימות מבוקר בפרודקשן.
נניח אתר שירותים היפותטי שמחזיר 502 רק לדף הצעות מחיר, בעוד דף הבית תקין. מסמך העבודה מציין URL מאושר, request IDs, חלון זמן, מקור אפשרי, מגבלת דגימות ואיסור load test. מקרי קבלה: דף הצעות מחיר מחזיר 200 תקין לאחר תיקון; כשל upstream מחזיר סטטוס מתאים ולא דף 200 ריק; כתובת לא קיימת נשארת 404; תחזוקה קצרה מחזירה 503 ומסתיימת; 429 נבדק בקצב נמוך בלי עקיפת אבטחה. מתעדים לפני ואחרי, שומרים חזרה לגרסה הקודמת, ומסבירים לבעל העסק אם התקלה עלולה להאט סריקה או לפגוע זמנית בגילוי. אין מבטיחים מועד חזרה לאינדקס.
בדוגמה זו כדאי לבדוק תחילה מה שונה בדף הצעות המחיר: האם הוא פונה לשירות חיצוני, קורא נתון שאינו דרוש בדף הבית או מדלג על המטמון. הצלחת דף הבית אינה מוכיחה שכל המערכת בריאה. משווים בקשה מוצלחת לבקשה שנכשלה מאותו מסלול, ומבקשים מצוות האחסון התאמה למזהה הבקשה. אם התקלה התחילה לאחר גרסה מסוימת, מציינים את הזמן הזה כהשערה לבדיקה. קרבה בזמן היא רמז שימושי, אך אינה הוכחה שהשינוי האחרון גרם לתקלה.
לא. 404 מציין משאב שלא נמצא, ו־429 מציין הגבלת קצב. מפרשים סטטוס לפי מצב ולא לפי כותרת כללית.
לא. Retry-After הוא רמז בלבד. 503 מתאים לזמינות זמנית, לא להגנה קבועה מפני אינדוקס.
לא. retries מרובים עלולים להחמיר עומס. משתמשים בדגימות מוגבלות, מרווחים, לוגים ו־request IDs.
משווים כותרות, request ID, זמן ותגובה מול נתוני proxy ו־origin במסלול מאושר. לא עוקפים בקרות כדי לבדוק.
בחרו עמוד אחד או תהליך אחד מהמדריך, תעדו את המצב הקיים ובדקו מה דורש טיפול. אם צריך עזרה באבחון ובהחלטה מה לקדם קודם, אפשר לפנות עם הכתובת והבעיה שמצאתם.