בניתי עמוד נחיתה, מה עכשיו?
מה חייב להיות בכל אתר שעולה לאוויר לקהל ישראלי — לפני שהוא באמת "גמור".
נגישות
אמל"ק חוק
בישראל חוק שוויון זכויות לאנשים עם מוגבלות ותקנות הנגישות מחייבות אתרים (בתנאים מסוימים, לפי היקף פעילות) לעמוד בתקן WCAG 2.1 רמה AA. גם כשאין חובה פורמלית מדויקת למקרה שלכם — זה הסטנדרט המקצועי, שיקול משפטי (תביעות נגישות נפוצות בישראל) ושיקול עסקי (יותר משתמשים = יותר לקוחות).
בפועל: ניגודיות צבעים, ניווט מקלדת מלא, alt text לתמונות, תמיכת קורא מסך (ARIA), טפסים עם labels תקינים, focus state ברור.
הצהרת נגישות — מה חייב להיות בה
- תאריך עדכון אחרון
- רמת התאמה (בד"כ AA)
- ערוץ פנייה לדיווח על בעיית נגישות + זמן מענה
- שם רכז הנגישות (לפי גודל הארגון)
- מה נבדק ואיך (כלי אוטומטי + בדיקה ידנית)
⚠ שני שלבים תמיד — קודם מחקר עדכני (דרישות/סייגים/עדכוני תקנות יכולים להשתנות), רק אז בדיקה על סמך הממצאים. לא לבדוק לפי ידע כללי ישן.
חפש באינטרנט את המצב העדכני של חוק/תקנות הנגישות בישראל לאתרי אינטרנט (חוק שוויון זכויות לאנשים עם מוגבלות, תקנות נגישות שירות, תקן ת"י 5568 / WCAG). בדוק ספציפית: 1. מהי הרמה הנדרשת כרגע (AA? רכיבים ספציפיים?) 2. האם יש סייגים לפי גודל עסק/היקף פעילות 3. עדכוני תקנות או פסיקה משמעותית בשנה האחרונה 4. מה חייב להיכלל בהצהרת נגישות לפי הדרישה הרשמית תן לי סיכום קצר עם מקורות (קישורים), לא ניחוש מזיכרון.
לפי הממצאים שהבאת בשלב הקודם, בצע אודיט נגישות לעמוד הזה. בדוק ותקן כל סעיף שעלה כרלוונטי, ובפרט: 1. ניגודיות צבעים (טקסט מול רקע) 2. alt text תיאורי לכל <img>, אייקונים דקורטיביים עם alt="" 3. ניווט מקלדת — כל אלמנט אינטראקטיבי נגיש ב-Tab, בסדר לוגי 4. focus state ברור וגלוי 5. ARIA labels על כפתורים/קישורים ללא טקסט גלוי 6. קישורים עם טקסט תיאורי — לא "לחץ כאן" 7. <html lang="he" dir="rtl"> מוגדר נכון 8. היררכיית כותרות תקינה 9. טפסים — כל <input> עם <label> מקושר תן לי רשימה של מה תוקן, מה דורש בדיקה ידנית, ואם משהו לא תואם למה שמצאת בשלב המחקר.
⚠ בדיקה ותיקון לא מספיקים — ההצהרה חייבת להיות נגישה למבקר באתר עצמו, לא רק קיימת בקוד.
תוסיפי לי לינק בפוטר להצהרת נגישות, ותייצרי את ההצהרה עצמה כפופאפ (modal) שנפתח מהלינק. תוכן ההצהרה לפי מה שסיכמנו בשלב המחקר. אם זה אתר רב-עמודי במקום עמוד נחיתה בודד — תבני אותה כעמוד נפרד עם לינק בפוטר במקום פופ-אפ.
פרטיות
אמל"ק חוק
תיקון 13 (בתוקף מאוגוסט 2025) החמיר משמעותית את חוק הגנת הפרטיות: הגדרות מורחבות ל"מידע אישי", חובות אבטחת מידע, סמכויות אכיפה מוגברות לרשות להגנת הפרטיות (כולל קנסות), וחובת דיווח על אירועי אבטחה חמורים.
כל אתר שאוסף מידע — גם רק Cookies או אנליטיקס, לא רק טפסים — חשוף. GA4 בפני עצמו כבר יוצר חובת הצהרה.
הצהרת פרטיות — מה צריך להיות בה
- אילו נתונים נאספים (שם, טלפון, מייל, התנהגות גלישה, Cookies)
- למה (מטרת האיסוף)
- האם מועבר לצד ג' (GA4, וואטסאפ, כלי אוטומציה)
- כמה זמן נשמר המידע
- זכויות המשתמש (עיון, תיקון, מחיקה) ואיך לממש
- פרטי יצירת קשר לפניות בנושא פרטיות
⚠ תיקון 13 הרחיב הגדרות וחובות — לבדוק קודם מה המצב היום, לא לבסס על ידע כללי מיושן.
חפש באינטרנט את המצב העדכני של תיקון 13 לחוק הגנת הפרטיות בישראל ואת הנחיות הרשות להגנת הפרטיות לגבי אתרי אינטרנט. בדוק ספציפית: 1. מה נחשב "מידע אישי" בהגדרה המורחבת (Cookies/מזהי מכשיר?) 2. חובות אבטחת מידע שחלות על אתר קטן/עסק עצמאי 3. האם יש חובת מינוי ממונה הגנת פרטיות, ובאילו תנאים 4. מה חייב להיכלל בהצהרת פרטיות לפי הדרישה הרשמית העדכנית 5. חובת הסכמה מפורשת ל-Cookies (banner) ולא רק גילוי תן לי סיכום קצר עם מקורות (קישורים), לא ניחוש מזיכרון.
לפי הממצאים שהבאת בשלב הקודם, סרוק את הפרויקט ומצא כל מקום שבו נאסף מידע על משתמשים: 1. טפסים (name attributes, input fields) — אילו שדות נאספים 2. סקריפטים של צד ג' (GTM, GA4, פיקסלים, כלי צ'אט) — מה נאסף 3. Cookies שנקבעים (document.cookie ו-localStorage) 4. קריאות API חיצוניות שמעבירות מידע החוצה (webhooks, CRM) תן לי רשימה: מקור המידע → סוג המידע → יעד, ותסמן אילו דורשים הסכמה מפורשת לפי מה שמצאת בשלב המחקר. אל תנסח את ההצהרה עצמה, רק מפה את זרימת המידע בפועל.
⚠ אותו עיקרון כמו בנגישות — הצהרה שיושבת רק בקוד ולא נגישה למבקר לא שווה הרבה.
תוסיפי לי לינק בפוטר למדיניות פרטיות, ותייצרי אותה כפופאפ (modal) שנפתח מהלינק — לפי מה שמיפינו בשלב הקודם. אם זה אתר רב-עמודי במקום עמוד נחיתה בודד — תבני אותה כעמוד נפרד עם לינק בפוטר במקום פופ-אפ.
תנאי שימוש
אמל"ק — למה זה קריטי
בלי תנאי שימוש: אין הגבלת אחריות, אין קביעה מהו שימוש מותר/אסור באתר, אין סמכות שיפוט מוגדרת, ואין הגנה על קניין רוחני (תוכן, עיצוב, קוד). כשיש טופס לידים או תשלום — תנאי השימוש הם גם הבסיס למערכת היחסים המסחרית.
מה כדאי שיהיה בהם
- הגדרת השירות/המוצר
- שימוש מותר ואסור באתר
- הגבלת אחריות — במיוחד כשיש ייעוץ/תוכן מקצועי
- זכויות קניין רוחני (תוכן, מיתוג, קוד)
- מדיניות ביטולים/החזרים (אם יש תשלום)
- סמכות שיפוט ודין חל (ישראל)
- עדכון תנאים — איך מודיעים
⚠ לבדוק קודם דרישות ספציפיות לתחום (מכירה מקוונת = זכות ביטול עסקה, ייעוץ מקצועי = חוקים ייעודיים) לפני כתיבת טיוטה גנרית.
חפש באינטרנט מה נדרש בישראל בתנאי שימוש לאתר מסוג [תארו: עמוד נחיתה לשירות / חנות מקוונת / שירותי ייעוץ וכו']. בדוק ספציפית: 1. האם חלים חוק הגנת הצרכן וזכות ביטול עסקה (תשלום/הזמנה מרחוק) 2. דרישות גילוי ספציפיות לתחום (ייעוץ פיננסי/משפטי/בריאות) 3. עד כמה ניתן להגביל אחריות בישראל 4. תקדימים או הנחיות עדכניות לתנאי שימוש באתרים ישראליים תן לי סיכום קצר עם מקורות (קישורים), לא ניחוש מזיכרון.
לפי הממצאים שהבאת בשלב הקודם, צור טיוטת דף "תנאי שימוש" בעברית לעמוד [שם העמוד/העסק]. כלול סעיפים ל: הגדרת השירות, שימוש מותר/אסור באתר, הגבלת אחריות, זכויות קניין רוחני, מדיניות ביטולים (אם רלוונטי לפי מה שמצאת), סמכות שיפוט (ישראל), יצירת קשר, ועדכון תנאים. חשוב: זו טיוטת עבודה בלבד ולא ייעוץ משפטי — סמן בבירור בראש הקובץ ש"טיוטה, טרם נבדקה משפטית" לפני העלאה לאוויר.
⚠ גם תנאי שימוש שנשארים כטיוטה בצד לא מגנים על כלום — חייבים להיות נגישים באתר עצמו.
תוסיפי לי לינק בפוטר לתנאי שימוש, ותייצרי אותם כפופאפ (modal) שנפתח מהלינק — לפי הטיוטה שכתבנו בשלב הקודם. אם זה אתר רב-עמודי במקום עמוד נחיתה בודד — תבני אותם כעמוד נפרד עם לינק בפוטר במקום פופ-אפ.
מדידה
למה בכלל מודדים
בלי מדידה, כל החלטה על העמוד — עיצוב, תוכן, לאן להפנות תקציב פרסום — היא ניחוש. עם מדידה יודעים אם משהו בפועל עובד (מביא לקוחות, מניע לפעולה) או רק נראה טוב. זה ההבדל בין "אני חושבת שזה עובד" ל"אני יודעת שזה עובד, ובגלל מה בדיוק".
בפועל: מאיפה אנשים מגיעים, מה הם עושים בעמוד (איפה לוחצים, עד כמה גוללים, מה מעניין אותם), ואם ה-UI/UX ברור ומובן. זה עוזר גם לענות על שאלות עיצוב/תוכן, וגם לכוון פרסום בצורה מדויקת יותר.
💡 לפני שרואים דוגמה בפועל, כדאי לנחש: מה לדעתכם יגלה לנו דוח שכזה שאתם לא יודעים היום?
GTM — Google Tag Manager מדידה
"מיכל תגיות" — מטמיעים ומנהלים את כל קודי המעקב (GA4, פיקסלים, כלים נוספים) ממקום אחד, בלי לגעת בקוד האתר בכל פעם שרוצים להוסיף מדידה.
פתיחת חשבון: tagmanager.google.com → חשבון + קונטיינר (Web) → מקבלים Container ID (בפורמט GTM-XXXXXXX).
את ההטמעה בקוד (שני קטעי הקוד — אחד ל-<head>, אחד מיד אחרי <body>) לא צריך לעשות ידנית — מספיק לתת לקלוד קוד את ה-ID, והוא מטמיע את שניהם נכון:
תחבר לי GTM לפרויקט, ה-ID הוא GTM-XXXXXXX
GA4 — Google Analytics 4
מראה כמה אנשים נכנסים, מאיפה הגיעו, מה עשו (גלילה, קליק, שליחת טופס), ואיפה נטשו. לא מתקינים ישירות בקוד — מתקינים כתג בתוך GTM, לשליטה מרכזית.
איך פותחים נכס (Property):
- analytics.google.com → אייקון Admin → Create → Account (אם אין עדיין) → Property
- שם הנכס + אזור זמן ומטבע — לפי מיקום בעל האתר, לא הלקוח או קהל היעד (קובע את אזור הזמן בדוחות; שינוי מאוחר יותר משפיע על חלוקת הנתונים ההיסטוריים)
- פרטי עסק (תעשייה, גודל) ולפחות מטרה עסקית אחת → בוחרים פלטפורמה: Web → מזינים URL מלא (עם https://) ושם ל-Data Stream
- Enhanced Measurement מומלץ להשאיר דלוק — עוקב אוטומטית אחרי גלילה, קליקים יוצאים, חיפוש באתר, הורדות
- מקבלים Measurement ID (בפורמט G-XXXXXXX) — משתמשים בו בתוך GTM
בתוך GTM: תג חדש → "Google Analytics: GA4 Configuration" → Measurement ID מ-analytics.google.com → טריגר: All Pages.
שלושת מושגי היסוד: Tag — הקוד שרוצים שיפעל · Trigger — מתי הוא יופעל (למשל All Pages, או קליק על כפתור) · Variable — מידע שהתג/הטריגר צריכים (Measurement ID, טקסט כפתור). תג בלי טריגר לא יופעל אף פעם.
הקמת ה-Tag/Trigger/Variable נעשית בממשק הוובי של GTM, לא בעריכת קוד:
תדריך אותי צעד-אחר-צעד איך להקים ב-GTM תג GA4 Configuration: איזה סוג תג לבחור, אילו Variables להגדיר (ה-Measurement ID שלי הוא [G-XXXXXXX]), ואיזה Trigger לחבר אליו כדי שיפעל בכל טעינת עמוד. תסביר גם איך בודקים שזה עובד דרך מצב Preview לפני שמפרסמים.
אחרי שהתג הבסיסי חי — שווה למדוד גם קליקים על כפתורים חשובים (וואטסאפ למשל), דרך Trigger מסוג "Click - All Elements" בממשק GTM, בלי לגעת בקוד:
תעבור על עמוד הנחיתה שלי ותציע לי מה כדאי למדוד — אילו כפתורים, קישורים או פעולות (קליק על וואטסאפ, שליחת טופס, גלילה לסקשן מסוים) הכי משמעותיים להבנת ביצועי העמוד. בשביל כל אחד, תגיד לי איזה Trigger להגדיר בממשק של GTM כדי למדוד אותו.
💡 טיפ — דוחות אוטומטיים למייל: לא צריך להיכנס ל-GA4 כל פעם. בתוך GA4 → Reports → פותחים דוח → Share this report → Schedule email delivery — קובעים תדירות (שבועי/חודשי) ומקבלים סיכום ישירות למייל.
💡 איך מסתכלים על אנליטיקס בלי ללמוד לנווט בדוחות: יש ל-GA4 עוזר AI מובנה. חושבים מה רוצים לדעת ("מאיפה הגיעו הכי הרבה מבקרים החודש?" / "כמה לחצו על כפתור הוואטסאפ השבוע?") ושואלים בשפה חופשית בממשק — הוא בונה את הדוח בעצמו.
MS Clarity — מפות חום
כלי חינמי של מיקרוסופט שמראה איך אנשים בפועל משתמשים בעמוד — הקלטות מסך אנונימיות + מפות חום (איפה לוחצים, עד איפה גוללים, איפה "נתקעים"). משלים את GA4: GA4 אומר מה קרה, Clarity מראה למה.
איך פותחים פרויקט:
- clarity.microsoft.com → התחברות עם חשבון Microsoft/Google → שם לפרויקט + כתובת האתר → Add new project
- בתוך הפרויקט: Settings → Setup → Google Tag Manager → Finish setup — מתחברים עם חשבון Google
- בוחרים את חשבון ה-GTM ואת הקונטיינר הרלוונטי מהרשימה → Create and publish
- Clarity מטמיע את התג אוטומטית בתוך ה-GTM הקיים ומפרסם — לא צריך לגעת בקוד או בקלוד קוד בכלל
💡 טיפ — מה לחפש במפת החום: אם רואים הרבה לחיצות במקום שהם לא אמורים ללחוץ (אלמנט שנראה ככפתור אבל לא, טקסט שמושך קליקים בלי סיבה) — זה סימן שה-UI לא ברור, לא רעש רקע להתעלם ממנו.
בקצרה — Search Console
כלי נוסף ששווה להכיר, לא בלוק מלא כמו GTM/GA4/Clarity.
מראה איך גוגל עצמו רואה את העמוד: אינדוקס, שגיאות סריקה, באילו חיפושים בפועל העמוד מופיע. משלים את GA4/Clarity בזווית שונה — איך גוגל מגלה ומדרג את העמוד.
איך מתחילים:
- תחילה, נכס Search Console חייב להיות קיים ומאומת: search.google.com/search-console → הוספת נכס → אימות בעלות. שיטות אימות אפשריות: דרך GTM שכבר מותקן (מומלץ, בלי לגעת בקוד), רשומת DNS, או תג META ב-
<head> - אחר כך, אם יש GA4 מותקן — אפשר גם לחבר ביניהם: GA4 → Admin → Product Links → Search Console Links → Link
- שיטת ה-GA4 דורשת owner מאומת ב-Search Console + עורך ב-GA4. נתונים זורמים תוך 24–48 שעות
תהליך בממשק גוגל בלבד — אין צורך בפרומפט לקלוד קוד.
בקצרה — Core Web Vitals
מדדי מהירות/חוויית טעינה שגוגל משתמש בהם בפועל כגורם דירוג. בודקים ב-pagespeed.web.dev.
התהליך: נכנסים לאתר, כותבים את ה-URL, נותנים לו לסרוק, מעתיקים/מייצאים את הדוח, ונותנים אותו לקלוד קוד לתקן:
הרצתי בדיקה ב-PageSpeed Insights על העמוד וזה הדוח שהתקבל: [הדבק כאן את הדוח / את הממצאים העיקריים] תעבור על הממצאים ותתקן את הבעיות שמורידות את הציון של Core Web Vitals (LCP, CLS, INP) — תסביר לי לכל תיקון למה הבעיה השפיעה על הציון ומה תיקנת.
צ'קליסט סיום
לעשות עכשיו, על העמוד שלכם — לא בסוף השבוע