קאש HTML בקלאודפלייר לוורדפרס: הכלל שלנו, ההחרגות (wp-cron, ווקומרס) ואיך מוודאים DYNAMIC

עודכן לאחרונה: 07.11.2026 · מאת עשהאל דרייר

בקצרה: Cloudflare לא שומר HTML בקאש כברירת מחדל, ולכן כל כניסה לאתר וורדפרס מגיעה לשרת. כלל אחד ב-Cache Rules פותר את זה, אבל הוא בטוח רק עם החרגות: משתמשים מחוברים, לוח ניהול, /wp-cron.php ושלוש העוגיות של ווקומרס. ב-7.11.2026 מצאנו אצלנו שתי החרגות חסרות, תיקנו, ווידאנו ש-cron והעגלה מחזירים DYNAMIC. עמוד מהקאש ענה ב-63 עד 297 מילישניות, מול 1,035 בלי קאש.

⏱ זמן ביצוע: 15 דקות · רמת קושי: בינוני · נבדק לאחרונה מול דשבורד Cloudflare: 07.11.2026

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

כי לפי התיעוד של Cloudflare, הוא שומר כברירת מחדל רק קבצים לפי סיומת: תמונות, CSS, JavaScript, גופנים. HTML ו-JSON לא נכנסים לקאש. התוצאה: התמונות מגיעות משרת קרוב, אבל העמוד עצמו נבנה בכל פעם בשרת שלכם.

אפשר לראות את זה בכותרת cf-cache-status. עמוד וורדפרס בהגדרות ברירת המחדל יחזיר בדרך כלל DYNAMIC, כלומר Cloudflare לא ניסה לשמור אותו. אחרי הכלל, אותו עמוד יחזיר MISS בפעם הראשונה ו-HIT אחר כך. רשימת הערכים המלאה: Cloudflare cache responses.

מה יכול להשתבש בקאש HTML?

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

מה מחריגים	איך מזהים	למה
משתמשים מחוברים	עוגייה שמכילה wordpress_logged_in	שלא יישמר עמוד עם סרגל ניהול
לוח הניהול	נתיב שמתחיל ב-/wp-admin	אזור אישי לגמרי
התחברות	נתיב שמכיל /wp-login	טפסים וקודי אבטחה חד-פעמיים
עמודים עם סיסמה	עוגייה wp-postpass	תוכן שמוגן בסיסמה
מגיבים	עוגייה comment_author	שם ומייל שמולאו מראש בטופס
ה-REST API	נתיב שמכיל /wp-json	נתונים דינמיים לתוספים ולעורך
תצוגה מקדימה	מחרוזת שאילתה עם preview	טיוטות
ווקומרס (אם יש חנות)	עוגיות woocommerce_items_in_cart, wp_woocommerce_session_, woocommerce_cart_hash, ונתיבי עגלה, קופה וחשבון	עגלה, מחירים ומשלוח אישיים
WP-Cron	הנתיב /wp-cron.php	קובץ שמריץ משימות מתוזמנות. מהקאש הוא לא רץ בכלל

בדקנו את זה בעצמנו: עד 7.11.2026 הכלל שלנו לא החריג את ווקומרס ולא את /wp-cron.php, כי באתר אין חנות. בקשה עם העוגייה woocommerce_items_in_cart קיבלה HIT, כלומר עמוד מהקאש. באתר עם חנות זו תקלה של ממש, ולכן הוספנו את ההחרגות גם אצלנו. הפירוט המלא בסעיף מה מצאנו ותיקנו. איך זה נראה כשזה נשבר בחנות: עגלה מתרוקנת או מחיר לא מתעדכן בווקומרס.

איך יוצרים כלל קאש HTML ב-Cloudflare?

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

1. בדשבורד של Cloudflare בחרו את הדומיין, ואז Caching > Cache Rules > Create rule.
2. תנו לכלל שם ברור, למשל WordPress HTML cache.
3. בחרו Custom filter expression, לחצו Edit expression והדביקו ביטוי כמו הדוגמה הכללית שלמטה (החליפו את הדומיין).
4. תחת Cache eligibility בחרו Eligible for cache.
5. תחת Edge TTL בחרו Ignore cache-control header and use this TTL והגדירו זמן. אנחנו בחרנו שעתיים. הוסיפו שורת Status code TTL: מ-400 ומעלה, No store.
6. תחת Browser TTL בחרו Override origin וזמן קצר. אצלנו 10 דקות, כי ניקוי קאש ב-Cloudflare לא מנקה את הדפדפנים של הגולשים.
7. לחצו Save ובדקו עם curl, כמו בסעיף הבא.

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

(http.host eq "example.co.il"
 and not starts_with(http.request.uri.path, "/wp-admin")
 and not http.request.uri.path contains "/wp-login"
 and not http.request.uri.path eq "/wp-cron.php"
 and not http.request.uri.path contains "/wp-json"
 and not http.request.uri.query contains "preview"
 and not http.cookie contains "wordpress_logged_in"
 and not http.cookie contains "wp-postpass"
 and not http.cookie contains "comment_author"
 and not http.cookie contains "woocommerce_items_in_cart"
 and not http.cookie contains "wp_woocommerce_session_"
 and not http.cookie contains "woocommerce_cart_hash")

בחנות ווקומרס הוסיפו גם החרגה לנתיבים של העגלה, הקופה והחשבון, למשל and not http.request.uri.path contains "/cart". התאימו את הנתיבים לשמות העמודים אצלכם, כי בחנות בעברית הם לא תמיד באנגלית. ההגדרות עצמן מתועדות ב-Cache Rules settings, ושמות העוגיות של ווקומרס מופיעים ב-רשימת העוגיות הרשמית של WooCommerce.

איך בודקים שהקאש באמת עובד?

מריצים curl על אותו עמוד כמה פעמים ומסתכלים על הכותרת cf-cache-status ועל הזמן עד הבייט הראשון. בבקשה הראשונה יהיה MISS, ומהשנייה HIT:

curl -s -o /dev/null -D - -w "ttfb=%{time_starttransfer}\n" https://example.co.il/ | grep -i -E "cf-cache-status|ttfb|cf-ray"

בדיקה שנייה, חשובה לא פחות: הוסיפו עוגיית התחברות מזויפת עם -H "Cookie: wordpress_logged_in_x=1". התשובה צריכה להיות DYNAMIC. אם יוצא HIT, ההחרגה לא עובדת, ומשתמשים מחוברים עלולים לקבל עמודים של אחרים.

אילו החרגות היו חסרות אצלנו, ואיך וידאנו DYNAMIC?

שתיים: /wp-cron.php והעוגיות של ווקומרס. מצאנו אותן ב-7.11.2026 בבדיקת curl שגרתית, תיקנו באותו יום, ומדדנו שוב. זו הטבלה המלאה, נמדד ב-7.11.2026 מחיבור ביתי בישראל, 3 בקשות לכל שורה:

בקשה	לפני התיקון	אחרי התיקון	מה זה אומר
/wp-cron.php	HIT, max-age=600	DYNAMIC, no-cache, max-age=0	הקובץ מגיע לשרת בכל פעם
עוגייה woocommerce_items_in_cart	HIT	DYNAMIC (3 מתוך 3)	עגלה לא תוגש מהקאש
עוגייה wp_woocommerce_session_	לא נבדק	DYNAMIC (3 מתוך 3)	כנ"ל
עוגייה woocommerce_cart_hash	לא נבדק	DYNAMIC (3 מתוך 3)	כנ"ל
עוגייה wordpress_logged_in	DYNAMIC	DYNAMIC (3 מתוך 3)	ההחרגה הישנה עדיין עובדת
גולש אנונימי, בלי עוגיות	HIT	MISS ואז HIT	הקאש לא נפגע מהתיקון

למה wp-cron מהקאש הוא בעיה? WP-Cron הוא המנגנון שמריץ בוורדפרס משימות מתוזמנות: פרסום פוסטים, גיבויים של תוספים, ניקוי. כשהקובץ מוגש מהקאש, הבקשה לא מגיעה לשרת, והמשימות לא רצות. אצלנו זה לא הזיק, כי WP-Cron כבוי ומשימה מתוזמנת בשרת מריצה אותו. באתר שסומך על WP-Cron הרגיל, זו בדיוק הדרך לקבל פוסטים שלא עולים בזמן. התסמין ופתרונו: Missed Schedule בוורדפרס, והמשימות בשרת: Cron Jobs בקלאודוויז.

אלה הפקודות שהרצנו. הריצו כל אחת 3 פעמים, כי הבקשה הראשונה תמיד MISS או DYNAMIC:

curl -s -o /dev/null -D - https://example.co.il/wp-cron.php | grep -i -E "cf-cache-status|cache-control"
curl -s -o /dev/null -D - -H "Cookie: woocommerce_items_in_cart=1" https://example.co.il/ | grep -i cf-cache-status
curl -s -o /dev/null -D - -H "Cookie: wp_woocommerce_session_test=1" https://example.co.il/ | grep -i cf-cache-status
curl -s -o /dev/null -D - -H "Cookie: woocommerce_cart_hash=test" https://example.co.il/ | grep -i cf-cache-status
curl -s -o /dev/null -D - https://example.co.il/ | grep -i cf-cache-status

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

DYNAMIC לא אומר שהעמוד איטי בכל מקרה. מתחת לקלאודפלייר, בשרת קלאודוויז, יש עוד שכבת קאש, Varnish, עם החרגות משלה. בבדיקה שלנו חלק מבקשות ה-DYNAMIC חזרו מהר, וחלק לקחו כ-0.8 עד 1.3 שניות. איך Varnish עובד: Varnish בקלאודוויז.

כמה זה שיפר אצלנו את זמן התגובה?

בערך פי 3.5 עד פי 14, תלוי לאיזה שרת קצה של Cloudflare הבקשה הגיעה. מדדנו מחיבור ביתי בישראל, 6–7 בקשות לכל מקרה, וזה החציון:

תאריך	מקרה	cf-cache-status	TTFB חציוני
6.11.2026	דף הבית, עקיפת קאש	MISS	1,035 ms
6.11.2026	דף הבית מהקאש (שרת קצה במרסיי)	HIT	297 ms
7.11.2026	דף הבית, עקיפת קאש	MISS	890 ms
7.11.2026	דף הבית מהקאש (שרת קצה בתל אביב)	HIT	63 ms
7.11.2026	מדריך, עם עוגיית התחברות	DYNAMIC	720 ms

שתי מסקנות: קודם כל, הקאש חוסך את זמן בניית העמוד בשרת שלנו בפרנקפורט, כחצי שנייה עד שנייה. שנית, את שרת הקצה לא אנחנו בוחרים. ב-6.11 הבקשות שלנו נותבו למרסיי (CF-RAY עם הקוד MRS), וב-7.11 לתל אביב (TLV). זו מדידה מנקודה אחת, והיא מראה כיוון ולא בנצ'מרק. ההסבר על פירוק TTFB לחלקים: TTFB גבוה ואיך מאבחנים. הקאש חוסך גם כשהבקשה עוברת דרך מרסיי, ולכן הוא הדבר הראשון שכדאי לעשות: למה האתר מוגש דרך אירופה ומה עוזר בחינם.

מה קורה כשמעדכנים עמוד?

הגולשים ימשיכו לראות את הגרסה הישנה עד שהקאש יפוג, אלא אם תנקו אותו. זה החיסרון המרכזי של קאש HTML בחבילה החינמית. אצלנו העדכון מגיע לגולשים תוך עד שעתיים, או מיד אחרי ניקוי ידני ב-Caching > Configuration > Purge Cache.

• Edge TTL קצר יותר (למשל 30 דקות) מקטין את זמן ההמתנה, במחיר של יותר בקשות לשרת.
• ניקוי ממוקד: ב-Purge Cache אפשר לנקות כתובת אחת במקום את כל האתר.
• ניקוי אוטומטי: לפי מאמר הידע של קלאודוויז, התוסף Breeze מנקה את הקאש של Cloudflare אוטומטית בעדכון פוסטים ועמודים, כשמשתמשים ב-Cloudflare Enterprise של קלאודוויז. המדריך: Breeze בקלאודוויז.

מתי עדיף Cloudflare Enterprise של קלאודוויז?

כשאתם לא רוצים לנהל כללים ולנקות קאש ידנית. התוסף של קלאודוויז עולה החל מ-$4.99 לחודש, עם 30 יום ניסיון (לפי עמוד המוצר, נכון ל-6.11.2026), ומשתלב עם Breeze. לאתר תוכן קטן שמתעדכן פעם ביום, הכלל החינמי מספיק. לחנות, או לאתר שמתעדכן כל שעה, החיסכון בזמן ובטעויות שווה את המחיר.

ההשוואה המלאה בין החבילות: Cloudflare Free מול Enterprise. המחירים של כל התוספים: מחירון התוספים של קלאודוויז.

אילו טעויות נפוצות עושים עם קאש HTML?

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

מתעלמים ממחרוזות שאילתה: כל כתובת עם פרמטר שונה, למשל ?utm_source=, נשמרת בנפרד ומתחילה ב-MISS. בבדיקה שלנו, אותה כתובת עם פרמטר אקראי החזירה MISS בפעם הראשונה ו-HIT מהשנייה.

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

שוכחים את wp-cron: כלל שתופס "כל מה שלא מוחרג" תופס גם את /wp-cron.php. החריגו אותו, ובדקו שהוא מחזיר DYNAMIC.

שומרים שגיאות: בלי שורת Status code TTL, עמוד שגיאה זמני של השרת יכול להישמר ולהיות מוגש שעתיים.

שאלות נפוצות

מדריכים קשורים

• איך האתר הזה מאוחסן בקלאודוויז
• הגדרת Cloudflare CDN
• Varnish בקלאודוויז
• Cloudflare Free מול Enterprise
• בעיות קאש ועגלה בווקומרס
• פוסטים שלא עולים בזמן (Missed Schedule)
• מה זה קלאודפלייר
• כל המדריכים בתחום: ביצועים ומהירות

מקורות: מדידות שלנו מ-6.11.2026 ומ-7.11.2026, כולל בדיקת ההחרגות אחרי התיקון (curl מישראל ודשבורד Cloudflare של cw-servers.co.il); Default cache behavior, Cloudflare cache responses, Cache Rules settings (Cloudflare Docs); WooCommerce cookies (WooCommerce Docs); Cloudflare Enterprise on Cloudways; How to Use Breeze Cloudflare Integration for Cache Purging (Cloudways Knowledge Base). נכתב ונבדק על ידי עשהאל דרייר · עודכן: 07.11.2026

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