Lovable למתחילים
המדריך המלא לבניית אתר עם AI

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

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

מתאים במיוחד ל:

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

פחות מתאים ל:

• אתרים שכל המודל העסקי שלהם הוא תנועה אורגנית מגוגל (ראה פרק ה-SEO)
• מערכות עם עשרות מסכים ולוגיקה עסקית שזורה
• אפליקציות מובייל נייטיב (Lovable בונה אתרים, גם אם הם מרגישים כמו אפליקציה)

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

הפרונטאנד — מה שהמבקר רואה: עמודים, כפתורים, טקסטים, תמונות. נבנה ב-React עם עיצוב ב-Tailwind CSS.

הבקאנד — מה שקורה מאחור: בסיס נתונים, התחברות משתמשים, שליחת מיילים, תשלומים. עד אוקטובר 2025 היה צריך לחבר Supabase בעצמך; היום יש Lovable Cloud — בסיס נתונים, אימות משתמשים ואחסון קבצים מובנים, בלי חשבון חיצוני ובלי הגדרות.

קרדיטים — כל בקשה מה-AI צורכת קרדיטים. זה המשאב המוגבל שלך, לא הזמן. כל המדריך הזה בנוי סביב ההבנה הזו.

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

קח דף ותענה על חמש שאלות:

1. 1מה מטרת האתר? משפט אחד. "שגולש ישאיר טלפון" זה לא אותו אתר כמו "שגולש יבין למה אנחנו יקרים יותר".
2. 2מי הקהל? גיל, רמת מיומנות דיגיטלית, האם הם מגיעים מהנייד.
3. 3אילו עמודים? רשימה. בית, אודות, שירותים, צור קשר — או משהו אחר.
4. 4מה קורה בכל עמוד? בשורה אחת לכל עמוד.
5. 5מה הפעולה שאתה רוצה שיעשו? כפתור אחד ראשי. לא שלושה.

נכנסים ל-lovable.dev ומתחברים עם Google או אימייל. אין צורך בכרטיס אשראי.

התוכניות (יולי 2026)

הפרומפט הראשון הוא ההשקעה הכי משתלמת בכל התהליך. אורך מומלץ: 150–400 מילים. פחות — ה-AI ממציא. יותר — הוא מפספס פרטים.

בנה אותו בארבע שכבות:

1. 1הקשר. מה אנחנו בונים, למי, ומה המטרה.
2. 2מבנה. אילו עמודים, ומה יש בכל אחד.
3. 3עיצוב. צבעים (HEX), טיפוגרפיה, אווירה.
4. 4אילוצים. עברית/RTL, ריספונסיבי, ומה לא לבנות עכשיו.

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

מאז פברואר 2026 יש ב-Lovable מצב Plan Mode: לפני שה-AI כותב שורת קוד אחת, הוא מציג לך תוכנית מפורטת של מה שהוא מתכוון לבנות.

הכלל היחיד שחשוב: בקשה אחת בכל הודעה.

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

מה שעובד

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

Visual Edits — לא צורך קרדיטים

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

כלל: כל שינוי ויזואלי קטן — Visual Edits. פרומפט זה לשינויים מבניים.

רפרנס עיצובי

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

לוגו וצבעים

• העלה לוגו כ-PNG שקוף, וציין במפורש גובה ומיקום.
• תן צבעים כקודי HEX. לעולם לא "כחול" או "ירוק רגוע".
• בקש להגדיר את הצבעים כ-design tokens — אז שינוי אחד מעדכן את כל האתר, במקום 40 מקומות.

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

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

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

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

עם Lovable Cloud זה פשוט. תגיד מה אתה צריך:

• טופס שנשמר — "טופס יצירת קשר עם שם, טלפון, אימייל וסוג טיפול. לשמור את הפניות בבסיס הנתונים ולהציג הודעת תודה."
• התראה במייל — "לשלוח לי מייל בכל פעם שמישהו ממלא את הטופס." (מחייב חשבון Resend או SendGrid — חינמי בהתחלה)
• אזור אישי — "התחברות עם אימייל וסיסמה, ואזור אישי שבו כל מטופל רואה רק את התורים שלו."
• לוח ניהול — "עמוד /admin שרק אני רואה, עם טבלה של כל הפניות, מסודרות מהחדשה לישנה."

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

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

קביעת תורים — Calendly. משובץ כ-embed בשניות. תומך גם בגביית תשלום מראש דרך Stripe ובניתוב לידים ל-HubSpot.

CRM. שתי דרכים: webhook לכלי אוטומציה (Zapier / Make / n8n) שמזרים ל-HubSpot או Salesforce — הדרך המומלצת למי שלא מפתח; או קריאת API ישירה מפונקציית שרת.

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

זו לא פרנויה. זו היסטוריה מתועדת.

בינואר 2025 נחשפה חולשה (CVE-2025-48757) שנגעה ליותר מ-170 אפליקציות שנבנו ב-Lovable — כ-10% מהפרויקטים שנסרקו. דלפו שמות, אימיילים, טלפונים, כתובות, פרטי תשלום ומפתחות API. באפריל 2026 נחשף אירוע רחב נוסף שנגע בפרויקטים שנוצרו לפני נובמבר 2025.

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

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

צ'קליסט אבטחה — לפני שאתה מפרסם

• הרצתי את סורק האבטחה של Lovable וטיפלתי בכל אזהרה.
• ביקשתי במפורש: "לוודא ש-RLS מופעל על כל טבלה, ושכל משתמש רואה רק את הנתונים שלו."
• בדקתי בפועל: פתחתי את האתר בחלון פרטי, בלי להתחבר, וניסיתי להגיע לנתונים. לא הצלחתי.
• בדקתי שמשתמש א' לא רואה את הנתונים של משתמש ב'.
• אין בקוד הפרונטאנד אף מפתח סודי (sk_live_, מפתחות API של ספקים, סיסמאות).
• עמוד ה-admin באמת חסום למי שאינו אדמין — לא רק מוסתר מהתפריט.
• יש דף מדיניות פרטיות, אם האתר אוסף פרטים אישיים.

זו נקודת החולשה האמיתית של Lovable, וכדאי לדעת עליה מראש.

אתרי Lovable הם SPA (Single Page Application) עם רינדור בצד הלקוח. במילים אחרות: הרובוט של גוגל מקבל בתחילה שלד HTML ריק, והתוכן נטען אחר כך ב-JavaScript. גוגל אכן מריץ JavaScript, אבל דוחפת עמודים כאלה לתור רינדור נפרד — האינדוקס איטי בסדר גודל של פי 9 בהשוואה ל-HTML סטטי, ועיכוב של 3–6 שבועות הוא נורמלי. קראולרים של מנועי חיפוש מבוססי AI לרוב לא מרנדרים בכלל.

לחיצה על Publish בפינה מעלה מפרסמת את האתר לכתובת yourapp.lovable.app — בחינם, בלי הגדרות DNS.

דומיין משלך (מחייב תוכנית בתשלום): Project → Settings → Domains. אפשר לרכוש דומיין דרך Lovable, לחבר דומיין קיים אוטומטית, או להוסיף רשומות DNS ידנית אצל הרשם: CNAME לסאב-דומיין, ALIAS/ANAME לדומיין הראשי, ורשומת TXT לאימות. התפשטות ה-DNS לוקחת בדרך כלל 10–60 דקות, לפעמים עד 48 שעות.

חיבור ל-GitHub נותן לך שלושה דברים, וכולם חשובים:

1. 1גיבוי אמיתי של כל היסטוריית הפרויקט, מחוץ ל-Lovable.
2. 2יכולת לחזור אחורה לכל נקודה שבה האתר עבד.
3. 3דרך יציאה. אם תחליט להמשיך את הפרויקט עם מפתח, ב-VS Code, ב-Cursor או בכל כלי אחר — הקוד שם, מוכן. הסנכרון דו-כיווני: שינוי בכל צד מתעדכן בצד השני.

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

1. 1Visual Edits לכל שינוי קטן — צבע, טקסט, ריווח. לא צורך קרדיטים בכלל.
2. 2Plan Mode לפני בקשות גדולות — לתקן תוכנית זה חינם; לתקן קוד זה לא.
3. 3בקשה אחת בכל הודעה — פחות פלטים חלקיים, פחות תיקונים.
4. 4לאבחן לפני שמתקנים — לחזור על אותו פרומפט אחרי כישלון זה הדרך הבטוחה לבזבז שלושה קרדיטים על אותה שגיאה.
5. 5פרומפט ממוקד — "תשפר את האתר" גורם ל-AI לגעת ב-15 קבצים. "תקטין את הכותרת בעמוד הבית ל-48px" נוגע באחד.

1. 1לפרמפט לפני שהחלטת מה אתה בונה.
2. 2לבקש חמישה דברים בהודעה אחת.
3. 3"תעשה שיהיה יפה" — אין למודל למה להיאחז.
4. 4להוסיף RTL בדיעבד במקום בפרומפט הראשון.
5. 5לפרמפט שינויים ויזואליים קטנים במקום להשתמש ב-Visual Edits.
6. 6לא לחבר GitHub, ואז לגלות שאין דרך לחזור אחורה.
7. 7לפרסם אתר שאוסף פרטים בלי לוודא RLS.
8. 8להשאיר מפתח סודי בקוד הפרונטאנד.
9. 9לשכוח שצריך ללחוץ Publish → Update כדי שהשינויים יעלו לאוויר.
10. 10לצפות שהאתר ידורג בגוגל תוך שבוע — בלי לטפל ב-SEO ובלי להבין את מגבלת ה-SPA.

כדאי לדעת את הגבולות מראש, כדי לא להתאכזב:

• מורכבות — מעל בערך 15–20 מסכים עם לוגיקה שזורה, ה-AI מתחיל לשבור דברים שעבדו.
• SEO ורינדור בצד השרת — ראה פרק 13.
• אבטחה — ברירות המחדל שופרו מאוד, אבל הן לא תחליף לביקורת של מי שמבין.
• ביצועים בקנה מידה — אין אופטימיזציית בסיס נתונים או ניהול עומסים אוטומטי.
• נגישות — WCAG ותקן ישראלי 5568 לא מטופלים אוטומטית. לאתר מסחרי בישראל זו דרישה חוקית, ותצטרך להתייחס אליה בנפרד.
• דיוק פיקסלי מול מוקאפ Figma — מגיעים ל-90%. את ה-10% האחרונים עושים בידיים.

לפני שאתה שולח את הקישור למישהו:

• כל העמודים נטענים, כל הקישורים עובדים, אין 404
• נבדק בנייד — לא רק בחלון מוקטן בדפדפן, אלא בטלפון אמיתי
• כל הטפסים נשלחים בהצלחה, וההודעות מגיעות ליעד
• העברית מיושרת נכון בכל העמודים, כולל טפסים וטבלאות
• אין טקסט "Lorem ipsum" או תמונות placeholder ששרדו
• צ'קליסט האבטחה מפרק 12 — כולו מסומן
• Meta titles, descriptions ותמונת OG לכל עמוד
• שיתוף הקישור בוואטסאפ מציג תצוגה מקדימה נכונה
• הפרויקט מחובר ל-GitHub
• לחצת Publish → Update אחרי השינוי האחרון

1. 1יום 1 — תכנון ובנייה. 15 דקות תכנון (פרק 3), פרומפט ראשון מובנה, ואז חמש-שש איטרציות ממוקדות עד שהמבנה נכון. לא לגעת בעיצוב הדק.
2. 2יום 2 — עיצוב ותוכן. Visual Edits לליטוש, החלפת כל התוכן בטקסט אמיתי, תמונות אמיתיות, בדיקת RTL בכל עמוד ובנייד.
3. 3יום 3 — נתונים, אבטחה והשקה. חיבור טפסים, התראות מייל, אינטגרציות, צ'קליסט האבטחה, SEO, חיבור דומיין, פרסום.