המאמר הזה הוא סיכום של איך בניתי את מאגר הידע הזה בעצמו, ובעיקר — מה חשוב לי בדרך. כתבתי אותו כדי שלעצמי העתידי (ולכל AI שאעבוד איתו בהמשך) תהיה נקודת מוצא אחת: לא רק "מה עשינו" אלא "למה כך ולא אחרת". העקרונות כאן חוזרים על עצמם — פשטות, מרכוז, כנות, וכלים מקומיים שלא דולפים החוצה — והם אותם עקרונות שאני מנסה להחיל על כל דבר שאני בונה.
אתר סטטי, בלי framework
המאגר הזה הוא אוסף קובצי HTML פשוטים — עמוד אחד לכל דף, בלי React, בלי שלב build, בלי שרת שרץ ברקע. הבחירה הזו מכוונת. אתר סטטי הוא זול לאחסון, מהיר, וכמעט בלתי ניתן לשבירה: אין תלות בגרסאות של חבילות, אין מה "להישבר" בעדכון, וכל דף נשאר קריא כקוד גם בעוד חמש שנים. כשמשהו פשוט מספיק, הוא שורד.
מנוע ניווט מרכזי אחד
כל מה שחוזר בכל דף — תפריט הצד, פירורי הלחם, הפוטר, הפאביקון, כפתור מצב בהיר/כהה — לא כתוב בכל קובץ בנפרד. הוא מוזרק בזמן ריצה מקובץ JavaScript אחד. כל דף מכיל רק את התוכן הייחודי שלו ושלד ריק, והמנוע ממלא את השאר. המשמעות: שינוי בתפריט הצד = עריכה אחת שמשפיעה על עשרות דפים, במקום לגעת בכל אחד מהם.
כדי שהמנוע יידע להתאים כל דף לעצמו, כל דף מצהיר על עצמו דרך תכונות
על תג ה-<body>:
| תכונה | למה היא משמשת |
|---|---|
| data-depth | כמה תיקיות הדף נמצא מתחת לשורש, כדי לבנות נתיבים יחסיים נכונים |
| data-page | הנתיב היחסי של הדף, כדי לסמן איפה אנחנו נמצאים בתפריט |
| data-crumbs | פירורי הלחם של הדף |
| data-updated | תאריך העדכון של הדף, שמוצג בפוטר |
כדי להוסיף דף חדש אני עושה שני דברים בלבד: מוסיף רשומה במנוע הניווט, ויוצר קובץ מתוך תבנית. אין קוד כפול, ואין מקום לשכוח לעדכן משהו בדף אחד מתוך רבים.
מרכוז: לא לכתוב את אותו דבר פעמיים
זה העיקרון שחוזר הכי הרבה. כל תוכן שזהה בכל הדפים צריך לחיות
במקום אחד; כל תוכן שהוא ייחודי לדף צריך לחיות על הדף עצמו. הדוגמה
הכי טובה היא הפוטר: המשפט "יניב אפרים — מאגר ידע אישי…" זהה בכל
עשרות הדפים, אז הוא מוזרק ממקום אחד. לעומתו, תאריך העדכון שונה
מדף לדף, אז הוא יושב על ה-<body> של כל דף בנפרד.
תבניות
לכל סוג דף יש תבנית מוכנה: אחת לעמוד "רכזת" של קטגוריה (עם כרטיסים לכתבות שבתוכה), ואחת לעמוד כתבה בודדת. התבניות כוללות את השלד הנכון, את התכונות שצריך למלא, והערות פנימיות שמסבירות מה להחליף. כך כל דף חדש נולד עקבי עם השאר, ואני לא ממציא מבנה מחדש בכל פעם.
עברית, RTL, ושמות לועזיים
האתר כולו בעברית ובכיוון ימין-לשמאל. כלל אחד שחשוב לי ושחוזר בכל מקום: שמות של מותגים, מוצרים ומושגים בעלי-שם נשארים באותיות לטיניות גם באמצע משפט בעברית — GitHub, WhatsApp, Zero Inbox, JavaScript. תרגום או תעתיק שלהם רק מבלבל. הטיפוגרפיה נשענת על שני גופנים בלבד (Frank Ruhl Libre לכותרות, Assistant לגוף הטקסט), כדי לשמור על מראה אחיד ונקי.
פאביקון
פאביקון הוא האייקון הקטן שמופיע בלשונית הדפדפן, במועדפים, ובתוצאות
חיפוש בגוגל לצד כתובת האתר. זה נשמע כמו פרט קוסמטי זניח, אבל
בלעדיו האתר מקבל אייקון ברירת מחדל גנרי, וזה אחד הדברים הראשונים
שגורמים לאתר להרגיש "לא גמור". אצלי זה קובץ SVG קטן אחד
(assets/favicon.svg) שמנוע הניווט מזריק לכל דף
באופן אוטומטי — כך שאין סיכוי לשכוח אותו כשמוסיפים דף חדש.
מרווחים בצדדים במובייל
טעות נפוצה: טקסט שנוגע ממש בקצוות המסך במובייל, בלי שום ריפוד.
זה קורה כשמסתמכים על הרוחב המלא של המסך בלי לחשוב על מסכים צרים,
והתוצאה היא טקסט שקשה לקרוא כי אין לעין "מנוחה" בצדדים. הפתרון
הפשוט הוא לא להוסיף ריפוד בכל רכיב בנפרד, אלא לעטוף כל תוכן
במחלקת עטיפה משותפת אחת עם ריפוד קבוע בצדדים (padding: 0
28px), כך שגם רכיב חדש שנוסף בעתיד "יורש" את המרווח הנכון
בלי מאמץ נוסף ובלי לזכור להוסיף אותו שוב.
איך הקישור נראה כשמשתפים אותו
כשמישהו שולח קישור לאתר בוואטסאפ, בסלאק או באימייל, האפליקציה
בונה כרטיסיית תצוגה מקדימה — כותרת, תיאור קצר, ולפעמים תמונה.
בלי תגיות מיוחדות בקוד, הכרטיסייה יוצאת דלה או לא מוצגת בכלל,
וזה פוגע באמינות הקישור עוד לפני שמישהו לוחץ עליו. התגיות
שאחראיות על זה נקראות Open Graph (og:title,
og:description, og:image) ותגי
Twitter Card המקבילים.
<head> של כל דף בקובץ עצמו,
לא מוזרקות דינמית.
מכיוון שלכל דף כאן כבר יש כותרת ותיאור ייחודיים (אותם
title ו-meta description), הוספתי
סקריפט קטן חד-פעמי (tools/gen-og-tags.js) שמעתיק
אותם לתגיות og:title ו-og:description
בכל קובץ בבת אחת, במקום להעתיק ידנית לכל דף בנפרד. תוך כדי
הריצה הראשונה שלו הוא גם גילה לי באג אמיתי: בדף אחד תיאור
המטא הכיל מירכאות מוברחות בסגנון \" במקום ישות
HTML תקנית ("), מה שקטע את התגית עצמה
באמצע. סקריפט שמריץ regex פשוט על כל הקבצים חושף באגים כאלה
הרבה יותר מהר מקריאה ידנית.
מצב בהיר וכהה בלי הבהוב
יש מתג שמחליף בין מצב בהיר לכהה, וההעדפה נשמרת בדפדפן. פרט קטן אך חשוב: סקריפט זעיר בראש כל דף מחיל את המצב הנבחר עוד לפני שהעמוד מצויר, כדי שלא יהיה "הבהוב" של רקע לבן לפני שהמצב הכהה נטען. חוויית משתמש טובה נמצאת בדיוק בפרטים הקטנים האלה.
העמודים המשפטיים
לכל אתר, גם אישי, כדאי שיהיו ארבעה עמודים בסיסיים, והם מקושרים מהפוטר של כל דף:
- הצהרת נגישות — הצהרה על מידת הנגישות של האתר ואיך לפנות אם משהו לא נגיש. זה עניין של כבוד למשתמשים, ובמקומות רבים גם דרישה חוקית.
- הצהרת פרטיות — מה נאסף על המבקרים ומה נעשה עם זה. אצלי המדיניות פשוטה כי האתר כמעט לא אוסף כלום — וזה בדיוק העניין: ההצהרה חייבת לשקף את מה שהאתר באמת עושה, לא נוסח גנרי שהודבק.
- תנאי שימוש — הכללים והגבולות לשימוש בתוכן.
- מדיניות עוגיות — אילו עוגיות או אחסון מקומי בשימוש. אצלי זה מסתכם באחסון מקומי להעדפת מצב התצוגה — ואת זה יש לומר בכנות, בלי להפריז ובלי להסתיר.
נראות: כמה עקרונות ל-SEO ול-GEO
מעבר לתגיות עצמן, יש כמה עקרונות שמשפיעים על הסיכוי שהאתר יופיע בתוצאות חיפוש (SEO — Search Engine Optimization) ועל הסיכוי שמנועי AI כמו ChatGPT, Perplexity או Google AI Overviews יצטטו או ישתמשו בתוכן שלו כשהם עונים על שאלה (GEO — Generative Engine Optimization). חלק מהעקרונות האלה כבר קיימים באתר הזה כתוצר לוואי של איך שהוא נבנה, וחלק הם דברים שכדאי להוסיף.
מה כבר עובד לטובתי
- HTML גולמי, בלי תלות ב-JavaScript לתוכן עצמו — מנועי חיפוש ומנועי AI קוראים את התוכן ישירות מה-HTML, בלי צורך "להריץ" את האתר כמו דפדפן. זה ההפך מאתרי React שבהם התוכן האמיתי נטען רק אחרי הרצת JavaScript, מה שמקשה על חלק מהסורקים.
- כותרת ותיאור ייחודיים לכל דף — כל עמוד כבר
מקבל
<title>ו-meta descriptionמשלו, ולא כותרת גנרית אחת לכל האתר. - מבנה כותרות היררכי — כותרת
h1אחת בכל דף, ותת-כותרותh2שמחלקות את התוכן לנושאים ברורים. זה עוזר גם לקורא אנושי וגם למנוע לזהות איפה נמצאת התשובה לשאלה ספציפית. - קישורים פנימיים בין דפים קרובים בנושא — הקטע "קשור" בתחתית כל כתבה, וקישורים בתוך הטקסט עצמו, עוזרים למנועים להבין אילו דפים קשורים זה לזה, ומחזקים את כל האשכול הנושאי כמקשה אחת.
- כתובות URL תיאוריות — הנתיב של כל דף (למשל
parenting/raising-people-we-like.html) מתאר את התוכן שלו באנגלית ברורה, במקום מזהה טכני חסר משמעות. - lang ו-dir נכונים — כל דף מצהיר בפירוש שהוא בעברית וב-RTL, מה שעוזר גם לנגישות וגם לזיהוי שפה נכון.
- מהירות טעינה — אתר סטטי בלי framework ובלי קריאות רשת מיותרות נטען כמעט מיידית, ומהירות טעינה היא גורם ישיר בדירוג של גוגל.
- sitemap.xml ו-robots.txt — קובץ שמפרט את
כל הדפים באתר (
sitemap.xml) עוזר למנועי חיפוש לגלות דפים חדשים מהר יותר, וקובץrobots.txtמבהיר להם אילו חלקים מותר לסרוק. נוצרים אוטומטית מתאריכי העדכון של הדפים עצמם, כך שאין צורך לתחזק אותם ידנית. - תגיות Open Graph ו-Twitter Card — כל דף מכריז סטטית על הכותרת והתיאור שלו, כך שקישור לאתר נראה טוב כשמשתפים אותו בוואטסאפ, בסלאק או ברשתות חברתיות.
- תאריך עדכון גלוי — כל דף מציג "עודכן לאחרונה", וזה סימן טריות שגם גוגל וגם מנועי AI מתחשבים בו כשהם בוחרים בין כמה מקורות.
- מקוריות וקול אישי — הגורם הכי משמעותי בפועל: תוכן עם נקודת מבט אישית וספציפית (כמו הכתבות כאן) נחשב אמין ומועדף לציטוט, גם לפי גוגל (העיקרון הידוע בשם E-E-A-T — Experience, Expertise, Authoritativeness, Trust) וגם לפי מנועי AI, בדיוק כי הוא לא תוכן גנרי שאפשר למצוא בעשרות גרסאות זהות במקומות אחרים.
מה עוד כדאי להוסיף
- נתוני Schema.org מובנים (JSON-LD) — בלוק
<script type="application/ld+json">בכל דף, שמתאר במפורש "זו כתבה", "זה תאריך העדכון", "זה הנושא". זה לא משנה איך הדף נראה למבקר, אבל נותן למנועים תיאור חד-משמעי של מה שהם קוראים, במקום שינחשו מהעיצוב. - תמונת תצוגה מקדימה (og:image) — תגיות ה- Open Graph כאן כוללות כותרת ותיאור, אבל בלי תמונה — כרגע אין באתר תמונת באנר גנרית מעוצבת שמתאימה לזה. כרטיסיית השיתוף תיראה טוב יותר עם אחת.
- תוכן שעונה ישירות על שאלה בשורה הראשונה — הרגל שכבר קיים בחלק מהכתבות (למשל "ההגדרה הפשוטה ביותר...") ושווה להקפיד עליו בכל מקום: לפתוח כל כתבה או כל תת-נושא במשפט תמציתי שעונה על השאלה שבכותרת, לפני ההרחבה. מנועי AI נוטים לצטט בדיוק את סוג המשפט הזה.
- פסקאות עצמאיות — מנועי AI לעיתים קרובות שולפים פסקה בודדת מתוך דף, לא את הדף כולו. פסקה שמתחילה ב"כפי שאמרנו למעלה" בלי הקשר עצמאי מאבדת משמעות כשהיא נשלפת לבד. עדיף שכל פסקה תעמוד, ברובה, בפני עצמה.
כפתור העריכה — מצב סקירה מקומי
בניתי לעצמי כלי עריכה שמופיע רק כשאני עובד על האתר במחשב שלי: כפתור קטן שפותח סרגל, ובו אני יכול לערוך טקסט ישירות בדפדפן — כותרות, פסקאות ותקצירים — להוסיף לעצמי הערות צהובות, ולסמן קטעים מיותרים. לחיצה על "שמור" כותבת את השינויים בחזרה לקובץ המקורי בדיסק בלחיצה אחת, בלי שום דיאלוג, דרך שרת פיתוח מקומי קטן.
הדבר הכי חשוב בכלי הזה הוא מה שהוא לא עושה בייצור. הוא מוגבל לחלוטין לסביבה מקומית (localhost): באתר החי הדפדפן אפילו לא מבקש את הקובץ שלו — אפס כפתור, אפס בקשת רשת. וההערות שאני משאיר לעצמי מוסתרות כברירת מחדל, כדי שלא ידלפו למבקרים. כלי עבודה נשאר כלי עבודה, ולא הופך לחלק מהמוצר.
עמוד 404
לכל אתר צריך עמוד שגיאה מותאם למקרה שמישהו מגיע לכתובת שלא קיימת —
קישור שבור, טעות הקלדה, או דף שהוסר. במקום מסך שגיאה גנרי של
השרת, המבקר מקבל עמוד בעיצוב של האתר עם קישור חזרה הביתה.
בפלטפורמת האחסון שלי מספיק להניח קובץ 404.html בשורש,
והיא מגישה אותו אוטומטית לכל כתובת חסרה. חשוב שהעמוד הזה יהיה
עצמאי — עם העיצוב שלו בתוכו — כי הוא עלול להיטען מכתובת בכל עומק,
ואסור שהוא יישבר בגלל נתיב יחסי שגוי.
בטיחות בייצור
כמה כללים שאני שומר עליהם כדי שמה שנועד לפיתוח לא יזלוג למבקרים:
- כלי פיתוח מוגבלים לסביבה מקומית — נבדקים לפי כתובת הדפדפן, ולא נטענים בכלל באתר החי.
- תוכן מוזרק לא "מתקבע" לקובץ — כל מה שהמנוע מייצר בזמן ריצה מסומן, כך ששמירה של דף לעולם לא כותבת בטעות את תפריט הצד או הפוטר לתוך קובץ המקור. אחרת, בכל טעינה הם היו מוכפלים שוב ושוב.
- ברירת מחדל פרטית — לא לאסוף מידע שאני לא באמת צריך, ולא לחשוף פנימיות שאין סיבה לחשוף.
פריסה (deploy)
הפריסה פשוטה בכוונה: דחיפה של הקוד לענף הראשי — וזהו, האתר מתעדכן תוך דקה, בלי שלב build. הפשטות הזו היא יתרון: פחות מה שיכול להשתבש. הכלל שלי אחרי כל פריסה הוא לפתוח את האתר החי ולוודא בעיניים ששני דברים תקינים — שהתוכן מוצג כמו שצריך, ושכלי הפיתוח (כמו כפתור העריכה) באמת לא מופיעים. אמון זה טוב, בדיקה זה יותר טוב.
לאמת, לא להאמין
העיקרון האחרון הוא הכי כללי, והוא נוגע לעבודה עצמה — במיוחד בעבודה עם AI. כל שינוי נבדק בדפדפן אמיתי לפני שאני מכריז שהוא עובד: בודקים את הקונסול לשגיאות, מוודאים שהשמירה חוזרת נקייה, ולא מסתמכים על "זה אמור לעבוד". כמה מהבאגים המשמעותיים ביותר בבנייה של המאגר הזה התגלו בדיוק בזכות בדיקה כזו, אחרי שהכל נראה תקין. עדיף לגלות אותם לבד מאשר שהמבקר יגלה אותם עבורי.