אחד הלקוחות הקבועים שלי שולח לי קישור למשהו שבנה בעצמו בתוך כמה שעות עם Lovable או v0. זה נראה מצוין. ואז מגיע המשפט הצפוי: ״אפשר פשוט להעלות את זה לוורדפרס?״
המילה ״פשוט״ היא בדיוק הנקודה שבה מתחילות הצרות. כלי בניית האפליקציות מבוססי ה-AI טובים מאוד ביצירת מסך שנראה גמור. הבעיה היא כל מה שאי אפשר לראות בצילום מסך.
והכלים האלה הם ממש לא ניסוי שולי. Lovable חצתה 200 מיליון דולר בהכנסה שנתית וכ-8 מיליון משתמשים בתוך פחות משנה, ול-v0 יש יותר מ-4 מיליון משתמשים. כלומר, המון אנשים עומדים להיתקל בדיוק באותו קיר: הפער בין פרוטוטייפ שנראה מוכן לבין אתר שבאמת מוכן לפרודקשן. פוסט זה הוא ההמשך המעשי למדריך הרחב יותר שלי על וייב קודינג לוורדפרס.
דלגו ישירות לתהליך ההמרה שאני מבצע
נראה גמור. וזו בדיוק המלכודת.
כל כלי המרה וכל מדריך שראיתי מתייחסים ל״זה נראה אותו דבר בתבנית״ כאילו זה קו הסיום. מניסיוני, דווקא שם מתחילה העבודה האמיתית. העיצוב הוא 70 האחוזים הקלים. 30 האחוזים האחרונים הם מה שהופך אתר למוכן לפרודקשן, וזה בדיוק מה שייצוא מ-AI משמיט.
״30 האחוזים האחרונים – החלק שהופך תוכנה למוכנה לפרודקשן, ניתנת לתחזוקה ויציבה – עדיין דורשים ידע הנדסי אמיתי.״
אדי אוסמני (Addy Osmani), ראש תחום חוויית המפתחים ב-Chrome בגוגל, מתאר את בעיית ה-70 אחוז.
והנתונים תומכים בזה. דו״ח אבטחת הקוד של Veracode לשנת 2025 מצא ש-45 אחוז מדגימות הקוד שנוצרו על ידי AI נכשלו בבדיקות אבטחה. וזה לא תיאורטי: פגיעות אמיתית בפרויקטים של Lovable (CVE-2025-48757) חשפה גישת קריאה וכתיבה למסד הנתונים בכ-10 אחוז מהפרויקטים שחוקר סרק, כי הקוד שנוצר עלה לאוויר בלי כללי הרשאה מתאימים.
מקור: Veracode, דו״ח אבטחת קוד GenAI לשנת 2025
בתחום הביצועים והנגישות המצב לא טוב יותר. רק כ-48 אחוז מאתרי המובייל עוברים את מדדי ה-Core Web Vitals של גוגל, וסקר של WebAIM משנת 2025 מצא כשלי נגישות שניתנים לזיהוי בכמעט 95 אחוז מהעמודים שנבדקו. כלי ה-AI משגרים חבילות JavaScript כבדות, תמונות לא ממוטבות ו-markup שמעולם לא נבדק מול אף אחד מהתקנים.
מקור: HTTP Archive, Web Almanac 2025 (Chrome UX Report)
מקור: WebAIM Million, 2025
ייצוא מ-AI מגיע לא פעם עם מפתחות API וסודות פעילים שמוטמעים ישירות בקוד ה-front-end. פתחתי בעצמי ייצואים עם מפתח מסד נתונים פעיל ששכב שם לעין כל. אל תעלו אף אחד מהפרויקטים האלה לאוויר בלי סקירת אבטחה קודם.
ויש פער אחד שחשוב לי יותר מכל השאר, כי הוא בלתי נראה עד שהתנועה שלכם פשוט לא מגיעה: לרוב מנועי החיפוש בכלל לא מסוגלים לקרוא את האתרים האלה.
ייתכן שאתר ה-AI שלכם בלתי נראה בגוגל
v0, Lovable ו-Bolt מייצרים אפליקציות עמוד יחיד (Single-Page Applications) שמרנדרות את התוכן שלהן באמצעות JavaScript בדפדפן. כאשר Googlebot, ובמיוחד סורקי AI כמו GPTBot ו-ClaudeBot, מבקשים את העמוד, הם מקבלים לרוב שלד HTML כמעט ריק.
וזו לא תיאוריה. ג׳ון מולר (John Mueller) מגוגל בחן בפומבי אתר שנבנה בווייב קודינג והצביע על כך שהתוכן שלו התקיים אך ורק ב-JavaScript.
״עמוד הבית שלכם צריך להכיל את כל מה שאנשים ובוטים צריכים כדי להבין במה עוסק האתר שלכם.״
ג׳ון מולר (John Mueller), Search Advocate בגוגל.
אתר וורדפרס שמרונדר בצד השרת (server-rendered) שולח את ה-HTML המלא כבר בבקשה הראשונה, וזה בדיוק מה שמנועי החיפוש ומנועי התשובות מבוססי ה-AI צריכים כדי לאנדקס אתכם ולצטט אתכם. אם חשוב לכם שימצאו אתכם, ושתופיעו ב-AI Overviews, הסיבה הזו לבדה מספיקה כדי לנטוש פרוטוטייפ שמרונדר בצד הלקוח. את צד הציטוט אני מכסה במדריך שלי על סכמות עבור מנועי AI.
שלוש דרכים להעביר את זה לוורדפרס
לפני שנוגעים בקוד, יש לכם החלטה לקבל. יש שלושה מסלולים אמיתיים, והמסלול הנכון תלוי בכמה מהפרויקט הוא עיצוב וכמה ממנו הוא לוגיקה של אפליקציה. כך אני חושב עליהם.
| גישה | מה מקבלים | מתי הכי מתאים |
|---|---|---|
| המרה אוטומטית (WPConvert, Lowpable) | שלד ויזואלי: ה-layout שלכם ממופה לקבצי התבנית, ואחריו עוד שעות של ניקוי ידני | אתם צריכים אתר במראה סטטי במהירות, ותתקנו בעצמכם את יכולת העריכה, המהירות והאבטחה |
| בנייה מחדש כתבנית מקורית | תבנית וורדפרס אמיתית, ניתנת לעריכה, מהירה ומאובטחת, ששומרת על העיצוב שלכם | שיווק תוכן, אתרי לקוחות, וכל דבר שצריך לתחזק ושאמור לדרג היטב בחיפוש. ברירת המחדל שלי. |
| וורדפרס Headless | וורדפרס כ-backend, וה-front-end שלכם ב-React נשאר | לוגיקת האפליקציה באמת מורכבת ושווה לשמור עליה, ויש לכם צוות שמסוגל לתחזק שתי מערכות |
כלי ההמרה האוטומטית דווקא שקופים לגבי המגבלות שלהם, אם קוראים את האותיות הקטנות. הם ממפים את ה-HTML וה-CSS המרונדרים שלכם לקבצי תבנית, ושם הם עוצרים. התיעוד שלהם עצמם מודה שלוגיקה דינמית, אימות (authentication), מסדי נתונים וטפסים אינם עוברים בהמרה. ״קליק אחד״ מייצר שלד ויזואלי, לא אתר גמור.
ברוב הפרויקטים שמגיעים אליי, בנייה מחדש כתבנית מקורית היא הבחירה הנכונה. זו יותר עבודה מראש, אבל זה המסלול היחיד שמתקן את יכולת העריכה, הביצועים, האבטחה והנראות בחיפוש בו-זמנית.
מה שכלי ההמרה מדלגים עליו בשקט
כשמישהו מגיש לי תבנית שהומרה אוטומטית ושואל למה היא ״מרגישה לא נכון״, התשובה כמעט תמיד נמצאת ברשימה הבאה. אלו החלקים שמפרידים בין שכפול סטטי לבין אתר שאפשר באמת לנהל עליו עסק.
עריכת תוכן אמיתית
ייצוא מ-AI מקבע (hardcodes) כל כותרת, כל מחיר וכל פסקה ישירות ב-markup. הלקוח שלכם לא יכול לשנות אפילו מילה אחת בלי לערוך קוד. בוורדפרס בפרודקשן, אותו תוכן הופך לשדות ובלוקים שניתנים לעריכה.
<?php
// AI export: hardcoded, uneditable, and unescaped
// <h1>Launch faster with Acme</h1>
// Production WordPress: editable in the CMS, escaped on output
$headline = get_field('hero_headline'); // a field the client can edit
?>
<h1><?php echo esc_html($headline); ?></h1>
אותה שורה מתקנת שתי בעיות בבת אחת: התוכן הופך לניתן לעריכה, והפלט הופך למאובטח עם escaping.
מידול תוכן (Content Modeling)
כלי ה-AI משכפלים קומפוננטת כרטיס עשר פעמים על ידי העתקה של ה-markup. בוורדפרס, כל דבר שחוזר על עצמו (אנשי צוות, המלצות, פריטי תיק עבודות) הופך ל-Custom Post Type עם שדות ולולאת שאילתה (query loop). מוסיפים אחד מלוח הבקרה, והוא מופיע בכל מקום, מעוצב ועקבי.
ביצועים ואבטחה
הייצוא משגר סביבת ריצה (runtime) שלמה של פריימוורק פרונט-אנד רק כדי לרנדר טקסט שאמור להיות HTML פשוט. חלק מהעבודה הוא להוריד את המשקל הזה, למטב תמונות ולטעון (enqueue) רק את מה שהעמוד באמת צריך, אותה עבודה שאני מתאר במדריך שלי על Core Web Vitals.
גם אבטחה היא קו אדום. קוד AI כמעט אף פעם לא מבצע escaping לפלט, לא מאמת nonces ולא בודק הרשאות משתמש (capabilities). בנייה מחדש בדרך של וורדפרס היא הדרך לסגור את החורים שמחקרי האבטחה ממשיכים למצוא, והיא משתלבת עם הקשחת וורדפרס כמו שצריך.
Backend וטפסים
אם הפרוטוטייפ שלכם השתמש בשירות כמו Supabase להתחברות או לנתונים, שום דבר מזה לא שורד המרת תבנית. האימות הופך למשתמשים והרשאות של וורדפרס, טופס יצירת הקשר הופך למנגנון אמיתי עם הגנה מפני ספאם, ונתוני האפליקציה עוברים למסד הנתונים של וורדפרס או ל-API כמו שצריך. זו העבודה שכל כלי המרה מתחמק ממנה.
איך אני מבצע את ההמרה בפועל
השינוי התפיסתי שגורם לכל זה להתחבר הוא פשוט: שומרים על העיצוב, לא על הקוד. הפלט של ה-AI הוא רפרנס איכותי, לא בסיס קוד שצריך לשמר. זו אותה משמעת שאני מיישם כשאני הופך עיצוב Figma לוורדפרס. הנה התהליך המלא שאני מריץ, מא' עד ת'.
- בדקו את הייצוא והפרידו בין העיצוב ללוגיקה. צילומי המסך, ה-layout וה-CSS שווים שמירה. סביבת הריצה של React והתוכן המקובע (hardcoded) לא.
- הקימו תבנית נקייה (בדרך כלל תבנית בלוקים) על התקנת וורדפרס מקומית.
- בנו מחדש את ה-markup כתבניות אמיתיות: header, footer ותבניות עמוד באמצעות template tags של וורדפרס.
- בנו מודל לתוכן עם ACF, סקשן אחר סקשן, כך שהלקוח יוכל לערוך הכל (פירוט בהמשך).
- הפכו כל דבר שחוזר על עצמו (פיצ׳רים, המלצות, אנשי צוות, לוגואים) ל-Custom Post Type עם שדות משלו ולולאת שאילתה, כך שהוספת אחד מלוח הבקרה מוסיפה אותו בכל מקום.
- חברו את התבניות לשדות ובצעו escaping לכל ערך בפלט.
- העבירו את ה-CSS לתוך התבנית והיפטרו מסביבת הריצה של ה-SPA. אם הייצוא בנוי עם Tailwind (מה שנכון לגבי v0, Lovable ו-Bolt), הגדירו אותו כמו שצריך בתבנית במקום לטעון את גרסת ה-CDN.
- הריצו מעבר ביצועים: גדלי תמונות, טעינה עצלה (lazy loading), caching, CSS קריטי, Core Web Vitals.
- הריצו מעבר אבטחה: escaping לפלט, הוספת nonces לטפסים, בדיקת הרשאות, והוצאת כל מפתח API שדלף מה-front-end.
- בנו מחדש את חלקי ה-backend שהייצוא זרק: התחברויות הופכות למשתמשים והרשאות של וורדפרס, טפסים הופכים למנגנון אמיתי עם הגנה מפני ספאם, ונתוני האפליקציה עוברים למסד הנתונים של וורדפרס או ל-API כמו שצריך.
- הוסיפו את שכבת ה-SEO שלפרוטוטייפ מעולם לא הייתה: HTML מרונדר בצד השרת, מטא-דאטה וסכמות.
- בצעו QA מול העיצוב המקורי במכשירים אמיתיים, ואז מסרו בסיס קוד מתועד וניתן לתחזוקה.
איך הופכים כל סקשן לניתן לעריכה עם ACF
זה השלב שמפריד בין אתר אמיתי לשכפול סטטי, וזה השלב שכל כלי המרה מדלג עליו. אני עובר על העיצוב סקשן אחר סקשן, hero, פיצ׳רים, תמחור, המלצות, שאלות נפוצות, footer, ובונה קבוצת שדות (field group) של ACF לכל אחד, כך ששום דבר לא נשאר מקובע ובעלי האתר יכולים לשנות הכל מלוח הבקרה:
- כותרות, כותרות משנה וטקסט גוף
- כפתורים והקישורים שלהם
- אייקונים, כבורר אייקונים או כשדה SVG או תמונה הניתן לעריכה
- תמונות ותמונות רקע, עם הגדלים הנכונים וטקסט alt אמיתי
- מספרים, מחירים, תגיות ותוויות
- סדר הסקשנים וההצגה שלהם, במקומות שבהם זה הגיוני
והתוצאה: ה-hero, טבלת התמחור, השאלות הנפוצות, כל בלוק בעמוד ניתן לעריכה בוורדפרס, בדיוק מה שהייצוא מ-AI הפך לבלתי אפשרי. זה מה שמאפשר ללקוח לנהל את האתר בלי להתקשר למפתח על כל שינוי של מילה.
כל סקשן הופך לקבוצת שדות (field group) משלו ב-ACF, כך שהלקוח עורך את כל העמוד (טקסט, כפתורים, אייקונים ותמונות) מלוח הבקרה.
זה מורכב יותר מלזרוק קובץ ZIP לתוך כלי המרה. אבל זה גם ההבדל בין אתר שנראה כמו הפרוטוטייפ לבין אתר שמתנהג כמו מוצר אמיתי: ניתן לעריכה, מהיר, מאובטח ונראה בחיפוש. אותם 30 האחוזים האחרונים הם כל העבודה, והם החלק שבשבילו קוראים לי.
שאלות נפוצות
השאלות שהכי שואלים אותי כשפרויקט שנבנה בווייב קודינג צריך בית אמיתי.
סיכום
כלי בניית אפליקציות מבוסס AI נותן לכם פרוטוטייפ שנראה מצוין, וגם תחושה מוטעית שהחלק הקשה כבר מאחוריכם. העיצוב הוא 70 האחוזים הקלים. יכולת עריכה, ביצועים, אבטחה ונראות בחיפוש הם 30 האחוזים שמכריעים אם הדבר הזה הוא אתר אמיתי או צילום מסך יפה.
המרה של v0, Lovable או Bolt לוורדפרס בדרך הנכונה אינה עניין של להעביר את הייצוא דרך איזה כלי. מדובר בשמירה על העיצוב ובבנייה מחדש של כל מה שמתחתיו כאתר וורדפרס אמיתי, מרונדר בצד השרת, ניתן לעריכה ומאובטח. זו העבודה, וזו הסיבה שפרוטוטייפ ואתר בפרודקשן אינם אותו הדבר.
