עודכן לאחרונה: · מאת עשהאל דרייר
בקצרה: בקלאודוויז (Cloudways) יש שתי דרכים לשלוט באיך השרת מגיב לבקשות: Web Rules (נכון לנובמבר 2026 בבטא ציבורית, Public Preview), ממשק בפאנל שמוסיף הפניות 301/302, שכתובים פנימיים וכותרות HTTP בלי לגעת בקבצים, וקובץ .htaccess הקלאסי, שעובד רק ב-Hybrid Stack. קובץ robots.txt הוא קובץ טקסט רגיל שמעלים לתיקייה public_html של האתר ב-SFTP או במנהל הקבצים, או שמנהלים מתוך וורדפרס. באותו אזור של הגדרות האפליקציה משנים גם Web Root, מפעילים CORS וחוסמים זמנית את הגישה לאתר.
⏱ זמן ביצוע: 5–15 דקות · רמת קושי: קל (Web Rules, robots.txt) עד בינוני (htaccess) · נבדק לאחרונה מול התיעוד הרשמי: 06.11.2026
מה ההבדל בין Web Rules, htaccess ו-robots.txt?
הכלים האלה נשמעים דומים, אבל הם עושים דברים שונים לגמרי. כדאי להבין את ההבדל לפני שמתחילים.
Web Rules הם חוקים שהשרת מפעיל על כל בקשה שמגיעה לאתר. למשל: "כל מי שנכנס ל-www, העבר אותו לכתובת בלי www", או "הוסף לכל תשובה כותרת אבטחה". קלאודוויז בנתה את הממשק הזה יחד עם ה-Lightning Stack, שבו אין Apache ולכן אין htaccess, אבל הוא עובד גם ב-Hybrid Stack.
שימו לב: Web Rules נמצא בבטא ציבורית (Public Preview). בפאנל מופיע תג Public Preview צמוד לכותרת. לפי התיעוד של קלאודוויז (עודכן 05.11.2026), גרסאות Public Preview הן שחרורים ראשוניים לבדיקה רחבה יותר: ה-SLA עשוי להימדד אבל לא מגובה בזיכוי כספי, והפיצ'ר כפוף לתהליך הפרישה הרגיל. לכן בדקו כל חוק מיד אחרי שהוספתם אותו, ושמרו עותק של הכללים החשובים.
.htaccess הוא קובץ הגדרות של Apache שיושב בתיקיית האתר. הוא יכול לעשות כמעט הכול: הפניות, חסימות IP, הגנת סיסמה, חסימת בוטים. הוא נקרא רק כשהאפליקציה רצה ב-Hybrid Stack (Nginx ו-Apache). שימו לב: במסך הקמת השרת העדכני Lightning מסומן Recommended ונבחר מראש לאפליקציית וורדפרס חדשה, כך שבאפליקציה חדשה ייתכן שאין htaccess בכלל.
robots.txt הוא לא חוק של השרת בכלל. זו בקשה מנומסת למנועי חיפוש: אילו חלקים באתר לסרוק ואילו לא. בוטים הגונים כמו Googlebot מכבדים אותו, בוטים זדוניים מתעלמים. לכן robots.txt הוא כלי SEO, לא כלי אבטחה.
| רוצים ל… | הכלי המתאים |
|---|---|
| להפנות עמוד ישן לחדש (301) | Web Rules, או htaccess ב-Hybrid |
| לאחד www ובלי www | Web Rules |
| להוסיף כותרות אבטחה (HSTS, X-Frame-Options) | Web Rules (Header Rules) |
| לחסום כתובת IP או בוט מסוים | htaccess (Hybrid), או חומת האש של השרת |
| להגן על אתר בפיתוח בסיסמה | htaccess, או חסימת גישה זמנית לאפליקציה |
| למנוע מגוגל לסרוק תיקייה | robots.txt |
| להוציא עמוד מתוצאות החיפוש | תגית noindex (לא robots.txt) |
לפני שמתחילים
- בדקו באיזה Stack האפליקציה רצה: Application Settings ואז הלשונית WebStack (בתיעוד: Stack setting). ההסבר המלא נמצא במדריך להגדרות השרת.
- לעריכת htaccess ו-robots.txt צריך גישה לקבצים: מנהל הקבצים, SFTP או SSH.
- לפני שינוי בהפניות של אתר חי, שמרו עותק של htaccess הקיים. הפניה שגויה יכולה להוריד את האתר או לייצר לולאת הפניות.
Web Rules (בטא): הפניות, שכתובים וכותרות בלי קבצים
- בתפריט הצד של הפאנל לחצו My Applications.
- בחרו את האפליקציה.
- בתפריט של האפליקציה לחצו Web Rules.
- בחרו לשונית: Header Rules (כותרות) או Rewrite Rules (הפניות ושכתובים). כברירת מחדל נפתחת Header Rules.

המגבלות, ומתי להישאר עם htaccess
| סוג חוק | מקסימום לאפליקציה | תנאים |
|---|---|---|
| Header Rules | 10 | – |
| Redirect / Rewrite Rules | 25 | תנאי אחד לכל חוק |
ההמלצה של קלאודוויז: עד 25 הפניות ועד 10 כותרות, Lightning Stack עם Web Rules. מעבר לזה, או כשצריך חוקים עם כמה תנאים, Hybrid Stack עם htaccess. אתר שעבר מבנה כתובות ויש לו מאות הפניות ישנות צריך להישאר ב-Hybrid, או להעביר את ההפניות לתוסף הפניות בוורדפרס.
יצירת הפניה (301, 302 או Rewrite)
- בלשונית Rewrite Rules לחצו Add Rewrite Rule.
- ב-Action בחרו: Permanent Redirect (301) לשינוי קבוע, Temporary Redirect (302) לשינוי זמני, או Rewrite לשכתוב פנימי שבו הכתובת בדפדפן לא משתנה.
- קבעו אם לשמור את ה-Query String המקורי (למשל
?utm_source=facebook). בקמפיינים כמעט תמיד כדאי לשמור, כדי לא לאבד נתוני ייחוס. - ב-Source הזינו את הכתובת או התבנית שמפעילה את החוק, למשל
/old-page. - ב-Destination הזינו את היעד: נתיב כמו
/new-pageאו כתובת מלאה. - אם צריך, הוסיפו תנאי (Attach Condition), ואז לחצו Add Rule בפינה העליונה.
301 אומר לגוגל שהעמוד עבר לצמיתות, והערך שלו בחיפוש עובר ליעד. 302 אומר שזה זמני, וגוגל ממשיך לאנדקס את הכתובת המקורית. אם אתם לא בטוחים, ובשינוי מבנה אתר, השתמשו ב-301.
תנאים: לפי דומיין, מדינה או מכשיר
לכל חוק אפשר לצרף תנאי אחד. סוגי התנאים הנתמכים: URI (נתיב), QUERY_ARG (פרמטר בכתובת, בלי סימן השאלה), HOST (הדומיין), COUNTRY CODE (קוד מדינה לפי MaxMind GeoIP, למשל IL) ו-DEVICE CODE (desktop, mobile או tablet). האופרטורים: שווה (=), שונה (!=), התאמת Regex (~) ואי-התאמת Regex (!~).
דוגמה ישראלית: אתר דו-לשוני יכול להפנות גולשים מחוץ לישראל לגרסה האנגלית עם תנאי COUNTRY CODE != IL ופעולת 302. שימו לב לשני דברים: גוגל סורקת בעיקר מכתובות IP מחוץ לישראל, ולכן הפניה כזו עלולה למנוע ממנה לראות את הגרסה העברית. ואם בכל זאת מפנים לפי מדינה, משתמשים ב-302 ולא ב-301.
דוגמה: איחוד www לכתובת בלי www
- Add Rewrite Rule.
- Action: Permanent Redirect (301).
- Source:
/* - Destination:
https://domain.co.il/ - Attach Condition: סוג Host, אופרטור Equal to (=), ערך
www.domain.co.il. - Add Rule, ואז בדקו בחלון גלישה בסתר.
אם יש כמה חוקים, אפשר לגרור ולשנות את הסדר שלהם. חוק שנמצא גבוה יותר מופעל קודם. אחרי שינוי סדר לחצו Save.
Header Rules: כותרות אבטחה וקאש
- בלשונית Header Rules לחצו Add Header Rule.
- ב-Rule Type בחרו Custom, או אחת התבניות המוכנות.
- ב-Action בחרו Set (הוספה או שינוי) או Unset (הסרה).
- הזינו Header Name ו-Value.
- השאירו Always Apply פעיל כדי שהכותרת תחול על כל הבקשות, או כבו אותו וצרפו תנאי לכתובת מסוימת.
- לחצו Add Rule.
| מטרה | Header Name | Value |
|---|---|---|
| לחייב HTTPS לשנתיים (HSTS) | Strict-Transport-Security | max-age=63072000; includeSubDomains; preload |
| למנוע קאש לקובץ שחייב להיות עדכני | Cache-Control | no-store, no-cache, must-revalidate, max-age=0 |
| לחסום הטמעת האתר ב-iframe באתרים אחרים | X-Frame-Options | SAMEORIGIN |
| להסתיר את סוג השרת | Server (בפעולת Unset) | – |
הערכים בטבלה הם הדוגמאות מהתיעוד של קלאודוויז. על HSTS עם preload: זו התחייבות ארוכת טווח שהאתר וכל תת-הדומיינים שלו יעבדו רק ב-HTTPS, וקשה לבטל אותה. הפעילו אותה רק אחרי שווידאתם שיש תעודת SSL תקינה לכל תת-דומיין. בהתחלה אפשר להסתפק בערך זהיר, למשל max-age=300 בלי includeSubDomains ובלי preload, ולהגדיל רק כשהכול עובד.
כדי לבדוק שכותרת נכנסה לתוקף, פתחו את האתר בחלון גלישה בסתר, פתחו את כלי המפתחים (F12), בלשונית Network לחצו על הבקשה הראשונה, ובדקו את Response Headers. אם תוסף קאש או CDN מגדירים את אותה כותרת, נקו את הקאש שלהם ובדקו שוב.
איך להגדיר robots.txt בקלאודוויז
robots.txt יושב בתיקייה הראשית של האתר, כך שהוא נגיש בכתובת https://domain.co.il/robots.txt. בקלאודוויז זו התיקייה public_html של האפליקציה.
באתר וורדפרס: לפני שיוצרים קובץ
וורדפרס מייצרת robots.txt וירטואלי משלה כשאין קובץ אמיתי. תוספי SEO כמו Yoast ו-Rank Math מאפשרים לערוך אותו מתוך לוח הבקרה, וזו הדרך הנוחה לרוב האתרים (תוספים מסוימים כותבים בפועל קובץ אמיתי, ולכן בדקו מה קיים בתיקייה). אם תעלו קובץ robots.txt אמיתי ל-public_html, הוא יגבר על הווירטואלי, ושינויים בתוסף יפסיקו להשפיע. זה מקור בלבול נפוץ.
יצירה והעלאה של הקובץ
- צרו במחשב קובץ טקסט בשם
robots.txt(באותיות קטנות), בקידוד UTF-8. - כתבו את החוקים (דוגמה בהמשך).
- העלו אותו לתיקייה
public_htmlשל האפליקציה, דרך מנהל הקבצים או SFTP עם FileZilla. - פתחו בדפדפן את הכתובת domain.co.il/robots.txt וודאו שאתם רואים את התוכן החדש. אם לא, נקו את הקאש של Varnish.
למי שעובד ב-SSH, אפשר ליצור את הקובץ ישירות בשרת:
cd applications/APP_FOLDER/public_html
nano robots.txt
דוגמה לאתר וורדפרס או ווקומרס טיפוסי:
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /?s=
Disallow: /cart/
Disallow: /checkout/
Sitemap: https://domain.co.il/sitemap_index.xml
| חוק | משמעות |
|---|---|
| User-agent: * | החוקים הבאים חלים על כל הבוטים |
| Disallow: / | אל תסרקו כלום באתר. מתאים ל-Staging, מסוכן באתר חי |
| Disallow: /folder/ | אל תסרקו את התיקייה הזו |
| Disallow: /*.pdf$ | אל תסרקו קבצים מסוג מסוים |
| Allow: /path | חריגה מחוק Disallow רחב יותר |
| Sitemap: | כתובת מפת האתר המלאה |
טעות יקרה: משאירים Disallow: / מ-Staging, דוחפים לאתר החי, ויום אחד מגלים שגוגל הפסיק לסרוק את האתר. אחרי כל Push מ-Staging או העברת אתר, פתחו את robots.txt של האתר החי ובדקו. וזכרו: Disallow לא מוציא עמוד שכבר נמצא באינדקס. בשביל זה צריך noindex, והעמוד צריך להיות פתוח לסריקה כדי שגוגל יראה את התגית.
מה אפשר לעשות עם htaccess בקלאודוויז
הקובץ .htaccess יושב ב-public_html של האפליקציה, ונקרא רק ב-Hybrid Stack. הדרך הכי בטוחה לערוך אותו היא SSH או SFTP, עם עותק גיבוי לפני כל שינוי. בוורדפרס כבר יש בו בלוק # BEGIN WordPress. הוסיפו חוקים מעליו, ולא בתוכו, כי וורדפרס משכתבת את הבלוק הזה.
הפניות ו-HTTPS
הפניה קבועה של כל האתר לדומיין חדש:
Redirect 301 / https://new-domain.co.il/
כפיית HTTPS. שימו לב שבודקים את X-Forwarded-Proto ולא את HTTPS הרגיל, כי בקלאודוויז Nginx מקבל את החיבור המוצפן ומעביר אותו הלאה ל-Apache:
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
איחוד ל-www:
RewriteEngine On
RewriteCond %{HTTP_HOST} ^example\.co\.il$ [NC]
RewriteRule ^(.*)$ https://www.example.co.il/$1 [L,R=301,NC]
למי שמעדיף בלי קוד, יש גם מדריך להפניית HTTP ל-HTTPS בקלאודוויז.
הגנת סיסמה, חסימת IP וחסימת בוטים
הגנת סיסמה על אתר בפיתוח, בשלושה צעדים ב-SSH:
- בתיקייה public_html של האפליקציה הריצו
pwdוהעתיקו את הנתיב המלא. - צרו קובץ סיסמאות ומשתמש (המערכת תבקש סיסמה פעמיים):
htpasswd -c .htpasswd USERNAME - הוסיפו ל-htaccess את השורות הבאות, עם הנתיב שהעתקתם:
AuthName "Restricted"
AuthType Basic
AuthUserFile /FULL/PATH/public_html/.htpasswd
Require user USERNAME
חסימת כתובות IP מסוימות (הכתובות בדוגמה הן טווח תיעוד בלבד, החליפו אותן בכתובות שאתם רוצים לחסום):
<Limit GET POST>
order allow,deny
deny from 203.0.113.10
deny from 203.0.113.11
allow from all
</Limit>
חסימת בוט לפי User-Agent:
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} ^.*(BadBot|EvilScraper).*$ [NC]
RewriteRule .* - [F,L]
לחסימת IP ברמת השרת כולו, ולהגנה מבוטים בהיקף רחב, עדיף להשתמש בחומת האש של השרת ובשכבת ה-Bot Protection של Cloudflare Enterprise, שמוסברות במדריך לאבטחת השרת. חוק ב-htaccess מטפל רק באפליקציה אחת, ורק אחרי שהבקשה כבר הגיעה ל-Apache. מכיוון שהבקשה עוברת קודם דרך Nginx, אם חסימת IP לא משפיעה ייתכן שה-IP ש-Apache רואה אינו של הגולש. במקרה כזה חסמו בחומת האש של השרת.
הגדרות PHP ב-htaccess: לא בשרתים חדשים
שורות כמו php_value post_max_size 20M נפוצות במדריכים ישנים. בשרתים שהוקמו מ-23 באוגוסט 2016 ואילך, עם PHP-FPM, הן לא עובדות. משנים את הערכים האלה בהגדרות ה-PHP של השרת או של האפליקציה.
הגדרות נוספות באותו אזור: Web Root, CORS, חסימת גישה ו-Session Path
כל ההגדרות האלה נמצאות באפליקציה, תחת Application Settings.

שינוי Web Root
Web Root היא התיקייה שממנה השרת מגיש את האתר. ברירת המחדל היא public_html. מסגרות כמו Laravel ו-Symfony מגישות מתת-תיקייה (למשל public), ואז צריך לשנות.
- ב-Application Settings מצאו את השדה Webroot.
- הזינו את הנתיב החדש. הוא חייב להיות בתוך public_html, למשל
public_html/public. - שמרו. אם התיקייה לא קיימת, היא תיווצר אוטומטית.
ודאו שבתיקייה החדשה יש קובץ index.php או index.html. אחרת האתר יציג שגיאה.
הפעלת CORS
CORS מאפשר לאתר אחר לטעון משאבים מהאתר שלכם, למשל פונטים, תמונות או קריאות API מאפליקציית פרונט נפרדת. כברירת מחדל דפדפנים חוסמים את זה.
- ב-Application Settings גללו ל-CORS Header.
- הפעילו את המתג ואשרו עם Confirm.
מגבלות לפי התיעוד: ההגדרה חלה על כל הדומיינים של האפליקציה, היא דורסת כותרות CORS שהוגדרו ב-htaccess או בקוד, ונכון ל-2026 נתמך רק ערך wildcard (*), כלומר כל דומיין מורשה. אם אתם צריכים להתיר דומיין אחד בלבד, הגדירו את הכותרת ב-Header Rules או בקוד, והשאירו את המתג כבוי. ב-CloudwaysCDN כותרות CORS פעילות כבר כברירת מחדל.
חסימת גישה זמנית לאתר
כשאתר בפיתוח, לא בשימוש, או אחרי פריצה, אפשר לנתק אותו בלי למחוק:
- ב-Application Settings גללו ל-Application Access.
- כבו את המתג ולחצו Proceed.
מה קורה: האתר לא נפתח, לא בדומיין ולא בכתובת הזמנית. גישת SFTP/SSH עם פרטי האפליקציה מושבתת (משתמש ה-Master עדיין נכנס), ומשימות Cron נעצרות. גיבויים ומסד הנתונים ממשיכים לעבוד. מחזירים את הגישה באותו מתג. הניתוק לא מוחק ולא עוצר את השרת עצמו, ולכן אל תניחו שהחיוב נעצר.
הגדרת Session Path
רלוונטי בעיקר לאפליקציות PHP מותאמות שצריכות תיקייה ייעודית לקבצי Session. בוורדפרס רגיל כמעט אף פעם לא צריך לגעת בזה.
- ב-SSH הריצו
hostnameורשמו את התוצאה. - צרו תיקייה. התיעוד ממליץ על
public_html/var/sessions, כי התיקייה הזו מוחרגת אוטומטית משכפול ומיצירת Staging:
cd applications/APP_FOLDER/public_html
mkdir -p var/sessions
- באפליקציה, תחת Application Settings, פתחו את PHP FPM Settings והוסיפו בסוף (בלי נקודה-פסיק בתחילת השורה, אחרת היא הופכת להערה):
php_admin_value[session.save_path] = /home/HOSTNAME/APP_FOLDER/public_html/var/sessions
- לחצו Save Changes.
ודאו שהתיקייה לא נגישה מהדפדפן, למשל עם חוק htaccess שחוסם אותה, כי היא בתוך public_html.
הקוד BFCM802 מוריד 80% מהחשבון בחודשיים הראשונים (עד 200$ הנחה בחודש), כולל העברת אתרים חינם בלי הגבלה. ללקוחות חדשים בלבד, ורק עד סוף המבצע.
המבצע מסתיים ב-4 בדצמבר 2026, ב-23:59 שעון ישראל.
מתחילים בניסיון חינם, בלי כרטיס אשראי. את הקוד מזינים בקופה ובודקים שהוא מופיע.
אחרי בלאק פריידי: 30% הנחה ל-3 חודשים עם הקוד ASAEL. בשרת גדול (מעל כ-444$ בחודש) ASAEL משתלם יותר כבר עכשיו. למחשבון BFCM802 מול ASAEL
פותחים שרת ניסיון חינם, בלי כרטיס אשראי. כשעוברים לתוכנית בתשלום, הקוד ASAEL מוריד 30% מהחשבון בשלושת החודשים הראשונים.
הקישור ממלא את הקוד בטופס ההרשמה. רק ודאו שהוא מופיע.
מהן הטעויות הנפוצות ואיך פותרים אותן?
חוקי htaccess לא עובדים בכלל: האפליקציה כנראה ב-Lightning Stack, שבו אין Apache. בדקו בלשונית WebStack. העבירו את החוקים ל-Web Rules או חזרו ל-Hybrid.
"Too many redirects" אחרי הוספת הפניה: שני חוקים מפנים זה לזה, למשל Web Rule ל-www וחוק htaccess בלי www, או הגדרת כתובת האתר בוורדפרס שסותרת את ההפניה. השאירו חוק אחד בלבד, וודאו שכתובת האתר בוורדפרס תואמת לו.
Error 500 אחרי עריכת htaccess: שגיאת תחביר. החזירו את העותק ששמרתם, ובדקו את השורה החדשה. גרשיים מעוצבים שהועתקו מעורך טקסט הם חשוד נפוץ.
שיניתם robots.txt ובדפדפן עדיין רואים את הישן: Varnish או CDN שומרים עותק. נקו את הקאש. בוורדפרס, בדקו שאין גם תוסף שמייצר robots.txt וירטואלי במקביל.
הגעתם למגבלת 25 החוקים: אחדו חוקים עם Regex, העבירו הפניות ישנות לתוסף הפניות, או עברו ל-Hybrid Stack עם htaccess.
אתר לא נטען אחרי שינוי Web Root: אין קובץ index בתיקייה החדשה, או שהנתיב לא בתוך public_html.
מקורות
- Cloudways Knowledge Base: How to create and manage web rules in Cloudways
- Cloudways Knowledge Base: How to setup robots.txt for your website
- Cloudways Knowledge Base: What can I do with an .htaccess file
- Cloudways Knowledge Base: How to change the web root of an application
- Cloudways Knowledge Base: How to enable CORS headers for your application
- Cloudways Knowledge Base: How to stop access to your application on Cloudways
- Cloudways Knowledge Base: Setting up the session path from the Cloudways platform
שאלות נפוצות
בתיקייה public_html של האפליקציה, אם יצרתם אותו. אם אין קובץ, וורדפרס מייצרת robots.txt וירטואלי, ותוספי SEO כמו Yoast מאפשרים לערוך אותו מלוח הבקרה. קובץ אמיתי בתיקייה גובר על הווירטואלי.
הסיבה הנפוצה היא Lightning Stack, שבו אין Apache ולכן htaccess לא נקרא בכלל. בדקו את ה-Stack בלשונית WebStack בהגדרות האפליקציה. סיבה שנייה: הגדרות PHP כמו php_value, שלא עובדות בשרתים עם PHP-FPM.
עד 25 חוקי הפניה ושכתוב לכל אפליקציה, עם תנאי אחד לכל חוק, ועד 10 חוקי כותרות. מעבר לזה קלאודוויז ממליצה על Hybrid Stack עם htaccess.
כן. הם נבנו בשביל Lightning Stack, אבל זמינים בשני ה-Stacks. נכון לנובמבר 2026 הפיצ'ר עדיין בבטא ציבורית (Public Preview), אז בדקו כל חוק מיד אחרי שהוספתם אותו.
לא. robots.txt רק מבקש ממנועי חיפוש לא לסרוק, ובוטים זדוניים מתעלמים ממנו. יותר מזה, הוא מפרסם את רשימת התיקיות שביקשתם להסתיר. להגנה אמיתית השתמשו בסיסמה, בחסימת IP או בחסימת גישה לאפליקציה.
הדרך הכי פשוטה היא לכבות את Application Access עד ההשקה. אם צריך שהלקוח יראה את האתר, הגנת סיסמה ב-htaccess עדיפה על robots.txt, כי היא באמת חוסמת.
מדריכים קשורים
- הגדרות שרת ושירותים בקלאודוויז
- WP-CLI בקלאודוויז
- איך לגשת למנהל הקבצים
- איך לאפס סיסמה בקלאודוויז
- איך לשנות גרסת PHP
- כל המדריכים בתחום: הגדרות שרת וכלים למפתחים
- למה שרת מנוהל: אחסון אתרים בקלאודוויז
מקור רשמי: How to Create and Manage Web Rules in Cloudways, How to Setup robots.txt for Your Website, What Can I Do With an .htaccess File?, How to Change the Web Root, How to Enable CORS Headers, How to Stop Access to Your Application, Setting up the Session Path (Cloudways Knowledge Base). המדריך נכתב ונבדק על ידי עשהאל דרייר · עודכן: 06.11.2026
גילוי נאות: זהו אתר עצמאי ואינו האתר הרשמי של Cloudways. חלק מהקישורים באתר הם קישורי שותפים – אם תירשמו דרכם נקבל עמלה, בלי עלות נוספת לכם. לפרטים המלאים