SEO ב-⁠Base44: מה מטופל בשבילכם, ואיפה התקרה

איך Base44 מגישה את הדפים שלכם

אפליקציית Base44 היא אפליקציית React של עמוד יחיד (single-page app): הדפדפן מוריד מעטפת HTML קטנה ו-⁠JavaScript, וה-⁠JavaScript מצייר את הדף. כשלעצמו, זה לא מתאים במיוחד למנועי חיפוש, ולכן Base44 מוסיפה שכבה בשביל הסורקים.

התיעוד של Base44 על נראות בחיפוש מסביר את זה: מכיוון שהאפליקציות רצות בדפדפן, סורק היה רואה בדרך כלל דף ריק, ולכן Base44 מגישה לסורקים גרסה מרונדרת של האפליקציה, עם תגיות המטא, הנתונים המובנים (structured data) והתוכן האמיתי של הדף בתוך ה-⁠HTML. אם דף עדיין לא רונדר, Base44 מגישה במקומו גרסה מקוצרת. אנשים שנכנסים לאפליקציה עדיין מקבלים את האפליקציה הרגילה, שמרונדרת בדפדפן.

זו יכולת שימושית באמת, ויותר ממה שהרבה בוני אפליקציות מציעים. אבל המשמעות היא גם שהאופן שבו הדפים שלכם נראים ל-⁠Google נקבע על ידי מערכת שאתם לא יכולים לראות או לכוונן.

מה Base44 מנהלת בשבילכם

באפליקציות שמפורסמות על דומיין מותאם אישית, Base44 מטפלת בדברים הבאים:

• תגיות canonical בכל דף, שמסירות פרמטרים של מעקב כמו utm_* ושומרות פרמטרים שמשנים את התוכן.
• מפת אתר בכתובת /sitemap.xml עם הדפים הציבוריים שלכם. אפשר לכבות אותה ולפרוס public/sitemap.xml משלכם, או להגיש מפת אתר דינמית מפונקציית שרת ולשלוח את הכתובת שלה ל-⁠Google Search Console (כל שליפה נספרת כקריאה לפונקציה).
• robots.txt, שמאפשר למנועי חיפוש ולסורקי AI להגיע לתוכן הציבורי.
• llms.txt, סיכום אופציונלי לסורקי AI, שמפעילים מהדף SEO & GEO.
• כותרות ותיאורים לכל דף, ומתג נראות בחיפוש לכל דף, שמוסיף noindex ומוציא את הדף ממפת האתר.
• קובץ ה-index.html שלכם, שאפשר לערוך בלשונית "Code" (הקוד) כדי להוסיף תגיות אימות וסקריפטים של צד שלישי.

Base44 תומכת גם בהפניות קבועות (301) של כתובות, כך שקישורים ישנים ממשיכים לעבוד אחרי שמעבירים דף (Apps API: דומיינים והפניות), ומריצה סריקת SEO ו-⁠GEO שמציעה תיקונים מלוח הבקרה (אופטימיזציה של SEO ו-⁠GEO).

הדרישה לדומיין מותאם אישית

Base44 אומרת במפורש שהגדרות ה-⁠SEO שלה תוכננו ונתמכות עבור אפליקציות שמפורסמות על דומיין מותאם אישית. סורקים עדיין יכולים לסרוק כתובות base44.app חינמיות, אבל לפי התיעוד הן לא מיועדות ל-⁠SEO לטווח ארוך בפרודקשן, והקבצים האוטומטיים והתצוגות המקדימות ברשתות החברתיות נבנו בשביל דומיינים מותאמים אישית.

חיבור דומיין הוא יכולת בתשלום: דף המחירים של Base44 מציג אותה ממסלול Starter ומעלה. כך שבפועל, SEO רציני ב-⁠Base44 מתחיל במסלול בתשלום ובדומיין משלכם.

איפה התקרה

רוב המגבלות הן לא באגים. זה מה שקורה כשהרינדור, המטמון (caching) והניתוב שייכים לפלטפורמה.

• הרינדור הוא קופסה שחורה. אי אפשר לבחור אילו דפים מרונדרים מראש, מתי הם מתרעננים, או מה מכילה הגרסה החלופית. אם דף מרונדר רע בשביל סורקים, הדבר היחיד שאפשר לעשות הוא לשנות את האפליקציה ולפרסם שוב.
• סורקים ואנשים רואים דברים שונים. מנועי חיפוש מקבלים את תמונת המצב המרונדרת; מבקרים מקבלים את אפליקציית ה-⁠JavaScript. כשהשתיים מתרחקות זו מזו, קשה לשים לב לזה, וקשה עוד יותר לאתר את הבעיה.
• דפים מאחורי התחברות לא נכנסים לאינדקס. דפים שדורשים התחברות לא יכולים להיכנס לאינדקס, לא ב-⁠Base44 ולא בשום מקום אחר. כדאי להשאיר את דפי השיווק והתוכן ציבוריים.
• תוכן דינמי דורש מעקפים. דפים שנוצרים מהנתונים שלכם, כמו בלוג או אינדקס עסקים, צריכים מפת אתר מפונקציית שרת, וכל שליפה של סורק צורכת הפעלה של פונקציה.
• כיבוי ה-⁠SEO הוא צעד קיצוני. Base44 מתעדת שכשמתג ה-⁠SEO הראשי כבוי, סורקים מגיעים לדף ריק, גם אם robots.txt מאפשר להם להיכנס.
• כותרות HTTP (headers), מטמון וביצועים קבועים. אי אפשר לקבוע כללי מטמון, דחיסה, כותרות אבטחה או התנהגות ב-⁠edge בשרת שמגיש את האפליקציה שלכם.

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

מה משתנה כשמריצים את השרת בעצמכם

אחרי העברה עם Unbase44, האפליקציה שלכם מוגשת מהשרת שלכם, מתוך המאגר (repository) שלכם, והגדרות ה-⁠SEO עוברות איתה. הנה מה זה אומר בפועל, כולל החלק שהוא פשרה.

השרת שלכם כותב את התגיות. לכל דף, השרת שלכם מכניס ל-⁠HTML שהוא שולח את הכותרת, התיאור, כתובת ה-⁠canonical ותגיות Open Graph ו-⁠Twitter מהגדרות ה-⁠SEO שלכם, לכל מבקר ולכל תצוגה מקדימה של קישור, לא רק לסורקים. הוא מגיש robots.txt ומפת אתר מאותן הגדרות, ומסמן אפליקציות פרטיות כ-noindex.

תוכן הדף עדיין מרונדר בדפדפן. גוף כל דף מצויר על ידי JavaScript, כמו שהיה עבור המבקרים האנושיים שלכם ב-⁠Base44. Google מרנדרת JavaScript ומכניסה דפים כאלה לאינדקס באופן שגרתי, אבל אצל סורקים אחרים זה משתנה. מה שלא עובר איתכם הוא תמונת המצב של Base44 שמיועדת לסורקים בלבד. אם HTML שמרונדר מראש במלואו חשוב לאפליקציה שלכם, אפשר להוסיף רינדור מוקדם (prerendering) או רינדור בצד השרת (server-side rendering), כי השרת והקוד שלכם. זה שינוי שעושים במאגר, עם Claude Code, ‏Cursor או מפתח.

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

רשימת SEO להעברת אפליקציה

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

1. שומרים על כתובות זהות. אותו דומיין, אותם נתיבים. אם נתיב חייב להשתנות, מוסיפים הפניה קבועה מהנתיב הישן.
2. מעבירים את הדומיין, לא את התוכן. כשאתם מוכנים, מפנים את הדומיין המותאם אישית הקיים לאפליקציה החדשה, כך שהכתובות ש-⁠Google מכירה ממשיכות לעבוד.
3. בודקים מה השרת החדש מחזיר. פותחים כמה דפים עם "view source" (הצגת מקור) ומוודאים שהכותרות, התיאורים וכתובות ה-⁠canonical נכונים.
4. נמנעים מתוכן כפול. ברגע שהאפליקציה החדשה באוויר על הדומיין שלכם, דואגים שהעותק הישן ב-⁠Base44 יפסיק להתחרות בה: מכבים בו את הנראות בחיפוש במקום לבטל את הפרסום שלו, כי הוא עדיין צריך לרוץ בזמן שהמשתמשים שלכם מתחברים בפעם הראשונה.
5. שולחים מחדש את מפת האתר ב-⁠Google Search Console, ומשתמשים ב-⁠URL Inspection (בדיקת כתובת URL) על הדפים החשובים ביותר.
6. עוקבים אחרי דוח הכיסוי (coverage) במשך כמה שבועות, כדי לזהות דפים שנופלים מהאינדקס או מחזירים שגיאה.