בניתם אתר ב־Lovable ואתם רוצים לפרסם אותו על הדומיין שלכם, להעביר אותו לאחסון עצמאי או פשוט להבין מה באמת צריך כדי שהאתר ימשיך לעבוד מחוץ לסביבת הבנייה? המדריך הזה מיועד לבעלי עסקים ולבוני אתרים שרוצים לקבל החלטה טכנית ומסחרית בלי לנחש.
תקציר מהיר
- Lovable מאפשרת חיבור ל־GitHub ועבודה עם קוד סטנדרטי; התאמת הפרויקט לאחסון חיצוני תלויה במה שהאתר עושה בפועל.
- אתר סטטי או build של React/Vite בדרך כלל פשוט יותר לפריסה מאפליקציה שתלויה ב־backend, במסד נתונים או בשירותי ענן.
- לפני מעבר שומרים עותק מלא, בודקים משתני סביבה, APIs, טפסים, authentication ו־DNS.
- לאתר AI שיוצא כקבצים סטטיים, אפשר לבדוק את חבילת Wing Start.
- לא מבטלים את הסביבה הישנה לפני שבודקים את האתר החדש על הדומיין האמיתי.
מה זה אתר שנבנה ב־Lovable?
Lovable היא סביבת פיתוח מבוססת AI שמייצרת אפליקציות ואתרי Web בקוד סטנדרטי. מבחינת אחסון, השם של כלי הבנייה פחות חשוב מהשאלה מה הפרויקט צריך בזמן ריצה: האם מספיק להגיש קבצי HTML, CSS ו־JavaScript, או שהאתר תלוי גם בשרת, מסד נתונים, authentication, storage, פונקציות backend או שירותי צד שלישי.
לכן שני אתרים שנבנו באותו כלי יכולים לדרוש תשתיות שונות לגמרי. אתר תדמית עם כמה עמודים וטופס חיצוני יכול להיות קל מאוד לפריסה; מערכת עם משתמשים, נתונים ותהליכים עסקיים דורשת בדיקה עמוקה יותר.
האם אפשר לאחסן אתר Lovable מחוץ ל־Lovable?
כן, במקרים המתאימים. לפי התיעוד הרשמי של Lovable, ניתן לחבר פרויקט ל־GitHub ולעבוד עם הקוד מחוץ לסביבת Lovable, כולל תהליכי deployment חיצוניים. עם זאת, עצם קיומו של repository לא אומר שכל שירות שהפרויקט משתמש בו יעבור אוטומטית לשרת אחר.
האתר שלי הוא אתר תדמית או landing page
אם לאחר build מתקבלת תיקיית קבצים סטטיים, זה בדרך כלל המקרה הפשוט ביותר. בודקים שהניתוב, הטפסים והנכסים עובדים ומעלים את הקבצים לאחסון סטטי.
האתר שלי משתמש ב־React/Vite אבל בלי backend משלו
גם כאן אפשר לעיתים קרובות לפרוס build סטטי. באפליקציית SPA צריך לוודא שהשרת מחזיר את index.html גם בכתובות פנימיות, כדי שרענון של עמוד לא יחזיר 404.
יש משתמשים, מסד נתונים או פעולות שרת
כאן לא מזמינים חבילת אחסון סטטית באופן אוטומטי. צריך למפות אילו שירותים נשארים בענן, אילו secrets נדרשים ואילו רכיבים צריכים backend פעיל.
למי מעבר לאחסון עצמאי יכול להתאים?
עסק שסיים את שלב הבנייה
כשהאתר כבר יציב ורוב השינויים הם תוכן קטנים, הפרדת הבנייה מהאחסון יכולה לתת שליטה טובה יותר בעלויות ובקבצים.
בעל אתר שרוצה שליטה בדומיין
האחסון והדומיין יכולים להיות מנוהלים בנפרד מהכלי שבו האתר נבנה. זה מקל על מעבר עתידי ועל ניהול DNS.
מי שמרכז כמה אתרי AI
אם בונים כמה אתרים קלים, ריכוז האחסון במקום אחד יכול להפוך את הניהול לפשוט יותר — כל עוד כל אתר אכן מתאים לסביבה שנבחרה.
ומתי זה פחות מתאים?
אם הפרויקט עדיין משתנה מדי יום, תלוי בשירותי backend של הפלטפורמה, או שאין לכם גישה מספקת לקוד ולמשתני הסביבה, מעבר מוקדם עלול ליצור יותר עבודה מחיסכון.
מה צריך להכין לפני שמעבירים אתר מ־Lovable?
- עותק עדכני של הקוד או repository פעיל.
- רשימה של משתני סביבה ו־API keys, בלי לשלוח secrets בהודעות לא מאובטחות.
- מיפוי של מסד נתונים, authentication, storage ושירותי צד שלישי.
- גישה לניהול הדומיין וה־DNS.
- רשימת כל הטפסים והפעולות שצריך לבדוק אחרי המעבר.
- גיבוי של הגרסה שעובדת לפני שינוי DNS.
- בדיקה של כתובות URL, title, meta description, canonical ו־robots לפני העלייה.
איך תהליך המעבר עובד בפועל?
- מסווגים את הפרויקט. סטטי, SPA, או אפליקציה עם backend.
- בונים גרסת production. מוודאים שה־build מסתיים בלי שגיאות ושאין secrets בתוך קבצי frontend.
- מעלים לסביבת בדיקה. בודקים עמודים, תמונות, טפסים וקישורים לפני חיבור הדומיין הראשי.
- מחברים DNS ו־SSL. רק אחרי שהסביבה החדשה מוכנה.
- בודקים אחרי העלייה. מובייל, נגישות, 404, טפסים, מהירות ו־Search Console.
- משאירים את הסביבה הקודמת זמינה לזמן מעבר. סוגרים אותה רק כשהתנועה והפונקציות עברו בהצלחה.
מתי Wing Start לא בהכרח מספיקה?
Wing Start מיועדת לאתרי AI שיוצאו כקבצים ולאתרי HTML פשוטים. אם האפליקציה צריכה תהליך Node.js קבוע, מסד נתונים מקומי, workers, queues או שירות backend ייעודי, צריך לבדוק פתרון אחר לפני ההזמנה.
Wing Start
לאתרי AI שיוצאו כקבצים ולאתרי HTML פשוטים
₪27.90
לחודש, בתשלום שנתי
₪334.80 לשנה
או ₪33.48 בחיוב חודשי
- 100 MB אחסון
- 10 GB תעבורה חודשית
- תעודת SSL כלולה
לא בטוחים? עדיף לבצע בדיקת התאמה לפני שמשנים DNS. זה חוסך מצב שבו האתר נראה תקין בדף הבית אבל פעולות חשובות כמו טופס, login או checkout אינן עובדות.
האם מעבר מ־Lovable לאחסון אחר יכול לפגוע ב־SEO?
עצם שינוי ספק האחסון אינו מחייב שינוי בדירוג. הסיכון נוצר בעיקר כאשר משתנות כתובות URL, נעלמים עמודים, robots.txt חוסם בטעות סריקה, תגיות SEO נעלמות או שהאתר אינו זמין בזמן המעבר.
אם שומרים על אותן כתובות, בודקים שהשרת מחזיר 200 לעמודים הנכונים ומנטרים את המעבר ב־Search Console, אפשר לצמצם מאוד את הסיכון. Google ממליצה להכין ולבדוק את התשתית החדשה לפני שינוי DNS ולהשאיר את הישנה פעילה עד שהמעבר הושלם.
שאלות נפוצות
האם חייבים WordPress כדי לאחסן אתר שנבנה ב־Lovable?
לא. אם האתר יוצא כקבצים סטטיים אין סיבה להפוך אותו ל־WordPress רק לצורך אחסון.
האם אפשר לחבר דומיין co.il?
כן. אפשר לחבר דומיין קיים באמצעות DNS, בלי קשר לכלי שבו האתר נבנה.
האם צריך להשאיר את Lovable פעיל אחרי המעבר?
זה תלוי בתלות של הפרויקט בשירותי הפלטפורמה ובדרך שבה אתם ממשיכים לפתח אותו. אל תבטלו שירות לפני שבדקתם שכל הרכיבים החיצוניים עובדים.
מה אם יש Supabase או שירות backend חיצוני?
אפשר לעיתים להשאיר את השירות החיצוני פעיל ולפרוס רק את ה־frontend במקום אחר. צריך לבדוק URLs, CORS, secrets והרשאות.
כמה זמן לוקח מעבר?
אתר סטטי פשוט יכול לעבור מהר, אבל propagation של DNS ובדיקות לאחר המעבר עשויים להימשך יותר. לא מומלץ לקבוע זמן קשיח בלי לראות את הפרויקט.
איך יודעים איזו חבילה מתאימה?
בודקים את סוג ה־build ואת התלות בשירותי backend. לאתר סטטי קטן מתחילים מבדיקת Wing Start; לפרויקט דינמי מבצעים בדיקת התאמה.
מדריכים ועמודים שיכולים לעזור
TL;DR
אם אתר Lovable שלכם ניתן לפריסה כקבצים או כ־frontend עצמאי, אפשר לבחון אחסון עצמאי. לפני המעבר ממפים backend ושירותים חיצוניים, שומרים גיבוי, בודקים את הגרסה החדשה ורק אז משנים DNS. לאתר סטטי קטן, Wing Start היא נקודת פתיחה לבדיקה.