המדריך המלא לפתרון בעיות נפוצות בווקומרס 2027

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

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

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

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

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

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

סטטוסים של הזמנה ומה כל אחד באמת אומר

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

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

סינון, מיון וחיפוש הזמנות

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

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

החזרים כספיים וביטולים

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

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

איך מאבחנים תקלה בווקומרס בלי לנחש?

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

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

למה העגלה או הצ׳ק-אאוט לא עובדים?

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

סיבות סבירות: קאש שמגיש את העגלה או הצ׳ק-אאוט מהזיכרון (הדפים האלה חייבים להישאר דינמיים); כלי אופטימיזציה שמאחד או דוחה קובצי JavaScript ושובר את הסקריפט של ווקומרס; Rocket Loader או הגנה מבוטים ב-Cloudflare שחוסמים את wc-ajax; תוסף אבטחה שחוסם admin-ajax; התנגשות בין הצ׳ק-אאוט מבוסס הבלוקים לבין תוסף שדות, סליקה או משלוח שמכיר רק את השורטקוד הישן; דף שמוגדר כ"צ׳ק-אאוט" בהגדרות אבל כבר לא מכיל את הבלוק.

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

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

מה עושים כשהסליקה מחזירה שגיאה?

שגיאות מחברת הסליקה

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

סיבות סבירות: מפתחות API או מספר מסוף שגויים (קלאסי אחרי מעבר לספק סליקה חדש, או שכפול לסביבת בדיקה עם פרטי הייצור); מצב בדיקה (sandbox) שנשאר דלוק; כתובת חזרה (callback) שאצל הספק שונה מזו שבאתר, כולל https ו-www; כרטיסים זרים, Bit או Apple Pay שלא הופעלו במסוף; הזמנה בסכום אפס או מטבע שגוי; אימות חזק (3D Secure) שנכשל אצל הלקוח, לא אצלכם.

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

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

הזמנות תקועות ב"ממתין לתשלום"

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

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

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

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

למה מיילים מהחנות לא נשלחים או נופלים לספאם?

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

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

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

למה הקופון לא עובד?

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

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

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

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

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

למה המלאי באתר לא תואם למחסן?

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

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

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

מתי קוראים למפתח: תיקון אלפי מוצרים אחרי סנכרון שהשתבש, או סנכרון דו-כיווני מול Priority, SAP Business One או מערכת קופה.

משלוחים ומע״מ: ההגדרות שמפילות צ׳ק-אאוט

"אין אפשרויות משלוח לכתובת שלך"

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

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

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

מע״מ בישראל: מחירים כוללים, חשבוניות ואילת

חנות ישראלית לצרכנים מציגה מחירים כולל מע״מ. בווקומרס: מפעילים מיסים בהגדרות הכלליות, בלשונית מיסים בוחרים "המחירים שהוזנו כוללים מס" ותצוגה "כולל" בחנות ובעגלה, ומגדירים תעריף סטנדרטי לישראל בשיעור המע״מ הנוכחי (18% מאז ינואר 2025; בודקים ברשות המסים לפני שמשנים). כשמשנים שיעור, המחירים באתר נשארים ורק חלק המס בחשבונית משתנה.

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

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

דפי מוצר: שגיאת 404 ותמונות

דף מוצר מחזיר 404 אחרי שינוי

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

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

התיקון: הגדרות > קישורים קבועים > שמור (בלי לשנות כלום) מרענן את הכללים ופותר את רוב המקרים. אחר כך בודקים סטטוס וחשיפה של המוצר, מנקים קאש, ואם ה-slug השתנה, מוסיפים הפניית 301 מהכתובת הישנה, כי גוגל, המודעות והפיד עוד מכירים אותה. מוצר שנמחק לתמיד עדיף להפנות לקטגוריה שלו ולא לדף הבית.

מתי קוראים למפתח: 404 על כל המוצרים אחרי מעבר שרת (כללי שרת), או רק בכתובות עם עברית (קידוד).

תמונות מוצר מטושטשות, חתוכות או כבדות

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

סיבות סבירות: תמונות מקור קטנות מהמידה שהתבנית מציגה; יחס חיתוך 1:1 למוצרים מלבניים; שינוי הגדרות תמונה בלי יצירה מחדש של הגדלים; קובצי מצלמה מקוריים שהועלו כמו שהם.

התיקון: בתבניות קלאסיות ההגדרה יושבת בהתאמה אישית > ווקומרס > תמונות מוצר (רוחב ויחס חיתוך); אחרי שינוי, ווקומרס מייצר גדלים חדשים ברקע, ואפשר להאיץ עם תוסף Regenerate Thumbnails או עם הפקודה wp media regenerate. סטנדרט לחנות: תמונות מקור ברוחב אחיד, WebP או AVIF, כיווץ אוטומטי בהעלאה, ותיאור חלופי (alt) לכל תמונה, שמשרת גם נגישות וגם חיפוש.

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

מסך לבן או "אירעה שגיאה קריטית באתר": מה עושים עכשיו?

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

סיבות סבירות: תוסף שלא תואם לגרסת PHP החדשה (8.2 ומעלה) או לוורדפרס; שני תוספים שמגדירים אותה פונקציה; קובץ functions.php שנשבר; זיכרון PHP שנגמר; עדכון שנקטע באמצע.

סדר החילוץ, בלי פאניקה

איך מעדכנים חנות חיה בלי לשבור אותה

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

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

למה החנות או הניהול איטיים?

ממשק הניהול זוחל ו-Action Scheduler עמוס

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

סיבות סבירות: Action Scheduler הוא התור של ווקומרס למשימות רקע (מיילים, סנכרונים, ניתוחים, חידושי מנויים, יצירת תמונות). הוא רץ על WP-Cron, שרץ רק כשמישהו גולש באתר, ועם קאש חזק כמעט אף אחד לא מעיר אותו. התור מתמלא, כל בקשה בניהול מנסה לרוקן קצת ממנו, והכל זוחל. מוסיפים לזה בסיס נתונים נפוח ותוספים שטוענים סקריפטים בכל מסך ניהול.

התיקון: להעביר את הקרון לשרת: DISABLE_WP_CRON ב-wp-config ומשימת cron אמיתית כל דקה שקוראת ל-wp-cron.php. לפתוח ווקומרס > סטטוס > פעולות מתוזמנות ולראות מה ממתין ומה נכשל: אלפי פעולות מתוסף אחד הן אצבע מאשימה, ולרוב מדובר בסנכרון שנשבר לפני שבועיים. לנקות סשנים ו-transients בסטטוס > כלים, ולמחוק תוספים שלא בשימוש במקום להשאיר אותם כבויים.

HPOS, קאש אובייקטים ואחסון שמתאים לחנות

שלושה דברים שמשנים חנות מבפנים. HPOS, שמעביר את ההזמנות לטבלאות ייעודיות (ווקומרס > הגדרות > מתקדם > תכונות; תוספים ישנים חייבים להצהיר על תאימות, והתיעוד של HPOS מסביר את מצב התאימות). קאש אובייקטים (Redis או Memcached) שמוריד את מספר השאילתות בכל טעינה, וזה מה שמרגישים בעגלה ובניהול, שם קאש דפים לא עוזר. ואחסון עם מספיק PHP workers וגרסת PHP נתמכת; חנות עם מאה תוספים על אחסון משותף תישאר איטית גם אחרי כל הכוונונים.

מהירות בצד הלקוח היא נושא נפרד ונמדדת במדדי הליבה של גוגל (LCP, INP ו-CLS), לא ביומן השרת. שם הפתרונות הם תמונות קלות, פחות סקריפטים של צד שלישי, וגופנים שנטענים מקומית. המדדים והספים מתפרסמים אצל גוגל, ואפשר לבדוק את הכתובת שלכם באבחון דיגיטלי חינם ולראות איפה החנות עומדת.

מתי קוראים למפתח: להפעלת HPOS בחנות עם תוספים ותיקים, להתקנת Redis, ולניתוח שאילתות איטיות.

אבטחה, גיבויים ופרטיות: מה חובה בכל חנות

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

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

מתי מפסיקים לנסות וקוראים למפתח?

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

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

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

מה עושים עכשיו

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

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