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

יש רגע אחד שכל בעל עסק עם אתר מכיר.

לקוח מתקשר ואומר: "ניסיתי להיכנס לאתר שלך, משהו לא עובד."

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

והשאלה הראשונה שעולה היא לא טכנית. היא: "כמה לקוחות ראו את זה לפני שאני ראיתי?"

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

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

01 האתר נפל. מה עושים ב-10 הדקות הראשונות?

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

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

הצ'קליסט: לפני שנוגעים במשהו

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

עץ ההחלטות: איזה סוג תקלה יש לך?

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

02 טבלת האבחון: 11 התקלות הנפוצות בוורדפרס

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

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

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

03 מסך לבן ו"שגיאה קריטית באתר": איך מתקנים

מסך לבן והודעת "There has been a critical error on this website" הם שני פנים של אותה בעיה: שגיאת PHP שעוצרת את טעינת האתר. החדשות הטובות: מאז גרסה 5.2, לוורדפרס יש מנגנון מובנה שעוזר בדיוק במצב הזה.

מצב שחזור (Recovery Mode): הכלי שרוב בעלי האתרים לא מכירים

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

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

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

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

ומה אם המייל לא הגיע?

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

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

WP_DEBUG: איך רואים מה באמת נשבר

וורדפרס מאפשר להפעיל מצב דיבאג דרך הקובץ wp-config.php. לפי המדריך הרשמי לדיבאג, השילוב הנכון הוא לרשום את השגיאות לקובץ, ולא להציג אותן לגולשים:

// wp-config.php
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );      // writes to wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false ); // hide errors from visitors

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

הסיבות הנפוצות למסך לבן, לפי מה שאני פוגש

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

04 שגיאות 500, 503 וחיבור למסד נתונים

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

שגיאת 500 (Internal Server Error)

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

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

שגיאת 503, ואתר שתקוע ב"תחזוקה"

503 אומר שהשרת לא זמין כרגע, לרוב בגלל עומס או מגבלות של חבילת האחסון. סיפור אחר הוא ההודעה "Briefly unavailable for scheduled maintenance" שלא נעלמת. וורדפרס יוצר קובץ זמני בזמן עדכון, ואם העדכון נקטע, הקובץ נשאר. התיעוד הרשמי ממליץ למחוק את קובץ .maintenance מתיקיית השורש.

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

"Error establishing a database connection"

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

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

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

05 אתר וורדפרס נפרץ: מה עושים ומה לא

אתר וורדפרס נפרץ דורש ניקוי מלא, סגירת הפרצה שדרכה נכנסו, והחלפת כל הסיסמאות. ניקוי חלקי הוא הסיבה מספר אחת לפריצה חוזרת. זה המקרה היחיד בטבלה שבו אני ממליץ לא לנסות לבד.

הסימנים שהאתר נפרץ

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

מה עושים מיד

יש מדריך רשמי של וורדפרס לאתר שנפרץ, ואני מסכים עם הסדר שלו. בקיצור, ובשפה של בעל עסק:

1. תעד. מה ראית, מתי, ומה השתנה לאחרונה. זה הבסיס להבין איך נכנסו.
2. שנה סיסמאות למייל ולחשבון האחסון, ממחשב נקי. המדריך הרשמי מזכיר שפורצים גונבים לפעמים פרטי גישה ישר מהמחשב של בעל האתר.
3. פנה לחברת האחסון. לפעמים הבעיה רחבה יותר מהאתר שלך.
4. גבה את המצב הנוכחי לפני ניקוי, גם אם הוא נגוע. זה לצורך חקירה, לא לשחזור.
5. הנקה עצמה: התקנה מחדש של קבצי הליבה של וורדפרס מהמקור הרשמי, בדיקת .htaccess וקבצים כמו functions.php, החלפת כל תוסף ממקור רשמי, ומחיקת משתמשים זרים.
6. סגירת הפרצה: עדכון, החלפת סיסמאות שוב אחרי הניקוי, יצירה מחדש של מפתחות האבטחה ב-wp-config.php, וחיזוק.
7. בקשת בדיקה חוזרת מגוגל ב-Search Console, אם הוצגה אזהרה.

מה לא לעשות

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

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

06 האתר נשבר אחרי עדכון, או שאלמנטור לא נטען

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

שלושה סוגי עדכונים, שלושה סוגי סיכון

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

אלמנטור לא נטען או נתקע על מסך טעינה

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

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

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

למה אני לא מעדכן אתרי לקוחות בלחיצה על "עדכן הכול"

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

07 אתר וורדפרס איטי: מה בודקים ואיך משפרים

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

אצל יוחאי ג'קסון, אינסטלטור שאני מלווה, נתוני Search Console הראו 78% מובייל. זה לא יוצא דופן לעסק שירות מקומי. מי שמחפש אינסטלטור, חשמלאי או עורך דין, מחפש בדרך כלל מהטלפון, ולפעמים ברגע לחוץ.

מה גוגל מודד: Core Web Vitals

לפי web.dev של גוגל, יש שלושה מדדים מרכזיים, וכל אחד מהם מודד חוויה אחרת:

• LCP, טעינה: כמה זמן עד שהתוכן הגדול בדף מופיע. טוב: 2.5 שניות או פחות.
• INP, תגובה: כמה מהר הדף מגיב ללחיצה. טוב: 200 אלפיות שנייה או פחות.
• CLS, יציבות: כמה הדף "קופץ" בזמן הטעינה. טוב: 0.1 או פחות.

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

איך בודקים לבד, ב-5 דקות

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

מה בדרך כלל מאט אתר וורדפרס, ומה התיקון

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

08 טפסים שלא מגיעים, SSL ונעילה מחוץ לניהול

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

טפסי יצירת קשר לא שולחים מייל

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

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

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

SSL: "לא מאובטח" או מנעול חסר

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

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

ננעלת מחוץ לניהול

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

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

09 לתקן או לבנות מחדש?

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

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

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

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

10 כמה עולה תיקון אתר וורדפרס, ומה לשאול לפני

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

טווחים נפוצים בשוק

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

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

8 שאלות לשאול את מי שמתקן לך את האתר

התועלת: שמונה השאלות האלה מסננות מהר מאוד מי עובד מסודר ומי "ייכנס ויסתכל". מי שעובד נכון יענה על כולן בלי להתבלבל.

מתי לא לפנות אליי

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

11 איך אני עובד על תיקון, ואיך לא להגיע לזה שוב

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

מה קורה בכל שלב

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

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

סביבת בדיקה. עותק של האתר שבו אפשר לשבור ולתקן בלי שאף לקוח רואה. התועלת: האתר החי לא נהיה מעבדה.

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

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

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

מניעה: למה רוב האתרים שאני מתחזק לא מגיעים למצב חירום

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

חיזוק אבטחה אחרי תיקון

אחרי כל תיקון, ובוודאי אחרי פריצה, אני עובר על כמה דברים קבועים. אחד מהם שווה להכיר: הגדרה ב-wp-config.php שחוסמת עריכת קבצי קוד מתוך הניהול. לפי המדריך הרשמי, עורך הקוד המובנה הוא "לרוב הכלי הראשון שתוקף ישתמש בו" אם הצליח להיכנס:

define( 'DISALLOW_FILE_EDIT', true );

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

האחסון והתחזוקה שלי, בשורה אחת

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

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

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

שאלות נפוצות

מי כתב את המאמר

משה מולה, מייסד Mula Digital

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

050-824-9824 לינקדאין אימייל