כשכתוב שיש שגיאה קריטית באתר זה, וורדפרס נתקלה בשגיאת PHP חמורה (fatal error) ועצרה את טעינת העמוד. באנגלית ההודעה היא There has been a critical error on this website, ובתרגום העברי של וורדפרס היא מופיעה כ"באתר זה אירעה שגיאה קריטית". ברוב המקרים הסיבה היא תוסף, תבנית או קוד שנוסף לאתר, ולפעמים גרסת PHP לא מתאימה או מגבלת זיכרון.
הסדר הנכון הוא קודם גיבוי, אחר כך חיפוש המייל של מצב השחזור (Recovery Mode), ואז הפעלה של לוג שגיאות כדי לדעת מה בדיוק נשבר. רק אחרי זה מנטרלים את מה שגרם לבעיה. כך אתה מתקן את הסיבה ולא מנחש.
בהמשך עברתי על כל הסיבות לפי הסדר שבו כדאי לבדוק אותן, ולכל אחת הסברתי איך מזהים אותה ואיך מתקנים.
לפני הכול: גיבוי מלא
התיעוד הרשמי של וורדפרס מבקש לוודא, לפני כל שינוי באתר, שיש לך סביבת בדיקה (staging) או גיבוי מתאים. אתר שמציג שגיאה קריטית כבר שבור, וכל שינוי בקבצים או בהגדרות יכול להוסיף בעיה על בעיה. לכן לפני שנוגעים במשהו מגבים גם את הקבצים וגם את מסד הנתונים, דרך לוח הבקרה של האחסון או דרך ספק האחסון. אם האחסון שלך כולל גיבויים אוטומטיים, כדאי לבדוק גם מתי נלקח הגיבוי התקין האחרון, כדי שתדע לאן אפשר לחזור.
כשהאתר לא עולה, מגבים ככה: מורידים ב-FTP או דרך מנהל הקבצים של האחסון את תיקיית האתר, או לפחות את wp-content ואת wp-config.php. את מסד הנתונים מייצאים מ-phpMyAdmin. בוחרים את מסד הנתונים, לוחצים על הלשונית Export, בוחרים Quick ולוחצים Go.
שלב 1: המייל של Recovery Mode
מאז גרסה 5.2 יש בוורדפרס מנגנון מובנה בשם Recovery Mode. כשוורדפרס מזהה שגיאה קריטית בטעינת עמוד רגילה, היא מציגה למבקרים את הודעת השגיאה, ובמקביל שולחת מייל לכתובת המייל של מנהל האתר, עם פרטי השגיאה וקישור כניסה מיוחד.
אז השלב הראשון הוא לחפש בתיבת המייל של מנהל האתר מייל מוורדפרס על בעיה טכנית באתר, כולל בתיקיית הספאם. לפי התיעוד, אם השגיאה קורית לפני שתוסף המיילים של האתר נטען, המייל נשלח ישירות מהשרת, ועלול להגיע לספאם או לא להגיע בכלל.
כשמוצאים את המייל, לוחצים על הקישור ומתחברים. במצב הזה התוסף או התבנית התקולים מושהים רק בשבילך, והמבקרים באתר לא מושפעים. בלוח הבקרה תופיע הודעה שמצביעה על הרכיב שנכשל. נכנסים ל-Plugins או ל-Appearance > Themes ומשביתים אותו. אחרי התיקון לוחצים על Exit Recovery Mode בסרגל העליון ובודקים שהאתר עובד.
לפעמים אין הודעה בכלל, רק מסך לבן. התיעוד של וורדפרס מסביר שגם שגיאות PHP וגם שגיאות של מסד הנתונים יכולות להופיע כמסך ריק, ולכן גם במקרה כזה ממשיכים לשלבים הבאים.
והשבתה של תוסף היא רק פתרון זמני שמחזיר את האתר לעבודה. עדיין צריך להבין למה התוסף נכשל, ובשביל זה ממשיכים לשלב הבא.
שלב 2: להפעיל לוג שגיאות עם WP_DEBUG
אם המייל לא הגיע, או שאתה רוצה לראות את השגיאה המדויקת, מפעילים את מצב הדיבאג של וורדפרס.
פותחים את הקובץ wp-config.php בתיקייה הראשית של האתר (דרך FTP או מנהל הקבצים של האחסון), ומוסיפים את השורות האלה לפני השורה /* That's all, stop editing! Happy blogging. */:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );אם השורה define( 'WP_DEBUG', false ); כבר קיימת בקובץ, משנים אותה ולא מוסיפים שנייה. ההגדרה WP_DEBUG_DISPLAY על false מונעת מהשגיאות להופיע למבקרים. אחרי שטוענים שוב את העמוד השבור, השגיאות נשמרות בקובץ wp-content/debug.log.
בלוג מחפשים את השורה שמתחילה ב-PHP Fatal error. בדרך כלל מופיע בה נתיב של קובץ. אם הנתיב עובר דרך wp-content/plugins/ ושם של תיקייה, הבעיה בתוסף. אם הוא עובר דרך wp-content/themes/, הבעיה בתבנית.
התיעוד של וורדפרס לא ממליץ להשאיר את כלי הדיבאג פעילים באתר חי, ו-Site Health מתריע שקובץ הלוג עלול להיות נגיש לכל אחד. לכן כשמסיימים, מחזירים את WP_DEBUG ל-false ומוחקים את debug.log.
אם לספק האחסון שלך יש לוג שגיאות של השרת בלוח הבקרה, כדאי להסתכל גם בו, כי לפעמים השגיאה נרשמת שם גם כשהלוג של וורדפרס ריק. אם אתה לא מוצא אותו, אפשר לבקש אותו מחברת האחסון. כשפונים לתמיכה, כדאי לתת להם את השעה המדויקת שבה ניסית לטעון את העמוד ואת הכתובת שנשברה, כדי שיהיה להם קל למצוא את השורה הנכונה.
שלב 3: תוסף שגורם לשגיאה
לפי התיעוד של וורדפרס, התנגשות בין תוספים היא אחת הסיבות הנפוצות לשגיאה קריטית.
החשד עובר לתוסף כשהלוג מצביע על קובץ בתוך wp-content/plugins/, או כשהשגיאה התחילה מיד אחרי התקנה או עדכון של תוסף.
גם בלי גישה ללוח הבקרה אפשר להשבית אותו. נכנסים ב-FTP או במנהל הקבצים לתיקייה wp-content/plugins/ ומשנים את שם התיקייה של התוסף החשוד. לדוגמה, hello-dolly הופך ל-hello-dolly-1. וורדפרס לא מוצאת את התוסף ומשביתה אותו. אם אין לך מושג איזה תוסף אשם, משנים את שם התיקייה כולה מ-plugins ל-plugins_old, וכל התוספים מושבתים בבת אחת. אם האתר חזר, הבעיה בתוסף. אז נכנסים לאזור הניהול ומחזירים לתיקייה את השם plugins, והתוספים יישארו מושבתים. עכשיו מפעילים אותם אחד אחד מהמסך Plugins, עד שהאתר נשבר שוב. התוסף האחרון שהפעלת הוא החשוד.
במיוחד כדאי לשים לב אם התוסף החשוד הגיע ממקור לא רשמי. אלמנטור פרו חינם וקבצים דומים שהורדת בחינם הם דרך נפוצה להכניס נוזקה לאתר, וקוד פגום כזה בהחלט יכול לגרום לשגיאה קריטית. ואם אתה כל הזמן נתקל בתוספים מוכנים שמתנגשים זה בזה, לפעמים הפתרון הנכון הוא לא עוד תוסף מהמדף אלא פיתוח תוספים לוורדפרס בהתאמה אישית, שעושה רק את מה שאתה צריך.
שלב 4: התבנית או קוד שנוסף ל-functions.php
כאן הסימן הוא לוג שמצביע על קובץ בתוך wp-content/themes/, בדרך כלל functions.php, או שגיאה שהתחילה אחרי עדכון תבנית או הדבקה של קטע קוד.
נתקלתי בזה פעם: שגיאה קטלנית באתר נבעה מכך שמפתחות של שדה חוזר היו טקסט ולא מספרים.
אם הדבקת קוד, מסירים אותו או מתקנים את השורה שהלוג מציין. אם החשד הוא על התבנית עצמה, משנים ב-FTP את שם התיקייה של התבנית הפעילה בתוך wp-content/themes/. אם יש לך גישה ללוח הבקרה, אפשר גם להפעיל זמנית אחת מתבניות ברירת המחדל של וורדפרס ולבדוק אם השגיאה נעלמת. אם ערכת קבצים בתבנית, מחזירים אותם מהגיבוי. אם התבנית עודכנה לאחרונה, בודקים אם יש לה עדכון נוסף. שינויים שאתה רוצה לשמור עוברים לתבנית בת (child theme), כי לפי התיעוד של וורדפרס עדכון של התבנית דורס שינויים שנעשו בקבצים שלה.
ואם בסוף אתה מחליט להחליף את התבנית לצמיתות, יש תהליך מסודר להמרת תבנית וורדפרס באתר חי בלי לשבור עמודים, תפריטים וקידום.
שלב 5: גרסת PHP לא מתאימה
לפי התיעוד, גרסת PHP שלא תואמת לאתר היא עוד סיבה נפוצה. זה יכול לקרות, למשל, כשגרסת ה-PHP בשרת שודרגה ותוסף ישן לא תומך בה.
אם יש לך גישה ללוח הבקרה, את הגרסה רואים ב-Tools > Site Health > Info, בחלק Server. בלשונית Status של אותו מסך, וורדפרס מתריעה כשהאתר רץ על גרסת PHP ישנה. בלי גישה, בודקים בלוח הבקרה של האחסון. אם השגיאה התחילה ביום שבו האחסון שינה גרסה, זה החשוד המרכזי.
נכון לספטמבר 2026, עמוד הדרישות של וורדפרס ממליץ על PHP 8.3 ומעלה. אם התוסף או התבנית לא תומכים בגרסה החדשה, עדיף לעדכן או להחליף אותם. חזרה לגרסה ישנה היא פתרון זמני בלבד, כי לפי php.net גרסה 8.2 מקבלת עדכוני אבטחה רק עד סוף 2026.
בזמן שאתה במסך Site Health, שווה להציץ גם בלשונית Status. וורדפרס מרכזת שם בעיות קריטיות, כמו תוספים שמחכים לעדכון או אתר שמוגדר להציג שגיאות למבקרים, ולפעמים הרמז לתקלה כבר מחכה שם.
שלב 6: חריגה ממגבלת הזיכרון
הבעיה הזו מזוהה בקלות, כי בלוג מופיעה שגיאה שמתחילה ב-Allowed memory size of ומסתיימת ב-exhausted.
כדי להגדיל את המגבלה, מוסיפים ל-wp-config.php, לפני השורה /* That's all, stop editing! */:
define( 'WP_MEMORY_LIMIT', '256M' );באחסון משותף ייתכן שהשרת לא מאפשר להגדיל את הזיכרון בעצמך, ואז פונים לספק האחסון.
שלב 7: קבצי וורדפרס פגומים
התיעוד של וורדפרס מונה גם קבצי ליבה פגומים בין הסיבות לשגיאה קריטית. במקרה כזה הלוג מצביע על קובץ בתוך wp-admin או wp-includes, ולא על תוסף או תבנית.
כאן נכנס הגיבוי שעשית. שחזור הקבצים מגיבוי תקין, או פנייה לספק האחסון, בטוחים יותר מניסיון להחליף קבצי ליבה ידנית.
תקלות וורדפרס אחרות: שגיאת שרת, מסד נתונים ומצב תחזוקה
לא כל תיקון אתר וורדפרס מתחיל בהודעה על שגיאה קריטית. יש עוד שלוש הודעות שאתה עלול לראות במקומה:
| ההודעה | הסיבה | מה עושים |
|---|---|---|
| 500 Internal Server Error | התיעוד של וורדפרס מציין שהסיבה הסבירה היא קובץ .htaccess פגום. | בתיקייה הראשית של האתר משנים את שמו ל-.htaccess_old ובודקים. אם זה פתר, נכנסים ל-Settings > Permalinks ולוחצים Save Changes כדי ליצור קובץ חדש. |
| Error Establishing a Database Connection | יש בעיה בחיבור למסד הנתונים. | בודקים ב-wp-config.php את שם מסד הנתונים, שם המשתמש, הסיסמה והשרת, ומוודאים מול האחסון ששרת מסד הנתונים פעיל. |
| Briefly unavailable for scheduled maintenance | בזמן עדכון וורדפרס יוצרת קובץ .maintenance בתיקייה הראשית. | אם העדכון נתקע, מוחקים את הקובץ ב-FTP ומריצים את העדכון שוב. |
אם האתר לא עולה בכלל, גם לא עם הודעת שגיאה, כדאי לבדוק קודם שזו לא בעיה כללית יותר של דומיין או DNS, ולא קובץ שבור באתר עצמו. הרחבתי על זה במדריך לא ניתן לגשת לאתר הזה. ואם האתר רץ מאחורי Cloudflare, שווה לבדוק גם שם לפני שממשיכים לחפש בקוד, כמו שהסברתי במדריך על Cloudflare תקלה.
ועוד הרגל שחוסך זמן בכל תיקון: לרשום לעצמך כל שינוי שעשית, באיזה קובץ ובאיזה סדר. כך, אם שינוי מסוים לא עזר, אתה יודע בדיוק מה להחזיר, והאתר לא נשאר עם שלושה ניסיונות תיקון שאף אחד כבר לא זוכר.
מתי תיקון עצמי של שגיאה קריטית כבר לא מספיק
כדאי לעצור כשאחד מאלה קורה:
- אין לך גיבוי, ואתה לא יודע איך לעשות אחד.
- הלוג ריק, או שהשגיאה בו לא מצביעה על תוסף או תבנית ברורים.
- הלוג מצביע על שגיאה בקוד שמישהו כתב במיוחד לאתר, ואתה לא מכיר PHP.
- יש סימנים לפריצה: קבצים שלא הכרת, משתמשי מנהל חדשים או הפניות לאתרים זרים.
- השגיאה היא במסד הנתונים עצמו, וצריך לתקן טבלאות.
- השבתת את כל התוספים והחלפת תבנית, ועדיין יש שגיאה קריטית באתר זה.
- זו חנות WooCommerce או אתר שמקבל הזמנות, וכל דקה של השבתה עולה לך כסף.
- הבעיה התחילה אחרי שדרוג PHP, והתוסף שנשבר קריטי לאתר.
ויש סיבה לא לדחות את הטיפול. מעבר ללקוחות שנתקלים באתר שבור, יש גם היבט של גוגל. כשוורדפרס מציגה את מסך השגיאה הקריטית, היא שולחת לדפדפן קוד סטטוס HTTP, בדרך כלל 500, שמסמן שגיאת שרת. לפי התיעוד של Google Search Central, שגיאות 5xx גורמות לסורקים של גוגל להאט את הסריקה של האתר, ועמודים שממשיכים להחזיר שגיאת שרת לאורך זמן מוסרים מהאינדקס.
לכן, גם אם אין לך זמן לתקן את שורש הבעיה עכשיו, כדאי להחזיר את האתר לעבודה כמה שיותר מהר, למשל בהשבתת התוסף שגרם לשגיאה, ולטפל בסיבה עצמה אחר כך. אחרי שהאתר חזר, כדאי לעקוב ב-Search Console שהעמודים ממשיכים להיסרק כרגיל. אם אתה רוצה להבין לעומק למה עמודים נעלמים מגוגל, כתבתי על זה במדריך למה האתר שלי לא מופיע בגוגל.
את התיעוד המלא אפשר לקרוא במדריך Recovery Mode של וורדפרס ובמדריך הדיבאג הרשמי.
שאלות נפוצות
מאיפה מתחילים תיקון אתר וורדפרס שלא עולה?
מגיבוי מלא של הקבצים ומסד הנתונים, ואז מבדיקת המייל של מנהל האתר. וורדפרס שולחת אליו פרטים על שגיאה קריטית וקישור ל-Recovery Mode.
מה המשמעות של ההודעה "יש שגיאה קריטית באתר זה"?
וורדפרס נתקלה בשגיאת PHP חמורה ועצרה את טעינת העמוד. בדרך כלל הסיבה היא תוסף, תבנית, קוד שנוסף לאתר, גרסת PHP לא מתאימה או חריגה ממגבלת הזיכרון.
לא קיבלתי את המייל של Recovery Mode. מה עושים?
בודקים בספאם, ובודקים שזו תיבת המייל שמוגדרת כמייל של מנהל האתר. אם הוא לא הגיע, מפעילים את WP_DEBUG_LOG כדי לראות את השגיאה, ומשביתים את התוסף החשוד דרך שינוי שם התיקייה שלו ב-FTP.
איפה נמצא קובץ debug.log?
כשמפעילים את WP_DEBUG_LOG, וורדפרס שומרת את הלוג בקובץ debug.log בתיקיית התוכן, בדרך כלל wp-content/debug.log.
האם אני מאבד תוכן כשמשנים את שם תיקיית התוספים?
שינוי השם משבית את התוספים ולא מוחק אותם, ולפי התיעוד של וורדפרס ההגדרות שלהם נשמרות. כשמחזירים את השם המקורי, התוספים חוזרים לרשימה, מושבתים, ומפעילים אותם מחדש. שחזור מגיבוי ישן, לעומת זאת, יכול לדרוס תוכן שנוסף אחריו, ולכן מגבים לפני כל צעד.
האם אפשר להשאיר את WP_DEBUG פעיל?
לא באתר חי. לפי התיעוד של וורדפרס, כלי הדיבאג מיועדים לסביבות בדיקה, ו-Site Health מתריע שקובץ הלוג עלול להיות נגיש לציבור. בסיום מחזירים ל-false ומוחקים את הקובץ.
מה עושים עם 500 Internal Server Error?
מתחילים בשינוי שם של קובץ .htaccess. אם זה פתר, יוצרים קובץ חדש על ידי שמירה של Settings > Permalinks. אם לא, בודקים תוספים ואת לוג השרת.
איך מגדילים את מגבלת הזיכרון?
מוסיפים ל-wp-config.php את השורה define( 'WP_MEMORY_LIMIT', '256M' ); לפני השורה That's all, stop editing. באחסון משותף ייתכן שצריך לבקש את זה מספק האחסון.
אם עברת על השלבים והאתר עדיין מציג שגיאה, אפשר לפנות אליי, ואני אאתר את הסיבה ואחזיר את האתר לעבודה.