GitHub Pages — אתרים חינמיים

3.1 מה זה GitHub Pages ולמה זה עדיין רלוונטי ב-2026

GitHub Pages הוא שירות אירוח חינמי לאתרים סטטיים, מובנה ישירות ב-GitHub. כל מה שצריך זה repository עם קבצי HTML, CSS ו-JavaScript — ו-GitHub יגיש אותם כאתר חי באינטרנט. בלי שרת, בלי תשלום, בלי תצורה מורכבת. תעשו push ל-repository — והאתר מתעדכן. זהו.

מאחורי הקלעים, GitHub Pages משתמש ברשת CDN של Fastly כדי להגיש את הקבצים במהירות מכל מקום בעולם. כלומר, גם אם האתר שלכם מתארח ב-GitHub, המשתמשים שלכם מקבלים אותו מהשרת הקרוב ביותר אליהם — בדיוק כמו אתר שמשלמים עליו.

יש שני סוגי אתרים ב-Pages, וחשוב להבין את ההבדל:

1. אתר משתמש/ארגון (User/Org site) — נגיש בכתובת username.github.io. נוצר מריפוזיטורי עם השם המדויק username.github.io. אחד בלבד לכל חשבון. פורסם מ-branch ברירת מחדל.
2. אתר פרויקט (Project site) — נגיש בכתובת username.github.io/repo-name. כל ריפוזיטורי יכול להיות אתר פרויקט — אין הגבלה על כמות. פורסם מ-branch ספציפי או מ-Actions.

ההבדל הפרקטי: אתר משתמש הוא הבית הראשי שלכם (portfolio, דף אישי), ואתרי פרויקט הם אתרים נפרדים לכל ריפו (דוקומנטציה, landing page, בלוג של פרויקט ספציפי).

למה Pages עדיין רלוונטי ב-2026, כשיש Vercel, Netlify ו-Cloudflare Pages? ארבע סיבות:

1. חינמי לגמרי. לא free tier עם כוכביות — חינמי. אירוח, HTTPS, דומיין מותאם, bandwidth של 100GB בחודש. לא צריך כרטיס אשראי, לא צריך הרשמה נפרדת. אם יש לכם GitHub — יש לכם Pages.
2. משולב ב-GitHub. הקוד, ה-CI/CD, והאירוח — הכל באותו מקום. push ל-main = האתר מתעדכן. אפס כלים חיצוניים, אפס תצורה של צד שלישי. ה-repository הוא האתר.
3. פשוט. אם כל מה שצריך זה להעלות HTML לאינטרנט — Pages הוא הדרך הקצרה ביותר. אין signup, אין dashboard נפרד, אין CLI נוסף. פתיחת Pages = toggle בהגדרות.
4. אמינות. GitHub Pages מופעל על ידי Fastly CDN עם uptime גבוה במיוחד. לאתרים סטטיים עם תעבורה סבירה, הביצועים מצוינים — והכל בלי שתשלמו שקל.

מתי Pages לא מתאים? כשצריכים server-side code (PHP, Node.js, Python), בסיס נתונים, authentication (חוץ מ-Enterprise Cloud), או serverless functions. ל-Pages אין שום עיבוד בצד השרת — הוא מגיש קבצים סטטיים ותו לא. אם האתר שלכם צריך לדבר עם database או לרוץ backend logic, Pages הוא לא הבית הנכון.

זמינות: Pages זמין בחינם לריפוזיטוריים ציבוריים בכל התוכניות, ולריפוזיטוריים פרטיים בתוכניות Pro, Team ו-Enterprise. שימו לב: גם אם הריפו פרטי, האתר של Pages תמיד ציבורי (חוץ מ-Enterprise Cloud שמאפשר אתרי Pages פרטיים עם authentication). זו נקודה שחשוב לזכור — לעולם אל תשימו מידע רגיש בקבצים שמפורסמים ב-Pages.

3.2 שני מצבי פרסום: מ-branch או מ-Actions

ל-GitHub Pages יש שני מצבי פרסום, ובחירת המצב הנכון משפיעה על כל דבר — מה build tool שתשתמשו בו ועד כמה שליטה יש לכם על התהליך. הבחירה נעשית פעם אחת ב-Settings → Pages → Source, ואפשר לשנות בכל רגע.

מצב 1: Deploy from a Branch (קלאסי)

בוחרים branch (בדרך כלל main או gh-pages) ותיקייה (/ root או /docs). GitHub מריץ Jekyll אוטומטית (אלא אם יש .nojekyll), בונה את האתר, ומגיש אותו. כל push ל-branch הזה = build חדש.

יתרונות: פשוט להפליא. אפס קונפיגורציה, אפס YAML, אפס workflow. בוחרים branch ותיקייה, לוחצים Save — וזהו. מושלם לאתרי Markdown/Jekyll, דוקומנטציה פשוטה, או HTML סטטי שלא צריך שום build.

חסרונות: Jekyll בלבד (או HTML סטטי), אין שליטה על תהליך ה-build, אין בדיקות (lint, tests, lighthouse) לפני פרסום, אין אפשרות להשתמש ב-npm/Node.js/Python/או כל build tool אחר.

טיפ על /docs folder: אם בוחרים לפרסם מתיקיית /docs, אפשר לשמור את הקוד של הפרויקט בשורש ואת האתר בתיקייה נפרדת. זה שימושי לפרויקטי open source שרוצים דוקומנטציה באותו ריפו — הקוד ב-root, האתר ב-/docs.

מצב 2: GitHub Actions (מודרני)

כותבים workflow שעושה build לאתר (עם כל כלי שרוצים — React, Vue, Astro, Hugo, Vite, 11ty, או כל דבר אחר), מעלים את התוצר כ-artifact, ופורסים ל-Pages. זה המצב המומלץ ב-2026.

יתרונות: כל framework, כל build tool, בדיקות לפני פרסום (lint, tests, accessibility audit), שליטה מלאה על כל שלב. אפשר להוסיף environments, secrets, conditions — הכל מה שלמדתם בפרק 1 על Actions.

חסרונות: דורש כתיבת workflow YAML (שנלמד בסעיף 3.5). צריך להבין permissions, artifacts, ו-environments. לאתר HTML פשוט בלי build — זה overkill.

טבלת השוואה

איזה מצב לבחור? כלל אצבע: אם אתם שמים קובץ HTML ועושים push — branch mode מספיק ויותר. אם יש לכם package.json, npm run build, או כל תהליך build — השתמשו ב-Actions. ברגע שתבנו את ה-workflow פעם אחת, הוא רץ אוטומטית לנצח.

3.3 האתר הראשון שלך — מאפס לאונליין ב-5 דקות

בואו נבנה אתר Pages מאפס. לא צריך framework, לא צריך build tool, לא צריך ידע מתקדם — רק HTML, push, והאתר באוויר. זו אחת החוויות הכי מספקות ב-GitHub: לכתוב קוד, לעשות push, ולראות אותו חי באינטרנט תוך 30 שניות.

שלב 1: יצירת הריפוזיטורי

אפשר להשתמש בריפוזיטורי קיים או ליצור חדש. אם יוצרים חדש, בחרו שם בלי רווחים או תווים מיוחדים (כי זה יהיה חלק מה-URL). לדוגמה: my-portfolio ייצור אתר בכתובת username.github.io/my-portfolio.

טיפ: אם אתם יוצרים ריפו בשם username.github.io (עם שם המשתמש המדויק שלכם), הכתובת תהיה https://username.github.io — בלי שם הריפו בסוף. זה אתר המשתמש שלכם, ויש רק אחד כזה לכל חשבון.

שלב 2: יצירת הקבצים

הוסיפו שני קבצים לריפו:

<!-- index.html -->
<!DOCTYPE html>
<html lang="he" dir="rtl">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>האתר שלי</title>
    <style>
        body {
            font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', sans-serif;
            max-width: 800px;
            margin: 0 auto;
            padding: 2rem;
            background: #0d1117;
            color: #e6edf3;
        }
        h1 { color: #a855f7; }
        a { color: #58a6ff; }
    </style>
</head>
<body>
    <h1>שלום עולם!</h1>
    <p>האתר הזה רץ על GitHub Pages. חינם.</p>
    <p><a href="https://github.com/USERNAME">הפרופיל שלי ב-GitHub</a></p>
</body>
</html>

שלב 3: קובץ .nojekyll

צרו קובץ ריק בשם .nojekyll בשורש הריפו. הקובץ הזה אומר ל-GitHub: אל תריץ Jekyll. בלי הקובץ הזה, GitHub ינסה לעבד את האתר עם Jekyll, מה שמוסיף זמן build מיותר ועלול לגרום לבעיות עם קבצים שמתחילים ב-underscore (כמו _next, _assets, _build).

# צרו את הקובץ (ריק, בלי תוכן):
touch .nojekyll

למה צריך את הקובץ הזה? ב-branch mode, GitHub מריץ Jekyll אוטומטית על כל build. Jekyll מצפה למבנה מסוים (front matter, Liquid, layouts) ומתייחס לתיקיות שמתחילות ב-_ כתיקיות מיוחדות שלו. אם אתם לא משתמשים ב-Jekyll — זה רק מעכב ויכול לשבור דברים. .nojekyll מבטל את זה.

שלב 4: Push והפעלת Pages

git add index.html .nojekyll
git commit -m "feat: add GitHub Pages site"
git push origin main

עכשיו היכנסו ל-Settings → Pages, בחרו:

• Source: Deploy from a branch
• Branch: main
• Folder: / (root)

לחצו Save. תוך 30 שניות עד דקה, האתר שלכם יהיה זמין בכתובת https://username.github.io/repo-name. תראו גם הודעה ירוקה עם הקישור באותו עמוד הגדרות.

לא רואים שינויים? כמה סיבות נפוצות: (1) cache של הדפדפן — נסו Ctrl+Shift+R לרענון מלא; (2) ה-build עדיין רץ — חכו דקה ורעננו; (3) שם הקובץ לא index.html בדיוק — בדקו אותיות גדולות/קטנות.

3.4 Jekyll — המנוע המובנה (ומתי לוותר עליו)

Jekyll הוא מנוע בניית אתרים סטטיים שנוצר על ידי Tom Preston-Werner — אחד ממייסדי GitHub. הוא כתוב ב-Ruby וממיר קבצי Markdown ותבניות Liquid לאתר HTML מלא. GitHub Pages מריץ אותו אוטומטית במצב branch-based — כלומר, אם אתם בוחרים Deploy from a branch ואין .nojekyll, Jekyll רץ על כל push.

ההיסטוריה חשובה להבנה: Jekyll נוצר ב-2008, לפני Vercel, לפני Netlify, לפני Astro. הוא היה מהראשונים שהציעו "כתוב ב-Markdown, קבל אתר" — ו-GitHub שילב אותו ישירות ב-Pages. עד היום הוא עדיין אופציה טובה למקרים מסוימים.

מה Jekyll עושה:

• ממיר Markdown (.md) ל-HTML — מצוין לבלוגים ודוקומנטציה
• תומך ב-themes — עיצובים מוכנים שמשנים את המראה בהחלפת שורה ב-_config.yml
• משתמש ב-Liquid templating — שפת תבניות עם {% raw %}{{ }}{% endraw %} (משתנים) ו-{% raw %}{% %}{% endraw %} (לוגיקה)
• תומך ב-front matter — מטאדאטה ב-YAML בתחילת כל קובץ (כותרת, תאריך, קטגוריה)
• מייצר sitemap.xml אוטומטית עם plugin מובנה (jekyll-sitemap)
• תומך ב-collections ו-data files — לארגון תוכן מורכב

מתי Jekyll מתאים:

• בלוג אישי שכותבים ב-Markdown — Jekyll נולד לזה
• דוקומנטציה לפרויקט — themes כמו just-the-docs מוכנים לשימוש
• אתר פשוט שלא צריך JavaScript frameworks או build מורכב
• כשרוצים להתחיל מהר בלי ללמוד עוד כלי

מתי לוותר על Jekyll:

• אתם משתמשים ב-React, Vue, Angular, Svelte, Astro, Next.js, או כל framework מודרני
• יש לכם HTML סטטי מוכן שלא צריך שום עיבוד
• אתם רוצים build מהיר יותר (Jekyll על אתר גדול יכול לקחת דקות)
• יש לכם קבצים שמתחילים ב-_ (underscore) שצריכים להישאר כמו שהם
• אתם לא מכירים Ruby ולא רוצים להתקין את הסביבה לפיתוח לוקלי

איך לבטל Jekyll: צרו קובץ ריק בשם .nojekyll בשורש הריפו. זהו. Jekyll לא ירוץ, והקבצים יוגשו כמו שהם — בדיוק מה ששמתם בריפו.

אלטרנטיבות מודרניות: אם רוצים את הרעיון של Jekyll (Markdown → אתר) אבל עם ביצועים טובים יותר, שקלו: Hugo (Go, מהיר מאוד), Astro (JavaScript, תומך ב-components), 11ty/Eleventy (JavaScript, פשוט). כולם עובדים עם Pages דרך Actions.

3.5 פרסום עם Actions — שליטה מלאה

עכשיו נעבור למצב המומלץ: פרסום דרך GitHub Actions. זה נותן שליטה מלאה — אתם בוחרים את ה-build tool, מוסיפים בדיקות, ורק אם הכל עובר — האתר מתפרסם. אם למדתם Actions בפרק 1, הרבה מהמבנה יהיה מוכר.

ה-workflow מורכב משני jobs שרצים ברצף:

1. Build — בונה את האתר (install, lint, test, build) ומעלה את התוצר כ-artifact
2. Deploy — לוקח את ה-artifact ופורס אותו ל-GitHub Pages

למה שני jobs ולא אחד? כי ה-deploy צריך לרוץ ב-environment מיוחד (github-pages), ואם ה-build נכשל — ה-deploy לא מתבצע. זה separation of concerns: build הוא build, deploy הוא deploy.

הנה workflow מלא ומוכן לשימוש:

# .github/workflows/deploy-pages.yml
name: Deploy to GitHub Pages

on:
  push:
    branches: [main]
  workflow_dispatch:          # אפשרות להפעלה ידנית מה-UI

# *** permissions חובה — בלי זה ה-deploy ייכשל ***
permissions:
  contents: read
  pages: write
  id-token: write

# מניעת פריסות כפולות — רק הגרסה האחרונה תיפרס
concurrency:
  group: "pages"
  cancel-in-progress: false

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Setup Pages
        uses: actions/configure-pages@v5

      # --- כאן הוסיפו את ה-build שלכם ---
      # דוגמה: npm ci && npm run build
      # התוצאה צריכה להיות בתיקייה (למשל: ./dist, ./build, ./out)

      - name: Upload artifact
        uses: actions/upload-pages-artifact@v3
        with:
          path: '.'    # או ./dist, ./build — התיקייה עם האתר הסופי

  deploy:
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}
    runs-on: ubuntu-latest
    needs: build
    steps:
      - name: Deploy to GitHub Pages
        id: deployment
        uses: actions/deploy-pages@v4

נפרק את החלקים הקריטיים אחד-אחד:

• permissions — שלושת ה-permissions הם חובה: contents: read (לקרוא את הקוד מהריפו), pages: write (לכתוב ל-GitHub Pages), id-token: write (לאימות OIDC מול Pages). בלי אחד מהם — ה-deploy ייכשל עם שגיאת permissions. זו הטעות הנפוצה ביותר.
• concurrency — מונע פריסות כפולות. אם שני pushes מגיעים ברצף, רק האחרון ייפרס. cancel-in-progress: false מבטיח שפריסה שכבר התחילה תסתיים (לא תיפסק באמצע). למה false ולא true? כי ביטול פריסה באמצע יכול להשאיר את האתר במצב לא ברור.
• configure-pages@v5 — קורא את הגדרות Pages מהריפו (base URL, CNAME, וכו') ומעביר אותם ל-build process. חשוב במיוחד כשיש custom domain.
• upload-pages-artifact@v3 — אורז את התיקייה שמצביעים עליה ב-path כ-artifact מוכן לפרסום. ה-artifact חייב להיות מתחת ל-10GB (בפועל, אתרים סטטיים כמעט אף פעם לא מגיעים לשם).
• deploy-pages@v4 — לוקח את ה-artifact שהועלה ופורס אותו ל-Pages. חייב לרוץ ב-environment: github-pages — זה ה-environment המיוחד שמנהל את Pages.
• workflow_dispatch — מאפשר להפעיל את ה-workflow ידנית מטאב Actions. שימושי לפריסה מחדש בלי push, או לדיבאגינג.

חשוב: לפני שה-workflow יעבוד, ודאו ש-Settings → Pages → Source מוגדר ל-GitHub Actions (לא Deploy from a branch). אם המצב לא נכון, ה-workflow ירוץ ויצליח — אבל האתר לא יתעדכן.

דוגמה: אתר React עם Vite

אם יש לכם אפליקציית React שנבנית עם Vite, ה-build job ייראה כך:

  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: 'npm'
      - run: npm ci
      - run: npm run build
      - uses: actions/configure-pages@v5
      - uses: actions/upload-pages-artifact@v3
        with:
          path: './dist'    # Vite מייצר לתיקיית dist

דוגמה: אתר Astro

  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: 'npm'
      - run: npm ci
      - run: npm run build
      - uses: actions/configure-pages@v5
      - uses: actions/upload-pages-artifact@v3
        with:
          path: './dist'    # Astro מייצר לתיקיית dist

דוגמה: אתר Hugo (בלי Node.js)

  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: peaceiris/actions-hugo@v3
        with:
          hugo-version: 'latest'
          extended: true
      - run: hugo --minify
      - uses: actions/configure-pages@v5
      - uses: actions/upload-pages-artifact@v3
        with:
          path: './public'    # Hugo מייצר לתיקיית public

שימו לב לתבנית: כל הדוגמאות חולקות אותו מבנה — checkout, setup, build, configure-pages, upload-artifact. השינוי היחיד הוא ב-build tool ובתיקיית הפלט (dist, public, build).

3.6 דומיין מותאם — מ-github.io לדומיין שלך

כתובת username.github.io היא סבבה ללמידה ולפרויקטים אישיים, אבל לאתר רציני — אתר עסקי, portfolio מקצועי, או פרויקט שרוצים שאנשים יזכרו — צריך דומיין משלכם. GitHub Pages תומך בדומיינים מותאמים עם HTTPS אוטומטי חינמי דרך Let's Encrypt, בלי שתשלמו שקל נוסף מעבר למחיר הדומיין עצמו.

יש שני סוגי חיבור, ואפשר גם את שניהם יחד:

סוג 1: Subdomain (מומלץ להתחלה)

אם יש לכם דומיין example.com ורוצים www.example.com או blog.example.com:

למה CNAME עדיף? כי GitHub יכול לשנות IP addresses מבלי שתצטרכו לעדכן DNS. ה-CNAME מצביע על שם (username.github.io) ולא על IP — אז אם GitHub מעביר שרתים, הכל ממשיך לעבוד.

סוג 2: Apex Domain (root domain)

אם רוצים example.com ישירות (בלי www), צריך A records כי apex domains לא תומכים ב-CNAME (זו מגבלה של DNS, לא של GitHub):

מומלץ גם להוסיף רשומות AAAA (IPv6) לתמיכה מלאה:

השילוב המומלץ: הגדירו גם www (CNAME) וגם apex (A records). ב-GitHub Pages Settings, הכניסו את הדומיין עם www (למשל www.example.com). GitHub יפנה אוטומטית מ-apex ל-www (או להיפך, תלוי מה הגדרתם).

הגדרה ב-GitHub — שלב אחר שלב

1. היכנסו ל-Settings → Pages
2. תחת Custom domain, הכניסו את הדומיין (למשל www.example.com)
3. לחצו Save — GitHub יבדוק DNS ויציג סטטוס
4. המתינו עד שה-DNS check יעבור (כפתור ירוק) — אם עדיין אדום, ה-DNS עדיין לא התעדכן
5. סמנו את Enforce HTTPS — אם האפשרות אפורה, ה-DNS עדיין לא מחובר; חכו ונסו שוב

מה קורה מאחורי הקלעים: כשאתם שומרים custom domain, GitHub יוצר קובץ CNAME בשורש הריפו שלכם (אם אתם במצב branch-based). הקובץ מכיל את שם הדומיין בלבד. אם אתם במצב Actions — ה-workflow צריך להשתמש ב-configure-pages@v5 שקורא את הגדרת הדומיין.

DNS propagation: שינויי DNS יכולים לקחת עד 24 שעות (בחלק מהרשמים הישראליים — עד 48 שעות). אל תיבהלו אם זה לא עובד מיד. אפשר לבדוק עם dig www.example.com בטרמינל אם ה-DNS כבר התעדכן.

טיפ ישראלי: דומיינים של .co.il עובדים מצוין עם GitHub Pages. הגדירו את הרשומות אצל הרשם שלכם (Namecheap, Cloudflare, GoDaddy, או ספק ישראלי כמו InterHost) בדיוק כמו בטבלאות למעלה. שימו לב ש-.co.il לפעמים דורש זמן propagation ארוך יותר מ-.com.

אימות דומיין: מומלץ מאוד לאמת את הדומיין שלכם ברמת המשתמש או הארגון: Settings (של חשבון, לא של ריפו) → Pages → Verified domains. זה מונע ממישהו אחר לחבר את הדומיין שלכם לריפו שלו (מה שנקרא domain takeover) — בעיית אבטחה אמיתית שכדאי למנוע.

3.7 404 מותאם ו-SPA Routing

Custom 404

כשמשתמש מגיע לנתיב שלא קיים באתר שלכם (למשל, טעות כתיב ב-URL, לינק שבור, או עמוד שנמחק), GitHub Pages מחפש קובץ 404.html בשורש. אם הוא קיים — הוא מוצג (עם HTTP status 404). אם לא — מוצג דף 404 גנרי ומכוער של GitHub עם לוגו ושום דבר שימושי.

דף 404 טוב הוא לא רק "הדף לא נמצא" — הוא הזדמנות. הוא יכול להכיל: ניווט חזרה לעמוד הראשי, שורת חיפוש, לינקים לדפים הכי פופולריים, או אפילו הומור שמשאיר את המשתמש באתר במקום ללחוץ Back.

צרו 404.html עם עיצוב שתואם לאתר שלכם:

<!DOCTYPE html>
<html lang="he" dir="rtl">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>404 — הדף לא נמצא</title>
    <style>
        body {
            font-family: -apple-system, sans-serif;
            text-align: center;
            padding: 4rem 2rem;
            background: #0d1117;
            color: #e6edf3;
        }
        h1 { font-size: 4rem; color: #a855f7; margin-bottom: 0.5rem; }
        p { font-size: 1.2rem; color: #8b949e; }
        a { color: #58a6ff; text-decoration: none; }
        a:hover { text-decoration: underline; }
        .links { margin-top: 2rem; }
        .links a { margin: 0 1rem; }
    </style>
</head>
<body>
    <h1>404</h1>
    <p>הדף שחיפשת לא קיים. אולי הכתובת השתנתה, או שיש טעות ב-URL.</p>
    <div class="links">
        <a href="/">חזרה לעמוד הראשי</a>
    </div>
</body>
</html>

SPA Routing Workaround

אם בניתם אפליקציית Single Page Application (React Router, Vue Router, Angular Router, וכו'), כל הניתוב קורה בצד הלקוח ב-JavaScript. כלומר, כש-URL משתנה מ-/ ל-/about, ה-JavaScript מטפל בזה — הדפדפן לא שולח בקשה חדשה לשרת.

אבל יש בעיה: כשהמשתמש מרענן דף פנימי כמו /about, או שולח את הלינק למישהו, הדפדפן שולח בקשה לשרת של GitHub Pages שמחפש קובץ about/index.html — ומחזיר 404 כי הקובץ לא קיים. כל הנתיבים קיימים רק ב-JavaScript, לא כקבצים פיזיים.

Workaround: יצירת 404.html שמפנה ל-index.html תוך שמירה על הנתיב המקורי:

<!-- 404.html — שומר את הנתיב ומפנה ל-index.html -->
<script>
  // שומר את הנתיב כ-query parameter ומפנה לעמוד הראשי
  const path = window.location.pathname + window.location.search;
  window.location.replace('/?redirect=' + encodeURIComponent(path));
</script>

<!-- ב-index.html (הוסיפו לפני ה-script של האפליקציה) -->
<script>
  const params = new URLSearchParams(window.location.search);
  const redirect = params.get('redirect');
  if (redirect) {
    window.history.replaceState(null, '', redirect);
  }
</script>

איך זה עובד: (1) משתמש מגיע ל-/about, (2) GitHub Pages מחזיר 404.html (עם status 404), (3) ה-JavaScript ב-404 מפנה ל-/?redirect=%2Fabout, (4) ה-JavaScript ב-index.html משחזר את הנתיב /about ב-URL bar, (5) ה-SPA router לוקח שליטה ומציג את הדף הנכון.

אלטרנטיבה פשוטה יותר: השתמשו ב-hash-based routing (/#/about במקום /about). Hash routes (החלק אחרי #) לא נשלחים לשרת כלל, אז הבעיה לא קיימת. ב-React Router: HashRouter במקום BrowserRouter. ב-Vue Router: createWebHashHistory().

שימו לב לבעיית SEO: ה-workaround מחזיר HTTP 404 לפני ההפניה. מנועי חיפוש רואים את ה-404 ולא מאנדקסים את הדף. לאתרי SPA רציניים עם דרישות SEO (שרוצים שגוגל ימצא את כל הדפים), שקלו Vercel או Netlify שתומכים ב-redirect rules נאטיביים, או שימוש ב-SSG (Static Site Generation) שמייצר HTML לכל נתיב בזמן build.

3.8 SEO בסיסי לאתרי Pages

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

Meta Tags חובה בכל דף

<head>
    <!-- כותרת — מופיעה בלשונית הדפדפן ובתוצאות חיפוש -->
    <title>שם האתר — שם הדף</title>

    <!-- תיאור — מופיע מתחת לכותרת בתוצאות חיפוש -->
    <meta name="description" content="תיאור של הדף ב-150-160 תווים.
     תכתבו משפט שמזמין לחיצה.">

    <!-- URL קנוני — אומר למנועי חיפוש מה הכתובת הרשמית -->
    <link rel="canonical" href="https://example.com/page">

    <!-- Open Graph — לשיתוף ברשתות חברתיות -->
    <meta property="og:title" content="שם הדף">
    <meta property="og:description" content="תיאור הדף">
    <meta property="og:image" content="https://example.com/og-image.png">
    <meta property="og:url" content="https://example.com/page">
    <meta property="og:type" content="website">

    <!-- Twitter Card — לשיתוף ב-Twitter/X -->
    <meta name="twitter:card" content="summary_large_image">
    <meta name="twitter:title" content="שם הדף">
    <meta name="twitter:description" content="תיאור הדף">
    <meta name="twitter:image" content="https://example.com/og-image.png">
</head>

טיפ על og:image: הגודל המומלץ הוא 1200x630 פיקסלים. תמונה טובה לשיתוף ברשתות עושה הבדל עצום — היא מה שאנשים רואים לפני שהם מחליטים ללחוץ. אל תוותרו על זה.

robots.txt

# robots.txt — בשורש האתר
User-agent: *
Allow: /
Sitemap: https://example.com/sitemap.xml

הקובץ הזה אומר למנועי חיפוש: "תאנדקסו הכל, וה-sitemap נמצא בכתובת הזו". אם יש דפים שלא רוצים לאנדקס (למשל, draft pages), אפשר להוסיף Disallow: /drafts/.

sitemap.xml

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/</loc>
    <lastmod>2026-04-01</lastmod>
    <changefreq>monthly</changefreq>
  </url>
  <url>
    <loc>https://example.com/about</loc>
    <lastmod>2026-04-01</lastmod>
    <changefreq>monthly</changefreq>
  </url>
</urlset>

אם יש לכם הרבה דפים, עדכון ידני של sitemap מייגע. אפשרויות: (1) Jekyll מייצר sitemap אוטומטית עם jekyll-sitemap plugin, (2) ב-Astro/Hugo/11ty — יש plugins שמייצרים sitemap בזמן build, (3) אפשר לכתוב script פשוט שסורק את הקבצים ומייצר sitemap.

Semantic HTML

מעבר ל-meta tags, המבנה של ה-HTML עצמו משפיע על SEO:

• <h1> — כותרת ראשית, אחת לכל דף. זה מה שמנוע החיפוש מבין כנושא העיקרי של הדף.
• <h2>, <h3> — תתי-כותרות בהיררכיה. אל תדלגו רמות (אל תעברו מ-h1 ל-h3).
• <nav>, <main>, <article>, <footer> — elements סמנטיים שעוזרים למנועי חיפוש (ולקוראי מסך) להבין את מבנה הדף.
• alt בתמונות — תיאור טקסטואלי לכל תמונה. חשוב ל-SEO וגם ל-accessibility.

JSON-LD לתוצאות עשירות

אם רוצים תוצאות עשירות בגוגל (Rich Snippets) — למשל, FAQ, HowTo, או Breadcrumbs — מוסיפים JSON-LD ב-head:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "name": "שם האתר",
  "url": "https://example.com",
  "description": "תיאור האתר"
}
</script>

כלים חינמיים לבדיקה

• Google Search Console — רשמו את האתר (חינם) כדי לעקוב אחרי אינדוקס, שגיאות, ודפים שנמצאו.
• Facebook Sharing Debugger — בדקו איך הקישור שלכם נראה כשמשתפים ב-Facebook.
• Twitter Card Validator — בדקו איך הקישור נראה ב-Twitter/X.
• Lighthouse (בתוך Chrome DevTools) — ציון SEO, ביצועים, accessibility, ו-best practices. אתרי Pages סטטיים בדרך כלל מקבלים ציונים גבוהים.

3.9 מגבלות — מה Pages לא יכול לעשות

GitHub Pages הוא מצוין למה שהוא, אבל חשוב לדעת את הגבולות לפני שמתחילים — לא אחרי שכבר בניתם חצי אתר וגיליתם שהפלטפורמה לא תומכת במה שצריך.

מגבלות טכניות

מה Pages לא יכול לעשות — בכלל:

• Server-side code — אין PHP, Node.js, Python server, Ruby server, Go server. אפס. סטטי בלבד. הקבצים מוגשים כמו שהם.
• בסיס נתונים — אין MySQL, PostgreSQL, MongoDB, SQLite server. אי אפשר לשמור מידע בצד השרת.
• טפסים — אין form handling מובנה. אם משתמש ממלא טופס — אין לאן לשלוח אותו. צריך שירות חיצוני כמו Formspree, FormSubmit, Tally, או שליחה ל-Google Forms.
• Authentication — אין login, password protection, או user management. אתרי Pages תמיד ציבוריים לכל העולם (Enterprise Cloud = יוצא דופן).
• Redirect rules — אין קובץ _redirects כמו ב-Netlify או vercel.json. הפניות דורשות JavaScript client-side (meta refresh או window.location).
• Serverless functions — אין Edge Functions, Lambda, Workers, או כל צורה של function-as-a-service. לפונקציות צריך Vercel, Netlify, או Cloudflare Workers.
• Custom headers — אין דרך לקבוע HTTP headers מותאמים (כמו CORS, CSP, Cache-Control, Security headers). GitHub קובע אותם.
• Server-side redirects (HTTP 301/302) — אי אפשר להגדיר redirect ברמת ה-HTTP. רק client-side.

לכל מגבלה יש workaround: טפסים עם Formspree או Tally, authentication עם Auth0, Clerk, או Supabase Auth, backend עם Cloudflare Workers או AWS Lambda, redirect עם JavaScript. אבל ברגע שצריכים 3-4 workarounds — אולי עדיף לעבור לפלטפורמה שעושה את זה נאטיבית.

3.10 Pages vs Vercel vs Netlify vs Cloudflare — טבלת החלטה

GitHub Pages הוא לא הבחירה היחידה לאירוח אתרים סטטיים. ב-2026 יש כמה פלטפורמות מצוינות שמציעות free tier נדיב. הבחירה הנכונה תלויה במה שצריכים — ולא תמיד הפלטפורמה הכי מתקדמת היא הנכונה. לפעמים הפשוט ביותר הוא הטוב ביותר.

3.11 שימושים נפוצים — מה אנשים באמת בונים

GitHub Pages הוא לא רק "פיצ'ר של GitHub" — הוא מפעיל מיליוני אתרים, מאתרים אישיים קטנים ועד דוקומנטציה של פרויקטים עם מיליוני משתמשים. הנה השימושים הנפוצים ביותר, עם דוגמאות שאפשר להסתכל עליהן:

1. דוקומנטציה לפרויקטי קוד פתוח

זה השימוש הנפוץ ביותר ב-Pages, ובצדק. פרויקטים גדולים כמו React, Bootstrap, Tailwind CSS ו-Jekyll עצמו משתמשים ב-Pages (או בשירותים דומים מבוססי GitHub) לדוקומנטציה שלהם. היתרון: הקוד והדוקומנטציה באותו ריפו — שינוי ב-docs = עדכון אוטומטי באתר. Contributors יכולים לשפר את הדוקומנטציה דרך PR, בדיוק כמו קוד.

2. Portfolio / קורות חיים

אתר אישי עם הפרויקטים, הכישורים, ופרטי הקשר שלכם. הכתובת username.github.io כבר אומרת "אני מפתח/ת" — ומי שמגייס יודע לבדוק שם. הוסיפו דומיין מותאם לרושם יותר מקצועי. טיפ: כלים כמו Resume CLI מייצרים portfolio אוטומטית מפרופיל GitHub.

3. בלוג

Jekyll + Markdown = בלוג חינמי בלי תשלום חודשי ובלי מודעות. כותבים post חדש בקובץ Markdown, עושים push, האתר מתעדכן. תמות מוכנות חוסכות את כל העיצוב. לבלוג יותר מתקדם (מהיר יותר, תמיכה ב-components), שקלו Hugo או Astro עם Actions.

4. Landing Page לפרויקט או מוצר

דף נחיתה שמסביר מה הפרויקט עושה, עם screenshots, GIF של demo, וקישור להורדה או התקנה. חינמי, מהיר, ומשולב ב-GitHub — כך שהמשתמש רואה את הדף ויכול מיד לעבור לריפו.

5. אתרים ארגוניים קטנים

עמותות, ארגונים קטנים, ופרויקטי קהילה שלא צריכים backend יכולים לחסוך מאות שקלים בחודש באירוח עם Pages. האתר מהיר, מאובטח (HTTPS חינמי), ולא צריך תחזוקת שרת.

6. אתרי קורסים ומדריכים

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

7. סטטוס דפים (Status Pages)

אתרים שמציגים את מצב השירותים שלכם (online/offline). כלים כמו Upptime משתמשים ב-GitHub Actions + Pages כדי לבנות status page חינמי לגמרי — בלי שרת צד שלישי.

3.12 סיכום ומבט קדימה

בפרק הבא: נעבור מאתרים לסביבות פיתוח — GitHub Codespaces. נלמד להקים סביבת עבודה מלאה בענן, עם devcontainer.json, prebuilds, ושליטה בעלויות. תוכלו לערוך את אתר ה-Pages שלכם מכל מקום בעולם, מכל דפדפן, בלי להתקין שום דבר על המחשב.