בינוני · 34 דק׳ קריאה · עודכן 2026-06-22

SEO לאתרי React SPA — איך לוודא שגוגל באמת מוצא אותך

Q: למה האתר שלי ב-React לא מופיע בגוגל?

הסיבה הנפוצה ביותר היא שה-HTML הראשוני שלך ריק — רק — והתוכן מוזרק אחרי שה-JS רץ. תעשה את הבדיקה: לחץ Ctrl+U (View Source) על דף הבית. אם אתה לא רואה שם את הטקסט של הדף, גם גוגל מתקשה לראות אותו. סיבות נוספות: noindex שנשאר מ-staging, robots.txt שחוסם את /assets/, או hash routing בסגנון /#/about שגוגל מתעלם ממנו.

Q: האם React 19 פותר את בעיית ה-SEO לבד?

לא לגמרי. React 19 מוסיף תמיכה native בהזרקת ו- ל- , וזה מייתר את react-helmet-async ברוב המקרים. אבל זה עדיין רץ בצד הקליינט — הבוטים שלא מריצים JS לא ירוויחו מזה. כדי שזה יעזור באמת ל-SEO, אתה עדיין צריך שכבת prerender, SSG או SSR שמוציאה את התגים האלה ל-HTML הסטטי.

SEO לאתרי React SPA ב-2026: למה גוגל, ווטסאפ ומנועי ה-AI לא רואים אותך, מתי SSR מציל ומתי prerender מספיק — עץ החלטות + קוד מוכן להעתקה

SEOReactSPAVitePrerender

למי זה מתאים: בנית אתר ב-React (Vite, CRA, Lovable, Base44, או כל סטארטר אחר), העלית אותו, חיכית חודש — ובגוגל הוא לא מופיע. או שהוא מופיע, אבל הכותרת היא "React App" והתיאור ריק. או ששלחת קישור ב-WhatsApp ולא הופיעה תצוגה מקדימה. המדריך הזה מסביר מה קורה מתחת למכסה המנוע, ומה אתה צריך לעשות בפועל — לפי סוג האתר שלך.

הבעיה האמיתית — ולמה היא לא מה שאתה חושב

ב-2026 כולם יודעים את המנטרה: ״גוגל מריץ JavaScript עכשיו, אז SPA זה בסדר״. זה נכון. ולא רלוונטי. כי הבעיה היא לא רק גוגל.

גוגל אכן מריץ JavaScript. Googlebot משתמש ב-headless Chromium עדכני, מריץ את ה-React שלך, ורואה את ה-DOM אחרי שהקומפוננטים נטענו. זה לא היה ככה ב-2015. ב-2026 זה עובד טוב. בערך.

אבל לזה יש מחיר — שנקרא Render Budget. גוגל לא מרנדר כל דף בזמן אמת. התהליך הוא דו-שלבי: קודם הוא מוריד את ה-HTML הראשוני (Initial Crawl), ואז דוחף את הדף לתור רינדור (Render Queue) שבו דפדפן headless יריץ את ה-JS. התור הזה יכול להיות שניות בודדות עד ימים שלמים, תלוי בעומס, בחשיבות האתר שלך בעיני גוגל, ובכמה משאבים נשארו במכסה הגלובלית. אם הדף שלך לוקח 8 שניות להתחיל לרנדר את הטקסט — יש סיכוי טוב שגוגל יוותר באמצע. הספים שמדווחים בקהילה: תכנן לסיים את הרינדור תוך 5 שניות, מקסימום.

והבעיה הגדולה יותר: כל השאר לא מריצים JS בכלל. Facebook (facebookexternalhit), Twitter/X (Twitterbot), LinkedIn (LinkedInBot), WhatsApp, Slack, Discord, Telegram — אף אחד מהם לא מריץ JavaScript. הם פותחים את ה-HTML הגולמי שלך, מחפשים תגי Open Graph (<meta property="og:title"> וכו׳), ומה שהם מוצאים שם הוא מה שיופיע בכרטיס התצוגה. ב-SPA רגיל ה-HTML הגולמי הוא <div id="root"></div> ריק. שום OG, שום תיאור, שום תמונה. הקישור שלך נראה שבור בכל רשת חברתית — לנצח.

ויש שחקן שלישי שצומח מהר: מנועי AI. ChatGPT (GPTBot, OAI-SearchBot), Claude (ClaudeBot, Claude-SearchBot), Perplexity (PerplexityBot) — נכון ליוני 2026, אף אחד מהבוטים האלה לא מריץ JavaScript. הם קוראים את ה-HTML הגולמי בלבד. היוצא מן הכלל הוא גוגל עצמה: Google-Extended (הבוט שמזין את Gemini ואת AI Overviews) משתמש באותה תשתית רינדור של Googlebot, כלומר הוא כן מריץ JS, בכפוף לאותו render budget. המשמעות המעשית: אתר ה-SPA שלך יכול לדרג מצוין בגוגל ובמקביל לקבל אפס ציטוטים ב-ChatGPT, ב-Claude וב-Perplexity, כי הם פשוט לא רואים את התוכן. אם אתה רוצה נוכחות במנועי תשובות, ה-HTML הראשוני חייב להכיל את התוכן. הרחבתי על איך לבנות נכון ל-AI במדריך GEO — אופטימיזציה למנועי תשובות AI.

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

js rendering budget

הצד הטכני — מה בדיוק קורה כשגוגלבוט מבקר אצלך

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

1. בקשת ה-HTML הראשונית

Googlebot שולח GET לכתובת שלך. השרת מחזיר HTML. ב-SPA טיפוסי, ה-HTML הזה נראה ככה:

<!doctype html>
<html lang="he">
  <head>
    <meta charset="UTF-8" />
    <title>Vite + React</title>
  </head>
  <body>
    <div id="root"></div>
    <script type="module" src="/assets/index-abc123.js"></script>
  </body>
</html>

זה מה שגוגל קורא ב-First Pass. הוא מחלץ מכאן קישורים, title, ו-meta, ומוסיף את הדף למסד נתונים של ״כתובות לרינדור״.

2. תור הרינדור (Render Queue)

הדף שלך נכנס לתור. כל URL שמחזיר 200 ולא חסום ב-robots.txt או ב-<meta name="robots" content="noindex"> נכנס לתור הזה. עכשיו הוא ממתין. כמה? אף אחד לא יודע בוודאות. גוגל עצמה לא פרסמה מספרים מדויקים, אבל הניסיון של מומחי SEO מצביע על שניות עד ימים, ובאתרים חדשים/קטנים — לפעמים שבועות.

3. הרינדור עצמו (Second Pass)

כשמגיע התור של הדף שלך, גוגל מריץ Headless Chromium, טוען את ה-JS, מחכה ל-load event, ואז מצלם snapshot של ה-DOM. כל מה שלא מוצג ב-5 השניות הראשונות בסכנה. Lazy data שמגיע אחרי 3 שניות מ-API? ייתכן שלא ייכנס. Routes שמחכים לאינטראקציה? לא יחקרו.

4. אינדוקס

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

דיאגנוסטיקה ב-30 שניות: View Source לעומת Inspect Element

זה הטריק החשוב ביותר במדריך הזה. פתח את האתר שלך, לחץ ימני, ולחץ "View Page Source" (Ctrl+U). זה מה שגוגלבוט רואה ב-First Pass. זה מה שכל הבוטים הסוציאליים רואים. אם הטקסט של הדף לא שם — יש לך בעיה.

עכשיו לחץ "Inspect Element" (F12) ועבור ל-Elements. זה ה-DOM המלא אחרי שה-JS רץ. רוב הסיכויים שכאן הכל בסדר. הפער בין שני המסכים האלה הוא הבעיה.

פעולה עכשיו: עשה את הבדיקה הזו על דף הבית שלך. אם View Source מראה רק <div id="root"> ריק — אתה צריך אחד מהפתרונות בפרק הבא.

עץ ההחלטות — איזה פתרון מתאים לך

יש 6 דרכים לפתור את הבעיה. ההבדל ביניהן הוא כמה תוכן יש לך, כמה דינמיות יש לך, וכמה כסף/זמן יש לך.

פתרון	מתי מתאים	זמן הקמה	עלות	SEO	תגי OG
SPA נקי	אפליקציה פנימית, אחרי login, dashboard	0	0	גרוע	שבורים
react-snap (prerender)	אתר תדמית, פורטפוליו, בלוג קטן, דפי שיווק	1-2 שעות	0	מצוין	מעולה
Vite SSG (vike / vite-react-ssg)	אתר תוכן עם 10-1000 דפים, ידוע מראש	יום-יומיים	0	מצוין	מעולה
Astro + React Islands	בלוג, דוקומנטציה, אתר תוכן כבד	3-5 ימים (כתיבה מחדש)	0	הטוב ביותר	מעולה
Next.js (SSR/SSG)	אפליקציה דינמית עם תוכן ציבורי, e-commerce	1-2 שבועות	0-X	מצוין	מעולה
prerender.io (Dynamic Rendering)	״להציל״ אתר קיים בלי לכתוב מחדש	שעה	9-90$/חודש	טוב	מעולה

אבחנה מהירה לפי סוג האתר:

פורטפוליו / אתר תדמית של 1-15 דפים → react-snap. נקודה. בלי לסבך.
בלוג / אתר תוכן עם מאמרים → Astro או Vite SSG. אם אתה מתחיל מאפס — Astro. אם יש לך React קיים עם הרבה קומפוננטים — Vite SSG.
e-commerce / SaaS עם דפי מוצר ציבוריים → Next.js. SSR בדפים הדינמיים, SSG בדפים הסטטיים.
Dashboard מאחורי login → SPA נקי, אתה לא צריך SEO על הדפים הסגורים. ודא רק שהדפים השיווקיים החיצוניים מצוידים.
אתר קיים שאי אפשר לכתוב מחדש → prerender.io. עלות מתמשכת, אבל אפס שינוי קוד.

decision tree spa seo

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

מתי SPA ״ערום״ באמת מספיק

נדבר רגע על המקרה ההפוך — מתי באמת אין לך צורך בכלום מהפתרונות שיוצגו.

SPA רגיל ללא prerender הוא בסדר גמור אם:

כל הדפים שמאחורי login. Dashboard, פאנל ניהול, כלי פנימי. גוגל לא יכול להיכנס. אין לך מה לקדם. אל תשקיע.
אין דרישת SEO ציבורית. כלי B2B שמגיע אליו רק דרך הזמנה ישירה. הקישור מגיע באימייל. גוגל לא רלוונטי.
אתה בונה MVP פנימי לבדיקה. אתה תכתוב מחדש בעוד 3 חודשים. אל תבזבז זמן עכשיו.

מה כן לעשות גם ב-SPA פנימי: דאג שדף ה-login והדף השיווקי החיצוני (אם יש) — שעליהם אתה רוצה תנועה — מטופלים כראוי. את שאר האפליקציה לא מעניין אף אחד.

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

הפתרון הראשון — react-snap (prerender סטטי)

זה הפתרון שמתאים ל-70% מהקוראים. אתה כבר עם Vite/CRA, יש לך 5-30 דפים סטטיים יחסית, ואתה לא רוצה לכתוב מחדש לכל פריימוורק חדש. react-snap בונה את האתר שלך כרגיל, ואז מריץ Puppeteer (Headless Chrome) על כל הקישורים מהדף הראשי, ושומר את ה-HTML המרונדר כקובץ סטטי לכל route.

התקנה ב-Vite

npm install --save-dev react-snap

עדכן את package.json:

{
  "scripts": {
    "build": "vite build",
    "postbuild": "react-snap"
  },
  "reactSnap": {
    "source": "dist",
    "destination": "dist",
    "inlineCss": true,
    "minifyHtml": {
      "collapseWhitespace": true,
      "removeComments": true
    },
    "include": ["/"],
    "puppeteerArgs": ["--no-sandbox", "--disable-setuid-sandbox"]
  }
}

הכלל: postbuild רץ אוטומטית אחרי build. אז npm run build יבנה את ה-Vite output ל-dist, ואז react-snap ידלוק על השרת המקומי של dist, יחקור את כל הקישורים, ויחליף את index.html ב-dist/about/index.html, dist/blog/index.html וכו׳ — כל אחד עם ה-HTML המרונדר שלו.

שינוי קטן ב-main.tsx ל-hydration

react-snap מצפה ש-React יעשה hydrate ולא render כשה-HTML כבר קיים. זה הטריק:

import { hydrateRoot, createRoot } from "react-dom/client";
import App from "./App";

const rootElement = document.getElementById("root")!;

if (rootElement.hasChildNodes()) {
  hydrateRoot(rootElement, <App />);
} else {
  createRoot(rootElement).render(<App />);
}

זה אומר: אם יש כבר HTML מ-prerender — תעשה hydration עליו (זה מהיר, ולא מבליץ בדף). אם אין — תרנדר רגיל.

Gotchas שתתקל בהם

Lazy routes (React.lazy): react-snap לא מצליח לעקוב אחרי import דינמי שמופעל אחרי קליק. אם יש לך route שמטוען רק אחרי אינטראקציה — הוסף אותו ידנית ל-include במערך:

``json "include": ["/", "/about", "/contact", "/blog", "/blog/post-1"] ``

דאטה דינמי מ-API: אם הקומפוננט מבקש דאטה מ-fetch בעת הטעינה — react-snap מחכה עד שהבקשה מסתיימת לפני שהוא מצלם snapshot. זה טוב לדפים יחסית סטטיים, אבל בעייתי אם ה-API שלך איטי או מחזיר תוצאות שונות בכל קריאה.

תמונות lazy-loaded: וודא שהתמונות שלך נטענות כרגיל (לא loading="lazy" בעמוד הראשי), כי react-snap מצלם את ה-DOM הראשוני.

routes עם פרמטרים (/blog/:slug): react-snap לא ידע על הפוסטים שלך אלא אם תכניס אותם ל-include. תכתוב סקריפט קטן שמושך את רשימת הסלאגים ובונה את המערך לפני הבילד.

רענון של דף פנימי: וודא שה-host שלך (Firebase Hosting, Netlify, Vercel) מוגדר עם rewrite ל-index.html רק כברירת מחדל, ושהוא מגיש את ה-/about/index.html הסטטי אם הוא קיים.

דאטה דינמי? לפעמים זה דווקא יתרון

נגיד שאתה בונה אתר עם בלוג שמושך פוסטים מ-Firestore או מ-CMS. react-snap יכול לעבוד גם פה — בתנאי שאתה מכניס לוגיקה של ״אם אנחנו ב-prerender, חכה לדאטה״. הנה הדפוס:

// in BlogPost.tsx
import { useEffect, useState } from "react";

const isPrerendering = navigator.userAgent === "ReactSnap";

export function BlogPost({ slug }: { slug: string }) {
  const [post, setPost] = useState(null);

  useEffect(() => {
    fetch(`/api/posts/${slug}`)
      .then((r) => r.json())
      .then(setPost);
  }, [slug]);

  if (!post) {
    if (isPrerendering) {
      // react-snap waits for state updates; throw to force wait
      throw new Promise(() => {});
    }
    return <p>טוען...</p>;
  }

  return <article>{post.content}</article>;
}

זה לא יפה, אבל זה עובד. הגרסה המקצועית: עבור ל-SSG אמיתי (פרק הבא).

פעולה עכשיו: התקן את react-snap, הרץ npm run build, ופתח את dist/about/index.html בעורך טקסט. אם אתה רואה את התוכן של הדף שלך כ-HTML — הצלחת.

הפתרון השני — Vite SSG (vike או vite-react-ssg)

אם אתר react-snap מרגיש לך "trickery", או שיש לך הרבה דפים דינמיים (200+ פוסטים), כדאי לעבור ל-SSG אמיתי. הפילוסופיה היא אותה — כל route הופך לקובץ HTML סטטי בזמן build — אבל הכלי יודע על ה-Router שלך, יודע לטעון דאטה מ-loader, ויודע איזה route לבנות לפי getStaticPaths.

vite-react-ssg (ל-React Router v6)

זה הכלי הקל ביותר אם אתה כבר עם React Router. ההתקנה:

npm install --save-dev vite-react-ssg

עדכן package.json:

{
  "scripts": {
    "dev": "vite-react-ssg dev",
    "build": "vite-react-ssg build"
  }
}

ובמקום BrowserRouter עם רשימת <Route>, אתה מגדיר routes כמערך נתונים:

// src/routes.tsx
import type { RouteRecord } from "vite-react-ssg";

export const routes: RouteRecord[] = [
  {
    path: "/",
    Component: () => import("./pages/Home"),
    entry: "src/pages/Home.tsx",
  },
  {
    path: "/about",
    Component: () => import("./pages/About"),
  },
  {
    path: "/blog/:slug",
    Component: () => import("./pages/BlogPost"),
    getStaticPaths: async () => {
      const posts = await fetch("https://api.example.com/posts").then((r) =>
        r.json()
      );
      return posts.map((p: { slug: string }) => p.slug);
    },
  },
];

הקסם פה ב-getStaticPaths — הוא רץ פעם אחת בזמן build, מושך את רשימת הפוסטים, וכותב קובץ HTML לכל אחד מהם. כל מה שמגיע ל-useLoaderData() בקומפוננט — נכתב לתוך ה-HTML הראשוני. גוגל מרוצה, OG עובד, האתר נטען מהר.

vike (קודם vite-plugin-ssr)

vike הוא פריימוורק יותר רציני, מתאים לאתרים שעתידים לגדול לכיוון SSR אמיתי. הפיצ׳ר החזק שלו: כל דף יכול להיות במצב שונה (SSG, SSR, SPA), והקונפיגורציה היא ברמת הדף, לא ברמת האתר.

npm install vike

ובדף ספציפי:

// pages/blog/+config.ts
export default {
  prerender: true,
};

זה הופך את הדף הזה ל-SSG. דף אחר יכול להישאר SPA. זה גמיש מאוד, אבל יש לזה עקומת למידה.

vite ssg build

פעולה עכשיו: אם יש לך 50+ דפים — לך על vite-react-ssg היום. אם אתה רוצה משהו לטווח הארוך עם SSR בעתיד — קרא את תיעוד vike בסוף השבוע.

הפתרון השלישי — לעזוב את Vite ולעבור ל-Astro או Next.js

יש מצב שבו הפתרון הכי שווה הוא לא לטלא את ה-Vite SPA שלך, אלא לכתוב מחדש בפריימוורק שנבנה מההתחלה ל-SEO. זה לא תמיד שווה את ההשקעה, אבל לפעמים כן.

Astro — בחירה מעולה לתוכן

ב-2026 Astro הפך לסטנדרט דה-פקטו לאתרי תוכן. הפילוסופיה: HTML סטטי כברירת מחדל, אפס JavaScript בטעינה, ו-"islands" של React/Vue/Svelte רק היכן שצריך אינטראקטיביות. ה-Lighthouse שלך יקפוץ מ-60 ל-99 ביום אחד.

מתי לעבור ל-Astro:

אתר תוכן עיקרי (בלוג, דוקומנטציה, marketing site)
מספר עמודים אינטראקטיביים — אבל מועט (טופס יצירת קשר, חיפוש, וזהו)
אתה רוצה את ה-SEO הכי טוב שיש

מתי לא לעבור ל-Astro:

אפליקציה אינטראקטיבית כבדה (dashboard, e-commerce עם cart)
אתה ב-React Router עם state ניהול כבד

Next.js — הבחירה הטבעית לאפליקציות

Next.js 16 נכון ל-2026 הוא הפתרון המבוסס ביותר ל-SSR/SSG. ה-App Router תומך ב-Server Components, ב-Cache Components (ה-PPR שיצא מ-experimental), ב-streaming, וכמעט בכל מה שצריך. החיסרון: vendor lock-in קל ל-Vercel (אם כי אפשר לרוץ גם במקומות אחרים), ועקומת למידה יחסית גבוהה אם אתה בא מ-Vite SPA. אם אתה שוקל את המעבר, יש לי מדריך ייעודי לApp Router של Next.js 16, ומדריך השוואה שיעזור לבחור איפה לארח — Vercel מול Firebase Hosting.

מתי לעבור ל-Next.js:

e-commerce עם דפי מוצר ציבוריים
SaaS עם דפי marketing וגם dashboard
צריך SSR אמיתי (תוכן שמשתנה לפי משתמש/locale/feature flag)

פעולה עכשיו: אם המעבר נראה כמו 2-3 שבועות עבודה והאתר הזה הוא העסק שלך — שווה. אם זה פרויקט צד או MVP — תישאר עם react-snap.

meta tags + Open Graph + JSON-LD ב-SPA

לא משנה איזה פתרון בחרת — אתה חייב meta tags. ב-2026 יש שתי דרכים, ואני אסביר מתי כל אחת.

הדרך החדשה — React 19 native metadata. מ-React 19 אתה יכול לכתוב <title> ו-<meta> ו-<link> ישירות בתוך כל קומפוננט, ו-React יזרים (hoists) אותם אוטומטית ל-<head>. אין צורך בספרייה, אין Provider, וזה עובד גם בקליינט וגם ב-SSR/streaming:

// אפשר ישירות בתוך כל דף ב-React 19 — בלי ספרייה
export default function AboutPage() {
  return (
    <>
      <title>אודות | nisai.dev</title>
      <meta name="description" content="פיתוח אתרים ואוטומציות לעסקים" />
      <meta property="og:title" content="אודות | nisai.dev" />
      <article>{/* תוכן */}</article>
    </>
  );
}

זה מצוין לרוב המקרים. הסייג: המנגנון הזה אינו דה-דופ אוטומטית של תגים זהים בין דפים, ואינו מטפל ב-<html lang> או ב-<body>. למקרים מורכבים (override של תג ספציפי לפי route, ניהול canonical מרכזי, סדר עדיפויות בין layout לדף) — react-helmet-async עדיין שווה את זה.

הדרך הבדוקה — react-helmet-async. היא תומכת ב-SSR, ב-prerender, וב-SPA רגיל, ולא דולפת זיכרון כמו ה-react-helmet הישנה. אם אתה ב-React 18 או רוצה שליטה מלאה — זו הבחירה. שאר הפרק מדגים אותה, כי הדפוס שלה מועתק 1:1 גם אם תעבור אחר כך ל-native.

התקנה

npm install react-helmet-async

עטוף את האפליקציה ב-HelmetProvider:

// src/main.tsx
import { HelmetProvider } from "react-helmet-async";

createRoot(document.getElementById("root")!).render(
  <HelmetProvider>
    <App />
  </HelmetProvider>
);

קומפוננטת SEO לשימוש חוזר

// src/components/SEO.tsx
import { Helmet } from "react-helmet-async";

type SEOProps = {
  title: string;
  description: string;
  image?: string;
  url: string;
  type?: "website" | "article";
  publishedAt?: string;
  jsonLd?: Record<string, unknown>;
};

export function SEO({
  title,
  description,
  image = "https://nisai.dev/og-default.png",
  url,
  type = "website",
  publishedAt,
  jsonLd,
}: SEOProps) {
  const fullTitle = `${title} | nisai.dev`;

  return (
    <Helmet>
      <title>{fullTitle}</title>
      <meta name="description" content={description} />
      <link rel="canonical" href={url} />

      {/* Open Graph */}
      <meta property="og:title" content={fullTitle} />
      <meta property="og:description" content={description} />
      <meta property="og:image" content={image} />
      <meta property="og:url" content={url} />
      <meta property="og:type" content={type} />
      <meta property="og:locale" content="he_IL" />
      {publishedAt && (
        <meta property="article:published_time" content={publishedAt} />
      )}

      {/* Twitter */}
      <meta name="twitter:card" content="summary_large_image" />
      <meta name="twitter:title" content={fullTitle} />
      <meta name="twitter:description" content={description} />
      <meta name="twitter:image" content={image} />

      {/* JSON-LD */}
      {jsonLd && (
        <script type="application/ld+json">{JSON.stringify(jsonLd)}</script>
      )}
    </Helmet>
  );
}

שימוש ברמת דף

// src/pages/BlogPost.tsx
import { SEO } from "../components/SEO";

export default function BlogPost({ post }: { post: Post }) {
  const jsonLd = {
    "@context": "https://schema.org",
    "@type": "Article",
    headline: post.title,
    description: post.excerpt,
    author: {
      "@type": "Person",
      name: "נעם ניסן",
    },
    datePublished: post.publishedAt,
    image: post.coverImage,
  };

  return (
    <>
      <SEO
        title={post.title}
        description={post.excerpt}
        image={post.coverImage}
        url={`https://nisai.dev/blog/${post.slug}`}
        type="article"
        publishedAt={post.publishedAt}
        jsonLd={jsonLd}
      />
      <article>{/* התוכן */}</article>
    </>
  );
}

חשוב: אם אתה ב-SPA רגיל ללא prerender — ה-<title> וה-<meta> שמוזרקים על ידי Helmet רק אחרי שה-JS רץ. גוגל יראה אותם בסוף, אבל הבוטים הסוציאליים לא. לכן אתה חייב לפחות prerender על דפים שאליהם משתפים קישורים.

הערה על אתרים בעברית: ודא ש-<html lang="he" dir="rtl"> יושב ב-index.html הראשוני, לא רק מוזרק ב-JS — גם בשביל הבוטים וגם בשביל קוראי מסך. את מלוא הנושא של RTL ונגישות כיסיתי בנגישות ו-RTL בעברית.

JSON-LD — איזה סוגים שווה להוסיף

Organization או Person בדף הבית
Article או BlogPosting בכל פוסט
BreadcrumbList בדפים פנימיים
FAQPage אם יש עמוד שאלות נפוצות (עדיין מציג Rich Snippets ב-2026 — בדיוק כמו ה-FAQ בתחתית המדריך הזה)
Product + Offer לדפי מוצר
LocalBusiness אם יש עסק עם כתובת פיזית — חשוב במיוחד לקידום מקומי בישראל, ראה SEO מקומי וגוגל לעסק שלי

תוודא תמיד עם Schema Markup Validator של schema.org לפני שאתה דוחף לפרודקשן. אם מטרת הקידום שלך היא בעיקר להופיע בתשובות של ChatGPT ו-Perplexity ולא רק בגוגל הקלאסי — schema מובנה הוא חלק קריטי מהמשוואה, וכיסיתי את כל הצד הזה לעומק במדריך GEO.

og card whatsapp preview

פעולה עכשיו: הוסף SEO component להוק של דף הבית, ובדוק עם Facebook Sharing Debugger ועם LinkedIn Post Inspector. אם זה לא תקין שם — תקן עכשיו.

sitemap.xml + robots.txt — דרישת חובה

גוגל לא חייב sitemap, אבל בלעדיו אתה תלוי לחלוטין בקישורים פנימיים שיגלו את הדפים שלך. עם sitemap, אתה אומר לגוגל במפורש ״אלה הדפים שלי, אלה התאריכים, בוא לבדוק״.

עם vite-plugin-sitemap

npm install --save-dev vite-plugin-sitemap

// vite.config.ts
import { defineConfig } from "vite";
import react from "@vitejs/plugin-react";
import sitemap from "vite-plugin-sitemap";

export default defineConfig({
  plugins: [
    react(),
    sitemap({
      hostname: "https://nisai.dev",
      dynamicRoutes: ["/", "/about", "/guides", "/guides/react-spa-seo"],
      exclude: ["/admin", "/api"],
      changefreq: "weekly",
      priority: 0.8,
    }),
  ],
});

זה ייצור dist/sitemap.xml ו-dist/robots.txt אוטומטית בכל בילד.

sitemap דינמי לבלוג

אם הדפים שלך נשלפים מ-CMS או DB — בנה את dynamicRoutes לפני הבילד:

// scripts/build-sitemap.ts
import { writeFileSync } from "fs";

const posts = await fetch("https://api.example.com/posts").then((r) =>
  r.json()
);
const routes = ["/", "/about", ...posts.map((p) => `/blog/${p.slug}`)];

writeFileSync("./sitemap-routes.json", JSON.stringify(routes));

ובsitemap config:

import routes from "./sitemap-routes.json";

sitemap({
  hostname: "https://nisai.dev",
  dynamicRoutes: routes,
});

הרץ npm run build-sitemap && npm run build כשרשרת.

robots.txt — דוגמה סבירה

User-agent: *
Allow: /
Disallow: /admin
Disallow: /api

Sitemap: https://nisai.dev/sitemap.xml

הזהרה אחת ענקית: אל תחסום את ה-/assets/ של ה-JS וה-CSS. לפעמים אנשים חוסמים את כל הקובץ הזה כי ״מה זה מעניין את גוגל״. זה בדיוק מה שגוגל צריך כדי לרנדר את הדף שלך. אם תחסום, הוא לא יוכל להריץ את ה-JS, והדף שלך יראה ריק. תוודא ש-CSS, JS, ותמונות חיוניים — פתוחים.

פעולה עכשיו: העלה את הסייטמאפ והרובוטס, בדוק שהם נטענים ב-https://example.com/sitemap.xml בדפדפן, והגש את הכתובת ל-Google Search Console (Sitemaps → Add a new sitemap).

Search Console — איך לוודא שזה באמת עבד

אל תסמוך על תחושות. תוודא. כל ההגדרות לעיל לא שוות כלום אם גוגל בפועל לא רואה את התוכן שלך.

1. רישום ל-Search Console

עבור ל-search.google.com/search-console, הוסף את הדומיין שלך כ-"Domain property" (דרושה גישת DNS) או "URL prefix" (קל יותר, רק https://).

2. URL Inspection — הכלי הכי חשוב

הקלד כתובת של דף ספציפי ב-Search bar בראש הקונסול. תקבל סטטוס: האם הדף ב-Google Index, האם הוא ניתן להגשה, וכמה זמן עבר מהסריקה האחרונה.

לחץ Test live URL. גוגל מריץ סריקה חיה. ואז לחץ View tested page → HTML. זה ה-HTML המרונדר שגוגל רואה עכשיו. גלול ותחפש את הטקסט של הדף שלך.

אם הטקסט שם — מצוין, פתרון ה-prerender שלך עובד.
אם רואים <div id="root"></div> ריק — משהו נשבר. לרוב, react-snap לא רץ, או שהמארח שלך מגיש index.html הריק במקום ה-HTML המרונדר.

לחץ גם על More info → JavaScript console messages. אם יש שם errors — הם יכולים לעצור את הרינדור באמצע.

3. Coverage / Pages report

ב-תפריט השמאלי לחץ Pages (לפעמים "Indexing → Pages"). שם תראה כמה דפים שלך באינדקס, כמה לא, ולמה לא:

"Discovered – currently not indexed" = גוגל יודע על הדף, אבל לא טרח לרנדר עדיין. סימן שאתר חדש או render budget הוסר. תקן: שפר performance, הוסף backlinks, הגש sitemap.
"Crawled – currently not indexed" = גוגל רינדר, אבל החליט שהדף לא איכותי מספיק. תקן: שפר תוכן, הוסף ייחודיות, הסר דפים דקים.
"Page with redirect" = יש redirect שגוגל מעדיף לא לאנדקס. ודא שהוא קנוני.

4. Mobile Usability + Core Web Vitals

ב-2026 גוגל מציין Mobile-First Indexing. אם האתר שלך לא ידידותי למובייל — אתה מאבד. בדוק ב-Core Web Vitals report:

LCP (Largest Contentful Paint) — מטרה: מתחת ל-2.5 שניות
CLS (Cumulative Layout Shift) — מטרה: מתחת ל-0.1
INP (Interaction to Next Paint) — מטרה: מתחת ל-200ms

react-snap עוזר ענק ל-LCP, כי הטקסט הראשי כבר ב-HTML, לפני שה-JS רץ. אם המספרים האלה לא מסתדרים לך, יש לי מדריך נפרד שמפרק כל מדד ואיך לתקן אותו בפועל — Core Web Vitals 2026.

lighthouse seo score

5. הרצה של Lighthouse

ב-Chrome DevTools, לחץ על Lighthouse tab, בחר "SEO" + "Performance" + "Accessibility" + "Best Practices", ולחץ "Analyze page load". כל ציון מתחת ל-90 ב-SEO — דברים שאתה צריך לתקן (meta description חסר, title קצר מדי, וכו׳).

פעולה עכשיו: עלה ל-Search Console עכשיו. אם זה לא מוגדר — תגדיר. הגש sitemap. הרץ URL Inspection על דף הבית. תיעזר במה שאתה רואה לעדכן את הפתרון שלך.

search console coverage

שגיאות נפוצות שראיתי אצל לקוחות

השגיאה	מה זה גורם	התיקון
`<title>React App</title>` בקובץ `index.html` ולא מוחלף	גוגל מאנדקס את הדף בתור "React App"	החלף ב-meta נכון + השתמש ב-react-helmet-async
`<meta name="description">` חסר לחלוטין	גוגל ימציא תיאור, לרוב גרוע	הוסף description ייחודי לכל דף
`robots.txt` חוסם את `/assets/`	גוגל לא יכול לרנדר את ה-JS	פתח את `/assets/` ו-`/static/`
`noindex` שנשאר מ-staging	האתר לא באינדקס בכלל	תבדוק את ה-HTML הראשוני
react-snap לא רץ ב-CI	פרודקשן עולה כ-SPA רגיל	הוסף `postbuild` ב-`package.json`, ודא ש-Puppeteer מותקן
OG image הוא נתיב יחסי	התצוגה ב-WhatsApp נשברת	תמיד URL מלא, עם `https://`
URL canonical שונה בכל סיבוב	duplicate content	תקבע canonical יציב לכל route
sitemap עם 404s	גוגל מוריד את האמון בכל הסייטמאפ	סרוק את הסייטמאפ עם curl, וודא שכל URL מחזיר 200
hash routing (`/#/about`)	גוגל מתעלם מ-fragments	עבור ל-History API (BrowserRouter)
תוכן שמופיע רק אחרי click או scroll	גוגל לא ילחץ ולא יגלול	טען את התוכן בעת mount

פעולה עכשיו: עבור על הטבלה הזו כצ׳קליסט. כל שורה — בדוק שאתה לא עושה אותה.

סיכום — מסלול הפעולה שלך

אם אתה בנית React SPA חדש, הנתיב הוא:

החלט אם אתה צריך SEO ציבורי (אם לא — סיים פה).
בחר פתרון מטבלת ההחלטות: react-snap לרוב המקרים.
התקן react-helmet-async והוסף SEO component.
הוסף sitemap.xml + robots.txt.
הרץ build, בדוק dist/index.html ידנית.
דפלוי.
רישום ל-Search Console, הגשת sitemap.
URL Inspection על 3-5 דפים, וודא שה-HTML המרונדר כולל את התוכן.
בדוק ב-Facebook Sharing Debugger ו-LinkedIn Inspector ש-OG עובד.
חכה שבוע, חזור ל-Coverage report, ראה מה אנדקס.

אם יש לך SPA קיים שלא מאונדקס: התחל מ-URL Inspection. תבין מה גוגל רואה. ואז תקן את שורש הבעיה, לא את הסימפטומים.

רוצה שאני אעשה לך את זה? אני עושה Audit מלא של אתר SPA קיים + הקמת prerender, sitemap, OG, JSON-LD ו-Search Console — תוך 2-3 ימי עבודה. דבר איתי ב-wa.me/972585802298 — 30 דק׳ חינם של ייעוץ, נבין אם אתה צריך את זה לפני שאתה משלם שקל.

שאלות נפוצות

האם React SPA טוב ל-SEO ב-2026?

באופן עקרוני גוגל מסוגל לאנדקס SPA כי הוא מריץ JavaScript, אבל זה לא אומר ש-SPA טוב ל-SEO. הבעיה הכפולה: גוגל מרנדר בעיכוב (render budget שיכול להגיע לימים), והבוטים הסוציאליים ומנועי ה-AI לא מריצים JS בכלל. בפועל, SPA שמוסיף עליו prerender או SSG מקבל SEO מצוין, ו-SPA ״ערום״ מקבל SEO גרוע ותצוגות מקדימות שבורות בכל רשת חברתית.

למה האתר שלי ב-React לא מופיע בגוגל?

הסיבה הנפוצה ביותר היא שה-HTML הראשוני שלך ריק — רק <div id="root"></div> — והתוכן מוזרק אחרי שה-JS רץ. תעשה את הבדיקה: לחץ Ctrl+U (View Source) על דף הבית. אם אתה לא רואה שם את הטקסט של הדף, גם גוגל מתקשה לראות אותו. סיבות נוספות: noindex שנשאר מ-staging, robots.txt שחוסם את /assets/, או hash routing בסגנון /#/about שגוגל מתעלם ממנו.

האם react-snap עדיין רלוונטי ב-2026 או שעדיף SSG?

react-snap עדיין עובד מצוין לאתרי תדמית, פורטפוליו ובלוגים קטנים עם מספר דפים ידוע מראש — הוא הפתרון המהיר ביותר בלי לכתוב מחדש. ברגע שיש לך עשרות או מאות דפים דינמיים, או דאטה שנשלף בזמן build, עדיף SSG אמיתי כמו vite-react-ssg או vike, שמכיר את ה-Router שלך ויודע לבנות נתיב לכל פוסט דרך getStaticPaths.

האם מנועי AI כמו ChatGPT ו-Claude רואים אתר SPA?

נכון ליוני 2026, GPTBot, ClaudeBot ו-PerplexityBot לא מריצים JavaScript, הם קוראים רק את ה-HTML הגולמי. כלומר אתר SPA ללא prerender הוא בלתי נראה עבורם, גם אם הוא מדורג מצוין בגוגל. היוצא מן הכלל הוא Google-Extended, שמשתמש בתשתית הרינדור של Googlebot. אם אתה רוצה להופיע בתשובות AI, ה-HTML הראשוני חייב להכיל את התוכן — ראה GEO — אופטימיזציה למנועי תשובות.

למה התצוגה המקדימה של הקישור שלי שבורה ב-WhatsApp ובפייסבוק?

כי WhatsApp, Facebook, LinkedIn ו-Slack לא מריצים JavaScript — הם מחפשים תגי Open Graph ב-HTML הגולמי, ובמקרה של SPA הם מוצאים <head> ריק. הפתרון: prerender (react-snap) או SSG שמטמיע את תגי ה-og:title, og:description ו-og:image בקובץ ה-HTML עצמו. ודא שה-og:image הוא URL מלא עם https://, לא נתיב יחסי, ובדוק עם Facebook Sharing Debugger.

האם React 19 פותר את בעיית ה-SEO לבד?

לא לגמרי. React 19 מוסיף תמיכה native בהזרקת <title> ו-<meta> ל-<head>, וזה מייתר את react-helmet-async ברוב המקרים. אבל זה עדיין רץ בצד הקליינט — הבוטים שלא מריצים JS לא ירוויחו מזה. כדי שזה יעזור באמת ל-SEO, אתה עדיין צריך שכבת prerender, SSG או SSR שמוציאה את התגים האלה ל-HTML הסטטי.

מתי שווה לעבור מ-Vite ל-Next.js בגלל SEO?

כשהאתר הוא הליבה של העסק ויש בו תוכן דינמי ציבורי שמשתנה לפי משתמש, locale או feature flag — למשל e-commerce עם דפי מוצר או SaaS עם דפי שיווק. בשלב הזה SSR אמיתי שווה את 1-2 שבועות המעבר. לפרויקט צד, MVP או אתר תדמית — זה over-engineering; תישאר עם Vite + react-snap. ראה מדריך App Router של Next.js 16 להחלטה מושכלת.

לסיכום

SEO ל-SPA ב-React הוא לא ״גוגל מריץ JS אז הכל בסדר״. זו שאלה של מי קורא את ה-HTML הגולמי שלך, וב-2026 רוב הבוטים החשובים (סוציאליים ו-AI) קוראים רק אותו. הכלל היחיד שצריך לזכור: כל דף שאליו מגיעה תנועה ציבורית או שמשתפים אותו חייב תוכן אמיתי ב-HTML הראשוני. לרוב האתרים (פורטפוליו, תדמית, בלוג קטן) react-snap עם react-helmet-async, או metadata native של React 19, פותר את זה בשעתיים. ליותר דפים — SSG. לאפליקציה דינמית כבדה — Next.js. תתחיל מ-View Source ומ-URL Inspection ב-Search Console, ותתקן את השורש ולא את הסימפטום.