אירעה שגיאה קריטית באתר שלך – מדריך חשוב

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

מה זו בעצם "שגיאה קריטית" בוורדפרס?

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

עד גרסה 5.2 הייתם מקבלים במקרה כזה "מסך לבן" ריק לגמרי (ה-White Screen of Death המפורסם). מאז וורדפרס הוסיפה שני שיפורים גדולים: הודעת השגיאה הידידותית שאתם רואים, ומייל אוטומטי למנהל האתר שמכיל את המידע החשוב ביותר — מי הרכיב שגרם לתקלה וקישור כניסה למצב שחזור. זה אומר שנקודת ההתחלה של הפתרון כמעט תמיד נמצאת בתיבת המייל שלכם.

ממה נגרמת שגיאה קריטית באתר? הסיבות הנפוצות

מהניסיון שלנו בתיקון עשרות מקרים כאלה, הגורמים מתחלקים לכמה קטגוריות ברורות:

1. התנגשות בין תוספים

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

2. תבנית עיצוב ישנה או לא מתוחזקת

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

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

3. גרסת PHP לא תואמת

גורם שהרבה בעלי אתרים לא מכירים: חברות אחסון מעדכנות מדי פעם את גרסת ה-PHP בשרת (למשל מ-7.4 ל-8.2). תוסף או תבנית ישנים שנכתבו לגרסה הישנה עלולים לקרוס בגרסה החדשה — והאתר נופל "פתאום", בלי שנגעתם בכלום. גם הכיוון ההפוך קיים: תוסף מודרני שדורש PHP 8 ומעלה ייכשל על שרת שעדיין רץ על 7.4.

4. מגבלת זיכרון (Memory Limit)

לכל אתר מוקצית כמות זיכרון בשרת. אתר עמוס בתוספים כבדים יכול לחצות את המגבלה — ואז PHP נכשל עם שגיאת "Allowed memory size exhausted". זו שגיאה קריטית לכל דבר, והפתרון הוא הגדלת המגבלה או הרזיית האתר.

5. עדכון שנקטע באמצע או קבצים פגומים

עדכון תוסף שנקטע (נפילת חיבור, שרת עמוס) משאיר אחריו קבצים חסרים או פגומים. גם העלאת קבצים ידנית ב-FTP שהשתבשה, או עריכה של קובץ functions.php עם טעות תחביר קטנה — פסיק חסר מספיק — יפילו את האתר מיידית.

6. פריצה או קוד זדוני

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

שלב ראשון: בדקו את המייל של מנהל האתר

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

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

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

יש גישה לניהול? כך מאתרים את התוסף הבעייתי

אם האתר קרוס אבל עמוד הניהול (wp-admin) עדיין נטען, או שנכנסתם דרך קישור השחזור:

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

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

אין גישה לניהול האתר? הפתרון דרך שרת האחסון

גם כשאין גישה לוורדפרס עצמה, תמיד תהיה לכם גישה לשרת האחסון — דרך ה-File Manager בממשק האחסון (cPanel, Plesk וכדומה) או דרך תוכנת FTP כמו FileZilla. משם אפשר לכבות תוספים בלי להיכנס לוורדפרס בכלל:

1. נווטו לתיקייה wp-content/plugins
2. לכיבוי תוסף ספציפי: שנו את שם התיקייה שלו (למשל מ-elementor ל-elementor-off). וורדפרס לא תמצא את התוסף ותכבה אותו אוטומטית
3. לכיבוי כל התוספים: שנו את שם התיקייה plugins כולה ל-plugins-off. אם האתר חזר לעלות — הבעיה בתוסף. החזירו את השם המקורי, וכל התוספים יופיעו בניהול במצב כבוי. משם מדליקים אחד-אחד כמו שתיארנו למעלה

אם כיבוי כל התוספים לא עזר, השלב הבא הוא התבנית: בתיקייה wp-content/themes שנו את שם תיקיית התבנית הפעילה. וורדפרס תעבור אוטומטית לתבנית ברירת מחדל (Twenty Twenty ומעלה). אם האתר עלה — הבעיה בתבנית שלכם.

איתור מדויק: מצב דיבאג ולוגים של השרת

רוצים לדעת בדיוק מה נשבר, ולא לנחש? יש שתי דרכים:

הפעלת WP_DEBUG: בקובץ wp-config.php (בתיקיית השורש של האתר) הוסיפו את השורות הבאות לפני השורה שאומרת להפסיק לערוך:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

עכשיו כל שגיאה תיכתב לקובץ wp-content/debug.log — כולל שם הקובץ המדויק ומספר השורה שגרמו לקריסה. לפי הנתיב תזהו מיד אם מדובר בתוסף (plugins/שם-התוסף) או בתבנית (themes/שם-התבנית). חשוב: אחרי שסיימתם, החזירו את WP_DEBUG ל-false — לא משאירים מצב דיבאג דולק באתר חי.

לוגים של השרת: בממשק האחסון יש בדרך כלל קובץ error_log או מסך Errors שמציג את שגיאות ה-PHP האחרונות. גם שם תמצאו את שם הקובץ האשם.

פתרונות בצד השרת

הגדלת מגבלת הזיכרון

אם בלוג מופיעה שגיאת "memory exhausted", הוסיפו ל-wp-config.php את השורה:

define( 'WP_MEMORY_LIMIT', '256M' );

בחלק מחברות האחסון צריך גם להגדיל את memory_limit בהגדרות ה-PHP של החשבון (לרוב דרך מסך "PHP Settings" או קובץ php.ini). אם אתם כבר על 256M והאתר עדיין נחנק — הבעיה היא לא המגבלה אלא תוסף רעב או אחסון חלש מדי.

החלפת גרסת PHP

בממשק האחסון (לרוב תחת "PHP Version" או "Select PHP Version") אפשר להחליף גרסת PHP בקליק. אם השגיאה הופיעה מיד אחרי שהאחסון שדרג גרסה — נסו לחזור זמנית לגרסה הקודמת. האתר יעלה, ואז תוכלו לעדכן בנחת את התוסף/התבנית הבעייתיים ולחזור לגרסה החדשה. חשוב להדגיש: חזרה לגרסת PHP ישנה היא פתרון זמני בלבד, לא מצב קבע.

שחזור מגיבוי

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

מה עושים אם האתר בנוי לגמרי על תבנית ישנה?

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

שגיאה קריטית תפגע לכם באתר — אל תשאירו אותה

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

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

איך מונעים את השגיאה הקריטית הבאה?

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

מדריך וידאו לתיקון שגיאה קריטית באתר

שאלות נפוצות על השגיאה הקריטית בוורדפרס

האם התוכן של האתר שלי נמחק?

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

לא קיבלתי מייל מוורדפרס. מה עושים?

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

השגיאה מופיעה רק בעמוד הניהול ולא באתר עצמו (או להפך). למה?

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

האתר חזר אחרי כיבוי התוסף. אפשר פשוט להשאיר אותו כבוי?

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

התקלה חוזרת שוב ושוב. מה זה אומר?

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

אירעה שגיאה קריטית באתר שלך? אנחנו כאן

עדיין מופיעה לכם התקלה ואתם רוצים חוות דעת ועזרה מקצועית? בדיוק בשביל זה אנחנו כאן. מוזמנים ליצור קשר, נאתר את מקור הבעיה ונחזיר לכם את האתר לאוויר במהירות.

בהצלחה!