אני זוכר את הפניות הראשונות שקיבלתי כשהתחלתי לפתח אתרי וורדפרס לפני יותר מעשור. מישהו מתקשר בפאניקה, האתר שלו מציג מסך לבן ריק, החנות שלכם בשבת שחורה לא מקבלת הזמנות, ואתם לא מצליחים להיכנס אפילו ל-wp-admin. במהלך 23 שנות עבודה בשיווק דיגיטלי וכשמתכנת שבונה את הכלים שלו בעצמו, ראיתי כל תקלה אפשרית שאתר WordPress יכול לייצר. הרוב המוחלט של התקלות האלה ניתן לפתרון אם יודעים איפה להסתכל ומה לבדוק קודם. במדריך הזה אני מרכז עבורכם את 17 התקלות הנפוצות ביותר שאני פוגש אצל לקוחות, מסביר מה גורם להן, איך לאבחן אותן בלי לעבור את שמונה השלבים הלא נכונים, ומתי באמת כדאי לכם לקרוא לבעל מקצוע במקום לחפור לבד בקוד.

תוכן העניינים 12 פרקים

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

WSOD – מסך לבן ופענוח לוג ה-PHP

WSOD זה ראשי תיבות של White Screen of Death, ובמילים פשוטות זה אומר שאתם נכנסים לאתר ורואים דף לבן ריק לחלוטין. בלי הודעת שגיאה, בלי לוגו, כלום. זו אחת התקלות הכי מתסכלות כי היא לא נותנת לכם רמז התחלתי. אבל האמת היא שאחרי שאתם יודעים איפה לחפש, WSOD הוא דווקא אחת התקלות הקלות יותר לאבחון.

הגורם השכיח ביותר הוא שגיאת PHP fatal error שמתרחשת ב-runtime – בדרך כלל אחרי עדכון של תוסף, ערכת עיצוב, או PHP עצמו. הגרסה החדשה לא תואמת לקוד שכבר רץ באתר, ו-PHP מפיל את כל התהליך ברגע שהוא נתקל בה. כדי לראות את ההודעה האמיתית, צריך להפעיל debug mode. נכנסים לקובץ wp-config.php דרך FTP או File Manager, מחפשים את השורה define('WP_DEBUG', false); ומשנים ל-true. מוסיפים גם:

  • define('WP_DEBUG_LOG', true); כדי לרשום את השגיאות לקובץ ולא להציג אותן באתר החי
  • define('WP_DEBUG_DISPLAY', false); כדי לא לחשוף את השגיאות למבקרים
  • @ini_set('display_errors', 0); שכבת הגנה נוספת מפני חשיפה

אחרי שטוענים את האתר מחדש, יופיע קובץ debug.log בתיקיית wp-content. שם תמצאו את השורה המדויקת שמפילה את האתר, עם שם הקובץ ומספר השורה. ברוב המקרים זה יוביל אתכם לתוסף ספציפי או לפונקציה שכבר לא קיימת בגרסה החדשה של PHP. למידע מעמיק יותר על אבחון WSOD ופתרון לפי גורם, עיינו בדף השירות שלנו לטיפול ב-WSOD שמכסה גם מצבים מתקדמים כמו שגיאות זיכרון או conflict בין שני תוספים שאף אחד מהם לא הגורם הישיר.

הלך לי האתר אחרי עדכון – rollback בטוח

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

הדרך הבטוחה היא לעולם לא לעדכן בלי גיבוי טרי של היום. אני ממליץ על UpdraftPlus, BackWPup או Solid Backups – שלושתם מאפשרים שחזור בלחיצה אחת. אם אין לכם גיבוי ואתם נתקעים, יש לכם עדיין כלי שנקרא WP Rollback – תוסף חינמי שמאפשר לחזור לגרסה הקודמת של כל תוסף או ערכה מתוך מאגר WordPress.org. אם התוסף שעודכן הוא בתשלום ולא נמצא במאגר הציבורי, תצטרכו להוריד את הגרסה הקודמת מאזור החשבון שלכם אצל היצרן, להעלות ידנית דרך FTP לתיקיית wp-content/plugins, ולמחוק את התיקייה הפגומה. שיטה שעובדת ב-95 אחוז מהמקרים.

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

אתר נפרץ – אבחון Malware ו-cleanup מלא

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

הסימנים שאתר שלכם נפרץ כוללים: הפניות אוטומטיות לאתרים אחרים, מודעות שלא הכנסתם, אזהרות של "האתר הזה עלול להזיק למחשב שלכם" בגוגל, ירידה חדה בתנועה האורגנית, או הופעת קבצים מוזרים בתיקיית האתר עם שמות אקראיים כמו wp-temp-x9.php. אם אתם מזהים אחד מהסימנים, פעלו מיד.

שלבי הניקוי המלא, לפי הסדר:

  • שינוי מיידי של כל הסיסמאות – hosting, FTP, מסד נתונים, ו-wp-admin
  • סריקה מלאה עם Wordfence או Sucuri Security – שתי תוספים שמזהים malware בתוך קבצי הליבה
  • השוואת קבצי ליבה לגרסה הרשמית של WordPress והחלפה של כל קובץ ששונה
  • בדיקת מסד נתונים אחר שורות מוזרות בטבלת wp_options, במיוחד ב-active_plugins ו-siteurl
  • חיפוש backdoor files בקבצי .htaccess בכל התיקיות, לא רק בשורש

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

אתר איטי – איפה מתחילים את הבדיקה

"האתר שלי איטי" זה משפט שאני שומע כמעט בכל פגישה ראשונה. הבעיה היא שאיטיות זה תסמין, לא מחלה. כדי לפתור אותו צריך לדעת איפה הצוואר הבקבוק. המדריך של web.dev ל-Core Web Vitals מציג שלוש מטריקות שגוגל בוחנת: LCP (Largest Contentful Paint), INP (Interaction to Next Paint) ו-CLS (Cumulative Layout Shift). כל אחת מסמנת בעיה אחרת.

הכלים הראשונים שכל אחד צריך להריץ הם PageSpeed Insights של גוגל ו-GTmetrix. שני הכלים יראו לכם מה הבעיה: זמן תגובת שרת ארוך (Server Response Time מעל 600ms), תמונות לא דחוסות, JavaScript חוסם רינדור, או יותר מ-2.5 שניות עד שהמשתמש רואה את האלמנט הגדול ביותר על המסך.

הגורמים הנפוצים ביותר לאיטיות, לפי הסדר שאני בודק אצל לקוחות:

  • אחסון משותף עם מאות אתרים אחרים על אותו שרת – שדרוג ל-VPS או cloud hosting פותר את זה מיד
  • חוסר caching ברמת השרת – הוספת Redis Object Cache או WP Super Cache מורידה זמני טעינה ב-60 עד 80 אחוז
  • תמונות בגדלים מקוריים שלא הוקטנו – WebP Express או ShortPixel הופכים את הכל ל-WebP אוטומטית
  • יותר מ-30 תוספים פעילים – כל תוסף מוסיף שאילתות למסד הנתונים
  • ערכת עיצוב כבדה עם 12 שאלות AJAX לכל טעינה – לפעמים שווה להחליף ערכה

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

שגיאת חיבור למסד נתונים – הפתרון בשלבים

"Error establishing a database connection" זו הודעת השגיאה הקלאסית של WordPress, וכשאתם רואים אותה, הלב נופל. הסיבה היא שהאתר לא מצליח לתקשר עם MySQL, ובלי תקשורת כזו אין WordPress. הגורמים נחלקים לשלוש קטגוריות עיקריות.

הסיבה הראשונה – פרטי גישה שגויים. נכנסים ל-wp-config.php ובודקים את ארבעת המשתנים: DB_NAME, DB_USER, DB_PASSWORD ו-DB_HOST. אם החלפתם לאחרונה את סיסמת מסד הנתונים בפאנל ניהול האחסון, אבל לא עדכנתם את wp-config, זו בדיוק הסיבה. תיקון אחד, מאתחלים את האתר, וזהו.

הסיבה השנייה – MySQL crashed או הגיע למגבלת חיבורים. בודקים את זה דרך phpMyAdmin או דרך CLI עם הפקודה mysqladmin -u root -p status. אם השרת השיב שיש מעל 150 חיבורים פתוחים, סביר שמסד הנתונים תקוע. הפתרון הוא איתחול שירות MySQL דרך WHM או SSH. בקלאוד מודרני כמו Cloudways או SiteGround זה לחיצה אחת בפאנל.

הסיבה השלישית, היותר חמורה – מסד נתונים פגום. אם wp-config תקין ו-MySQL רץ, אבל החיבור עדיין נכשל, סביר שקובצי הטבלה corrupted. WordPress מציע פתרון מובנה: מוסיפים ל-wp-config את השורה define('WP_ALLOW_REPAIR', true); ונכנסים לכתובת yourdomain.com/wp-admin/maint/repair.php. הסקריפט מריץ אופטימיזציה ותיקון על כל הטבלאות באוטומטיות. אחרי שמסיימים, חשוב להוריד את השורה שהוספתם כדי שהדף הזה לא יהיה זמין למתקיפים. למדריך מלא ויסודי, יש לנו דף שירות לתיקון שגיאת מסד נתונים שמכסה גם תרחישים מורכבים כמו טבלאות שאבדו לחלוטין.

5xx errors וההבדל ביניהם

שגיאות 5xx הן שגיאות שמקורן בשרת, לא בדפדפן שלכם. ההבחנה בין הסוגים השונים חיונית כדי לאבחן את הבעיה. שגיאה 500 – Internal Server Error – אומרת שמשהו השתבש בעיבוד הבקשה, אבל השרת לא יודע בדיוק מה. ב-WordPress, הגורם הנפוץ הוא קובץ .htaccess פגום, מגבלת זיכרון PHP שהושגה, או שגיאת PHP פנימית. הפתרון הראשון הוא תמיד לשנות זמנית את שם קובץ .htaccess ל-htaccess.old ולגשת לדף ההגדרות של ה-permalinks כדי שיגרר חדש.

שגיאה 502 – Bad Gateway – מסמנת שהשרת הקדמי, בדרך כלל Nginx או Cloudflare, לא קיבל תגובה תקינה מהשרת האחורי שמריץ PHP. ב-90 אחוז מהמקרים זה אומר ש-PHP-FPM קרס או שיש timeout. הפתרון: איתחול PHP-FPM דרך SSH, או יצירת קשר עם תמיכת האחסון.

שגיאה 503 – Service Unavailable – לרוב מסמנת תחזוקה זמנית או עומס יתר. אם זה ב-WordPress, צריך לבדוק אם יש קובץ .maintenance בשורש האתר. למידע נוסף על המצב הספציפי הזה, ראו את הסעיף הבא.

שגיאה 504 – Gateway Timeout – אומרת שהבקשה לקחה יותר זמן ממה שהשרת מוכן לחכות. לרוב זה קורה בעת ייבוא גדול, סקריפט כבד, או שאילתת SQL לא יעילה. ההגדלה של max_execution_time ב-php.ini מ-30 ל-300 שניות פותרת רוב המקרים, כאשר התרחיש הוא חד-פעמי. אם זו תופעה חוזרת, סימן שהאתר זקוק לאופטימיזציה רצינית.

אתר תקוע במצב תחזוקה

"Briefly unavailable for scheduled maintenance. Check back in a minute." זו ההודעה שמופיעה כשעדכון נכשל באמצע התהליך. WordPress יוצר אוטומטית קובץ נסתר בשם .maintenance בשורש האתר ברגע שמתחיל עדכון, ואמור למחוק אותו ברגע שהעדכון הסתיים. כשהעדכון נופל באמצע – בגלל timeout, חיבור שנותק, או כפתור Stop שלחצתם בטעות – הקובץ נשאר ונועל את האתר לכולם.

הפתרון פשוט ובן 30 שניות: נכנסים דרך FTP או File Manager של האחסון, ניגשים לשורש האתר (התיקייה שמכילה את wp-config.php), ומוחקים את הקובץ .maintenance. הוא מתחיל בנקודה אז ייתכן שצריך להפעיל "הצג קבצים נסתרים" בלקוח ה-FTP. אחרי שמחקתם, האתר חוזר לפעולה תוך שניות. אם העדכון שנכשל היה של תוסף, מומלץ להיכנס ל-wp-admin ולסיים את העדכון ידנית, או לחזור לגרסה הקודמת של אותו תוסף עד שתאתרו את הסיבה לכישלון.

תוסף שמפיל את האתר – איך מנטרלים מ-FTP

תוסף בעייתי הוא הסיבה השכיחה ביותר לתקלות וורדפרס שאני פוגש. הוא יכול ליצור WSOD, שגיאות 500, איטיות פתאומית, או אפילו לחסום אתכם מ-wp-admin. כשאתם לא מצליחים להיכנס לפאנל הניהול, צריך לנטרל את התוסף מבחוץ.

השיטה הקלאסית: התחברו ב-FTP לשרת, גשו לתיקייה wp-content/plugins, ושנו את שם התיקייה plugins ל-plugins-disabled. כל התוספים שלכם מנוטרלים בו-זמנית, וברוב המקרים האתר חוזר לפעולה מיד. עכשיו אפשר להיכנס ל-wp-admin, להחזיר את שם התיקייה ל-plugins, ולהפעיל את התוספים אחד-אחד עד שמוצאים את האשם.

שיטה מתקדמת יותר ב-WP-CLI, אם יש לכם גישת SSH:

  • wp plugin list --status=active מציג את כל התוספים הפעילים
  • wp plugin deactivate --all מנטרל את כולם בבת אחת
  • wp plugin activate plugin-name מפעיל אחד-אחד עד שמזהים את הבעייתי

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

backup קיים אבל לא עובד – שחזור ידני

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

שחזור ידני בנוי משני חלקים: הקבצים ומסד הנתונים. בחלק הראשון, מוחקים את כל הקבצים הקיימים בשורש האתר חוץ מ-wp-config.php (אם הוא תקין), ומעלים מחדש דרך FTP את גיבוי הקבצים שלכם. דאגו להעלות גם את wp-content (התוכן, התוספים והערכות), גם את wp-admin ו-wp-includes, וכל קובץ אחר בשורש כמו index.php ו-.htaccess.

בחלק השני, ניגשים ל-phpMyAdmin של האחסון, בוחרים את מסד הנתונים הקיים, מוחקים את כל הטבלאות, ומיבאים את קובץ ה-.sql של הגיבוי דרך טאב Import. אם הקובץ גדול מ-50MB, ייתכן שתצטרכו לפצל אותו עם BigDump – סקריפט PHP חינמי שמייבא קובץ SQL חתיכה-חתיכה בלי להגיע ל-timeout. אחרי שסיימתם, חשוב לבדוק שהשדה siteurl ו-home בטבלת wp_options מכילים את הכתובת הנכונה של האתר, ולא של ה-localhost או דומיין ישן.

memory limit ו-max execution time

שתי המגבלות האלה הן הסיבה למחצית מהתקלות הנקודתיות באתרי וורדפרס פעילים. memory_limit מגדיר כמה זיכרון RAM סקריפט PHP יכול לתפוס, ו-max_execution_time קובע כמה שניות הוא רשאי לרוץ עד שהשרת יקטוע אותו. ברירת המחדל באחסון משותף היא בדרך כלל 64MB זיכרון ו-30 שניות זמן ריצה, וזה מספיק לאתר רגיל אבל נופל בקלות בעת ייבוא תוכן, סנכרון תוסף כבד, או הפעלת WooCommerce עם הרבה מוצרים.

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

  • בקובץ wp-config.php: הוסיפו define('WP_MEMORY_LIMIT', '256M'); ו-define('WP_MAX_MEMORY_LIMIT', '512M');
  • בקובץ .htaccess (אם השרת מאפשר): php_value memory_limit 256M ו-php_value max_execution_time 300
  • בקובץ php.ini או user.ini בשורש האתר, אם יש לכם גישה
  • בפאנל ניהול האחסון – cPanel, Plesk, Cloudways – שם יש בדרך כלל ממשק גרפי

אם השרת לא מאפשר להגדיל מעבר למגבלה ברמת ה-hosting plan, סימן שהגיע הזמן לשדרג חבילה או לעבור לפלטפורמת cloud מודרנית. אצל רוב הספקים האיכותיים, 256MB ו-300 שניות זה הסטנדרט.

איך למנוע – תחזוקה חודשית מקצועית

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

תוכנית תחזוקה בסיסית כוללת לפחות:

  • גיבוי שבועי אוטומטי לענן (Amazon S3, Backblaze, Google Drive), עם בדיקה חודשית שהשחזור באמת עובד
  • עדכון תוספים, ערכת עיצוב וליבת WordPress בסביבת staging ראשונה, ורק אחרי בדיקה – בייצור
  • סריקת אבטחה שבועית עם Wordfence או Sucuri
  • אופטימיזציה של מסד הנתונים אחת לחודש – מחיקת revisions ישנים, spam ו-transients ישנים
  • בדיקת Core Web Vitals חודשית ב-Search Console כדי לזהות סחיפה ביצועית
  • בדיקת broken links ו-404 פעם בחודש

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

מתי לקרוא לאיש מקצוע ומתי לטפל לבד

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

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

תקראו לאיש מקצוע אם: האתר נפרץ (לא מנסים לנקות לבד malware, יותר מדי קל לדלג על backdoor חבוי), מסד הנתונים פגום בצורה לא ברורה, האתר על production עם תנועה משמעותית ואתם חוששים לעשות נזק נוסף, או אם ניסיתם דבר אחד בלי הצלחה ואתם לא רוצים לבזבז על זה עוד שעות. ב-2026, עלות שעת עבודה של מומחה וורדפרס היא 350-450 שקל. עלות אתר שירד 12 שעות בשבת היא הרבה יותר.

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

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

תיקון תקלות וורדפרס - 17 הבעיות הנפוצות