מסמך הסבר טכני

SEO, Pre-rendering ובניית האתר מחדש

הסבר מקיף בעברית — מה זה, למה זה חשוב, ואיך זה משפיע על האתר שלך

נכתב במאי 2026 · עבור Plan-B Systems · אורך משוער: 20-25 דקות קריאה

סקירת הקוד שנבנה — תוצאות

מה קרה פה? Opus בנה את ה-Next.js migration. אחרי שה-build היה מוכן, 4 סוכני בדיקה (Claude Sonnet) בדקו את הקוד בארבעה ממדים שונים — ארכיטקטורה, SEO, ביצועים ואבטחה. Opus קרא את כל הדוחות וסינתז את הממצאים.

שורת תחתית

Build נקי — אבל לא ready for production. האתר נבנה בהצלחה ועובד, אבל יש בעיות שמחייבות תיקון לפני שפותחים לציבור. חלקן יגרמו לנזק SEO מיידי אם ה-deploy יקרה עכשיו.

קבצים נסקרו

בעיות קריטיות

אזהרות

דפים pre-built

6 הבעיות הקריטיות

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

חוסמות deploy

קריטי SEO

Canonical URL לכל דף מצביע לדף הבית

app/[locale]/layout.tsx:45 — canonical: locale === 'he' ? '/' : '/en'

לכל דף יש תגית HTML שאומרת לגוגל "הדף הראשי שלי הוא כאן". כרגע כל דף — יהיה זה /about, /cybersecurity, /contact — אומר לגוגל "הדף הראשי שלי הוא הדף הבית".

מה גוגל תבין? שכל הדפים הם העתקים של הדף הבית. היא תוציא אותם מהאינדקס ולא תציג אותם בתוצאות חיפוש.

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

קריטי SEO

hreflang לכל דף מצביע לדף הבית

app/[locale]/layout.tsx:47-50 — languages: { he: '/', en: '/en' }

hreflang הוא תגית שמסמנת לגוגל "לדף הזה יש גרסה בעברית וגרסה באנגלית". כרגע כל דף מכריז שהגרסה האנגלית שלו היא /en (הדף הבית) — במקום /en/about, /en/cybersecurity וכו'.

גוגל תבין שכל הגרסאות האנגליות של כל הדפים הן אותו דף אחד. הגרסה האנגלית של האתר תיפגע לחלוטין.

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

קריטי אבטחה

מפתח web3forms חשוף בקוד הלקוח

app/[locale]/contact/page.tsx:64 — access_key: '7205d8bf-d394-4ef9-a396-84ddf487c561'

טופס יצירת הקשר שלך שולח מיילים דרך שירות שנקרא web3forms. המפתח שמאמת שה-form שייך לך מוטמע בתוך הקוד שנשלח לכל דפדפן. כל מי שיפתח את DevTools יוכל לראות אותו.

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

השלכה עסקית: אפשרות לפגוע בתיבת הדואר של העסק ובמוניטין הדומיין. תיקון: 30 דקות עבודה.

באגים חזותיים / UX

קריטי ארכיטקטורה

תפריט ניווט ופוטר מוצגים פעמיים ב-3 דפים

components/CategoryOverviewTemplate.tsx:27 + components/LegalDocumentPage.tsx:36

הדפים /infrastructure-cloud, /implementation-consulting ו-/terms מציגים שני Navbars זה מתחת לזה, שני Footers, ואת ה-NeuralCanvas animation פעמיים. האתר נראה שבור.

הסיבה: קומפוננטות מסוימות עוטפות עצמן ב-PageLayout פעם שנייה, למרות ש-layout.tsx כבר מוסיף את ה-PageLayout לכל דף.

השלכה עסקית: לקוח שנכנס לדפי "תשתיות" או "תנאי שימוש" רואה עיצוב שבור. פוגע באמינות.

קריטי ביצועים

פונט Heebo לא נטען — האתר רץ על פונט מערכת

app/theme.css:48 — --font-sans: 'Heebo', 'Inter', system-ui — אבל אין next/font/google

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

לגולשים בנייד ובווינדוס — האתר ייראה גנרי ולא מעוצב.

השלכה עסקית: עיצוב בינוני שפוגע ברושם הראשוני. תיקון: 20 דקות.

קריטי ביצועים

רכיב Voice Agent (40KB) נטען בכל דפי השירותים

components/ServiceDetailClient.tsx:10 — import VoiceAgentEmbed (static)

ה-Voice Agent (הרכיב שמאפשר שיחה קולית עם AI) הוא קובץ ענק שמכיל WebSocket, עיבוד שמע, ותקשורת עם ה-API. הוא נטען בכל דפי השירותים — DR, Cybersecurity, Infrastructure — גם אם הוא לא מוצג שם.

המשמעות: 40KB+ מיותרים לכל ביקור בכל דף שירות (למעט /chatbots שבו הוא באמת צריך).

השלכה עסקית: דפים נטענים לאט יותר מהצורך. תיקון: 5 דקות (הוספת dynamic import).

6 בעיות נוספות — לא חוסמות אבל חשובות

אזהרה SEO

JSON-LD (מידע מובנה לגוגל) לא הועבר לגרסה החדשה

lib/site.ts — buildPageSchema() קיים אבל לא נקרא מאף מקום

האתר הישן ייצא לגוגל מידע מובנה (Schema.org) שמסביר לגוגל "זו חברת IT, זה כתובת המשרד, זה מספר הטלפון". זה מה שמאפשר ל-Google לפעמים להציג תוצאות עשירות — שעות פתיחה, דירוגים וכו'. בגרסה החדשה — הפונקציה קיימת אבל לא מופעלת.

השלכה עסקית: פחות "עשירות" בתוצאות גוגל. ירידה בסמכות האתר בעיני גוגל.

אזהרה אבטחה

CSP nonce — הגנת אבטחה שהוכנה אבל לא הופעלה

middleware.ts — nonce נוצר ומוגדר ב-header, אבל לא מוזן לאף script

הצוות הכין תשתית להגנה מתקדמת מפני הזרקת קוד זדוני (XSS). ה-nonce הוא קוד חד-פעמי שמסמן "הסקריפט הזה מאושר". הבעיה: הכינו את ה-nonce אבל לא שמו אותו על אף סקריפט. התוצאה: הגנה שמוגדרת אבל לא ממש עובדת.

השלכה עסקית: הגנת CSP פחות אפקטיבית ממה שהיא יכולה להיות.

אזהרה ביצועים

13 דפים מסומנים כ-"client-only" ללא צורך אמיתי

about/page.tsx, ai-automation/page.tsx, cybersecurity/page.tsx ועוד 10

ב-Next.js יש הבדל בין דפים שמוכנים מראש בשרת (מהיר, SEO טוב) לדפים שנבנים בדפדפן (איטי יותר). 13 דפים מסומנים כ"דפדפן בלבד" רק בגלל שיש בהם אנימציות קטנות. המשמעות: גוגל ומשתמשים רואים את הדף מאוחר יותר ממה שצריך.

השלכה עסקית: זמן טעינה גבוה יותר, LCP (מדד מהירות גוגל) גרוע יותר.

אזהרה ארכיטקטורה

5 דפים ישנים עדיין עם עיצוב שונה

ai-automation/integrations, rag-knowledge-systems, cybersecurity/siem-soc, compliance-privacy, digital-transformation

5 דפים (AIIntegration, LLMExpertise, SIEMSolutions, PrivacyCompliance, Transformation) לא עברו המרה מלאה לעיצוב החדש. הם עדיין משתמשים בצבעי slate (slate-900, slate-950) של ה-Vite הישן, ולא בטוקני העיצוב של ה-design system החדש.

השלכה עסקית: חוסר עקביות עיצובית. לא חוסם deploy.

אזהרה אבטחה

5 security headers חסרים

middleware.ts — חסרים Permissions-Policy, Referrer-Policy, HSTS, X-Content-Type-Options, X-Permitted-Cross-Domain-Policies

האתר הישן הגדיר 5 headers של אבטחה שמגינים על הדפדפן מפני מגוון התקפות. ב-Vercel חלקם נוצרים אוטומטית, אבל לא כולם. תיקון: 10 דקות, שורות ספורות ב-middleware.ts.

השלכה עסקית: חשיפה חלקית במצב staging ולא-Vercel. לא קריטי לפרודקשן בלבד.

אזהרה ארכיטקטורה

type cast `as unknown as` מסתיר חוסר תאימות בקוד

app/[locale]/page.tsx:240 — homepageServices as unknown as {...}[]

בדף הבית, רכיב ServicePuzzleGrid מקבל נתונים עם קסטינג מאולץ — שיטה לומר לקומפיילר "תאמין לי, זה עובד". זה מסתיר חוסר תאימות אמיתי בין המבנה של הנתונים. אין crash בפועל אבל זה code smell שיקשה תחזוקה.

השלכה עסקית: כשינויים יבוצעו ב-ServicePuzzleGrid, יתכן crash שיהיה קשה לאתר.

הדוחות המקוריים (4 ממדים)

כל אחד מ-4 סוכני ה-Sonnet כתב דוח מפורט. ניתן לקרוא כל אחד בנפרד:

REVIEW-SUMMARY.md — סינתזה של Opus architecture.md — ארכיטקטורה seo.md — SEO ו-metadata performance.md — ביצועים ו-bundle security.md — אבטחה

מה השלב הבא?

אופוס יכול לתקן אוטונומית את רוב הבעיות (~1.5 שעות): כפל ה-PageLayout, הפונטים, ה-VoiceAgent, ה-security headers, ועוד. הדברים שדורשים החלטה שלך מפורטים בלשונית הבאה.

מה אתה צריך להחליט

אופוס יכול לתקן את רוב הבעיות אוטומטית ובלי שאלות. אבל יש 6 החלטות ארכיטקטוניות שהסמכות לגביהן היא שלך — כי כל אחת היא החלטה על כיוון, לא רק תיקון באג.

מה אופוס יכול לתקן ללא שאלות (Track A — ~1.5 שעות)

הסרת PageLayout הכפול מ-3 הקומפוננטות
הוספת next/font/google עם Heebo + Inter
עטיפת VoiceAgentEmbed ב-dynamic import
הוספת 5 security headers חסרים
תיקוני setTimeout cleanup קטנים
מחיקת dead code (StatsSection, AboutDraftPage, ui/* שלא בשימוש)
תיקון useFlowingHighlight עם useReducedMotion() reactive

ה-6 החלטות הבאות הן Track B — הדברים שדורשים אותך:

Metadata ייחודי לכל דף — איך לתקן?

כרגע כל דף מציג אותו title, description וcanonical — כמו הדף הבית. לפי הדוח, זה רגרסיה SEO. השאלה: איך לתקן את זה?

אפשרות A

לפצל כל דף ל-Server + Client (כמו ServiceDetailPage)

+ תיקון SEO מיידי + דפוס נקי + canonical ו-hreflang יתוקנו

- עבודה של ~3 שעות, לכל דף נפרד

אפשרות B

להשאיר ולתקן רק אחרי שה-i18n extraction יסתיים

+ פחות שינויים עכשיו, אחד פחות משימה

- ה-SEO regression נשאר ער עד אז — אם deploy מוקדם, גוגל תראה דופליקטים

המלצת Opus: אפשרות A — לתקן לפני כל deploy ציבורי. זו הבעיה הכי קריטית ב-SEO וכדאי לסגור אותה ב-Track B הקרוב.

JSON-LD (מידע מובנה) — איך להחזיר?

האתר הישן ייצא לגוגל Schema.org עשיר — פרטי חברה, breadcrumbs, ועוד. הפונקציה buildPageSchema() כבר קיימת בגרסה החדשה, רק צריך לחבר אותה. איך?

אפשרות A

בlayout בלבד — Organization + WebSite ברמת האתר

+ פשוט, תיקון ב-15 דקות

- פחות עשיר לדפים פנימיים, אין breadcrumbs ספציפיים לדף

אפשרות B

Per-page — Organization + WebPage + BreadcrumbList לכל דף, ProfessionalService לדף הבית

+ בדיוק מה שהיה בגרסה הישנה + rich snippets לכל דף

- תלוי בהחלטה 1 (צריך server component לכל דף)

המלצת Opus: אפשרות B — אבל רק אחרי שמחליטים על החלטה 1. אם בוחרים A בהחלטה 1, עדיף A גם כאן לעת עתה.

מפתח web3forms — איך לתקן את הדליפה?

המפתח של טופס יצירת הקשר חשוף בקוד. כיצד להגן עליו?

אפשרות A

API route בצד השרת (app/api/contact/route.ts) שמסתיר את המפתח

+ ~30 דקות עבודה + המפתח נשמר ב-.env ולא בקוד + הפתרון הנכון

- דורש הוספת endpoint חדש

אפשרות B

לעבור לספק אחר (Formspree, Resend, custom)

+ הזדמנות לשפר את כל תשתית המייל

- שעה+ עבודה + שינוי ספק באמצע migration

אפשרות C

להשאיר כפי שהוא + rate-limiting ב-Cloudflare

+ מהיר לביצוע

- פחות בטוח, המפתח עדיין חשוף, מסתמך על Cloudflare

המלצת Opus: אפשרות A — זה ה-fix הנכון ולוקח חצי שעה. לא צריך להחליף ספק.

CSP nonce — איך להפעיל את ההגנה?

ה-nonce הוכן אבל לא מוזן לאף script. ה-CSP guard הוא כרגע קוסמטי. איך לגרום לו לעבוד?

אפשרות A

Server Component שקורא את x-nonce מה-headers ומעביר ל-<Script> ב-layout

+ ~30 דקות + ה-CSP עובד בפועל + הגנה אמיתית

- דורש שינוי ב-layout

אפשרות B

לוותר על strict-dynamic ולהסתפק ב-https: allowlist

+ 5 דקות שינוי

- פחות בטוח — כל סקריפט מ-https יכול לרוץ

המלצת Opus: אפשרות A — 30 דקות בלבד, ומשלים את ההגנה שכבר הוכנה.

5 דפי legacy — להאחיד עיצוב?

AIIntegration, LLMExpertise, SIEMSolutions, PrivacyCompliance, Transformation — 5 דפים שעדיין נראים שונה מכל שאר האתר. האם לאחד אותם?

אפשרות A

להשאיר כפי שהם, לא לגעת

+ לא חוסם deploy + חוסך זמן עכשיו

- חוסר עקביות עיצובית. גולש שמסתכל על כמה דפים ירגיש שינוי

אפשרות B

להעביר ל-design system אחיד — ~5-7 שעות עבודה

+ אחידות מלאה + ניקוי קוד legacy

- זמן משמעותי, ריסק של רגרסיות ב-5 דפים

המלצת Opus: אפשרות A לעת עתה — לא חוסם deploy. להוסיף כפרויקט נפרד אחרי שהכל יציב.

i18n extraction — אסטרטגיה

יש 877 מחרוזות עבריות שצריכות להיחלץ מהקוד ולעבור תרגום לאנגלית. איך לגשת לזה?

אפשרות A

Opus מחלץ הכל אוטונומית, תרגום אנגלית ע"י ML, תעביר על זה בסוף

+ הכי מהיר — session אחד

- סיכון לאיכות תרגום, קשה לעצור באמצע אם משהו לא נכון

אפשרות B

Opus מחלץ sample (דף הבית), מבסס pattern, אתה מאשר, ואז bulk

+ שליטה על האיכות + אפשר לתקן כיוון לפני 877 מחרוזות

- דורש session נוסף להסכמה

אפשרות C

לדחות — לשלוח גרסה עברית בלבד עכשיו

+ לא עוצר deploy + הכי פשוט

- הגרסה האנגלית לא מתקדמת, לקוחות בינלאומיים לא יכולים לגלוש

המלצת Opus: אפשרות B — האיזון הנכון בין מהירות לאיכות. גם ה-NEXT-STEPS.md מציין את Phase 2 כ-i18n extraction.

סיכום — מה עכשיו?

אפשר לאשר את הכל בפעם אחת (Track A אוטומטי + התחלה של Track B) או לאשר רק Track A ולתת לך זמן לחשוב על ה-6 החלטות. אין לחץ — Track A לבד כבר ייצר שיפור גדול.

1. מבוא — על מה אנחנו מדברים בכלל?

שאלת שלוש שאלות חשובות:

האם כדאי לבנות את האתר מחדש בטכנולוגיה אחרת?
האם SEO דורש Node.js או Next.js?
איך מוסיפים תמיכה בעברית ואנגלית?

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

תקציר המסקנות (לעצלנים)

1. אין צורך לבנות את האתר מחדש. הסטאק הנוכחי שלך מודרני ומצוין.

2. SEO לא דורש Node.js או Next.js. יש פתרון פשוט בהרבה שנקרא pre-rendering.

3. תוספת עברית/אנגלית היא 7-9 שעות עבודה ממוקדת על הסטאק הקיים.

4. הוספת pre-rendering היא 2-3 שעות נוספות ופותרת 95% מבעיות ה-SEO.

5. סה"כ ~10-12 שעות עבודה במקום rewrite של 60-80 שעות לסטאק חדש.

2. איך אתר באינטרנט עובד? (הבסיס)

לפני שנכנסים ל-SEO, חשוב להבין מה קורה כשמישהו פותח אתר. נחלק את התהליך לשלבים:

משתמש מקליד כתובת

←

הדפדפן שולח בקשה לשרת

←

השרת מחזיר HTML

←

הדפדפן מצייר את הדף

זה התהליך הבסיסי. בשנות ה-90 ובתחילת שנות ה-2000, ה-HTML שהשרת היה מחזיר היה מלא ומוכן — עם כל הטקסט, התמונות והקישורים. הדפדפן רק היה צריך "לצייר" אותו.

אבל אז הגיע JavaScript ושינה הכל

JavaScript זאת שפת תכנות שרצה בתוך הדפדפן של המשתמש. במקום שהשרת ייצור את כל ה-HTML מראש, אפשר לשלוח HTML חלקי, ולתת ל-JavaScript להשלים את שאר התוכן בזמן ריצה.

זה פתח אפשרויות מטורפות:

אנימציות חלקות
אינטראקציות בלי טעינה מחדש של דף (כמו Gmail או Facebook)
חוויית משתמש כמו אפליקציה, לא כמו אתר

אבל זה גם יצר בעיה חדשה — שאליה נגיע בעוד רגע.

שלוש גישות לבניית אתר

שיטה	איך זה עובד?	דוגמאות
אתר סטטי קלאסי	השרת מחזיר HTML מלא ומוכן לכל דף	בלוג WordPress פשוט, דפי נחיתה
SPA (אפליקציית עמוד יחיד)	השרת מחזיר HTML ריק + JavaScript. ה-JS מצייר הכל	Gmail, Facebook, האתר שלך כרגע
SSR (רינדור בצד השרת)	השרת מריץ את ה-JS בעצמו ומחזיר HTML מוכן	אתרים שנבנו עם Next.js, Nuxt

3. מה זה SEO ולמה זה קריטי לעסק שלך?

SEO זה ראשי תיבות של Search Engine Optimization — אופטימיזציה למנועי חיפוש. בעברית פשוטה: הפעולות שאנחנו עושים כדי שהאתר שלנו יופיע גבוה בתוצאות החיפוש של גוגל.

איך גוגל בכלל יודעת מה יש באתר שלך?

גוגל מפעילה תוכנה שנקראת crawler (זוחל) או spider (עכביש). מה היא עושה?

מבקרת בכל אתר באינטרנט, כל הזמן
קוראת את כל התוכן בכל דף
מבינה על מה הדף מדבר
שומרת את המידע במאגר ענק שנקרא אינדקס (Index)

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

מה גוגל מודדת בכל דף?

Title — כותרת הדף (מה שמופיע בלשונית הדפדפן)
Meta description — תיאור קצר של הדף (מופיע מתחת לכותרת בתוצאות)
תוכן הטקסט — כל הטקסט שיש בדף
היררכיה של כותרות — H1, H2, H3...
קישורים פנימיים וחיצוניים
זמן טעינה — דף איטי = ידורג נמוך
חוויית משתמש — האם הדף עובד טוב גם בנייד
Schema markup — מידע מובנה בפורמט שגוגל מבינה (יש לך כבר את זה!)

חדשות טובות

האתר שלך כבר עושה הרבה מהדברים האלה נכון: יש PageSEO component מסודר, schema.org markup, sitemap.xml, robots.txt, ו-Open Graph tags. הבעיה היחידה היא שהמידע הזה ב-JavaScript ולא ב-HTML הראשוני — וזה מה שננסה לתקן.

4. הבעיה: למה אתרי React כמו שלך פגיעים

האתר שלך נבנה ב-React עם Vite. זאת ארכיטקטורת SPA. בואי נראה בפועל מה השרת שלך מחזיר כשמישהו מבקש את הדף הבית:

<!DOCTYPE html>
<html lang="he" dir="rtl">
<head>
  <meta charset="UTF-8">
  <title>Plan-B Systems</title>
</head>
<body>
  <div id="root"></div>        ← קופסה ריקה!
  <script src="/main.js"></script>
</body>
</html>

שים לב לשתי נקודות קריטיות:

<div id="root"></div> — הקופסה הזאת ריקה לחלוטין. אין שם תוכן.
<script src="/main.js"></script> — הקובץ הזה הוא ה-JavaScript של React. רק כשהוא יורד, מתפענח, ורץ — הוא ייצור את כל התוכן של האתר וישים אותו בתוך ה-div הריק.

מה קורה אצל משתמש רגיל?

דפדפן מבקש את האתר

←

מקבל HTML ריק (50ms)

←

מוריד JS (300ms)

←

מריץ JS (500ms)

←

דף מוכן!

סה"כ: כ-850ms עד שהדף מוכן. למשתמש זה נראה כמו רגע — ב-200ms הוא רואה אנימציה של טעינה, וב-850ms הכל קופץ. זה מהיר מספיק.

אבל מה קורה אצל הרובוט של פייסבוק?

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

5. שלושת סוגי הרובוטים שמבקרים באתר

חשוב להבין שלא כל הרובוטים זהים. בואי נחלק אותם לשלוש קבוצות:

קבוצה א' מנועי חיפוש מרכזיים

גוגל ו-Bing מסוגלים להריץ JavaScript. כשהרובוט שלהם מגיע לאתר שלך:

מקבל את ה-HTML הריק
מוריד את ה-JS
מריץ אותו (יש להם מעין דפדפן וירטואלי בשרתים)
מחכה כמה שניות שהדף יתייצב
קורא את התוכן הסופי

אבל יש כוכבית

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

בנוסף, יש "תור" של דפים לרינדור — לפעמים גוגל רואה את ה-HTML הריק קודם, מאנדקסת אותו ככה, ורק אחרי ימים-שבועות חוזרת לרנדר. זה נקרא Two-pass indexing.

קבוצה ב' רשתות חברתיות — לא מריצים JS בכלל

פייסבוק, וואטסאפ, לינקדאין, טוויטר/X, טלגרם, סלאק, דיסקורד — כולם משתמשים ברובוטים שונים שנקראים scrapers. הרובוטים האלה בכוונה לא מריצים JavaScript:

זה בטוח יותר — JS עלול להכיל קוד זדוני
זה מהיר יותר — הם צריכים לעבד מיליארדי לינקים ביום
זה זול יותר — הרצת JS דורשת הרבה משאבים

הם פשוט מורידים את ה-HTML הראשוני, מחפשים בו את ה-meta tags, ובונים מהם תצוגה מקדימה.

קבוצה ג' מנועי חיפוש קטנים ו-AI crawlers

DuckDuckGo, Yandex (רוסי), Baidu (סיני), Naver (קוריאני) — תמיכה חלקית או לא קיימת ב-JS.

AI crawlers כמו GPTBot של OpenAI, ClaudeBot, PerplexityBot — חלקם מריצים JS, חלקם לא. בעידן שבו אנשים שואלים את ChatGPT ו-Perplexity במקום לחפש בגוגל, זה הופך להיות קריטי יותר ויותר.

6. הבעיה הכי מוחשית: שיתוף בוואטסאפ

זה התרחיש שיגרום לך הכי הרבה כאב, אז בואי נדגים אותו בפועל:

תרחיש: לקוח פוטנציאלי משתף קישור לאתר שלך בקבוצת וואטסאפ של מנהלים

בלי pre-rendering — מה הם רואים:

תמונה גנרית/ברירת מחדל

planbdev.net

עם pre-rendering — מה הם רואים:

Plan-B Systems

פתרונות AI ואבטחת מידע לארגונים

בית התוכנה שמוביל את הטרנספורמציה הדיגיטלית של ארגונים בישראל...

planbdev.net

ההבדל הוא תהומי. בתרחיש הראשון, הלקוח כנראה לא יקליק. בתרחיש השני, יש לך הזדמנות.

וזה לא רק וואטסאפ. אותו דבר קורה ב:

שיתוף בלינקדאין (קריטי לעסק B2B כמו שלך!)
שיתוף בפייסבוק
שיתוף בטוויטר/X
שליחת לינק במייל (Outlook, Gmail מציגים תצוגה מקדימה)
שליחת לינק בסלאק או דיסקורד

7. מה זה Pre-rendering ואיך זה פותר הכל?

Pre-rendering, בעברית: "רינדור מראש", זאת טכניקה שבה אנחנו מצלמים את הדפים שלנו פעם אחת בזמן ה-build, ושומרים את התוצאה כקבצי HTML מלאים.

איך זה עובד צעד אחר צעד

נניח שעכשיו אתה מריץ npm run build. מה שקורה היום:

Vite מקמפל את כל קבצי TypeScript ו-React
יוצר קובץ JS אחד גדול (אופטימלי ומכווץ)
יוצר קובץ index.html אחד עם div ריק
שם את שניהם בתיקייה dist/

עם pre-rendering, נוסיפים שלב חמישי:

סקריפט נוסף מפעיל דפדפן וירטואלי (Headless Chrome)
הדפדפן הווירטואלי מבקר בכל route של האתר: /, /about, /cybersecurity, וכו'
בכל ביקור, הוא מחכה שה-React יסיים לרנדר את כל התוכן
הוא שומר את ה-HTML המלא שהתקבל
במקום קובץ index.html ריק אחד, יש לך עכשיו 55 קבצי HTML מלאים

מבנה התיקיות אחרי pre-rendering

dist/
├── index.html                                    ← דף הבית, מלא בתוכן
├── about/
│   └── index.html                                ← דף "אודות", מלא
├── ai-automation/
│   ├── index.html                                ← דף AI ראשי, מלא
│   ├── integrations/
│   │   └── index.html                            ← תת-דף, מלא
│   └── rag-knowledge-systems/
│       └── index.html                            ← תת-דף, מלא
├── cybersecurity/
│   ├── index.html
│   ├── siem-soc/index.html
│   └── compliance-privacy/index.html
└── ... (עוד 45 דפים)

מה הרובוטים רואים עכשיו?

כש-WhatsApp או פייסבוק מבקשים את הדף /cybersecurity/siem-soc, השרת מחזיר את הקובץ cybersecurity/siem-soc/index.html, שכולל את כל ה-HTML המלא:

<!DOCTYPE html>
<html lang="he" dir="rtl">
<head>
  <title>פתרונות SIEM ו-SOC | Plan-B Systems</title>
  <meta name="description" content="פלטפורמות SIEM מתקדמות...">
  <meta property="og:title" content="פתרונות SIEM ו-SOC">
  <meta property="og:image" content="...">
</head>
<body>
  <div id="root">
    <header>...</header>
    <main>
      <h1>פתרונות SIEM ו-SOC לארגונים</h1>
      <p>ניטור אבטחה 24/7...</p>
      <!-- כל התוכן של הדף, מוכן וכתוב כאן -->
    </main>
    <footer>...</footer>
  </div>
  <script src="/main.js"></script>
</body>
</html>

מה עם המשתמשים האמיתיים?

גם הם מרוויחים. הדפדפן שלהם:

מקבל את ה-HTML המלא
מצייר אותו מיד (אין צריך לחכות ל-JS)
במקביל, מוריד את ה-JS ברקע
כשה-JS גמר לרוץ, הוא "תופס" את ה-HTML הקיים — תהליך שנקרא Hydration (הידרציה)
מאותו רגע, האתר אינטראקטיבי

מה זה Hydration ולמה זה חשוב

Hydration (הידרציה)

תהליך שבו ה-React "מתחבר" ל-HTML שכבר קיים בדף, בלי לצייר אותו מחדש. במקום לבנות הכל מאפס, הוא רק מוסיף את הלוגיקה (אירועי לחיצה, state management) למה שכבר נמצא שם.

בלי הידרציה, ה-React היה מוחק את כל ה-HTML שצוייר מראש ובונה אותו מחדש — מה שהיה הופך את ה-pre-rendering לחסר משמעות. אבל React מבין מתי יש HTML קיים שתואם, ופשוט "נדבק" אליו.

תרשים זרימה מסכם

ב-build time (פעם אחת):

npm run build

←

Vite בונה JS

←

דפדפן וירטואלי מבקר ב-55 דפים

←

55 קבצי HTML מוכנים

בזמן ריצה (כל ביקור):

משתמש/רובוט מבקש דף

←

CDN מחזיר HTML מוכן

←

דף מוצג מיד

←

JS נטען ברקע

8. למה לא צריך Next.js או Node.js?

זה החלק הכי חשוב להבין, כי הוא חוסך לך עבודה של חודש. בואי נשווה את שלוש הגישות שכולן פותרות את בעיית ה-SEO:

גישה	איך זה עובד	איפה ה-HTML נוצר	מתי?
SPA רגיל (היום)	JS רץ בדפדפן ובונה את הדף	בדפדפן של המשתמש	בכל ביקור
SSR (Next.js)	שרת Node.js רץ על React ויוצר HTML	בשרת בענן	בכל ביקור
SSG / Pre-rendering	HTML נוצר פעם אחת בזמן ה-build	במחשב המפתח (אצלך)	פעם אחת, ב-build

למה Next.js הוא Overkill לאתר שלך?

Next.js זאת framework מצויינת, אבל היא נבנתה לפתור בעיות שלך אין:

פיצ'ר של Next.js	מתי הוא רלוונטי	אצלך?
SSR בכל בקשה	כשהתוכן משתנה לכל משתמש (Twitter, Facebook)	לא
API routes	כשצריך backend על אותו codebase	לא
ISR (Incremental Static Regeneration)	כשיש המון תוכן שמתעדכן (אתר חדשות)	לא
Authentication מובנה	כשיש מערכת משתמשים	לא
Image optimization	תמיד שימושי	חלקי — Vite יודע גם
i18n routing מובנה	כשיש כמה שפות	כן — תועיל

מה החסרונות של Next.js בהשוואה ל-pre-rendering?

החסרונות של מעבר ל-Next.js

דורש שרת Node.js בפרודקשן — ה-pre-rendering נותן קבצים סטטיים שיכולים לרוץ על כל CDN בעולם (חינם, מהיר, אמין). Next.js דורש שרת שצריך לתחזק (או לשלם ל-Vercel/Netlify).
Re-write כמעט מאפס — צריך להמיר את כל הראוטים שלך ממבנה של react-router למבנה של Next.js. ~40-80 שעות עבודה.
שינויי מנטליות — Server Components, Server Actions, צריך להבין את ה-execution model. עקומת למידה רצינית.
תלות בספק — Next.js הכי טוב על Vercel. במקומות אחרים זה עובד, אבל פחות חלק.
חשבון על שרת — Pre-rendering = הוסטינג סטטי (חינם או 5$/חודש). Next.js = שרת (20-100$+/חודש).

מתי כן הייתי שוקל Next.js?

אם תוסיף בעתיד אזור משתמשים עם login
אם תוסיף בלוג עם הרבה תוכן דינמי שמתעדכן בלי build
אם תרצה API routes על אותו codebase
אם תרצה e-commerce עם סל קניות וצ'קאאוט

אף אחד מאלה לא רלוונטי לאתר שיווקי B2B כמו שלך.

9. ניתוח האתר שלך — האם הוא מתאים?

חקרתי את הקוד שלך כדי להעריך עד כמה הוא מתאים ל-pre-rendering. הנה מה שמצאתי:

נתונים שמדדתי

מדד	ערך	השפעה על pre-rendering
סה"כ דפים סטטיים	23 קבצי `.tsx` ב-`src/pages/`	מצוין — מספר ידוע מראש
Slugs דינמיים ב-`siteStructure.ts`	32 (קטגוריות + שירותים)	מצוין — כולם הארדקודד, ניתנים לחיזוי
סה"כ דפים אחרי build	~55 דפים	סביר ל-pre-rendering
קריאות API לתוכן	אין	מצוין — תוכן סטטי
`useEffect` שמביא תוכן	אין (יש רק לאינטראקציה)	מצוין
שימוש ב-`react-helmet-async`	כן, רכיב `PageSEO` מסודר	מצוין — meta tags כבר מוכנים
אנימציות framer-motion	הרבה (lazy load, AnimatePresence)	דורש זהירות בזמן ה-prerender
Lazy loading של דפים	כן, כולם `React.lazy`	דורש המתנה לטעינה

מסקנה: 9.5/10

האתר שלך נבנה כאילו בכוונה כדי להיות מתאים ל-pre-rendering. כל התוכן הוא סטטי, נמצא בקבצי TypeScript, ולא נדרשת קריאת API בזמן ריצה. שני הסיכונים היחידים — אנימציות ו-lazy loading — הם פתירים בקלות.

פירוט הראוטים שלך

הנה הרשימה המלאה של הדפים שייווצרו ב-pre-rendering:

דפים ראשיים (10):

/
/ai-automation
/infrastructure-cloud
/cybersecurity
/dr-bcp
/implementation-consulting
/about
/contact
/terms
/privacy
/accessibility

תתי-דפים מובנים (5):

/ai-automation/integrations
/ai-automation/rag-knowledge-systems
/cybersecurity/siem-soc
/cybersecurity/compliance-privacy
/implementation-consulting/digital-transformation

דפי שירות דינמיים (32):

נוצרים אוטומטית מ-siteStructure.ts, לפי הדפוס /:categorySlug/:serviceSlug

דפי ניסוי/draft (6):

/about-review/luxury, /about-review/human, /about-review/notes
/terms-review/future-ready, /terms-review/current-site, /terms-review/notes

(אלה כנראה לא צריכים pre-rendering — הם פנימיים)

סה"כ ל-pre-rendering: ~47 דפים ציבוריים.

10. איזה כלים יש ואיזה הכי מתאים?

יש כמה ספריות שעושות pre-rendering ל-Vite. נסקור אותן מהקלות ביותר לכבדות:

אופציה 1: vite-plugin-prerender-spa

vite-plugin-prerender-spa

2-3 שעות

איך זה עובד: מתקין plugin אחד ב-vite.config.ts, נותן רשימת routes, ובכל פעם שאתה רץ build — ה-plugin מפעיל Puppeteer ויוצר HTML לכל route.

יתרונות: פשוט, מתחבר לסטאק הקיים, אפס שינוי בקוד.

חסרונות: פחות מתוחזק, לפעמים בעיות עם dependencies חדשים.

מתאים אם: רוצים פתרון מהיר, פשוט, וקל לתחזוקה.

אופציה 2: react-snap

react-snap (post-build script)

3-4 שעות

איך זה עובד: רץ אחרי ה-build הרגיל. סקריפט npm נפרד שלוקח את התיקייה dist/ ויוצר ממנה גרסה pre-rendered.

יתרונות: בוגר, יציב, הרבה תיעוד, עובד עם כל framework.

חסרונות: פותח לא מתוחזק כבר כמה שנים, לא תומך ב-Tailwind v4 בצורה מושלמת בלי tweaks.

מתאים אם: רוצים פתרון אמין שכבר עבד באלפי פרויקטים.

אופציה 3: Vike (לשעבר vite-plugin-ssr)

Vike

8-12 שעות

איך זה עובד: מסגרת מלאה על Vite שמאפשרת SSG, SSR, או mix. דורשת קצת ארגון מחדש של הקוד (לכל route יש קובץ +Page.tsx במקום מבנה react-router רגיל).

יתרונות: חזק מאוד, מאפשר לעבור בעתיד ל-SSR אמיתי בלי rewrite, מתוחזק פעיל, מודרני.

חסרונות: דורש שינוי מבנה הראוטים, עקומת למידה.

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

אופציה 4: סקריפט מותאם אישית

סקריפט Node.js פנימי

5-8 שעות

איך זה עובד: כותבים סקריפט פשוט ב-Node.js שמשתמש ב-Puppeteer/Playwright, ניגש לכל route ב-localhost, שומר את ה-HTML לקובץ.

יתרונות: שליטה מלאה, אפס תלות בספריות צד שלישי.

חסרונות: צריך לתחזק בעצמך, מקרי קצה (anchor links, redirects, 404s).

מתאים אם: יש לכם ניסיון ב-Puppeteer.

ההמלצה הסופית שלי לאתר שלך

תהליך מומלץ

התחל עם אופציה 1 (vite-plugin-prerender-spa). אם מתעוררות בעיות, נעבור ל-אופציה 4 (סקריפט מותאם). לא הייתי הולך על Vike בשלב הזה — עקומת הלמידה לא משתלמת רק בשביל pre-rendering.

11. סיכונים ומגבלות שחייבים להכיר

שום פתרון הוא לא קסם. הנה מה שצריך לדעת מראש:

סיכון 1: אנימציות framer-motion יוצאות "תקועות"

הבעיה: כש-Puppeteer "מצלם" את הדף, האנימציות עלולות להיות באמצע. אז ה-HTML שנשמר עלול להראות אלמנטים שקופים, או באמצע התקרבות, או לא מוצגים בכלל.

הפתרון:

לזהות את ה-prerender environment (יש flag כזה ב-Puppeteer)
לבטל אנימציות "כניסה" באותו תרחיש
או: לחכות שכל האנימציות יסתיימו לפני שמצלמים (לקבוע animationComplete flag)

שעות עבודה: ~30-60 דקות.

סיכון 2: Lazy-loaded components לא נטענים בזמן

הבעיה: יש לך React.lazy על כל הדפים. זה אומר שהקוד שלהם נטען רק אחרי שה-React מתחיל. ב-pre-render, צריך לוודא שכל ה-lazy chunks ירדו ויטענו לפני הצילום.

הפתרון: Puppeteer יכול לחכות ל-networkidle או ל-selector ספציפי. רוב הכלים עושים את זה אוטומטית.

שעות עבודה: ~15-30 דקות הגדרה.

סיכון 3: זמן build ארוך יותר

הבעיה: במקום build של ~30 שניות, ייקח ~3-5 דקות (כי הדפדפן הווירטואלי צריך לבקר ב-47 דפים, כל אחד נטען 1-3 שניות).

הפתרון: זה לא באמת בעיה — build רץ פעם בכמה ימים, וגם CI/CD מסוגלים לזה.

סיכון 4: דפים שמשתנים לפי משתמש

הבעיה: אם בעתיד תוסיף דפים שמותאמים אישית (Dashboard למשתמש מחובר, מחירים לפי מטבע מקומי) — pre-rendering לא יעבוד עליהם.

הפתרון: פשוט לא לעשות pre-render לדפים האלה — להשאיר אותם כ-SPA. פשרה הגיונית.

סיכון 5: שינויי תוכן דורשים build מחדש

הבעיה: אם מתקן typo בקובץ siteStructure.ts, צריך לעשות build חדש. גוגל לא תראה את התיקון מיד.

הפתרון: זה כבר המצב היום אצלך. אין הבדל.

סיכון 6: בעיות עם cookies / localStorage

הבעיה: אם הקוד שלך קורא מ-localStorage או cookies בזמן רינדור (למשל, "הציג שפה לפי העדפה שמורה") — ב-pre-render אין כאלה!

הפתרון: לעטוף קריאות localStorage ב-typeof window !== 'undefined' ולהציג ברירת מחדל.

שעות עבודה: ~30 דקות לסקירה ותיקון.

טבלת סיכום סיכונים

סיכון	חומרה	עלות תיקון
אנימציות תקועות	בינונית	30-60 דק'
Lazy loading	נמוכה	15-30 דק'
זמן build	זניחה	0
דפים מותאמים	לא רלוונטי	0
שינויי תוכן	לא רלוונטי	0
cookies/localStorage	בינונית	30 דק'

12. עברית/אנגלית — איך זה משתלב?

זאת הייתה השאלה המקורית שלך. בואי נראה איך i18n (תמיכה בכמה שפות) ו-pre-rendering עובדים יחד.

הסטנדרט: i18next + react-i18next

זאת הספרייה הנפוצה ביותר ב-React לתרגומים. מה שהיא עושה:

במקום לכתוב טקסט קשיח ב-React (<h1>ברוכים הבאים</h1>), קוראים למפתח (<h1>{t('home.welcome')}</h1>)
שני קבצי JSON: he.json ו-en.json — בכל אחד את אותם מפתחות עם תרגום
ה-i18next בוחר את הקובץ לפי השפה הנוכחית
החלפת שפה = החלפת קובץ + רינדור מחדש של כל הטקסטים

איך זה נראה בקוד

לפני:

function Hero() {
  return (
    <section>
      <h1>פתרונות AI ואבטחת מידע</h1>
      <p>מובילים את הטרנספורמציה הדיגיטלית</p>
    </section>
  );
}

אחרי:

import { useTranslation } from 'react-i18next';

function Hero() {
  const { t } = useTranslation();
  return (
    <section>
      <h1>{t('home.hero.title')}</h1>
      <p>{t('home.hero.subtitle')}</p>
    </section>
  );
}

קובץ he.json:

{
  "home": {
    "hero": {
      "title": "פתרונות AI ואבטחת מידע",
      "subtitle": "מובילים את הטרנספורמציה הדיגיטלית"
    }
  }
}

קובץ en.json:

{
  "home": {
    "hero": {
      "title": "AI Solutions and Cybersecurity",
      "subtitle": "Leading digital transformation"
    }
  }
}

שתי גישות לראוטינג רב-שפתי

גישה א': prefix בכתובת (מומלץ ל-SEO)

planbdev.net/        ← עברית (ברירת מחדל)
planbdev.net/about   ← עברית
planbdev.net/en/     ← אנגלית
planbdev.net/en/about ← אנגלית

יתרונות: כל שפה זה URL נפרד, גוגל רואה שני אתרים עצמאיים, אפשר לשתף קישור באנגלית בלי שיקפוץ לעברית.

גישה ב': query parameter

planbdev.net/?lang=he
planbdev.net/?lang=en

חסרונות: גוגל רואה רק URL אחד, פחות טוב ל-SEO. לא מומלץ.

שילוב עם pre-rendering

אם תבחר ב-Pattern א' (URL prefix), ה-pre-rendering יצטרך לרנדר גם את הגרסה העברית וגם את האנגלית של כל דף:

dist/
├── index.html               ← עברית
├── about/index.html         ← עברית
├── en/
│   ├── index.html          ← English
│   └── about/index.html    ← English
└── ... (סה"כ ~94 קבצים: 47 עברית + 47 אנגלית)

הכלי שתבחר (vite-plugin-prerender-spa או אחר) יקבל פשוט רשימה של 94 routes במקום 47, ויעבור על כולם.

טיפים חשובים ל-i18n + pre-rendering

hreflang tags: חובה להוסיף <link rel="alternate" hreflang="en" href="..."> בכל דף, כדי שגוגל יבין שהדפים קשורים
פונט שונה לכל שפה: Heebo לעברית, Inter לאנגלית — להגדיר font-family לפי html[lang]
RTL/LTR אוטומטי: dir="rtl" בעברית, dir="ltr" באנגלית
Tailwind logical properties: במקום left-4 ו-right-4, להשתמש ב-start-4 ו-end-4 (התומכות ב-RTL/LTR אוטומטית)
חצים: ArrowLeft בעברית הופך להיות ArrowRight כי כיוון הקריאה הפוך

13. תכנית עבודה מומלצת

להלן תכנית מסודרת, לפי סדר ביצוע מומלץ:

7-9 שעות 1

תוספת תמיכה בעברית/אנגלית

התקנת react-i18next + i18next-browser-languagedetector
יצירת i18n.ts עם config
עטיפת App ב-i18next Provider
כפתור החלפת שפה ב-Navbar
dir דינמי ב-PageLayout
הגדרת ראוטינג עם prefix /en/*
שמירה ב-localStorage
חילוץ 876 מחרוזות ל-keys
תרגום ל-en.json (LLM באצווה)
תיקוני RTL→LTR (109 מקומות)
QA על כל הדפים בשתי השפות

2-3 שעות 2

הוספת pre-rendering

התקנת vite-plugin-prerender-spa
הגדרה ב-vite.config.ts עם רשימת routes
גנרציה אוטומטית של רשימת routes מ-siteStructure.ts (כל הקטגוריות + שירותים, כפול 2 לשפות)
תיקון אנימציות שנתקעות (זיהוי prerender mode)
תיקוני localStorage / window references
בדיקה ידנית של ~5 דפים — לוודא שה-HTML שנוצר כולל את כל התוכן

1-2 שעות 3

בדיקות SEO וסיום

הוספת hreflang tags לכל דף
עדכון sitemap.xml לכלול גם דפים באנגלית
בדיקה ב-Google Rich Results Test
בדיקת תצוגה מקדימה ב-Facebook Sharing Debugger
בדיקת תצוגה מקדימה ב-LinkedIn Post Inspector
הגשה מחדש ב-Google Search Console

סה"כ: ~10-14 שעות עבודה

במקום ~60-80 שעות של rewrite ל-Next.js. תקבל את אותה איכות SEO, יותר גמישות, ובמחיר הוסטינג סטטי במקום שרת.

14. שאלות נפוצות

האם הלקוחות הקיימים יראו הבדל?

כן — האתר ייטען מהר יותר. במקום לחכות 1-2 שניות לטעינת JS, הם יראו תוכן מיד (~200ms). שאר החוויה זהה.

האם יש סיכון שהאתר ייפול בזמן ה-migration?

לא משמעותי. ה-pre-rendering הוא תוספת על ה-build הקיים, לא החלפה. אם משהו לא עובד, פשוט מבטלים את ה-plugin וחוזרים למצב הנוכחי.

למה לא לעשות SSR מלא ולקבל הכל יחד?

SSR נותן רק 5% יתרון מעל pre-rendering, במחיר של עלות תחזוקה משמעותית: שרת Node.js שצריך לרוץ 24/7, deployment מורכב יותר, חשבון חודשי גדול יותר. עבור אתר שיווקי, ה-tradeoff לא משתלם.

האם יש משהו שאני כן חייב לבנות מחדש בעתיד?

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

מה לגבי AI crawlers? GPTBot ו-ClaudeBot?

חלקם מריצים JS, חלקם לא. עם pre-rendering, אתה מבטיח שכולם יקבלו את התוכן. זה הופך להיות חשוב יותר ויותר ככל שאנשים שואלים את ChatGPT במקום לחפש בגוגל.

האם זה ישפיע על מהירות ה-build ב-CI/CD?

build יקח 3-5 דקות במקום 30 שניות. עבור deploy של אתר שיווקי, זה זניח. רוב פלטפורמות ה-CI/CD נותנות מספיק זמן build.

האם Tailwind v4 תואם ל-pre-rendering?

כן, לחלוטין. Tailwind מקמפל CSS בזמן build (לא בזמן ריצה), אז ה-CSS מוכן ב-HTML הסטטי.

מה עם Voice Agent ב-Contact page? הוא אינטראקטיבי

אין בעיה. ה-pre-rendering ייצר את ה-HTML הראשוני של הדף (כולל UI), וה-JS עדיין יטען וייתן את האינטראקציה. ה-pre-rendering לא משבית JavaScript — הוא רק מוסיף HTML מוכן לפני שה-JS רץ.

צריך לעדכן את sitemap.xml?

כן, אחרי הוספת אנגלית — צריך לכלול גם את ה-URLs באנגלית, ולהוסיף תגיות xhtml:link שמקשרות בין הגרסאות.

כמה זה יעלה לי בעלויות הוסטינג?

אפס שינוי. אתה ממשיך עם אותו hosting סטטי. אם תעבור ל-Next.js — תצטרך שרת Node.js ($20-100+/חודש).

15. מילון מונחים

SEO (Search Engine Optimization)

אופטימיזציה למנועי חיפוש — שיטות שגורמות לאתר להופיע גבוה בתוצאות חיפוש.

SPA (Single Page Application)

יישום עמוד יחיד — אתר שמשתמש ב-JavaScript כדי לטעון תוכן בלי לרענן דפים. האתר שלך הוא SPA.

SSR (Server-Side Rendering)

רינדור בצד השרת — השרת מייצר HTML מלא בכל בקשה. דורש שרת Node.js.

SSG (Static Site Generation)

ייצור אתר סטטי — HTML נוצר פעם אחת בזמן ה-build. שם נרדף ל-pre-rendering בהקשר זה.

Pre-rendering

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

Hydration (הידרציה)

תהליך שבו React "תופס" HTML שכבר נמצא בדף, ומוסיף לו אינטראקטיביות בלי לצייר מחדש.

Crawler / Spider

רובוט שמבקר באתרים באינטרנט וקורא את התוכן שלהם. גוגל, פייסבוק, ChatGPT — כולם משתמשים ב-crawlers.

Headless Browser

דפדפן וירטואלי שרץ בלי GUI. משמש ל-pre-rendering, בדיקות אוטומטיות, וכו'. הכלים הנפוצים: Puppeteer ו-Playwright.

Meta tags / Open Graph

תגיות HTML שמתארות את הדף לרובוטים. Open Graph (og:) זה הסטנדרט של פייסבוק לתצוגה מקדימה.

Schema.org / JSON-LD

פורמט מובנה לתאר את התוכן של הדף לגוגל (חברה, מוצר, מאמר, וכו'). אצלך כבר מוטמע.

Hreflang

תגית HTML שמסמנת לגוגל שלאותו דף יש גרסאות בשפות שונות. קריטי ל-SEO רב-שפתי.

i18n

קיצור של internationalization (יש 18 אותיות בין ה-i ל-n). תהליך הפיכת תוכנה לתומכת בכמה שפות.

RTL / LTR

Right-To-Left (ימין לשמאל, עברית/ערבית) ו-Left-To-Right (שמאל לימין, אנגלית). משפיע על כיוון הטקסט וה-layout.

CDN (Content Delivery Network)

רשת שרתים שמפיצה את האתר שלך לפי מיקום גיאוגרפי. כל אתר סטטי שלך כנראה כבר משתמש ב-CDN.

Build

תהליך הקומפילציה של הקוד — Vite/TypeScript ממירים את הקוד שלך לקבצי JS ו-HTML מוכנים לפרודקשן.

Hydration mismatch

בעיה שקורית כשה-HTML שצוייר מראש שונה מהמה ש-React חושב שצריך להיות. פתרונה: לוודא שה-server-rendered HTML זהה לזה שיוצא בלקוח.

Vite

כלי build מודרני ומהיר לאתרי web. אצלך כבר משתמש בו.

Next.js

framework של React לאתרים בעלי SSR. דורש שרת Node.js. מתאים לאתרים מורכבים עם backend.

Astro

framework מודרני שמייצר HTML סטטי כברירת מחדל, עם "islands" של JavaScript רק היכן שצריך. מצוין לאתרי תוכן וקצת אינטראקטיביות.

16. סיכום בשורה אחת

האתר שלך מתאים מצוין ל-pre-rendering, לא צריך לבנות אותו מחדש בטכנולוגיה אחרת, ולא צריך Next.js או Node.js בשביל SEO מעולה. תכנית: קודם i18n (7-9 שעות), אחרי זה pre-rendering (2-3 שעות), ויש לך אתר שמופיע יפה בכל מקום (גוגל, וואטסאפ, לינקדאין, AI crawlers) — בלי לשנות סטאק ובלי תוספת בעלויות הוסטינג.

הצעדים הבאים

החלטה: האם להתחיל ב-i18n או ב-pre-rendering ראשון?
בחירת prefix לאנגלית: /en/ (מומלץ) או /?lang=en
בחירת כלי pre-rendering: vite-plugin-prerender-spa (מומלץ) או אחר
תכנון QA — מי יבדוק את כל 47 הדפים בשתי השפות?

סקירת הקוד שנבנה — תוצאות

6 הבעיות הקריטיות

חוסמות deploy

Canonical URL לכל דף מצביע לדף הבית

hreflang לכל דף מצביע לדף הבית

מפתח web3forms חשוף בקוד הלקוח

באגים חזותיים / UX

תפריט ניווט ופוטר מוצגים פעמיים ב-3 דפים

פונט Heebo לא נטען — האתר רץ על פונט מערכת

רכיב Voice Agent (40KB) נטען בכל דפי השירותים

6 בעיות נוספות — לא חוסמות אבל חשובות

JSON-LD (מידע מובנה לגוגל) לא הועבר לגרסה החדשה

CSP nonce — הגנת אבטחה שהוכנה אבל לא הופעלה

13 דפים מסומנים כ-"client-only" ללא צורך אמיתי

5 דפים ישנים עדיין עם עיצוב שונה

5 security headers חסרים

type cast as unknown as מסתיר חוסר תאימות בקוד

הדוחות המקוריים (4 ממדים)

מה אתה צריך להחליט

Metadata ייחודי לכל דף — איך לתקן?

JSON-LD (מידע מובנה) — איך להחזיר?

מפתח web3forms — איך לתקן את הדליפה?

CSP nonce — איך להפעיל את ההגנה?

5 דפי legacy — להאחיד עיצוב?

i18n extraction — אסטרטגיה

1. מבוא — על מה אנחנו מדברים בכלל?

2. איך אתר באינטרנט עובד? (הבסיס)

אבל אז הגיע JavaScript ושינה הכל

שלוש גישות לבניית אתר

3. מה זה SEO ולמה זה קריטי לעסק שלך?

איך גוגל בכלל יודעת מה יש באתר שלך?

מה גוגל מודדת בכל דף?

4. הבעיה: למה אתרי React כמו שלך פגיעים

מה קורה אצל משתמש רגיל?

אבל מה קורה אצל הרובוט של פייסבוק?

5. שלושת סוגי הרובוטים שמבקרים באתר

קבוצה א' מנועי חיפוש מרכזיים

קבוצה ב' רשתות חברתיות — לא מריצים JS בכלל

קבוצה ג' מנועי חיפוש קטנים ו-AI crawlers

6. הבעיה הכי מוחשית: שיתוף בוואטסאפ

תרחיש: לקוח פוטנציאלי משתף קישור לאתר שלך בקבוצת וואטסאפ של מנהלים

7. מה זה Pre-rendering ואיך זה פותר הכל?

איך זה עובד צעד אחר צעד

מבנה התיקיות אחרי pre-rendering

מה הרובוטים רואים עכשיו?

מה עם המשתמשים האמיתיים?

מה זה Hydration ולמה זה חשוב

תרשים זרימה מסכם

8. למה לא צריך Next.js או Node.js?

למה Next.js הוא Overkill לאתר שלך?

מה החסרונות של Next.js בהשוואה ל-pre-rendering?

מתי כן הייתי שוקל Next.js?

9. ניתוח האתר שלך — האם הוא מתאים?

נתונים שמדדתי

פירוט הראוטים שלך

דפים ראשיים (10):

תתי-דפים מובנים (5):

דפי שירות דינמיים (32):

דפי ניסוי/draft (6):

10. איזה כלים יש ואיזה הכי מתאים?

אופציה 1: vite-plugin-prerender-spa

vite-plugin-prerender-spa

אופציה 2: react-snap

react-snap (post-build script)

אופציה 3: Vike (לשעבר vite-plugin-ssr)

Vike

אופציה 4: סקריפט מותאם אישית

סקריפט Node.js פנימי

ההמלצה הסופית שלי לאתר שלך

11. סיכונים ומגבלות שחייבים להכיר

סיכון 1: אנימציות framer-motion יוצאות "תקועות"

סיכון 2: Lazy-loaded components לא נטענים בזמן

סיכון 3: זמן build ארוך יותר

סיכון 4: דפים שמשתנים לפי משתמש

סיכון 5: שינויי תוכן דורשים build מחדש

סיכון 6: בעיות עם cookies / localStorage

טבלת סיכום סיכונים

12. עברית/אנגלית — איך זה משתלב?

הסטנדרט: i18next + react-i18next

איך זה נראה בקוד

type cast `as unknown as` מסתיר חוסר תאימות בקוד