מדריך
בדיקות לפני עלייה לאוויר
עשר הבדיקות שאני עושה לפני שאתר עולה לאוויר, עם פקודה מוכנה לקלוד ובדיקה ידנית לכל אחת
קלוד בונה מהר, אבל הוא בונה מה שמבקשים ממנו. אלה עשר הבדיקות שאני עושה לפני שאתר או מערכת עולים לאוויר. לכל בדיקה יש פקודה מוכנה לקלוד ובדיקה ידנית של חצי דקה. את הפקודות מריצים ב-Claude Code (או בכל סוכן קוד אחר) מתוך תיקיית הפרויקט.
אין זמן? פקודה אחת לכולן
בדיקה כללית לפני עלייה לאוויר:
לפני שהפרויקט עולה לאוויר, תעבור על עשר הבדיקות האלה ותחזיר לי טבלה: בדיקה | עבר / נכשל / לא רלוונטי | מה מצאת | איך מתקנים.
1. אבטחה: פרצות, הרשאות, סיסמאות או משתמשי ברירת מחדל בקוד, הגבלת ניסיונות, חבילות עם חולשות ידועות
2. נגישות לפי WCAG 2.1 AA (ת"י 5568): ניגודיות, מקלדת, פוקוס, alt, תוויות, חלונות קופצים
3. מדיניות פרטיות: קיימת? תואמת למה שהאתר באמת אוסף ולאן הוא שולח?
4. טפסים: כל טופס באמת שולח את הנתונים ליעד אמיתי, ומציג שגיאה אם השליחה נכשלה
5. הצהרת נגישות: קיימת, עם קישור בפוטר
6. מובייל: 360, 390 ו-768 פיקסלים, בלי גלילה לצדדים, כפתורים בגודל נוח ללחיצה
7. מהירות טעינה: תמונות, גופנים, קבצים כבדים, מצב פרודקשן
8. SEO ותמונת שיתוף: title, description, Open Graph, sitemap, robots
9. קישורים שבורים: קישורים פנימיים, תמונות, עוגנים ועמוד 404
10. מפתחות API: אין מפתחות או סודות בקוד צד לקוח, ב-git או ב-build
אל תשנה כלום. תציג לי את הטבלה ותחכה לאישור שלי לפני שאתה מתקן.1. בדיקת אבטחה
אצלי הבדיקה מצאה 12 בעיות, ואחת מהן הייתה סיסמת מנהל שכתובה בתוך הקוד. ב-Claude Code יש פקודה מובנית: /security-review. כדאי להריץ גם אותה וגם את הפקודה המלאה.
תעשה בדיקת אבטחה מלאה לפרויקט, בלי לשנות קוד:
- התחברות והרשאות: כל משתמש רואה ומשנה רק את מה שמותר לו? יש בדיקה בצד השרת ולא רק בממשק?
- סיסמאות, משתמשי אדמין או נתוני דמו שכתובים בקוד
- הגבלת ניסיונות (rate limit) בהתחברות ובטפסים
- ולידציה של קלט בצד השרת (SQL injection, XSS)
- הודעות שגיאה שחושפות פרטים טכניים
- חבילות עם חולשות ידועות (npm audit או המקבילה)
- אם יש Supabase: RLS מופעל על כל טבלה
תחזיר רשימה לפי חומרה: קריטי / גבוה / בינוני / נמוך, ולכל ממצא איך מתקנים.בדיקה ידנית: פותחים חלון גלישה בסתר ומדביקים כתובת של עמוד פנימי. אם הוא נפתח בלי התחברות, יש בעיה.
2. בדיקת נגישות
אתר של עסק שנותן שירות לציבור צריך לעמוד בת"י 5568 (WCAG ברמה AA). אצלי, באחד האתרים הכפתורים לא עמדו בתקן הניגודיות, ואי אפשר היה להזמין בלי עכבר.
תבדוק נגישות לפי WCAG 2.1 ברמה AA (ת"י 5568), בלי לשנות קוד:
- סריקה אוטומטית (axe או Lighthouse)
- ובדיקה ידנית של מה שסריקה לא תופסת: ניווט מלא ב-Tab, פוקוס נראה, חלונות קופצים (הפוקוס נכנס, נשאר כלוא, וחוזר בסגירה), תוויות לכפתורי אייקון, הודעות שגיאה בטפסים, וטקסט שיושב על תמונה
תחזיר רשימה לפי חומרה ותחכה לאישור לפני שאתה מתקן. בצבעי מותג: גוון קרוב שעומד בניגודיות, לא צבע אחר.בדיקה ידנית: עוברים על כל האתר רק עם Tab. תמיד רואים איפה אתם? אפשר לשלוח טופס?
3. מדיניות פרטיות
כשביקשתי מדיניות פרטיות, קלוד החליט בשמי דברים שלא אמרתי לו, כמו כמה זמן אני שומר את הנתונים. המדיניות היא הבטחה ללקוחות, ואתם חתומים עליה.
תכתוב מדיניות פרטיות לאתר לפי חוק הגנת הפרטיות (כולל תיקון 13).
קודם תבדוק בקוד: אילו פרטים כל טופס אוסף, לאן הם נשלחים, אילו שירותים חיצוניים נטענים (גופנים, אנליטיקס, פיקסלים), והאם יש עוגיות.
אחר כך תשאל אותי כל מה שאי אפשר לדעת מהקוד: פרטי העסק, למי המידע מועבר, כמה זמן שומרים אותו, ואם שולחים דיוור. תחכה לתשובות.
כל מה שלא נמסר לך: תסמן [למלא] ואל תנחש. בסוף תוסיף רשימה של ההתחייבויות שצריך לקיים בפועל.4. הטפסים באמת שולחים
באחד האתרים שקלוד בנה לי, הטופס הציג "תודה, נחזור אליכם", והנתונים לא נשלחו לשום מקום. אין שגיאה ואין התראה, ולכן אף אחד לא שם לב.
תמצא כל טופס בפרויקט ותבדוק לאן הנתונים שלו באמת נשלחים.
- תסמן כל טופס שמציג הודעת הצלחה בלי לשלוח בפועל (למשל setTimeout ואז "תודה")
- תוודא שאם השליחה נכשלת, המשתמש רואה שגיאה ולא "תודה"
- תוודא שיש הגנה בסיסית מספאם
תציג לי טבלה: טופס | לאן נשלח | מה קורה בכישלון. אל תחבר שום שירות לפני שאני מאשר לאן.בדיקה ידנית: ממלאים כל טופס עם הפרטים שלכם, ומוודאים שהפנייה באמת הגיעה: למייל, לגיליון או למערכת.
5. הצהרת נגישות
דרישה נפרדת מהנגישות עצמה: עמוד שמפרט מה הונגש באתר, ואיך פונים לרכז הנגישות.
תיצור עמוד הצהרת נגישות בעברית, ותוסיף אליו קישור בפוטר של כל העמודים.
העמוד יכלול: רמת הנגישות (ת"י 5568, WCAG AA), מה הונגש באתר בפועל (רק מה שבאמת קיים בקוד), מגבלות ידועות, ופרטי פנייה לרכז נגישות.
פרטים שאתה לא יודע (שם הרכז, טלפון, הסדרי נגישות פיזיים בעסק, תאריך בדיקה): תסמן [למלא].בדיקה ידנית: לוודא שלא נשאר אף [למלא], ושמישהו באמת עונה לפרטי הפנייה.
6. תצוגה במובייל
רוב הגולשים מגיעים מהטלפון, ומה שנראה מושלם במחשב יכול להישבר במסך צר.
תבדוק את כל העמודים ברוחב 360, 390 ו-768 פיקסלים (אפשר עם Playwright ולצלם מסך לכל אחד).
תחפש: גלילה לצדדים, טקסט או כפתורים שנחתכים, כפתורים קטנים מדי ללחיצה (מומלץ לפחות 44 פיקסלים), תפריט שלא נפתח, טבלאות רחבות, ושדות טופס בלי סוג מקלדת מתאים (tel, email).
תציג לי את הממצאים עם צילומי המסך לפני שאתה מתקן.בדיקה ידנית: פותחים את האתר בטלפון שלכם, ממלאים טופס אחד עד הסוף ולוחצים על כל כפתור בתפריט.
7. מהירות טעינה
אתר איטי מאבד גולשים לפני שהם בכלל ראו אותו. בדרך כלל האשמים הם תמונות כבדות וקבצים שלא דחוסים.
תריץ Lighthouse במצב מובייל על העמודים הראשיים, על גרסת פרודקשן ולא במצב פיתוח.
תבדוק: תמונות כבדות או בלי פורמט מודרני (WebP/AVIF) ובלי lazy loading, גופנים שחוסמים טעינה, קבצי JS ו-CSS גדולים או לא דחוסים, ובקשות מיותרות.
תציג לי ציון וממצאים, ואחרי שאני מאשר תתקן ותריץ שוב כדי להראות לפני ואחרי.בדיקה ידנית: ב-Chrome: F12 ← Lighthouse ← Mobile ← Analyze.
8. SEO ותמונת שיתוף
בלי כותרת, תיאור ותמונת שיתוף, האתר לא יופיע טוב בגוגל, וכשמשתפים אותו בוואטסאפ מקבלים קישור ריק.
תבדוק SEO בסיסי בכל העמודים:
- title ו-meta description ייחודיים לכל עמוד, h1 אחד בכל עמוד, lang="he" ו-dir="rtl"
- תגיות Open Graph (og:title, og:description, og:image בגודל 1200×630) ו-Twitter card
- favicon, sitemap.xml ו-robots.txt
- אם האתר הוא אפליקציית צד לקוח (SPA): האם התוכן מגיע לגוגל, או שהוא רואה עמוד ריק
תציג מה חסר לפני שאתה מוסיף.בדיקה ידנית: שולחים לעצמכם את הקישור בוואטסאפ ובודקים שמופיעים תמונה, כותרת ותיאור.
9. קישורים שבורים
קישור שמוביל ל-404 או תמונה שלא נטענת נראים לא מקצועיים, ופוגעים גם בגוגל.
תעבור על כל הקישורים, התמונות והעוגנים (#) בפרויקט, ותבדוק שכולם מובילים ליעד קיים.
תבדוק גם: קישורי tel ו-mailto תקינים, קישורים חיצוניים שעדיין עובדים, כפתורים שמובילים ל-"#" ריק, ושיש עמוד 404 מעוצב.
תחזיר רשימה של כל מה ששבור, עם המיקום בקוד.בדיקה ידנית: לוחצים על כל פריט בתפריט ובפוטר, ופותחים כתובת שלא קיימת כדי לראות את עמוד ה-404.
10. מפתחות API מוסתרים
מפתח שמגיע לדפדפן גלוי לכל גולש. מי שמעתיק אותו יכול להשתמש בשירות על חשבונכם.
תחפש בכל הפרויקט מפתחות וסודות שלא אמורים להיות גלויים:
- בקוד צד הלקוח ובקבצי ה-build (למשל sk-, AKIA, service_role, private key, token)
- בקבצים שנכנסו ל-git, כולל ההיסטוריה
- קבצי .env: נמצאים ב-.gitignore? יש .env.example בלי ערכים אמיתיים?
- קריאות לשירותי AI או תשלומים: יוצאות מהשרת ולא מהדפדפן?
אם מצאת מפתח שנחשף, תגיד לי ואל תמחק אותו בעצמך. מפתח שנחשף צריך להחליף אצל הספק, לא רק להסיר מהקוד.בדיקה ידנית: ב-Chrome: F12 ← Sources, וחיפוש (Cmd+Option+F) של key, sk-, token.
רוצים להעמיק?
יש לי מדריכים מלאים לשתיים מהבדיקות: נגישות עם קלוד ומדיניות פרטיות עם AI.
רוצים ללמוד לבנות בעצמכם?
שיעורים לפי הסדר, מהצעד הראשון.